[coyotos-dev] Some comments on Coyotos Microkernel Specification
frantz at pwpconsult.com
Thu Dec 22 20:48:50 EST 2005
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
>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
More information about the coyotos-dev