Thank you Norman,
it is really more than sufficient answer.
since i am still new with Geonde it may early to give an advise, regarding to the book ,it is an amazing effort ( i went through few parts of it since yesterday), but do you think that it will be better to include some more code examples. what i mean is making the book as reference to "how to develop in Genode".
thank you again for your answering.
best.
> Subject: Re: RPC parameters
> To: genode-main@lists.sourceforge.net
> From: norman.feske@...1...
> Date: Thu, 14 Jan 2016 12:09:30 +0100
>
> Hello,
>
> On 14.01.2016 11:52, Bilal ma wrote:
> > Thank you for the examples, does it make difference if i don't pass my
> > input-output POD struct by reference since it need to be copied to the
> > server side, and later from the server to the client.
> > from the point view of performance which one is the best if we add the
> > option of placing my POD in shared memory.
>
> the RPC mechanism always copies data. It does not use shared memory.
> Please review Section 8.12.2. "Transferable argument types" to get a
> picture how different argument types are handled.
>
> If a reference is passed as argument, the following steps are taken:
>
> 1. The argument is copied into the message to be sent to the server.
>
> 2. The server instantiates a temporary object of the argument type
> and copies the argument from the message to the temporary object.
>
> 3. The server-side RPC method is called with a reference to the
> temporary object as argument.
>
> 4. Once the server-side RPC method returns, the new content of the
> temporary object is copied to the reply message buffer.
>
> By using the temporary object instance, it looks like you pass a
> reference. But under the hood, the server operates on a different object.
>
> You mentioned performance. If you need to transfer large amounts of bulk
> data between components, you may consider shared memory. For a
> description of how to set up shared memory between components, please
> refer to Section 3.6.3. "Shared memory" in [1].
>
> That said, I recommend you to think twice about introducing a new
> session interface. Maybe an existing interface would do the job just
> fine when looking at your problem from a slightly different angle? To
> cite the intro of Chapter 4:
>
> "The versatility of a component-based system does not come from
> the existence of many components alone. Even more important is
> the composability of components. Components can be combined only
> if their interfaces match. To maximize composability, the number
> of interfaces throughout the system should be as low as possible,
> and all interfaces should be largely orthogonal to each other."
>
> Whereas it is a nice exercise to design a custom RPC interface, I mostly
> advise against it. In particular, if your interface is just a bunch of
> getters and setters, the existing ROM and Report session interfaces may
> accommodate you quite well.
>
> [1] http://genode.org/documentation/genode-foundations-15-05.pdf
>
> Cheers
> Norman
>
> --
> Dr.-Ing. Norman Feske
> 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
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> genode-main mailing list
> genode-main@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main