Hi Daniel,
I'd like to better understand the capability mapping support in Genode.
Is there a generalized mechanism (beyond RPC endpoint mapping) for a parent to map capabilities (e.g., Dataspace) between two child processes?
capabilities are not limited to session interfaces but can refer to any kind of object. For example, each dataspaces allocated from a RAM session is referenced by a capability, or each PCI device returned by the PCI session interface is represented as a capability, or a nitpicker view created via a nitpicker session is one. These capabilities can be delegated via arbitrary RPC calls. The parent does not play a special role here.
Can a process (e.g., client) map a capability into another capability? I am wondering how the packet_stream interface establishes shared memory e.g., for channels.
Would you mind me throwing another sequence diagram in your direction? ;-) The attached diagram illustrates the way shared memory gets established in Genode.
First, the server allocates a dataspace from core's RAM service (or another provider of dataspaces). At allocation time, the dataspace's backing store gets reserved in core. The server receives a dataspace capability in return of the alloc-RPC-call. This capability can then be used to make the dataspace visible in the server's address space using core's RM service. As the second step, the server delegates the dataspace capability to the client as RPC payload (usually as a return value of a RPC function). After the delegation, both server and client have a capability referring to the same physical dataspace. Now, the client is able to also use core's RM session to make the same dataspace visible in its local address space. But only the server is able to destroy it (because it has both the dataspace capability and the RAM session capability that was used to allocate the dataspace)
This procedure is performed by all users of the packet-stream interface, for example the 'Nic::Session' interface. There are two possible uses of the packet stream interface, which are the transmission of bulk data to the server (represented by the packet_stream_tx RPC interface) and the reception of bulk data from the server (represented by the packet_stream_rx RPC interface). The 'Nic::Session' is bi-directional. Hence, it aggregates two instances of the packet-stream interface.
I guess I am looking for something equivalent to L4Re l4re_ns_query_to_srv http://os.inf.tu-dresden.de/L4Re/doc/group__api__l4re__c__ns.html#ga5069ab93cc8a3611dd208a8af83940b0 and l4re_ns_query_to_srv http://os.inf.tu-dresden.de/L4Re/doc/group__api__l4re__c__ns.html#ga5069ab93cc8a3611dd208a8af83940b0 APIs.
There is currently no generic way to publish capabilities at a central registry and looking them up. Thanks to Genode's session mechanism, we haven't had the need for such a feature yet. Generally speaking, such a feature could be implemented as a service providing the registering and lookup functionalities via a session interface. Parents could then instantiate as many instances of this service as desired whereas each instance would represent a separate namespace.
Could you please briefly explain your intention behind this inquiry? Maybe there is an solution to your problem that does not need a new interface?
Best regards Norman
