Capability mapping

Fri Jan 4 00:52:00 CET 2013

Hi Stefan,

Ahhh, I see. I always wondered about message registers vs. buffer 
registers in the UTCB ;-).  To close the loop do you happen to know 
where in the Fiasco.OC kernel this implicit capability mapping is performed?

Thanks for your enlightenment as always.

Daniel

On 01/03/2013 01:44 AM, Stefan Kalkowski wrote:
> 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
>>

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