[coyotos-dev] Endpoints and replies
Jonathan S. Shapiro
shap at eros-os.org
Tue Jan 17 17:31:10 EST 2006
[I am forwarding the following note on behalf of Norm Hardy, who
originally sent this to me privately.]
-------- Forwarded Message --------
From: Norman Hardy <norm at cap-lore.com>
To: Jonathan Shapiro <shap at cs.jhu.edu>
Subject: Exposed call count
Date: Tue, 17 Jan 2006 13:04:09 -0800
If there is or was a discussion of this on the coyotos mail list I
did not see it.
I would be glad to put this on that list (giving you credit) unless
You call the "call count" something else—I forget what.
I ran into a problem at the end of the note.
You propose to expose the call count and thus remove hair from the
There are two aspects to this: (1) kernel semantics, (2) kernel
The later subdivides into (2a) code size and (2b) code complexity
There is also the issue of new complexity in domain land.
As I understand the proposal the 3 kernel states would be simplified
by eliding waiting and available.
In their place would be a new state that was receptive to only some
subset of gate keys and
that subset would be defined by a subset of data byte (GPL (guarded
Domain logic would somehow specify this subset.
Likewise start keys and resume keys would be elided to mere gate keys.
The call would specify a GPL value for a new key to the caller, much
as resume keys are
produced in the old plan.
The caller is advised to produce a distinct value upon each call if
he must guard against stale resumption.
I recall a vague proposal that we did not implement for Keykos, or
even write down.
It would have given priority on the stall queue to start keys whose
data byte value was greater than some fixed constant, say 192.
This provided an extremely simple priority scheme that was trivial to
specify and implement.
If the benefit had been more than hypothetical we would have
I see no problem in the caller specifying the subset of GPL values
via which it will accept messages.
It certainly need not be an arbitrary subset.
Indeed it might be all or singlton zot where zot is the GPL value in
the last call operation.
Allowing some slightly more general subsets might be strategic however.
Perhaps such generality should be deferred until concrete demand is
To solve the problem of overflow of GPL values one can use a sever
operation on the domain (process) root which would dissolve all
That would also dissolve the keys playing the role of start keys in
the old plan and that is bad.
Alternatively a node could have two sorts of allocation count, as it
has two in the old plan.
I would call these the front door key and the back door key.
Alas this is tending back to the disadvantages of the old plan.
Have you another idea here?
More information about the coyotos-dev