Yet another question. Associated with "Re: Shared library"

Norman Feske norman.feske at ...1...
Thu Mar 4 14:41:03 CET 2010


Hi Peter,

> I just realized that making the library a shared object won't 
> necessarily fix my problem. What i'm trying to do is have two genode 
> components share data with each other, where this data is in user space. 
> I do this with a buffer that i create in the kernel, where I obtain the 
> physical address of the buffer, and map that to user space. The mapping 
> is established via the use of Io_mem_connection, as was suggested to me 
> previously.

The I/O-memory approach would not work for establishing shared memory
between two processes because core hands out each I/O-memory region only
once.

> Is there a way of sharing data between two components where the data is 
> wholly created in user space? I'm not sure whether there is any 
> functionality in genode that will allow me to obtain the physical 
> address of a variable or class instance, for example. Otherwise, i could 
> just use Io_mem_connection along with said functionality to establish 
> the mapping.

It is possibility to share memory between processes by the means of
dataspaces. The previously mentioned I/O-memory approach is just a
special case of this concept. A dataspace is a container for memory. It
can be created using core's RAM service (or other core services). When
creating a new dataspace, the creator gets a dataspace capability. Using
this capability, the creator can attach the dataspace into its local
address space (using 'env()->rm_session()->attach'). Furthermore, a
dataspace capability can be transferred to another process via IPC. For
an example, please have a look at the source code of one of the
framebuffer drivers, which allows the client to obtain the dataspace for
the frame buffer using an RPC call. Once the client has received a
dataspace capability, it can attach the dataspace to its local address
space as well.

To get this to work for your use case, you must decide, which of your
components acts as client and which acts as server. The component
allocating the dataspace is normally the server. Then the general
protocol works as follows:

* Server announces its service
* Server creates dataspace, gets dataspace capability, and attaches
  dataspace to its local address space
* Client requests session to server
* Server gets session-creation request, returns session capability
* Client gets session capability as return value of the session call
* Client requests dataspace capability via RPC call via the session
  capability
* Server receives RPC call and returns dataspace capability
* Client attaches dataspace to its local address space

If you are not able to decide which of your components should be the
client and the server, you might need a third process acting as server,
handing out the dataspace to each client. But I suppose that you might
be able to model your use-case as a client-server scenario.

Regards
Norman





More information about the users mailing list