At Wed, 15 Jun 2005 14:44:07 +0200, Espen Skoglund wrote:
Since I'm linf of involved with these sort of questions myself it seems like the right thing for me to share my thoughts on the subject.
Thanks for jumping in here, it's very helpful.
I agree that having an operation that can identify one's own virtual address of a mapping can be pretty neat. Many people on this list have however pointed out the nasty aspects of it. The killer nastiness here (IMO) is that you may potentially need to traverse the mapping tree all the way up to the root. This means that no matter how clever a locking scheme you use for the mapping database, you may always need to somehow lock the root nodes in the tree.
I realize that the operation I suggested is not actually one that is particularly desirable from its implementation properties. I used the map_lookup operation to describe very precisely the narrow semantics I need in implementing the type of systems I want to implement.
I am very happy to hear that you have already considered such an operation. The performance effects you enumerate sound convincing.
Another problem with cmp() is that as far as I understand it doesn't do what Marcus asks for. That is, it does not identify a particular vaddr within the address space.
This is true, but I should add that I am not really asking for the vaddr, but for the bigger picture of identifying objects. I hope I made this sufficiently clear (in retrospect, I could have made it clearer).
Now, just for the sake of confusing people even more, let me throw in another idea I've been playing around with. My take on the problem of application specific capability transfer is to introduce another type of address space; an ID space. One can fabricate new IDs within one's ID space and also map/grant/unmap such IDs between ID spaces.
Thank you for the detailed description of how ID spaces are designed. I knew you had something like this in mind, but what I was missing was the detail that you can map the ID object, but also the right to use it for translation purposed. With this missing piece in the puzzle, I am convinced that ID spaces can work for me.
I realize that these IDs do not directly solve the problems you are posing. That is, it doesn't allow you to verify that, e.g., a memory mapping you receive really is what you expect it to be. You can do certain tricks here though. For example, a server can create an ID associated with every memory mapping it hands out (i.e., it maps the ID together with the page frame). Someone down in the mapping hierarchy can then use this ID to prove to the server that it has a capability to the page frame. This would for example solve the reference counting problem you posed.
Yes, indeed. I would actually do it the following way: The reference counter would become the global object server. It would create all the ID objects for all objects in the system, on behalf of the servers providing the objects. It would map the right to do the translation to the server providing the object. The server can then identify the objects in incoming RPCs without any additional RPCs to the global object server. The reference counter can naturally identify all capabilities, as it is the principal provider of the corresponding ID objects.
This would work very well. It would have slightly different properties than a purely local model, but no differences that matter to us.
It would require to separate communication channels from objects, but this actually is a benefit, because more optimizations are possible.
I think that such ID objects would be, all things considered, a much better solution than any type of map_lookup() or cmp() function. It does, however, require a new type of kernel objects. What do the Dresden people think about new kernel objects like this?
Thanks, Marcus