Re: capability interface for idl4

[Jonathan S. Shapiro]

On Sat, 2005-10-08 at 14:09 +0200, Matthieu Lemerre wrote:
> What I would like here would be to have the IDL generate the code
> depending on the implementation of the microkernel we choose, but with
> keeping the same interfaces.

Yes. That would be a very nice thing to have. Unfortunately, I think
that you will only achieve this on paper. The problem is that
implementing correct capability semantics on top of map/grant/unmap will
prove to be prohibitively expensive.

Setting this aside, I think we should evaluate moving Hurd to CapIDL.
CapIDL is a general capability-based IDL -- it was not intended to be
specific to EROS/Coyotos -- and it has some features that you will come
to want. It should not be any difficulty to add back ends for other
target operating systems.

> BTW, by capability handle I mean the local number which is assocatied
> with the capability.

Ah. Thank you. The term "handle" is used too many ways, and I had
assumed something else.

> But what if the endpoint is a local mappable object?  AFAIK, in L4ng
> you specify the number by which the endpoint will be accessible when
> this endpoint is mapped to you.  If this is done for each capability
> (provided that you can map the same endpoint to different numbers, and
> you don't have a way to tell if 2 endpoints have the same receive
> end), what is the problem of this approach?

There is no problem with this approach. I think that my assumptions
about the term "handle" confused me.

> What I name authentification token is in fact some sorts of
> capabilities that you cannot copy, just map/unmap/grant.

That is what concerns me. It suggests that you have not considered the
problem carefully enough yet. I apologize for being vague. I will expand
on this in a few hours.

> It is something which could be implemented on L4ka's L4ng by capIDs
> (as described by Espen Skoglund in
> http://os.inf.tu-dresden.de/pipermail/l4-hackers/2005/002190.html).
> 
> If I understand correctly, in EROS capabilities can be "only" copied,
> whereas in L4 they can't, they can only be mapped/granted/unmap.

Yes. The L4sec semantics is broken. It is not a feature. It is a bug. I
understand that this statement requires justification -- more later.

> Copying could be simulated in L4 by using a trusted capability server
> which would map the capabilities.

Yes. However, the practical performance of this would be awful. Many
years ago Jochen and I discussed moving EROS onto L4 using this
approach. We agreed that it would not deliver adequate performance to
support the type of system design that EROS is intended to support.
First class kernel support for capabilities is required, and map/unmap
is *not* an appropriate primitive for this part of the system.

>   Marcus told me that you could
> emulate mapping by "wrapping" a capability in EROS, although I haven't
> read how this works yet.

I will describe later.

> I think that unmaping an object is a less
> costly operation than revoking the capability and re-creating a new
> one.

It turns out that this is not true -- revoking a capability is just as
efficient. It is sometimes more efficient and sometimes less, depending
on how the capability has been transferred.


shap