Hi Peter,

please ensure that you added the dynamic linker binary (called "ldso") to your weaver file (e.g., <memsection name="ldso" file="ldso" direct="true" />). Nothing else should be necessary since the linker is loaded by Genode if a dynamic binary is found.

Greetings, Sebastian

On 03/03/10 05:32, Peter Nguyen wrote:

Hi,

I've tried to create a shared library for use by multiple components in Genode, where in the mk file for the library, i have specified SHARED_LIB=yes. When i try to execute Genode, I keep getting the following message at runtime:

"Dynamically linked file found, but no dynamic linker binary present"

What steps do i need to take so as to ensure that the binary is present?

Peter

---

Download Intel&#174; 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

Hi Peter,

[init -> lwip_httpsrv_test] Starting ldso ... [init -> lwip_httpsrv_test] void* fwrite(): fwrite - not yet implemented [init -> lwip_httpsrv_test] void* fputs(const char*, void*): fputs: "Genode::Rm_session::Region_conflict" [init -> lwip_httpsrv_test] void* fwrite(): fwrite - not yet implemented [init -> lwip_httpsrv_test] void* abort(): abort called

Why is this occurring? The "region_conflict" would obviously give some sort of indication.

This is a problem with the default link address used for ldso. It conflicts with the address of the dynamic binary to load. We have updated the handling of the default text address for OKL4 in the subversion repository. Could you give it a try again?

Norman

Hi,

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.

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.

Thanks Peter

Norman Feske wrote:

Hi Peter,

...

[init -> lwip_httpsrv_test] Starting ldso ... [init -> lwip_httpsrv_test] void* fwrite(): fwrite - not yet implemented [init -> lwip_httpsrv_test] void* fputs(const char*, void*): fputs: "Genode::Rm_session::Region_conflict" [init -> lwip_httpsrv_test] void* fwrite(): fwrite - not yet implemented [init -> lwip_httpsrv_test] void* abort(): abort called

Why is this occurring? The "region_conflict" would obviously give some sort of indication.

This is a problem with the default link address used for ldso. It conflicts with the address of the dynamic binary to load. We have updated the handling of the default text address for OKL4 in the subversion repository. Could you give it a try again?

Norman

---

Download Intel&#174; 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

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

Hi,

I have the feeling you're mixing two distinct matters here. The issue Norman addressed in his email was "How to share memory buffers between applications". That is done via dataspaces that are referenced by dataspace capabilities (in Unix file descriptors) and could be attached to any virtual address space via region management (in Unix mmap()).

Well, I was wondering about how to share data between components, where the data may be specified within a library eg. having a variable in a library that should be shared between all components using this library.

