summaryrefslogtreecommitdiff
path: root/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues/libmachuser_libhurduser_rpc_stubs.mdwn')
-rw-r--r--open_issues/libmachuser_libhurduser_rpc_stubs.mdwn177
1 files changed, 0 insertions, 177 deletions
diff --git a/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn
deleted file mode 100644
index b571b82e..00000000
--- a/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn
+++ /dev/null
@@ -1,177 +0,0 @@
-[[!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
-
- <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`
-
-[[!message-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