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

[Jed Donnelley]

On 2/12/2008 4:01 PM, Charles Landau wrote:
...
> What I meant by "using a private interface" was this: After using 
> Amplify Gate Key, a process could use the resultant Process key to 
> obtain a start key to a facet of the other process. That facet is 
> used only internally, and when calling it, the callee is willing to 
> reveal more-private data. This can be used where you need some 
> synchronization that you can't get with shared memory.
> 
> Terminology:
> In EROS and CapROS, the facet identifier is 16 bits and is called the 
> keyInfo. It is stored as part of the capability.
> In KeyKOS, a process is called a "domain", a start capability is 
> called an "entry" key (following Dennis and Van Horn), and the facet 
> identifier is the "databyte" (because it is 8 bits).

I think I get the idea.  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.

How did you manage with such minimal information to
distinguish sufficient keys/capabilities serviced by
a "deputy"?  Didn't you use such deputies, for
example, for open network ports?  Perhaps 64k would
work in that case, but surely not 256?  Did you
end up using multiple service processes mainly
to allow support for more objects in some cases?
The programming for such seems awkward to me, but
perhaps there was a simplification that isn't
immediately obvious?

I was able to find the databyte and Key Info fields in:

http://www.cis.upenn.edu/~KeyKOS/agorics/KeyKos/Gnosis/67.html#iden

and in:

http://www.eros-os.org/devel/ObRef/standard/ProcessCreator.html

respectively, so that helps explains what was going on there.

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?
I know this was an issue we had to deal with in NLTSS, so I'm
just curious how you dealt with it in KeyKOS and heirs.

Thanks Charlie!

--Jed  http://www.webstart.com/jed/