Re: capability interface for idl4

[Neal H. Walfield]

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.

> 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.

> 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.

This is one of the reasons why the kernel needs to provide some form
of support for capabilities.

Thanks,
Neal