[cap-talk] KeyKOS, EROS, CapROS keyInfo/databyte (was: Re: EQ, MyCap? review)
clandau at macslab.com
Tue Feb 12 22:54:46 EST 2008
At 5:13 PM -0800 2/12/08, Jed Donnelley wrote:
>One thing that's curious to me is
>the 16/8 bit size of the keyInfo/databyte. I know that
>the equivalent in our NLTSS work was essentially a pointer
>of 64 bits. I suppose that with a 16 bit keyInfo you
>were able to support 64k distinct objects? Even that
>seems a bit limiting to me, but certainly only having
>the option for 256 seems almost impossibly constraining.
it is limiting, and we use(d) the pattern described by Eric Northup
in another message.
KeyKOS: Red segment (can also be used as a segment)
EROS: wrapper (can also be used as a segment)
Coyotos: endpoint (endpoints also have other features)
(We're not actually trying to be confusing, just moving towards better terms.)
>Since I believe I recall the KeyKOS, EROS, and CapROS capabilities
>are persistent, presumably you needed to use sufficient distinct
>"Key Info" values to distinguish from all possible past instances
>of capabilities (even if no longer valid) for a given deputy?
To add to what Eric and Jonathan have said: you could in principle do
what I think you are suggesting, which is to use new keyInfo values
for new objects, and retire keyInfo values for rescinded instances. I
don't recall any case where we did so, for two reasons.
(a) You need 2**8 or 2**16 bits to keep track of the valid keyInfo values.
(b) If clients allocate all keyInfo values and rescind all but one,
you still need to keep the server process around. If you want to make
the client responsible for the resources, then the "cost" of one
object is thus as much as one process anyway, so why not always use
one process per object.
More information about the cap-talk