[cap-talk] In Defense of Identities - not

[Marcus Brinkmann]

At Wed, 06 Dec 2006 16:01:09 -0500,
"Jonathan S. Shapiro" <shap at eros-os.com> wrote:
> 
> On Wed, 2006-12-06 at 15:44 -0500, Jonathan S. Shapiro wrote:
> 
> > 1. Introducing a wrapper is incredibly expensive (thousands of cycles).
> 
> And when you think about it, this is quite a nasty statement. If
> membranes are a frequently manipulated pattern this will almost
> certainly perturb the OS, because it means that for efficiency reasons
> the OS must have explicit cognizance of membrane domain boundaries.
 
> This in turn means that we are introducing an entirely new capability
> model, because one of the operations (we may want others) takes the
> form:
> 
>   domain->revoke(cap)
> 
> and we don't want to search the domain to hunt them down. This is quite
> a serious mess.

I am not sure I understand what this operation does and what is
searched.

> But there is a bigger problem. I haven't heard anybody articulate a
> sensible algebra for membrane construction. Consider processes in three
> different revocation domains A, B, C.
> 
>   A sends cap 'c' to C.
>   B sends cap 'c' to C.
> 
> A revokes cap 'c'. Does C still have it? Which copies?

It seems to me that the sensible option is to revoke the copy from A
and retain the copy from B.

> Must the sender be explicitly aware of membrane domain boundaries,
> or should the "wrapping" be implicit in the transport?

That's the tough one.  Also, should the whole delegation chain of the
invoked capability be duplicated, or should the fetched capability be
delegated from the invoked capability in the revocation dependency
tree?  Neither option seems very attractive to me.

> What are the implications for EQ and EQUAL?

Common sense seems to suggest that eq? should ignore delegation
completely.

Thanks,
Marcus