rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn

1 files changed, 177 insertions, 0 deletions

diff --git a/service_solahart_jakarta_selatan__082122541663/libmachuser_libhurduser_rpc_stubs.mdwn b/service_solahart_jakarta_selatan__082122541663/libmachuser_libhurduser_rpc_stubs.mdwn
new file mode 100644
index 00000000..b571b82e
--- /dev/null
+++ b/service_solahart_jakarta_selatan__082122541663/libmachuser_libhurduser_rpc_stubs.mdwn
@@ -0,0 +1,177 @@
+[[!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