Capability mapping

[Norman Feske]

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

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
-------------- next part --------------
A non-text attachment was scrubbed...
Name: shm_seq.png
Type: image/png
Size: 379518 bytes
Desc: not available
URL: <http://lists.genode.org/pipermail/users/attachments/20121223/f102268f/attachment.png>