[Marcus Brinkmann]
I'm not sure how this works, what is the definition of owning a capability. I think there is no such definition and because of that you need as far as I undersood in espens model provide a capability with the translation right that has the same owner space (whatever the difinition of this is, and how can one transfer ownership?)
It would make sense to me if it is the address space of the thread (or the thread itself) that created the ID object in the first place. I don't think that ownership can be transfered. I think it works similar to receive rights, which are, in Espen's model, bound to a thread, and can not be moved or copied, either. It's fixed at creation time.
Just to clarify; my choice of words when I said "owner space" could probably have been better. What I really meant was "origin space" or "space in which the root mapping for the ID resides" (let's call it "root space"). If you use the latter definition it should be clear that one can transfer "ownership" by granting the root ID to another space. This gives a bit more flexibility to the model, has some minor implementation issues, but nothing that one can't deal with.
We want no lookup because it is not only inefficent but also may return an unintended result. Because there may be more than one capability pointing to the same object in one address space (aliasing). The result of a lookup may return a capability to the object which the server itself may not have a interpretation for, because some library could have mapped an alias that the server does not know of.
Although map_lookup is not longer in the picture, let me say that it didn't have the aliasing problem, because the ancestor would be unique.
Right. Aliasing where the application can use two names to identify the same physical resource: good. Aliasing where the kernel has to choose the name to idenity a physical resource with: bad.
The model I've proposed---both regarding ID spaces and receive endpoints being fixed to specific threads---was chosen specifically because it avoids aliasing problems. This means that there are both no semantic ambiguities and that one can implement the model really efficiently.
eSk