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