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