Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

From: Peter Williams
Date: Thu Dec 02 2004 - 17:19:03 EST


Tomas Carnecky wrote:
Peter Williams wrote:

Design by contract isn't really an agreement between the caller and the callee (which may not even exist when the contract is created). It's more of a (one way) promise by the callee that if the interface is used as described in the contract that it will correctly perform the advertised operation (where the advertised operation generally includes descriptions of possible failures and how they will be signalled). Most C APIs meet these criteria even though their pre and post conditions are expressed less formally than an Eiffel interface.


Design by Contract, as seen in the Eiffel language, is not a one way promise, it's a contract between the caller and callee. Both sides have
to fullfil their part of the contract, the caller has to make sure that
the input are valid, and (only) given that, the callee can/has to make
sure that the caller gets the right output.

BTW, Bertrand Meyer is one of my professors, I should know the Eiffel language... :)

Yes, but I still think it's essentially a one way thing. The writer of the callee doesn't have to consult with the writer of the caller to negotiate the contract (although that option isn't ruled out either) so it's essentially a unilateral promise on the part of the callee. This would especially be the case when writing library interfaces as it's impossible for the writer of the callee to negotiate with all the (potential) writers of callers to agree on an interface.


I agree but think it's important to realize that it's a unilateral promise on the part of the callee (rather than agreement between the callee and the caller) which is in accord with Linus's view of the ABI.


Whenever you have two sides/parties, you have to agree on _something_, otherwise you can't communicate, if you speak to someone, you have to choose a language in which to speak, that's the first agreement.
In this situation you have two sides, the kernel and the userspace. Your first agreement is the syscall number, and then the arguments, the type and format of the arguments, etc. Both sides have to agree on those things.

Not really. In the final analysis, userspace has to accept what the kernel provides. It's not really a conversation it's more like a billboard on which the kernel describes an interface and makes promises about how it will operate if used according to the specification (or contract). If the caller fails to use the interface within the constraints of the specification (or contract) then the result is indeterminate and the callee can do whatever it likes including failing silently or even crashing (although that wouldn't be a good idea for a kernel interface).

Peter
--
Peter Williams pwil3058@xxxxxxxxxxxxxx

"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
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/