d.waddington at ...60...
Wed Jan 2 20:58:57 CET 2013
Hi Norman, a few more follow up questions in line..
On 12/23/2012 11:04 AM, Norman Feske wrote:
> 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.
But "under the hood" does the Genode core perform the l4 map system
call? If so can you point me to the code in core? I want to understand
how Genode interacts with the Fiasco.OC kernel.
>> 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).
So the capability identifier in the RPC payload does not have any
special marshalling/unmarshalling it's just a value?
In your example is 'delegate' just some arbitrary interface method?
> 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
>> and l4re_ns_query_to_srv
> 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
I am trying to get my head around the Genode capability model which
seems quite different from the L4Re capability model. I think the
essence of the Genode solution is to hide the mapping between Genode
caps and OS-specific caps in Genode's core, and have this core process
perform the mapping w.r.t. calling the kernel.
Apologies if I am totally missing the point.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users