Re: capability types

[Jonathan S. Shapiro]

On Sat, 2005-10-15 at 20:21 +0100, Neal H. Walfield wrote:
> At Wed, 12 Oct 2005 14:10:34 -0400,
> Jonathan S. Shapiro wrote:
> > 2. A capability *names* precisely one interface, by
> >    definition. This interface *may* (but need not) include
> >    operations that return other capabilities. These other
> >    capabilities may or may not name the same representation
> >    state as the original capability.
> > 
> >    Examples:
> > 
> >      The Void capability does not have any methods that
> >      return capabilities.
> > 
> >      The EROS read-write page capability has an operation
> >      that returns a read-only capability to the same page.
> > 
> >      An EROS space bank capability has an operation that
> >      returns page capabilities. These capabilities
> >      do not name the space bank.
> 
> I think I understand your examples but I am not convinced that: we can
> statically determine what interface a capability names based strictly
> on the RPC name; nor that a capability necessarily names precisely one
> interface.

I have never claimed that we could statically determine what the
interface of a capability is. In a previous thread I explained why the
capability type system is necessarily dynamic: dir_lookup("name") must
be able to return a capability whose static type is unknown.

In fact, we cannot even *dynamically* determine the capability type. In
the absence of some unusual authority, there are only three ways we can
know the type of a capability:

  1. We can ask the capability what it's interface type is,
     and of course the capability may lie. Sometimes this is useful!
     The capability may be virtualizing some other object!

  2. We can know the capability type by virtue of knowing how
     the capability was created.

  3. Positive identification. We may have access to the constructor
     of this capability, which might allow us to affirmatively identify
     it. This case is rarely used.

As to whether a capability implements a single interface: the answer is
"yes", by definition.

Given a capability, there is a known set of "methods" or "requests" that
can be performed. As programmer, *you* may be confused about what the
set is, or you may have incomplete information, but the capability names
some object, and if you request an operation that the object does not
understand then the request will fail. This set of requestable
operations is the capability's interface. That is the *definition* of an
interface, and a given capability clearly can have only one such
interface.

We may, by convention, define useful subsets of this interface (as in an
interface hierarchy), but the capability ultimately implements exactly
one concrete interface that is precisely defined.

I think what you were really trying to say is that we may not know
statically what this interface is. This is why I view the CapIDL
descriptions as a useful convenience shorthand rather than an
enforceable static type system. It is, however, a *very* useful
shorthand.

> 
> In the Hurd, most objects are made accessible via the virtual file
> system.  When a task wants to create a pipe, for instance, the
> standard Hurdish idiom is to ask the pflocal server.  To find the
> pflocal server, a task obtains a capability to `/servers/socket'
> (which presumably names the fs, i.e. directory, interface).  The task
> invokes that interface using the dir_open method with the string
> argument "1".  (Why 1?  That is the number associated with PF_LOCAL.)
> The returned capability presumably names the socket (server)
> interface.  The reason that we know this is not because dir_lookup
> necessarily returns capabilities which name the socket interface but
> because by convention, the node /server/socket/1 names an object which
> can create sockets.
> 
> Using the capability, I can invoke the socket_create method.  The
> pfinet server will typically return a capability which names the
> socket (client) interface AND the io interface.  Using the socket
> (client) interface, a task, for example, can connect two sockets to
> create a socket pair.  Using the io interface, a task can read from
> and write to a socket.
> 
> How would capidl express these two usage modes?  Would you recommend a
> different model?

Exactly as you do. Each of the descriptors in your explanation has
exactly one interface.

I think we are confusing interfaces for types. dir_lookup("name"), for
example, can return an arbitrary capability type. Once you have the
capability back, however, that capability has well defined behavior, and
you can ask the capability what its behavior is.

shap