Re: RPC user stub libraries (was: error compiling hurd after gnumach interface change)

[Neal H. Walfield]

At Mon, 19 Jul 2010 11:16:03 +0200,
Thomas Schwinge wrote:
>       * Avoid code duplication -- may have been relevant, but is it
>         still?
> 
>         Actually, if I understood correctly, in his Viengoos kernel, Neal
>         is doing all RPC stub code generation in the pre-processor, thus
>         has it as inline code at every call site.  This has one immediate
>         advantage: GCC can optimize it, as there is no function-call
>         boundary.  Should we be doing the same?  Someone should do some
>         measurements.  Neal, any off-hand comments?

That's what I did.  The obvious disadvantage of inlining code is that
you have more code.  That's bad for the CPU caches.  Of course, if you
execute an RPC, you've definately blown your L1 in the asynchronous
case and likely blown your L2 in the synchronous case.  In which case,
the cache issue is likely moot.


I used CPP to generate RPC stubs as I didn't want to write an IDL
(although you could say that I ended up doing exactly that!).  I
encountered two main problems.  The first is that error messages for
incorrectly written prototypes are hard to decipher: the IDL compiler
can't really emit error messages.  Second, marshalling variable length
arrays is a serious pain.  What you'd like are two arguments: the
array and a count, not one as you have for other types (i.e., just the
value).  Making a decision based on a type is hard to do with CPP.

Neal