[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