summaryrefslogtreecommitdiff
path: root/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues/libmachuser_libhurduser_rpc_stubs.mdwn')
-rw-r--r--open_issues/libmachuser_libhurduser_rpc_stubs.mdwn50
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 :-)