What do you want to say with this statement? Do you want the data to be shared? Do you want to prevent sharing of the data (which is perfectly achieved with shared libraries that only share the read-only segements http://en.wikipedia.org/wiki/Library_%28computing%29#Shared_libraries)?

I do want the data to be shared between genode apps that utilize the library. In other words, i'd like there to essentially be a single copy of the variable that is used by these apps/components (like static variables in Java).

I propose to implement the "network sampling thread" in a profiling "server" that announces its "service" and provides "sessions" to its "clients" (e.g., the HTTP server). On startup, the client requests a "session" to "profiling" from its parent. Thereafter, it requests the dataspace capability via the "profiling session" interface and attaches the dataspace locally. The resulting virtual start address can be used to initilialize your sampling "library".

This makes sense. In reference to my responses above, I'm thinking there would be a profiling session interface that defines the memory that can be shared, have the server write data to this memory, and the clients can declare a dataspace capability (via attaching the dataspace as you mentioned) to this memory so as to read the contents of this memory. Am I on the right track?

Peter

Hi,

Sounds good, though I expected the clients to write sampling data into the memory that is processed by the profiling server. More precisely, the server allocates the shared dataspace from its RAM session and provides the associated RAM-dataspace capability to its clients. Both

• client and server - attach the dataspace to their virtual memory

and, thereafter, share access to the same RAM pages.

So I've had a go at trying to implement a simpler case of having shared memory between two processes via adding code to the hello tutorial. I have done the following things:

- I added a dataspace capability variable in the session server (which contains the dispatch function) called net_buffer, and in the constructor, I allocate 4 bytes to the dataspace like so:

net_buffer = Genode::env()->ram_session()->alloc(4);

- In the session class, I added an extra virtual function declaration (get_cap()) to return the net_buffer variable.

- In the session client, I have an implementation of the get_cap function. In this function, I pass an opcode relating to returning the dataspace capability.

- In the component header, I have an implementation of get_cap() where i return net_buffer.

- The server source code is currently unchanged.

- I added code to the client source code to obtain the dataspace capability like so:

Dataspace_capability ds_cap = h.get_cap(); void *ptr = Genode::env()->rm_session()->attach(ds_cap);

And at the moment, I am able to write to ptr eg. an integer, and the value prints fine, for instance. In reference to what was said previously ie.

"Both - client and server - attach the dataspace to their virtual memory and, thereafter, share access to the same RAM pages."

How is the server meant to obtain the dataspace capability? Also, I'm assuming what I've done above is correct in terms of having shared memory between the server and client. So if i've done something, I would love to know what I need to do to fix it.

Thanks Peter

...

So I've had a go at trying to implement a simpler case of having shared memory between two processes via adding code to the hello tutorial. I have done the following things:

• I added a dataspace capability variable in the session server

(which contains the dispatch function) called net_buffer, and in the constructor, I allocate 4 bytes to the dataspace like so:

net_buffer = Genode::env()->ram_session()->alloc(4);

Pretty similar to what I had in mind, just some notes:

• The RAM-session allocation granularity is page size, i.e. 4096

bytes. So, your allocation of 4 bytes will be rounded up to 4096.

• We prefer to implement server-specific implementation parts in a

sub class of the server. This keeps the public headers clean. So, I suggest to move your code into Hello::Session_component.

...

• In the session class, I added an extra virtual function declaration

(get_cap()) to return the net_buffer variable.

• In the session client, I have an implementation of the get_cap

function. In this function, I pass an opcode relating to returning the dataspace capability.

• In the component header, I have an implementation of get_cap()

where i return net_buffer.

Fine.

...

• The server source code is currently unchanged.

What i meant by this is that I didn't add any code to server.cc.

Didn't you adapt the dispatch method for get_cap() by adding a new case?

...

• I added code to the client source code to obtain the dataspace

capability like so:

Dataspace_capability ds_cap = h.get_cap(); void *ptr = Genode::env()->rm_session()->attach(ds_cap);

And at the moment, I am able to write to ptr eg. an integer, and the value prints fine, for instance. In reference to what was said previously ie.

What do you mean by "the value prints fine"?

What i meant by this is that in the client code, I obtain the dataspace capability, write to that memory, and print the contents of that memory. After this, I create other variables to store the dataspace capability, and it refers to the same memory. However, I was under the impression that this memory could be shared by other components other than the client code. For instance, adding a connection to the server from the HTTP server code (for instance) seems to result in a different dataspace capability as printing the contents (casting the memory to an int) results in the value being 0. Maybe moving the code into the Session_component would probably fix this problem.

...

"Both - client and server - attach the dataspace to their virtual memory and, thereafter, share access to the same RAM pages."

How is the server meant to obtain the dataspace capability?

From what you wrote before I expected both components - Hello::Session_client and Hello::Session_component - to have obtained the dataspace capability. The server-side component allocated a RAM region and passed the capability to the client on call of get_cap().

...

Also, I'm assuming what I've done above is correct in terms of having shared memory between the server and client. So if i've done something, I would love to know what I need to do to fix it.

So... it does not work? The only point I see is: Add a new case to dispatch for get_cap() using your enum (e.g., GET_CAP) and call the get_cap() method in the Session_component like the following

os << get_cap();

I'm encouraged that i've done most things correctly though. Thank you very much for your help.

HTH

Christian Helmuth Genode Labs

http://www.genode-labs.com/ · http://genode.org/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

---

Download Intel&#174; 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main

Christian,

Sorry, I probably should have sent the source code to begin with. Attached are two zip files: sampling.tar.gz (which contains the server source code I have, the build.conf file, the config file for building as well as the weaver file i use), and sampling_session.tar.gz, which should be placed in $(GENODE_DIR)/os/include. The sampling folder in sampling.tar.gz should be placed in the base genode directory ie. Whatever value GENODE_DIR takes.

I am currently using version 9.11 of genode, and using the okl4 "version".

Just to reiterate, I was under the impression that memory could be shared between two separate components ie. not just in the client code. I recall you mentioned that both the server and client should obtain the capability and attach it so as to write to the same memory. So i tried creating client connection in server.cc after announcing the service, but the dataspace seems to be different in that after the announcement code in the server main.cc is done, i create a client connection then. The capability that the server main.cc and client main.cc has do not seem to point the same memory locations.

Thanks Peter

Quoting Christian Helmuth <christian.helmuth@...1...>:

Hello Peter,

On Thu, Mar 11, 2010 at 07:21:28PM +1030, Peter Nguyen wrote:

...

What i meant by this is that in the client code, I obtain the dataspace capability, write to that memory, and print the contents of that memory. After this, I create other variables to store the dataspace capability, and it refers to the same memory. However, I was under the impression that this memory could be shared by other components other than the client code. For instance, adding a connection to the server from the HTTP server code (for instance) seems to result in a different dataspace capability as printing the contents (casting the memory to an int) results in the value being 0. Maybe moving the code into the Session_component would probably fix this problem.

IMO it's time for me to stop guessing what your code may look like or you may try to say. Please post compilable source code and/or logs if you want further support from my side.

Ciao

Christian Helmuth Genode Labs

http://www.genode-labs.com/ · http://genode.org/

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth

---

Download Intel&#174; 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main