[cap-talk] 'Destroy' vs 'Sever'

[Charles Landau]

At 1:57 PM -0500 11/27/07, Jonathan S. Shapiro wrote:
>On Mon, 2007-11-26 at 21:11 -0800, Charles Landau wrote:
>
>  > I repeat, Sever is not an operation on the object.
>
>But aside from implementation convenience, it is not clear why this
>should be so.

I meant, in CapROS/EROS/KeyKOS, Sever is not currently an operation 
on the object.

>If I allocated an object, I can accomplish the effect of
>sever via:
>
>   new alloc
>   shallow copy
>   destroy old
>
>Given which, it does not seem that there is any semantic or security
>motivation that would *preclude* making sever a per-object operation
>[except, of course, that we would then need to implement non-several
>page caps in the same way that we have non-writable page caps].

I agree. The ability to sever needs to be controlled the same way the 
ability to destroy is.

In CapROS etc., there is no destroy operation on a page either, but 
there could be.

>I think this question is worth exploring briefly, because it sheds light
>on the semantic distinction between severing storage and destroying the
>object that resides in that storage. The confusion is exacerbated
>(unavoidably) in KeyKOS/EROS/Coyotos because certain data structure
>(e.g. Node, Page, GPT, Process) have simultaneous roles as constituent
>storage of an aggregate object and as objects in their own right.

The issue is, what should the semantics of Sever be? I claim it 
should be to invalidate all external caps to the object, but not 
change the internal state of the object. So, if it has internal 
references, they need to be preserved. Basically, Sever would be 
defined to have the same semantics as clone and destroy, where the 
clone is done to whatever depth makes semantic sense for the object.

Given that, the purpose of Sever is only to do clone and destroy more 
efficiently. For the many objects that don't have internal references 
to the root, it can be very efficient. I don't think it's ever less 
efficient than clone and destroy.