From be4193108513f02439a211a92fd80e0651f6721b Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 30 Nov 2011 21:21:45 +0100 Subject: IRC. --- open_issues/libmachuser_libhurduser_rpc_stubs.mdwn | 50 ++++++++++++++++++++++ 1 file changed, 50 insertions(+) (limited to 'open_issues/libmachuser_libhurduser_rpc_stubs.mdwn') 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 but those using them, other than hurd itself, won't compile anymore, so you fix them progressively + + +# IRC, freenode, #hurd, 2011-11-16 + + is the mach_debug interface packaged in debian ? + what mach_debug interface? + include/include/mach_debug/mach_debug.defs in gnumach + include/mach_debug/mach_debug.defs in gnumach + what exactly is supposed to be packaged there? + i'm talking about the host_*_info client code + braunr: you mean MIG-generated stubs? + antrik: yes + i wrote a tiny slabinfo tool, and rpctrace doesn't show the + host_slab_info call + do you happen to know why ? + braunr: doesn't show it at all, or just doesn't translate? + antrik: doesn't at all, the msgids file contains what's needed to + translate + 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 + great :-) + i'll probably add a /proc/slabinfo entry some day + and considering the current state of our beloved kernel, i'm + wondering why host_*_info rpcs are considered debugging calls + imo, they should always be included by default + and part of the standard mach interface + (if the rpc is missing, an error is simply returned) + I guess that's been inherited from original Mach + so you think the stubs should be provided by libmachuser? + i'm not sure + 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... + i don't know the complete list of potential places for such calls + 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 + and i didn't want to imply they should be part of libc + on the contrary, libmachuser seems right + libmachuser is part of libc + ah + :) + why so ? + well, for one, libc needs the Mach (and Hurd) stubs itself + also, it's traditionally the role of libc to provide the call + wrappers for syscalls... so it makes some sense + sure, but why doesn't it depend on an external libmachuser instead + of embedding it ? + right + now that's a good question... no idea TBH :-) -- cgit v1.2.3