Genode RPC: Handling vector parameters

[Norman Feske]

Hello,

welcome to the list. :-)

> Okay. Now I changed my rpc params to transferable types.
> I am using Rpc_in_buffer<> instead of std::string.
> I want to receive a feedback message from a server through an Rpc_in_buffer<> argument,
> but the client doesn't receive the results from the server correctly while working correclty with an character array.
> 
> I should not use Rpc_in_buffer for a reply message from a server?

That is right. 'Rpc_in_buffer' is specifically meant as an input
parameter, hence the name. Let me give you a bit of the rationale behind
this class template: The most basic way of passing strings as RPC
function arguments is by using a compound object that contains a
character array. For example:

  struct File_name { char buffer[64]; };

This compound struct works for both directions as RPC argument or as RPC
return value. However, this approach has two slight problems. First, it
is a bit clumsy to use. It would be much nicer to pass a string directly
to the RPC function at the client side. And second, the whole buffer is
transferred regardless of the actual string length. Because 'buffer[64]'
is just a bunch of bytes, this is the only sensible thing to do. Because
most kernels support variable-sized messages, it would be nice to
transfer only the elements of the buffer that carry any meaningful
information to speed things up a bit. This is where 'Rpc_in_buffer'
comes into play. It is a class template for the basic idea outlined
above. Thanks to its implicit constructor that takes a null-terminated
string as argument, it is quite convenient to use. And because
'Rpc_in_buffer' is specially handled in 'ipc_generic.h', only the actual
payload is stuffed into the RPC message.

In the other direction (which you asked about) there is no such
convenience function yet. This is simply because, until now, there was
no need for it. In the framework, there is currently no single place (at
least that I am aware of) where a string is returned. If we observe that
this use case becomes frequent, we might add an 'Rpc_out_buffer' type.
Until then, I suggest to use a compound type as mentioned above.

Regarding the general problem of communicating complex types from one
process to another, Christian already mentioned the packet-stream
facility. However, I would like to point out another approach that is
somewhere in the middle: Using a dataspace shared between client and
server as buffer for complex arguments combined with synchronous RPC for
invoking the actual RPC function. You can find a brief explanation and
pointers to code examples in the following posting:


http://sourceforge.net/mailarchive/forum.php?thread_name=op.v56pvpky50x9fi%40domopc&forum_name=genode-main

Best regards
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