[cap-talk] KeyKOS, EROS, CapROS keyInfo/databyte (was: Re: EQ, MyCap? review)

[Charles Landau]

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.

More terminology:
KeyKOS: Red segment (can also be used as a segment)
EROS: wrapper (can also be used as a segment)
CapROS: forwarder
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.