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

Jed Donnelley jed at nersc.gov
Tue Nov 27 19:26:15 EST 2007

On 11/26/2007 7:37 PM, David Hopwood wrote:
> Jed Donnelley wrote:
>> ...a file/page/segment will not 'malfunction'
>> in this way with typical semantics.
> But the objects whose storage is backed by the file/page/segment
> may malfunction.

Of course.  That's the intent of such a "Sever" operation
as I understand it.

Sorry, but I'm going to skip around a bit here in this thread
by what I feel is necessity.  Next:

On 11/26/2007 9:11 PM, Charles Landau wrote:
> At 3:37 AM +0000 11/27/07, David Hopwood wrote:
>> ...So the presence of the Sever operation implies that
>> this composite is not defensively consistent.
> I repeat, Sever is not an operation on the object. Therefore clients
> cannot Sever.

I'm afraid I'm still a little lost with the above.
If a "client" can't issue a Sever request, who can?
Aren't all requesters in some sense "client"s?
How is a Sever request authorized?

On 11/27/2007 11:26 AM, Charles Landau wrote:
> 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.

The above makes some sense to me except for the reference
to "the root".  Can you describe what "the root" is in
the above context Charlie?

On 11/26/2007 7:47 PM, Jonathan S. Shapiro wrote:
> Note that if NewCap is implemented, it almost requires a per-capability
> permission bit that permits or restricts this operation.

The above is interestingly insightful.  We did have such
a bit - somewhat was sadly (in my opinion) referred to as an
"ownership" permission.  I just spoke with a couple of
the NLTSS developers who pulled out some listings and
verified this.

With regard to:

On 11/26/2007 9:11 PM, Charles Landau wrote:
> At 4:49 PM -0800 11/26/07, Jed Donnelley wrote:
>> 1.  Our NLTSS system had what I believe are these
>> operations.  We called them 'Destroy' and 'NewCap'.
> Do you know if anyone made good use of NewCap?

I don't believe there ever was any good use made
of this "NewCap" function.  However, I don't necessarily
think that reflects poorly on it's design as almost
no programmers saw any of the capability interfaces
in NLTSS.  The only way for NewCap to be effectively
used would be to have it used by the LTSS emulation.
I don't believe it was used in that emulation.

We were trying to address the "lose capabilities"
concerns and really needed something like a membrane
implementation, but we didn't get there.  E.g. what
good is "NewCap" on a directory (c-list) if
capabilities have been removed before the
"NewCap" operation is done on the directory?

With almost all the practical use of the NLTSS
system happening through the LTSS API, the
capability interfaces effectively got frozen
in the early 1980s and were never fully explored.
Most of the changes in NLTSS after about
1984 were work on the LTSS emulation and work
on improving performance (e.g. "servers in
the kernel").

I found this insight interesting and potentially

On 11/27/2007 10:57 AM, Jonathan S. Shapiro wrote:
> Part of the disconnect that I think you and David Hopwood are having
> stems from the fact that in a language-based system the duality of
> storage and (language) object is never exposed in the operations.

but I don't think I know enough about the issue to contribute.
I'll file that one and look for it when the opportunity

Sorry for the jumping around - just doing the best I
can to respond coherently with anything I might be
able to contribute to this thread.

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

More information about the cap-talk mailing list