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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main