[cap-talk] Objects and Facets, the Hurd and capabilities

Jed at Webstart donnelley1 at webstart.com
Wed Aug 2 20:20:09 EDT 2006


At 05:23 AM 8/2/2006, Neal H. Walfield wrote:
>I understand the terms object and facet in the following way: an
>object encapsulates some state which can be sensed or manipulated
>through capability invocations; a facet presents an object with
>diminished authority, e.g. a read-only facet.

I see that some have used the term "facet" in the above way, e.g.
the sub thread that starts here:

http://www.eros-os.org/pipermail/cap-talk/2006-June/005267.html

I believe the "facet" term is relatively obscure.  Since it really
only means a particular type of capability and I expect nearly
any capability can be considered as a "facet" of another more
powerful capability, the term seems pretty meaningless to me.
I don't recommend using it, though it seems to show up in
some of the erights capability documentation.

If anybody wants to defend the "facet" term as meaningful in
it's own right (necessarily distinct from capability), it seems now
would be a good time to do so.

>On the Hurd,

Regarding the Hurd and capabilities - has anybody done a network
extension of capabilities for the Hurd?  Nobody on this should be
surprised to hear me say that I believe such an extension should
be written and tested before any Hurd capability mechanism is
"finalized".  If it has been done I'd be very interested to hear how it
went.  If not I'd like to know why not.

Is there a general summary of capabilities in the Hurd somewhere?

Does anybody believe the Hurd has a chance to be a capability base
to build from that many of us are looking for (why or why not?)?

I'd particularly like to know how far this statement goes:
(from: http://www.gnu.org/software/hurd/hurd.html ):

it's compatible
     The Hurd provides a familiar programming and user environment. 
For all intents and purposes, the Hurd is a modern Unix-like kernel. 
The Hurd uses the GNU C Library, whose development closely tracks 
standards such as ANSI/ISO, BSD, POSIX, Single Unix, SVID, and X/Open.

Perhaps I can give the sense of my question if I ask how one would
put a YURL into a directory on the Hurd?

>we have the following: a file consists of its contents
>and some meta-data.  When a user calls "open", the file server doesn't
>simply return a capability naming this state; it first allocates some
>memory to hold, among other things, the position of the cursor in the
>file and returns a capability naming that state.  This state is
>private to each open.

To me that sounds like an "open file" capability as distinct from
a "file" capability.  I'm agreeing with Charles Landau when he said:

"I would just call it an OpenFile, since all capabilities are handles."

and really everything he said in his message on this topic.

>In the language of capabilities, what would be the file object here?
>Is it the shared state and the private state?  (If so, is the shared
>state also a separate object from this conglomeration of the shared
>state and the private state?)  Is it the private state with the
>addition of a capability naming an object encapsulating the shared
>state?  In short, what's the right way to talk about these things?

There is no constraint on any sharing that may or may not go on
behind the scenes.  There are capabilities of various sorts and
the "objects" that they grant permission to access.  That's it
as far as I know.  Any such "object" is no more that the sum
total of the permissions granted by the capability - meaning that
they could be very "un object" like.  E.g. a capability to a compiler
service.  Invoke it and send it a file, it sends back some control
results (e.g. errors, perhaps in a file) and perhaps some object
output.  Is that compiler an "object"?  In capability parlance it seems
to me it is, though of course it's also a program combined with some
sort of active server.

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




More information about the cap-talk mailing list