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.ah...@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
