Re: capability interface for idl4

[Jonathan S. Shapiro]

I think that we should not be asking how to adapt MIG. The design of the
IDL compiler is very closely attached to the design of the underlying
microkernel, and IDL designs have improved since MIDL. It seems to me
that the right thing to do is to build a translator that will convert
the mig files forward, or simply modify them by hand.

On Tue, 2005-10-04 at 22:15 +0100, Neal H. Walfield wrote:
> At Tue, 04 Oct 2005 21:54:50 +0200,
> ness wrote:
> > 
> > To get the abstraction we need, there has to be an capability interface 
> > in idl4. This means, we can say idl4 "here is the cap, give it to xyz", 
> > and idl4 generates the stub. But I'm a little confused about what ways 
> > of sending caps we have and what is needed in idl4. I found the 
> > following ways of sending a capability:
> 
> Jonathan suggested something along the lines of:
> 
>   method int foo (cap interface io a, int x)
> 
> Which means that foo is a method which takes: a capability which
> implements the io interface; and an integer x.  Note that this is
> more strongly typed than, for instance, mig which cannot be taught
> that only a port right which implements a particular interface should
> be accepted.

Neil could mean two things in his example above, so let me try to make
this concrete. In CapIDL we would write:

        // somwhere:
        package mypackage;
        interface IO extends cap raises(IoErr) {
                int foo(int x);
                // methods for IO
        };

        package AnotherPackage;
        interface Another extends cap {
                void sendIoCap(mypackage.IO ioCap);
        };

The IDL compiler expands foo to the C signature:

        result_t mypackage_IO_foo(cap_t _cap, int x,
                /* OUT */ int *_retval);

where result_t==0 if OK, non-zero if an exceptional outcome is being
returned. The /cap_t/ is defined in an IDL header. It is the type of
capability indexes.

The IDL compiler would similarly expand sendIoCap to the following C
signature:

        result_t AnotherPackage_Another_sendIoCap(
                cap_t _cap,
                cap_t ioCap);

I do not remember at the moment whether we generated specific typedefs
for specific capability types. If we did not, then I'm sure the IDL
compiler emits a comment indicating the intended type.

Oh. We do DoxyGen too.

> > 1. simple handle passing
> >     We simply pass the handle for authentication. This means, the
> >     server we pass the handle provides the cap.
> > 
> > 2. capability copying
> >     The process a has a handle to a cap provided by s and wants to
> >     give the process b the right to use this cap. This is done via
> >     the cap server.
> > 
> > 3. sth. mysterious I called capability object passing
> >     The client calls a server and gets as result a newly created
> >     handle to a cap. Can e.g. be found in hurd_pm_container_create
> >     (better to see with the patches by racin).
> > 
> > Looks nice, but is this right this way?
> 
> As far as the client should be concerned, a capability is a capability
> independent of who actually implements it.  Thus drawing this
> distinction should only be a function of the implementation.

Yes. The logical operation is that a capability is being transferred.
This can be made arbitrarily and foolishly complex by introducing a
capability server, but that does not alter the intent or the semantics
of capability copy.

> > And, do we need the second one 
> > to be provided by idl4? I say, usually the server will not trust its 
> > client and this it's useless, as the server will not use the new handle.

You are making an incorrect assumption. In general, what you say is
true, but if the server can authenticate the validity of a capability,
there is no reason not to use it.

I shall write more on this in a moment, but it probably deserves a
different subject line to keep the threads of discussion better
organized.

shap