Re: Hurd IPC (client side)

[Ludovic Courtès]

On Sun, Nov 03, 2002 at 05:19:45PM -0500, Neal H. Walfield wrote:
> If you do have bad macros, then yes.  But we can always do:

Whatever the macro is, the following wouldn't work:

  error_t (* f) (user_handle_t, uid_t, gid_t);
  f = file_chown;

Right? ;)

> > Having a library in between the client code and the actual RPCs could avoid
> > that.  What do you think would be the best way to unify client code for the
> > various Hurd implementations?
> 
> But, what does it buy us other than overhead of remarshaling the
> parameters?

Uniformity and ukernel-independence.  And overhead, but not so much. ;)

> This is the type of magic that we will use on the server side when
> doing the mutations (I have not written the client side stuff):

> /* Generate an rpc stub.  FUNCTION is the rpc name; ARGTYPES the
>    parameter list as returned from RPC_TYPES(); and args the argument
>    list as returned from RPC_ARGS().  Makes the following assumptions:
>    the rpc returns an error_t and the first argument is a
>    user_handle_id_t on the wire and a struct server_handle_info * in
>    the stub.  */
> #define RPC_GEN(function, argtypes, args) _RPC_GEN(function, argtypes, args)

The comment says "RPC_TYPES()" where it should be "RPC_PARAMETERS()" I think.

Ok.  But with these macros, the above example does not work then (but is it
really a problem?).

BTW, what does "frob" mean?

Thanks,
Ludovic.