diff options
Diffstat (limited to 'open_issues/libmachuser_libhurduser_rpc_stubs.mdwn')
| -rw-r--r-- | open_issues/libmachuser_libhurduser_rpc_stubs.mdwn | 106 |
1 files changed, 106 insertions, 0 deletions
diff --git a/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn new file mode 100644 index 00000000..80fc9fcd --- /dev/null +++ b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn @@ -0,0 +1,106 @@ +[[!meta copyright="Copyright © 2010, 2011 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 + + <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 :-) |