>> 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/genode-main ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/genode-main
