[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RPC user stub libraries (was: error compiling hurd after gnumach interfa
RPC user stub libraries (was: error compiling hurd after gnumach interface change)
Mon, 19 Jul 2010 11:16:03 +0200
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 <email@example.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
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
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?
Description: Digital signature