[coyotos-dev] Some comments on Coyotos Microkernel Specification

[Bill Frantz]

On 12/22/05, shap at eros-os.org (Jonathan S. Shapiro) wrote:

>On Wed, 2005-12-21 at 22:39 -0800, Bill Frantz wrote:
>
>> There is still the question of the parameters.  KeyKOS, EROS, and I
>> assume Coyotos have the characteristic that a caller can pass fewer
>> capability parameters than the receiver receives.  Un-passed
>> capabilities are represented as Null capabilities to the receiver.
>
>There are two ways one could read what you say above:
>
>1. The sender can send a malformed message. This is true in all systems,
>and I don't think you are talking about this.
>2. The sender can decline to send capability parameters. I think you are
>referring to this.
>
>In KeyKOS, this was true. In EROS/Coyotos, it is not. In EROS, you
>*must* send four capabilities. The convention is to send a void
>capability explicitly if you have no other capability to send. The API
>has no bitmask to control which capabilities are sent. I chose instead
>to "softwire" capability register 0 to void and let the sender send from
>register 0.
>
>I will adopt a similar approach in Coyotos, but matters are more
>complicated there. You still can't "skip" a capability, but there are
>going to be more cases in which the message is malformed, and we will
>need to design some means for the receiver to detect this.

Sorry for a poor description of the situation in all three systems.

As I see it, it doesn't matter whether you use the KeyKOS approach of
having a bit mask which specifies which capability parameters are
offered, and having the kernel substitute a null capability for those
that aren't offered, or whether you have capability register 0 always
contain null, and specify register zero when you don't want to offer a
capability.  The question I was trying to get at is, "Is a null
capability in this argument position semantically meaningful?"  That is
something that a method parameter requirements discovery protocol should
be able to express.

One Java coding convention I have used to express
this possibility is including the string /*nullok*/ in the prototype. 
For example in a Hashtable:

   Object /*nullok*/ put(Object key, Object value);

(Hashtable.put throws an exception if either key or value is null.)

This convention is obviously a hack to get around a missing feature in the language.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | gets() remains as a monument | Periwinkle 
(408)356-8506      | to C's continuing support of | 16345 Englewood Ave
www.pwpconsult.com | buffer overruns.             | Los Gatos, CA 95032