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® 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