[cap-talk] kernel object knowledge

Jonathan S. Shapiro shap at eros-os.com
Fri Jun 1 06:38:41 EDT 2007


On Wed, 2007-05-30 at 10:53 -0700, Charles Landau wrote:
> Assuming the system has an EQ operator, both kinds of membranes can 
> determine whether passed capabilities are distinct and thus need to 
> be separately wrapped. Thus it's O(n-distinct-caps-xferred) for both.
> 
> >Neither number is usefully small, since both
> >numbers considerably exceed available storage. Indeed, both requirements
> >likely exceed total historical world production of real storage media.
> 
> I don't see how this statement can be justified. Let's take an 
> example. Consider a membrane that wraps a key to some output device 
> such as a terminal or system log (see for example 
> http://www.eros-os.org/devel/ObRef/kernel/LogAppend.html). The only 
> key that needs to be wrapped, other than the original log key, is the 
> resume key from the call. (All other passed keys are EQ to the void 
> key.) On each call, a new resume key is passed. But, the membrane can 
> observe that previous resume keys have become void and thus no longer 
> need to be wrapped. So in this case the storage is actually bounded 
> to that needed to wrap two keys.

What you are describing isn't a membrane. It is a wrapper. I agree that
what you say is true for a wrapper. Membranes, as they have been
discussed on the cap-talk list, are required to do full causal tracking,
and this requires much more comprehensive wrapping.

For membranes, the basis of my assertion is that in Coyotos there may be
2^64 processes each serving 2^96 differentiable objects (more precisely,
2^64 objects, each of which may have outstanding capabilities with 2^32
distinct protected payloads).

To completely wrap such a process, we would need 2^64 wrapper objects
per process.

These wrappers are of course introduced dynamically. But in a *membrane*
they must reflect causal connectivity as well, so each and every
invocation must create a new wrapper unless the membrane implementation
is able to unify revocation domains.

shap
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC



More information about the cap-talk mailing list