[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hurd IPC (client side)

From: Ludovic Courtès
Subject: Re: Hurd IPC (client side)
Date: Mon, 4 Nov 2002 00:03:57 +0100
User-agent: Mutt/1.4i

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]