Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[Pekka Enberg <penberg@cs.helsinki.fi>]

On Thu, 2 Dec 2004, Pekka Enberg wrote:
> > How is a class interface different from an external API?

On Thu, 2004-12-02 at 07:35 -0800, Linus Torvalds wrote:
> It's different from an external API exactly because it's not "external". 
> 
> I dunno about you, but the (admittedly few) explicitly object-oriented 
> projects I've seen from the inside, the class interface is something that 
> you consider internal to your project, and are willing to change.
> 
> In Linux, the VFS layer comes pretty close: it's really very much about
> object-oriented programming, except the implementation is explicit rather
> than left up to the programmer. And we have very explicit rules on how
> you're supposed to do things: some are even _documented_ (oh, horrors) in
> Documentation/filesystems/vfs.txt.
> 
> And yes, in this kind of environment I actually think "contract" makes 
> some kind of sense, because it is an internal thing that _has_ come out of 
> agreement on both sides, and where changes need to be agreed upon by both 
> user and definition. It's not an a-priori interface, it's something where 
> both sides are intimately involved.

I tend to think the other way around actually. For published (external)
APIs, contracts are far more important because you cannot review or test
the callers. For internal APIs, contracts can be more relaxed as you
usually have full control over the codebase. So no, I don't think
contracts are for internal use only.

On Thu, 2 Dec 2004, Pekka Enberg wrote:
> > I think Alexandre's definition has in fact originated from the "Design
> > by Contract" cult. And it's all pretty simple stuff:
> > 
> >   - You need to call a function in a certain way (precondition). The
> >     caller fills this part
> >     of the contract. Now the caller can _expect_ something from the
> >     function (see below).
> >   - The function does what it has promised to do and optionally
> >     returns some values
> >     (postcondition). The callee fills this part of the contract.
> >   - The function expects some parts of the system state to remain stable during
> >     execution (invariants). In the kernel, you use BUG_ON for these btw.
> > 
> > So there's nothing new here really. However, if your _tools_ support
> > Design by Contract, you can be explicit about this and enforce the
> > 'contract' during compile-time or run-time.
> > 
> > And I think you're already doing this with your "require spinlock to
> > be taken" sparse thingy...

On Thu, 2004-12-02 at 07:35 -0800, Linus Torvalds wrote:
> Yes. And I think it makes sense _internally_ for a project. 
> 
> But pretty much by definition, that's not an ABI. That's an "internal 
> interfaces" kind of thing.

And why not externally too? There are elements of a contract, I think.
The kernel, for example, dictates that you must invoke syscall A with a
pointer X pointing to an memory region of size E. Now, if the userland
follows that contract, it gets service; otherwise it won't. And as soon
as the userland _agrees_ with the contract, the kernel _must_ deliver
the service as specified by the contract.

Please note that the kernel may change the contract on its part any time
it wishes to do so. The userland can either accept the fact or reject it
and live without the service. And this is what you're essentially doing
right now. The only thing you're missing is actually _enforcing_ those
contracts.

But anyway, I think I'm twisting the original definition of Design by
Contract here for my own purposes and the only thing I violently
disagreed with you was the fact that you claimed Alexandre was making up
terms. ;)

On Thu, 2 Dec 2004, Pekka Enberg wrote:
> > I don't think it's an US thing. At the university you did your CS
> > stuff, we (well at least I) use the term 'contract' pretty much the
> > same way Alexandre does...

On Thu, 2004-12-02 at 07:35 -0800, Linus Torvalds wrote:
> It may also be a new thing. Dammit, when I started, we had USCD Pascal,
> and we were happy. None of this OO stuff ;)

Yeah, they've ruined it completely now. They're pushing Java right from
day one to youngsters :-)

			Pekka