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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
