rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn

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