Capability mapping

Thu Jan 3 10:44:41 CET 2013

Hi Daniel,

On 01/02/2013 08:58 PM, Daniel Waddington wrote:
> 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.
> 

Core isn't involved in general to transfer a capability from one side to
the other. As you probably know: we use C++ streaming operators to put
arguments into IPC message buffers, or get them out of it. When using
Fiasco.OC, the streaming operators of 'Capability' objects are
overloaded. Have a look at:

  base-foc/include/base/ipc.h

The 'local_name()' of the capability is transferred as a regular value.
But the index in the capability name space of the corresponding task is
added explicitly to the message buffer as a special value. When
preparing the IPC syscall, we setup flex-pages for each capability that
has to be transferred. These flex-pages are part of the UTCB, and get
analyzed by the kernel after the IPC syscall was done. Look at:

  base-foc/src/base/ipc/ipc.cc

To sum it up, we do not use a 'l4_task_map' syscall to transfer
capabilities when they are exchanged via explicit messages.

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

I hope this is clarified via the explanations above?

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

As already said: in general, the delegation of capabilities between
processes is done without the help of core. We simply use the kernel's
IPC mechanism for that. Nevertheless, there are some capabilities in a
process that are managed by core. These capabilities are somehow
special, e.g. the pager capability of a thread, or its task capability.
These capabilities are needed by a new born thread in order to be able
to do at least IPC calls to other ones. That's why these capabilities
are transferred by core via the 'l4_task_map' syscall just before a new
thread gets executed.

I hope this helps to clarify your questions. Happy new year ;-)
Stefan

> 
> Daniel
> 
> 
> 
> ------------------------------------------------------------------------------
> Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
> and much more. Keep your Java skills current with LearnJavaNow -
> 200+ hours of step-by-step video tutorials by Java experts.
> SALE $49.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122612 
> 
> 
> 
> _______________________________________________
> Genode-main mailing list
> Genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
> 

-- 
Stefan Kalkowski
Genode Labs

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