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

[Peter Nguyen]

Norman,

This makes sense. However, on my end, i think i'm going to have to do 
quite a bit of reconfiguring. I'm trying to integrate my profiling 
environment with the http server that is part of lwip. I've added code 
to the http server to collect samples whenever a request is received, 
and when the network sampling buffer is full, have the profiling 
environment read the buffer contents, and perform the relevant 
processing. The "bridge" between the server and the profiling 
environment _should_ be a library that i created. However, the data in 
the library isn't shared between the two components.

In order for me to share the buffer data with the profiling environment, 
I'm thinking that I would need to know the ID of the network sampling 
handler thread (that commences the reading of samples from the buffer) 
ahead of time, and supply the address of the dataspace to the network 
sampling thread. Just to clarify, I have written my profiling 
environment as a genode app ie. like the example "hello_tutorial" app 
(my sampling code is situated in genode-9.11/sampling, while the HTTP 
server is located in the libports directory as usual ie. 
genode/libports/....

Infact, i'm thinking the easiest way to get around my issue is probably 
having to integrate the sampling functionality into the HTTP server eg. 
having my source code in the same directory as the HTTP server. This 
isn't really an ideal situation, and i'd like to avoid this if possible. 
But if this is the only way, then I really have no choice obviously.

Norman Feske wrote:
> 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
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Genode-main mailing list
> Genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>