Re: Meaning of IDL

[Jonathan S. Shapiro]

On Wed, 2005-10-12 at 12:47 +0100, Neal H. Walfield wrote:
> How do you handle the case where a single capability implements
> multiple (and potentially unknown) interfaces?  In the Hurd, file
> systems implement the fs interface, which provides mechanisms to find
> and manage nodes (think manage directories).  If I have a capability
> which implements the fs interface, I can invoke dir_lookup(cap, name)
> to retrieve a capability to the object named NAME in the context of
> CAP.  The returned capability can provide any number of interfaces.

Ahh. I see that I have executed an out-of-order reply. My apologies.

First, we need to clear up terminology.

1. A capability does not implement interfaces. A server does.

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.

3. The Void capability is probably misnamed. It should probably
   have been named the "Invalid Capability". The role of a void
   capability is comparable to the role of a null pointer value.

Now on to the question I think you meant to ask:

What you appear to be asking is a question about the type system of
capabilities. The same problem can appear in argument capabilities.
Consider dir_insert(dircap, name, someCap).

OS-style capabilities are dynamically typed -- if you want to implement
in C we have no way to enforce the static typing suggested by the IDL.
In any case, the IDL-stated type is only alleged. An implementing server
might, of course, lie.

So finally, in answer to your question:

The CapIDL solution is interface single inheritance. In practice, we
have exactly two "top level" interfaces: Void and Cap. The Coyotos
specification for the "cap" interface is here:

http://www.opencm.org/opencm/~/PUBLIC/coyotos/DEV/sys/17/idl/cap.idl

In practice, all other capabilities inherit from Cap. For example:

http://www.opencm.org/opencm/~/PUBLIC/coyotos/DEV/sys/17/idl/page.idl

In the example you used, we would specify the interface as:

        interface dir extends cap {
                cap dir_lookup(name);
                void dir_insert(name, cap);
        };

This should be read to mean that dir_lookup returns something that
implements (at least) the "cap" interface.

I should also explain that we ended up deciding in Coyotos that the EROS
void capability was a mistake. You need an "empty" capability that can
be used to fill a capability slot when you don't really want to put
something there, but the correct behavior when you invoke a revoked
capability is an exception. In Coyotos, this is the cap.InvalidCap
exception at

http://www.opencm.org/opencm/~/PUBLIC/coyotos/DEV/sys/17/idl/cap.idl#24


Aside: notice the quasi-doxygen. Our equivalent to man pages is
generated from this, as you can see here:

http://www.coyotos.org/docs/ukernel/spec.html#7

I have just noticed, however, that the generator is broken. The text is
fine, but the Coyotos site wrappers and CSS stuff are not getting
properly inserted. Sigh. At least I know when/how I broke it. :-)


shap