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

[Peter Nguyen]

>> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main