Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

[Pekka Enberg]

Hi Linus,

[I am getting off-topic but...]

On Wed, 1 Dec 2004, Alexandre Oliva wrote:
> > Most of that is covered by the software engineering term `contract'.

On Wed, Linus Torvalds wrote:
> I think you're making that up. Maybe there's some sw cult that swears by
> "contract programming", the same way there are the "extreme programming"
> cults etc.  For example, I find this "Design by Contract" cult for object-
> oriented programming, but it has _zero_ to do with external API's, and is
> all about the interfaces for object-oriented components.

How is a class interface different from an external API? Sure, you
don't want to change a _published_ API too often but I fail to see how
internal and external APIs are fundamentally different.

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 Wed, Linus Torvalds wrote:
> IOW, I don't find your arguments or your language usage in the least
> convincing. But hey, I did all my CS stuff outside of the US, whatever.

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...

                              Pekka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/