On Wed, 2005-06-15 at 14:44 +0200, Espen Skoglund wrote:
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.
The fabricate operation would take two parameters:
Fabricate_Id (id, number) --- where id is the location within one's ID space and number is a number associated with that ID.
When the user does an IPC it can specify to send an ID as some form of protected payload to the destination. On the destination side, the receiver specifies an ID to use for translation purposes. During the transfer of the ID the kernel checks if the two IDs reside within the same owner space. If so, the actual transferred value is the number specified when creating the ID. If not, an "invalid" value is transferred.
Translation of an ID takes constant time. It simply involves checking whether the owner space of two IDs are the same. An extension of the translation process is to allow a small number (say 2--4) IDs be specified as translation IDs. Another extension is to have an access right that allows the ID to be used for translation purposes. Without this right the ID can only be used as a protected payload.
This sounds fairly the same like the proposed cmp() operation, the only difference is that you do it in combination with IPC, wich is only a performance argument, and however may be the right way.
The similarity is as follows: The compare operation takes two capabilites (only communication capabilites are valid). The first one is well known by the one that does the compare and must have a compare right (similar to your translation right). The second capability is the one which is unknown. If the compare right is given and the two capabilites point to the same object (in our case this would be an end point) the 'badge' which is a protected number assigned to this capability is returned by the compare and is therefore similar to your protected name. If either the compare right is not given or the capabilities are not communication caps or the point to different objects the compare will return the invalid badge.
I think, if we have a way for cheap temporary mappings of capabilities the compare is more flexible, however if we havn't we should consider doing the compare during IPC by giving a local capability to compare to in the receive and getting the compare result in the message.