[[!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 License|/fdl]]."]]"""]] [[!tag open_issue_glibc open_issue_hurd]] [[!toc]] # bug-hurd discussion. # IRC, freenode, #hurd, 2010-08-12 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) I would fix it, but something tells me that maybe it's a feature :-) jkoenig: the headers are provided by glibc, along with the stubs antrik, you mean, even those built from the .defs files in hurd/ ? yes oh, ok then. as glibc provides the stubs (in libhurduser), the headers also have to come from there, or they would get out of sync hmm, shouldn't glibc also provide /usr/share/msgids/hurd.msgids, then? 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... ok this makes sense # IRC, OFTC, #debian-hurd, 2011-09-29 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). sounds fair maybe they could be moved from glibc to hurd? pinotree: Yeah; someone needs to research why we have them (or if it's only convenience), and whether we want to keep them. you could move them to hurd, leaving them unaltered, so binary compatibility with eventual 3rd party users is not broken but those using them, other than hurd itself, won't compile anymore, so you fix them progressively # IRC, freenode, #hurd, 2011-11-16 is the mach_debug interface packaged in debian ? what mach_debug interface? include/include/mach_debug/mach_debug.defs in gnumach include/mach_debug/mach_debug.defs in gnumach what exactly is supposed to be packaged there? i'm talking about the host_*_info client code braunr: you mean MIG-generated stubs? antrik: yes i wrote a tiny slabinfo tool, and rpctrace doesn't show the host_slab_info call do you happen to know why ? braunr: doesn't show it at all, or just doesn't translate? antrik: doesn't at all, the msgids file contains what's needed to translate 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 great :-) i'll probably add a /proc/slabinfo entry some day and considering the current state of our beloved kernel, i'm wondering why host_*_info rpcs are considered debugging calls imo, they should always be included by default and part of the standard mach interface (if the rpc is missing, an error is simply returned) I guess that's been inherited from original Mach so you think the stubs should be provided by libmachuser? i'm not sure 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... i don't know the complete list of potential places for such calls 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 and i didn't want to imply they should be part of libc on the contrary, libmachuser seems right libmachuser is part of libc ah :) why so ? well, for one, libc needs the Mach (and Hurd) stubs itself also, it's traditionally the role of libc to provide the call wrappers for syscalls... so it makes some sense sure, but why doesn't it depend on an external libmachuser instead of embedding it ? right now that's a good question... no idea TBH :-) ## IRC, freenode, #hurd, 2013-02-25 we should also discuss the mach_debug interface some day it's not exported by libc, but the kernel provides it slabinfo depends on it, and i'd like to include it in the hurd but i don't know what kind of security problems giving access to mach_debug RPCs would create (imo, the mach_debug interface should be adjusted to be used with privileged ports only) (well, maybe not all mach_debug RPCs) ## IRC, freenode, #hurd, 2013-11-20 [...] we have to make the mach_debug interface available well, i never took the time to integrate slabinfo into the hurd repository because it relies on the mach_debug interface ah while enabling that interface alone can't do harm, some debugging functions shouldn't be usable by unprivileged applications so it requires some discussions i always delayed it because of more important stuff to do but slabinfo is actually very useful the more information we have about the system state, the better so it's actually important # IRC, freenode, #hurd, 2012-07-23 aren't libmachuser and libhurduser supposed to be slowly faded out? pinotree: That discussion has not yet come to a conclusion, I think. (I'd say: yes.) # IRC, freenode, #hurd, 2012-12-17 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? pinotree: libc should bring them # `gnumach.defs` [[!message-id "CAEvUa7nd2LSUsMG9axCx5FeaD1aBvNxE4JMBe95b9hbpdqiLdw@mail.gmail.com"]]. ## IRC, freenode, #hurd, 2013-05-13 youpi: what's the point of the last commit in the upstream hurd repository (utils/vmstat: Use gnumach.defs from gnumach) ? or rather, i think i see the point, but then why do it only for gnumach and not fot the rest ? for* most probably because nobody did it, probably aiui, it makes the hurd build process not rely on system headers (and nobody had any issue with it) well yes, that's why i'm wondering :) it looks perfectly fine to me to use system headers instead of generating them ah right I thought there was actually a reason I'll revert could you answer David about it? sure