path: root/service_solahart_jakarta_selatan__082122541663/libmachuser_libhurduser_rpc_stubs.mdwn
diff options
Diffstat (limited to 'service_solahart_jakarta_selatan__082122541663/libmachuser_libhurduser_rpc_stubs.mdwn')
1 files changed, 177 insertions, 0 deletions
diff --git a/service_solahart_jakarta_selatan__082122541663/libmachuser_libhurduser_rpc_stubs.mdwn b/service_solahart_jakarta_selatan__082122541663/libmachuser_libhurduser_rpc_stubs.mdwn
new file mode 100644
index 00000000..b571b82e
--- /dev/null
+++ b/service_solahart_jakarta_selatan__082122541663/libmachuser_libhurduser_rpc_stubs.mdwn
@@ -0,0 +1,177 @@
+[[!meta copyright="Copyright © 2010, 2011, 2012, 2013, 2014 Free Software
+Foundation, Inc."]]
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
+is included in the section entitled [[GNU Free Documentation
+[[!tag open_issue_glibc open_issue_hurd]]
+# bug-hurd discussion.
+# IRC, freenode, #hurd, 2010-08-12
+ <jkoenig> Looking at hurd.git, shouldn't {hurd,include}/Makefile's "all"
+ target do something, and shouldn't pretty much everything depend on them?
+ As it stands it seems that the system headers are used and the
+ potentially newer ones never get built, except maybe on "install" (which
+ is seemingly never called from the top-level Makefile)
+ <jkoenig> I would fix it, but something tells me that maybe it's a feature
+ :-)
+ <antrik> jkoenig: the headers are provided by glibc, along with the stubs
+ <jkoenig> antrik, you mean, even those built from the .defs files in hurd/
+ ?
+ <antrik> yes
+ <jkoenig> oh, ok then.
+ <antrik> as glibc provides the stubs (in libhurduser), the headers also
+ have to come from there, or they would get out of sync
+ <jkoenig> hmm, shouldn't glibc also provide /usr/share/msgids/hurd.msgids,
+ then?
+ <antrik> jkoenig: not necessarily. the msgids describe what the servers
+ actually understand. if the stubs are missing from libhurduser, that's no
+ reason to leave out the msgids...
+ <jkoenig> ok this makes sense
+# IRC, OFTC, #debian-hurd, 2011-09-29
+ <tschwinge> pinotree: I don't like their existence. IMO (but I haven't
+ researched this in very much detail), every user of RPC stubs should
+ generated them for themselves (and glibc should directly include the
+ stubs it uses internally).
+ <pinotree> sounds fair
+ <pinotree> maybe they could be moved from glibc to hurd?
+ <tschwinge> pinotree: Yeah; someone needs to research why we have them (or
+ if it's only convenience), and whether we want to keep them.
+ <pinotree> you could move them to hurd, leaving them unaltered, so binary
+ 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 :-)
+## IRC, freenode, #hurd, 2013-02-25
+ <braunr> we should also discuss the mach_debug interface some day
+ <braunr> it's not exported by libc, but the kernel provides it
+ <braunr> slabinfo depends on it, and i'd like to include it in the hurd
+ <braunr> but i don't know what kind of security problems giving access to
+ mach_debug RPCs would create
+ <braunr> (imo, the mach_debug interface should be adjusted to be used with
+ privileged ports only)
+ <braunr> (well, maybe not all mach_debug RPCs)
+## IRC, freenode, #hurd, 2013-11-20
+ <braunr> [...] we have to make the mach_debug interface available
+ <braunr> well, i never took the time to integrate slabinfo into the hurd
+ repository
+ <braunr> because it relies on the mach_debug interface
+ <teythoon> ah
+ <braunr> while enabling that interface alone can't do harm, some debugging
+ functions shouldn't be usable by unprivileged applications
+ <braunr> so it requires some discussions
+ <braunr> i always delayed it because of more important stuff to do
+ <braunr> but slabinfo is actually very useful
+ <braunr> the more information we have about the system state, the better
+ <braunr> so it's actually important
+# IRC, freenode, #hurd, 2012-07-23
+ <pinotree> aren't libmachuser and libhurduser supposed to be slowly faded
+ out?
+ <tschwinge> pinotree: That discussion has not yet come to a conclusion, I
+ think. (I'd say: yes.)
+# IRC, freenode, #hurd, 2012-12-17
+ <pinotree> what was the idea about using the rpc stubs currently in
+ libmachuser and libhurduser? should they be linked to explicitly, or
+ assume libc brings them?
+ <braunr> pinotree: libc should bring them
+# `gnumach.defs`
+## IRC, freenode, #hurd, 2013-05-13
+ <braunr> youpi: what's the point of the last commit in the upstream hurd
+ repository (utils/vmstat: Use gnumach.defs from gnumach) ?
+ <braunr> or rather, i think i see the point, but then why do it only for
+ gnumach and not fot the rest ?
+ <braunr> for*
+ <youpi> most probably because nobody did it, probably
+ <braunr> aiui, it makes the hurd build process not rely on system headers
+ <youpi> (and nobody had any issue with it)
+ <braunr> well yes, that's why i'm wondering :)
+ <braunr> it looks perfectly fine to me to use system headers instead of
+ generating them
+ <youpi> ah right
+ <youpi> I thought there was actually a reason
+ <youpi> I'll revert
+ <youpi> could you answer David about it?
+ <braunr> sure