diff options
Diffstat (limited to 'open_issues/libmachuser_libhurduser_rpc_stubs.mdwn')
| -rw-r--r-- | open_issues/libmachuser_libhurduser_rpc_stubs.mdwn | 50 |
1 files changed, 50 insertions, 0 deletions
diff --git a/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn index 93055b77..80fc9fcd 100644 --- a/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn +++ b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn @@ -54,3 +54,53 @@ License|/fdl]]."]]"""]] compatibility with eventual 3rd party users is not broken <pinotree> but those using them, other than hurd itself, won't compile anymore, so you fix them progressively + + +# IRC, freenode, #hurd, 2011-11-16 + + <braunr> is the mach_debug interface packaged in debian ? + <antrik> what mach_debug interface? + <braunr> include/include/mach_debug/mach_debug.defs in gnumach + <braunr> include/mach_debug/mach_debug.defs in gnumach + <antrik> what exactly is supposed to be packaged there? + <braunr> i'm talking about the host_*_info client code + <antrik> braunr: you mean MIG-generated stubs? + <braunr> antrik: yes + <braunr> i wrote a tiny slabinfo tool, and rpctrace doesn't show the + host_slab_info call + <braunr> do you happen to know why ? + <antrik> braunr: doesn't show it at all, or just doesn't translate? + <braunr> antrik: doesn't at all, the msgids file contains what's needed to + translate + <braunr> btw, i was able to build the libc0.3 packages with a kernel using + the slab allocator today, while monitoring it with the aforementioned + slabinfo tool, everything went smoothly + <antrik> great :-) + <braunr> i'll probably add a /proc/slabinfo entry some day + <braunr> and considering the current state of our beloved kernel, i'm + wondering why host_*_info rpcs are considered debugging calls + <braunr> imo, they should always be included by default + <braunr> and part of the standard mach interface + <braunr> (if the rpc is missing, an error is simply returned) + <antrik> I guess that's been inherited from original Mach + <antrik> so you think the stubs should be provided by libmachuser? + <braunr> i'm not sure + <antrik> actually, it's a bit arguable. if interfaces are not needed by + libc itself, it isn't really necessary to build them as part of the libc + build... + <braunr> i don't know the complete list of potential places for such calls + <antrik> OTOH, as any updates will happen in sync with other Mach updates, + it makes sense to keep them in one place, to reduce transition pain + <braunr> and i didn't want to imply they should be part of libc + <braunr> on the contrary, libmachuser seems right + <antrik> libmachuser is part of libc + <braunr> ah + <braunr> :) + <braunr> why so ? + <antrik> well, for one, libc needs the Mach (and Hurd) stubs itself + <antrik> also, it's traditionally the role of libc to provide the call + wrappers for syscalls... so it makes some sense + <braunr> sure, but why doesn't it depend on an external libmachuser instead + of embedding it ? + <braunr> right + <antrik> now that's a good question... no idea TBH :-) |