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
id:"CAEvUa7nd2LSUsMG9axCx5FeaD1aBvNxE4JMBe95b9hbpdqiLdw@mail.gmail.com"
.
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