Capability mapping

[Daniel Waddington]

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
>> 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?
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.

Daniel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20130102/c73deac0/attachment.html>