Merge remote-tracking branch 'fp/master'

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 :-)