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

[Thomas Schwinge]

Hello!

On Mon, Jul 19, 2010 at 10:17:32AM +0200, Sergio Lopez wrote:
> El Sun, 18 Jul 2010 00:47:01 +0300
> Karim Allah Ahmed <karim.allah.ahmed@gmail.com> escribió:
> 
> > I've modified a little bit some RPCs of the current gnumach interface
> > ( mainly added a new argument ) , all the changes are in
> > <mach/mach.defs> ( [gnu-src]/include/mach/mach.defs ) , and I've
> > modified the pager library accordingly.
> > 
> > Now I'm compiling the pager library code to start testing the patch
> > but I keep getting "too many arguments to function
> > `memory_object_change_attributes`" while compiling the pager library.
> > ( This error also pops up in every call to the modified RPCs )
> > This means that it's still using the mach.defs (it has less arguments
> > than the new one) which is strange because I've added the new
> > mach.defs to "/usr/include/mach" and recompiled mig and installed
> > linked the generated "mig" binary to /usr/bin (I've no idea if this
> > is necessary).

No, replacing the MIG program isn't needed.

> You also need to rebuild glibc. This one provides the user interface
> to RPCs (which is pretty undesirable, but that's another matter).

So.  Yes.  Usually this isn't a big problem, as RPC interfaces are
seldomly being changed, but still, here are some quick questions, without
having done much research:

  * What's the reason for having a libmachuser / libhurduser be part of
    glibc?

    Is it for Roland's convenience, or is there a technical reason?  Can
    we move it out of the glibc build process?

  * What's the reason for having a libmachuser / libhurduser at all?

      * Run-time efficiency reasons (can't really imagine)?

      * Easier use of these functions (RPCs), as they're now part of a
        library.  But we can have the same with some basic Makefile rules
        -- which are needed nevertheless for stuff that isn't part of
        libmachuser / libhurduser.

      * 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?


Regards,
 Thomas

signature.asc
Description: Digital signature