rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn

331 files changed, 0 insertions, 68126 deletions

diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn
deleted file mode 100644
index 04273630..00000000
--- a/open_issues/64-bit_port.mdwn
+++ /dev/null
@@ -1,72 +0,0 @@
-[[!meta copyright="Copyright © 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_gnumach open_issue_mig]]
-
-There is a `master-x86_64` GNU Mach branch.  As of 2012-11-20, it only supports
-the [[microkernel/mach/gnumach/ports/Xen]] platform.
-
-
-# IRC, freenode, #hurd, 2011-10-16
-
-    <youpi> it'd be really good to have a 64bit kernel, no need to care about
-      addressing space :)
-    <braunr> yes a 64 bits kernel would be nice
-    <braunr> i guess it wouldn't be too hard to have a special mach kernel for
-      64 bits processors, but 32 bits userland only
-    <youpi> well, it means tinkering with mig
-
-[[mig_portable_rpc_declarations]].
-
-
-# IRC, freenode, #hurd, 2012-10-03
-
-    <braunr> youpi: just so you know in case you try the master-x86_64 with
-      grub
-    <braunr> youpi: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689509
-    <youpi> ok, thx
-    <braunr> the squeeze version is fine but i had to patch the wheezy/sid one
-    <youpi> I actually hadn't hoped to boot into 64bit directly from grub
-    <braunr> youpi: there is code in viengoos that could be reused
-    <braunr> i've been thinking about it for a time now
-    <youpi> ok
-    <braunr> the two easiest ways are 1/ the viengoos one (a -m32 object file
-      converted with objcopy as an embedded loader)
-    <braunr> and 2/ establishing an identity mapping using 4x1 GB large pages
-      and switching to long mode, then jumping to c code to complete the
-      initialization
-    <braunr> i think i'll go the second way with x15, so you'll have the two :)
-
-
-## IRC, freenode, #hurd, 2013-07-02
-
-In context of [[mondriaan_memory_protection]].
-
-    <xscript> BTW, it's not like I have an infinite amount of time for this,
-      but having 64-bit support would be valuable for me, so I might contribute
-      that back if it's not a too monumental task
-    <xscript> I saw some discussions about 32bit apps on top of 64bit mach, but
-      I'd like a full 64bit system
-    <xscript> any clues?
-    <xscript> I suppose the compiler support is all there already
-    <xscript> is MIG (and mach) the only piece missing?
-    <braunr> the problem is the interfaces themselves
-    <braunr> type widths
-    <braunr> as passed between userspace and kernel
-
-
-## IRC, OFTC, #debian-hurd, 2013-10-05
-
-    <dharc> and what about 64 bit support, almost done?
-    <youpi> kernel part is done
-    <youpi> MIG 32/64 trnaslation missing
-
-[[mig_portable_rpc_declarations]].
diff --git a/open_issues/Upstart.mdwn b/open_issues/Upstart.mdwn
deleted file mode 100644
index c8a8347d..00000000
--- a/open_issues/Upstart.mdwn
+++ /dev/null
@@ -1,61 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-Upstart is an event based init system that is GPL licensed, however upstream
-contributions are under a CLA that permits proprietary relicensing.
-
-As of Jan 2 2013, Debian is considering adopting Upstart as an init system on
-GNU/Linux, and on GNU/kFreeBSD when the port to kFreeBSD is finished.
-
-The following are the words of Colin Watson on the debian-ctte@lists.debian.org
-mailing list and list the requirements of a potential HURD port:
-
->I haven't looked at this in much detail, and I suspect Dimitri hasn't
-yet although IIRC he did express some interest in doing so.  But I
-haven't seen anyone else try to outline the scope of a port, so let me
-try to do so for the sake of general understanding.  As far as I know,
-the hardest parts would be inotify, ptrace, and prctl
-(PR_SET_CHILD_SUBREAPER).
-
->inotify is used to notice changes to configuration files.  This is
-certainly helpful for users, but it isn't critical as "initctl
-reload-configuration" works without it.  We could probably do without
-this with the aid of a dpkg trigger.
-
->ptrace is used for "expect fork" and "expect daemon"; as I indicated in
-another post, I think it would be preferable to avoid these in Debian
-and quite possibly to compile them out.  (This would mean we wouldn't be
-able to translate Ubuntu jobs quite as directly, and a number of
-important jobs would definitely need to be changed, but the conversion
-isn't usually particularly difficult.)
-
->prctl (PR_SET_CHILD_SUBREAPER) is used to make SIGCHLD notification work
-properly when Upstart is supervising a user session.  This isn't a
-required feature and could easily be compiled out until suitable kernel
-support is available (this actually seems like the sort of thing that
-could be done in the Hurd without too much difficulty, but I haven't
-looked into it).  If absent, it might well impede the ability to do an
-advanced desktop port, but it wouldn't get in the way of porting the
-bulk of services.
-
->There might also be odds and ends around the details of wait status
-handling.
-
-inotify seems to be a feature that is often used in GNU/Linux programs, and
-implementing the feature in the HURD seems like a better and more rewarding
-option than porting the code in Upstart.
-
-Although many daemons double fork, that behavior seems to be dying out, and
-one can comfortably ignore the "expect fork/daemon" functionality of Upstart
-(and compile it out).
-
-[[!tag open_issue_porting]]
-
-See also the discussion about upstart on the [[systemd]] page.
diff --git a/open_issues/_san.mdwn b/open_issues/_san.mdwn
deleted file mode 100644
index 5e6c8796..00000000
--- a/open_issues/_san.mdwn
+++ /dev/null
@@ -1,64 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 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]]."]]"""]]
-
-[[!meta title="Port the GCC and LLVM/clang Sanitizers (*san) to the Hurd"]]
-
-[[!tag open_issue_gcc]]
-
-GCC and LLVM/clang provide several *sanitizers*,
-<http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation>, such
-as:
-
-  * Address Sanitizer, a memory error detector (ASan; `-fsanitize=address`)
-
-    [Finding races and memory errors with GCC instrumentation
-    (AddressSanitizer)](http://gcc.gnu.org/wiki/cauldron2012#Finding_races_and_memory_errors_with_GCC_instrumentation_.28AddressSanitizer.29),
-    GNU Tools Cauldron 2012.  <http://code.google.com/p/address-sanitizer/>.
-
-  * Memory Sanitizer, an detector of uninitialized reads (MSan;
-    `-fsanitize=memory`)
-
-    <http://code.google.com/p/memory-sanitizer/>
-
-  * Thread Sanitizer, a data race detector (TSan; `-fsanitize=thread`)
-
-    <http://code.google.com/p/data-race-test/wiki/ThreadSanitizer>
-
-  * Undefined Behavior Sanitizer (UBsan; `-fsanitize=undefined`)
-
-Porting these to the Hurd is not a trivial task, for they have intimate
-knowledge about the operating system kernel they're running on, and from a
-first look they reimplement a lot of [[/glibc]] by directly using
-[[system_call]]s -- which is basically a no-go on GNU Hurd.
-
-
-# IRC, OFTC, #gcc, 2012-12-11
-
-    <richi> hmm, is libtsan not multi-libbed?
-    <jakub> richi: it only works on x86_64 right now
-    <richi> ugh
-    <jakub> richi: so, it is multilibbed, but only built on multilibs and
-      targets which are supported
-    <jakub> richi: as it often needs lots of RAM, it is probably not going to
-      be supported on 32-bit targets at all
-    <jakub> richi: no reason not to support it on say ppc64 or sparc64 or s390x
-      I guess, just needs work
-    <richi> jakub: where is asan supported?  everywhere?
-    <jakub> richi: but then, I haven't even read what exactly libtsan does,
-      only looked at the atomics in there, and did the GCC side from what I
-      knew should be instrumented
-    <jakub> richi: asan is right now supported on x86_64/i686, ppc/ppc64,
-      perhaps partially x86 darwin (don't care) and in theory arm (nobody
-      tested)
-    <jakub> richi: porting isn't that hard, but the library isn't as clean as
-      it would be desirable portability wise
-    <jakub> richi: that said, I don't want to spend as much time as I've done
-      so far on it, and in the time I'll allocate for it optimizing the code it
-      generates is higher on the todo list than ports to other targets
diff --git a/open_issues/active_vs_passive_symlink_translator.mdwn b/open_issues/active_vs_passive_symlink_translator.mdwn
deleted file mode 100644
index cbd9b077..00000000
--- a/open_issues/active_vs_passive_symlink_translator.mdwn
+++ /dev/null
@@ -1,44 +0,0 @@
-[[!meta copyright="Copyright © 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_documentation open_issue_hurd]]
-
-IRC, freenode, #hurd, 2011-07-25
-
-Set an *active* (not *passive*) `/hurd/symlink` translator on a node.
-
-    < antrik> that's strange: the file doesn't look like a symlink in ls output
-      -- but it behaves like one...
-    < antrik> using firmlink instead of symlink yields less confusing
-      results...
-    < gg0> how does it behaves like one?
-    < antrik> perhaps the symlink mechanism only fully works for a passive
-      symlink translator, not an active one
-    < antrik> gg0: if you access it, you actually get the linked file contents
-    < antrik> it's only ls that's confused
-    < antrik> it might be because ls -l uses O_NOFOLLOW, which results in
-      O_NOTRANS, so it sees the original file contents
-    < gg0> stat says it's still 12264 bytes
-    < antrik> stat also seems to use NOFOLLOW
-    < antrik> wc will show the "correct" size
-    < gg0> ok
-    < antrik> if you set it as passive translator, it works as expected... but
-      then you better don't forget removing it, as it won't go away after a
-      reboot :-)
-    < antrik> but as I said, you can just ignore the weirdness -- or use
-      firmlink instead
-    < antrik> the thing is, if symlink is set as a passive translator, the
-      filesystem handles it specially, so it really looks like a symlink to
-      programs using NOFOLLOW. that's not the case with an active symlink... so
-      programs using NOFOLLOW simply do not see the active symlink at all
-    < antrik> firmlink OTOH ignores NOFOLLOW, so you always see the linked-to
-      file
-
-  * [[hurd/translator/short-circuiting]]
diff --git a/open_issues/address_space_memory_mapping_entries.mdwn b/open_issues/address_space_memory_mapping_entries.mdwn
deleted file mode 100644
index f1811b27..00000000
--- a/open_issues/address_space_memory_mapping_entries.mdwn
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2013 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_gnumach]]
-
-IRC, freenode, #hurd, 2011-05-07
-
-    <braunr> and as a last example: memory mapping is heavily used in the hurd,
-      but for some reason, the map entries in an address space are still on a
-      linked list
-    <braunr> a bare linked list
-    <braunr> which makes faults and page cache lookups even slower
-
-A [[red-black tree|gnumach_vm_map_red-black_trees]] was added to VM maps to
-speed up lookups.
diff --git a/open_issues/adduser.mdwn b/open_issues/adduser.mdwn
deleted file mode 100644
index 713a1dd3..00000000
--- a/open_issues/adduser.mdwn
+++ /dev/null
@@ -1,37 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2009 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]]."]]"""]]
-
-[[!meta title="adduser: posix_spawn() error=1073741826"]]
-
-[[!tag open_issue_porting]]
-
-`adduser` does work as expected, the following warnings are spurious, they just
-appear when one doesn't have the nscd package. They do not appear on Linux boxes
-because there posix_spawn doesn't report ENOENT for exec(). POSIX indeed says
-that `if the error occurs after the calling process successfully returns, the
-child process shall exit with exit status 127'. The Hurd however reports all
-errors, thus the warning.
-
-    $ sudo adduser foo
-    Adding user `foo' ...
-    Adding new group `foo' (1002) ...
-    posix_spawn() error=1073741826
-    posix_spawn() error=1073741826
-    posix_spawn() error=1073741826
-    Adding new user `foo' (1002) with group `foo' ...
-    posix_spawn() error=1073741826
-    posix_spawn() error=1073741826
-    posix_spawn() error=1073741826
-    posix_spawn() error=1073741826
-    Creating home directory `/home/foo' ...
-    Copying files from `/etc/skel' ...
-    [...]
-
-Reported at [[!debbug 623199]].
diff --git a/open_issues/alarm_setitimer.mdwn b/open_issues/alarm_setitimer.mdwn
deleted file mode 100644
index a1c8a7d3..00000000
--- a/open_issues/alarm_setitimer.mdwn
+++ /dev/null
@@ -1,182 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 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]]."]]"""]]
-
-[[!meta title="alarm/setitimer"]]
-
-[[!tag open_issue_glibc open_issue_hurd]]
-
-`setitimer()`, called by `alarm()` when setting a new alarm, it is not able
-to disable on its own the timer when the alarm is fired the first time.
-On the other hand, manually invoking `alarm(0)` can cancel the running timer
-for `SIGALRM`.
-
-See also the attached file: on other OSes (e.g. Linux) it blocks waiting
-for a signal, while on GNU/Hurd it gets a new alarm and exits.
-
-[[alrm.c]]
-
-This issue was recently fixed (around January 2013).
-
-# IRC, freenode, #hurd, 2012-07-29
-
-    <braunr> our setitimer is bugged
-    <braunr> it seems doesn't seem to leave a timer disarmed when the interval
-      is set to 0
-    <braunr> (which means a one shot timer is actually periodic ..)
-
-
-## IRC, freenode, #hurd, 2012-12-26
-
-    <braunr> youpi: tschwinge: the setitimer issue
-      http://www.gnu.org/software/hurd/open_issues/alarm_setitimer.html) is
-      because of the global preemptor installed by setitimer not being run when
-      sigalrm is catched
-    <braunr> if anyone has a good definition for a preemptor, let us know (mine
-      is currently "something that is scanned on signal delivery and can alter
-      this delivery")
-    <youpi> I don't have any better definition
-    <pinotree> braunr: ah, that explains indeed
-    <pinotree> thanks
-    <braunr> i think i found the problem :)
-    <braunr> seems to be a minor overlook from drepper
-    <braunr> (or the real author if he was only the committer)
-    <braunr> hurd_preempt_signals augments _hurdsig_preempted_set with the
-      signals from the installed preemptor
-    <braunr> but the inline version in setitimer doesn't
-    <braunr> and post_signal actually checks that
-    <braunr> the preemptor itself looks wrong, since its sigcode range is 0, 0
-      whereas SI_TIMER is used when raising SIGALRM ...
-    <braunr> ah but that's a recent change, right
-    <braunr> it came with "implement SA_SIGINFO signal handlers"
-      (e19a2fad70b187e5efe79768f86a1f05cb5e0390, Tue Feb 21 02:41:18 2012)
-    <braunr> yes, fixed :)
-    <braunr> patch committed at
-      http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/setitimer_fix
-    <youpi> and pushed to the debian package
-
-
-## IRC, freenode, #hurd, 2012-12-27
-
-    <braunr> do we know any application that was broken because of setitimer ?
-    <pinotree> braunr: bits in the python and perl test suites
-    <braunr> ok
-
-
-## IRC, freenode, #hurd, 2012-12-28
-
-    <pinotree> braunr: ah, also libglib-perl's testsuite is affected by the
-      alarm/setitimer issue
-    <braunr> pinotree: only tests ? :(
-    <pinotree> braunr: yeah
-    <braunr> ok, we don't win that much on this fix, but anyway, still good to
-      have
-    <pinotree> but that source is pretty quick to compile and check
-    <pinotree> braunr: eh, so far that's what i found myself
-
-
-## IRC, freenode, #hurd, 2013-01-04
-
-See also [[select]].
-
-    <youpi> bummer, we have broken ghc completely with the latest glibc patches
-    <pinotree> youpi: what do you mean?
-    <youpi> pinotree: it just hangs on installation
-
-
-## IRC, freenode, #hurd, 2013-01-05
-
-    <youpi> pinotree: it seems ghc was disturbed by the setitimer patch
-    <youpi> pinotree: http://paste.debian.net/221807/
-    <youpi> pinotree: it seems to be simply due to nested locking of
-      _hurd_siglock :/
-    <youpi> pinotree: I wonder whether this code has ever been really tested
-    <youpi> oops
-    <youpi> braunr: my comments above were for you actually :)
-    <youpi> braunr: see the update I've just commited to the debian patch
-    <youpi> I've added a parameter to setitimer_locked, to know whether the
-      lock is already taken or not
-    <youpi> that does fix ghc
-    <youpi> as well as the gdb ntpdate hang, apparently
-    <youpi> I can confirm that the single-select patch breaks ntpdate for some
-      reason
-    <youpi> I wonder whether it could be due to port set behavior being
-      different from single reply port
-    <youpi> I believe I understand what happens
-
-[[select_vs_signals]].
-
-    <youpi> I'll rebuild ntpdate with a 1s timeout
-    <youpi> that'll at least fix that
-    <youpi> rah, no, doesn't work, it insists on getting its alarm
-    <youpi> Mmm, no, the __mach_msg call doesn't even return
-    <youpi> even though MACH_RCV_TIMEOUT is set, and to is 1000
-    <braunr> youpi: i see
-    <braunr> gnu_srs: and you, see how youpi analysed and understood the
-      problem, instead of just guessing :p
-    <braunr> youpi: it doesn't return ?
-    <braunr> iirc, the __mach_msg wrapper deals with the interruptible flag
-    <youpi> braunr: yes, __mach_msg deals with the interruptible flag by
-      looping !
-    <youpi> and the info page says it: if it's interrupted too often, it may
-      just never return
-    <youpi> that's what actually happens here
-    <youpi> (ntpdate sets an itimer more often than every 1s)
-    <braunr> youpi: ew :)
-    <youpi> I'll test a bit more, and submit a patch
-    <pinotree> youpi: otoh a _locker function usually means it expects a locked
-      mutex ;)
-    <pinotree> i also i wondered whether there could be a race in the settimer
-      mini-thread, between its mach_msg and its reading of the interval
-    <youpi> pinotree: right, we could as well just lock anyway
-    <youpi> there could be indeed
-    <pinotree> youpi: i don't know much about the internals of signal
-      dispatching, but could it happen the following:
-    <pinotree> in timer thread, mach_msg expires → sig_post_request → before
-      the main thread receives/processes the signal, the timer thread iterates
-      again on its while(1), using the same interval previously used
-    <pinotree> ?
-    <youpi> did you check the comment above __msg_sig_post_request?
-    <pinotree> ah ok
-    <youpi> I'm not sure how that works, but it's supposed to :)
-    <pinotree> just wonder: wouldn't it be simplier if the logic to change the
-      timeout would be in the timer thread, instead of relying on the main
-      thread adjusting it?
-    <youpi> maybe there are some semantic details that wouldn't be right with
-      such approach
-    <pinotree> i see
-    <pinotree> i guess so if the new interval is 0, the thread can be properly
-      suspened (or killed, if the former fails)
-    <youpi> could be something like this, yes
-    <pinotree> youpi: ah, wrt your comments of tonight: at least with the
-      current setitimer patch (in -38), a simple alarm() test app works, and i
-      saw few python tests can be reenabled now
-    <youpi> ok
-    <pinotree> so even if not totally correct, at least it had some positive
-      effects
-    <pinotree> youpi: wrt the double lock issue of _hurd_siglock, what about
-      using the "crit" parameter of setitimer_locked?
-    <youpi> it may have various values
-    <youpi> depending whether we're already in the critical section etc.
-    <pinotree> restart_itimer does not take that lock, so we could check
-      whether crit is null, and in that case not even bothering to check the
-      signal preemptors, since it was called as a result of own setitimer
-      thread?
-    <youpi> I'd rather avoid binding whether the mutex is held to whether the
-      call is coming from the actual premptor
-    <youpi> again, crit may be null if we're already in the critical section
-      when setitimer is called
-    <braunr> setitimer already does unclean things with preemptors
-    <youpi> not a good thing to add more :)
-    <pinotree> fair enough, so a simple bool should do the job
-    <braunr> i mean, the whole thing is "cheezoid" :)
-    <braunr> it probably needs a rewrite some day
-    <braunr> so "in the meantime" (of years, i know)
-    <pinotree> braunr: and temporary, too
-    <braunr> but a bool is fine too, sure :)
diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn
deleted file mode 100644
index 496d2a06..00000000
--- a/open_issues/anatomy_of_a_hurd_system.mdwn
+++ /dev/null
@@ -1,1430 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-[[!taglink open_issue_documentation]]
-
-A bunch of this should also be covered in other (introductionary) material,
-like Bushnell's Hurd paper.  All this should be unfied and streamlined.
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2011-03-08
-
-    <foocraft> I've a question on what are the "units" in the hurd project, if
-      you were to divide them into units if they aren't, and what are the
-      dependency relations between those units(roughly, nothing too pedantic
-      for now)
-    <antrik> there is GNU Mach (the microkernel); there are the server
-      libraries in the Hurd package; there are the actual servers in the same;
-      and there is the POSIX implementation layer in glibc
-    <antrik> relations are a bit tricky
-    <antrik> Mach is the base layer which implements IPC and memory management
-    <foocraft> hmm I'll probably allocate time for dependency graph generation,
-      in the worst case
-    <antrik> on top of this, the Hurd servers, using the server libraries,
-      implement various aspects of the system functionality
-    <antrik> client programs use libc calls to use the servers
-    <antrik> (servers also use libc to communicate with other servers and/or
-      Mach though)
-    <foocraft> so every server depends solely on mach, and no other server?
-    <foocraft> s/mach/mach and/or libc/
-    <antrik> I think these things should be pretty clear one you are somewhat
-      familiar with the Hurd architecture... nothing really tricky there
-    <antrik> no
-    <antrik> servers often depend on other servers for certain functionality
-
-
-# Bootstrap
-
-## [[hurd_init]]
-
-## IRC, freenode, #hurd, 2011-03-12
-
-    <dEhiN> when mach first starts up, does it have some basic i/o or fs
-      functionality built into it to start up the initial hurd translators?
-    <antrik> I/O is presently completely in Mach
-    <antrik> filesystems are in userspace
-    <antrik> the root filesystem and exec server are loaded by grub
-    <dEhiN> o I see
-    <dEhiN> so in order to start hurd, you would have to start mach and
-      simultaneously start the root filesystem and exec server?
-    <antrik> not exactly
-    <antrik> GRUB loads all three, and then starts Mach. Mach in turn starts
-      the servers according to the multiboot information passed from GRUB
-    <dEhiN> ok, so does GRUB load them into ram?
-    <dEhiN> I'm trying to figure out in my mind how hurd is initially started
-      up from a low-level pov
-    <antrik> yes, as I said, GRUB loads them
-    <dEhiN> ok, thanks antrik...I'm new to the idea of microkernels, but a
-      veteran of monolithic kernels
-    <dEhiN> although I just learned that windows nt is a hybrid kernel which I
-      never knew!
-    <rm> note there's a /hurd/ext2fs.static
-    <rm> I belive that's what is used initially... right?
-    <antrik> yes
-    <antrik> loading the shared libraries in addition to the actual server
-      would be unweildy
-    <antrik> so the root FS server is linked statically instead
-    <dEhiN> what does the root FS server do?
-    <antrik> well, it serves the root FS ;-)
-    <antrik> it also does some bootstrapping work during startup, to bring the
-      rest of the system up
-
-
-## IRC, freenode, #hurd, 2014-01-03
-
-    <teythoon> hmpf, the hurd bootstrapping process is complicated and fragile,
-      maybe to the point that it is to be considered broken
-    <teythoon> aiui the hurd uses the filesystem for service lookup
-    <teythoon> older mach documentation suggests that there once existed a name
-      server instead for this purpose
-    <teythoon> the hurd approach is elegant and plan9ish
-    <teythoon> the problem is in the early bootstrapping
-    <teythoon> what if the root filesystem is r/o and there is no /servers or
-      /servers/exec ?
-    <teythoon> e. g. rm /servers/exec && reboot -> the rootfs dies early in the
-      hurd server bootstrap :/
-    <braunr> well yes
-    <braunr> it's normal to have such constraints
-    <teythoon> uh no
-    <braunr> at the same time, the boot protocol must be improved, if only to
-      support userspace disk drivers
-    <teythoon> totally unacceptable
-    <braunr> why not ?
-    <teythoon> b/c my box just died and lost it's exec node
-    <braunr> so ?
-    <braunr> loosing the exec node is unacceptable
-    <youpi> well, linux dies too if you don't have /dev populated at least a
-      bit
-    <braunr> not being able to boot without the "exec" service is pretty normal
-    <braunr> the hurd turns the vfs into a service directory
-    <teythoon> the exec service is there, only the lookup mechanism is broken
-    <braunr> replacing the name server you mentioned earlier
-    <teythoon> yes
-    <braunr> if you don't have services, you don't have them
-    <braunr> i don't see the problem
-    <braunr> the problem is the lookup mechanism getting broken
-    <teythoon> ... that easily
-    <braunr> imagine a boot protocol based on a ramfs filled from a cpio
-    <teythoon> i do actually ;)
-    <braunr> there would be no reason at all the lookup mechanism would break
-    <teythoon> yes
-    <teythoon> but the current situation is not acceptable
-    <braunr> i agree
-    <teythoon> ^^
-    <braunr> ext2fs is too unreliable for that
-    <braunr> but using the VFS as a directory is more than acceptable
-    <braunr> it's probably the main hurd feature
-    <teythoon> yes
-    <braunr> i see it rather as a circular dependency problem
-    <braunr> and if you have good ideas, i'm all ear for propel ... :>
-    <braunr> antrik already talked about some of them for the bootstrap
-      protocol
-    <braunr> we should sum them up somewhere if not done already
-    <teythoon> i've been pondering how to install a tmpfs translator as root
-      translator
-    <teythoon> braunr: we could create a special translator for /servers
-    <braunr> maybe
-    <teythoon> very much like fakeroot, it just proxies messages to a real
-      translator
-    <teythoon> but if operations like settrans fail, we handle them
-      transparently, like an overlay
-    <braunr> i consider /servers to be very close to /dev
-    <teythoon> yes
-    <braunr> so something like devfs seems obvious yes
-    <braunr> i don't even think there needs to be an overlay
-    <teythoon> y not ?
-    <braunr> why does /servers need real nodes ?
-    <teythoon> for persistence
-    <braunr> what for ?
-    <teythoon> e.g. crash server selection
-    <braunr> hm ok
-    <teythoon> network configuration
-    <braunr> i personally wouldn't make that persistent
-    <braunr> it can be configured in files and installed at boot time
-    <teythoon> me neither, but that's how it's currently done
-    <braunr> are you planning to actually work on that soon ?
-    <teythoon> if we need no persistence, we can just use tmpfs
-    <braunr> it wouldn't be a mere tmpfs
-    <teythoon> it could
-    <braunr> it's a tmpfs that performs automatic discovery and registration of
-      system services
-    <teythoon> with some special wrapper that preserves e.g. /servers/exec
-    <teythoon> oh
-    <braunr> so rather, devtmpfs
-    <teythoon> it is o_O :p
-    <braunr> ?
-    <braunr> what is what ?
-    <teythoon> well, it could be a tmpfs and some utility creating the nodes
-    <braunr> whether the node management is merged in or separate doesn't
-      matter that much i guess
-    <braunr> i'd personally imagine it merged, and tmpfs available as a
-      library, so that stuff like sysfs or netstatfs can easily be written
-
-
-## IRC, freenode, #hurd, 2014-02-12
-
-    <teythoon> braunr: i fixed all fsys-related receiver lookups in libdiskfs
-      and surely enough the bootstrap hangs with no indication whats wrong
-    <braunr> teythoon: use mach_print :/
-    <teythoon> braunr: the hurd bootstrap is both fragile and hard to tweak in
-      interesting ways :/
-    <braunr> teythoon: i agree with that
-    <braunr> teythoon: maybe this will help :
-      http://wiki.hurdfr.org/upload/graphviz/dot9b65733655309d059dca236f940ef37a.png
-    <braunr> although i guess you probably already know that
-    <teythoon> heh, unicode for the win >,<
-    <braunr> :/
-
-
-# Source Code Documentation
-
-Provide a cross-linked sources documentation, including generated files, like
-RPC stubs.
-
-  * <http://www.gnu.org/software/global/>
-
-
-# [[Hurd_101]]
-
-
-# [[hurd/IO_path]]
-
-Need more stuff like that.
-
-
-# IRC, freenode, #hurd, 2011-10-18
-
-    <frhodes> what happens @ boot. and which translators are started in what
-      order?
-    <antrik> short version: grub loads mach, ext2, and ld.so/exec; mach starts
-      ext2; ext2 starts exec; ext2 execs a few other servers; ext2 execs
-      init. from there on, it's just standard UNIX stuff
-
-
-# IRC, OFTC, #debian-hurd, 2011-11-02
-
-    <sekon_> is __dir_lookup a RPC ??
-    <sekon_> where can i find the source of __dir_lookup ??
-    <sekon_> grepping most gives out rvalue assignments 
-    <sekon_> -assignments 
-    <sekon_> but in hurs/fs.h it is used as a function ??
-    <pinotree> it should be the mig-generated function for that rpc
-    <sekon_> how do i know how its implemented ??
-    <sekon_> is there any way to delve deeprer into mig-generated functions 
-    <tschwinge> sekon_: The MIG-generated stuff will either be found in the
-      package's build directory (if it's building it for themselves), or in the
-      glibc build directory (libhurduser, libmachuser; which are all the
-      available user RPC stubs).
-    <tschwinge> sekon_: The implementation can be found in the various Hurd
-      servers/libraries.
-    <tschwinge> sekon_: For example, [hurd]/libdiskfs/dir-lookup.c.
-    <tschwinge> sekon_: What MIG does is provide a function call interface for
-      these ``functions'', and the Mach microkernel then dispatches the
-      invocation to the corresponding server, for example a /hurd/ext2fs file
-      system (via libdiskfs).
-    <tschwinge> sekon_: This may help a bit:
-      http://www.gnu.org/software/hurd/hurd/hurd_hacking_guide.html
-
-
-# IRC, freenode, #hurd, 2012-01-08
-
-    <abique> can you tell me how is done in hurd:  "ls | grep x" ?
-    <abique> in bash
-    <youpi> ls's standard output is a port to the pflocal server, and grep x's
-      standard input is a port to the pflocal server
-    <youpi> the connexion between both ports inside the pflocal server being
-      done by bash when it calls pipe()
-    <abique> youpi, so STDOUT_FILENO, STDIN_FILENO, STDERR_FILENO still exists
-      ?
-    <youpi> sure, hurd is compatible with posix
-    <abique> so bash 1) creates T1 (ls) and T2 (grep), then create a pipe at
-      the pflocal server, then connects both ends to T1 and T2, then start(T1),
-      start(T2) ?
-    <youpi> not exactly
-    <youpi> it's like on usual unix, bash creates the pipe before creating the
-      tasks
-    <youpi> then forks to create both of them, handling them each side of the
-      pipe
-    <abique> ok I see
-    <youpi> s/handling/handing/
-    <abique> but when you do pipe() on linux, it creates a kernel object, this
-      time it's 2 port on the pflocal ?
-    <youpi> yes
-    <abique> how are spawned tasks ?
-    <abique> with fork() ?
-    <youpi> yes
-    <youpi> which is just task_create() and duplicating the ports into the new
-      task
-    <abique> ok
-    <abique> so it's easy to rewrite fork() with a good control of duplicated
-      fd
-    <abique> about threading, mutexes, conditions, etc.. are kernel objects or
-      just userland objects ?
-    <youpi> just ports
-    <youpi> (only threads are kernel objects)
-    <abique> so, about efficiency, are pipes and mutexes efficient ?
-    <youpi> depends what you call "efficient"
-    <youpi> it's less efficient than on linux, for sure
-    <youpi> but enough for a workable system
-    <abique> maybe hurd is the right place for a userland thread library like
-      pth or any fiber library
-    <abique> ?
-    <youpi> hurd already uses a userland thread library
-    <youpi> libcthreads
-    <abique> is it M:N ?
-    <youpi> libthreads, actually
-    <youpi> yes
-
-Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and libpthread use an 1:1 model.
-
-    <abique> nice
-    <abique> is the task scheduler in the kernel ?
-    <youpi> the kernel thread scheduler, yes, of course
-    <youpi> there has to be one
-    <abique> are the posix open()/readdir()/etc... the direct vfs or wraps an
-      hurd layer libvfs ?
-    <youpi> they wrap RPCs to the filesystem servers
-    <antrik> the Bushnell paper is probably the closest we have to a high-level
-      documentation of these concepts...
-    <antrik> the Hurd does not have a central VFS component at all. name
-      lookups are performed directly on the individual FS servers
-    <antrik> that's probably the most fundamental design feature of the Hurd
-    <antrik> (all filesystem operations actually, not only lookups)
-
-
-## IRC, freenode, #hurd, 2012-01-09
-
-    <braunr> youpi: are you sure cthreads are M:N ? i'm almost sure they're 1:1
-    <braunr> and no modern OS is a right place for any thread userspace
-      library, as they wouldn't have support to run threads on different
-      processors (unless processors can be handled by userspace servers, but
-      still, it requires intimate cooperation between the threading library and
-      the kernel/userspace server in any case
-    <youpi> braunr: in libthreads, they are M:N
-    <youpi> you can run threads on different processors by using several kernel
-      threads, there's no problem in there, a lot of projects do this
-    <braunr> a pure userspace library can't use kernel threads
-    <braunr> at least pth was explacitely used on systems like bsd at a time
-      when they didn't have kernel threads exactly for that reason
-    <braunr> explicitely*
-    <braunr> and i'm actually quite surprised to learn that we have an M:N
-      threading model :/
-    <youpi> why do you say "can't" ?
-    <braunr> but i wanted to reply to abique and he's not around
-    <youpi> of course you need kernel threads
-    <youpi> but all you need is to bind them
-    <braunr> well, what i call a userspace threading library is a library that
-      completely implement threads without the support of the kernel
-    <braunr> or only limited support, like signals
-    <youpi> errr, you can't implement anything with absolutely no support of
-      the kernel
-    <braunr> pth used only SIGALRM iirc
-    <youpi> asking for more kernel threads to use more processors doesn't seem
-      much
-    <braunr> it's not
-    <braunr> but i'm refering to what abique said
-    <braunr> 01:32 < abique> maybe hurd is the right place for a userland
-      thread library like pth or any fiber library
-    <youpi> well, it's indeed more, because the glibc lets external libraries
-      provide their mutex
-    <youpi> while on linux, glibc doesn't
-    <braunr> i believe he meant removing thread support from the kernel :p
-    <youpi> ah
-    <braunr> and replying "nice" to an M:N threading model is also suspicious,
-      since experience seems to show 1:1 models are better
-    <youpi> "better" ????
-    <braunr> yes
-    <youpi> well
-    <youpi> I don't have any time to argue  about that
-    <youpi> because that'd be extremely long
-    <braunr> simpler, so far less bugs, and also less headache concerning posix
-      conformance
-    <youpi> but there's no absolute "better" here
-    <youpi> but less performant
-    <youpi> less flexible
-    <braunr> that's why i mention experience :)
-    <youpi> I mean experience too
-    <braunr> why less performant ?
-    <youpi> because you pay kernel transition
-    <youpi> because you don't know anything about the application threads
-    <youpi> etc.
-    <braunr> really ?
-    <youpi> yes
-    <braunr> i fail to see where the overhead is
-    <youpi> I'm not saying m:n is generally better than 1:1 either
-    <youpi> thread switch, thread creation, etc.
-    <braunr> creation is slower, i agree, but i'm not sure it's used frequently
-      enough to really matter
-    <youpi> it is sometimes used frequently enough
-    <youpi> and in those cases it would be a headache to avoid it
-    <braunr> ok
-    <braunr> i thought thread pools were used in those cases
-    <youpi> synchronized with kernel mutexes ?
-    <youpi> that's still slow
-    <braunr> it reduces to the thread switch overhead
-    <braunr> which, i agree is slightly slower
-    <braunr> ok, i's a bit less performant :)
-    <braunr> well don't futexes exist just for that too ?
-    <youpi> yes and no
-    <youpi> in that case they don't help
-    <youpi> because they do sleep
-    <youpi> they help only when the threads are living
-    <braunr> ok
-    <youpi> now as I said I don't have to talk much more, I have to leave :)
-
-
-# IRC, freenode, #hurd, 2012-12-06
-
-    <braunr> spiderweb: have you read
-      http://www.gnu.org/software/hurd/hurd-paper.html ?
-    <spiderweb> I'll have a look.
-    <braunr> and also the beginning of
-      http://ftp.sceen.net/mach/mach_a_new_kernel_foundation_for_unix_development.pdf
-    <braunr> these two should provide a good look at the big picture the hurd
-      attemtps to achieve
-    <Tekk_> I can't help but wonder though, what advantages were really
-      achieved with early mach?
-    <Tekk_> weren't they just running a monolithic unix server like osx does?
-    <braunr> most mach-based systems were
-    <braunr> but thanks to that, they could provide advanced features over
-      other well established unix systems
-    <braunr> while also being compatible
-    <Tekk_> so basically it was just an ease of development thing
-    <braunr> well that's what mach aimed at being
-    <braunr> same for the hurd
-    <braunr> making things easy
-    <Tekk_> but as a side effect hurd actually delivers on the advantages of
-      microkernels aside from that, but the older systems wouldn't, correct?
-    <braunr> that's how there could be network file systems in very short time
-      and very scarce resources (i.e. developers working on it), while on other
-      systems it required a lot more to accomplish that
-    <braunr> no, it's not a side effect of the microkernel
-    <braunr> the hurd retains and extends the concept of flexibility introduced
-      by mach
-    <Tekk_> the improved stability, etc. isn't a side effect of being able to
-      restart generally thought of as system-critical processes?
-    <braunr> no
-    <braunr> you can't restart system critical processes on the hurd either
-    <braunr> that's one feature of minix, and they worked hard on it
-    <Tekk_> ah, okay. so that's currently just the domain of minix
-    <Tekk_> okay
-    <Tekk_> spiderweb: well, there's 1 advantage of minix for you :P
-    <braunr> the main idea of mach is to make it easy to extend unix
-    <braunr> without having hundreds of system calls
-
-[[/system_call]].
-
-    <braunr> the hurd keeps that and extends it by making many operations
-      unprivileged
-    <braunr> you don't need special code for kernel modules any more
-    <braunr> it's easy
-    <braunr> you don't need special code to handle suid bits and other ugly
-      similar hacks,
-    <braunr> it's easy
-    <braunr> you don't need fuse
-    <braunr> easy
-    <braunr> etc..
-
-
-# Service Directory
-
-## IRC, freenode, #hurd, 2012-12-06
-
-    <spiderweb> what is the #1 feature that distinguished hurd from other
-      operating systems. the concept of translators. (will read more when I get
-      more time).
-    <braunr> yes, translators
-    <braunr> using the VFS as a service directory
-    <braunr> and the VFS permissions to control access to those services
-
-
-## IRC, freenode, #hurd, 2013-05-23
-
-    <gnu_srs> Hi, is there any efficient way to control which backed
-      translators are called via RPC with a user space program?
-    <gnu_srs> Take for example io_stat: S_io_stat is defined in boot/boot.c,
-      pfinet/io-ops.c and pflocal/io.c
-    <gnu_srs> And the we have libdiskfs/io-stat.c:diskfs_S_io_stat,
-      libnetfs/io-stat.c:netfs_S_io_stat, libtreefs/s-io.c:treefs_S_io_stat,
-      libtrivfs/io-stat.c:trivfs_S_io_stat
-    <gnu_srs> How are they related?
-    <braunr> gnu_srs: it depends on the server (translator) managing the files
-      (nodes) you're accessing
-    <braunr> so use fsysopts to know the server, and see what this server uses
-    <gnu_srs> fsysopts /hurd/pfinet and fsysopts /hurd/pflocal gives the same
-      answer: ext2fs --writable --no-inherit-dir-group --store-type=typed
-      device:hd0s1
-    <braunr> of course
-    <braunr> the binaries are regular files
-    <braunr> see /servers/socket/1 and /servers/socket/2 instead
-    <braunr> which are the nodes representing the *service*
-    <braunr> again, the hurd uses the file system as a service directory
-    <braunr> this usage of the file system is at the core of the hurd design
-    <braunr> files are not mere files, they're service names
-    <braunr> it happens that, for most files, the service behind them is the
-      same as for regular files
-    <braunr> gnu_srs: this *must* be obvious for you to do any tricky work on
-      the hurd
-
-    <gnu_srs> Anyway, if I create a test program calling io_stat I assume
-      S_io_stat in pflocal is called.
-    <gnu_srs> How to make the program call S_io_stat in pfinet instead? 
-    <braunr> create a socket managed by pfinet
-    <braunr> i.e. an inet or inet6 socket
-    <braunr> you can't assume io_stat is serviced by pflocal
-    <braunr> only stats on unix sockets of pipes will be
-    <braunr> or*
-    <gnu_srs> thanks, what about the *_S_io_stat functions?
-    <braunr> what about them ?
-    <gnu_srs> How they fit into the picture, e.g. diskfs_io_stat?
-    <gnu_srs> *diskfs_S_io_stat
-    <braunr> gnu_srs: if you open a file managed by a server using libdiskfs,
-      e.g. ext2fs, that one will be called
-    <gnu_srs> Using the same user space call: io_stat, right?
-    <braunr> it's all userspace
-    <braunr> say rather, client-side
-    <braunr> the client calls the posix stat() function, which is implemented
-      by glibc, which converts it into a call to io_stat, and sends it to the
-      server managing the open file
-    <braunr> the io_stat can change depending on the server
-    <braunr> the remote io_stat implementation, i mean
-    <braunr> identify the server, and you will identify the actual
-      implementation
-
-
-## IRC, freenode, #hurd, 2013-06-30
-
-    <hacklu> hi, what is the replacer of netname_check_in? 
-
-    <hacklu> I want to ask another question. in my opinion, the rpc is the
-      mach's way, and the translator is the hurd's way. so somebody want to
-      lookup a service, it should not need to ask the mach kernel know about
-      this query. the hurd will take the control. 
-    <hacklu> am I right?
-    <braunr> no
-    <braunr> that's nonsense
-    <braunr> service lookups has never been in mach
-    <braunr> first mach based systems used a service directory, whereas the
-      hurd uses the file system for that
-    <braunr> you still need mach to communicate with either of those
-    <hacklu> how to understand the term of service directory here?
-    <braunr> a server everyone knows
-    <braunr> which gives references to other servers
-    <braunr> usually, depending on the name
-    <braunr> e.g. name_lookup("net") -> port right to network server
-    <hacklu> is that people use netname_check_in to register service in the
-      past? now used libtrivfs?
-    <braunr> i don't know about netname_check_in
-    <braunr> old mach (not gnumach) documentation might mention this service
-      directory
-    <braunr> libtrivfs doesn't have much to do with that
-    <braunr> on the hurd, the equivalent is the file system
-    <hacklu> maybe that is outdate, I just found that exist old doc, and old
-      code which can't be build.
-    <braunr> every process knows /
-    <braunr> the file system is the service directory
-    <braunr> nodes refer to services
-    <hacklu> so the file system is the nameserver, any new service should
-      register in it before other can use
-    <braunr> and the file system is distributed, so looking up a service may
-      require several queries
-    <braunr> setting a translator is exactly that, registering a program to
-      service requests on a node
-    <braunr> the file system isn't one server though
-    <braunr> programs all know about /, but then, lookups are recursive
-    <braunr> e.g. if you have / and /home, and are looking for
-      /home/hacklu/.profile, you ask / which tells you about /home, and /home
-      will give you a right to /home/hacklu/.profile
-    <hacklu> even in the past, the mach don't provide name register service,
-      there must be an other server to provide this service?
-    <braunr> yes
-    <braunr> what's nonsense in your sentence is comparing RPCs and translators
-    <braunr> translators are merely servers attached to the file system, using
-      RPCs to communicate with the rest of the system
-    <hacklu> I know yet, the two just one thing.
-    <braunr> no
-    <braunr> two things :p
-    <braunr> completely different and unrelated except for one using the other
-    <hacklu> ah, just one used aonther one.
-    <hacklu> is exist anyway to anounce service except settrans with file node?
-    <braunr> more or less
-    <braunr> tasks can have special ports
-    <braunr> that's how one task knows about / for example
-    <braunr> at task creation, a right to / is inserted in the new task
-    <hacklu> I think this is also a file node way.
-    <braunr> no
-    <braunr> if i'm right, auth is referenced the same way
-    <braunr> and there is no node for auth
-    <hacklu> how the user get the port of auth with node?
-    <braunr> it's given when a task is created
-    <hacklu> pre-set in the creation of one task?
-    <braunr> i'm unconfortable with "pre-set"
-    <braunr> inserted at creation time
-    <braunr> auth is started very early
-    <braunr> then tasks are given a reference to it
-
-
-# IRC, freenode, #hurd, 2012-12-10
-
-    <spiderweb> I want to work on hurd, but I think I'm going to start with
-      minix, I own the minix book 3rd ed. it seems like a good intro to
-      operating systems in general. like I don't even know what a semaphore is
-      yet.
-    <braunr> well, enjoy learning :)
-    <spiderweb> once I finish that book, what reading do you guys recommend?
-    <spiderweb> other than the wiki
-    <braunr> i wouldn't recommend starting with a book that focuses on one
-      operating system anyway
-    <braunr> you tend to think in terms of what is done in that specific
-      implementation and compare everything else to that
-    <braunr> tannenbaum is not only the main author or minix, but also the one
-      of the book http://en.wikipedia.org/wiki/Modern_Operating_Systems
-    <braunr>
-      http://en.wikipedia.org/wiki/List_of_important_publications_in_computer_science#Operating_systems
-      should be a pretty good list :)
-
-
-# IRC, freenode, #hurd, 2013-03-12
-
-    <mjjc> i have a question regarding ipc in hurd. if a task is created, does
-      it contain any default port rights in its space? i am trying to deduce
-      how one calls dir_lookup() on the root translator in glibc's open().
-    <kilobug> mjjc: yes, there are some default port rights, but I don't
-      remember the details :/
-    <mjjc> kilobug: do you know where i should search for details?
-    <kilobug> mjjc: hum either in the Hurd's hacking guide
-      https://www.gnu.org/software/hurd/hacking-guide/ or directly in the
-      source code of exec server/libc I would say, or just ask again the
-      question here later on to see if someone else has more information
-    <mjjc> ok, thanks
-    <pinotree> there's also rpctrace to, as the name says, trace all the rpc's
-      executed
-    <braunr> some ports are introduced in new tasks, yes
-    <braunr> see
-      http://www.gnu.org/software/hurd/hacking-guide/hhg.html#The-main-function
-    <braunr> and
-    <braunr>
-      http://www.gnu.org/software/hurd/gnumach-doc/Task-Special-Ports.html#Task-Special-Ports
-    <mjjc> yes, the second link was just what i was looking for, thanks
-    <braunr> the second is very general
-    <braunr> also, the first applies to translators only
-    <braunr> if you're looking for how to do it for a non-translator
-      application, the answer is probably somewhere in glibc
-    <braunr> _hurd_startup i'd guess
-
-
-# IRC, freenode, #hurd, 2013-06-15
-
-    <damo22> ive been reading a little about exokernels or unikernels, and i
-      was wondering if it might be relevant to the GNU/hurd design.  I'm not
-      too familiar with hurd terminology so forgive me.  what if every
-      privileged service was compiled as its own mini "kernel" that handled (a)
-      any hardware related to that service (b) any device nodes exposed by that
-      service etc...
-    <braunr> yes but not really that way
-    <damo22> under the current hurd model of the operating system, how would
-      you talk to hardware that required specific timings like sound hardware?
-    <braunr> through mapped memory
-    <damo22> is there such a thing as an interrupt request in hurd?
-    <braunr> obviously
-    <damo22> ok
-    <damo22> is there any documentation i can read that involves a driver that
-      uses irqs for hurd?
-    <braunr> you can read the netdde code
-    <braunr> dde being another project, there may be documentation about it
-    <braunr> somewhere else
-    <braunr> i don't know where
-    <damo22> thanks
-    <damo22> i read a little about dde, apparently it reuses existing code from
-      linux or bsd by reimplementing parts of the old kernel like an api or
-      something
-    <braunr> yes
-    <damo22> it must translate these system calls into ipc or something
-    <damo22> then mach handles it?
-    <braunr> exactly
-
-[[/system_call]].
-
-    <braunr> that's why i say it's not the exokernel way of doing things
-    <damo22> ok
-    <damo22> so does every low level hardware access go through mach?'
-    <braunr> yes
-    <braunr> well no
-    <braunr> interrupts do
-    <braunr> ports (on x86)
-    <braunr> everything else should be doable through mapped memory
-    <damo22> seems surprising that the code for it is so small
-    <braunr> 1/ why surprising ? and 2/ "so small" ?
-    <damo22> its like the core of the OS, and yet its tiny compared to say the
-      linux kernel
-    <braunr> it's a microkenrel
-    <braunr> well, rather an hybrid
-    <braunr> the size of the equivalent code in linux is about the same
-    <damo22> ok
-    <damo22> with the model that privileged instructions get moved to
-      userspace, how does one draw the line between what is OS and what is user
-      code
-    <braunr> privileged instructions remain in the kernel
-    <braunr> that's one of the few responsibilities of the kernel
-    <damo22> i see, so it is an illusion that the user has privilege in a sense
-    <braunr> hum no
-    <braunr> or, define "illusion"
-    <damo22> well the user can suddenly do things never imaginable in linux
-    <damo22> that would have required sudo
-    <braunr> yes
-    <braunr> well, they're not unimaginable on linux
-    <braunr> it's just not how it's meant to work
-    <damo22> :)
-    <braunr> and why things like fuse are so slow
-    <braunr> i still don't get "i see, so it is an illusion that the user has
-      privilege in a sense"
-    <damo22> because the user doesnt actually have the elevated privilege its
-      the server thing (translator)?
-    <braunr> it does
-    <braunr> not at the hardware level, but at the system level
-    <braunr> not being able to do it directly doesn't mean you can't do it
-    <damo22> right
-    <braunr> it means you need indirections
-    <braunr> that's what the kernel provides
-    <damo22> so the user cant do stuff like outb 0x13, 0x1
-    <braunr> he can
-    <braunr> he also can on linux
-    <damo22> oh
-    <braunr> that's an x86 specifity though
-    <damo22> but the user would need hardware privilege to do that
-    <braunr> no
-    <damo22> or some kind of privilege
-    <braunr> there is a permission bitmap in the TSS that allows userspace to
-      directly access some ports
-    <braunr> but that's really x86 specific, again
-    <damo22> i was using it as an example
-    <damo22> i mean you wouldnt want userspace to directly access everything
-    <braunr> yes
-    <braunr> the only problem with that is dma reall
-    <braunr> y
-    <braunr> because dma usually access physical memory directly
-    <damo22> are you saying its good to let userspace access everything minus
-      dma?
-    <braunr> otherwise you can just centralize permissions in one place (the
-      kernel or an I/O server for example)
-    <braunr> no
-    <braunr> you don't let userspace access everything
-    <damo22> ah
-    <damo22> yes
-    <braunr> userspace asks for permission to access one specific part (a
-      memory range through mapping)
-    <braunr> and can't access the rest (except through dma)
-    <damo22> except through dma??  doesnt that pose a large security threat?
-    <braunr> no
-    <braunr> you don't give away dma access to anyone
-    <braunr> only drivers
-    <damo22> ahh
-    <braunr> and drivers are normally privileged applications anyway
-    <damo22> so a driver runs in userspace?
-    <braunr> so the only effect is that bugs can affect other address spaces
-      indirectly
-    <braunr> netdde does
-    <damo22> interesting
-    <braunr> and they all should but that's not the case for historical reasons
-    <damo22> i want to port ALSA to hurd userspace :D
-    <braunr> that's not so simple unfortunately
-    <braunr> one of the reasons it's hard is that pci access needs arbitration
-    <braunr> and we don't have that yet
-    <damo22> i imagine that would be difficult
-    <braunr> yes
-    <braunr> also we're not sure we want alsa
-    <braunr> alsa drivers, maybe, but probably not the interface itself
-    <damo22> its tangled spaghetti
-    <damo22> but the guy who wrote JACK for audio hates OSS, and believes it is
-      rubbish due to the fact it tries to read and write to a pcm device node
-      like a filesystem with no care for timing
-    <braunr> i don't know audio well enough to tell you anything about that
-    <braunr> was that about oss3 or oss4 ?
-    <braunr> also, the hurd isn't a real time system
-    <braunr> so we don't really care about timings
-    <braunr> but with "good enough" latencies, it shouldn't be a problem
-    <damo22> but if the audio doesnt reach the sound card in time, you will get
-      a crackle or a pop or a pause in the signal
-    <braunr> yep
-    <braunr> it happens on linux too when the system gets some load
-    <damo22> some users find this unnacceptable
-    <braunr> some users want real time systems
-    <braunr> using soft real time is usually plenty enough to "solve" this kind
-      of problems
-    <damo22> will hurd ever be a real time system?
-    <braunr> no idea
-    <youpi> if somebody works on it why not
-    <youpi> it's the same as linux
-    <braunr> it should certainly be simpler than on linux though
-    <damo22> hmm
-    <braunr> microkernels are well suited for real time because of the well
-      defined interfaces they provide and the small amount of code running in
-      kernel
-    <damo22> that sounds promising
-    <braunr> you usually need to add priority inheritance and take care of just
-      a few corner cases and that's all
-    <braunr> but as youpi said, it still requires work
-    <braunr> and nobody's working on it
-    <braunr> you may want to check l4 fiasco.oc though
-
-
-# System Personality
-
-## IRC, freenode, #hurd, 2013-07-29
-
-    <teythoon> over the past few days I gained a new understanding of the Hurd
-    <braunr> teythoon: really ? :)
-    <tschwinge> teythoon: That it's a complex and distributed system?  ;-)
-    <tschwinge> And at the same time a really simple one?
-    <tschwinge> ;-D
-    <teythoon> it's just a bunch of mach programs and some do communicate and
-      behave in a way a posix system would, but that is more a convention than
-      anything else
-    <teythoon> tschwinge: yes, kind of simple and complex :)
-    <braunr> the right terminology is "system personality"
-    <braunr> 11:03 < teythoon> over the past few days I gained a new
-      understanding of the Hurd
-    <braunr> teythoon: still no answer on that :)
-    <teythoon> braunr: ah, I spent lot's of time with the core servers and
-      early bootstrapping and now I gained the feeling that I've seen the Hurd
-      for what it really is for the first time
-
-
-# RPC Interfaces
-
-## IRC, freenode, #hurd, 2013-09-03
-
-    <rekado> I'm a little confused by the hurd and incubator git repos.
-    <rekado> DDE is only found in the dde branch in incubator, but not in the
-      hurd repo.
-    <rekado> Does this mean that DDE is not ready for master yet?
-    <braunr> yes
-    <rekado> If DDE is not yet used in the hurd (except in the dde branch in
-      the incubator repo), does pfinet use some custom glue code to use the
-      Linux drivers?
-    <braunr> this has nothing to do with pfinet
-    <braunr> pfinet is the networking stack, netdde are the networking drivers
-    <braunr> the interface between them doesn't change, whether drivers are in
-      kernel or not
-    <rekado> I see
-
-
-# IRC, freenode, #hurd, 2013-09-20
-
-    <giuscri> HI there, I have no previous knowledge about OS's. I'm trying to
-      undestand the structure of the Hurd and the comparison between, say,
-      Linux way of managing stuff ...
-    <giuscri> for instance, I read: "Unlike other popular kernel software, the
-      Hurd has an object-oriented structure that allows it to evolve without
-      compromising its design."
-    <giuscri> that means that while for adding feature to the Linux-kernel you
-      have to add some stuff `inside` a procedure, whilst in the Hurd kernel
-      you can just, in principle at least, add an object and making the kernel
-      using it?...
-    <giuscri> Am I making stuff too simple?
-    <giuscri> Thanks
-    <braunr> not exactly
-    <braunr> unix historically has a "file-oriented" structure
-    <braunr> the hurd allows servers to implement whatever type they want,
-      through the ability to create custom interfaces
-    <braunr> custom interfaces means custom calls, custom semantics, custom
-      methods on objects
-    <braunr> you're not restricted to the set of file interfaces (open, seek,
-      read, write, select, close, etc..) that unix normally provides
-    <giuscri> braunr: uhm ...some example?
-    <braunr> see processes for example
-    <braunr> see
-      http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/tree/HEAD:/hurd
-    <braunr> this is the collection of interfaces the hurd provides
-    <braunr> most of them map to unix calls, because gnu aims at posix
-      compatibility too
-    <braunr> some are internal, like processes
-    <braunr> or authentication
-    <braunr> but most importantly, you're not restricted to that, you can add
-      your own interfaces
-    <braunr> on a unix, you'd need new system calls
-    <braunr> or worse, extending through the catch-all ioctl call
-    <giuscri> braunr: mhn ...sorry, not getting that.
-    <braunr> what part ?
-    <kilobug> ioctl has become such a mess :s
-    <giuscri> braunr: when you say that Unix is `file-oriented` you're
-      referring to the fact that sending/receiving data to/from the kernel is
-      designed like sending/receiving data to/from a file ...?
-    <braunr> not merely sending/receiving
-    <braunr> note how formatted your way of thinking is
-    <braunr> you directly think in terms of sending/receiving (i.e. read and
-      write)
-    <giuscri> braunr: (yes)
-    <braunr> that's why unix is file oriented, access to objects is done that
-      way
-    <braunr> on the hurd, the file interface is one interface
-    <braunr> there is nothing preventing you from implementing services with a
-      different interface
-    <braunr> as a real world example, people interested in low latency
-      profesionnal audio usually dislike send/recv
-    <braunr> see
-      http://lac.linuxaudio.org/2003/zkm/slides/paul_davis-jack/unix.html for
-      example
-    <kilobug> braunr: how big and messy ioctl has become is a good proof that
-      the Unix way, while powerful, does have its limits
-    <braunr> giuscri: keep in mind the main goal of the hurd is extensibility
-      without special privileges
-    <giuscri> braunr: privileges?
-    <braunr> root
-    <giuscri> braunr: what's wrong with privileges?
-    <braunr> they allow malicious/buggy stuff to happne
-    <braunr> and have dramatic effects
-    <giuscri> braunr: you're obviously *not* referring to the fact that once
-      one have the root privileges could change some critical-data
-    <giuscri> ?
-    <braunr> i'm referring to why privilege separation exists in the first
-      place
-    <braunr> if you have unprivileged users, that's because you don't want them
-      to mess things up
-    <braunr> on unix, extending the system requires privileges, giving those
-      who do it the ability to destroy everything
-    <giuscri> braunr: yes, I think the same
-    <braunr> the hurd is designed to allow unprivileged users to extend their
-      part of the system, and to some extent share that with other users
-    <braunr> although work still remains to completely achieve that
-    <giuscri> braunr: mhn ...that's the `server`-layer between the
-      single-application and kernel ?
-    <braunr> the multi-server based approach not only allows that, but
-      mitigates damage even when privileged servers misbehave
-    <braunr> one aspect of it yes
-    <braunr> but as i was just saying, even root servers can't mess things too
-      much
-    <braunr> for example, our old (sometimes buggy) networking stack can be
-      restarted when it behaves wrong
-    <braunr> the only side effect being some applications (ssh and exim come to
-      mind) which need to be restarted too because they don't expect the
-      network stack to be restarted
-    <giuscri> braunr: ...instead?
-    <braunr> ?
-    <kilobug> giuscri: on Linux, if the network stack crash/freezes, you don't
-      have any other option than rebooting the system - usually with a nice
-      "kernel pani"
-    <kilobug> giuscri: and you may even get filesystem corruption "for free" in
-      the bundle
-    <braunr> and hoping it didn't corrupt something important like file system
-      caches before being flushed
-    <giuscri> kilobug, braunr : mhn, ook
-
-
-# IRC, freenode, #hurd, 2013-10-13
-
-    <ahungry> ahh, ^c isn't working to cancel a ping - is there alternative?
-    <braunr> ahungry: ctrl-c does work, you just missed something somewhere and
-      are running a shell directly on a console, without a terminal to handle
-      signals
-
-
-# IRC, freenode, #hurd, 2013-11-04
-
-    <braunr> nalaginrut: you can't use the hurd for real embedded stuff without
-      a lot of work on it
-    <braunr> but the hurd design applies very well to embedded environments
-    <braunr> the fact that we're able to dynamically link practically all hurd
-      servers against the c library can visibly reduce the system code size 
-    <braunr> it also reduces the TCB
-    <nalaginrut> what about the memory occupation? 
-    <braunr> code size is about memory occupation
-    <teythoon> also, the system is composable like lego, don't need tcp - don't
-      include pfinet then
-    <braunr> the memory overheald of a capability based system like the hurd
-      are, well, capabilities
-    <braunr> teythoon: that's not an argument compared to modular kernels like
-      linux
-    <teythoon> yes it is
-    <braunr> why ?
-    <braunr> if you don't need tcp in linux, you just don't load it
-    <braunr> same thing
-    <teythoon> ok, right
-    <braunr> on the other hand, a traditional unix kernel can never be linked
-      against the c library
-    <braunr> much less dynamically
-    <teythoon> right
-    <nalaginrut> I think the point is that it's easy to cut, since it has
-      better modularity than monolithic, and could be done in userland relative
-      easier
-    <braunr> modularity isn't better
-    <braunr> that's a big misconception
-    <teythoon> also, restarting components is easier on a distributed system
-    <braunr> on the hurd, this is a side effect
-    <braunr> and it doesn't apply well
-    <nalaginrut> braunr:  oops, misconception
-    <braunr> many core servers such as proc, auth, exec, the root fs server
-      can't be restarted at all
-    <teythoon> not yet
-    <braunr> and servers like pfinet can be restarted, but at the cost of posix
-      servers not expecting that
-    <braunr> looping on errors such as EBADF because the target socket doesn't
-      exist any more
-    <teythoon> I've been working on a restartable exec server during some of my
-      gsoc weekends
-    <braunr> ah right
-    <braunr> linux has kexec
-    <braunr> and can be patched at run time
-    <nalaginrut> sounds like Hurd needs something similar to generalizable
-      continuation
-    <braunr> so again, it's not a real advantage
-    <braunr> no
-    <nalaginrut> sorry serilizable
-    <braunr> that would persistence
-    <braunr> personally, i don't want it at all
-    <teythoon> yes it is a real advantage, b/c the means of communication
-      (ports) is common to every IPC method on Hurd, and ports are first class
-      objects
-    <teythoon> so preserving the state is much easier on Hurd
-    <braunr> if a monolithic kernel can do it too, it's not a real advantage
-    <teythoon> yes, but it is more work
-    <braunr> that is one true advantage of the hurd
-    <braunr> but don't reuse it each time
-    <nalaginrut> oh, that's nice for the ports
-    <teythoon> why not?
-    <braunr> what we're talking about here is resilience
-    <braunr> the fact that it's easier to implement doesn't mean the hurd is
-      better because it has resilience
-    <braunr> it simply means the hurd is better because it's easier to
-      implement things on it
-    <braunr> same for development in general
-    <braunr> debugging
-    <braunr> virtualization
-    <braunr> etc..
-    <nalaginrut> yes, but why we stick to compare it to monolithic
-    <braunr> but it's still *one* property
-    <teythoon> well, minix advertises this feature a lot, even if minix can
-      only restart very simple things like printer servers
-    <braunr> minix sucks
-    <braunr> let them advertise what they can
-    <teythoon> ^^
-    <nalaginrut> it has cool features, that's enough, no need to find a feature
-      that monolithic can never done
-    <braunr> no it's not enough
-    <braunr> minix isn't a general purpose system
-    <braunr> let's just not compare it to general purpose systems
-
-
-# IRC, freenode, #hurd, 2013-11-08
-
-    <teythoon> and, provided you have suitable language bindings, you can
-      replace almost any hurd server with your own implementation in any
-      language
-    <crocket> teythoon: language bindings?
-    <crocket> Do you mean language bindings against C libraries?
-    <teythoon> either that or for the low level mach primitives
-    <crocket> For your information, IPC is independent of languages.
-    <teythoon> sure, that's the beauty
-    <crocket> Why is hurd best for replacing parts written in C with other
-      languages?
-    <teythoon> because Hurd consists of many servers, each server managing one
-      kind of resource
-    <teythoon> so you have /hurd/proc managing posix processes
-    <teythoon> you could reimplement /hurd/proc in say python or go, and
-      replace just that component of the Hurd system
-    <teythoon> you cannot do this with any other (general purpose) operating
-      system that I know of
-    <teythoon> you could incrementally replace the Hurd with your own
-      Hurd-compatible set of servers written in X
-    <teythoon> use a language that you can verify, i.e. prove that a certain
-      specification is fulfilled, and you end up with an awesome stable and
-      secure operating system
-    <crocket> Any microkernel OS fits the description.
-    <crocket> teythoon, Does hurd have formal protocols for IPC communications?
-    <teythoon> sure, name some other general purpose and somewhat
-      posix-compatible microkernel based operating system please
-    <teythoon> what do you mean by formal protocols ?
-    <crocket> IPC communications need to be defined in documents.
-    <teythoon> the "wire" format is specified of course, the semantic not so
-      much
-    <crocket> network protocols exist.
-    <crocket> HTTP is a transport protocol.
-    <crocket> Without formal protocols, IPC communications suffer from
-      debugging difficulties.
-    <crocket> Formal protocols make it possible to develop and test each module
-      independently.
-    <teythoon> as I said, the wire format is specified, the semantics only in
-      written form in the source
-    <teythoon> this is an example of the ipc specification for the proc server
-      http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/hurd/process.defs
-    <crocket> teythoon, how file server interacts with file clients should be
-      defined as a formal protocol, too.
-    <teythoon> do you consider the ipc description a kind of formal protocol ?
-    <crocket>
-      http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/hurd/process.defs can
-      be considered as a formal protocol.
-    <crocket> However, the file server protocol should be defined on top of IPC
-      protocol.
-    <teythoon> the file server protocol is in fs.defs
-    <teythoon> every protocol spoken is defined in that ipc description
-      language
-    <teythoon> it is used to derive code from
-    <braunr> crocket: not any system can be used to implement system services
-      in any language
-    <braunr> in theory, they do, but in theory only
-    <braunr> the main reason they don't is because most aren't posix compliant
-      from the ground up
-    <braunr> posix compliance is achieved through virtualization
-    <braunr> which isolates services too much for them to get useful,
-      notwithstanding the impacts on performance, memory, etc..
-    <crocket> braunr, Do you mean it's difficult to achieve POSIX compliance
-      with haskell?
-    <braunr> crocket: i mean most l4 based systems aren't posix
-    <braunr> genode isn't posix
-    <braunr> helenos is by design not posix
-    <braunr> the hurd is the only multi server system providing such a good
-      level of posix conformance
-    <braunr> and with tls on the way, we'll support even more non-posix
-      applications that are nonetheless very common on unices because of
-      historical interfaces still present, such as mcontext
-    <braunr> and modern ones
-    <braunr> e.g. ruby is now working, go should be there after tls
-    * teythoon drools over the perspective of having go on the Hurd...
-    <crocket> braunr, Is posix relevant now?
-    <braunr> it's hugely relevant
-    <braunr> conforming to posix and some native unix interfaces is the only
-      way to reuse a lot of existing production applications
-    <braunr> and for the matter at hand (system services not written in c), it
-      means almost readily getting runtimes for other languages than c
-    <braunr> something other microkernel based system will not have
-    <braunr> imagine this
-    <braunr> one day, one of us could create a company for a hurd-like system,
-      presenting this idea as the killer feature
-    <braunr> by supporting posix, customers could port their software with very
-      little effort
-    <braunr> *very little effort* is what makes software attractive
-    <crocket>
-      http://stackoverflow.com/questions/1806585/why-is-linux-called-a-monolithic-kernel/1806597#1806597
-      says "The disadvantage to a microkernel is that asynchronous IPC
-      messaging can become very difficult to debug, especially if fibrils are
-      implemented."
-    <crocket> " GNU Hurd suffers from these debugging problems (reference)."
-    <braunr> stackoverflow is usually a nice place
-    <braunr> but concerning microkernel stuff, you'll read a lot of crap
-      anywhere
-    <braunr> whether it's sync or async, tracking references is a hard task
-    <braunr> it's a bit more difficult in distributed systems, but not that
-      much if the proper debugging features are provided
-    <braunr> we actually don't suffer from that too much
-    <braunr> many of us have been able to debug reference leaks in the past,
-      without too much trouble
-    <braunr> we lack some tools that would give us a better view of the system
-      state
-    <crocket> braunr, But is it more difficult with microkernel?
-    <braunr> crocket: it's more difficult with distributed systems
-    <crocket> How much more difficult?
-    <braunr> i don't know
-    <crocket> distributed systems
-    <braunr> not much
-    <crocket> braunr, How do you define distributed systems?
-    <braunr> crocket: not monolithic
-    <crocket> braunr, Hurd is distributed, then.
-    <braunr> multiserver if you prefer
-    <braunr> yes it is
-    <crocket> braunr, So it is more difficult with hurd.
-    <crocket> How much more difficult? How do you debug?
-    <braunr> just keep in mind that a monolithic system can run on a
-      microkenrel
-    <braunr> we use tools that show us references
-    <crocket> braunr, like?
-    <braunr> like portinfo
-    <crocket> braunr, Does hurd use unix-socket to implement IPC?
-    <braunr> no
-    <braunr> unix-socket use mach ipc
-    <crocket> I'm confused
-    <braunr> ipc is provided by the microkernel, gnumach (a variant of mach)
-    <braunr> unix sockets are provided by one of the hurd servers (pflocal)
-    <braunr> servers and clients communicate through mach ipc
-    <crocket> braunr, Do you think it's feasible to build servers in haskell?
-    <braunr> why not ?
-    <crocket> ok
-    <teythoon> I've been thinking about that
-    <teythoon> in go, with cgo, you can call go functions from c code
-    <teythoon> so it should be possible to create bindings for say libtrivfs
-    <crocket> I'd like to write an OS in clojure or haskell.
-    <braunr> crocket: what for ?
-    <crocket> braunr, I want to see a better system programming language than
-      C.
-    <braunr> i don't see how clojure or haskell would be "better system
-      programming languages" than c
-    <braunr> and even assuming that, what for ?
-    <crocket> braunr, It's better for programmers.
-    <crocket> haskell
-    <crocket> haskell is expressive.
-    <braunr> personally i disagree
-    <braunr> it's better for some things
-    <braunr> not for system programming
-    <gnufreex> For system programming, Google Go is trying to replace C.  But I
-      doubt it will.
-    <braunr> we may not be referring to the same thing here when we say "system
-      programming"
-    <crocket> braunr, What do you think is a better one?
-    <braunr> crocket: i don't think there is a better one currently
-    <crocket> braunr, Even Rust and D?
-    <braunr> i don't know them well enough
-    <braunr> certainly not D if it's what i think it is
-    <crocket> C is too slow.
-    <crocket> C is too slow to develop.
-    <braunr> depends
-    <braunr> again, i disagree
-    <braunr> rust looks good but i don't know it well to comment
-    <crocket> C is a tank, and clojure is an airplane.
-    <crocket> A tank is reliable but slow.
-    <crocket> Clojure is fast but lacks some accuracy.
-    <braunr> c is as reliable as the developer is skilled with it
-    <braunr> it's clearly not a tank
-    <braunr> there are many traps
-    <gnufreex> crocket: are you suggesting to rewrite Hurd in Clojure?
-    <crocket> no
-    <crocket> Why rewrite hud?
-    <crocket> hurd
-    <crocket> I'd rather start from scratch.
-    <braunr> which is what a rewrite is
-    <gnufreex> I am not expert on Clojure, but I don't think it is made for
-      system programming.
-    <gnufreex> If you want alternate language, I thing Go is only  serious
-      candidate other than C
-    <crocket> Or Rust
-    <crocket> However, some people wrote OSes in haskell.
-    <braunr> again, why ?
-    <braunr> if it's only for the sake of using another language, i think it's
-      bad reason
-    <crocket> Because haskell provides a high level of abstraction that helps
-      programmers.
-    <crocket> It is more secure with monads.
-    <gnufreex> If you want your OS to become successful Free Software project,
-      you have to use popular language. Haskell is not. 
-    <gnufreex> Most Haskell programmers are not into kernels
-    <gnufreex> They do high level stuff.
-    <gnufreex> So little contributors.
-    <braunr> crocket: so you aim at security ?
-    <gnufreex> I mean, candidats for contribution
-    <crocket> braunr, security and higher abstraction.
-    <braunr> i don't understand higher abstraction
-    <crocket> braunr, FP can be useful to systems.
-    <braunr> FP ?
-    <neal> functional programming
-    <braunr> right
-    <braunr> but you can abstract a lot with c too, with more efforts
-    <crocket> braunr, like that's easy.
-    <braunr> it's not that hard
-    <braunr> i'm just questioning the goals and the solution of using a
-      particular language
-    <braunr> the reason c is still the preferred language for system
-      programming is because it provides control over how the hardware does
-      stuff
-    <braunr> which is very important for performance
-    <braunr> the hurd never took off because of bad performance
-    <braunr> performance doesn't mean doing things faster, it means being able
-      to do things or not, or doing things a new way
-    <braunr> so ok, great, you have your amazing file system written in
-      haskell, and you find out it doesn't scale at all beyond some threshold
-      of processors or memory
-    <crocket> braunr, L4 is fast.
-    <braunr> l4 is merely an architecture abstraction
-    <braunr> and it's not written in haskell :p
-    <braunr> don't assume anything running on top of something fast will be
-      fast
-    <crocket> Hurd is slow and written in C.
-    <braunr> yes
-    <braunr> not because of c though
-    <crocket> Becuase it's microkernel?
-    <braunr> because c wasn't used well enough to make the most of the hardware
-      in many places
-    <braunr> far too many places
-    <crocket> A microkernel can be as fast as a monolithic kernel according to
-      L4.
-    <braunr> no
-    <braunr> it can't
-    <braunr> it can for very specific cases
-    <braunr> almost none of which are real world
-    <braunr> but that's not the problem
-    <braunr> again, i'm questioning your choice of another language in relation
-      to your goals, that's all
-    <braunr> c can do things you really can't do easily in other languages
-    <braunr> be aware of that
-    <crocket> braunr, "Monolithic kernel are faster than microkernel . while
-      The first microkernel Mach is 50% slower than Monolithic kernel while
-      later version like L4 only 2% or 4% slower than the Monolithic kernel ."
-    <braunr> 14:05 < braunr> but concerning microkernel stuff, you'll read a
-      lot of crap anywhere
-    <braunr> simple counterexample :
-    <braunr> the measurements you're giving consider a bare l4 kernel with
-      nothing on top of it
-    <braunr> doing thread-to-thread ipc
-    <braunr> this model of communication is hardly used in any real world
-      application
-    <braunr> one of the huge features people look for with microkernels are
-      capabilities
-    <braunr> and that alone will bump your 4% up
-    <braunr> since capabilities will be used for practically every ipc
-    <crocket> ok
-
-
-# Hurd From Scratch
-
-## IRC, freenode, #hurd, 2013-11-30
-
-    <hurdmaster> because I think there is no way to understand the whole pile,
-      you need to go step by step
-    <hurdmaster> for example, I'm starting with mach only, then adding one
-      server, then another and on each step I have working system
-    <hurdmaster> that's how I want to understand it
-    <teythoon> you are interested in the early bootstrapping of the hurd system
-      ?
-    <hurdmaster> now I'm starting debian gnu/mach, it hungs, show me black
-      screen and I have no idea how to fix it
-    <teythoon> if you are unable to fix this, why do you think you can build a
-      hurd system from scratch ?
-    <hurdmaster> not gnu/mach, gnu/hurd I mean
-    <teythoon> or, you could describe your problem in more detail and one of
-      the nice people around here might help you ;)
-    <hurdmaster> as I said, it will be easier to understand and fix bugs, if I
-      will go step by step, and I will be able to see where bugs appears
-    <hurdmaster> so you should help me with that 
-    <teythoon> and I tend to disagree
-    <teythoon> but you could always read my blog. you'll learn lots of things
-      about bootstrapping a hurd system
-    <teythoon> but it's complicated
-    <hurdmaster> http://www.linuxfromscratch.org/
-    <teythoon> also, you'll need at least four hurd servers before you'll
-      actually see much
-    <teythoon> five
-    <teythoon> yeah, i know lfs
-    <hurdmaster> if somebody is interested in creating such a project, let me
-      know
-    <teythoon> you seem to be interested
-    <hurdmaster> yes, but I need the a real hurd master to help me
-    <teythoon> become one. fix your system and get to know it
-    <hurdmaster> I need knowledge, somebody built the system but didn't write
-      documentation about it, I have to extract it from your heads
-    <teythoon> hurdmaster: extract something from here
-      http://teythoon.cryptobitch.de
-    <teythoon> I need my head ;)
-    <hurdmaster> thanks
-    <hurdmaster> okay, what's the smallest thing I can run?
-    <teythoon> life of a Hurd system starts with the root filesystem, and the
-      exec server is loaded but not started
-    <teythoon> you could get rid of the exec server and replace the root
-      filesystem with your own program
-    <teythoon> statically linked, uses no unix stuff, only mach stuff
-    <hurdmaster> can I get 'hello world' on pure mach?
-    <teythoon> you could
-    <teythoon> hurdmaster: actually, here it is:
-      http://darnassus.sceen.net/gitweb/rbraun/mach_print.git/
-    <teythoon> compile it statically, put it somewhere in /boot
-    <teythoon> make sure you're running a debug kernel
-    <teythoon> load it from grub instead of /hurd/ext2fs.static
-    <teythoon> look at the grub config for how this is done
-    <teythoon> let me know if it worked ;)
-
-
-# IRC, freenode, #hurd, 2014-03-04
-
-    <bwright> Can I run a single instance of hurd on multiple computers
-    <bwright> With them acting as different servers?
-    <braunr> no
-    <bwright> Like the fs server on one pc etc.
-    <bwright> Which os could I do this with?
-    <bwright> I assumed Mach RPC would support that.
-    <braunr> it can
-    <braunr> but we don't use it that way
-    <braunr> plan9 is probably better suited to what you want
-    <braunr> inferno too
-    <braunr> maybe dragonflybsd
-    <bwright> Yep.
-    <bwright> irAwesome.
-    <bwright> Plan9 is exactly it.
-    <braunr> enjoy
-
-
-# IRC, freenode, #hurd, 2014-03-11
-
-    <ltx> Does anyone have a distributed OS over GNU/hurd project running?
-    <ltx> (GNU/hurd has many of the utilities to make this easy, but it still
-      requires some more utilities for transparent computation)
-    <braunr> not at the moment, no
-    <braunr> and i consider our ipc inappropriate if you want system able to
-      run over heterogeneous hardware
-    <braunr> or rather, our RPCs
-    <ltx> I haven't spent the time, this is speculative (in the worse "let's do
-      everything magically!" way.)
-    <ltx> Just wondering if this exists outside of plan9 (which is limited in
-      some ways.)
-    <braunr> dragonflybsd had plans for a SSI
-    <braunr> there are ancient research systems that actually did the job
-    <braunr> such as amoeba
-    <braunr> here at the hurd, we just don't have the manpower, and the people
-      spending time on the project have other interests
-    <ltx> Yeah, that seems like a large problem.
-    <ltx> GNU/hurd is self hosting (in the "I like working on it" way), yes?
-    <ltx> I've done some work on it, but don't really know how nice it is.
-    <braunr> yes it is
-    <ltx> Working from a microkernel to add pseudo-SSI features to a bunch of
-      servers seems like a much more trivial task than, say, modifying TLK.
-    <braunr> posix conformance and stability are good enough that more than 70%
-      of debian packages build and most of them work fine
-    <braunr> tlk the linux kernel ?
-    <ltx> Yes.
-    <braunr> first time i see this acronym :)
-    <braunr> and yes i agree, a microkernel is much much more suited for that
-    <braunr> but then, i consider a microkernel better suited for practically
-      everything ... :)
-    <ltx> :)
-    <ltx> I'm wondering how to mix SSI with network-awareness.
-    <braunr> mach used to have a network server
-    <braunr> which would merely act as a proxy for capabilities
-    <braunr> network drivers were in kernel though
-    <ltx> That's the simple way of sharing the sources.
-    <ltx> I'm wondering how we can make a software stack that's network aware;
-      completely transparent SSI can lead to inefficiencies in userspace, as it
-      may do things the kernels won't expect. Having to deal with the network
-      through a network server is a headache.
-    <braunr> what kind of problems do you have in mind ?
-    <ltx> Still working on defining the problem. I think that's half the
-      problem.
-    <ltx> (For any problem.)
-    <ltx> Beyond that, it's just some coding ;)
-    <braunr> ok
-    <braunr> sounds interesting :)
-    <braunr> i'd love to see a modern SSI in action
-    <braunr> but that's really a secondary goal for me so glad to see someone
-      making this his primary goal
-    <braunr> doctoral thesis ?
-    <ltx> ... Undergrad who's been hacking away since grade school.
-    <braunr> heh :)
-    <ltx> 18 y/o sophomore at a respected technical college, dealing with
-      boredom :)
-    <braunr> well throroughly thinking about "defining the problem" is an
-      excellent reflex
-    <teythoon> :) stick around, the hurd is fun
-    <braunr> it does help fight boredom a lot indeed ...... )
-    <braunr> :)
-    <cluck> maybe it'd be possible to port the relevant features from plan9 now
-      that there is a gpl'ed version
-    <teythoon> either way, we'd need network-transparent mach messaging
-    <teythoon> which mach messaging could do, but gnumach does not implement
-      this currently
-    <cluck> teythoon: afaiui if there was a proper 9fs2000 hurd server the rest
-      could be hidden behind the curtains 
-    <teythoon> ah, well, that sounds like a 9p network filesystem translator
-    <cluck> teythoon: also iirc plan9 uses libmach for some things so i suppose
-      a port wouldn't be completely impossible
-    <teythoon> given that in plan9 everything is a file, that might be enough
-      to use plan9 services
-    <cluck> teythoon: yes, it'd be the easiest route (at least initially) i
-      believe
-    <teythoon> careful, lots of stuff is named mach-something
-    <cluck> bloody ernest mach and his damned famous-ness-ish
-    <cluck> =)
-    <teythoon> :D
diff --git a/open_issues/arm_port.mdwn b/open_issues/arm_port.mdwn
deleted file mode 100644
index 26e0b770..00000000
--- a/open_issues/arm_port.mdwn
+++ /dev/null
@@ -1,267 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-Several people have expressed interested in a port of GNU/Hurd for the ARM
-architecture.
-
-
-# IRC, freenode, #hurd, 2012-07-28
-
-    <mcsim> Has anyone heard about porting hurd and gnu/mach to arm
-      architecture?
-    <braunr> mcsim: i think so
-    <braunr> mcsim: why are you asking ?
-    <mcsim> I found an article where author stated that he has ported hurd to
-      arm, but I have never met this information before.
-    <mcsim> He wrote ethernet driver and managed to use ping command
-    <mcsim> author's name is Sartakov Vasily
-    <braunr> well that's possible, a long time ago
-    <braunr> and it was probably not complete enough to be merged upstream
-    <braunr> like many other attempts at many other things
-    <mcsim> Not so long. Article is dated by June 2011.
-    <braunr> do you have a link ?
-    <mcsim> Yes, but it is in Russian.
-    <braunr> oh
-    <braunr> well i don't remember him sharing that with us
-    <antrik> mcsim: he did some work on porting Mach, but AIUI never got it
-      nearly finished
-    <antrik> nowadays he does L4 stuff
-    <antrik> was also at FOSDEM
-
-
-## IRC, freenode, #hurd, 2012-10-09
-
-    <mcsim> bootinfdsds: There was an unfinished port to arm, if you're
-      interested.
-    <tschwinge> mcsim: Has that ever been published?
-    <mcsim> tschwinge: I don't think so. But I have an email of that person and
-      I think that this could be discussed with him.
-
-
-## IRC, freenode, #hurd, 2012-10-10
-
-    <tschwinge> mcsim: If you have a contact to the ARM porter, could you
-      please ask him to post what he has?
-    <antrik> tschwinge: we all have the "contact" -- let me remind you that he
-      posted his questions to the list...
-
-
-## IRC, freenode, #hurd, 2012-10-17
-
-    <mcsim> tschwinge: Hello. The person who I wrote regarding arm port of
-      gnumach still hasn't answered. And I don't think that he is going to
-      answer.
-
-
-# IRC, freenode, #hurd, 2012-11-15
-
-    <matty3269> Well, I have a big interest in the ARM architecture, I worked
-      at ARM for a bit too, and I've written my own little OS that runs on
-      qemu. Is there an interest in getting hurd running on ARM?
-    <braunr> matty3269: not really currently
-    <braunr> but if that's what you want to do, sure
-    <tschwinge> matty3269: Well, interest -- sure!, but we don't really have
-      people savvy in low-level kernel implementation on ARM.  I do know some
-      bits about it, but more about the instruction set than about its memory
-      architecture, for example.
-    <tschwinge> matty3269: But if you're feeling adventurous, by all means work
-      on it, and we'll try to help as we can.
-    <tschwinge> matty3269: There has been one previous attempt for an ARM port,
-      but that person never published his code, and apparently moved to a
-      different project.
-    <tschwinge> matty3269: I can help with toolchains (GCC, etc.) things for
-      ARM, if there's need.
-    <matty3269> tschwinge: That sounds great, thanks! Where would you recommend
-      I start (at the moment I've got Mach checked out and am trying to get it
-      compiled for i386)
-    <matty3269> I'm guessing that the Mach micro-kernel is all that would need
-      to be ported or are there arch-dependant bits of code in the server
-      processes?
-    <tschwinge> matty3269:
-      http://www.gnu.org/software/hurd/faq/system_port.html has some
-      information.  Mach is the biggest part, yes.  Then some bits in glibc and
-      libpthread, and even less in the Hurd libraries and servers.
-    <tschwinge> matty3269: Basically, you'd need equivalents for the i386 (and
-      similar) directories, yep.
-    <tschwinge> Though, you may be able to avoid some cruft in there.
-    <tschwinge> Does building for x86 have any issues?
-    <tschwinge> matty3269: How is generally your understanding of the Hurd on
-      Mach system architecture, and on microkernel-based systems generally, and
-      on Mach in particular?
-    <matty3269> tschwinge: yes, it seems to be progressing... I've got mig
-      installed and it's just compiling now
-    <matty3269> hmm, not too great if I'm honest, I've done mostly monolithic
-      kernel development so having such low-level processes, such as
-      scheduling, done in user-space seems a little strinage
-    <tschwinge> Ah, yes, MIG will need a little bit of porting, too.  I can
-      help with that, but that's not a priority -- first you have to get Mach
-      to boot at all; MIG will only be needed once you need to deal with RPCs,
-      so user-land/kernel interaction, basically.  Before, you can hack around
-      it.
-    <matty3269> tschwinge: I have been running a GNU/Hurd system for a while
-      now though
-    <tschwinge> I'm happy to tell you that the schedules is still in the
-      kernel.  ;-)
-    <tschwinge> OK, good, so you know about the basic ideas.
-    <braunr> matty3269: there has to be machine specific stuff in user space
-    <braunr> for initial thread contexts for example
-    <matty3269> tschwinge: Ok, just got gnumach built
-    <braunr> but there isn't much and you can easily base your work from the
-      x86 implementation
-    <tschwinge> Yes.  Mach itself is the more difficult one.
-    <matty3269> braunr: Yeah, looking around at things, it doesn't seem that
-      there will be too much work involoved in the user-space stuff
-    <tschwinge> braunr: Do you know off-hand whether there are some old Mach
-      research papers describing architecture ports?
-    <tschwinge> I know there are some describing the memory system (obviously),
-      and I/O system -- which may help matty3269 to understand the general
-      design/structure.
-    <tschwinge> We might want to identify some documents, and make a list.
-    <braunr> all mach related documentation i have is available here:
-      ftp://ftp.sceen.net/mach/
-    <braunr> (also through http://)
-    <tschwinge> matty3269: Oh, definitely I'd suggest the Mach 3 Kernel
-      Principles book.  That gives a good description of the Mach architecture.
-    <matty3269> Great, that's my weekends reading then!
-    <braunr> you don't need all that for a port
-    <matty3269> Is it possible to run the gnumach binary standalone with qemu?
-    <braunr> you won't go far with it
-    <braunr> you really need at least one program
-    <braunr> but sure, for a port development, it can easily be done
-    <braunr> i'd suggest writing a basic static application for your tests once
-      you reach an advanced state
-    <braunr> the critical parts of a port are memory and interrupts
-    <braunr> and memory can be particularly difficult to implement correctly
-    <tschwinge> matty3269: I once used QEMU's
-      virtual-FAT-filesystem-from-a-directory-on-the-host, and configured GRUB
-      to boot from that one, so it was easy to quickly reboot for kernel
-      development.
-    <braunr> but the good news is that almost every bsd system still uses a
-      similar interface
-    <tschwinge> matty3269: And, you may want to become familiar with QEMU's
-      built-in gdbserver, and how to connect to and use that.
-    <braunr> so, for example, you could base your work from the netbsd/arm pmap
-      module
-    <tschwinge> matty3269: I think that's better than starting on real
-      hardware.
-    <braunr> tschwinge: you can use -kernel with a multiboot binary now
-
-[[hurd/running/qemu#multiboot]].
-
-    <braunr> tschwinge: and even creating iso images is so fast it's not any
-      slower
-
-    <braunr> ah, the gnumach executable is a correct elf image
-    <matty3269> Is there particular reason that mach is linked at 0xc0100000?
-    <matty3269> or is that where it is expected to be in VM>
-    <tschwinge> That's my understanding.
-    <braunr> kernels commmonly sti at high addresses
-    <braunr> that's the "standard" 3G/1G split for user/kernel space
-    <matty3269> I think Linux sits at a similar VA for 32-bit
-    <braunr> no
-    <matty3269> Oh, I thought it did, I know it does on ARM, the kernel is
-      mapped to 0xc000000 
-    <braunr> i don't know arm, but are you sure about this number ?
-    <braunr> seems to lack a 0
-    <matty3269> Ah, yes sorry
-    <matty3269> so 0xC0000000
-    <braunr> 0xc0100000 is just 1 MiB above it
-    <braunr> the .text section of linux on x86 actually starts at c1000000
-      (above 16 MiB, certainly to preserve as much dma-able memory since modern
-      machines now have a lot more)
-    <matty3269> so with gnumach, does the boot-up sequence use PIC until VM is
-      active and the kernel mapped to the linking address?
-    <braunr> no
-    <braunr> actually i'm not certain of the details
-    <braunr> but there is no PIC
-    <braunr> either special sections are linked at physical addresses
-    <braunr> or it relies on the fact that all executable code uses near jumps
-    <braunr> and uses offsets when accessing data
-    <braunr> (which is why the kernel text is at 3 GiB + 1 MiB, and not 3 GiB)
-    <matty3269> hmm,
-    <braunr> but you shouldn't worry about that i suppose, as the protocol
-      between the boot loader and an arm kernel will certainly not be the saem
-    <braunr> same*
-    <matty3269> indeed, ARM is tricky because memory maps are vastly differnt
-      on every platform
-
-
-## IRC, freenode, #hurd, 2012-11-21
-
-    <matty3269> Well, I have a ARM gnumach kernel compiled. It just doesn't
-      run! :)
-    <braunr> matty3269: good luck :)
-
-
-# IRC, freenode, #hurd, 2013-01-30
-
-    <slpz> Hi, i've read there's an ongoing effort to port GNU Mach to ARM. How
-      is it going?
-    <braunr> not sure where you read that
-    <braunr> but i'm pretty sure it's not started if it exists
-    <slpz> braunr: http://www.gnu.org/software/hurd/open_issues/arm_port.html
-    <braunr> i confirm what i said
-    <slpz> braunr: OK, thanks. I'm interested on it, and didn't want to
-      duplicate efforts.
-    <braunr> little addition: it may have started, but we don't know about it
-
-
-# IRC, freenode, #hurd, 2013-09-18
-
-    <Hooligan0> as i understand ; on startup, vm_resident.c functions configure
-      the whole available memory ; but at this point the system does not split
-      space for kernel and space for future apps
-    <Hooligan0> when pages are tagged to be used by userspace ?
-    <braunr> Hooligan0: at page fault time
-    <braunr> the split is completely virtual, vm_resident deals with physical
-      memory only
-    <Hooligan0> braunr: do you think it's possible to change (at least)
-      pmap_steal_memory to mark somes pages as kernel-reserved ?
-    <braunr> why do you want to reserve memory ?
-    <braunr> and which memory ?
-    <Hooligan0> braunr: first because on my mmu i have two entry points ; so i
-      want to set kernel pages into a dedicated space that never change on
-      context switch (for best cache performance)
-    <Hooligan0> braunr: and second, because i want to use larger pages into
-      kernel (1MB) to reduce mmu work
-    <braunr> vm_resident isn't well suited for large pages :(
-    <braunr> i don't see the effect of context switch on kernel pages
-    <Hooligan0> at many times, context switch flush caches
-    <braunr> ah you want something like global pages on x86 ?
-    <Hooligan0> yes, something like
-    <braunr> how is it done on arm ?
-    <Hooligan0> virtual memory is split into two parts depending on msb bits
-    <Hooligan0> for example 3G/1G
-    <Hooligan0> MMU will use two pages tables depending on vaddr (hi-side or
-      low-side)
-    <braunr> hi is kernel, low is user ?
-    <Hooligan0> so, for the moment i've put mach at 0xC0000000 -> 0xFFFFFFFF  ;
-      and want to use 0x00000000 -> 0xBFFFFFFF for userspace
-    <Hooligan0> yes
-    <braunr> ok, that's what is done for x86 too
-    <Hooligan0> 1MB pages for kernel ; and 4kB (or 64kB) pages for apps
-    <braunr> i suggest you give up the large page stuff
-    <braunr> well, you can use them for the direct physical mapping, but for
-      kernel objects, it's a waste
-    <braunr> or you can rewrite vm_resident to use something like a buddy
-      allocator but it's additional work
-    <Hooligan0> for the moment it's waste ; but with some littles changes this
-      allow only one level of allocation mapping ;  -i think- it's better for
-      performances
-    <braunr> Hooligan0: it is, but not worth it
-    <Hooligan0> will you allow changes into vm_resident if i update i386 too ?
-    <braunr> Hooligan0: sure, as long as these are relevant and don't introduce
-      regressions
-    <Hooligan0> ok
-    <braunr> Hooligan0: i suggest you look at x15, since you may want to use it
-      as a template for your own changes
-    <braunr> as it was done for the slab allocator for example
-    <braunr> e.g. x15 already uses a buddy allocator for physical memory
diff --git a/open_issues/automatic_backtraces_when_assertions_hit.mdwn b/open_issues/automatic_backtraces_when_assertions_hit.mdwn
deleted file mode 100644
index df7294e9..00000000
--- a/open_issues/automatic_backtraces_when_assertions_hit.mdwn
+++ /dev/null
@@ -1,79 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2012 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]]
-
-
-# IRC, unknown channel, unknown date
-
-    <azeem> tschwinge: ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion `! __spin_lock_locked (&ss->critical_section_lock)' failed.
-    <youpi> it'd be great if we could have backtraces in such case
-    <youpi> at least just the function names
-    <youpi> and in this case (static), just addresses would be enough
-
-
-# IRC, freenode, #hurd, 2012-07-19
-
-In context of the [[ext2fs_libports_reference_counting_assertion]].
-
-    <braunr> pinotree: tschwinge: do you know if our packages are built with
-      -rdynamic ?
-    <pinotree> braunr: debian's cflags don't include it, so unless the upstream
-      build systems do, -rdynamic is not added
-    <braunr> i doubt glibc' backtrace() is able to find debugging symbol files
-      on its own
-    <pinotree> what do you mean?
-    <braunr> the port reference bug youpi noticed is rare
-    <pinotree> even on linux, a program compiled with normal optimizations (eg
-      -O2 -g) can give just pointer values in backtrace()'s output
-    <braunr> core dumps are unreliable at best
-
-[[crash_server]].
-
-    <braunr> uh, no, backtrace does give names
-    <braunr> but not with -fomit-frame-pointer
-    <braunr> unless the binary is built with -rdynamic
-    <braunr> at least it used to
-    <pinotree> not really, when being optimized some steps can be optimized
-      away (eg inlines)
-    <braunr> that's ok
-    <braunr> anyway, the point is i'd like a way that can give us as much
-      information as possible when the problem happens
-    <braunr> the stack trace being the most useful imo
-    <pinotree> do you face issues currently with backtrace()?
-    <braunr> not tried yet
-    <braunr> i guess i could make the application trap in the kernel, and fault
-      there, so we can attach gdb while still in the pager address space :>
-    <pinotree> that would imply the need for interactivity when the fault
-      happens, wouldn't it?
-    <braunr> no
-    <braunr> it would remain this way until someone comes, hours, days later
-    <braunr> pinotree: well ok, it would require interactivity, but not *when*
-      it happens ;p
-    <braunr> pinotree: right, it needs -rdynamic
-
-
-## IRC, freenode, #hurd, 2012-07-21
-
-    <braunr> tschwinge: my current "approach" is to introduce an infinite loop
-    <braunr> it makes the faulting task mapped in often enough to use gdb
-      through qemu
-    <braunr> ... :)
-    <tschwinge> My understanding is that glibc already does have some mechanism
-      for that: I have seen it print backtraces whendetecting malloc
-      inconsistencies (double free and the lite).
-    <braunr> yes, i thought it used the backtrace functions internally though
-    <braunr> that is, execinfo
-    <braunr> but this does require -rdynamic
-
-
-# GCC's libbacktrace
-
-Introduced in GCC commit ecd3459e7bb829202601e3274411135a15c64dde.
diff --git a/open_issues/automatically_checking_port_deallocation.mdwn b/open_issues/automatically_checking_port_deallocation.mdwn
deleted file mode 100644
index 6aeaf207..00000000
--- a/open_issues/automatically_checking_port_deallocation.mdwn
+++ /dev/null
@@ -1,32 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_gnumach]]
-
-IRC, unknown channel, unknown date.
-
-    <youpi> we really need something that is able to automatically check port deallocation
-    <youpi> at least for the trivial cases, for which we do have bugs I'm currently fixing...
-    <pochu> test suite? :)
-    <pochu> won't magically find them though, so not what you've asked for...
-    <youpi> test suites can trigger some of the bugs yes
-    <youpi> which is already a good thing
-    <youpi> of course the coverage can't be perfect
-    <youpi> one of the bugs I fixed happened only for setuid binaries for instance
-
-- - -
-
-portseal can automatically detect port leaks.  It is somewhat
-intrusive, as it leverages a source-transformation and hence requires
-a recompilation of the code that contains the port leak.  Currently,
-it is a prototype.  If you are looking for a port leak, I'd love you
-to try it though:
-
-[[http://darnassus.sceen.net/gitweb/teythoon/portseal.git]]
diff --git a/open_issues/bash.mdwn b/open_issues/bash.mdwn
deleted file mode 100644
index f6b14a08..00000000
--- a/open_issues/bash.mdwn
+++ /dev/null
@@ -1,59 +0,0 @@
-[[!meta copyright="Copyright © 2009, 2013 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_porting]]
-
-
-# *bash* 4.0 vs. typing `C-c` (*SIGINT*)
-
-Will show `-bash: echo: write error: (ipc/mig) wrong reply message ID` unter
-certain conditions.
-
-After having noticed that this error doesn't occur if starting *bash* with
-`--norc`, I isolated it to the following command in `.bashrc`:
-    
-    case $TERM in
-      xterm* | rxvt*)
-        PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}:${PWD}\007"';;
-    esac
-
-... and indeed:
-
-    tschwinge@flubber:~ $ echo "$TERM" -- "$PROMPT_COMMAND"
-    xterm -- echo -ne "\033]0;${USER}@${HOSTNAME}:${PWD}\007"
-    tschwinge@flubber:~ $ ^C
-    -bash: echo: write error: (ipc/mig) wrong reply message ID
-    tschwinge@flubber:~ $ PROMPT_COMMAND=
-    tschwinge@flubber:~ $ ^C
-    tschwinge@flubber:~ $ 
-
-    bash-4.0$ PROMPT_COMMAND='echo >&2 -n foo\ '
-    foo bash-4.0$ ^C
-
-    bash-4.0$ PROMPT_COMMAND='echo >&1 -n foo\ '
-    foo bash-4.0$ ^C
-    bash: echo: write error: (ipc/mig) wrong reply message ID
-
-    bash-4.0$ PROMPT_COMMAND='/bin/echo >&1 -n foo\ '
-    foo bash-4.0$ ^C
-    bash: start_pipeline: pgrp pipe: (ipc/mig) wrong reply message ID
-
-So, there's something different with stdout in / after the SIGINT handler.
-
-
-# IRC, freenode, #hurd, 2013-01-13
-
-Perhaps completely unrelated to the issue above, perhaps not.
-
-    <tschwinge> bash: xmalloc: ../../../bash/lib/sh/strtrans.c:60: cannot
-      allocate 261 bytes (323584 bytes allocated)
-    <tschwinge> 1.5 GiB RAM were free.
-    <tschwinge> This happened when I did a rever history search (C-r [...]),
-      and then pressed C-c.
diff --git a/open_issues/bash_busy-loop.mdwn b/open_issues/bash_busy-loop.mdwn
deleted file mode 100644
index 5228ba33..00000000
--- a/open_issues/bash_busy-loop.mdwn
+++ /dev/null
@@ -1,33 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-I've first seen this problem after having had the following command line run
-for a week, or two, or three:
-
-Start `screen`.  Find PID of pfinet.
-
-    $ while sleep 66; do echo "$(date)" " $(ps --no-header --format=hurd -p [PID])"; done | tee ps-pfinet
-
-Leave it running, detach from `screen`.
-
-Eventually, the main `bash` process will go bonkers and eat 100 % CPU time.
-Reproduced on four different systems.
-
-A faster way to reproduce this, again inside `screen`; every three seconds,
-write text in 10 MiB bursts to the terminal:
-
-    $ while sleep 3; do date > tmp/tmp && yes "$(date)" | dd bs=1M count=10; done
-
-This one only needs like ten hours, before `bash` starts its busy-loop, from
-which it can only be terminated with `SIGKILL`.  At this point, the `term`,
-`screen`, `fifo` processes also have used 40, 52, 25 minutes of CPU time,
-respectively, but appear to be still working fine.
-
-I did not yet start debugging this.
diff --git a/open_issues/bash_interrupted_system_call.mdwn b/open_issues/bash_interrupted_system_call.mdwn
deleted file mode 100644
index 9feab6ff..00000000
--- a/open_issues/bash_interrupted_system_call.mdwn
+++ /dev/null
@@ -1,19 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-IRC, unknown channel, unknown date.
-
-    <virtuoso015> i seem to be getting this message from the shell "-bash: /dev/fd/62: Interrupted system call"
-    <virtuoso015> is it significant ?
-    <youpi> I've seen this issue already yes
-    <youpi> it's not
-    <youpi> it's bash not handling EINTR properly
-    <antrik> youpi: so this is actually a bug in bash, not Hurd generating a bogus error?
-    <youpi> well, it's Hurd generating an error which bash doesn't expect to see
diff --git a/open_issues/bash_vs_screen_vs_sigint.mdwn b/open_issues/bash_vs_screen_vs_sigint.mdwn
deleted file mode 100644
index 9672041c..00000000
--- a/open_issues/bash_vs_screen_vs_sigint.mdwn
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!meta copyright="Copyright © 2009 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]]."]]"""]]
-
-  * [[bash]]
-  * [[screen]]
diff --git a/open_issues/benefits_of_a_native_hurd_implementation.mdwn b/open_issues/benefits_of_a_native_hurd_implementation.mdwn
deleted file mode 100644
index dfd41837..00000000
--- a/open_issues/benefits_of_a_native_hurd_implementation.mdwn
+++ /dev/null
@@ -1,139 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 2013 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_documentation]]
-
-What are the benefits of a native GNU/Hurd system, now that Linux et al. can do
-so much? Think [[hurd/translator]]s: FUSE, [[hurd/subhurd]]s: User-Mode-Linux
-and other virtualization techiques, and so on.
-
-It is possible to begin [[implementing_Hurd_on_top_of_another_system]], but...
-
-IRC, #hurd, August / September 2010
-
-    <marcusb> ArneBab: but Neal and I were not happy with that alone.  We were
-      looking for deeper improvements to the system, for, I think, sound
-      reasons.  That is what brought us to the L4/Coyotos technologies
-    <marcusb> ArneBab: as you are writing a kernel in user space, you can still
-      do kernel improvements there
-    <marcusb> ArneBab: if you take it very far, you end up with a kernel that
-      runs Linux in user space (just flip the two) for the drivers
-    <marcusb> ArneBab: that is what the L4 people did with the DDE
-
-[[/DDE]].
-
-    <marcusb> ArneBab: so, with these different cuts, there are different
-      opportunities. on the one end, you can run Linux as normal and get some
-      of the Hurd features such as translators in some programs.  At the other
-      end, you can do whatever you want and run some linux code for the drivers
-      or none at all.
-    <marcusb> ArneBab: one of the big questions then becomes: at which point
-      can the advantages offered by the Hurd be realized?
-    <marcusb> ArneBab: and that's not entirely clear to me
-    <marcusb> when I worked on this with Neal, we pushed further and further
-      into need-to-change-everything land
-    <marcusb> while the current efforts on the Hurd seem to be more equivalent
-      to the could-run-it-in-userspace-on-top-of-Linux camp
-    <ArneBab> marcusb: for that I think we need a way to move towards them step
-      by step. Would it be possible to get the advantages of better resource
-      allocation with a Viengoos in userspace, too?
-    <ArneBab> and when that is stable, just switch over?
-    <marcusb> ArneBab: I don't know.  I suspect these people will know before
-      us: http://lxc.sourceforge.net/
-    <ArneBab> something like implementing flip points: flip Linux with Hurd to
-      Hund with Linux. Flip Mach with L4 to L4 with Mach.
-    <ArneBab> lxc sounds interesting.
-    <marcusb> note that these efforts address security concerns more than other
-      concerns
-    <marcusb> so they will get isolation long before sharing is even considered
-    <marcusb> but some of the issues are the same
-    <marcusb> once you allow malware to do what it wants, it's a small step to
-      also allow the user to what he wants :)
-    <ArneBab> it kinda looks like hacking it where it doesn’t really fit again…
-    <ArneBab> there I ask myself when the point comes that doing a cleaner
-      design offsets the popularity
-    <ArneBab> they are pushing more and more stuff into userspace
-    <ArneBab> which is a good thing (to me)
-    <ArneBab> it’s hard to clearly describe how, but even though I like having
-      more stuff in userspace, the way it is bolted onto Linux doesn’t feel
-      good for me.
-    <ArneBab> FUSE is cool, but if I use it, I am at a disadvantage compared to
-      a non-fuse user
-    <ArneBab> while in the Hurd, these additional options are on eqal footing.
-    <marcusb> ArneBab: are they pushing more and more into user space?  I don't
-      think so.  I see more of the reverse, actually
-    <marcusb> or maybe both
-    <ArneBab> FUSE, lxd and scheduling in userspace move to userspace
-    <ArneBab> well, KMS moved to the kernel
-    <ArneBab> to avoid flickering when switching between X and the console?
-    <ArneBab> marcusb: Do you experience FUSE lxc and such being secondclass in
-      Linux, too, or is that just a strange feeling of me?
-    <ArneBab> marcusb: and that splits the users into those who can get stuff
-      into the kernel and those who can only work in userspace – which I don’t
-      really like.
-    <ArneBab> That’s one more advantage of the Hurd: eqal footing for all
-      (except the Mach hackers, but they have a very limited terrain)
-    <marcusb> ArneBab: but UML kernel module is minimal, and Linus didn't have
-      a principled objection to it (but just wanted a more general solution)
-    <marcusb> ArneBab: as a side note, although people keep complaining, the
-      linux kernel seems to be growing steadily, so getting stuff into the
-      kernel doesn't seem too hard.  8-O
-
----
-
-IRC, #hurd, 2010-12-28
-
-    <tim> but is monolithic so bad?
-    <sartakov> yep 
-    <braunr> no it's not
-    <braunr> proof: it works very well for most people
-    [...]
-    <braunr> the real problem is extensibility and interfaces
-    <tim> :/ whats the huge advantage of micro-k
-    <braunr> extensibility
-    <tim> over?
-    <braunr> you can add a whole lot of new services for new purposes with new
-      interfaces without changing the kernel
-    <tim> oright
-    <braunr> it basically boils down to the original Unix idea: everything does
-      one thing well
-    [...]
-    <kilobug> well, I would say extensibility and fault-tolerance are the two
-      key advantages
-    <braunr> taht's a side effect
-    <braunr> there are fault taulerant monolithic kernels
-    [...]
-    <braunr> tolerant*
-    <braunr> and the hurd is for now a non fault-tolerant microkernel based OS
-      :/
-    [...]
-    <kilobug> braunr: not really; you can't ensure fault tolerance for code
-      running in kernel space, code running in kernel space can do everything,
-      including reboot, crash, ...
-    [...]
-    <braunr> kilobug: right, a monolithick kernel is less folt-tolerant than a
-      well designed/implemented microkernel based os
-
-It turns out that it is perfectly possible to isolate services running in the
-same address space, as it was done in projects such as Singularity, the idea
-being that the code is verified through static analysis when installed (but
-this requires a language other than C).
-
-    <kilobug> braunr: well, the Hurd is buggy nowadays, but things like an
-      ext2fs translator doing a segfault and being restarted is a
-      fault-tolerance that would be almost impossible to have in Linux
-    <kilobug> braunr: sure, you can have fault-tolerance with FUSE, but FUSE is
-      applying micro-kernel paradigm to Linux
-    [...]
-    <braunr> the reason i don't care that much about fault tolerance is that
-      Linux obviously shows a monolithic kernel can run almost flawlessly if
-      well written
-    <braunr> but extensibility is really another matter
diff --git a/open_issues/binutils.mdwn b/open_issues/binutils.mdwn
deleted file mode 100644
index 306ba38a..00000000
--- a/open_issues/binutils.mdwn
+++ /dev/null
@@ -1,954 +0,0 @@
-[[!meta copyright="Copyright © 2007, 2008, 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]]."]]"""]]
-
-[[!meta title=binutils-gdb]]
-
-[[!tag stable_URL open_issue_binutils open_issue_gdb]]
-
-Here's what's to be done for maintaining GNU Binutils and GDB.
-
-
-[[!toc levels=2]]
-
-
-# General Information
-
-
-## [[/Binutils]]
-
-As these tools primarily deal with low-level parts of the target architecture
-and the object file format (ELF ABI), which are essentially (at least meant to
-be) the same, there shouldn't be many differences comparing the binutils
-between the GNU/Hurd and GNU/Linux ports, for example.  There are a few,
-though, as explained below.
-
-
-## [[/GDB]]
-
-GDB needs an processor architecture as well as operating system port.
-
-
-# Configuration
-
-<!--
-
-git checkout reviewed
-git diff --patience --stat=$COLUMNS,$COLUMNS --patch --src-prefix=./ --dst-prefix=./ --find-renames --ignore-space-change ..upstream/master | awk '/^diff/ { c = " " $0; } /^@@/ { print c; } { print; }' | less
--i
-/^---.*/([^.]*|.*\.texi.*|[^/]*gnu[^/]*)$|hurd|linux|nacl|nptl|glibc|gs:
-
--->
-
-Last reviewed up to Git commit c2853f3d99797a321c37948297441ca6021f719a
-(2014-02-14).
-
-  * Globally
-
-      * a.out (such as `ld/emulparams/i386linux.sh`, `ld/emultempl/linux.em`,
-        etc.), COFF, PE image support and 64-bit support are not interesting.
-
-      * In the testsuites, `.exp` and `.d` files very likely should not only
-        care for `*-*-linux*`, but also `*-*-gnu*`.  (If they need to be
-        conditionalized like this at all.)
-
-  * `bfd/`
-
-      * `config.bfd`
-
-          * `i[3-7]86-*-gnu*`
-
-            Comparing to `i[3-7]86-*-linux-*`:
-
-              * `i386linux_vec` -- a.out.
-
-              * `i386pei_vec` -- PE.
-
-              * 64 bit.
-
-      * `configure.host`
-
-        Souldn't need anything.  x86 Linux neither.
-
-      * `configure.in`
-
-        Linux:
-
-          * `COREFILE=trad-core.lo` with `TRAD_HEADER='"hosts/i386linux.h"'`
-
-            We don't have any such core file support configured.  TODO: should
-            we?  Where is this core file reading exactly used?  GDB?
-
-          * `i386linux_vec` -- a.out.
-
-          * `i386pei_vec` -- PE.
-
-  * `binutils/`
-
-      * `configure.tgt`
-
-  * `gas/`
-
-      * `config/te-gnu.h`
-
-        C.f. `te-linux.h`; search tree for `TE_LINUX` vs. `TE_GNU` usage.
-
-          * `tc-i386.h`
-
-            Sole `TE_LINUX` usage is for a.out.
-
-      * `configure.tgt`
-
-  * `gdb/`
-
-      * Have a look at config/i386/i386gnu.mh.
-
-      * configure.tgt
-
-          * glibc-tdep et al. also for GNU/Hurd?
-
-      * [[gdb/gdbserver]]
-
-      * In `gdb/gnu-nat.c:gnu_wait`, we don't implement
-        `gdb/target/wait.h:TARGET_WNOHANG`.  What is this needed for?
-
-  * `libdecnumber/`
-
-    Should/can probably align to GNU/Linux.
-
-  * `ld/`
-
-     * `configure.host`
-
-         * `*-*-gnu*`
-
-            TODO: resolve `crt0.o` vs. `crt1.o` issue.  [[Testsuite
-            failures|binutils#static]].
-
-      * `configure.tgt`
-
-          * `i[3-7]86-*-gnu*`
-
-            Compare to `i[3-7]86-*-linux-*`, but don't need a.out (`i386linux`)
-            and 64 bit support.
-
-  * `__ehdr_start symbol`, c84ed8d89d0b8bf5a2968d465f77ac24bcfc40c2 -- can this
-    be helpful in the exec server, glibc, or elsewhere?  Used in GDB (BFD)
-    commit bdbd9758806ed855af89244870fdc52cf3ff09bc.
-    Used in glibc commit 288f7d79fe2dcc8e62c539f57b25d7662a2cd5ff `Use
-    __ehdr_start, if available, as fallback for AT_PHDR.`.
-
-  * `Add HOSTING_SCRT0 for PIE test`, 49cc20aa5c416ea4307931cccf6353247368187d
-    -- is for GNU/Linux only; but also seems unused.
-
-  * 82763a3d329b0d342d0273941b1521be9ef0c604 »MODIFIED is unknown, pass it as
-    true.«
-
-  * Configure so that Debian system's `/usr/lib/debug/[...]` will be loaded
-    automatically.
-
-      * [[!message-id "m3ei24vh4l.fsf@fleche.redhat.com"]]
-
-  * [low] c26e9cbb0ce70e8fca32a40c434a0837bf46750a,
-    `gdb/gnu-nat.c:set_exceptions_cmd`, `Make this take effect immediately in a
-    running process`.
-
-  * [low] b27caf75c311991772b316fe7c0eecfd5788eeaf, ld, `Add HOSTING_SLIBS and
-    use it for -pie`.  For us, too?
-
-
-# Build
-
-Here's a log of a binutils-gdb build run; this is from Git commit
-c2853f3d99797a321c37948297441ca6021f719a (2014-02-14) plus
-[[!message-id "87vbxxhww4.fsf@kepler.schwinge.homeip.net"]],
-[[!message-id "8738kyi30l.fsf@kepler.schwinge.homeip.net"]],
-[[!message-id "8761ofv62k.fsf@kepler.schwinge.homeip.net"]],
-[[!message-id "1391759958-972-2-git-send-email-yao@codesourcery.com"]],
-[[!message-id "1391759958-972-3-git-send-email-yao@codesourcery.com"]], run on
-kepler.SCHWINGE and coulomb.SCHWINGE.
-
-    $ export LC_ALL=C
-    $ ../W._C._Handy/configure --prefix="$PWD".install --enable-gold --with-sysroot=/ SHELL=/bin/dash CC=gcc-4.8 CXX=g++-4.8 --disable-werror 2>&1 | tee log_build
-    [...]
-    $ make 2>&1 | tee log_build_
-    [...]
-
-Different hosts may default to different shells and compiler versions; thus
-harmonized.  Debian GCC (which is used in binutils' testsuite) likes to pass
-`--sysroot=/` to `ld`, so we need to configure binutils with support for
-sysroots.  In the GDB build, there are several occurences of *error:
-dereferencing type-punned pointer will break strict-aliasing rules* in the
-MIG-generated stub files; thus no `-Werror` until that is resolved
-([[strict_aliasing]]).
-
-This takes up around 1.3 GiB, and needs roughly 17 min on kepler.SCHWINGE and
-79 min on coulomb.SCHWINGE.
-
-<!--
-
-    $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-test) 2>&1 | tee log_install && test -f .go-test && make -k check 2>&1 | tee log_test
-
--->
-
-
-## Analysis
-
-x86 GNU/Linux' and GNU/Hurd's configurations are slightly different, thus mask
-out most of the differences that are due to GNU/Linux supporting more core file
-formats, and more emulation vectors.
-
-    $ toolchain/logs/process binutils-gdb build
-
-  * For GDB, why do we specify `-D_GNU_SOURCE`, and GNU/Linux doesn't?
-
-  * GNU/Linux: `gdb/symfile-mem.c` for [[vDSO]].
-
-  * GNU/Linux: `gdb/i386-nat.c` for hardware breakpoints, etc. -- we should
-    probably use that, too.  Related to Samuel's Hurd GDB patch?
-
-  * `gdb/gnu-nat.c`
-
-        gnu-nat.c: In function 'proc_set_exception_port':
-        gnu-nat.c:409:3: warning: format '%d' expects argument of type 'int', but argument 8 has type 'mach_port_t' [-Wformat]
-        gnu-nat.c: In function 'proc_steal_exc_port':
-        gnu-nat.c:449:7: warning: format '%d' expects argument of type 'int', but argument 8 has type 'mach_port_t' [-Wformat]
-        gnu-nat.c:470:7: warning: format '%d' expects argument of type 'int', but argument 8 has type 'mach_port_t' [-Wformat]
-        gnu-nat.c: In function 'make_proc':
-        gnu-nat.c:583:7: warning: format '%d' expects argument of type 'int', but argument 2 has type 'mach_port_t' [-Wformat]
-        gnu-nat.c:586:7: warning: format '%d' expects argument of type 'int', but argument 8 has type 'mach_port_t' [-Wformat]
-        gnu-nat.c: In function 'inf_set_pid':
-        gnu-nat.c:761:3: warning: format '%d' expects argument of type 'int', but argument 7 has type 'task_t' [-Wformat]
-        gnu-nat.c: In function 'inf_validate_procs':
-        gnu-nat.c:1085:6: warning: format '%d' expects argument of type 'int', but argument 8 has type 'thread_t' [-Wformat]
-        gnu-nat.c: In function 'inf_signal':
-        gnu-nat.c:1349:4: warning: format '%d' expects argument of type 'int', but argument 7 has type 'thread_t' [-Wformat]
-        gnu-nat.c:1349:4: warning: format '%d' expects argument of type 'int', but argument 8 has type 'thread_t' [-Wformat]
-        gnu-nat.c: In function 'S_exception_raise_request':
-        gnu-nat.c:1668:3: warning: format '%d' expects argument of type 'int', but argument 7 has type 'thread_t' [-Wformat]
-        gnu-nat.c:1668:3: warning: format '%d' expects argument of type 'int', but argument 8 has type 'task_t' [-Wformat]
-        gnu-nat.c:1705:8: warning: format '%d' expects argument of type 'int', but argument 7 has type 'mach_port_t' [-Wformat]
-        gnu-nat.c:1711:8: warning: format '%d' expects argument of type 'int', but argument 7 has type 'mach_port_t' [-Wformat]
-        gnu-nat.c: In function 'do_mach_notify_dead_name':
-        gnu-nat.c:1762:3: warning: format '%d' expects argument of type 'int', but argument 7 has type 'mach_port_t' [-Wformat]
-        gnu-nat.c: In function 'gnu_write_inferior':
-        gnu-nat.c:2383:8: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'vm_address_t' [-Wformat]
-        gnu-nat.c:2393:8: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'vm_address_t' [-Wformat]
-        gnu-nat.c: In function 'steal_exc_port':
-        gnu-nat.c:2864:5: warning: format '%d' expects argument of type 'int', but argument 2 has type 'mach_port_t' [-Wformat]
-
-  * fe19822761b4635f392875a186e48af446b40f41..7a63e9515491f21eaf07301df87d389def20e317:
-
-    `-Wmissing-prototypes`
-
-        notify_S.c:305:24: warning: no previous prototype for 'notify_server' []
-        notify_S.c:341:28: warning: no previous prototype for 'notify_server_routine' []
-        process_reply_S.c:343:24: warning: no previous prototype for 'process_reply_server' []
-        process_reply_S.c:379:28: warning: no previous prototype for 'process_reply_server_routine' []
-        msg_reply_S.c:165:24: warning: no previous prototype for 'msg_reply_server' []
-        msg_reply_S.c:201:28: warning: no previous prototype for 'msg_reply_server_routine' []
-        exc_request_S.c:157:24: warning: no previous prototype for 'exc_server' []
-        exc_request_S.c:193:28: warning: no previous prototype for 'exc_server_routine' []
-
-  * `O_NOFOLLOW`
-
-    First seen in
-    20f498edfd7e57d3297febcf9c7c7d667cc74239..69a5e2b022c7d15ec4c7c49e6f53a8d924d3b72b:
-
-        -checking for working fcntl.h... yes
-        +checking for working fcntl.h... no (bad O_NOFOLLOW)
-
-    [[!taglink open_issue_glibc]]?
-
-
-# Install
-
-    $ make install 2>&1 | tee log_install
-    [...]
-
-This takes up around 200 MiB, and needs roughly 2 min on kepler.SCHWINGE and 6
-min on coulomb.SCHWINGE.
-
-
-## Analysis
-
-    $ toolchain/logs/process binutils-gdb install
-
-  * `libtool: finish`: `ldconfig` is not run for the Hurd.
-
-
-# Testsuite
-
-    $ make -k check 2>&1 | tee log_test
-    [...]
-
-This needs roughly 20 min on kepler.SCHWINGE and 140 min on coulomb.SCHWINGE.
-
-When running `make -k check 2>&1 | tee log_test`, at the end of the testsuite
-the `tee` process does not terminate if there are still stray leftover
-processes that [have their stdout/stderr
-open](http://sourceware.org/ml/gdb-patches/2012-10/msg00489.html).  `kill`ing
-these (`SIGKILL` may be needed), makes the `tee` process terminate, too.  On
-GNU/Hurd, these generally are `gdb.multi/watchpoint-multi`, and an unknown
-(`?`) GDB one ("57 PIDs before" `expect [...] gdb.cp`).
-
-
-## Analysis
-
-GDB's testsuite uses the system's default `gcc` (and similar) compilers, not
-those specified on the `configure` line ([[!taglink open_issue_gdb]]?), see
-`find_gcc` (and similar) usage in the testsuite and DejaGnu.  Maybe something
-like `gdb/testsuite/boards/cc-with-tweaks.exp` would help, or setting
-`CC_FOR_TARGET` (and similar) per `gdb/testsuite/lib/future.exp`?
-
-    $ toolchain/logs/process binutils-gdb test
-
-  * <a name="static"><!-- stable_URL -->`FAIL: static [...]`</a>
-
-    The testsuite isn't prepared for using `crt0.o` instead of `crt1.o`
-    depending on whether a static or dynamic executable is created.  Documented
-    in `ld/configure.host`.  Perhaps we should finally rewrite this messy code
-    in glibc?  Or, something similar to commit
-    49cc20aa5c416ea4307931cccf6353247368187d `Add HOSTING_SCRT0 for PIE test`
-    or commit b27caf75c311991772b316fe7c0eecfd5788eeaf `Add HOSTING_SLIBS and
-    use it for -pie`
-    can be used.
-
-    Same issue for `FAIL: Common symbol override ifunc *` ones?
-
-  * <a name="64ksec">`FAIL: ld-elf/64ksec`</a>
-
-    On the idle grubber, this one takes a few minutes wall time to complete
-    successfully ([[I/O system
-    weakness|performance/io_system/binutils_ld_64ksec]]), so assuming some
-    system load variation, the testsuite's timeout may trigger.
-
-  * `FAIL: gas/i386/rept` (intermittently)
-
-    Added in commit 06f1247c54126b9f1e6acb8ff8c7be35aec6f44c (2012-06-07) as
-    part of the fix for [[!sourceware_PR 14201]], renamed in commit
-    d654e24bbc2f601df4dc43b26049b0339528b93a (2012-06-07):
-
-        WARNING: program timed out.
-        FAIL: gas/i386/rept
-
-  * ld IFUNC execution tests
-
-    Missing [[IFUNC]] support on GNU/Hurd.
-
-    Added in commit 82c5587db078581cfe94a4385ed99de1d1fa6657 (2012-09-19):
-
-        FAIL: Common symbol override ifunc test 1a
-        FAIL: Common symbol override ifunc test 1b
-
-  * gold GNU/Linux vs. GNU/Hurd
-
-        -FAIL: relro_test.sh
-        +PASS: relro_test.sh
-
-        -PASS: ver_matching_test.sh
-        +FAIL: ver_matching_test.sh
-
-        -PASS: script_test_3
-        +FAIL: script_test_3
-
-        -PASS: tls_phdrs_script_test
-        +FAIL: tls_phdrs_script_test
-
-  * `gdb.base/attach-pie-misread.exp`
-
-    Is only run for GNU/Linux; needs [[prelink]].
-
-  * Disabled
-
-      * `gdb.base/interrupt.exp`
-
-             PASS: gdb.base/interrupt.exp: child process is alive
-             a
-             a
-             PASS: gdb.base/interrupt.exp: child process ate our char
-             ^C
-             Program received signal SIGINT, Interrupt.
-            -0x010bf5a2 in _hurd_intr_rpc_mach_msg () from /lib/i386-gnu/libc.so.0.3
-            +0x010bdb09 in _hurd_intr_rpc_mach_msg () from /lib/i386-gnu/libc.so.0.3
-             (gdb) PASS: gdb.base/interrupt.exp: send_gdb control C
-             p func1 ()
-             
-             Program received signal SIGTRAP, Trace/breakpoint trap.
-            -0x010bf5a2 in _hurd_intr_rpc_mach_msg () from /lib/i386-gnu/libc.so.0.3
-            +0x010bdb09 in _hurd_intr_rpc_mach_msg () from /lib/i386-gnu/libc.so.0.3
-             The program being debugged was signaled while in a function called from GDB.
-             GDB remains in the frame where the signal was received.
-             To change this behavior use "set unwindonsignal on".
-             Evaluation of the expression containing the function
-             (func1) will be abandoned.
-             When the function is done executing, GDB will silently stop.
-             (gdb) FAIL: gdb.base/interrupt.exp: call function when asleep (wrong output)
-             p func1 ()
-             
-             Program received signal SIGTRAP, Trace/breakpoint trap.
-            -0x010bf5a2 in _hurd_intr_rpc_mach_msg () from /lib/i386-gnu/libc.so.0.3
-            +0x010bdb09 in _hurd_intr_rpc_mach_msg () from /lib/i386-gnu/libc.so.0.3
-             The program being debugged was signaled while in a function called from GDB.
-             GDB remains in the frame where the signal was received.
-             To change this behavior use "set unwindonsignal on".
-             Evaluation of the expression containing the function
-             (func1) will be abandoned.
-             When the function is done executing, GDB will silently stop.
-             (gdb) FAIL: gdb.base/interrupt.exp: call function a second time
-             continue
-             Continuing.
-            -PASS: gdb.base/interrupt.exp: continue
-            +
-            +Program received signal SIGSEGV, Segmentation fault.
-            +0x010bdb09 in _hurd_intr_rpc_mach_msg () from /lib/i386-gnu/libc.so.0.3
-            +(gdb) FAIL: gdb.base/interrupt.exp: continue
-             data
-             PASS: gdb.base/interrupt.exp: echo data
-             ^C(gdb) Quit
-             (gdb) FAIL: gdb.base/interrupt.exp: Send Control-C, second time
-             signal SIGINT
-             Continuing with signal SIGINT.
-             PASS: gdb.base/interrupt.exp: signal SIGINT
-             more data
-             PASS: gdb.base/interrupt.exp: echo more data
-             
-             Program received signal SIGSEGV, Segmentation fault.
-            -0x010bf6c8 in _hurd_intr_rpc_mach_msg () from /lib/i386-gnu/libc.so.0.3
-            +0x010bdc9d in _hurd_intr_rpc_mach_msg () from /lib/i386-gnu/libc.so.0.3
-             (gdb) more data
-             Undefined command: "more".  Try "help".
-             (gdb) FAIL: gdb.base/interrupt.exp: send end of file
-            -testcase ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/interrupt.exp completed in 6 seconds
-            +[hangs]
-
-             7939 1000  6817  7939  7939  2  144M 8.92M 93.8  5:29.23    10hrs /media/erich/home/thomas/tmp/gdb/tschwinge/Ferry_Tagscherer.build/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory /media/erich/home/thomas/tmp/gdb/tschwinge/Ferry_Tagscherer.build/gdb/testsuite/../data-directory
-             7944 1000  7939  7944  7939  2  146M  744K  0.0  0:00.00  0:00.01 /media/erich/home/thomas/tmp/gdb/tschwinge/Ferry_Tagscherer.build/gdb/testsuite/gdb.base/interrupt
-
-            $ gdb -q tmp/gdb/tschwinge/Ferry_Tagscherer.build/gdb/gdb 7961
-            Reading symbols from /media/erich/home/thomas/tmp/gdb/tschwinge/Ferry_Tagscherer.build/gdb/gdb...done.
-            Attaching to program `/media/erich/home/thomas/tmp/gdb/tschwinge/Ferry_Tagscherer.build/gdb/gdb', pid 7961
-            [New Thread 7961.1]
-            [New Thread 7961.2]
-            
-            warning: Can't modify tracing state for pid 7961: (ipc/rcv) timed out
-            Reading symbols [...]
-            (gdb) thread apply all bt full
-            
-            Thread 2 (Thread 7961.2):
-            #0  0x014949cc in swtch_pri () at /build/eglibc-wYOBb2/eglibc-2.17/build-tree/hurd-i386-libc/mach/swtch_pri.S:2
-            No locals.
-            #1  0x01496354 in __spin_lock_solid (lock=0x168100c) at spin-solid.c:26
-            No locals.
-            #2  0x014aa677 in __spin_lock (__lock=<optimized out>) at ../mach/lock-intern.h:54
-            No locals.
-            #3  _hurd_sigstate_lock (ss=0x1681808) at hurdsig.c:175
-            No locals.
-            #4  0x014acbfb in post_signal (untraced=untraced@entry=0) at hurdsig.c:680
-                    err = <optimized out>
-                    handler = <optimized out>
-                    blocked = <optimized out>
-                    __PRETTY_FUNCTION__ = "post_signal"
-                    signo = 11
-                    act = 23593696
-                    ss = 0x1681808
-                    thread_state = {set = 0, basic = {gs = 1, fs = 17840912, es = 23594144, ds = 17840912, edi = 23290621, esi = 21506724, ebp = 23281960, esp = 1, ebx = 3, edx = 27255556, ecx = 23599112, eax = 163840, eip = 23273912, 
-                        cs = 29351492, efl = 29351424, uesp = 0, ss = 29351336}, fpu = {fpkind = 17840912, initialized = 29351344, 
-                        hw_state = "\364\213\002\000\000\000\000\000\000\000\000\000cfH\001\000\000\000\000\377\377\377\377\000 c\001T\244G\001\020;\020\001\b\030h\001\000\260g\001\370ݿ\001\060\357\277\001p\000\000\000\233\322e\001\220ݿ\001\216\246J\001\000\300b\001\260\341J\001\b\030h\001\000\000\000\000\000\000\000\000\000 c\001\022\000\000\000\000\200\002\000\020;\020\001\030\306b\001", exc_status = 359}}
-                    ss_suspended = 0
-                    reply = 0x1bfddf4
-                    detail = 0x1bfde4c
-            #5  0x014ae29e in _hurd_internal_post_signal (ss=ss@entry=0x1681808, signo=11, detail=detail@entry=0x1bfde4c, reply_port=reply_port@entry=0, reply_port_type=reply_port_type@entry=17, untraced=untraced@entry=0) at hurdsig.c:1221
-                    reply_rpc = 0x165d200 <__msg_sig_post_reply>
-            #6  0x014af98f in _S_catch_exception_raise (port=142, thread=112, task=1, exception=1, code=2, subcode=19137735) at catch-exc.c:88
-                    ss = 0x1681808
-                    signo = 11
-                    d = {exc = 1, exc_code = 2, exc_subcode = 19137735, code = 2, error = EKERN_PROTECTION_FAILURE}
-            #7  0x016442c2 in _Xexception_raise (OutHeadP=0x1bfdf20, InHeadP=0x1bfef30) at /build/eglibc-wYOBb2/eglibc-2.17/build-tree/hurd-i386-libc/mach/mach/exc_server.c:150
-            No locals.
-            #8  _Xexception_raise (InHeadP=0x1bfef30, OutHeadP=0x1bfdf20) at /build/eglibc-wYOBb2/eglibc-2.17/build-tree/hurd-i386-libc/mach/mach/exc_server.c:41
-                    In0P = 0x1bfef30
-                    OutP = 0x1bfdf20
-            #9  0x01644344 in _S_exc_server (InHeadP=InHeadP@entry=0x1bfef30, OutHeadP=OutHeadP@entry=0x1bfdf20) at /build/eglibc-wYOBb2/eglibc-2.17/build-tree/hurd-i386-libc/mach/mach/exc_server.c:189
-                    InP = 0x1bfef30
-                    OutP = 0x1bfdf20
-                    routine = 0x1644220 <_Xexception_raise>
-            #10 0x014a58ec in msgport_server (outp=0x1bfdf20, inp=0x1bfef30) at msgportdemux.c:49
-            No locals.
-            #11 msgport_server (inp=inp@entry=0x1bfef30, outp=outp@entry=0x1bfdf20) at msgportdemux.c:36
-                    d = 0x0
-            #12 0x01495898 in __mach_msg_server_timeout (demux=demux@entry=0x14a5890 <msgport_server>, max_size=max_size@entry=4096, rcv_name=rcv_name@entry=142, option=option@entry=0, timeout=timeout@entry=0) at msgserver.c:108
-                    request = 0x1bfef30
-                    reply = 0x1bfdf20
-                    mr = <optimized out>
-                    __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-            #13 0x014959cb in __mach_msg_server (demux=demux@entry=0x14a5890 <msgport_server>, max_size=4096, rcv_name=142) at msgserver.c:195
-            No locals.
-            #14 0x014a597d in _hurd_msgport_receive () at msgportdemux.c:67
-            No locals.
-            #15 0x010f7956 in entry_point (self=0x8520788, start_routine=0x14a5920 <_hurd_msgport_receive>, arg=0x0) at ./pthread/pt-create.c:61
-            No locals.
-            #16 0x00000000 in ?? ()
-            No symbol table info available.
-            
-            Thread 1 (Thread 7961.1):
-            #0  _hurd_userlink_unlink (link=0x81c2a20 <command_handler+48>) at ../hurd/hurd/userlink.h:123
-            No locals.
-            #1  __sigreturn (scp=0x81c2950 <handle_sigint>) at ../sysdeps/mach/hurd/i386/sigreturn.c:47
-                    link = 0x81c2a20 <command_handler+48>
-                    reply_port = <optimized out>
-            #2  0x014aef46 in trampoline () from /lib/i386-gnu/libc.so.0.3
-            No locals.
-            #3  0x081c2950 in ?? () at ../../Ferry_Tagscherer/gdb/event-top.c:869
-                    sigtstp_token = 0x860a7c0
-                    sighup_token = 0x86089e0
-                    more_to_come = 0
-                    sigfpe_token = 0x860a7a8
-                    sigquit_token = 0x86089c8
-                    sigint_token = 0x860a3b0
-                    call_readline = 0x81c2ab0 <rl_callback_read_char_wrapper>
-                    exec_done_display_p = 0
-                    input_handler = 0x81c2c50 <command_line_handler>
-                    async_command_editing_p = 1
-                    after_char_processing_hook = 0x0
-                    async_annotation_suffix = 0x83d8648 "prompt"
-                    input_fd = 0
-                    readline_input_state = {linebuffer = 0x0, linebuffer_ptr = 0x0}
-            Backtrace stopped: previous frame inner to this frame (corrupt stack?)
-            (gdb) kill
-            Kill the program being debugged? (y or n) y
-
-      * `gdb.base/readline.exp`
-
-        [[term_blocking]] issue.
-
-      * `gdb.base/sigall.exp`
-
-        From `send signal TSTP` on, all FAIL running into timeouts.
-
-      * `gdb.python/py-inferior.exp` (mostly disabled)
-
-            Running ../../../Ferry_Tagscherer/gdb/testsuite/gdb.python/py-inferior.exp ...
-            [...]
-            python print 'result =', i0.was_attached
-            result = False
-            (gdb) PASS: gdb.python/py-inferior.exp: test Inferior.was_attached
-            python print i0.threads ()
-            (<gdb.InferiorThread object at 0x61170>, <gdb.InferiorThread object at 0x61160>)
-            (gdb) FAIL: gdb.python/py-inferior.exp: test Inferior.threads
-            break check_threads
-            Breakpoint 2 at 0x8048869: file ../../../Ferry_Tagscherer/gdb/testsuite/gdb.python/py-inferior.c, line 61.
-            (gdb) continue
-            Continuing.
-            [New Thread 25670.6]
-            [New Thread 25670.7]
-            [New Thread 25670.8]
-            [New Thread 25670.9]
-            [New Thread 25670.10]
-            [New Thread 25670.11]
-            [New Thread 25670.12]
-            [New Thread 25670.13]
-            
-            Breakpoint 2, check_threads (barrier=0x15ff144) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.python/py-inferior.c:61
-            61        pthread_barrier_wait (barrier);
-            (gdb) PASS: gdb.python/py-inferior.exp: continue to breakpoint: cont to check_threads
-            python print len (i0.threads ())
-            10
-            (gdb) FAIL: gdb.python/py-inferior.exp: test Inferior.threads 2
-            break 28
-            Breakpoint 3 at 0x80487c2: file ../../../Ferry_Tagscherer/gdb/testsuite/gdb.python/py-inferior.c, line 28.
-            (gdb) continue
-            Continuing.
-            FAIL: gdb.python/py-inferior.exp: continue to breakpoint: cont to Break here. (timeout)
-            python addr = gdb.selected_frame ().read_var ('str')
-            FAIL: gdb.python/py-inferior.exp: read str address (timeout)
-            [All following tests FAIL with timeout.]
-            FAIL: gdb.python/py-inferior.exp: Switch to first inferior (timeout)
-            remove-inferiors 3
-            FAIL: gdb.python/py-inferior.exp: Remove second inferior (timeout)
-
-        At this point, the system hangs; no new processes can be spawned, so
-        perhaps an issue with the exec server.
-
-      * `gdb.threads/manythreads.exp`
-
-        [[!taglink open_issue_libpthread]].  Perhaps fails due to pthread
-        attributes usage?  Doesn't execute properly:
-
-            $ gdb/testsuite/gdb.threads/manythreads
-            manythreads: ../libpthread/sysdeps/mach/pt-thread-halt.c:51: __pthread_thread_halt: Unexpected error: (ipc/rcv) invalid name.
-            Killed
-
-  * Linux syscall usage, `<asm/unistd.h>`
-
-      * `UNSUPPORTED: gdb.threads/ia64-sigill.exp: Couldn't compile ../../../master/gdb/testsuite/gdb.threads/ia64-sigill.c: unrecognized error`
-
-      * `UNSUPPORTED: gdb.threads/siginfo-threads.exp: Couldn't compile ../../../Ferry_Tagscherer/gdb/testsuite/gdb.threads/siginfo-threads.c: unrecognized error`
-
-      * `gdb.threads/sigstep-threads.c`
-
-        Also uses `tgkill`.
-
-      * `UNSUPPORTED: gdb.threads/watchpoint-fork.exp: parent: multithreaded: Couldn't compile ../../../Ferry_Tagscherer/gdb/testsuite/gdb.threads/watchpoint-fork-mt.c ../../../Ferry_Tagscherer/gdb/testsuite/gdb.threads/watchpoint-fork-parent.c: unrecognized error`
-
-  * `UNSUPPORTED: gdb.threads/multi-create.exp: Couldn't compile ../../../master/gdb/testsuite/gdb.threads/multi-create.c: unrecognized error`
-        ../../../master/gdb/testsuite/gdb.threads/multi-create.c: In function 'create_function':
-        ../../../master/gdb/testsuite/gdb.threads/multi-create.c:46:39: error: 'PTHREAD_STACK_MIN' undeclared (first use in this function)
-        ../../../master/gdb/testsuite/gdb.threads/multi-create.c:46:39: note: each undeclared identifier is reported only once for each function it appears in
-        ../../../master/gdb/testsuite/gdb.threads/multi-create.c: In function 'main':
-        ../../../master/gdb/testsuite/gdb.threads/multi-create.c:73:39: error: 'PTHREAD_STACK_MIN' undeclared (first use in this function)
-
-  * `UNSUPPORTED: gdb.threads/staticthreads.exp: Couldn't compile ../../../master/gdb/testsuite/gdb.threads/staticthreads.c: unrecognized error`
-
-        ../../../master/gdb/testsuite/gdb.threads/staticthreads.c: In function 'main':
-        ../../../master/gdb/testsuite/gdb.threads/staticthreads.c:52:37: error: 'PTHREAD_STACK_MIN' undeclared (first use in this function)
-        ../../../master/gdb/testsuite/gdb.threads/staticthreads.c:52:37: note: each undeclared identifier is reported only once for each function it appears in
-
-  * `UNSUPPORTED: gdb.threads/create-fail.exp: Couldn't compile ../../../Ferry_Tagscherer/gdb/testsuite/gdb.threads/create-fail.c: unrecognized error`
-
-        [...]/gdb.threads/create-fail.c:77: undefined reference to `pthread_attr_setaffinity_np'
-        [...]/gdb.threads/create-fail.c:83: undefined reference to `pthread_create'
-
-  * `UNTESTED: gdb.base/longest-types.exp: longest-types.exp`
-
-        ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/longest-types.c:20:8: error: size of array 'buf' is too large
-
-    Also on GNU/Linux.
-
-  * `FAIL: gdb.base/jit.exp: PIE: one_jit_test-1: Can't run to main`
-
-        (gdb) break main
-        Breakpoint 1 at 0xb84: file ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/jit-main.c, line 128.
-        (gdb) run 
-        Starting program: /media/erich/home/thomas/tmp/gdb/tschwinge/Ferry_Tagscherer.build/gdb/testsuite/gdb.base/jit-main 
-        Cannot access memory at address 0x393
-        Cannot access memory at address 0x38f
-        (gdb) FAIL: gdb.base/jit.exp: PIE: one_jit_test-1: Can't run to main
-
-    [[GCC/PIE]].
-
-    Is the following supposed to terminate in this way?
-
-        (gdb) break main
-        Breakpoint 1 at 0x675: file ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/attach-pie-noexec.c, line 23.
-        (gdb) run 
-        Starting program: /media/erich/home/thomas/tmp/gdb/tschwinge/Ferry_Tagscherer.build/gdb/testsuite/gdb.base/attach-pie-noexec 
-        Cannot access memory at address 0x6c626172
-        Cannot access memory at address 0x6c62616e
-        (gdb) testcase ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/attach-pie-noexec.exp completed in 3 seconds
-
-    IRC, freenode, #hurd, 2013-09-06:
-
-        <gnu_srs1> How to debug a program that works in the shell but Cannot
-          access memory at address ... in gdb?
-        <tschwinge> Build it without -pie -- but that is just a guess of what
-          might be going on.
-        * tschwinge clearly has spent enough time with obscure things to be
-            able to make such guesses.
-        <gnu_srs1> tschwinge: looks like -fPIE is used.
-        <gnu_srs1> verified: some (all?) executables compiled with -fPIE, -fpie
-          and linked with -pie cannot be debugged in gdb :(
-
-  * `solib-event stop`
-
-        Running ../../../Ferry_Tagscherer/gdb/testsuite/gdb.mi/mi-catch-load.exp ...
-        PASS: gdb.mi/mi-catch-load.exp: breakpoint at main
-        PASS: gdb.mi/mi-catch-load.exp: mi runto main
-        PASS: gdb.mi/mi-catch-load.exp: catch-load: auto-solib-add on
-        PASS: gdb.mi/mi-catch-load.exp: catch-load: catch load
-        FAIL: gdb.mi/mi-catch-load.exp: catch-load: solib-event stop
-        PASS: gdb.mi/mi-catch-load.exp: breakpoint at main
-        PASS: gdb.mi/mi-catch-load.exp: mi runto main
-        PASS: gdb.mi/mi-catch-load.exp: catch-unload: auto-solib-add on
-        PASS: gdb.mi/mi-catch-load.exp: catch-unload: catch unload
-        FAIL: gdb.mi/mi-catch-load.exp: catch-unload: solib-event stop
-
-        *stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation fault",frame={addr="0x00014add",func="??",args=[],from="/lib/ld.so"},thread-id="4",stopped-threads="all"
-
-  * `gdb.base/call-signal-resume.exp`
-
-        $ gdb -q gdb/testsuite/gdb.base/call-signals
-        (gdb) break stop_one
-        (gdb) r
-        (gdb) call gen_signal()
-        (gdb) bt
-        (gdb) frame [<function called from gdb>]
-        (gdb) return
-        (gdb) break handle_signal
-        (gdb) c
-        (gdb) c
-
-    kepler.SCHWINGE:
-
-        Breakpoint 2, handle_signal (sig=6) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:28
-        28      }
-        (gdb) bt
-        #0  handle_signal (sig=6) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:28
-        #1  <signal handler called>
-        #2  0xb7fde416 in __kernel_vsyscall ()
-        #3  0xb7dffd96 in kill () at ../sysdeps/unix/syscall-template.S:81
-        #4  0x0804859c in gen_signal () at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:35
-        #5  0x08048610 in main () at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:81
-
-    coulomb.SCHWINGE:
-
-        Breakpoint 2, handle_signal (sig=6) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:28
-        28      }
-        (gdb) bt
-        #0  handle_signal (sig=6) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:28
-        #1  0x010baac2 in trampoline () from /lib/i386-gnu/libc.so.0.3
-        #2  0x00000006 in ?? ()
-        #3  0x00000000 in ?? ()
-
-    kepler.SCHWINGE:
-
-        (gdb) c
-        Continuing.
-        no signal
-        [Inferior 1 (process 10401) exited normally]
-
-    coulomb.SCHWINGE:
-
-        (gdb) c
-        Continuing.
-        no signal
-        
-        Program received signal SIGSEGV, Segmentation fault.
-        0x00000000 in ?? ()
-        (gdb) bt
-        #0  0x00000000 in ?? ()
-        #1  0x01116c28 in _IO_acquire_lock_fct (p=<synthetic pointer>) at libioP.h:905
-        #2  _IO_puts (str=0x80487e0 "no signal") at ioputs.c:45
-        #3  0x080486d8 in gen_signal () at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:38
-        #4  0x0804873d in main () at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/call-signals.c:81
-
-    This is apparently new with the glibc 2.17 upgrade.  If not doing the
-    manual `gen_signal` call, it works fine.  TODO.
-
-  * `gdb.base/relativedebug.exp`
-
-        (gdb) PASS: gdb.base/relativedebug.exp: continue
-        bt
-        #0  0x010a1afc in ?? () from /lib/i386-gnu/libc.so.0.3
-        #1  0x010a23be in mach_msg () from /lib/i386-gnu/libc.so.0.3
-        #2  0x0126cd98 in msg_sig_post () from /lib/i386-gnu/libhurduser.so.0.3
-        #3  0x010e2141 in ?? () from /lib/i386-gnu/libc.so.0.3
-        #4  0x010e23ed in kill () from /lib/i386-gnu/libc.so.0.3
-        #5  0x010e17f4 in raise () from /lib/i386-gnu/libc.so.0.3
-        #6  0x010e5b7c in abort () from /lib/i386-gnu/libc.so.0.3
-        #7  0x08048607 in handler (signo=14) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/relativedebug.c:25
-        #8  0x010bdac2 in ?? () from /lib/i386-gnu/libc.so.0.3
-        Backtrace stopped: previous frame inner to this frame (corrupt stack?)
-        (gdb) FAIL: gdb.base/relativedebug.exp: pause found in backtrace
-
-    This is apparently new with the glibc 2.17 upgrade.  Previously it said:
-
-        (gdb) PASS: gdb.base/relativedebug.exp: continue
-        bt
-        #0  0x0107c85c in ?? () from /lib/i386-gnu/libc.so.0.3
-        #1  0x0107d069 in mach_msg () from /lib/i386-gnu/libc.so.0.3
-        #2  0x01220d4f in msg_sig_post () from /lib/i386-gnu/libhurduser.so.0.3
-        #3  0x010bb683 in ?? () from /lib/i386-gnu/libc.so.0.3
-        #4  0x010bb8f6 in kill () from /lib/i386-gnu/libc.so.0.3
-        #5  0x010bad76 in raise () from /lib/i386-gnu/libc.so.0.3
-        #6  0x010bf029 in abort () from /lib/i386-gnu/libc.so.0.3
-        #7  0x08048597 in handler (signo=14) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/relativedebug.c:25
-        #8  0x01098282 in ?? () from /lib/i386-gnu/libc.so.0.3
-        #9  0x010bbe5a in sigsuspend () from /lib/i386-gnu/libc.so.0.3
-        #10 0x0112fee1 in pause () from /lib/i386-gnu/libc.so.0.3
-        #11 0x080485c5 in main () at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/relativedebug.c:32
-        (gdb) PASS: gdb.base/relativedebug.exp: pause found in backtrace
-
-    TODO.
-
-  * `gdb.gdb/selftest.exp`
-
-        (gdb) PASS: gdb.gdb/selftest.exp: send SIGINT signal to child process
-        backtrace
-        #0  0x0146fafc in ?? () from /lib/i386-gnu/libc.so.0.3
-        #1  0x014703be in mach_msg () from /lib/i386-gnu/libc.so.0.3
-        #2  0x0163bd98 in msg_sig_post () from /lib/i386-gnu/libhurduser.so.0.3
-        #3  0x014b0141 in ?? () from /lib/i386-gnu/libc.so.0.3
-        #4  0x014b03ed in kill () from /lib/i386-gnu/libc.so.0.3
-        #5  0x082cf471 in _rl_handle_signal (sig=2) at ../../Ferry_Tagscherer/readline/signals.c:221
-        #6  0x0148bac2 in ?? () from /lib/i386-gnu/libc.so.0.3
-        Backtrace stopped: previous frame inner to this frame (corrupt stack?)
-        (gdb) FAIL: gdb.gdb/selftest.exp: backtrace through signal handler
-
-    This is apparently new with the glibc 2.17 upgrade.  Previously it said:
-
-        (gdb) PASS: gdb.gdb/selftest.exp: send SIGINT signal to child process
-        backtrace
-        #0  0x0144885c in ?? () from /lib/i386-gnu/libc.so.0.3
-        #1  0x01449069 in mach_msg () from /lib/i386-gnu/libc.so.0.3
-        #2  0x015ecd4f in msg_sig_post () from /lib/i386-gnu/libhurduser.so.0.3
-        #3  0x01487683 in ?? () from /lib/i386-gnu/libc.so.0.3
-        #4  0x014878f6 in kill () from /lib/i386-gnu/libc.so.0.3
-        #5  0x082cf401 in _rl_handle_signal (sig=2) at ../../Ferry_Tagscherer/readline/signals.c:221
-        #6  0x01464282 in ?? () from /lib/i386-gnu/libc.so.0.3
-        #7  0x0144fce3 in ?? () from /lib/i386-gnu/libc.so.0.3
-        #8  0x0153975b in poll () from /lib/i386-gnu/libc.so.0.3
-        #9  0x081c91c2 in gdb_wait_for_event (block=1) at ../../Ferry_Tagscherer/gdb/event-loop.c:804
-        #10 0x081c998f in gdb_do_one_event () at ../../Ferry_Tagscherer/gdb/event-loop.c:402
-        #11 0x081c9b07 in start_event_loop () at ../../Ferry_Tagscherer/gdb/event-loop.c:431
-        #12 0x081c2f42 in captured_command_loop (data=data@entry=0x0) at ../../Ferry_Tagscherer/gdb/main.c:260
-        #13 0x081c0e57 in catch_errors (func=func@entry=0x81c2f30 <captured_command_loop>, func_args=func_args@entry=0x0, errstring=errstring@entry=0x83
-        5b81b "", mask=mask@entry=6) at ../../Ferry_Tagscherer/gdb/exceptions.c:546
-        #14 0x081c388c in captured_main (data=data@entry=0x19ff150) at ../../Ferry_Tagscherer/gdb/main.c:1055
-        #15 0x081c0e57 in catch_errors (func=func@entry=0x81c3130 <captured_main>, func_args=func_args@entry=0x19ff150, errstring=errstring@entry=0x835b
-        81b "", mask=mask@entry=6) at ../../Ferry_Tagscherer/gdb/exceptions.c:546
-        #16 0x081c43c0 in gdb_main (args=0x19ff150) at ../../Ferry_Tagscherer/gdb/main.c:1064
-        #17 0x08099533 in main (argc=5, argv=0x19ff1e8) at ../../Ferry_Tagscherer/gdb/gdb.c:34
-        (gdb) PASS: gdb.gdb/selftest.exp: backtrace through signal handler
-
-    TODO.
-
-  * `gdb.base/restore.exp`, `gdb.base/store.exp`
-
-    Several FAILs, starting with GCC 4.8 usage:
-
-        (gdb) PASS: gdb.base/restore.exp: caller3 calls callee1; return callee now
-        print l1
-        $16 = <optimized out>
-        (gdb) FAIL: gdb.base/restore.exp: caller3 calls callee1; return restored l1 to 32492
-
-    [[!GCC_PR 55056]], [[!message-id
-    "20130126202645.GA4888@host2.jankratochvil.net"]], and maybe [[!message-id
-    "CAO2gOZXvCLdaKE2=ZKpjGVGq8A0wQ94-AUo7eKvvWHWncrU_yg@mail.gmail.com"]] look
-    related.
-
-  * `gdb.base/default.exp`
-
-        shell echo Hi dad!
-        bash: relocation error: /lib/i386-gnu/libdl.so.2: symbol __libc_lock_self, version GLIBC_PRIVATE not defined in file libc.so.0.3 with link time reference
-        (gdb) FAIL: gdb.base/default.exp: shell echo Hi dad!
-
-    TODO.
-
-  * `gdb.base/exitsignal.exp`
-
-        Running ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/exitsignal.exp ...
-        PASS: gdb.base/exitsignal.exp: $_exitsignal is void before running
-        PASS: gdb.base/exitsignal.exp: $_exitcode is void before running
-        PASS: gdb.base/exitsignal.exp: trigger SIGSEGV
-        PASS: gdb.base/exitsignal.exp: program terminated with SIGSEGV
-        FAIL: gdb.base/exitsignal.exp: $_exitsignal is 11 (SIGSEGV) after SIGSEGV.
-        PASS: gdb.base/exitsignal.exp: $_exitcode is still void after SIGSEGV
-        PASS: gdb.base/exitsignal.exp: rerun to main
-        FAIL: gdb.base/exitsignal.exp: $_exitsignal is 11 (SIGSEGV) after restarting the inferior
-        PASS: gdb.base/exitsignal.exp: $_exitcode is still void after restarting the inferior
-        PASS: gdb.base/exitsignal.exp: $_exitsignal is void before normal inferior is executed
-        PASS: gdb.base/exitsignal.exp: $_exitcode is void before normal inferior is executed
-        PASS: gdb.base/exitsignal.exp: continue until exit
-        PASS: gdb.base/exitsignal.exp: $_exitcode is zero after normal inferior is executed
-        PASS: gdb.base/exitsignal.exp: $_exitsignal is still void after normal inferior is executed
-
-    TODO.
-
-  * `gdb.arch/i386-prologue.exp`
-
-    There are several FAILs, where there are unexpected frames showing up in
-    backtraces, for example.  Earlier on, these just FAILed on
-    coulomb.SCHWINGE; since
-    9939e1314f970c6ba568956148a518ac710a280a..c2853f3d99797a321c37948297441ca6021f719a
-    on kepler.SCHWINGE, too.  TODO.
-
-  * [[libgc|boehm_gc]] `GC_find_limit_with_bound` SIGSEGVs
-
-    On coulomb.SCHWINGE, in
-    9939e1314f970c6ba568956148a518ac710a280a..c2853f3d99797a321c37948297441ca6021f719a
-    several PASSes regressed to FAILs:
-
-        Starting program: [...]/gdb/testsuite/gdb.gdb/xgdb -nw -nx -data-directory [...]/gdb/testsuite/../data-directory
-        [New Thread 13417.5]
-        
-        Program received signal SIGSEGV, Segmentation fault.
-        0x0126b961 in GC_find_limit_with_bound () from /usr/lib/i386-gnu/libgc.so.1
-        (gdb) FAIL: gdb.gdb/complaints.exp: run until breakpoint at captured_command_loop
-        WARNING: Couldn't test self
-
-        Starting program: [...]/gdb/testsuite/gdb.gdb/xgdb -nw -nx -data-directory [...]/gdb/testsuite/../data-directory
-        [New Thread 13448.5]
-        
-        Program received signal SIGSEGV, Segmentation fault.
-        0x0126b961 in GC_find_limit_with_bound () from /usr/lib/i386-gnu/libgc.so.1
-        (gdb) FAIL: gdb.gdb/python-interrupts.exp: run until breakpoint at captured_command_loop
-        WARNING: Couldn't test self
-
-        Starting program: [...]/gdb/testsuite/gdb.gdb/xgdb -nw -nx -data-directory [...]/gdb/testsuite/../data-directory
-        [New Thread 13464.3]
-        
-        Program received signal SIGSEGV, Segmentation fault.
-        0x0126b961 in GC_find_limit_with_bound () from /usr/lib/i386-gnu/libgc.so.1
-        (gdb) FAIL: gdb.gdb/python-selftest.exp: run until breakpoint at captured_command_loop
-        WARNING: Couldn't test self
-
-        (gdb) PASS: gdb.gdb/selftest.exp: step into xmalloc call
-        continue
-        Continuing.
-        
-        Program received signal SIGSEGV, Segmentation fault.
-        0x0126b961 in GC_find_limit_with_bound () from /usr/lib/i386-gnu/libgc.so.1
-        (gdb) FAIL: gdb.gdb/selftest.exp: xgdb is at prompt
-
-    These are all tests where GDB examines itself; being linked against libgc
-    (new dependency due to new Guile scripting support; all Guile scripting
-    tests PASS).  So, probably some bad interaction between GDB and a debuggee
-    that is using libgc; maybe libgc is using SIGSEGV for internal signalling
-    purposes; see the `HEURISTIC2` discussion on [[boehm_gc]].
-
-        #0  0x0126b961 in GC_find_limit_with_bound () from /usr/lib/i386-gnu/libgc.so.1
-        #1  0x0126ba2e in GC_find_limit () from /usr/lib/i386-gnu/libgc.so.1
-        #2  0x0126bb15 in GC_get_stack_base () from /usr/lib/i386-gnu/libgc.so.1
-        #3  0x011be0ec in scm_init_guile () from /usr/lib/libguile-2.0.so.22
-        #4  0x081203ba in _initialize_guile () at ../../W._C._Handy/gdb/guile/guile.c:704
-        #5  0x082dc94d in initialize_all_files () at init.c:291
-        #6  0x082a3c7f in gdb_init (argv0=0x8563e90 "[...]/gdb/testsuite/gdb.gdb/xgdb") at ../../W._C._Handy/gdb/top.c:1822
-        #7  0x081da3b8 in captured_main (data=0x1bff164) at ../../W._C._Handy/gdb/main.c:747
-        #8  0x081d70e9 in catch_errors (func=func@entry=0x81da110 <captured_main>, func_args=func_args@entry=0x1bff164, errstring=errstring@entry=0x837a0e5 "", mask=mask@entry=RETURN_MASK_ALL) at ../../W._C._Handy/gdb/exceptions.c:524
-        #9  0x081db277 in gdb_main (args=0x1bff164) at ../../W._C._Handy/gdb/main.c:1062
-        #10 0x0809714b in main (argc=5, argv=0x1bff1f4) at ../../W._C._Handy/gdb/gdb.c:33
-
-    TODO.
-
-TODO.
-
-
-# Open Issues
-
-## [[tag/open_issue_binutils]]
-
-## [[tag/open_issue_gdb]]
-
-## GDB `info files` SIGSEGV
-
-[[!tag open_issue_gdb]]
-
-
-### IRC, freenode, #hurd, 2013-09-07
-
-    <rekado> I'm trying to debug pfinet, but I'm not very familiar with gdb.
-      Tried to attach to the running pfinet process (built with debug symbols),
-      set a breakpoint and ... when I ran "info files" the process segfaulted.
-    <teythoon> which process segfaults, pfinet or gdb?
-    <rekado> gdb segfaults.
-
-
-## GDB Watchpoints
-
-[[!tag open_issue_gdb]]
-
-
-### IRC, freenode, #hurd, 2013-09-16
-
-    <gnu_srs> tschwinge: Is gdb watch known to fail on hurd? It hangs for me
-      when logged in via ssh.
-    <tschwinge> gnu_srs: Don't know about GDB's watch command.  Are you sure it
-      is hanging?
diff --git a/open_issues/blkrrpart_ioctl.mdwn b/open_issues/blkrrpart_ioctl.mdwn
deleted file mode 100644
index b3a91bfb..00000000
--- a/open_issues/blkrrpart_ioctl.mdwn
+++ /dev/null
@@ -1,32 +0,0 @@
-[[!meta copyright="Copyright © 2009 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]]."]]"""]]
-
-[[!meta title="BLKRRPART IOCTL"]]
-
-[[!tag open_issue_glibc open_issue_hurd open_issue_gnumach]]
-
-Just like in other Unix systems one can, for example, use `fdisk` or `parted`
-to manage hard disks' partition tables.  After doing changes to a disk's
-partition table, the kernel has to be instructed to reinitialize its internal
-data structures: where does a partition begin, where does it end, etc.
-
-With `fdisk` and friends this is done on Linux with the `BLKRRPART` IOCTL,
-which is used to tell the kernel to reread the disk's partition table.
-
-`parted` also uses this interface on Linux, but for GNU Hurd, the corresponding
-function, `libparted/arch/gnu.c (gnu_disk_commit)`, doesn't do anything at all.
-The infrastructure in [[GNU_Mach|microkernel/mach/gnumach]] is already there,
-`linux/src/drivers/block/ide.c (ide_ioctl) <BLKRRPART>` and
-`linux/src/drivers/scsi/sd_ioctl.c (sd_ioctl) <BLKRRPART>`, but the IOCTL needs
-to be routed from `libparted` through [[hurd/glibc]]'s Hurd IOCTL interface,
-through Hurd's [[hurd/libstore]], to [[GNU_Mach|microkernel/mach/gnumach]].
-
-This is not a huge project, and actually one that is suitable for someone who
-wants to start with hacking the system.
diff --git a/open_issues/boehm_gc.mdwn b/open_issues/boehm_gc.mdwn
deleted file mode 100644
index 2913eea8..00000000
--- a/open_issues/boehm_gc.mdwn
+++ /dev/null
@@ -1,553 +0,0 @@
-[[!meta copyright="Copyright © 2010, 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]]."]]"""]]
-
-Here's what's to be done for maintaining Boehm GC.
-
-This one does need Hurd-specific configuration.
-
-It is, for example, used by [[/GCC]] (which has its own fork), so any changes
-committed upstream should very like also be made there.
-
-[[!toc levels=2]]
-
-
-# [[General information|/boehm_gc]]
-
-
-# Configuration
-
-<!--
-
-git checkout reviewed
-git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..upstream/master
--i
-/^commit |^---$|hurd|linux|glibc
-
--->
-
-Last reviewed up to the 5f492b98dd131bdd6c67eb56c31024420c1e7dab (2012-06-08)
-sources, and for `libatomic_ops` to the
-6a0afde033f105c6320f1409162e3765a1395bfd (2012-05-15) sources.
-
-  * `configure.ac`
-
-      * `PARALLEL_MARK` is not enabled; doesn't make sense so far.
-
-      * `*-*-kfreebsd*-gnu` defines `USE_COMPILER_TLS`.  What's this, and
-        why does not other config?
-
-      * TODO
-
-            [ if test "$enable_gc_debug" = "yes"; then
-                AC_MSG_WARN("Should define GC_DEBUG and use debug alloc. in clients.")
-                AC_DEFINE([KEEP_BACK_PTRS], 1,
-                          [Define to save back-pointers in debugging headers.])
-                keep_back_ptrs=true
-                AC_DEFINE([DBG_HDRS_ALL], 1,
-                          [Define to force debug headers on all objects.])
-                case $host in
-                  x86-*-linux* | i586-*-linux* | i686-*-linux* | x86_64-*-linux* )
-                    AC_DEFINE(MAKE_BACK_GRAPH)
-                    AC_MSG_WARN("Client must not use -fomit-frame-pointer.")
-                    AC_DEFINE(SAVE_CALL_COUNT, 8)
-                  ;;
-            AM_CONDITIONAL([KEEP_BACK_PTRS], [test x"$keep_back_ptrs" = xtrue])
-
-  * `configure.host`
-
-    Nothing.
-
-  * `Makefile.am`, `include/include.am`, `cord/cord.am`, `doc/doc.am`,
-    `tests/tests.am`
-
-    Nothing.
-
-  * `include/gc_config_macros.h`
-
-    Should be OK.
-
-  * `include/private/gcconfig.h`
-
-    Hairy.  But should be OK.  Search for *HURD*, compare to *LINUX*,
-    *I386* case.
-
-    See `doc/porting.html` and `doc/README.macros` (and others) for
-    documentation.
-
-    *LINUX* has:
-
-      * `#define LINUX_STACKBOTTOM`
-
-        Defined instead of `STACKBOTTOM` to have the value read from `/proc/`.
-
-      * `#define HEAP_START (ptr_t)0x1000`
-
-        May want to define it for us, too?
-
-      * `#ifdef USE_I686_PREFETCH`, `USE_3DNOW_PREFETCH` --- [...]
-
-        Apparently these are optimization that we also could use.  Have a
-        look at *LINUX* for *X86_64*, which uses `__builtin_prefetch`
-        (which Linux x86 could use, too?).
-
-      * TODO
-
-            #if defined(LINUX) && defined(USE_MMAP)
-                /* The kernel may do a somewhat better job merging mappings etc.    */
-                /* with anonymous mappings.                                         */
-            #   define USE_MMAP_ANON
-            #endif
-
-      * TODO
-
-            #if defined(GC_LINUX_THREADS) && defined(REDIRECT_MALLOC)
-                /* Nptl allocates thread stacks with mmap, which is fine.  But it   */
-                /* keeps a cache of thread stacks.  Thread stacks contain the       */
-                /* thread control blocks.  These in turn contain a pointer to       */
-                /* (sizeof (void *) from the beginning of) the dtv for thread-local */
-                /* storage, which is calloc allocated.  If we don't scan the cached */
-                /* thread stacks, we appear to lose the dtv.  This tends to         */
-                /* result in something that looks like a bogus dtv count, which     */
-                /* tends to result in a memset call on a block that is way too      */
-                /* large.  Sometimes we're lucky and the process just dies ...      */
-                /* There seems to be a similar issue with some other memory         */
-                /* allocated by the dynamic loader.                                 */
-                /* This should be avoidable by either:                              */
-                /* - Defining USE_PROC_FOR_LIBRARIES here.                          */
-                /*   That performs very poorly, precisely because we end up         */
-                /*   scanning cached stacks.                                        */
-                /* - Have calloc look at its callers.                               */
-                /*   In spite of the fact that it is gross and disgusting.          */
-                /* In fact neither seems to suffice, probably in part because       */
-                /* even with USE_PROC_FOR_LIBRARIES, we don't scan parts of stack   */
-                /* segments that appear to be out of bounds.  Thus we actually      */
-                /* do both, which seems to yield the best results.                  */
-            
-            #   define USE_PROC_FOR_LIBRARIES
-            #endif
-
-      * TODO
-
-            # if defined(GC_LINUX_THREADS) && defined(REDIRECT_MALLOC) \
-                 && !defined(INCLUDE_LINUX_THREAD_DESCR)
-                /* Will not work, since libc and the dynamic loader use thread      */
-                /* locals, sometimes as the only reference.                         */
-            #   define INCLUDE_LINUX_THREAD_DESCR
-            # endif
-
-      * TODO
-
-            # if defined(UNIX_LIKE) && defined(THREADS) && !defined(NO_CANCEL_SAFE) \
-                 && !defined(PLATFORM_ANDROID)
-                /* Make the code cancellation-safe.  This basically means that we   */
-                /* ensure that cancellation requests are ignored while we are in    */
-                /* the collector.  This applies only to Posix deferred cancellation;*/
-                /* we don't handle Posix asynchronous cancellation.                 */
-                /* Note that this only works if pthread_setcancelstate is           */
-                /* async-signal-safe, at least in the absence of asynchronous       */
-                /* cancellation.  This appears to be true for the glibc version,    */
-                /* though it is not documented.  Without that assumption, there     */
-                /* seems to be no way to safely wait in a signal handler, which     */
-                /* we need to do for thread suspension.                             */
-                /* Also note that little other code appears to be cancellation-safe.*/
-                /* Hence it may make sense to turn this off for performance.        */
-            #   define CANCEL_SAFE
-            # endif
-
-      * `CAN_SAVE_CALL_ARGS` vs. -fomit-frame-pointer now being on by
-        default for Linux x86 IIRC?  (Which is an [[!taglink
-        open_issue_gcc]] for not including us.)
-
-      * TODO
-
-            # if defined(REDIRECT_MALLOC) && defined(THREADS) && !defined(LINUX)
-            #   error "REDIRECT_MALLOC with THREADS works at most on Linux."
-            # endif
-
-
-    *HURD* has:
-
-      * `#define STACK_GROWS_DOWN`
-
-      * `#define HEURISTIC2`
-
-        Defined instead of `STACKBOTTOM` to have the value probed.
-
-        Linux also has this:
-
-            #if defined(LINUX_STACKBOTTOM) && defined(NO_PROC_STAT) \
-                && !defined(USE_LIBC_PRIVATES)
-                /* This combination will fail, since we have no way to get  */
-                /* the stack base.  Use HEURISTIC2 instead.                 */
-            #   undef LINUX_STACKBOTTOM
-            #   define HEURISTIC2
-                /* This may still fail on some architectures like IA64.     */
-                /* We tried ...                                             */
-            #endif
-
-        Being on [[glibc]], we could perhaps do similar as `USE_LIBC_PRIVATES`
-        instead of `HEURISTIC2`.  Pro: avoid `SIGSEGV` (and general fragility)
-        during probing at startup (if I'm understanding this correctly).  Con:
-        rely on glibc internals.  Or we instead add support to parse
-        [[`/proc/`|hurd/translator/procfs]] (can even use the same as Linux?),
-        or use some other interface.  [[!tag open_issue_glibc]]
-        This is also likely the issue causing the GDB [[!tag open_issue_gdb]]
-        `GC_find_limit_with_bound` SIGSEGV startup confusion described in
-        [[binutils]].
-
-      * `#define SIG_SUSPEND SIGUSR1`, `#define SIG_THR_RESTART SIGUSR2`
-
-      * We don't `#define MPROTECT_VDB` (WIP comment); but Linux neither.
-
-      * Where does our `GETPAGESIZE` come from?  Should we `#include
-        <unistd.h>` like it is done for *LINUX*?
-
-  * `include/gc_pthread_redirects.h`
-
-      * TODO
-
-        Cancellation stuff is Linux-only.  In other places, too.
-
-  * `mach_dep.c`
-
-      * `#define NO_GETCONTEXT`
-
-        [[!taglink open_issue_glibc]], but this is not a real problem here,
-        because we can use the following GCC internal function without much
-        overhead:
-
-      * `GC_with_callee_saves_pushed`
-
-        The `HAVE_BUILTIN_UNWIND_INIT` case is ours.
-
-  * `os_dep.c`
-
-      * `read`
-
-        Sure that it doesn't internally (in [[glibc]]) use `malloc`.  Probably
-        only / mostly (?) a problem for `--enable-redirect-malloc`
-        configurations?  Linux with threads uses `readv`.
-
-      * TODO.
-
-  * `dyn_load.c`
-
-    For `DYNAMIC_LOADING`.  TODO.
-
-  * `pthread_support.c`, `pthread_stop_world.c`
-
-    TODO.
-
-  * TODO.
-
-    Other files also contain *LINUX* and other conditionals.
-
-  * `libatomic_ops/`
-
-      * `configure.ac`
-
-        Nothing.
-
-      * `Makefile`, `src/Makefile`, `src/atomic_ops/Makefile`,
-        `src/atomic_ops/sysdeps/Makefile`, `doc/Makefile`, `tests/Makefile`
-
-        Nothing.
-
-      * `src/atomic_ops/sysdeps/gcc/x86.h`
-
-        Nothing.
-
-  * b8b65e8a5c2c4896728cd00d008168a6293f55b1 configure.ac probably not all
-    correct.
-
-  * `mmap`, b64dd3bc1e5a23e677c96b478d55648a0730ab75
-
-  * `parallel mark`, 07c2b8e455c9e70d1f173475bbf1196320812154, pass
-    `--disable-parallel-mark` or enable for us, too?
-
-  * `HANDLE_FORK`, e9b11b6655c45ad3ab3326707aa31567a767134b,
-    806d656802a1e3c2b55cd9e4530c6420340886c9,
-    1e882b98c2cf9479a9cd08a67439dab7f9622924
-
-  * Check `include/private/thread_local_alloc.h` re
-    `USE_COMPILER_TLS`/`USE_PTHREAD_SPECIFIC`.
-
-
-# Build
-
-Here's a log of a binutils build run; this is from the
-5f492b98dd131bdd6c67eb56c31024420c1e7dab (2012-06-08) sources, and for
-`libatomic_ops` for the 6a0afde033f105c6320f1409162e3765a1395bfd (2012-05-15)
-sources, run on kepler.SCHWINGE and coulomb.SCHWINGE.
-
-    $ export LC_ALL=C
-    $ (cd ../master/ && ln -sfn ../libatomic_ops/master libatomic_ops)
-    $ (cd ../master/ && autoreconf -vfi)
-    $ ../master/configure --prefix="$PWD".install SHELL=/bin/bash CC=gcc-4.6 CXX=g++-4.6 --enable-cplusplus --enable-gc-debug --enable-gc-assertions --enable-assertions 2>&1 | tee log_build
-    [...]
-    $ make 2>&1 | tee log_build_
-    [...]
-
-Different hosts may default to different shells and compiler versions; thus
-harmonized.  Using bash instead of dash as otherwise libtool explodes.
-
-This takes up around X MiB, and needs roughly X min on kepler.SCHWINGE and
-X min on coulomb.SCHWINGE.
-
-<!--
-
-    $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-check) 2>&1 | tee log_install && test -f .go-check && { make -k check 2>&1 | tee log_check; (cd libatomic_ops/ && make -k check) 2>&1 | tee log_check_; }
-
--->
-
-## Analysis
-
-    $ ssh kepler.SCHWINGE 'cd tmp/source/boehm-gc/ && cat master.build/log_build* | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/linux/log_build
-    $ ssh coulomb.SCHWINGE 'cd tmp/boehm-gc/ && cat master.build/log_build* | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/hurd/log_build
-    $ diff -wu <(sed -f toolchain/logs/boehm-gc/linux/log_build.sed < toolchain/logs/boehm-gc/linux/log_build) <(sed -f toolchain/logs/boehm-gc/hurd/log_build.sed < toolchain/logs/boehm-gc/hurd/log_build) > toolchain/logs/boehm-gc/log_build.diff
-
-  * only GNU/Linux: `configure: WARNING: "Explicit GC_INIT() calls may be
-    required."`
-
-  * only GNU/Linux: `configure: WARNING: "Client must not use
-    -fomit-frame-pointer."`
-
-
-# Install
-
-    $ make install 2>&1 | tee log_install
-    [...]
-
-This takes up around X MiB, and needs roughly X min on kepler.SCHWINGE and X
-min on coulomb.SCHWINGE.
-
-
-## Analysis
-
-    $ ssh kepler.SCHWINGE 'cd tmp/source/boehm-gc/ && cat master.build/log_install | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/linux/log_install
-    $ ssh coulomb.SCHWINGE 'cd tmp/boehm-gc/ && cat master.build/log_install | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/hurd/log_install
-    $ diff -wu toolchain/logs/boehm-gc/linux/log_install toolchain/logs/boehm-gc/hurd/log_install > toolchain/logs/boehm-gc/log_install.diff
-
-
-# Testsuite
-
-    $ make -k check
-    [...]
-    $ (cd libatomic_ops/ && make -k check)
-    [...]
-
-This needs roughly X min on kepler.SCHWINGE and X min on coulomb.SCHWINGE.
-
-
-## Analysis
-
-    $ ssh kepler.SCHWINGE 'cd tmp/source/boehm-gc/ && cat master.build/log_check* | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/linux/log_check
-    $ ssh coulomb.SCHWINGE 'cd tmp/boehm-gc/ && cat master.build/log_check* | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/hurd/log_check
-    $ diff -wu <(sed -f toolchain/logs/boehm-gc/linux/log_check.sed < toolchain/logs/boehm-gc/linux/log_check) <(sed -f toolchain/logs/boehm-gc/hurd/log_check.sed < toolchain/logs/boehm-gc/hurd/log_check) > toolchain/logs/boehm-gc/log_check.diff
-
-There are different configurations possible, but in general, the testsuite
-restults of GNU/Linux and GNU/Hurd look very similar.
-
-  * GNU/Hurd is missing `Call chain at allocation: [...]` output.
-
-    `os_dep.c`:`GC_print_callers`
-
-
-# TODO
-
-  * What are other applications to test Boehm GC?  Also especially in
-    combination with [[/libpthread]] and dynamic loading of shared libraries?
-
-      * There are patches (apparently not committed) that GCC itself can use
-        it, too: <http://gcc.gnu.org/wiki/Garbage_collection_tuning>.
-
-      * There's been some talking about it on GNU guile mailing lists, and two
-        Git branches (2010-12-15: last change 2009-09).
-
-      * <http://www.hpl.hp.com/personal/Hans_Boehm/gc/#users>
-
-
-## IRC, OFTC, #debian-hurd, 2012-02-05
-
-[[!tag open_issue_porting]]
-
-    <pinotree> youpi: i think i found out the possible cause of the ecl and
-      mono issuess
-    <pinotree> -s
-    <youpi> oh
-    <pinotree> basically, we don't have the realtime signals (so no
-      SIGRTMIN/SIGRTMAX defined), hence things use either SIGUSR1 or
-      SIGUSR2... which are used in libgc to resp. stop/resume threads when
-      "collecting"
-    <pinotree> i just patched ecl to use SIGINFO instead of SIGUSR1 (used when
-      no SIGRTMIN+2 is available), and it seems going on for a while
-    <youpi> uh, why would SIGINFO work better than SIGUSR1?
-    <pinotree> it was a test, i tried the first "not common" signal i saw
-    <pinotree> my test was, use any signal different than USR1/2
-    <youpi> ah, sorry, I hadn't understood
-    <youpi> you mean there's a conflict between ecl and mono using SIGUSR1, as
-      well as libgc?
-    <pinotree> yes
-    <pinotree> for example, in ecl sources see src/c/unixint.d,
-      install_process_interrupt_handler()
-    <youpi> SIGINFO seems a sane choice
-    <youpi> SIGPWR could have been a better choice if it was available :)
-    <pinotree> i would have chose an "unassigned" number, say SIGLOST (the
-      bigger one) + 10, but it would be greater than _NSIG (and thus discarded)
-    <youpi> not a good idea indeed
-    <pinotree> it seems that linux, beside the range for rt signals, has some
-      "free space"
-    <pinotree> i'll start now another ecl build, from scratch this time, with
-      s/SIGUSR1/SIGINFO/ (making sure ctags won't bother), and if it works i'll
-      update svante's bug
-
-    <pinotree> mmap(...PROT_NONE...) failed
-    <pinotree> hmm...
-    <pinotree> apparently enabling MMAP_ANON in mono's libgc copy was a good
-      step, let's see
-
-
-### IRC, OFTC, #debian-hurd, 2012-03-18
-
-    <pinotree> youpi: mono is afflicted by the SIGUSR1/2 conflict with libgc
-    <youpi> pinotree: didn't we have a solution for that?
-    <pinotree> well, it works just for one signal
-    <pinotree> the ideal solution would be having a range for RT signals, and
-      make libgc use RTMIN+5/6, like done on most of other OSes
-    <youpi> but we don't have RT signals, do we?
-    <pinotree> right :(
-
-
-### IRC, freenode, #hurd, 2012-03-21
-
-    <pinotree> civodul: given we have to realtime signals (so no range of
-      signals for them), libgc uses SIGUSR1/2 instead of using SIGRTMIN+5/6 for
-      its thread synchronization stuff
-    <pinotree> civodul: which means that if an application using libgc then
-      sets its own handlers for either of SIGUSR1/2, hell breaks
-    <civodul> pinotree: ok
-    <civodul> pinotree: is it a Debian-specific change, or included upstream?
-    <pinotree> libgc using SIGUSR1/2? upstream
-    <civodul> ok
-
-
-### IRC, freenode, #hurd, 2013-09-03
-
-    <congzhang> braunr: when will libc malloc say memory corruption?
-    <braunr> congzhang: usually on free
-    <braunr> sometimes on alloc
-    <congzhang> and after one thread be created
-    <congzhang> I want to know why and how to find the source
-    <congzhang> does libgc work well on hurd?
-    <braunr> i don't think it does
-    <congzhang> so , why it can't?
-    <braunr> congzhang: what ?
-    <congzhang> libgc was not work on hurd
-    <pinotree> why?
-    <congzhang> I try porting dotgnu
-    <braunr> ah
-    <braunr> nested signal handling
-    <congzhang> one program always receive Abort signal
-    <pinotree> and why it should be a problem in libgc?
-    <congzhang> for malloc memory corruption
-    <braunr> libgc relies on this
-    <congzhang> yes
-    <congzhang> so, is there a workaround to make it work? 
-    <braunr> show the error please
-    <congzhang> http://paste.debian.net/34416/
-    <pinotree> where's libgc?
-    <congzhang> i compile dotgnu with enable-gc
-    <pinotree> so?
-    <congzhang> I am not sure about it
-    <pinotree> so why did you say earlier that libgc doesn't work?
-    <congzhang> because after I see one thread was created notice by gdb, it
-      memory corruption
-    <pinotree> so what?
-    <congzhang> maybe gabage collection happen, and gc thread start
-    <pinotree> that's speculation
-    <pinotree> you cannot debug things speculating on code you don't know
-    <pinotree> less speculation and more in-deep debugging, please
-    * congzhang I try again, to check weather thread list changing
-    <congzhang> sorry for this
-    <braunr> it simply looks like a real memory corruption (an overflow)
-    <congzhang> maybe PATH related problem
-    <pinotree> PATH?
-    <congzhang> yes
-    <braunr> PATH_MAX
-    <braunr> but unlikely
-    <congzhang> csant do path traverse
-    <congzhang> I fond the macro
-    <congzhang> found
-    <congzhang> #if defined(__sun__) || defined(__BEOS__)
-    <congzhang> #define     BROKEN_DIRENT   1
-    <congzhang> #endif
-    <congzhang> and so for hurd?
-    <pinotree> BROKEN_DIRENT doesn't say much about what it does
-    <WhiteKIBA> nope
-    <WhiteKIBA> whoops
-    <congzhang> it seems other port meet the trouble too
-    <pinotree> which trouble?
-    <congzhang> http://comments.gmane.org/gmane.comp.gnu.dotgnu.developer/3642
-    <congzhang> (gdb) ptype struct dirent
-    <congzhang> type = struct dirent {
-    <congzhang>     __ino_t d_ino;
-    <congzhang>     unsigned short d_reclen;
-    <congzhang>     unsigned char d_type;
-    <congzhang>     unsigned char d_namlen;
-    <congzhang>     char d_name[1];
-    <congzhang> }
-    <congzhang>  
-    <congzhang> d_name should be char[PATH_MAX]?
-    <congzhang> and
-      http://libjit-linear-scan-register-allocator.googlecode.com/svn/trunk/pnet/support/dir.c
-    <pinotree> no
-    <braunr> stop pasting that much
-    <_d3f> uhm PATH_MAX on the hurd?
-    <braunr> and stop saying nonsense
-    <congzhang> sorry, i think four line was not worth to pastbin 
-    <pinotree> they are 8
-    <congzhang> never again
-    <braunr> just try by defining BROKEN_DIRENT to 1 in all cases and see how
-      it goes
-    * congzhang read dir.c again
-    <congzhang> braunr: it does not crash this time, I do more test
-
-
-#### IRC, freenode, #hurd, 2013-09-04
-
-    <congzhang> hi, I am dotgnu work on hurd, and even winforms app 
-    <congzhang> s/am/make
-    <congzhang> and maybe c# hello world translate another day :)
-
-
-### IRC, freenode, #hurd, 2013-12-16
-
-    <braunr> gnu_srs: ah, libgc
-    <braunr> there are signal-related problems with libgc
-
-
-## Leak Detection
-
-### IRC, freenode, #hurd, 2013-10-17
-
-    <teythoon> I spent the last two days integrating libgc - the boehm
-      conservative garbage collector - into hurd
-    <teythoon> it can be used in leak detection mode
-    <azeem> whoa, cool
-    <teythoon> and it actually kind of works, finds malloc leaks in translators
-    <braunr> i think there were problems with signal handling in libgc
-    <braunr> i'm not sure we support nested signal handling well
-    <teythoon> yes, I read about them
-    <teythoon> libgc uses SIGUSR1/2, so any program installing handlers on them
-      will break
-    <azeem> (which is not a problem on Linux, cause there some RT-signals or so
-      are used)
-    <teythoon> yes
diff --git a/open_issues/bpf.mdwn b/open_issues/bpf.mdwn
deleted file mode 100644
index d051c2d8..00000000
--- a/open_issues/bpf.mdwn
+++ /dev/null
@@ -1,654 +0,0 @@
-[[!meta copyright="Copyright © 2009, 2012, 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]]."]]"""]]
-
-[[!meta title=BPF]]
-
-[[!tag open_issue_gnumach open_issue_hurd]]
-
-This is a collection of resources concerning *Berkeley Packet Filter*s.
-
-
-# Documentation
-
-  * Wikipedia: [[!wikipedia "Berkeley Packet Filter"]]
-
-  * [The Packet Filter: An Efficient Mechanism for User-level Network
-    Code](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.8755),
-    1987, Jeffrey C. Mogul, Richard F. Rashid, Michael J. Accetta
-
-  * [The BSD Packet Filter: A New Architecture for User-level Packet
-    Capture](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.7849),
-    1992, Steven Mccanne, Van Jacobson
-
-  * [Protocol Service Decomposition for High-Performance
-    Networking](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.30.8387),
-    1993, Chris Maeda, Brian N. Bershad
-
-  * [Efficient Packet Demultiplexing for Multiple Endpoints and Large
-    Messages](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.46.44),
-    1994, Masanobu Yuhara Fujitsu, Masanobu Yuhara, Brian N. Bershad, Chris
-    Maeda, J. Eliot, B. Moss
-
-  * ... and many more
-
-
-# Implementation
-
-  * [[community/HurdFr]]
-
-      * <http://wiki.hurdfr.org/index.php/BPF>
-
-      * <http://wiki.hurdfr.org/index.php/Reseau_dans_gnumach>
-
-      * Git repository: <http://rcs-git.duckcorp.org/hurdfr/bpf.git/>
-
-    The patch for [[GNU Mach|microkernel/mach/gnumach]] is expected to be
-    complete and functional, the [[hurd/translator]] less so -- amongst others,
-    there are unresolved issues concerning support of [[hurd/glibc/IOCTL]]s.
-
-      * <http://lists.gnu.org/archive/html/bug-hurd/2006-03/msg00025.html>
-
-  * [[zhengda]]
-
-      * [[!GNU_Savannah_bug 25054]] -- Kernel panic with eth-multiplexer
-
-      * [[!GNU_Savannah_patch 6619]] -- pfinet uses the virtual interface
-
-      * [[!GNU_Savannah_patch 6620]] -- pfinet changes its filter rules with
-        its IP address
-
-      * [[!GNU_Savannah_patch 6621]] -- pfinet sets the mach device into the
-        promiscuous mode
-
-      * [[!GNU_Savannah_patch 6622]] -- pfinet uses the BPF filter
-
-      * [[!GNU_Savannah_patch 6851]] -- fix a bug in BPF
-
-
-# IRC
-
-## IRC, freenode, #hurd, 2012-01-13
-
-    <braunr> hm, i think the bpf code needs a complete redesign :p
-    <braunr> unless it's actually a true hurdish way to do things
-    <braunr> antrik: i need your help :)
-    <braunr> antrik: I need advice on the bpf "architecture"
-    <braunr> the current implementation uses a translator installed at /dev/bpf
-    <braunr> which means packets from the kernel are copied to that translator
-      and then to client applications
-    <braunr> does that seem ok to you ?
-    <braunr> couldn't the translator be used to set a direct link between the
-      kernel and the client app ?
-    <braunr> which approach seems the more Hurdish to you ? (<= this is what I
-      need your help on)
-    <pinotree> braunr: so there would be a roundtrip like kernel → bpf
-      translator → pfinet?
-    <antrik> braunr: TBH, I don't see why we need a BPF translator at all...
-    <braunr> antrik: it handles the ioctls
-    <braunr> pinotree: pfinet isn't involved (it was merely modified to use the
-      "new" filter format to specify it used the old packet filter, and not
-      bpf)
-    <antrik> braunr: do we really need to emulate the ioctl()s? can't we assume
-      that all packages using BPF will just use libpcap?
-    <antrik> (and even if we *do* want to emulate ioctl()s, why can't we handle
-      this is libc?)
-    <braunr> antrik: that's what i'm wondering actually
-    <braunr> even if assuming all packages use libpcap, i'd like our bpf
-      interface to be close to what bsds have, and most importantly, what
-      libpcap expects from a bpf interface
-    <antrik> well, why? if we already have a library handling the abstraction,
-      I don't see much point in complicating the design and use by adding
-      another layer :-)
-    <braunr> so you would advise adapting libpcap to include a hurd specific
-      module ?
-    <antrik> there are two reasons for adding translators: more robustness or
-      more flexibility... so far I don't see how a BPF translator would add
-      either
-    <braunr> right
-    <antrik> yes
-    <braunr> so we'd end up with a bpf-like interface, the same instructions
-      and format, with different control calls
-    <antrik> right
-    <antrik> note that I had more or less the same desicion to make for KGI
-      (emulate Linux/BSD ioctl()s, or implement a backend in libggi for
-      handling Hurd-specific RPC; and after much consideration, I decided on
-      the latter)
-
-
-## IRC, freenode, #hurd, 2012-01-16
-
-    <braunr> antrik: is there an existing facility to easily give a send right
-      to the device master port to a task ?
-    <braunr> another function of the bpf translator is to handle the /dev/bpf
-      node, and most importantly its permissions
-    <braunr> so that users which have read/write access to the node have access
-      to the packet filter
-    <braunr> i guess the translator could limit itself to that functionality
-    <braunr> and then provide a device port on which libpcap operates directly
-      by means of device_{g,s}et_status/device_set_filter
-    <antrik> braunr: I don't see the point in seperating permissions for filter
-      from permissions from general network device access...
-    <antrik> as for device master port, all root tasks can obtain it from proc
-      IIRC
-    <braunr> antrik: yes, but how do we allow non-root users to access that
-      facility ?
-    <braunr> on a unix like system, it's a matter of changing the permissions
-      of /dev/bpf
-    <antrik> with devnode, non-root users can get access to specific device
-      nodes, including network devices
-    <braunr> i can't imagine the hurd being less flexible for that
-    <braunr> ah devnode
-    <braunr> good
-    <antrik> so we can for example make /dev/eth0 accessible by users of some
-      group
-    <braunr> what's devnode exactly ?
-    <antrik> it's a very simple translator that implements an FS node that
-      looks somewhat like a file, but the only operation it supports is
-      obtaining a pseudo device master port, giving access to a specific Mach
-      device
-    <braunr> is it already part of the hurd ?
-    <braunr> or hurdextras maybe ?
-    <antrik> it's only in zhengda's branch
-    <braunr> ah
-    <antrik> needed for both eth-multipexer and DDE
-    <braunr> and bpf soon i guess
-    <antrik> indeed :-)
-    <braunr> "obtaining a pseudo device master port", i believe you meant a
-      pseudo device port
-    <antrik> I must admit that I don't remember exactly whether devnode proxies
-      device_open(), so clients direct get a port to the device in question, or
-      whether it implements a pseudo device master port...
-    <antrik> but definitely not a pseudo device port :-)
-    <braunr> i'm almost positive it gives the target device port, otherwise i
-      don't see the point
-    <braunr> i don't understand the user of the "pseudo" word here either
-    <braunr> s/user/use/
-    <braunr> aiui, devnode should be started as root (or in any way which gives
-      it the device master port)
-    <antrik> the point is that the client doesn't need to know the Mach device
-      name, and also is not bound to actual kernel devices
-    <braunr> and when started, implement the required permissions before giving
-      clients a device port to the specific device it was installed for
-    <braunr> right
-    <braunr> but it mustn't be a proxy
-    <antrik> yes, devnode needs access to either the real master device port
-      (for kernel devices), or one provided by eth-multiplexer or the DDE
-      network driver
-    <braunr> well, a very simple proxy for deviceopen
-    <braunr> ok
-    <braunr> that seems exactly what i wanted to do
-    <braunr> we now need to see if we can integrate it separately
-    <braunr> create a separate branch that works for the current gnumach code,
-      and merge dde/other specific code later on
-    <antrik> you mean independent of eth-multiplexer or DDE? yes, it was
-      generally agreed that devnode is a good idea in any case. I have no idea
-      why there are no device nodes for network devices on other UNIX
-      systems...
-    <braunr> i've been wondering that for years too :)
-    <antrik> zhengda's branch has a pfinet modified to a) use devnode, and b)
-      use BPF
-    <braunr> why bpf ?
-    <braunr> for more specific filters maybe ?
-    <antrik> hm... don't remember whether there was any technical reason for
-      going with BPF; I guess it just seemed more reasonable to invest new work
-      in BPF rather than obsolete Mach-specific NPF...
-    <braunr> cspf could be removed altogether, i agree
-    <antrik> another plus side of his modified pfinet is that it actually sets
-      an appropriate filter for TCP/IP and the IP in use, rather than just
-      setting a dummy filter catching app packets (including those irrelevant
-      to the specific pfinet instance)
-    <antrik> err... catching all packets
-    <braunr> that's what i meant by "for more specific filters maybe ?"
-    <braunr> he was probably more comfortable with the bpf interface to write
-      his filter rules
-    <antrik> well, it would probably be doable with NPF too :-) so by itself
-      it's not a reason for switching to BPF...
-    <antrik> it's rather the other way around: as it was necessary to implement
-      filters in eth-multiplexer, and implementing BPF seemed more reasoable,
-      pfinet had to be changed to use BPF...
-    <braunr> antrik: where is zhengda's branch btw ?
-    <antrik> (I guess using proper filters with eth-multiplexer is not strictly
-      necessary; but it would be a major performance hit not to)
-    <antrik> it's in incubator.git
-    <antrik> but it's very messy
-    <braunr> ok
-    <antrik> at some point I asked him to provide cleaned up branches, and I'm
-      pretty sure he said he did, but I totally fail to remember where he
-      published them :-(
-    <braunr> hm, i don't like how devnode is "architectured" :/
-    <braunr> but it makes things a little more easy to get working i guess
-    <LarstiQ> antrik: any idea what to grep the logs on for that?
-    <braunr> ok never mind, devnode is fine
-    <braunr> exactly what i need
-    <braunr> i wonder however if it shouldn't be improved to better handle
-      permissions
-    <braunr> ok, never mind either, permission handling is fine
-    <braunr> so what are we waiting for ? :)
-    <antrik> I remember that there were some issues with permission handling,
-      but I don't remember whether all were fixed :-(
-    <antrik> LarstiQ: hm... good question...
-    <braunr> ah ?
-    <braunr> hm actually, there could be issues for packet filters, yes
-    <braunr> i guess we want to allow e.g. read-only opens for capture only
-    <antrik> braunr: that would have to be handled by the actual BPF
-      implementation I'd say
-    <braunr> it should already be the case
-    <antrik> what's the problem then?
-    <braunr> but when the actual device_open() is performed, the appropriate
-      permissions must be provided
-    <braunr> and checking those is the responsibility of the proxy, devnode in
-      this case
-    <antrik> and it doesn't do that?
-    <braunr> apparently not
-    <braunr> the only check is against the device name
-    <braunr> i'll begin playing with that first
-    <antrik> I vaguely remember that there has been discussion about the
-      relation of underlying device open mode and devnode open mode... but I
-      don't remember the outcome. in fact it was probably one of the
-      discussions I never got around to follow up on... :-(
-    <antrik> before you begin playing, take a look at the relevant messages in
-      the ML archive :-)
-    <antrik> must have been around two years ago
-    <braunr> ok
-    <antrik> some thread with me and scolobb (Sergiu Ivanov +- spelling) and
-      probably zhengda
-    <antrik> there might also be some outstanding patch(es) from scolobb, not
-      sure
-
-
-## IRC, freenode, #hurd, 2012-01-17
-
-    <braunr> antrik: i think i found the thread you mentioned about devnode
-    <braunr> neither sergiu nor zhengda considered the use of a read-only
-      device for packet filtering
-    <braunr> leading to assumptions such as "only receiving packets
-    <braunr> is not terribly useful, in view of the fact that you have to at
-      least
-    <braunr> request them, which implies *sending* packets :-)
-    <braunr> "
-    <braunr> IMO, devnode should definitely check its node permissions to build
-      the device open flags
-    <braunr> good news is that it doesn't depend on anything specific to other
-      incubator projects
-    <braunr> making it almost readily mergeable in the hurd
-    <braunr> i'm not sure devnode is an appropriate name though
-    <braunr> maybe something like device, or devproxy
-    <braunr> proxy-devopen maybe
-    <antrik> braunr: well, I don't remember the details of the disucssion; but
-      as I mentioned in some mail, I did actually want to write a followup,
-      just didn't get around to it... so I was definitely not in agreement with
-      some of the statements made by others. I just don't remember on which
-      point :-)
-    <antrik> which thread was it?
-    <antrik> anyways, this should in no way be specific to network
-      devices... the idea is simply that if the client has only read
-      permissions on the device node, it should only get to open the underlying
-      device for read. it's up to the kernel to handle the read-only status for
-      the device once it's opened
-    <antrik> as for the naming, the idea is that devnode simply makes Mach
-      devices accessible through FS nodes... so the name seemed appropriate
-    <antrik> you may be right though that just "device" might be more
-      straightforward... I don't agree on the other variants
-    <braunr> antrik:
-      http://lists.gnu.org/archive/html/bug-hurd/2009-12/msg00155.html
-    <braunr> antrik: i agree with the general idea behind permission handling,
-      i was just referring to their thoughts about it, which probably led to
-      the hard coded READ | WRITE flags
-    <antrik> braunr: unfortunately, I don't remember the context of the
-      discussion... would take me a while to get into this again :-(
-    <antrik> the discussion seems to be about eth-multiplexer as much as about
-      devnode (if not more), and I don't remember the exact interaction
-
-
-## IRC, freenode, #hurd, 2012-01-18
-
-    <braunr> so, does anyone have an objection to getting devnode into the hurd
-      and calling it something else like e.g. device ?
-    <youpi> braunr: it's Zhengda's work, right?
-    <braunr> yes
-    <youpi> I'm completely for it, it just perhaps needs some cleanup
-    <braunr> i have a few changes to add to what already exists
-    <braunr> ok
-    <braunr> well i'm assigning myself to the task
-    <antrik> braunr: I'm still not convinced just "device" is preferable
-    <antrik> perhaps machdevice ;-)
-    <antrik> but otherwise, I'd LOVE to see it in :-)
-    <braunr> i don't know .. what if the device is actually eth-multiplexer or
-      a dde one ?
-    <braunr> it's not really "mach", is it ?
-    <braunr> or do we only refer to the interface ?
-    <youpi> that translator is only for mach devices
-    <braunr> so you consider dde devices as being mach devices too ?
-    <braunr> it's a simple proxy for device_open really
-    <youpi> will these devices use that translator?
-    <youpi> ah
-    <youpi> I thought it was using a mach-specific RPC
-    <braunr> so we can consider whatever we want
-    <antrik> braunr: yes, the translator is for Mach device interface only. it
-      might be provided by other servers, but it's still Mach devices
-    <youpi> then drop the mach, yes
-    <braunr> i'd tend to agree with antrik
-    <youpi> antrik: I'd say the device interface is part of the hur dinterfaces
-    <braunr> then machdev :p
-    <braunr> no, it's really part of the mach interface
-    <youpi> it's part of the mach interface, yes
-    <youpi> but also of the Hurd, no?
-    <antrik> DDE network servers also use the Mach device interface
-    <braunr> no
-    <youpi> can't we say it's part of it?
-    <youpi> I mean
-    <youpi> even if we change the kernel
-    <braunr> dde is the only thing that implements it besides the kernel that i
-      know of
-    <youpi> we will probably want to keep the same interface
-    <braunr> yes but that's a mach thing
-    <youpi> what we have now is not necessarily a reason
-    <antrik> as for other DDE drivers, I for my part believe they should export
-      proper Hurd (UNIX) device nodes directly... but for some reason zhengda
-      insisted on implementing it as Mach devices too :-(
-    <braunr> antrik: i agree with you on that too
-    <braunr> i was a bit surprised to see the same interface was reused
-    <braunr> youpi: we can, we just have to agree on what we'll do
-    <braunr> what do you mean by "even if we change the kernel" ?
-    <antrik> the problem with "machdev" is that it might suggest the translator
-      actually implements the device... not sure whether this would cause
-      serious confusion
-    <antrik> "devopen" might be another option
-    <antrik> or "machdevopen" to be entirely verbose ;-)
-    <braunr> an option i suggested earlier which you disagreed on :p
-    <braunr> but devopen is the one i'd choose
-    <antrik> youpi: as I already mentioned in the libburn thread, I don't
-      actually think the Mach device interface is very nice; IMHO we should get
-      rid of it as soon as we can, rather than port it to other
-      architectures...
-    <antrik> but even *if* we decided to reuse it after all, it would still be
-      the Mach device interface :-)
-    <braunr> actually, zheng da already suggested that name a long time ago
-    <braunr> http://lists.gnu.org/archive/html/bug-hurd/2008-08/msg00005.html
-    <braunr> no actually antrik did eh
-    <braunr> ok let's use devopen
-    <antrik> braunr: you suggested proxy-devopen, which I didn't like because
-      of the "proxy" part :-)
-    <braunr> not only, but i don't have the logs any more :p
-    <antrik> oh, I already suggested devopen once? didn't expect myself to be
-      that consistent... ;-)
-    <antrik> braunr: you suggested device, devproxy or proxy-devopen
-    <braunr> ah, ok
-    <braunr> devopen is better
-    <antrik> I wonder whether it's more important for clarity to have "mach" in
-      there or "open"... or whether it's really too unweildy to have both
-
-
-## IRC, freenode, #hurd, 2012-01-21
-
-    <braunr> oh btw, i made devopen run today, it shouldn't be hard getting it
-      in properly
-    <braunr> patching libpcap will be somewhat trickier
-    <braunr> i don't even really need it, but it allows having user access to
-      mach devices, which is nice for the libpcap patch and tcpdump tests
-    <braunr> permission checking is actually its only purpose
-    <braunr> well, no, not really, it also allows opening devices implemented
-      by user space servers transparently
-
-
-## IRC, freenode, #hurd, 2012-01-27
-
-    <braunr> hmm, bpf needs more work :(
-    <braunr> or we can use the userspace bpf filter in libpcap, so that it
-      works with both gnumach and dde drivers
-    <antrik> braunr: there is a userspace BPF implementation in libpcap? I'm
-      surprised that zhengda didn't notice it, and ported the one from gnumach
-      instead...
-    <antrik> what is missing in the kernel implementation?
-    <braunr> antrik: filling the bpf header
-    <braunr> frankly, i'm not sure we want to bother with the kernel
-      implementation
-    <braunr> i'd like it to work with both gnumach and dde drivers
-    <braunr> and in the long run, we'll be using userspace drivers anyway
-    <braunr> the bpf header was one of the things the defunct translator did
-    <braunr> which involved ugly memcpy()s :p
-    <antrik> braunr: well, if you want to get rid of the kernel implementation,
-      basically you would have to take up eth-multiplexer and get it into
-      mainline
-    <antrik> (and make sure it's used by default in Debian)
-    <antrik> I frankly believe it's the better design anyways... but quite a
-      major change :-)
-    <braunr> not that major to me
-    <braunr> in the meantime i'll use the libpcap embedded implementation
-    <braunr> we'll have something useful faster, with minimum work when
-      eth-multiplexer is available
-    <antrik> eth-multiplexer is ready for use, it just needs to go upstream
-    <antrik> though it's probably desirable to switch it to the BPF
-      implementation from libpcap
-    <braunr> using the libpcap implementation in libpcap and in eth-multiplexer
-      are two different things
-    <braunr> the latter is preferrable
-    <braunr> (and yes, by available, i meant upstream ofc)
-    <antrik> eth-mulitplexer is already using libpcap anyways (for compiling
-      the filters); I'm sure zhengda just didn't realize it has an actual BPF
-      implementation too...
-    <braunr> we want the filter implementation as close to the packet source as
-      possible
-    <antrik> I have been using eth-multiplexer for at least two years now
-    <braunr> hm, there is a "snoop" source type, using raw sockets
-    <braunr> too far from the packet source, but i'll try it anyway
-    <braunr> hm wrong, snoop was the solaris packet filter fyi
-
-
-## IRC, freenode, #hurd, 2012-01-28
-
-    <braunr> nice, i have tcpdump working :)
-    <braunr> let's see if it's as simple with wireshark
-    <pinotree> \o/
-    <braunr> pinotree: it was actually very simple
-    <pinotree> heh, POV ;)
-    <braunr> yep, wireshark works too
-    <braunr> promiscuous mode is harder to test :/
-    <braunr> but that's a start
-
-
-## IRC, freenode, #hurd, 2012-01-30
-
-    <braunr> ok so next step: get tcpreplay working
-    <antrik> braunr: BTW, when you checked the status of the kernel BPF code,
-      did you take zhengda's enhancements/fixes into account?...
-    <braunr> no
-    <braunr> when did i check it ?
-    <antrik> braunr: well, you said the kernel BPF code has serious
-      shortcomings. did you take zhengda's changes into account?
-    <braunr> antrik: ah, when i mention the issues, i considered the userspace
-      translator only
-    <braunr> antrik: and stuff like non blocking io, exporting a selectable
-      file descriptor
-    <braunr> antrik: deb http://ftp.sceen.net/debian-hurd experimental/
-    <braunr> antrik: this is my easy to use repository with a patched
-      libpcap0.8
-    <braunr> and a small and unoptimized pcap-hurd.c module
-    <braunr> it doesn't use devopen yet
-    <braunr> i thought it would be better to have packet filtering working
-      first as a debian patch, then get the new translator+final patch upstream
-    <jkoenig> braunr, tcpdump works great here (awesome!). I'm probably using
-      exactly the same setup and "hardware" as you do, though :-P
-
-
-## IRC, freenode, #hurd, 2012-01-31
-
-    <braunr> antrik: i tend to think we need a bpf translator, or anything
-      between the kernel and libpcap to provide selectable file descriptors
-    <braunr> jkoenig: do you happen to know how mach_msg (as called in a
-      hello.c file without special macros or options) deals with signals ?
-    <braunr> i mean, is it wrapped by the libc in a version that sets errno ?
-    <jkoenig> braunr: no idea.
-    <pinotree> braunr: what's up with it? (not that i have an idea about your
-      actual question, just curious)
-    <braunr> pinotree: i'm improving signal handling in my pcap-hurd module
-    <braunr> i guess checking for MACH_RCV_INTERRUPTED will dio
-    <braunr> -INFO is correctly handled :)
-    <braunr> ok new patch seems fine
-    <antrik> braunr: selectable file descriptors?
-    <braunr> antrik: see pcap_fileno() for example
-    <braunr> it returns a file descriptor matching the underlying object
-      (usually a socket) that can be multiplexed in a select/poll call
-    <braunr> obviously a mach port alone can't do the job
-    <braunr> i've upgraded the libpcap0.8 package with improved signal handling
-      for tests
-    <antrik> braunr: no idea what you are talking about :-(
-
-
-## IRC, freenode, #hurd, 2012-02-01
-
-    <braunr> antrik: you do know about select/poll
-    <braunr> antrik: you know they work with multiple selectable/pollable file
-      descriptors
-    <braunr> on most unix systems, packet capture sources are socket
-      descriptors
-    <braunr> they're selectable/pollable
-    <antrik> braunr: what are packet capture sources?
-    <braunr> antrik: objects that provide applications with packets :)
-    <braunr> antrik: a PF_PACKET socket on Linux for example, or a Mach device,
-      or a BPF file descriptor on BSD
-    <antrik> for a single network device? or all of them?
-    <antrik> AIUI the userspace BPF implementation in libpcap opens this
-      device, waits for packets, and if any arrive, decides depending on the
-      rules whether to pass them to the main program?
-    <braunr> antrik: that's it, but it's not the point
-    <braunr> antrik: the point is that, if programs need to include packet
-      sources in select/poll calls, they need file descriptors
-    <braunr> without a translator, i can't provide that
-    <braunr> so we either decide to stick with the libpcap patch only, and keep
-      this limitation, or we write a translator that enables this feature
-    <pinotree> braunr: are the two options exclusive?
-    <braunr> pinotree: unless we implement a complete bpf translator like i did
-      years ago, we'll need a patch in libpcap
-    <braunr> pinotree: the problem with my early translator implementation is
-      that it's buggy :(
-    <braunr> pinotree: and it's also slower, as packets are small enough to be
-      passed through raw copies
-    <antrik> braunr: I'm not sure what you mean when talking about "programs
-      including packet sources". programs only interact with packet sources
-      through libpcap, right?
-    <antrik> braunr: or are you saying that programs somehow include file
-      descriptors for packet sources (how do they obtain them?) in their main
-      loop, and explicitly pass control to libpcap once something arrives on
-      the respecitive descriptors?
-    <braunr> antrik: that's the idea, yes
-    <antrik> braunr: what is the idea?
-    <braunr> 20:38 < antrik> braunr: or are you saying that programs somehow
-      include file descriptors for packet sources (how do they obtain them?) in
-      their main loop, and explicitly pass control to libpcap once something
-      arrives on the respecitive descriptors?
-    <antrik> braunr: you didn't answer my question though :-)
-    <antrik> braunr: how do programs obtain these FDs?
-    <braunr> antrik: using pcap_fileno() for example
-
-
-## IRC, freenode, #hurd, 2012-02-02
-
-    <antrik> braunr: oh right, you already mentioned that one...
-    <antrik> braunr: so you want some entity that exposes the device as
-      something more POSIXy, so it can be used in standard FS calls, unlike the
-      Mach devices used for pfinet
-    <antrik> this is probably a good sentiment in general... but I'm not in
-      favour of a special solution only for BPF. rather I'd take this as an
-      indication that we probably should expose network interfaces as something
-      file-like in general after all, and adapt pfinet, eth-multiplexer, and
-      DDE accordingly
-    <braunr> antrik: i agree
-    <braunr> antrik: eth-multiplexer would be the right place
-
-
-## IRC, freenode, #hurd, 2012-04-24
-
-    <gnu_srs> braunr: Is  BPF fully supported by now? Can it be used for
-      isc-dhcp?
-    <braunr> gnu_srs: bpf isn't supported at all
-    <braunr> gnu_srs: instead of emulating it, i added a hurd-specific module
-      in libpcap
-    <braunr> if isc-dhcp can use libpcap, then fine
-    <braunr> (otherwise we could create a hurd-specific patch for dhcp that
-      uses the in-kernel bpf filter implementation)
-    <braunr> gnu_srs: can't it use a raw socket ?
-    <youpi> it can
-    <youpi> it's just that the shape of the patch to do so wasn't exactly how
-      they needed it
-    <youpi> so they have to rework it a bit
-    <youpi> and that takes time
-    <braunr> ok
-    <braunr> antrik: for now, we prefer encapsulating the system specific code
-      in libpcap, and let users of that library benefit from it
-    <braunr> instead of implementing the low level bpf interface, which
-      nonetheless has some system-specific variants ..
-
-
-## IRC, freenode, #hurd, 2012-08-03
-
-In context of the [[select]] issue.
-
-    <braunr> i understand now why my bpf translator was so buggy
-    <braunr> the condition_timedwait i wrote at the time was .. incomplete :)
-
-
-## IRC, freenode, #hurd, 2014-02-04
-
-    <teythoon> btw, why is there a bpf filter in gnumach ?
-    <teythoon> braunr: didn't you put it there ?
-    <braunr> teythoon: ah yes i did
-    <braunr> teythoon: i completed the work of a friend
-    <braunr> teythoon: the original filters in mach were netf filters
-    <braunr> teythoon: we added bpf so that libpcap could directly upload them
-      to the kernel
-    <braunr> in order to apply filters as close as possible to the packet
-      source and save copies
-    <teythoon> so they were used with the in-kernel network drivers ?
-    <braunr> only by experimental code and pfinet which sets a
-      receive-all-inet4/6 filter
-    <braunr> i also have a pcap-hurd.c file for libpcap but integration is a
-      bit tricky because of netdde
-    <braunr> maybe i could work on it again some day
-    <braunr> it should be easy to get into the debian package at least
-    <teythoon> so they can still be used with a netdde-based driver ?
-    <braunr> i'm not sure
-    <braunr> the pcap-hurd.c file i wrote uses the libpcap bpf filter
-    <teythoon> oh, ok, i misinterpreted what you said wrt netdde
-    <braunr> the problem caused by netdde is about where to get packets from,
-      but devnode should take care of that
-    <teythoon> did you mean that the integration is tricky b/c when netdde is
-      used, a different approach is necessary and that would have to be
-      detected at runtime ?
-    <braunr> something like that
-    <teythoon> right
-    <braunr> i didn't want to detect anything
-    <teythoon> right
-    <braunr> i was waiting for things to settle but netdde is still debian only
-    <braunr> but that's ok, this oculd be a debian only patch for now
-    <teythoon> so is eth-filter the netdde equivalent or am i getting a wrong
-      picture here ?
-    <braunr> i don't know
-    <teythoon> it seems to implement bpf filters as well
-    <braunr> it could very well be
-    <braunr> whatever the driver, pfinet must be able to install a filter
-    <braunr> even if it's almost a catch-all
-    <teythoon> i guess it could start a eth-filter and use this, why not
-    <braunr> sure
-
-
-### IRC, freenode, #hurd, 2014-02-06
-
-    <antrik> teythoon: the BPF filter in Mach can also be used by
-      eth-multiplexer or eth-filter when running on in-kernel network
-      drivers... in fact the implementation was finished by the guy who created
-      eth-multiplexer; it was not fully working before
-    <antrik> it's not useful at all when using netdde I believe
-    <antrik> teythoon: IIRC eth-filted both relies on BPF being implemented by
-      the layer below it (whatever it is) to do the actual filtering, as well
-      as implements BPF itself so any layer on top of it can in turn use BPF
-    <antrik> netdde should provide BPF filters too I'd say... but don't
-      remember for sure
diff --git a/open_issues/bsd_compatibility.mdwn b/open_issues/bsd_compatibility.mdwn
deleted file mode 100644
index 5c916908..00000000
--- a/open_issues/bsd_compatibility.mdwn
+++ /dev/null
@@ -1,34 +0,0 @@
-[[!meta copyright="Copyright © 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_documentation]]
-
-IRC, freenode, #hurd, 2011-10-12:
-
-    <pinotree> hm, why our sys/param.h #define's BSD?
-    <braunr> pinotree: because we're evil
-    <pinotree> is that correct?
-    <pinotree> (the define, not the evilness)
-    <braunr> pinotree: i think it's because the Hurd is closer to the BSD
-      interfaces, probably because of Mach (which is itself derived from
-      BSD4.2)
-    <pinotree> braunr: but mach being bsd-ish won't make the userland (glibc)
-      interfaces bsd-ish, will it?
-    <braunr> pinotree: no
-    <pinotree> braunr: so...? :)
-    <braunr> pinotree: i guesse there are bsdisms in the glibc hurd specific
-      code, possibly because of mach
-    <braunr> or they used to be bsdisms, before being standardized
-    <braunr> e.g. mmap
-    <pinotree> braunr: hrmm...
-    <antrik> braunr: the BSDisms are there on purpose... Hurd was originally
-      even meant to be binary-compatible with BSD
-    <antrik> nothing to do with Mach really
-    <braunr> antrik: ok
diff --git a/open_issues/cannot_create__dev_null__interrupted_system_call.mdwn b/open_issues/cannot_create__dev_null__interrupted_system_call.mdwn
deleted file mode 100644
index b0f14a17..00000000
--- a/open_issues/cannot_create__dev_null__interrupted_system_call.mdwn
+++ /dev/null
@@ -1,193 +0,0 @@
-[[!meta copyright="Copyright © 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_hurd]]
-
-
-# IRC, freenode, #hurd, 2013-12-05
-
-    <teythoon> Creating device nodes: fd fdX std vcs hdX hdXsY hdXs1Y sdX sdXsY
-      sdXs1Y cdX netdde ethX loopX ttyX ptyp ptyq/sbin/MAKEDEV: 75:
-      /sbin/MAKEDEV: cannot create /dev/null: Interrupted system call
-    <teythoon> that's new
-    <braunr> teythoon: ouch
-    <teythoon> braunr: everything works fine though
-    <braunr> teythoon: that part isn't too surprising
-    <teythoon> y?
-    <braunr> teythoon: /dev/null already existed, didn't it ?
-    <teythoon> braunr: sure, yes
-
-
-## IRC, freenode, #hurd, 2013-12-19
-
-    <braunr> hm
-    <braunr> i'm seeing those /sbin/MAKEDEV: cannot create /dev/null:
-      Interrupted system call messages too
-
-
-## IRC, freenode, #hurd, 2013-12-20
-
-    <teythoon> braunr: interesting, I've seen some of those as well
-
-
-## IRC, freenode, #hurd, 2014-01-26
-
-    <gg0> cannot create /dev/null: Interrupted system call
-    <gg0>
-      http://gnashdev.org:8010/builders/z-sid-hurd-i386/builds/26/steps/system_upgrade/logs/stdio
-
-
-## IRC, freenode, #hurd, 2014-01-27
-
-    <anatoly> gg0: I had same /dev/null error after upgrading my old image
-      (more than 6 months old) a week ago. But I got such message only on boot
-      and it didn't autostart hurd console.
-    <anatoly> Tried to upgrade current qemu image (from topic) to reproduce it
-      but it works OK after upgrade
-    <gg0> i can reproduce it with # apt-get install --reinstall python2.7 dbus
-      # for instance
-    <gg0> http://paste.debian.net/plain/78566/
-    <teythoon> gg0: i've seen those as well, but i cannot reliably reproduce it
-      to track it down
-    <teythoon> i believe it's benign though
-    <gg0> in shell scripts if -e is set, it aborts on failures like those
-    <teythoon> uh, it does? :/
-    <gg0> so if this happens in prerm/postinst scripts, package is not properly
-      installed/removed/configured and it fails
-    <gg0> redirecting stdout and strerr to /dev/null shouldn't be so
-      problematic, anything wrong in my setup?
-    <gg0> can you reproduce it?
-    <teythoon> not reliably
-    <teythoon> gg0: but i do not believe that anything is wrong with your
-      machine
-    <gg0> any way to debug it?
-    <teythoon> having a minimal test case that triggers this reliably would be
-      great
-    <teythoon> but i fear it might be a race
-
-
-## IRC, freenode, #hurd, 2014-01-28
-
-    <teythoon> have you seen the /dev/null issue ?
-    <braunr> yes
-    <teythoon> what do you make of it ?
-    <braunr> no idea
-    <teythoon> i believe it is related to the inlining work i've done
-    <braunr> just like the bogus deallocation at boot, it needs debugging :)
-    <braunr> hm i don't think so
-    <teythoon> no ?
-    <braunr> i think we saw it even before your started working on the hurd ;p
-    <teythoon> i've never seen it before my recent patches
-    <teythoon> maybe i made it worse
-    <braunr> not worse, just exposed more
-    <teythoon> right
-
-
-## IRC, freenode, #hurd, 2014-01-29
-
-    <gg0> cannot reproduce "cannot create /dev/null: Interrupted system call"
-      on a faster VM
-    <gg0> might depend on that?
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-02
-
-    <pere> but now saw a strange message at the end of the boot:
-      /etc/init.dhurd-console: 55: /etc/init.d/hurd-console: cannot create
-      /dev/null: Interrupted system call
-    <gg0> oh well known on a slow VM (even old qemu/kvm btw), i can't reproduce
-      it on a faster/more recent one
-    <gg0> slow VM = gnash buildbot slave
-      http://gnashdev.org:8010/builders/z-sid-hurd-i386/builds/26/steps/system_upgrade/logs/stdio
-    <gg0> especially bad on system upgrade because it doesn't finish to run
-      prerm/postinst scripts :/
-
-
-## IRC, freenode, #hurd, 2014-02-05
-
-    <gg0> Creating device nodes: fd fdX std vcs hdX hdXsY/sbin/MAKEDEV: 75:
-      /sbin/MAKEDEV: cannot create /dev/null: Interrupted system call hdXs1Y
-      sdX sdXsY sdXs1Y cdX netdde ethX loopX ttyX ptyp ptyq lprX comX random
-      urandom kbd mouse shm.
-
-
-## IRC, freenode, #hurd, 2014-02-11
-
-    <gg0> typical dist-upgrade http://paste.debian.net/plain/81346/
-    <gg0> many fewer cannot create /dev/null: Interrupted system call
-    <gg0> on a faster machine
-    <teythoon> gg0: wow, so many interrupted system call messages
-    <teythoon> i don't get as many, but makedev produces a few every time i run
-      it as well
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-16
-
-    <pere> anyone here got any idea why upgrading initscripts fail on the hurd
-      gnash autobuilder, as reported on <URL:
-      http://gnashdev.org:8010/builders/z-sid-hurd-i386/builds/28/steps/system_upgrade/logs/stdio
-      >?
-    <gg0> pere: cannot create /dev/null: Interrupted system call
-    <pere> gg0: I noticed the message, but fail to understand how this could
-      happen.
-    <gg0> 13:16 < gg0> oh well known on a slow VM (even old qemu/kvm btw), i
-      can't reproduce it on a faster/more recent one
-    <gg0> 13:17 < gg0> slow VM = gnash buildbot slave
-      http://gnashdev.org:8010/builders/z-sid-hurd-i386/builds/26/steps/system_upgrade/logs/stdio
-    <gg0> 13:18 < gg0> especially bad on system upgrade because it doesn't
-      finish to run prerm/postinst scripts :/
-    <gg0> i remember teythoon talking about something racy
-    <teythoon> gg0: the /dev/null issue is known for a long time
-    <teythoon> gg0: some of the recent work (i believe mine) has made the
-      problem more apparent
-    <teythoon> gg0: that's what braunr told me
-    <gg0> i see. it would be really nice fixing it. really annoying. i
-      workaround it by moving null away and moving it back under /dev before
-      halting/rebooting
-
-
-## IRC, freenode, #hurd, 2014-02-17
-
-    <tschwinge> Earlier today, I upgraded my Debian GNU/Hurd installation from
-      several months ago, and I'm now seeing bogus things as follows; is that a
-      known issue?
-    <tschwinge>  checking for i686-unknown-gnu0.5-ar... ar
-    <tschwinge>  configure: updating cache ./config.cache
-    <tschwinge>  configure: creating ./config.status
-    <tschwinge> +./config.status: 299: ./config.status: cannot create
-      /dev/null: Interrupted system call
-    <tschwinge>  config.status: creating Makefile
-    <tschwinge> (The plus is from a build log diff.)
-    <azeem> 13:36 < gg0> pere: cannot create /dev/null: Interrupted system call
-    <azeem> 20:10 < teythoon> gg0: the /dev/null issue is known for a long time
-    <tschwinge> Anyone working on resolving this?  I't causing build issues:
-    <tschwinge> checking for i686-unknown-gnu0.5-ranlib... (cached) ranlib
-    <tschwinge> checking command to parse nm output from gcc-4.8
-      object... [...]/opcodes/configure: 6760: ./configure.lineno: cannot
-      create /dev/null: Interrupted system call
-    <tschwinge> failed
-    <tschwinge> checking for dlfcn.h... yes
-    <tschwinge> Anyway, will go researching IRC logs.
-    <azeem> tschwinge: (that one was from #debian-hurd)
-    <azeem> I assume teythoon and/or braunr can comment once he's back
-    <azeem> they're*
-    <braunr> tschwinge: we've been seing this more often lately but noone has
-      attempted to fix it yet
-    <braunr> tschwinge: if you have a reliable way to reproduce that /dev/null:
-      Interrupted system call error, please let us know
-
-
-## IRC, freenode, #hurd, 2014-02-23
-
-    <gg0> braunr: cool. i'd vote /dev/null one as next one in your todo
-    <gg0> still frequent on this slow vm
-      http://gnashdev.org:8010/builders/z-sid-hurd-i386/builds/30/steps/system_upgrade/logs/stdio
-    <gg0> especially during setup-translators -k
-    <braunr> yes
diff --git a/open_issues/chroot_difference_from_linux.mdwn b/open_issues/chroot_difference_from_linux.mdwn
deleted file mode 100644
index f2009bd8..00000000
--- a/open_issues/chroot_difference_from_linux.mdwn
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-\#hurd, freenode, 2010
-
-    <cfhammar> weird, even fd = open("/"), chroot("/tmp/chroot"), openat(fd, "/tmp/chroot/..) opens /tmp/chroot in linux
-    <pochu> cfhammar: isn't that expected?
-    <cfhammar> pochu: well, i didn't expect it :-)
-    <cfhammar> pochu: in hurd, /tmp gets opened, which i think is more natural
-    <pochu> cfhammar: oh right, didn't notice the ".." :-)
diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn
deleted file mode 100644
index 407a104c..00000000
--- a/open_issues/clock_gettime.mdwn
+++ /dev/null
@@ -1,348 +0,0 @@
-[[!meta copyright="Copyright © 2011, 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]]."]]"""]]
-
-[[!meta title="clock_gettime"]]
-
-[[!tag open_issue_glibc open_issue_gnumach]]
-
-Missing `clock_gettime(CLOCK_MONOTONIC)` (e.g. for iceweasel)
-
-It could be a mere matter of extending the
-[[mapped-time_interface|microkernel/mach/gnumach/interface/device/time]]:
-add it to
-`mapped_time_value_t` in gnumach, handle it in `gnumach/kern/mach_clock.c`, and
-make `clock_gettime` use it.
-
-BTW, also make `gettimeofday()` use it, since it's way more efficient and some
-applications assume that it is.
-
-What about adding a nanosecond-precision clock, too?  --[[tschwinge]]
-
-
-# IRC, freenode, #hurd, 2011-08-26
-
-    < pinotree> youpi: thing is: apparently i found a simple way to have a
-      monotonic clock as mmap-able device inside gnumach
-    < pinotree> currently, in kern/mach_clock.c there's a variable 'time',
-      which gets increased on clock interrupt, and optionally modified by
-      host_set_time
-    < pinotree> ()
-    < pinotree> if i add a new variable next to it, only increasing it on
-      interrupt but not modifying it at all otherwise, would that give me a
-      monotonic clock?
-    < pinotree> at least on sme basic tests i did, it seems it could work that
-      way
-    < youpi> yes, it should work
-    < braunr> sure
-    < youpi> and that's the way I was considering implementing it
-
-
-# IRC, freenode, #hurd, 2011-09-06
-
-    <pinotree> yeah, i had a draft of improved idea for also handling
-      nanoseconds
-    <tschwinge> pinotree: Ah, nice, I thought about nanoseconds as well.
-    <tschwinge> pinotree, youpi: This memory page is all-zero by default,
-      right?
-    <tschwinge> Can't we then say that its last int is a version code, and if
-      it is 0 (as it is now), we only have the normal mapped time field, if it
-      is 1, we also have the monotonic cliock and ns precision on address 8 and
-      16 (or whatever)?
-    <tschwinge> In case that isn't your plan anyway.
-    <youpi> it's all-zero, yes
-    <tschwinge> Or, we say if a field is != 0 it is valid.
-    <youpi> making the last int a version code limits the size to one page
-    <youpi> I was thinking a field != 0  being valid is simpler
-    <youpi> but it's probably a problem too
-    <youpi> in that glibc usually caches whether interfaces are supported
-    <tschwinge> Wrap-around?
-    <youpi> for some clocks, it may be valid that the value is 0
-    <youpi> wrap-around is another issue too
-    <tschwinge> Well, then we can do the version-field thing, but put it right
-      after the current time field (address 8, I think)?
-    <youpi> yes
-    <youpi> it's a bit ugly, but it's hidden behind the structure
-    <tschwinge> It's not too bad, I think.
-    <youpi> yes
-    <tschwinge> And it will forever be a witness of the evolving of this
-      map_time interface.  :-)
-
-
-# IRC, freenode, #hurd, 2013-02-11
-
-In context of [[select]].
-
-    <pinotree> braunr: would you send for review (and inclusion) your
-      time_data_t addition?
-    <pinotree> this way we could add nanosecs-based utime rpc (and then their
-      implementation in libc)
-    <braunr> pinotree: it's part of the hurd branch
-    <braunr> do you want it sent separately ?
-    <pinotree> yeah
-    <braunr> ok
-    <braunr> let me get it right first :)
-    <pinotree> sure :)
-
-
-## IRC, freenode, #hurd, 2013-02-12
-
-    <braunr> pinotree:
-      http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout_pthread_v2&id=6ec50e62d9792c803d00cbff1cab2c0b3675690a
-    <pinotree> uh nice
-    <pinotree> will need two small inline functions to convert time_data_t <->
-      timespec, but that's it
-    <braunr> hm right
-    <braunr> i could have thought about it
-    <braunr> but i'll leave it for another patch :p
-    <pinotree> oh sure, no hurry
-
-
-## IRC, freenode, #hurd, 2013-02-19
-
-    <youpi> braunr: about time_data_t, I get it's needed that it be an array
-    <youpi> so it can be passed by reference, not by value?
-    <braunr> by address, yes
-    <braunr> that's the difference between array and struct
-
-
-## IRC, freenode, #hurd, 2013-02-25
-
-    <youpi> braunr: why did you want to see time_data passed as pointer, not as
-      struct?
-    <braunr> to microoptimize
-    <braunr> the struct is 2 64-bit integers
-    <youpi> well, we already pass structs along in a few cases,
-      e.g. io_statbuf_t, rusage_t, etc.
-    <youpi> be it written t[0].sec or t->sec, it seems odd
-    <youpi> copying 2 64bit integers is not much compared to the potential for
-      bugs here
-    <braunr> bugs ?
-    <youpi> yes, as in trying to access t[1], passing a wrong pointer, etc.
-    <youpi> or the reader frowning on "why is this case different than the
-      others?"
-    <braunr> well, i'm already usually frowning when i see what mig does ..
-    <youpi> right
-    <youpi> on the plus side, it's only the client side, i.e. mostly glibc,
-      which sees the t[0]
-    <braunr> and the practice established by my patch is to convert to struct
-      timespec as soon as possible
-    <braunr> the direct use of this type is therefore limited
-    <youpi> could we define time_data_t as a struct time_data * instead of
-      struct time_data[1] ?
-    <youpi> (in the.h)
-    <youpi> that would make more sense to define a struct time_data, and pass a
-      pointer to it
-    <braunr> i'm not sure
-    <braunr> the mach server writing guide was very clear about array implying
-      a C array too
-    <braunr> and i remember having compilation problems before doing that
-    <braunr> but i don't remember their nature exactly 
-    <youpi> I'm not sure to understand what you said about converting to struct
-      timespec
-    <youpi> what makes it not possible now?
-    <youpi> and what is the relation with being an array or a pointer?
-    <braunr> concerning struct timespec, what i mean is that the functions
-      called by the mig stub code directly convert time_data_t to a struct
-      timespec (which is the real type used throughout the hurd code)
-    <braunr> about the rest, i'm not sure, i'd have to try again
-    <braunr> mig just assumes it's an array
-    <youpi> and why not just using struct timespec?
-    <youpi> (for the mig type too)
-    <braunr> my brain can't correctly compute variable sized types in mig
-      definition files
-    <braunr> i wanted something that would remain correct for the 64-bit port
-
-[[64-bit_port]], [[mig_portable_rpc_declarations]].
-
-    <youpi> ah, you mean because tv_nsec is a long, which will not be the same
-      type?
-    <braunr> and tv_sec being a time_t (thus a long too)
-    <youpi> but we have the same issue e.g. for the rusage structure, don't we?
-    <braunr> yes
-    <youpi> so we'll have to fix things for that too anyway
-    <braunr> sure
-    <youpi> making a special case will not necessarily help
-    <braunr> but it doesn't mean new interfaces have to be buggy too
-    <youpi> well, using the proper type in the server itself is nicer
-    <youpi> instead of having to convert
-    <braunr> yes
-    <braunr> i'm not exactly sure where to declare struct timespec then
-    <braunr> should it be declared in hurd_types.h, and simply reused by the
-      libc headers ?
-    <youpi> ? AIUI, it's the converse, hurd_types.h uses the struct timespec
-      from libc headers, and defines timespec_t
-    <braunr> ok
-    <youpi> timespec_t being the internal type whose definition gets done right
-      for mig to do the right thing
-    <braunr> yes
-    <braunr> i see
-    <braunr> so, you'd like a struct of integer_t instead of an array of
-      signed64
-    <youpi> for our current 32bit userland yes
-    <braunr> do you want to make the changes yourself or should i add a new
-      branch ?
-    <youpi> and we'll make that a 64bit struct when we have a64bit userland
-
-
-# IRC, freenode, #hurd, 2013-04-06
-
-    <tschwinge> pinotree: You had once been working on adding nsec-procision
-      timestamps to GNU Mach's maptime interface (or what the name is).  Is
-      that blocked on something or just waiting to be continued?
-    <pinotree> blocked on me needing to learn more the proper way to do
-      "atomic" update of the struct with time :)
-
-
-# IRC, freenode, #hurd, 2013-09-04
-
-    <teythoon> do we have CLOCK_MONOTONIC ?
-    <braunr> teythoon: i think we do but it's actually a simple offset from
-      CLOCK_REALTIME .. :)
-    <teythoon> ah never mind, I do hate this posix time interface anyways
-    <braunr> really ?
-    <braunr> i think librt is decent
-
-
-# Candidate for [[vDSO]] code?
-
-
-# IRC, freenode, #hurd, 2014-02-23
-
-    <desrt> GLib (gthread-posix.c): Unexpected error from C library during
-      'pthread_condattr_setclock': Invalid argument.  Aborting.
-    <desrt> uh oh...
-    <desrt> time to go digging in glibc i guess...
-    <braunr> what are you trying to run ?
-    <desrt> glib
-    <braunr> with what ?
-    <desrt> just running glib's test suite under jhbuild
-    <desrt> i maintain glib and i made some changes recently -- i wanted to
-      make sure they didn't break the hurd
-    <desrt> and it seems they have ;/
-    <braunr> well
-    <braunr> the hurd doesn't completely comply with posix 2008
-    <desrt> long story short: we've keyed our timed waits on condition
-      variables to the monotonic clock for a long time now, but we never tested
-      that it actually worked
-    <desrt> so i just added an assert -- and indeed it fails on hurd
-    <braunr> our glibc lies about supporting timers
-    <braunr> good thinking
-    <braunr> we don't support the monotonic clock
-    <desrt> clock_gettime(CLOCK_MONOTONIC) seems to work
-    <braunr> and you should know that, even if clock selection and timers are
-      available (which posix 2008 requires), it's still optional
-    <braunr> no, glibc lies
-    <desrt> !!
-    <braunr> our "support" is a mere hack shifting CLOCK_REALTIME
-    <desrt> it should at least lie consistently :)
-    <braunr> we need to implement CLOCK_MONOTONIC properly
-    <desrt> ya... that would be very nice indeed
-    <braunr> not that hard either
-    <desrt> i agree!
-    <braunr> we just have to do it right
-    <desrt> fwiw, i plan to keep this assert in glib
-    <braunr> yes, it's good
-    <desrt> is there anywhere i can file a bug to give you guys some advance
-      warning?
-    <braunr> i don't think it's needed
-    <braunr> we know the problem
-    <desrt> k -- consider yourself warned, then :)
-    <braunr> and it's been a bigger concern recently
-    <desrt> awesome.  glad i don't have to do anything :)
-    <braunr> if it's not already done, i suggest you check for the
-      CLOCK_MONOTONIC option
-    <desrt> fwiw, i'm trying to get a regular debian/gnu/hurd build of
-      glib/gtk/etc setup
-    <braunr> regular ?
-    <desrt> ya... out of git master on a daily basis
-    <braunr> from sources ?
-    <braunr> oh nice
-    <desrt> we recently set this up for freebsd as well
-    <braunr> few maintainers take the pain :)
-    <desrt> our non-linux 'problem discovery' is a bit crap before now :/
-    <braunr> i guess that's pretty normal
-    <braunr> i don't consider it the responsibility of the maintainers to test
-      every possible platform
-    <desrt> glib is a bit unique -- portability is our business
-    <braunr> taking our patches into consideration is what we ask most
-    <braunr> right
-    <desrt> and the "please take the patches" thing is something we want to
-      stop doing
-    <braunr> why ?
-    <desrt> mostly because we often look at a patch that someone sent a few
-      years ago and say "do we even still need this?"
-    <desrt> and have no way to know
-    <braunr> uh
-    <desrt> you would not believe how many patches like this we've
-      accumulated...
-    <braunr> but if we send it now ? :)
-    <desrt> braunr: new policy is roughly this:
-      https://wiki.gnome.org/Projects/GLib/SupportedPlatforms
-    <desrt> ie: fixes for issues that are general portability improvements and
-      POSIX compliance are welcome...
-    <desrt> patches that introduce platform-specific #ifdef sections are
-      rejected unless we have a regular builder to test that code
-    <braunr> i see
-    <braunr> again, regarding portability, don't consider CLOCK_MONOTONIC to be
-      readily available, check for it
-    <braunr> an #error would be enough but it has to be checked
-    <desrt> it basically comes down to: we don't want to have code in our
-      version control that we have no possible way of testing
-    <braunr> yes
-    <desrt> braunr: we do check for it
-    <braunr> ok
-    <desrt> we assert() if clock_gettime(CLOCK_MONOTONIC) fails
-    <braunr> no i mean
-    <desrt> as POSIX said it should if CLOCK_MONOTONIC is not supported
-    <desrt> if you lie to us.... well, not much we can do
-    <braunr> POSIX_MONOTONIC_CLOCK
-    <braunr> _POSIX_MONOTONIC_CLOCK
-    <desrt> this is actually defined to 0 on most platforms...
-    <desrt> which does not mean that it's unsupported -- it means that the
-      runtime must be ready to deal with it not actually existing at runtime
-    <braunr> really ?
-    <desrt> yes
-    <desrt> we used to rely on this and got a bug that we were doing it wrong
-      :)
-    <desrt> and indeed, even on linux, both with glibc and uclibc:
-    <desrt> /usr/include/bits/posix_opt.h:#define _POSIX_MONOTONIC_CLOCK
-      0
-    <desrt> /usr/include/uClibc/bits/posix_opt.h:#define _POSIX_MONOTONIC_CLOCK
-      0
-    <braunr> ok it's described in 2.1.6 Options
-    <braunr> so your check is appropriate
-    <desrt> so does clock_gettime(MONOTONIC) on debian/hurd get me realtime?
-    <braunr> either that, or a value shifted from it
-    <desrt> if so, i'll just hack out the condattr_setclock() check and proceed
-      trying to build past glib...
-    * desrt checks
-    <desrt> as it is, even the build of glib fails since we use some tools
-      linked against ourselves during the build process...
-    <desrt> 1393124084790000 1393124084790000
-    <desrt> those look the same....
-    <braunr> heh
-    <desrt> i also notice that your clocks are not very high precision :)
-    <braunr> that's right
-    <desrt> HZ = 100, i guess
-    <braunr> yes
-    <desrt> fair enough
-    <desrt> our mainloop doesn't support better-than-millisecond accuracy yet
-      anyway :)
-    <desrt> (although it will soon...)
-    <braunr> nice
-
-
-## IRC, freenode, #hurd, 2014-03-05
-
-    <desrt> braunr: bit of a warning: i released the glib that depends on
-      working pthread_condattr_setclock(..._MONOTONIC) and pochu said that it
-      will be landing in debian within the next days
-    <braunr> desrt: ok
diff --git a/open_issues/code_analysis.mdwn b/open_issues/code_analysis.mdwn
deleted file mode 100644
index df434b76..00000000
--- a/open_issues/code_analysis.mdwn
+++ /dev/null
@@ -1,277 +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]]."]]"""]]
-
-In the topic of *code analysis* or *program analysis* ([[!wikipedia
-Program_analysis_(computer_science) desc="Wikipedia article"]]), there is
-static code analysis ([[!wikipedia Static_code_analysis desc="Wikipedia
-article"]]) and dynamic program analysis ([[!wikipedia Dynamic_program_analysis
-desc="Wikipedia article"]]).  This topic overlaps with [[performance
-analysis|performance]], [[formal_verification]], as well as general
-[[debugging]].
-
-[[!toc]]
-
-
-# Bounty
-
-There is a [[!FF_project 276]][[!tag bounty]] on some of these tasks.
-
-
-# Static
-
-  * [[GCC]]'s warnings.  Yes, really.
-
-      * GCC plugins can be used for additional semantic analysis.  For example,
-        <http://lwn.net/Articles/457543/>, and search for *kernel context* in
-        the comments.
-
-      * Have GCC make use of [[RPC]]/[[microkernel/mach/MIG]] *in*/*out*
-        specifiers, and have it emit useful warnings in case these are pointing
-        to uninitialized data (for *in* only).
-
-  * [[!wikipedia List_of_tools_for_static_code_analysis]]
-
-  * [Engineering zero-defect software](http://esr.ibiblio.org/?p=4340), Eric
-    S. Raymond, 2012-05-13
-
-  * [Static Source Code Analysis Tools for C](http://spinroot.com/static/)
-
-  * [Cppcheck](http://sourceforge.net/apps/mediawiki/cppcheck/)
-
-    For example, [Debian's hurd_20110319-2
-    package](http://qa.debian.org/daca/cppcheck/sid/hurd_20110319-2.html)
-    (Samuel Thibault, 2011-08-05: *I had a look at those, some are spurious;
-    the realloc issues are for real*).
-
-  * Coccinelle
-
-      * <http://lwn.net/Articles/315686/>
-
-      * <http://www.google.com/search?q=coccinelle+analysis>
-
-    Has already been used for finding and fixing [[!message-id desc="double
-    mutex unlocking issues"
-    "1355701890-29227-1-git-send-email-tipecaml@gmail.com"]].
-
-  * [clang](http://www.google.com/search?q=clang+analysis)
-
-      * <http://darnassus.sceen.net/~teythoon/qa/gnumach/scan-build>
-
-      * <http://darnassus.sceen.net/~teythoon/qa/hurd/scan-build>
-
-  * [Linux' sparse](https://sparse.wiki.kernel.org/)
-
-  * <http://klee.llvm.org/>
-
-      * <http://blog.llvm.org/2010/04/whats-wrong-with-this-code.html>
-
-  * [Smatch](http://smatch.sourceforge.net/)
-
-  * [Parfait](http://labs.oracle.com/projects/parfait/)
-
-      * <http://lwn.net/Articles/344003/>
-
-  * [Saturn](http://saturn.stanford.edu/)
-
-  * [Flawfinder](http://www.dwheeler.com/flawfinder/)
-
-  * [sixgill](http://sixgill.org/)
-
-  * [s-spider](http://code.google.com/p/s-spider/)
-
-  * [CIL (C Intermediate Language)](http://kerneis.github.com/cil/)
-
-  * [Frama-C](http://frama-c.com/)
-
-        <teythoon> btw, I've been looking at http://frama-c.com/ lately
-        <teythoon> it's a theorem prover for c/c++
-        <braunr> oh nice
-        <teythoon> I think it's most impressive, it works on the hurd (aptitude
-          install frama-c o_O)
-        <teythoon> *and it works
-        <braunr> "Simple things should be simple,
-        <braunr> complex things should be possible."
-        <braunr> :)
-        <braunr> looks great
-        <teythoon> even the gui is awesome, allows one to browse source code in
-          a very impressive way
-        <braunr> clear separation between value changes, dependencies, side
-          effects
-        <braunr> we could have plugins for stuff like ports
-        <braunr> handles concurrency oO
-        <nalaginrut> so you want to use Frame-C to analyze the whole Hurd code
-          base?
-        <teythoon> nalaginrut: well, frama-c looks "able" to assist in
-          analyzing the Hurd, yes
-        <teythoon> nalaginrut: but theorem proving is a manual process, one
-          needs to guide the prover
-        <teythoon> nalaginrut: b/c some stuff is not decideable
-        <nalaginrut> I ask this because I can imagine how to analyze Linux
-          since all the code is in a directory. But Hurd's codes are
-          distributed to many other projects
-        <braunr> that's not a problem
-        <braunr> each server can be analyzed separately
-        <teythoon> braunr: also, each "entry point"
-        <nalaginrut> alright, but sounds a big work
-        <teythoon> it is
-        <braunr> otherwise, formal verification would be widespread :)
-        <teythoon> that, and most tools are horrible to use, frama-c is really
-          an exception in this regard
-
-  * [Coverity](http://www.coverity.com/) (nonfree)
-
-      * <https://scan.coverity.com/projects/1307> If you want access, speak up in #hurd or on the mailing list.
-
-      * IRC, OFTC, #debian-hurd, 2014-02-03
-
-            <pere> btw, did you consider adding hurd and mach to <URL:
-              https://scan.coverity.com/ > to detect bugs automatically?
-            <pere> I found lots of bugs in gnash, ipmitool and sysvinit when I
-              started scanning those projects. :)
-            <teythoon> i did some static analysis work, i haven't used coverty
-              but free tools for that
-            <teythoon> i think thomas wanted to look into coverty though
-            <pere> quite easy to set up, but you need to download and run a
-              non-free tarball on the build host.
-            <teythoon> does that tar ball contains binary code ?
-            <teythoon> that'd be a show stopper for the hurd of course
-            <pere> did not investigate.  I just put it in a contained virtual
-              machine.
-            <pere> did not want it on my laptop. :)
-            <pere> prefer free software here. :)
-            <pere> but I did not have to "accept license", at least. :)
-
-      * IRC, OFTC, #debian-hurd, 2014-02-05
-
-            <pere> ah, cool.  <URL: https://scan.coverity.com/projects/1307 >
-              is now in place. :)
-
-        [[microkernel/mach/gnumach/projects/clean_up_the_code]],
-        *Code_Analysis, Coverity*.
-
-  * [Splint](http://www.splint.org/)
-
-      * IRC, freenode, #hurd, 2011-12-04
-
-            <mcsim> has anyone used splint on hurd?
-            <mcsim> this is tool for statically checking C programs
-            <mcsim> seems I made it work
-
-
-## Hurd-specific Applications
-
-  * [[Port Sequence Numbers|microkernel/mach/ipc/sequence_numbering]].  If
-    these are used, care must be taken to update them reliably, [[!message-id
-    "1123688017.3905.22.camel@buko.sinrega.org"]].  This could be checked by a
-    static analysis tool.
-
-  * [[glibc]]'s [[glibc/critical_section]]s.
-
-
-# Dynamic
-
-  * [[community/gsoc/project_ideas/Valgrind]]
-
-  * glibc's `libmcheck`
-
-      * Used by GDB, for example.
-
-      * Is not thread-safe, [[!sourceware_PR 6547]], [[!sourceware_PR 9939]],
-        [[!sourceware_PR 12751]], [[!stackoverflow_question 314931]].
-
-  * <http://en.wikipedia.org/wiki/Electric_Fence>
-
-      * <http://sourceforge.net/projects/duma/>
-
-  * <http://wiki.debian.org/Hardening>
-
-  * <https://wiki.ubuntu.com/CompilerFlags>
-
-  * `MALLOC_CHECK_`/`MALLOC_PERTURB_`
-
-      * IRC, freenode, #glibc, 2011-09-28
-
-            <vsrinivas> two things you can do -- there is an environment
-              variable (DEBUG_MALLOC_ iirc?) that can be set to 2 to make
-              ptmalloc (glibc's allocator) more forceful and verbose wrt error
-              checking
-            <vsrinivas> another is to grab a copy of Tor's source tree and copy
-              out OpenBSD's allocator (its a clearly-identifyable file in the
-              tree); LD_PRELOAD it or link it into your app, it is even more
-              aggressive about detecting memory misuse.
-            <vsrinivas> third, Red hat has a gdb python plugin that can
-              instrument glibc's heap structure. its kinda handy, might help?
-            <vsrinivas> MALLOC_CHECK_ was the envvar you want, sorry.
-
-      * [`MALLOC_PERTURB_`](http://udrepper.livejournal.com/11429.html)
-
-      * <http://git.fedorahosted.org/cgit/initscripts.git/diff/?id=deb0df0124fbe9b645755a0a44c7cb8044f24719>
-
-  * In context of [[!message-id
-    "1341350006-2499-1-git-send-email-rbraun@sceen.net"]]/the `alloca` issue
-    mentioned in [[gnumach_page_cache_policy]]:
-
-    IRC, freenode, #hurd, 2012-07-08:
-
-        <youpi> braunr: there's actually already an ifdef REDZONE in libthreads
-
-    It's `RED_ZONE`.
-
-        <youpi> except it seems clumsy :)
-        <youpi> ah, no, the libthreads code properly sets the guard, just for
-          grow-up stacks
-
-  * GCC, LLVM/clang: [[Address Sanitizer (asan), Memory Sanitizer (msan),
-    Thread Sanitizer (tasn), Undefined Behavor Sanitizer (ubsan), ...|_san]]
-
-  * [GCC plugins](http://gcc.gnu.org/wiki/plugins)
-
-      * [CTraps](https://github.com/blucia0a/CTraps-gcc)
-
-        > CTraps is a gcc plugin and runtime library that inserts calls to runtime
-        > library functions just before shared memory accesses in parallel/concurrent
-        > code.
-        > 
-        > The purpose of this plugin is to expose information about when and how threads
-        > communicate with one another to programmers for the purpose of debugging and
-        > performance tuning.  The overhead of the instrumentation and runtime code is
-        > very low -- often low enough for always-on use in production code.  In a series
-        > of initial experiments the overhead was 0-10% in many important cases.
-
-  * Input fuzzing
-
-    Not a new topic; has been used (and papers published?) for early [[UNIX]]
-    tools.  What about some [[RPC]] fuzzing?
-
-      * <http://caca.zoy.org/wiki/zzuf>
-
-      * <http://www.ece.cmu.edu/~koopman/ballista/>
-
-      * [Jones: system call abuse](http://lwn.net/Articles/414273/), Dave
-        Jones, 2010.
-
-          * [Trinity: A Linux kernel fuzz tester (and then
-            some)](http://www.socallinuxexpo.org/scale11x/presentations/trinity-linux-kernel-fuzz-tester-and-then-some),
-            Dave Jones, The Eleventh Annual Southern California Linux Expo, 2013.
-
-  * Mayhem, *an automatic bug finding system*
-
-    IRC, freenode, #hurd, 2013-06-29:
-
-        <teythoon> started reading the mayhem paper referenced here
-          http://lists.debian.org/debian-devel/2013/06/msg00720.html
-        <teythoon> that's nice work, they are doing symbolic execution of x86
-          binary code, that's effectively model checking with some specialized
-          formulas
-        <teythoon> (too bad the mayhem code isn't available, damn those
-          academic people keeping the good stuff to themselvs...)
-        <teythoon> (and I really think that's bad practice, how should anyone
-          reproduce their results? that's not how science works imho...)
diff --git a/open_issues/code_analysis/discussion.mdwn b/open_issues/code_analysis/discussion.mdwn
deleted file mode 100644
index 45126b91..00000000
--- a/open_issues/code_analysis/discussion.mdwn
+++ /dev/null
@@ -1,245 +0,0 @@
-[[!meta copyright="Copyright © 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_documentation]]
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2011-12-04
-
-    <mcsim> defpager uses it's own dynamic memory allocator, which uses
-      vm_allocate/vm_deallocate as backing store? Am I able to use duma in such
-      case?
-    <braunr> you will have to adapt it
-    <braunr> but it's already designed to handle custom allocators
-    <braunr> iirc
-    <braunr> btw, are there special flags for that memory which the pager
-      allocates ?
-    <braunr> e.g. to use wired memory ?
-    <mcsim> yes, wired memory
-    <braunr> you'll have to change that in duma then
-    <braunr> but apart from such details, it should be straightforward
-
-    <antrik> braunr: I have no idea about duma; but if you think it's a useful
-      tool, please add it to open_issues/code_analysis.mdwn
-    <antrik> (I guess we should have a "proper" page listing useful debugging
-      tools...)
-
-
-## IRC, freenode, #hurd, 2012-09-03
-
-    <mcsim> hello. Has anyone tried some memory debugging tools like duma or
-      dmalloc with hurd?
-    <braunr> mcsim: yes, but i couldn't
-    <braunr> i tried duma, and it crashes, probably because of cthreads :)
-
-
-# Static Analysis
-
-## IRC, freenode, #hurd, 2012-09-08
-
-    <mcsim> hello. What static analyzer would you suggest (probably you have
-      tried it for hurd already)?
-    <braunr> mcsim: if you find some good free static analyzer, let me know :)
-    <pinotree> a simple one is cppcheck
-    <mcsim> braunr: I'm choosing now between splint and adlint
-
-
-## IRC, freenode, #hurd, 2013-10-17
-
-    <teythoon> whoa, llvm kinda works, enough to make scan-build work :)
-    <braunr> teythoon: what is scan-build ?
-    <teythoon> braunr: clangs static analyzer
-    <braunr> ok
-    <teythoon> I'm doing a full build of the hurd using it, I will post the
-      report once it is finished
-    <teythoon> this will help spot many problems
-    <teythoon> well, here are the scan-build reports I got so far:
-      https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/
-    <teythoon> I noticed it finds problems in mig generated code, so there are
-      probably lot's of duplictaes for those kind of problems
-    <pinotree> what's a... better one to look at?
-    <teythoon> it's also good at spotting error handling errors, and can spot
-      leaks sometimes
-    <teythoon> hm
-    <teythoon>
-      https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-yVBHO1.html
-    <braunr> that's minor, the device always exist
-    <braunr> but that's still ugly
-    <teythoon>
-      https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-MtgWSa.html
-    <teythoon>
-      https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-QdsZIm.html
-    <teythoon> this could be important:
-      https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-PDMEbk.html
-    <teythoon> this is the issue it finds in mig generated server stubs:
-      https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build/report-iU3soc.html
-    <braunr> this one is #if TypeCheck1
-    <braunr> the libports one looks weird indeed
-    <teythoon> but TypeCheck is 1 (the tooltip shows macro expansion)
-    <teythoon> it is defined in line 23
-    <braunr> oh
-    <teythoon> hmmm... clang does not support nested functions, that will limit
-      its usefulness for us :/
-    <braunr> yes
-    <braunr> one more reason not to use them
-
-
-### IRC, freenode, #hurd, 2013-10-18
-
-    <teythoon> more complete, now with index:
-      https://teythoon.cryptobitch.de/qa/2013-10-17/scan-build-2/
-
-
-### IRC, freenode, #hurd, 2013-11-04
-
-    <teythoon> btw, why does the nested functions stuff needs the executable
-      stack? for trampolines?
-    <braunr> yes
-    <teythoon> I didn't even realize that, that's one more reason to avoid them
-      indeed
-
-    <teythoon> braunr: kern/slab.c (1471): vm_size_t info_size = info_size;
-    <braunr> yes ?
-    <teythoon> braunr: what's up with that?
-    <braunr> that's one way to silence gcc warnings about uninitialized
-      variables
-    <braunr> this warning can easily result in false positives when gcc is
-      unable to determine dependencies
-    <braunr> e.g. if (flag & FLAG_CREATE) myvar = create(); ...; ... if (flag &
-      FLAG_CREATE) use(myvar)
-    <teythoon> well, ok, that's a shortcomming of gcc
-    <teythoon> braunr: your way of silencing that in gcc still shows up in
-      scan-build and most likely any more advanced analysis tool
-    <teythoon> as it should of course, but it is noisy
-    <braunr> teythoon: there is a gcc attribute for that
-    <braunr> __attribute__((unused))
-    <braunr> analysis tools might know that better
-    <teythoon> braunr: could you have a quick look at
-      http://darnassus.sceen.net/~teythoon/qa/gnumach/scan-build/2013-11-04/report-mXqstT.html#EndPath
-      ?
-    <braunr> nice
-    <braunr> anything else on the rbtree code ?
-    <teythoon> well
-    <teythoon>
-      http://darnassus.sceen.net/~teythoon/qa/gnumach/scan-build/2013-11-04/report-LyiOO1.html#EndPath
-    <teythoon> but this is of length 18, so it might be far-fetched
-    <braunr> ??
-    <teythoon> the length of the chain of argumentation
-    <braunr> i don't understand that issue
-    <braunr> isn't 18 the analysis step ?
-    <teythoon> well, the greater the length, the more assumption the tool
-      makes, the more likely it is that it just does not "get" some invariant
-    <braunr> probably yes
-    <braunr> the code can segfault if input parameters are invalid
-    <braunr> that's expected
-    <teythoon> right, looks like this only happens if the tree is invalid
-    <teythoon> if in line 349 brother->children[right] is NULL
-    <teythoon> this is a very good target for verification using frama-c
-    <braunr> :)
-    <teythoon> the code already has many assertions that will be picked up by
-      it automatically
-    <teythoon> so what about the dead store, is it a bug or is it harmless ?
-    <braunr> harmless probably
-    <braunr> certainly
-    <braunr> a simple overlook when polishing
-
-
-### IRC, freenode, #hurd, 2014-01-16
-
-    <mcsim> braunr: hi. Once, when I wrote a lot if inline gcc functions in
-      kernel you said me not to use them. And one of the arguments was that you
-      want to know which binary will be produced. Do you remember that?
-    <braunr> not exactly
-    <braunr> it seems likely that i advice not to use many inline functions
-    <braunr> but i don't see myself stating such a reason
-    <mcsim> braunr: ok
-    <mcsim> so, what do you think about using some high level primitives in
-      kernel
-    <mcsim> like inline-functions
-    <mcsim> ?
-    <braunr> "high level primitives" ?
-    <braunr> you mean switching big and important functions into inline code ?
-    <mcsim> braunr: something that is hard to translate in assembly directly
-    <mcsim> braunr: I mean in general
-    <braunr> i think it's bad habit
-    <mcsim> braunr: why?
-    <braunr> don't inline anything at first, then profile, then inline if
-      function calls really are a bottleneck
-    <mcsim> my argument would be that it makes code more readable
-    <braunr> https://www.kernel.org/doc/Documentation/CodingStyle <= see the
-      "inline disease"
-    <braunr> uh
-    <braunr> more readable ?
-    <braunr> the only difference is an inline keyword
-    <mcsim> sorry
-    <mcsim> i confused with functions that you declare inside functions
-    <mcsim> nested
-    <mcsim> forgot the word
-    <mcsim> sorry 
-    <braunr> ah nested
-    <braunr> my main argument against nested functions is that they're not
-      standard and hard to support for non-gcc tools
-    <braunr> another argument was that it required an executable stack but
-      there is apparently a way to reliably make nested functions without this
-      requirement
-    <braunr> so, at the language level, they bring nice closures
-    <braunr> the problem for me is at the machine level
-    <braunr> i don't know them well so i'm unable to predict the kind of code
-      they generate
-    <braunr> but i guess anyone who would take the time to study their
-      internals would be able to do that
-    <mcsim> and why this last argument is important?
-    <braunr> because machine code runs on machines
-    <braunr> one shouldn't ignore the end result ..
-    <braunr> if you don't know the implications of what you're doing precisely,
-      you loose control over the result
-    <braunr> if you can trust the tool, fine
-    <kilobug> mcsim: in general, when you use something you don't really
-      understand how it works internally, you've a much higher risk of making
-      bugs or inefficient code because you just didn't realize it couldn't work
-      or would be inefficient
-    <braunr> but in the case of a kernel, it often happens that you can't, or
-      at least not in a straightforward way
-    <braunr> s/loose/lose/
-    <mcsim> kilobug: and that's why for kernel programming you try to use the
-      most straightforward primitives as possible?
-    <braunr> no
-    <kilobug> mcsim: not necessarily the most straightforward ones, but ones
-      you understand well
-    <braunr> keeping things simple is a way to keep control complexity in any
-      software
-    <braunr> as long as you understand, and decouple complicated things apart,
-      you can keep things simple
-    <braunr> nested functions doesn't have to do with complexity
-    <braunr> don't*
-    <braunr> it's just that, since they're not standard and commonly used
-      outside gnu projects, they're not well known
-    <braunr> i don't "master" them
-    <teythoon> also, they decouple the data flow from the control flow
-    <teythoon> which in my book is bad for imparative languages
-    <teythoon> and support for them in tools like gdb is poor
-    <mcsim> braunr: I remembered nested functions because now I use C++ and I
-      question myself if I may use all these C++ facilities, like lambdas,
-      complicated templates and other stuff.
-    <mcsim> kilobug: And using only things that you understand well sounds
-      straightforward and logical
-    <braunr> that's why i don't write c++ code :)
-    <braunr> it's very complicated and requires a lot of effort for the
-      developer to actually master it
-    <braunr> mcsim: you can use those features, but sparsely, when they really
-      do bring something useful
-
-
-# Leak Detection
-
-See *Leak Detection* on [[boehm_gc]].
diff --git a/open_issues/console_tty1.mdwn b/open_issues/console_tty1.mdwn
deleted file mode 100644
index 614c02c9..00000000
--- a/open_issues/console_tty1.mdwn
+++ /dev/null
@@ -1,151 +0,0 @@
-[[!meta copyright="Copyright © 2012 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_hurd]]
-
-Seen in context of [[libpthread]], but probably not directly related to it.
-
-
-# IRC, freenode, #hurd, 2012-08-30
-
-    <gnu_srs> Do you also experience a frozen hurd console?
-    <braunr> yes
-    <braunr> i didn't check but i'm almost certain it's a bug in my branch
-    <braunr> the replacement of condition_implies was a bit hasty in some
-      places
-    <braunr> this is why i want to rework it separately
-
-
-## IRC, freenode, #hurd, 2012-09-03
-
-    <gnu_srs> braunr: Did you find the cause of the Hurd console freeze for
-      your libpthread branch?
-    <braunr> gnu_srs: like i said, a bug
-    <braunr> probably in the replacement of condition_implies
-    <braunr> i rewrote that part in libpipe and it no works
-    <braunr> now*
-
-    <braunr> gnu_srs: the packages have been updated
-    <braunr> and these apparently fix the hurd console issue correctly
-
-## IRC, freenode, #hurd, 2012-09-04
-
-    <braunr> gnu_srs: this hurd console problem isn't fixed
-    <braunr> it seems to be due to a race condition that only affects the first
-      console
-    <braunr> and by reading the code i can't see how it can even work oO
-    <gnu_srs> braunr: just rebooted, tty1 is still locked, tty2-6 works. And
-      the floppy error stays (maybe a kvm bug??) 
-    <braunr> the floppy error is probably a kvm bug as we discussed
-    <braunr> the tty1 locked isn't
-    <braunr> i have it too
-    <braunr> it seems to be a bug in the hurd console server
-    <braunr> which is started by tty1, but for some reason, doesn't return a
-      valid answer at init time
-    <braunr> if you kill the term handling tty1, you'll see your first tty
-      starts working
-    <braunr> for now i'll try a hack that starts the hurd console server before
-      the clients
-    <braunr> doesn't work eh
-    <braunr> tty1 is the only one started before runttys
-    <braunr> indeed, fixing /etc/hurd/runsystem.gnu so that it doesn't touch
-      tty1 fixes the problem
-    <gnu_srs> do you have an explanation?
-    <braunr> not really no
-    <braunr> but it will do for now
-    <pinotree> samuel added that with the comment above, apparently to
-      workaround some other issue of the hurd console
-    <braunr> i'm pretty sure the bug is already visible with cthreads
-    <braunr> the first console always seems weird compared to the others
-    <braunr> with a login: at the bottom of the screen
-    <braunr> didn't you notice ?
-    <pinotree> sometimes, but not often
-    <braunr> typical of a race
-    <pinotree> (at least for me)
-    <braunr> pthreads being slightly slower exposes it
-    <gnu_srs> confirmed, it works by commenting out touch /dev/tty1
-    <gnu_srs> yes, the login is at the bottom of the screen, sometimes one in
-      the upper part too:-/
-    <braunr> so we have a new open issue
-    <braunr> hm
-    <braunr> exiting the first tty doesn't work
-    <braunr> which makes me think of the issue we have with screen
-    <gnu_srs> confirmed!
-    <braunr> also, i don't understand why we have getty on tty1, but nothing on
-      the other terminals
-    <braunr> something is really wrong with terminals on hurd *sigh*
-    <braunr> ah, the problem looks like it happens when getty attempts to
-      handle a terminal !
-    <braunr> gnu_srs: anyway, i don't think it should be blocking for the
-      conversion to pthreads
-    <braunr> but it would be better if someone could assign himself that bug
-    <braunr> :)
-
-
-## IRC, freenode, #hurd, 2012-09-05
-
-    <antrik> braunr: the login at the bottom of the screen if from the Mach
-      console I believe
-    <braunr> antrik: well maybe, but it shouldn't be there anyway
-    <antrik> braunr: why not?
-    <antrik> it's confusing, but perfectly correct as far as I can tell
-    <braunr> antrik: two login: on the same screen ?
-    <braunr> antrik: it's even more confusing when comparing with other ttys
-    <antrik> I mean it's correct from a techincal point of view... I'm not
-      saying it's helpful for the user ;-)
-    <braunr> i'm not even sure it's correct
-    <braunr> i've double checked the pthreads patch and didn't see anything
-      wrong there
-    <antrik> perhaps the startup of the Hurd console could be delayed a bit to
-      make sure it happens after the Mach console login is done printing
-      stuff...
-    <braunr> why are our gettys stubs ?
-    <antrik> I never understood the point of a getty TBH...
-    <braunr> well you need to communicate to something behind your terminal,
-      don't you ?
-    <braunr> with*
-    <antrik> why not just launch the login program or login shell right away?
-    <braunr> what if you want something else than a login program ?
-    <antrik> like what?
-    <antrik> and how would a getty help with that?
-    <braunr> an ascii-art version of star wars
-    <braunr> it would be configured to start something else
-    <antrik> and why does that need a getty? why not just start something else
-      directly?
-    <braunr> well getty is about the serial line parameters actually
-    <antrik> yeah, I had a vague understanding that it has something to do with
-      serial lines (or real TTY lines)... but we hardly need that on local
-      cosoles :-)
-    <antrik> consoles
-    <braunr> right
-    <braunr> but then why even bother with something like runttys
-    <antrik> well, something has to start the terminal servers?...
-    <antrik> I might be confused though
-    <braunr> what i don't understand is
-    <braunr> why is there no getty at startup, whereas they are spawned when
-      logging off ?
-    <antrik> they are? that's fascinating indeed ;-)
-    <braunr> does it behave like this on your old version ?
-    <antrik> I don't remember ever having seen a "getty" process on my Hurd
-      systems...
-    <braunr> can you log on e.g. tty2 and then log out, and see ?
-    <antrik> OTOH, I'm hardly ever using consoles...
-    <antrik> hm... I think that should be possible remotely using the console
-      client with ncurses driver? never tried that...
-    <braunr> ncurses driver ?
-    <braunr> hum i don't know, never tried either
-    <braunr> and it may add other bugs :p
-    <braunr> better wait to be close to the machine
-    <antrik> hehe
-    <antrik> well, it's a good excuse for trying the ncurses driver ;-)
-    <antrik> hrm
-    <antrik> alien:~# console -d ncursesw
-    <antrik> console: loading driver `ncursesw' failed: Gratuitous error
-    <antrik> I guess nobody tested that stuff in years
diff --git a/open_issues/console_vs_xorg.mdwn b/open_issues/console_vs_xorg.mdwn
deleted file mode 100644
index ffefb389..00000000
--- a/open_issues/console_vs_xorg.mdwn
+++ /dev/null
@@ -1,31 +0,0 @@
-[[!meta copyright="Copyright © 2012 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]]
-
-
-# IRC, freenode, #hurd, 2012-08-30
-
-    <gean> braunr: I have some errors about keyboard in the xorg log, but
-      keyboard is working on the X
-    <braunr> gean: paste the log somewhere please
-    <gean> braunr: http://justpaste.it/19jb
-    [...]
-    [1987693.272] Fatal server error:
-    [1987693.272] Cannot set event mode on keyboard (Inappropriate ioctl for device)
-    [...]
-    [1987693.292] FatalError re-entered, aborting
-    [1987693.302] can't reset keyboard mode (Inappropriate ioctl for device)
-    [...]
-    <braunr> hum
-    <braunr> it looks like the xorg keyboard driver evolved and now uses ioctls
-      our drivers don't implement
-    <braunr> thanks for the report, we'll have to work on this
-    <braunr> i'm not sure the problem is new actually
diff --git a/open_issues/contributing.mdwn b/open_issues/contributing.mdwn
deleted file mode 100644
index 7ae742f0..00000000
--- a/open_issues/contributing.mdwn
+++ /dev/null
@@ -1,44 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_documentation]]
-
-This should be integrated into [[/contributing]].
-
----
-
-Every now and then, people show up who have an inward urge to contribute to the
-GNU Hurd, but have some difficulties about how to do that.
-
-For example, IRC, #hurd, 2010-10-06:
-
-    <rah> I find it difficult to find the will to contribute to the hurd while hurd != hurd-ng
-    <pochu> hurd-ng?
-    <pochu> ah, http://www.gnu.org/software/hurd/hurd/ng.html
-    <pochu> rah: you may want to work on achieving that then
-    <rah> pochu: I'm not in a position to do OS research
-    <antrik> rah: if you are not into OS research, why do you need it to be ngHurd? :-)
-    <rah> antrik: I don't want to work on software which I know is already obsolete
-    <tschwinge> rah: My position on that can be found here; you may want to think about it.  http://lists.gnu.org/archive/html/bug-hurd/2007-07/msg00111.html
-    <antrik> rah: the existing Hurd implementation is not any more obsolete than any other large software project
-    <antrik> there are always things that could be redone in a better way some time in the future
-    <antrik> but we have to start somewhere
-    <antrik> software development is a dynamic process
-    <antrik> trying to come up with a perfect design before you write any code will never lead anywhere, ever
-    <rah> antrik: of course, but when you know your start is wrong, have identified its problems, and are in the process of designing a second attempt, working on the first seems pointless
-    <antrik> rah: well, do you know all these things? because I do not
-    <antrik> what the experiments with new Hurd designs proved so far is that nobody is in a position to claim, "I have a better design"
-    <antrik> it's not hard to come up with a design that is better in some points -- but it's damn hard to come up with one that's not lacking in others
-    <antrik> the existing Hurd design is actually the only one which we *know* to work
-    <antrik> while research on improving the design is certainly beneficial, it's not like there is something new ready to replace the existing design at any moment
-    <antrik> and frankly, I'm more and more convinced that only iterative changes can ever result in any real improvement
-    <antrik> (and doing these changes requires a certain momentum, which we will never gain unless we actually have something usable first)
-    <LarstiQ> rah: afaik, not much is being done of designing another attempt
-    <rah> antrik: yes, I know all these things
diff --git a/open_issues/crash_server.mdwn b/open_issues/crash_server.mdwn
deleted file mode 100644
index 3d656082..00000000
--- a/open_issues/crash_server.mdwn
+++ /dev/null
@@ -1,270 +0,0 @@
-[[!meta copyright="Copyright © 2009, 2010, 2011, 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_hurd]]
-
-Given an `a.out` executable that only does `raise (SIGABRT)`, invoking that
-one...
-
-  * ... against `crash-dump-core` will...
-
-      * ... not overwrite existing `core` files.
-
-        Is this reasonable?  Linux does overwrite them, for example.
-
-      * ... show big variances in running-time behavior:
-
-            $ TIMEFORMAT='real %R user %U system %S'
-            $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core
-            Aborted (core dumped)
-            real 1.350 user 0.000 system 0.010
-            -rw------- 1 tschwinge tschwinge 17031168 Jul  7 21:59 core
-            $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core
-            Aborted (core dumped)
-            real 22.771 user 0.000 system 0.010
-            -rw------- 1 tschwinge tschwinge 17031168 Jul  7 21:59 core
-            $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core
-            Aborted (core dumped)
-            real 1.367 user 0.000 system 0.010
-            -rw------- 1 tschwinge tschwinge 17031168 Jul  7 22:00 core
-            $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core
-            Aborted (core dumped)
-            real 5.789 user 0.000 system 0.010
-            -rw------- 1 tschwinge tschwinge 17031168 Jul  7 22:00 core
-            $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core
-            Aborted (core dumped)
-            real 22.664 user 0.010 system 0.000
-            -rw------- 1 tschwinge tschwinge 17031168 Jul  7 22:01 core
-
-      * ... produce a huge `core` file:
-
-            $ du -hs core 
-            17M     core
-
-        On Linux, the `core` file occupies 76 KiB of disk space, which seems
-        much more reasonable. This is possibly related with the default 128MiB
-        heap preallocation.
-
-      * ... does not always produce a useful backtrace:
-
-        `abort();`
-
-            $ gdb test core
-            warning: core file may not match specified executable file.
-            [New Thread 86678]
-            warning: Wrong size fpregset in core file.
-            ...
-            Core was generated by `./test'.
-            Program terminated with signal 6, Aborted.
-            warning: Wrong size fpregset in core file.
-            (gdb) bt
-            #0  0x00000000 in ?? ()
-            #1  0x011f593f in __msg_sig_post (process=72, signal=6, sigcode=0, refport=1)
-                at /build/buildd-eglibc_2.10.2-7-hurd-i386-iGL6op/eglibc-2.10.2/build-tree/hurd-i386-libc/hurd/RPC_msg_sig_post.c:144
-            #2  0x0109a433 in kill_port (pid=<value optimized out>)
-                at ../sysdeps/mach/hurd/kill.c:68
-            #3  kill_pid (pid=<value optimized out>) at ../sysdeps/mach/hurd/kill.c:105
-            #4  0x0109a69f in __kill (pid=21142, sig=6) at ../sysdeps/mach/hurd/kill.c:139
-            #5  0x01099af6 in raise (sig=6) at ../sysdeps/posix/raise.c:27
-            #6  0x0109de59 in abort () at abort.c:88
-            #7  0x0804849f in main ()
-
-        `char *foo = 0; *foo = 1;`
-
-            $ gdb test core
-            Program terminated with signal 11, Segmentation fault.
-            warning: Wrong size fpregset in core file.
-            #0  0x00000000 in ?? ()
-            (gdb) bt
-            #0  0x00000000 in ?? ()
-            #1  0x0108565b in __libc_start_main (main=0x8048464 <main>, argc=1, ubp_av=0x1023e64, 
-                init=0x8048490 <__libc_csu_init>, fini=0x8048480 <__libc_csu_fini>, rtld_fini=0xea20 <_dl_fini>, 
-                stack_end=0x1023e5c) at libc-start.c:251
-            #2  0x080483d1 in _start ()
-
-        `raise (SIGABRT);`
-
-            $ gdb a.out core
-            warning: core file may not match specified executable file.
-            [New Thread 76651]
-            
-            warning: Wrong size fpregset in core file.
-            Reading symbols from /lib/libc.so.0.3...[...]
-            Core was generated by `./a.out'.
-            Program terminated with signal 6, Aborted.
-            
-            warning: Wrong size fpregset in core file.
-            #0  0x00000000 in ?? ()
-            (gdb) bt
-            #0  0x00000000 in ?? ()
-            Cannot access memory at address 0x17
-
-        [[!tag open_issue_gdb]] Probably [[GDB]] doesn't manage to dig in the stack properly.
-
-  * ... against `crash-suspend` will...
-
-      * ... not work at all:
-    
-            $ CRASHSERVER=/servers/crash-suspend ./a.out
-            $ [returns to the shell and doesn't suspended]
-
-      * ... show big variances in running-time behavior:
-    
-            $ TIMEFORMAT='real %R user %U system %S'
-            $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
-            Aborted (core dumped)
-            real 1.381 user 0.000 system 0.010
-            -rw------- 1 tschwinge tschwinge 17031168 Jul  7 22:04 core
-            $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
-            Aborted (core dumped)
-            real 1.332 user 0.000 system 0.010
-            -rw------- 1 tschwinge tschwinge 17031168 Jul  7 22:04 core
-            $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
-            Aborted (core dumped)
-            real 21.228 user 0.000 system 0.010
-            -rw------- 1 tschwinge tschwinge 17031168 Jul  7 22:04 core
-            $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
-            Aborted (core dumped)
-            real 1.323 user 0.000 system 0.010
-            -rw------- 1 tschwinge tschwinge 17031168 Jul  7 22:05 core
-            $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
-            Aborted (core dumped)
-            real 22.279 user 0.000 system 0.010
-            -rw------- 1 tschwinge tschwinge 17031168 Jul  7 22:05 core
-            $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
-            Aborted (core dumped)
-            real 1.362 user 0.000 system 0.000
-            -rw------- 1 tschwinge tschwinge 17031168 Jul  7 22:08 core
-            $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
-            Aborted (core dumped)
-            real 21.110 user 0.000 system 0.000
-            -rw------- 1 tschwinge tschwinge 17031168 Jul  7 22:08 core
-            $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
-            Aborted (core dumped)
-            real 1.350 user 0.000 system 0.020
-            -rw------- 1 tschwinge tschwinge 17031168 Jul  7 22:08 core
-
-      * ... can reliably crash GNU Mach:
-
-        This happens if a `core` file is already present (and won't get
-        overwritten; see above).  I reproduced this three times.
-
-            $ TIMEFORMAT='real %R user %U system %S'
-            $ time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core
-            Aborted
-            real 2.856 user 0.000 system 0.010
-            -rw------- 1 tschwinge tschwinge 17031168 Jul  7 22:08 core
-
-            panic: zalloc: zone kalloc.8192 exhausted
-            Kernel Breakpoint trap, eip 0x20020a77
-            Stopped at  0x20020a76: int     $3
-            db> trace
-            0x20020a76(2006aba8,4d0f7e9c,200209b0,0,0)
-            0x20020a4d(2006b094,2006ae40,2000,20016803,4a5f4114)
-            0x2002bca5(49a03564,1,0,9,1000)
-            0x20022f4c(2000,4a5f45d4,4a84879c,49a46564,4ac43e78)
-            0x20021e65(4ac43e78,4a5f45d4,4a5f4114,0,0)
-            0x2005309d(2106ba9c,3,38,28,1783)
-            Bad frame pointer: 0x2106ba78
-
-            $ addr2line -i -f -e /boot/gnumach-xen 0x20020a76 0x20020a4d 0x2002bca5 0x20022f4c 0x20021e65 0x2005309d
-            Debugger
-            /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/debug.c:105
-            panic
-            /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/debug.c:148
-            zalloc
-            /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/zalloc.c:470
-            kalloc
-            /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/kalloc.c:185
-            ipc_kobject_server
-            /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/ipc_kobject.c:76
-            mach_msg_trap
-            /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/ipc/mach_msg.c:1367
-
-
-# IRC, freenode, #hurd, 2013-09-07
-
-    <rekado> I'm trying to investigate a crash in pfinet, so it will actually
-      die.  I just want to know why it dies and what the value of a few
-      variables has been when it died.
-    <teythoon> have you tried to make it dump core?
-    <rekado> oh, good idea.
-    <rekado> I'll try that.
-    <teythoon> do you know how?
-    <rekado> I don't, but I think I can figure it out.
-    <teythoon> look into /servers
-    <rekado> do I just have to set CRASHSERVER=/servers/crash-dump-core and run
-      pfinet in that environment?
-    <teythoon> possibly, I've never heard of CRASHSERVER, but it's certainly
-      plausible ;)
-    <teythoon> I just link crash to crash-dump-core, that way it is permanent
-      and for all processes
-    <rekado> found it in the website contents
-    <rekado> gotta try that.
-    <rekado> hmm, I can't get pfinet to dump core; linked /servers/crash to
-      /servers/crash-dump-core and compiled pfinet to raise(6) at one point.
-    <rekado> But no core file is created.
-    <teythoon> :/
-    <teythoon> rekado: try cd /tmp ; cat & kill -SIGILL %% to see if that dumps
-      core
-    <rekado> yes, this works.
-    <rekado> I replaced the original pfinet with my crashing version.
-    <rekado> Should it dump core to /hurd then?
-    <teythoon> I'm not sure about it's wd
-    <teythoon> hm, ok, I just did settrans -ca foo /hurd/pfinet and then killed
-      that pfient with SIGILL and it dumped core
-    <teythoon> to the directory I issued the settrans from
-    <rekado> So I must run it myself.  I can't just replace the original binary
-      and have it dump core somewhere.
-    <teythoon> it seems that you have to use settrans -ca to start an active
-      translator
-    <teythoon> do fsysopts /servers/socket/2 to find out the cmdline of your
-      pfinet
-    <rekado> that's very helpful.
-    <rekado> thanks
-    <teythoon> then use this to restart it, e.g.:
-    <teythoon> settrans -afg /servers/socket/2 $(fsysopts /servers/socket/2)
-    <teythoon> if it dies it should dump core to you cwd
-    <rekado> great. Thank you very much.  I had been wondering how to get the
-      full cmdline of pfinet.
-    * rekado makes a note of fsysopts
-    <rekado> yup, there's the core file. Nice.
-    <teythoon> cool 8D
-    <teythoon> btw, in case using gdb doesn't work out for your problem, if you
-      start pfinet (or any translator) this way (with -a == active), you can
-      write stuff to stderr
-    <rekado> yeah, I noticed that.  The assert() call wrote to stderr.  Useful.
-    <braunr> rekado: core dumps are another not-working-well feature of the
-      hurd :/
-    <braunr> i recommend attaching
-    <tschwinge> rekado: In case that's still helpful:
-      <http://www.gnu.org/software/hurd/hurd/debugging/translator.html>.
-
-
-# IRC, freenode, #hurd, 2013-12-14
-
-    <gnu_srs> How to get a core dump?
-    <teythoon> either set CRASHSERVER to /servers/crash-dump-core for the
-      process you want the core file of
-    <teythoon> or make /servers/crash point to crash-dump-core to make this the
-      default for all processes
-    <gnu_srs> does it work now, it did not before?
-    <teythoon> it does for me, never had issues
-    <gnu_srs> k!
-    <teythoon> well, i believe the second option has issues
-    <teythoon> if two processes crash, both may write/create a file in the same
-      location
-
-
----
-
-If someone is working in this area, they may want to have a look at
-[[GDB_gcore]], and port <http://code.google.com/p/google-coredumper/>, too.
diff --git a/open_issues/crashes_vs_system_load_cpu_load_rpc_load.mdwn b/open_issues/crashes_vs_system_load_cpu_load_rpc_load.mdwn
deleted file mode 100644
index 4076d8d0..00000000
--- a/open_issues/crashes_vs_system_load_cpu_load_rpc_load.mdwn
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-IRC, unknown channel, unknown date:
-
-    <antrik> I have a theory
-    <antrik> when the system is under CPU load, the ext2 locking issues are more likely to happen
-    <antrik> I'm under the impression, that when doing something disk-intensive (like a compile job) *considerably* more often causes crashes, when doing *any* other activity in parallel -- be it other compile jobs, or CPU-only activities
-    <antrik> thinking about it, I'm not sure whether CPU-intensive is the decisive criterium, or maybe RPC-intensive...
-    <antrik> CPU load doesn't seem to have any effect -- neither alone, nor in combination with other testcases
diff --git a/open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn b/open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn
deleted file mode 100644
index b94c0c1d..00000000
--- a/open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn
+++ /dev/null
@@ -1,41 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_gcc]]
-
-    $ gcc -o /dev/null -x c /dev/null 
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 0 has invalid symbol index 12
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 1 has invalid symbol index 13
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 2 has invalid symbol index 2
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 3 has invalid symbol index 2
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 4 has invalid symbol index 12
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 5 has invalid symbol index 14
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 6 has invalid symbol index 14
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 7 has invalid symbol index 14
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 8 has invalid symbol index 2
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 9 has invalid symbol index 2
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 10 has invalid symbol index 13
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 11 has invalid symbol index 14
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 12 has invalid symbol index 14
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 13 has invalid symbol index 14
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 14 has invalid symbol index 14
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 15 has invalid symbol index 14
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 16 has invalid symbol index 14
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 17 has invalid symbol index 14
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 18 has invalid symbol index 14
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 19 has invalid symbol index 14
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 20 has invalid symbol index 14
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 21 has invalid symbol index 14
-    /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 22 has invalid symbol index 22
-    /usr/lib/gcc/i486-gnu/4.4.5/../../../crt1.o: In function `_start':
-    (.text+0x18): undefined reference to `main'
-    collect2: ld returned 1 exit status
-
-Likewise for `-static`, `crt0.o`.
diff --git a/open_issues/cvs_tasks_file.mdwn b/open_issues/cvs_tasks_file.mdwn
deleted file mode 100644
index 67b64651..00000000
--- a/open_issues/cvs_tasks_file.mdwn
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!meta copyright="Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009
-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]]."]]"""]]
-
-[[!meta title="CVS tasks file"]]
-
-[[!tag open_issue_hurd]]
-
-The canonical [tasks
-file](http://savannah.gnu.org/cgi-bin/viewcvs/~checkout~/hurd/hurd/tasks?rev=HEAD&content-type=text/plain)
-from the CVS archive.
diff --git a/open_issues/cvs_todo_file.mdwn b/open_issues/cvs_todo_file.mdwn
deleted file mode 100644
index a42e6dca..00000000
--- a/open_issues/cvs_todo_file.mdwn
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!meta copyright="Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009
-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]]."]]"""]]
-
-[[!meta title="CVS TODO file"]]
-
-[[!tag open_issue_hurd]]
-
-The canonical [TODO
-file](http://savannah.gnu.org/cgi-bin/viewcvs/~checkout~/hurd/hurd/TODO?rev=HEAD&content-type=text/plain)
-from the CVS archive.
diff --git a/open_issues/dbus.mdwn b/open_issues/dbus.mdwn
deleted file mode 100644
index b3bebf48..00000000
--- a/open_issues/dbus.mdwn
+++ /dev/null
@@ -1,502 +0,0 @@
-[[!meta copyright="Copyright © 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_hurd]]
-
-The dbus problems are due to missing scm credentials [[sendmsg_scm_creds]] and socket credentials
-[[pflocal_socket_credentials_for_local_sockets]]. There was also a problem with short timeout in 
-[[select]], but that has been solved in Debian by setting a minimum timeout of 1ms.
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2011-11-26
-
-    <antrik> BTW, how much effort is necessary to fix dbus?
-    <pinotree> basically, have pflocal know who's the sender
-      (pid/uid/gid/groups) in the socket send op
-
-
-# IRC, freenode, #hurd, 2011-12-16
-
-    <braunr> pinotree: what's the problem with dbus ?
-    <pinotree> braunr: select() returning 0 changed fd's with very short (eg <
-      1ms) timeouts when there are actually events;
-
-[[select]].
-
-    <pinotree> and missing socket credentials
-
-[[sendmsg_scm_creds]].
-
-    <braunr> oh
-    <braunr> which socket creds interface ?
-    <pinotree> bsd, i.e. with SCM_CREDENTIALS payload for cmsg on
-      {recv,send}msg()
-    <braunr> ok
-    <braunr> SCM_RIGHTS too ?
-    <braunr> the select issue seems weird though
-    <pinotree> hm no, that's for passing fd's to other processes
-    <braunr> is it specific to pflocal or does dbus use pfinet too ?
-    <pinotree> iirc on very short timeouts the application has no time waiting
-      for the reply of servers
-    <braunr> i see
-    <pinotree> braunr: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=79358
-    <braunr> thanks
-    <pinotree> (the interesting messages are from #53 and on)
-    <braunr> 2000 eh ... :)
-    <braunr> hm i agree with neal, i don't understand why the timeout is given
-      to the kernel as part of the mach_msg call
-
-
-# IRC, freenode, #hurd, 2011-12-20
-
-    <braunr> hm, i don't see any occurrence of SCM_CREDENTIALS in dbus
-    <braunr> only SCM_RIGHTS
-    <pinotree> braunr: yes, that one
-    <braunr> oh
-    <braunr> i thought you said the opposite last time
-    <pinotree> dbus/dbus-sysdeps-unix.c, write_credentials_byte and
-      _dbus_read_credentials_socket (with #define HAVE_CMSGCRED)
-    <braunr> hm
-    <braunr> which version ?
-    <braunr> i don't see anything in 1.4.16
-    <pinotree> 1.4.16
-    <braunr> grmbl
-    <braunr> ah, i see
-    <braunr> SCM_CREDS
-    <pinotree> if you want, i have a simplier .c source with it
-    <braunr> no i'm just gathering info
-    <pinotree> ok
-    <braunr> what's the deal with SCM_CREDS and SCM_CREDENTIALS ?
-    <braunr> bsd vs sysv ?
-    <braunr> oh, http://lists.debian.org/debian-hurd/2002/03/msg00135.html
-    <braunr> so we actually do want both SCM_CREDS and SCM_RIGHTS for debus
-    <braunr> dbus
-    <pinotree> SCM_RIGHTS is a different matter, it is for passing fd's
-    <braunr> yes
-    <braunr> but it's used by dbus
-    <braunr> so if we can get it, it should help too
-    <pinotree> there's a preliminary patch for it done by emilio time ago, and
-      iirc it's applied to debian's glibc
-    <braunr> ah, he changed the libc
-    <braunr> right, that's the only sane way
-    <pinotree> iirc roland didn't like one or more parts of it (but i could be
-      wrong)
-    <braunr> ok
-
-
-# IRC, freenode, #hurd, 2013-07-17
-
-    <teythoon> btw pinotree, what happened to your efforts to make dbus work?
-    <pinotree> not much, my initial patch was just a crude hack, a better
-      solution requires more thinkering and work 
-    <teythoon> yes, ive seen that
-    <teythoon> but that was only a tiny patch against the libc, surely there
-      must be more to that?
-    <pinotree> not really
-    <teythoon> and the proper fix is to patch pflocal to query the auth server
-      and add the credentials?
-    <pinotree> possibly
-    <teythoon> that doesn't sound to bad, did you give it a try?
-    <pinotree> not really, got caught in other stuff
-
-
-# IRC, freenode, #hurd, 2013-09-02
-
-    <gnu_srs1> something is wrong with libc0.3 since the switch to 2.17. dbus
-      does not run any longer when rebuilt
-    <gnu_srs1> the latest build of dbus was with 2.13: libc0.3-dev: already
-      installed (2.13-38)
-    <pinotree> debug it
-    <gnu_srs1> Yes, I will. Maybe somebody could rebuild it and verify my
-      findings?
-    <pinotree> gnu_srs1: your finding is "doesn't work", which is generic and
-      does not help without investigation
-    <gnu_srs1> just rebuild it and: e.g. ./build-debug/bus/dbus-daemon --system
-      (--nofork)
-    <pinotree> gnu_srs1: please, debug it
-    <gnu_srs1> I have partially already. But maybe the problems only shows on
-      my box. I'll rebuild on another box before continuing debugging.
-    <pinotree> gnu_srs1: are you, by chance, running a libc or something else
-      with your scm_creds work?
-    <gnu_srs1> I did, but I've backed to 2.17-92 right now.
-    <gnu_srs1> sane problem with dbus on another box, something's fishy:-(
-    <gnu_srs1> braunr: any good way to find out if the dbus problems are with
-      libpthread? Setting a breakpoint with libc0.3-dbg installed.
-    <braunr> gnu_srs1: i don't know
-
-See [[glibc]], *Missing interfaces, amongst many more*, *`SOCK_CLOEXEC`*.
-
-
-# IRC, freenode, #hurd, 2013-09-04
-
-    <gnu_srs> Hi, looks like dbus requires abstract socket namespace: #undef
-      HAVE_ABSTRACT_SOCKETS What's missing?
-    <pinotree> uh?
-    <pinotree> abstract unix sockets are a Linux feature, and surely it is not
-      mandatory for dbus
-    <gnu_srs> Looks like dbus exits if they are not supported:
-    <gnu_srs>  dbus_set_error (error, DBUS_ERROR_NOT_SUPPORTED,  "Operating
-      system does not support abstract socket namespace\n");        _dbus_close
-      (listen_fd, NULL);  1061       return -1;
-    <pinotree> that is enclosed in a if (abstract)
-    <pinotree> and that parameter is set to true in other places (eg
-      dbus/dbus-server-unix.c) only when HAVE_ABSTRACT_SOCKETS is defined
-    <pinotree> so no, abstract sockets are not mandatory
-    <gnu_srs> Well this code is executed e.g. when running emacs remotely in
-      X. Have to dig deeper then to see why.
-    <pinotree> maybe it could have to do the fact that your dbus server is
-      running in linux and runs by default using such sockets type
-    <pinotree> but yes, you need to dig better
-    <gnu_srs> pinotree: You are right. when running natively the problem is:
-    <pinotree> *drums*
-    <gnu_srs> Manually: Process /usr/lib/at-spi2-core/at-spi-bus-launcher
-      exited with status 1
-    <pinotree> eh?
-    <gnu_srs> Error retrieving accessibility bus address:
-      org.freedesktop.DBus.Error.Spawn.ChildExited: ^
-    <pinotree> most probably that service does not start due to the lack of
-      socket credentials which affects dbus
-    <pinotree> uninstall or disable those additional services, they are not
-      your problem
-    <gnu_srs> credentials is enabled. which services to remove?
-    <pinotree> dunno
-
-
-# IRC, freenode, #hurd, 2013-09-11
-
-    <gnu_srs> Hi, looks like frebsd had (2008) the same problem as hurd when
-      sending credentials over PF_INET: 
-    <gnu_srs>
-      http://lists.freebsd.org/pipermail/freebsd-hackers/2008-May/024577.html
-    <gnu_srs> Since the dbus code is about the same now (2013), maybe they
-      added support?
-    <gnu_srs> The next message in the thread confirms that the dbus code is
-      invalid, does anybody have pointers?
-    <pinotree> from what i've seen so far, socket credentials are done only for
-      local sockets (ie PF_UNIX)
-    <pinotree> i don't see how things like uid/gid/pid of the socket endpoint
-      can have anything to do with AF_INET
-    <pinotree> and socket credentials in dbus are used only in the [local]
-      socket transport, so there's no issue
-
-
-# IRC, freenode, #hurd, 2013-09-12
-
-    <gnu_srs> pinotree: Yes, there is an issue with dbus and AF_INET, see
-      test/corrupt.c: tests /corrupt/tcp and /corrupt/byte-order/tcp:-/
-    <pinotree> gnu_srs: what's wrong with those? they are just testing the
-      connection over a tcp socket
-    <pinotree> as said above, socket credentials shouldn't be used in such
-      cases
-    <gnu_srs> They are, see also test/relay.c: /relay and /limit tests:-(
-    <pinotree> how are they?
-    <pinotree> please be more specifc...
-    <gnu_srs> Just run the tests yourself with DBUS_VERBOSE=1
-    <pinotree> you are claiming there is a problem, so please specify what is
-      the actual issue
-    <gnu_srs>  DBUS_VERBOSE=1 build-debug/test/test-relay 
-    <pinotree> you are claiming there is a problem, so please specify what is
-      the actual issue
-    <gnu_srs> same with test-corrupt
-    <gnu_srs> look at the verbose output:  Failed to write credentials: Failed
-      to write credentials byte: Invalid argument
-    <gnu_srs> coming from pfinet since PF_INET is used.
-    <pinotree> check what it does on linux then
-    <pinotree> put an abort() at the start of the read/write socket credential
-      functions in dbus-sysdeps-unix.c and see whether it is triggered also on
-      linux
-    <gnu_srs> SO_PEERCRED is used for linux and LOCAL_CREDS is used for
-      kfreebsd, so we are on our own here:-/
-    <pinotree> and linux' SO_PEERCRED works also on AF_INET sockets? i'd doubt
-      it
-    <gnu_srs>
-      http://stackoverflow.com/questions/10037086/so-peercred-vs-scm-credentials-why-there-are-both-of-them
-    <pinotree> yes, i know the difference, but please read what i asked again
-    <gnu_srs> I'll check to be sure...
-    <braunr> gnu_srs: user credentials are not supposed to be passed through an
-      AF_INET socket
-    <braunr> how hard is that to understand ?
-    <gnu_srs> OK, linux use send since CMSGCREDS is not defined to write
-      credentials. Working on how they are received.
-    <gnu_srs> braunr: I do understand, but the dbus code tries to do that for
-      Hurd:-(
-    <pinotree> then it should do that on linux too
-    <pinotree> (since the local socket credentials code is isolated in own
-      functions, and they are called only for the unix transport)
-    <gnu_srs> Happiness:-D, almost all dbus tests pass!
-    <gnu_srs> 17(17) dbus tests pass:)
-    <braunr> gnu_srs: hopefully your patch does things right
-    <gnu_srs> which patch
-    <braunr> adding credentials through unix socket
-    <braunr> isn't that what you're doing ?
-    <gnu_srs> the mail to MLs is from the stock installed packages.
-    <braunr> ?
-    <gnu_srs> the test reports are with the SCM_CREDS patches, but I stumbled
-      on the SCM_RIGHTS issues reported to MLs
-    <gnu_srs> no patches applied, just test the attached file yourself.
-    <braunr> so what's your work about ?
-    <gnu_srs> I'm working on SCM_CREDS, yes, and created patches for dbus,
-      glib2.0 and libc.
-    <gnu_srs> the mail was about some bug in the call to io_restrict_auth in
-      sendmsg.c: without any of my patches applied (another image) 
-    <teythoon> gnu_srs: you have to give us more context, how are we supposed
-      to know how to find this sendmsg.c file?
-    <pinotree> (it's in glibc, but otherwise the remark is valid)
-    <pinotree> s/otherwise/anyway/
-
-
-# Emails
-
-# IRC, freenode, #hurd, 2013-10-16
-
-    <braunr> gnu_srs: how could you fail to understand credentials need to be
-      checked ?
-    <gnu_srs> braunr: If data is sent via sendmsg, no problem, right?
-    <braunr> gnu_srs: that's irrelevant
-    <gnu_srs> It's just to move the check to the receive side.
-    <braunr> and that is the whole problem
-    <braunr> it's not "just" doing it
-    <braunr> first, do you know what the receive side is ?
-    <braunr> do you know what it can be ?
-    <braunr> do you know where the corresponding source code is to be found ?
-    <gnu_srs> please, describe a scenario where receiving faulty ancillary data
-      could be a problem instead
-    <braunr> dbus
-    <braunr> a user starting privileged stuff although he's not part of a
-      privileged group of users for example
-    <braunr> gnome, kde and others use dbus to pass user ids around
-    <braunr> if you can't rely on these ids being correct, you can compromise
-      the whole system
-    <braunr> because dbus runs as root and can give root privileges
-    <braunr> or maybe not root, i don't remember but a system user probably
-    <pinotree> "messagebus"
-    <gnu_srs> k!
-    <braunr> see http://www.gnu.org/software/hurd/open_issues/dbus.html
-    <braunr> IRC, freenode, #hurd, 2013-07-17
-    <braunr> <teythoon> and the proper fix is to patch pflocal to query the
-      auth server and add the credentials?
-    <braunr> <pinotree> possibly
-    <braunr> <teythoon> that doesn't sound to bad, did you give it a try?
-
-
-# IRC, freenode, #hurd, 2013-10-22
-
-    <gnu_srs> I think I have a solution on the receive side for SCM_CREDS :)
-
-    <gnu_srs> A question related to SCM_CREDS: dbus use a zero data byte to get
-      credentials sent.
-    <gnu_srs> however, kfreebsd does not care which data (and credentials) is
-      sent, they report the credentials anyway
-    <gnu_srs> should the hurd implementation do the same as kfreebsd?
-    <youpi> gnu_srs: I'm not sure to understand: what happens on linux then?
-    <youpi> does it see zero data byte as being bogus, and refuse to send the
-      creds?
-    <gnu_srs> linux is also transparent, it sends the credentials independent
-      of the data (but data has to be non-null)
-    <youpi> ok
-    <youpi> anyway, what the sending application writes does not matter indeed
-    <youpi> so we can just ignore that
-    <youpi> and have creds sent anyway
-    <braunr> i think the interface normally requires at least a byte of data
-      for ancilliary data
-    <youpi> possibly, yes
-    <braunr>        To pass file descriptors or credentials over a SOCK_STREAM,
-      you need to  send  or
-    <braunr>        receive  at  least  one  byte  of  non-ancillary  data  in
-      the same sendmsg(2) or
-    <braunr>        recvmsg(2) call.
-    <braunr> but that may simply be linux specific
-    <braunr> gnu_srs: how do you plan on implementing right checking ?
-    <gnu_srs> Yes, data has to be sent, at least one byte, I was asking about
-      e.g. sending an integer 
-    <braunr> just send a zero
-    <braunr> well
-    <braunr> dbus already does that
-    <braunr> just don't change anything
-    <braunr> let applications pass the data they want
-    <braunr> the socket interface already deals with port rights correctly
-    <braunr> what you need to do is make sure the rights received match the
-      credentials
-    <gnu_srs> The question is to special case on a zero byte, and forbid
-      anything else, or allow any data.
-    <braunr> why would you forbid 
-    <braunr> ?
-    <gnu_srs> linux and kfreebsd does not special case on a received zero byte
-    <braunr> same question, why would you want to do that ?
-    <gnu_srs> linux sends credentials data even if no SCM_CREDENTIALS structure
-      is created, kfreebsd don't
-    <braunr> i doubt that
-    <gnu_srs> To be specific:msgh.msg_control = NULL; msgh.msg_controllen = 0;
-    <braunr> bbl
-    <gnu_srs> see the test code:
-      http://lists.debian.org/debian-hurd/2013/08/msg00091.html
-    <braunr> back
-    <braunr> why would the hurd include groups when sending a zero byte, but
-      only uid when not ?
-    <gnu_srs> ?
-    <braunr> 1) Sent credentials are correct:
-    <braunr> no flags: Hurd: OK, only sent ids
-    <braunr> -z Hurd: OK, sent IDs + groups
-    <braunr> and how can it send more than one uid and gid ?
-    <braunr> "sent credentials are not honoured, received ones are created"
-    <gnu_srs> Sorry, the implementation is changed by now. And I don't special
-      case on a zero byte.
-    <braunr> what does this mean ?
-    <braunr> then why give me that link ?
-    <gnu_srs> The code still applies for Linux and kFreeBSD. 
-    <gnu_srs> It means that whatever you send, the kernel emits does not read
-      that data: see
-    <gnu_srs> socket.h: before  struct cmsgcred: the sender's structure is
-      ignored ...
-    <braunr> do you mean receiving on a socket can succeed with gaining
-      credentials, although the sender sent wrong ones ?
-    <gnu_srs> Looks like it. I don't have a kfreebsd image available right now.
-    <gnu_srs> linux returns EPERM
-    <braunr> anyway
-    <braunr> how do you plan to implement credential checking ?
-    <gnu_srs> I'll mail patches RSN
-
-
-# IRC, freenode, #hurd, 2013-11-03
-
-    <gnu_srs> Finally, SCM_CREDS (IDs) works:) I was on the right track all the
-      time, it was just a small misunderstanding.
-    <gnu_srs> remains to solve the PID check
-    <youpi> gnu_srs: it should be a matter of adding
-      proc_user/server_authenticate
-    <gnu_srs> there are no proc_user/server_authenticate RPCs?
-    <gnu_srs> do you mean adding them to process.defs (and implement them)?
-    <youpi> gnu_srs: I mean that, yes
-
-
-# IRC, freenode, #hurd, 2013-11-13
-
-    <gnu_srs> BTW: I have to modify the SCM_RIGHTS patch to work together with
-      SCM_CREDS, OK?
-    <youpi> probably
-    <youpi> depends on what you change of course
-
-
-# IRC, freenode, #hurd, 2013-11-15
-
-    <gnu_srs> Hi, any ideas where this originates, gdb? warning: Error setting
-      exception port for process 9070: (ipc/send) invalid destination port
-    <braunr> gnu_srs: what's process 9070 ?
-    <gnu_srs> braunr: It's a test program for sending credentials over a
-      socket. Have to create a reproducible case, it's intermittent.
-    <gnu_srs> The error happens when running through gdb and the sending
-      program is chrooted:
-    <gnu_srs> -rwsr-sr-x 1 root root 21156 Nov 15 15:12
-      scm_rights+creds_send.chroot
-
-
-## IRC, freenode, #hurd, 2013-11-16
-
-    <gnu_srs> Hi, I have a problem debugging a suid program, see
-      http://paste.debian.net/66171/
-    <gnu_srs> I think this reveals a gnumach/hurd bug, it makes things behave
-      strangely for other programs.
-    <gnu_srs> How to get further on with this?
-    <gnu_srs> Or can't I debug a suid program as non-root?
-    <pochu> gnu_srs: if gdb doesn't work for setuid programs on hurd, I suppose
-      you could chmod -s the binary you're trying to debug, login as root and
-      run it under gdb
-    <gnu_srs> pochu: When logged in as root the program works, independent of
-      the s flag setting.
-    <pochu> right, probably the setuid has no effect in that case because your
-      effective uid is already fine
-    <pochu> so you don't hit the gdb bug in that case
-    <pochu> (just guessing)
-    <gnu_srs> It doesn't work in Linux either, so it might be futile.
-    <gnu_srs> trying
-    <pochu> hmm that may be the expected behaviour. after all, gdb needs to be
-      priviledged to debug priviledged processes
-    <gnu_srs> Problem is that it was just the suid properties I wanted to
-      test:(
-    <braunr> gnu_srs: imagine if you could just alter the code or data of any
-      suid program just because you're debugging it
-
-
-## IRC, freenode, #hurd, 2013-11-18
-
-    <gnu_srs> Hi, is the code path different for a suid program compared to run
-      as root?
-    <gnu_srs> Combined with LD_PRELOAD?
-    <teythoon> gnu_srs: afaik LD_PRELOAD is ignored by suid programs for
-      obvious security reasons
-    <gnu_srs> aha, thanks:-/
-    <braunr> gnu_srs: what's your problem with suid ?
-    <gnu_srs> I made changes to libc and tried them out with
-      LD_PRELOAD=... test_progam. It worked as any user (including root),
-    <gnu_srs> but not with suid settings. Justus explained why not.
-    <braunr> well i did too
-    <braunr> but is that all ?
-    <braunr> i mean, why did you test with suid programs in the first place ?
-    <gnu_srs> to get different euid and egid numbers
-
-    <gnu_srs> hi, anybody seen this with eglibc-2.17-96: locale: relocation
-      error: locale: symbol errno,
-    <gnu_srs> version GLIBC_PRIVATE not defined in file libc.so.0.3 with link
-      time reference
-    <teythoon> yes, I have
-    <teythoon> but afaics nothing did break, so I ignored it
-
-
-## IRC, freenode, #hurd, 2013-11-23
-
-    <gnu_srs> Finally 8-)
-    <gnu_srs> Good news: soon both SCM_CREDS _and_ SCM_RIGHTS is supported
-      jointly. RFCs will be sent soon.
-
-
-## IRC, freenode, #hurd, 2013-12-05
-
-    <gnu_srs> I have a problem with the SCM_CREDS patch and dbus. gamin and my
-      test code runs fine.
-    <gnu_srs> the problem with the dbus code is that it won't work well with 
-    <gnu_srs> auth_user_authenticate in sendmsg and auth_server_authenticate in
-      recvmsg.
-    <gnu_srs> Should I try to modify the dbus code to make it work?
-    <youpi> unless you manage to prove that dbus is not following the posix
-      standard, there is no reason why you should have to modify dbus
-    <gnu_srs> I think the implementation is correct,
-    <gnu_srs> but auth_user_authenticate hangs sendmsg until
-      auth_seerver_authenticate is executed in recvmsg.
-    <gnu_srs> and dbus is not doing that, so it hangs in sendmsg writing a
-      credentials byte.
-    <gnu_srs> well the credentials byte is definitely non-posix.
-    <gnu_srs> I found a bug related to the HURD_DPORT_USE macro too:-(
-    <youpi> ah, yes, auth_user_authenticate might be synchronous indeed, let me
-      think about it
-    <gnu_srs> Nevertheless, I think it's time to publish the code so it can be
-      commented on:-D
-    <youpi> sure
-    <youpi> publish early, publish often
-
-
-# IRC, freenode, #hurd, 2014-01-17
-
-    <gnu_srs> youpi: as a start all our requested dbus changes are now
-      committed, and in Debian unstable
-    <youpi> good :)
-
-
-# IRC, freenode, #hurd, 2014-01-30
-
-    <pochu> dbus has some known problems
-    <pere> known fixes too?
-    <pochu> http://www.gnu.org/software/hurd/open_issues/dbus.html
-    <gnu_srs> pochu: Maybe that page should be updated:
-      http://lists.nongnu.org/archive/html/bug-hurd/2013-12/msg00150.html
-    <youpi> gnu_srs: well, maybe you can do it :
-    <youpi> )
diff --git a/open_issues/dbus_in_linux_kernel.mdwn b/open_issues/dbus_in_linux_kernel.mdwn
deleted file mode 100644
index 6f83db03..00000000
--- a/open_issues/dbus_in_linux_kernel.mdwn
+++ /dev/null
@@ -1,164 +0,0 @@
-[[!meta copyright="Copyright © 2010, 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]]."]]"""]]
-
-[[!meta title="AF_BUS, D-Bus, and the Linux kernel"]]
-
-Might be interesting to watch how this develops.
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, about 2010-08/2010-09
-
-    <neal> check this out:
-    <neal> someone is working on implementing dbus in linux
-    <neal> linux finally gets mach ipc ;-)
-    <marcusb> it's old news though, unless there is an update
-    <marcusb> and I think it was only the client?
-    <neal> youpi : someone is adding dbus ipc to the linux kernel
-    <neal> marcusb: I just heard about it.
-    <youpi> (it's crazy how this drives backward compared to a hurdish approach)
-    <youpi> what is the motivation for moving to the kernel?
-    <neal> context switch overhead
-    <azeem_> they wanna use it to talk to device drivers? :)
-    <kilobug> well, they did that with the in-kernel web server, but they
-      abandonned it later on
-    <neal> azeem: I don't think so.
-    <neal> dbus in the kernel is actually good for the Hurd as dbus IPC is
-      basically neutered Mach IPC
-    <marcusb> I don't think anybody wants to put the dbus server in the kernel
-    <neal> well, there is at least one person
-    <marcusb> maybe this is a different news from the one I read
-    <neal> Alban Crequy (albanc) is working out.  He works for collabora, fwiw
-
-<http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster/>
-
-    <marcusb> what I read was about hal etc
-    <marcusb> so that you don't need a user space daemon to glue the kernel to the
-      dbus world
-    <neal> I don't think that is what he is talking about
-    <marcusb> I can't find it anymore though.  I mentioned it in this channel at
-      the time though, so it should be in the backlog
-    <marcusb> neal, yeah could very well be a separate thing
-    <marcusb> neal, dbus does have marginal support for fd passing though, and some
-      attempts on the mailing list to make "fds" an official type in the message
-      failed (as far as I could see, I didn't read the whole discussion)
-    <marcusb> so no mach ipc just yet
-    <neal> wrong
-    <neal> FD handling is in 1.4
-    <neal> type o, if I'm not mistaken
-    <marcusb> then the discussion moved on from initial rejection
-    <neal> no, 'h'
-    <marcusb> I'm out of date by two months
-    <marcusb> ok
-    <guillem> neal: AFAIR Marcel Holtmann talked about dbus in-kernel several years
-      ago, but he never ended up implementing it, or there were rumors he had
-      private "working code"
-
-  * Related Mailing List Discussion
-
-      * [\[PATCH 0/5\] RFC: Multicast and filtering features on
-        AF_UNIX](http://article.gmane.org/gmane.linux.kernel/1040481),
-        2010-09-24
-
-
-# 2013-02
-
-[AF_BUS, D-Bus, and the Linux
-kernel](http://www.kroah.com/log/linux/af_bus.html), Greg Kroah-Hartman,
-2013-02-08.
-
-
-# kdbus
-
-
-## IRC, freenode, #hurd, 2014-01-28
-
-    <braunr> i would like to see things like dbus and zeromq use an optimized
-      microkernel transport one day
-    <teythoon> we could port kdbus >,<
-    <braunr> why not
-    <braunr> you port cgroups first
-    <teythoon> exactly
-    <braunr> :p
-
-[[systemd]].
-
-
-## IRC, freenode, #hurd, 2014-02-23
-
-In context of [[linux_as_the_kernel]], *IRC, freenode, #hurd, 2014-02-23*.
-
-    <desrt> mach seems like this really simple thing when you first explain
-      what a microkernel is
-    <braunr> and because of that, i think it's better to start the right
-      solution directly
-    <braunr> it looks simple, it's clearly not
-    <desrt> but i did a bit of looking into it... it's a bit non-trivial after
-      all :)
-    <braunr> mach ipc is over complicated and error prone
-    <braunr> it leads to unefficient communication compared to other solutions
-      such as what l4 does
-    <desrt> ya -- i hear that this is a big part of the performance hit
-    <braunr> that's why i've started x15
-    <desrt> i was also doing some reading about how it's based on mapping
-      memory segments between processes
-    <braunr> first, it was a mach clone, but since i've come to know mach
-      better, it's now a "spiritual" mach successor .. :)
-    <desrt> these are two issues that we've been dealing with at another
-      level... in the design of kdbus
-    <braunr> ah kdbus :)
-    <desrt> this is something that started with my masters thesis a long time
-      ago...
-    <braunr> ah you too
-    <desrt> first thing we did is make the serialisation format so that all
-      messages are valid and therefore never need to be checked
-    <desrt> (old dbus format requires checks at every step on the way)
-    <braunr> looks interesting
-    <desrt> then of course we cut the daemon out
-    <desrt> but some other interesting things: security is super-simple... it's
-      based enirely on endpoints
-    <desrt> either you're allowed to send messages between two processes or
-      you're not
-    <desrt> there is no checking for message types, for example
-    <braunr> yes
-    <desrt> and the other thing: memory mapping is usually bad
-    <braunr> that's what i mean when i say mach ipc is over complicated
-    <braunr> it depends
-    <desrt> the kdbus guys did some performance testing and found out that if
-      the message is less than ~512k then the cost of invalidating the TLB in
-      order to change the memory mapping is higher than the cost of just
-      copying the data
-    <braunr> yes, we know that too
-    <braunr> that's why zero copy isn't the normal way of passing small amounts
-      of data over mach either
-    <desrt> nice
-    <desrt> i got the impression in some of my reading (wikipedia, honestly)
-      that memory mapping was being done all the time
-    <braunr> well
-    <braunr> no it's not
-    <braunr> memory mapping is unfortunately a small fraction of the
-      performance overhead
-    <desrt> that's good :)
-    <braunr> that being said
-    <braunr> memory mapping can be very useful
-    <braunr> for example, it's hard for us to comply with posix requirements of
-      being able to read/write at least 2G of data in a single call
-    <braunr> weird bugs occur beyond 512M iirc
-    <braunr> you do want memory mapping for that
-    <desrt> ya... for things of this size.... you don't want to copy that
-      through a socket :)
-    <braunr> monolithic kernels have it naturally, since the kernel is mapped
-      everywhere
-    <braunr> for microkernels, it's a little more complicated
-    <braunr> and the problem gets worse on smp
-    <braunr> again, that's why i preferred starting a new kernel instead of
-      reusing linux
diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn
deleted file mode 100644
index e7083557..00000000
--- a/open_issues/dde.mdwn
+++ /dev/null
@@ -1,661 +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_hurd open_issue_gnumach]]
-
-[[General Information|/dde]].
-
-Still waiting for interface finalization and proper integration.
-
-[[!toc]]
-
-See [[user-space_device_drivers]] for generic discussion related to user-space
-device drivers.
-
-
-# Disk Drivers
-
-Not yet supported.
-
-The plan is to use [[libstore_parted]] for accessing partitions.
-
-
-# Upstream Status
-
-
-## IRC, freenode, #hurd, 2012-02-08
-
-After the microkernel devroom at [[community/meetings/FOSDEM_2012]]:
-
-    <antrik> there was quite some talk about DDE. I learnt that there are newer
-      versions in Genode and in Minix (as opposed to the DROPS one we are
-      using)
-    <antrik> but apparently none of the guys involved is interested in creating
-      a proper upstream project with central repository and communication
-      channels :-(
-    <antrik> the original DDE creator was also there, but said he isn't working
-      on it anymore
-    <tschwinge> OK, and the other two projects basically have their own forks.
-    <tschwinge> Or are they actively cooperating?
-    <tschwinge> (If you know about it.)
-    <antrik> well, Genode is also part of the Dresden L4 group; but apart from
-      that, I'd rather call it a fork...
-    <antrik> hm... actually, I'm not sure anymore whether the guy I talked to
-      was from Genode or Nova...
-    <antrik> (both from the Dresdem L4 group)
-
-
-### IRC, freenode, #hurd, 2012-08-12
-
-    <antrik>
-      http://genode.org/documentation/release-notes/12.05#Re-approaching_the_Linux_device-driver_environment
-    <antrik> I wonder whether the very detailed explanation was prompted by our
-      DDE discussions at FOSDEM...
-    <pinotree> antrik: one could think about approaching them to develop the
-      common dde libs + dde_linux together
-    <antrik> pinotree: that's what I did at FOSDEM -- they weren't interested
-    <pinotree> antrik: this year's one? why weren't they?
-    <pinotree> maybe at that time dde was not integrated properly yet (netdde
-      is just few months "old")
-    <braunr> do you really consider it integrated properly ?
-    <pinotree> no, but a bit better than last year
-    <antrik> I don't see what our integration has to do with anything...
-    <antrik> they just prefer hacking thing ad-hoc than having some central
-      usptream
-    <pinotree> the helenos people?
-    <antrik> err... how did helenos come into the picture?...
-    <antrik> we are talking about genode
-    <pinotree> sorry, confused wrong microkernel OS
-    <antrik> actually, I don't remember exactly who said what; there were
-      people from genode there and from one or more other DDE projects... but
-      none of them seemed interested in a common DDE
-    <antrik> err... one or two other L4 projects
-
-
-## IRC, freenode, #hurd, 2012-02-19
-
-    <youpi> antrik: do we know exactly which DDE version Zheng Da took as a
-      base ?
-    <youpi> (so as to be able to merge new changes easily)
-    <antrik> youpi: not sure... but from what I gathered at FOSDEM, the version
-      he based on (from DROPS) is not really actively developed right now; if
-      we want to go for newer versions, we probably have to look at other
-      projects (like Genode or Nova or Minix)
-    <youpi> there's no central project for dde ?
-    <youpi> that sucks
-    <antrik> no... and nobody seemed interested in having one :-(
-    <youpi> pff
-    <antrik> which makes me seriously question the original decision to build
-      on DDE...
-    <braunr> ..
-    <antrik> if we have to basically maintain it ourselfs anyways, we could
-      just as well have gone with custom glue
-    <youpi> well, the advantage of DDE is that it already exists now
-    <antrik> on the positive side, one of the projcets (not sure which)
-      apparently have both USB and SATA working with some variant of DDE
-
-
-### IRC, freenode, #hurd, 2012-11-03
-
-    <mcsim> DrChaos: there is DDEUSB framework for L4. You could port it, if
-      you want. It uses Linux 2.6.26 usb subsystem.
-
-
-## IRC, freenode, #hurd, 2013-02-15
-
-After the microkernel devroom at [[community/meetings/FOSDEM_2013]].
-
-    <pinotree> youpi: speaking of dde, was there any will among other
-      microkernel os developers to eventually develop one single dde (with
-      every team handling the custom glue of the own kernel)?
-    <youpi> well, there is still upstream dde actually
-    <youpi> in dresden
-    <youpi> nothing was really decided or anything (it was a round table, not a
-      workgroup)
-    <youpi> but conversation converged into sharing the DDE maintenance, yes
-    <youpi> and dresden would be the logical central place
-    <youpi> pb is that they don't have the habit of being very open
-    <youpi> http://svn.tudos.org/repos/oc/tudos/trunk/l4/pkg/dde  has a recent
-      enough version
-    <youpi> which macsim confirmed having all the latest commits from the
-      internal repository
-    <pinotree> i see
-    <youpi> so it seems a viable solution on the medium term
-    <youpi> the long term might need a real visible open source project
-    <youpi> but we should probably still keep basing on dresden work
-    <youpi> (better take work being done anywhere)
-    <pinotree> well, if the upstream is not really open, microkernel teams
-      could just fork it and all work on it
-    <youpi> that's what I mean
-    <pinotree> should still be a win than everybody maintaining their own dde
-    <youpi> sure
-    <pinotree> ah yes, i was writing and i'm slow at it :)
-    <youpi> but at least we can try to work with dresden
-    <youpi> see how open they could become by just asking :)
-    <pinotree> right
-
-
-# IRC, OFTC, #debian-hurd, 2012-02-15
-
-    <pinotree> i have no idea how the dde system works
-    <youpi> gnumach patch to provide access to physical memory and interrupts
-    <youpi> then userland accesses i/o ports by hand to drive things
-    <youpi> but  that assumes that no kernel driver is interfering
-    <youpi> so one has to disable kernel drivers
-    <pinotree> how are dde drivers used? can they be loaded on their own
-      automatically, or you have to settrans yourself to setup a device?
-    <youpi> there's no autoloader for now
-    <youpi> we'd need a bus arbitrer that'd do autoprobing
-
-[[PCI_arbiter]].
-
-    <pinotree> i see
-    <pinotree> (you see i'm not really that low level, so pardon the flood of
-      posssibly-noobish questions ;) )
-    <youpi> I haven't set it up yet, but IIRC you need to specify which driver
-      to be used
-    <youpi> well, I mostly have the same questions actually :)
-    <youpi> I just have some guesswork here :)
-    <pinotree> i wonder whether the following could be feasible:
-    <youpi> I'm wondering how we'll manage to make it work in d-i
-    <pinotree> a) you create a package which would b-d on linux-source, build a
-      selection of (network only for now) drivers and install them in
-      /hurd/dde/
-    <youpi> probably through a choice at the boot menu
-    <youpi> I wouldn't dare depending on linux-source
-    <youpi> dde is usually not up-to-date
-    <pinotree> b) add a small utility over the actual fsys_settrans() which
-      would pick the driver from /hurd/dde/
-    <pinotree> ... so you could do `set-dde-driver b43 <device>` (or something
-      like that)
-    <youpi> we can provide something like b) yes
-    <youpi> although documenting the settrans should be fine enough ;)
-    <pinotree> the a) would help/ease with the fact that you need to compile on
-      your own the drivers
-    <pinotree> otherwise we would need to create a new linux-dde-sources-X.Y.Z
-      only with the sources of the drivers we want from linux X.Y.Z
-    <pinotree> (or hurd-dde-linux-X.Y.Z)
-    <CIA-4> samuel.thibault * raccdec3 gnumach/debian/ (changelog
-      patches/70_dde.patch patches/series): 
-    <CIA-4> Add DDE experimental support
-    <CIA-4> * debian/patches/70_dde.patch: Add experimental support for irq
-      passing and
-    <CIA-4> physical memory allocation for DDE. Also adds nonetdev boot
-      parameter to
-    <CIA-4> disable network device drivers.
-    <youpi> ok, boots fine with the additional nonetdev option
-    <youpi> now I need to try that dde hurd branch :)
-    <CIA-4> samuel.thibault * rf8b9426 gnumach/debian/patches/70_dde.patch: Add
-      experimental.defs to gnuamch-dev
-
-
-# IRC, freenode, #hurd, 2012-02-19
-
-    * youpi got dde almost working
-    <youpi> it's able to send packets, but apparently not receive them
-    <youpi> (e1000)
-    <youpi> ok, rtl8139 works
-    <youpi> antrik: the wiki instructions are correct
-    <youpi> with e1000 I haven't investigated
-    <antrik> (Archhurd guys also reported problems with e1000 IIRC... the one I
-      built a while back works fine though on my T40p with real e1000 NIC)
-    <antrik> maybe I should try with current versions... something might got
-      broken by later changes :-(
-    <youpi> at least testing could tell the changeset which breaks it
-    <youpi> Mmm, it's very odd
-    <youpi> with the debian package, pfinet's call to device_set_filter returns
-      D_INVALID_OPERATION
-    <youpi> and indeed devnode.c returns that
-    <youpi> ah but it's libmachdev which is supposed to answer here
-    <antrik> youpi: so, regarding the failing device_set_filter... I guess you
-      are using some wrong combination of gnumach and pfinet
-    <youpi> no it's actually that my pfinet was not using bpf
-    <youpi> I've now fixed it
-    <antrik> the DDE drivers rely on zhengda's modified pfinet, which uses
-      devnode, but also switched to using proper BPF filters. so you also need
-      his BPF additions/fixes in gnumach
-    <antrik> OK
-    <youpi> that's the latter
-    <youpi> I had already fixed the devnode part
-    <youpi> but hadn't seen that the filter was different
-    <antrik> err... did I say gnumach? that of course doesn't come into play
-      here
-    <antrik> so yes, you just need a pfinet using BPF
-    <youpi> libmachdev does ;)
-    <antrik> I'm just using pfinet from zhengda's DDE branch... I think devnode
-      and BPF are the only modifications
-    <youpi> there's also a libpcap modification in the incubator
-    <youpi> probably for tcpdump etc.
-    <antrik> libpcap is used by the modified pfinet to compile the filter rule
-    <youpi> why does pfinet need to compile the rule ?
-    <youpi> it's libbpf which is used in the dde driver
-    <antrik> it doesn't strictly need to... but I guess zhengda considered it
-      more elegant to put the source rule in pfinet on compile it live, rather
-      than the compiled blob
-    <antrik> I probably discussed this with him myself a few years back... but
-      my memory on this is rather hazy ;-)
-    <antrik> err... and compile it live
-    <youpi> ah, right, it's only used when asking pfinet to change its filter
-    <youpi> but it does not need it for the default filter
-    <youpi> which is hardcoded
-    <antrik> I see
-    <antrik> when would pfinet change its filter?
-    * youpi now completely converting his hurd box to debian packages with dde
-        support
-    <youpi> on SIOCSIFADDR apparently
-    <youpi> to set "arp or (ip host %s)",
-    <antrik> well, that sounds like the default filter...
-    <youpi> the default filter does not choose an IP
-    <antrik> oh, right... pfinet has to readjust the filter when setting the IP
-    <youpi> arg we lack support for kernel options for gnumach in update-grub
-    <antrik> again, I have a vague recollection of discussing this
-    * youpi crosses fingers
-    <youpi> yay, works
-    <antrik> so we *do* need libpcap in pfinet to set proper rules... though I
-      guess it can also work with a static catchall rule (like it did before
-      zhengda's changes), only less efficient
-    <youpi> well in the past we were already catching everything anyway, so at
-      least it's not a regression :)
-    <antrik> right
-
-
-# [[PCI_Arbiter]]
-
-## IRC, freenode, #hurd, 2012-02-21
-
-    <youpi> since all drivers need is interrupts, io ports and iomem
-    <youpi> the latter was already available through /dev/mem
-    <youpi> io ports through the i386 rpcs
-    <youpi> the changes provide both interrupts, and physical-contiguous
-      allocation
-    <youpi> it should be way enough
-    <braunr> youpi: ok
-    <braunr> youpi: thanks for the details :)
-    <antrik> braunr: this was mentioned in the context of the interrupt
-      forwarding interface... the original one implemented by zhengda isn't
-      suitable for a PCI server; but the ones proposed by youpi and tschwinge
-      would work
-    <antrik> same for the physical memory interface: the current implementation
-      doesn't allow delegation; but I already said that it's wrong
-
-
-# IRC, freenode, #hurd, 2012-02-20
-
-    <youpi> I was a bit wary of including the ton of dde headers in hurd-dev
-    <youpi> maybe adding another package for that
-    <youpi> but that would have delayed introducing the dde binaries
-    <youpi> probably we can do that for next upload
-    <pinotree> i can try to work on it, if is feasible (ie if the dde drivers
-      can currently be built from outside the hurd source tree)
-    <youpi> it should be, it's a matter of pointing its makefile to a place
-      where the make scripts and include headers are
-    <youpi> (and the libraries)
-    <pinotree> ok
-    <antrik> youpi: you mean DDEKit headers?
-    <antrik> pinotree: actually it doesn't matter where the dde-ified Linux
-      drivers are built -- libdde_linux26 and the actual drivers use a
-      completetly different build system anyways
-    <antrik> in fact we concluded at some point that they should live in a
-      separate repository -- but that change never happened
-    <antrik> only the base stuff (ddekit, libmachdev etc.) belong in the Hurd
-      source tree
-    <youpi> antrik: yes
-    <youpi> antrik: err, not really completely different
-    <youpi> the actual drivers' Makefile include the libdde_linux26 mk files
-    <youpi> the build itself is separate, though
-    <antrik> youpi: yes, I mean both libdde_linux26 and the drivers use a build
-      system that is completely distinct from the Hurd one
-    <youpi> ah, yes
-    <youpi> libdde_linux26 should however be shipped in the system
-    <antrik> ideally libdde_linux26 and all the drivers should be built in one
-      go I'd say...
-    <youpi> it should be easily feasible to also have a separate driver too
-    <youpi> e.g. to quickly try a 2.6 driver
-    <antrik> youpi: I'm not sure about that. it's not even dynamically linked
-      IIRC?...
-    <youpi> with scripts to build it
-    <youpi> it's not
-    <youpi> but that doesn't mean it can't be separate
-    <youpi> .a files are usually shipped in -dev packages
-    <antrik> youpi: ideally we should try to come with a build system that
-      reuses the original Linux makefile snippets to build all the drivers
-      automatically without any manual per-driver work
-    <youpi> there's usually no modification of the drivers themselves?
-    <youpi> but yeah
-    <youpi> "ideally", when somebody takes the time to do it
-    <antrik> unfortunately, it's necessary to include one particular
-      Hurd/DDE-specific header file in each driver :-(
-    <youpi> can't it be done through gcc's -include option?
-    <antrik> zhengda didn't find a way to avoid this... though I still hope
-      that it must be possible somehow
-    <antrik> I think the problem is that it has to be included *after* the
-      other Linux headers. don't remember the details though
-    <youpi> uh
-    <youpi> well, a good script can add a  line after the last occurrence of
-      #include
-    <antrik> yeah... rather hacky, but might work
-    <youpi> even with a bit of grep, tail, cut, and sed it should work :)
-    <antrik> note that this is Hurd-specific; the L4 guys didn't need that
-    <youpi> what is it?
-    <antrik> don't remember off-hand
-
-
-# IRC, freenode, #hurd, 2012-02-22
-
-    <youpi> antrik: AIUI, it should be possible to include all network drivers
-      in just one binary?
-    <youpi> that'd permit to use it in d-i
-    <youpi> and completely replace the mach drivers
-    <youpi> we just need to make sure to include at least what the mach drivers
-      cover
-    <youpi> (all DDE network drivers, I mean)
-    <youpi> of course that doesn't hinder from people to carefully separate
-      drivers in several binaries if they wish
-    <youpi> antrik: it does link at least, I'll give a try later
-    <youpi> yes it works!
-    <youpi> that looks like a plan
-    <youpi> throw all network drivers in a /hurd/dde_net
-    <youpi> settrans it on /dev/dde_net, and settrans devnode on /dev/eth[0-9]
-    <youpi> I'm also uploading a version of hurd which includes headers &
-      libraries, so you just need a make in dde_{e100,e1000,etc,net}
-    <youpi> (uploading it with the dde driver itself :) )
-    <youpi> btw, a nice thing is that we don't really care that all drivers are
-      stuffed into a single binary, since it's a normal process only the useful
-      pages are mapped and actually take memory :)
-    <Tekk_> is that really a nice thing though? compared to other systems I
-      mean
-    <Tekk_> I know on linux it only loads the modules I need, for example. It's
-      definitely a step up for hurd though :D
-    <youpi> that's actually precisely what I mean
-    <youpi> you don't need to load only the modules you need
-    <youpi> you just load them all
-    <youpi> and paging eliminates automatically what's not useful
-    <youpi> even parts of the driver that your device will not need
-    <Tekk_> ooh
-    <Tekk_> awesome
-    <youpi> (actually, it's not even loaded, but the pci tables of the drivers
-      are loaded, then paged out)
-
-
-# IRC, freenode, #hurd, 2012-02-24
-
-    <youpi> antrik_: about the #include <ddekit/timer.h>, I see the issue, it's
-      about jiffies
-    <youpi> it wouldn't be a very good thing to have a jiffies variable which
-      we'd have to update 100times per second
-    <youpi> so ZhengDa preferred to make jiffies a macro which calls a function
-      which reads the mapped time
-
-[[Mapped-time_interface|microkernel/mach/gnumach/interface/device/time]].
-
-    <youpi> however, that break any use of the work "jiffies", e.g. structure
-      members & such
-    <youpi> actually it's not only after headers that the #include has to be
-      done, but after any code what uses the word "jiffies" for something else
-      than the variable
-    <youpi> pb is: it has to be done *before* any code that uses the word
-      "jiffies" for the variable, e.g. inline functions in headers
-    <youpi> in l4dde, there's already the jiffies variable so it's not a
-      problem
-
-
-# IRC, OFTC, #debian-hurd, 2012-02-27
-
-    <tschwinge> I plan to do some light performance testing w.r.t. DDE
-      Ethernet.  That is DDE vs. Mach, etc.
-    <youpi> that'd be good, indeed
-    <youpi> I'm getting 4MiB/s with dde
-    <youpi> I don't remember with mach
-    <tschwinge> Yes.  It just shouldn't regress too much.
-    <tschwinge> Aha, OK.
-
-
-## IRC, freenode, #hurd, 2012-02-27
-
-    <youpi> tschwinge: nttcp tells me ~80Mbps for mach-rtl8139, ~72Mbps for
-      dde-rtl8139, ~72Mbps for dde-e1000
-    <youpi> civodul: ↑ btw
-    <ArneBab> youpi: so the dde network device is not much slower than the
-      kernel-one?
-    <civodul> youpi: yes, looks good
-    <ArneBab> rather almost the same speed
-    <youpi> apparently
-    <ArneBab> that’s quite a deal. 
-    <ArneBab> what speed should it have as maximum?
-    <ArneBab> (means: does the mach version get out all that’s possible?)
-    <ArneBab> differently put: What speed would GNU/Linux get?
-    <youpi> I'm checking that right now
-    <ArneBab> cool!
-    <ArneBab> we need those numbers for the moth after the next
-    <youpi> Mmm, I'm not sure you really want the linux number :)
-    <youpi> 1.6Gbps :)
-    <ArneBab> oh…
-    <youpi> let me check with udp rather than tcp
-    <ArneBab> so the Hurd is a “tiny bit” worse at using the network… 
-    <youpi> it might simply be an issue with tcp tuning in pfinet
-    <ArneBab> hm, yes
-    <ArneBab> tcp is not that cheap
-    <ArneBab> and has some pretty advanced stuff for getting to high speeds
-    <youpi> well, I'm not thinking about being cheap
-    <youpi> but using more recent tuning
-    <youpi> that does not believe only 1Mbps network cards exist :)
-    <ArneBab> like adaptive windows and such?
-    <ArneBab> :)
-    <youpi> yes
-    * ArneBab remembers that TCP was invented when the connections went over
-        phone lines - by audio :)
-    <youpi> yep
-    <ArneBab> what’s the system load while doing the test?
-    <youpi> yes, udp seems not so bad
-    <ArneBab> ah, cool!
-    <youpi> it's very variable (300-3000Mbps), but like on linux
-    <ArneBab> that pushing it into user space has so low cost is pretty nice.
-    * ArneBab thinks that that’s a point where Hurd pays off
-    <youpi> that's actually what AST said to fosdem
-    <youpi> he doesn't care about putting an RPC for each and every port i/o
-    <youpi> because hardware is slow anyway
-    <ArneBab> jupp
-    <ArneBab> but it is important to see that in real life
-
-
-# IRC, freenode, #hurd, 2012-04-01
-
-    <youpi> antrik: I wonder whether you could actually not route the IRQs to a
-      non-zero ring, AIUI you can in the x86 IDT table
-    <antrik> youpi: you mean having a userspace server for each (non-timer)
-      interrupt?
-    <antrik> youpi: how would a userspace IRQ handler interact with the
-      scheduler?
-    <youpi> antrik: it doesn't necessarily have to
-    <youpi> provided that it's trusted
-    <antrik> youpi: how would you do CPU time accounting if there is no
-      interaction with the scheduler?...
-    <youpi> antrik: you don't necessarily want to care about it
-    <antrik> youpi: well, that would mean that all drivers handling interrupts
-      would have to be trusted to not use more than a very small part of CPU
-      time...
-    <youpi> yes
-    <youpi> which is usually needed for interrupt handlers anyway
-    <antrik> youpi: nah, the bottom handler only has to do very basic stuff;
-      afterwards, we can pass off to "normal" driver processes, scheduled just
-      like other processes... but that requires some interaction between the
-      IRQ handler and the scheduler I think
-    <youpi> the IRQ handler can wake up a thread, yes
-    <youpi> no need for anything special there
-    <antrik> so the userspace IRQ server would just decide what process to wake
-      up, and then call the scheduler to do a normal task switch? I guess
-      that's possible; but I'm not sure it would buy much...
-    <youpi> it would permit userland to quickly react to the IRQ
-    <youpi> such as acknowledge it to the hardware etc.
-    <antrik> yeah, but my point is that I don't see much benefit in having this
-      part of the code isolated in a userspace process... it has to be trusted
-      anyways, and it's pretty trivial too
-    <youpi> I never said it was a good idea
-
-
-# IRC, freenode, #hurd, 2012-04-06
-
-    <braunr> oh i forgot about my work on pcap
-    <braunr> is devnode (or devopen or whatever) in the upstream repository now
-      ?
-    <antrik> can't say for sure, but I'd be surprised... don't remember seeing
-      any movement in that regard :-(
-    <braunr> wasn't it needed for dde ?
-    <antrik> hm... good point
-
-
-## IRC, freenode, #hurd, 2013-09-20
-
-    <braunr> i should take some time to integrate my pcap changes into the
-      libpcap debian package at least
-    <pinotree> braunr: if upstream is active, i'd say to go there directly
-    <braunr> the problem with that approach is that netdde is still not part of
-      our upstream code
-    <pinotree> don't understand the relation
-    <braunr> i don't want to send the pcap guys code for an interface that is
-      still not considered upstream ...
-
-
-# IRC, freenode, #hurd, 2012-08-14
-
-    <braunr> it's amazing how much code just gets reimplemented needlessly ...
-    <braunr> libddekit has its own mutex, condition, semaphore etc.. objects
-    <braunr> with the *exact* same comment about the dequeueing-on-timeout
-      problem found in libpthread
-    <braunr> *sigh*
-
-
-## IRC, freenode, #hurd, 2012-08-18
-
-    <braunr> hum, leaks and potential deadlocks in libddekit/thread.c :/
-
-
-## IRC, freenode, #hurd, 2012-08-18
-
-    <braunr> nice, dde relies on a race to start ..
-
-
-## IRC, freenode, #hurd, 2012-08-21
-
-In context of [[libpthread]].
-
-    <braunr> hm, i thought my pthreads patches introduced a deadlock, but
-      actually this one is present in the current upstream/debian code :/
-    <braunr> (the deadlock occurs when receiving data fast with sftp)
-    <braunr> either in netdde or pfinet
-
-
-## IRC, freenode, #hurd, 2013-02-28
-
-    <braunr> (which needs the same kinds of fixes that libpthread got)
-    <braunr> actually i'm not sure why he didn't simply reuse the pthread
-      functions :/
-    <youpi> which kind of fixes?
-    <youpi> cancellation?
-    <braunr> timeouts
-    <braunr> cancellation too but that's less an issue
-    <youpi> I'm not sure it really needs timeout work
-    <youpi> on what RPC?
-    <youpi> pfinet is just using the mach interface
-    <braunr> i don't know but it clearly copies some of the previous pthread
-      code from pthread_cond_timedwait
-    <braunr> see libddekit/thread.c:_sem_timedwait_internal
-    <youpi> I recognize the comment indeed :)
-    <youpi> I guess he thought he might need some particular semantic that
-      libpthread may not provide
-    <braunr> also, now that i think about it, he couldn't have used libpthread,
-      could he ?
-    <braunr> and there was no condition_timedwait in cthreads
-    <braunr> there is a deadlock in netdde
-    <braunr> it occurs sometimes, at high network speeds
-    <braunr> (well high, 4 MiB/s or more)
-
-
-## IRC, freenode, #hurd, 2013-11-20
-
-    <braunr> for example, netdde needs more reviewing and polishing
-    <braunr> it is known to deadlock sometimes
-    <teythoon> what deadlocks ?
-    <braunr> i'm not sure
-    <teythoon> ah, netdde
-    <teythoon> right
-    <braunr> yes
-    <teythoon> I'm seeing that to on one of my vms
-    <teythoon> nasty one
-    <braunr> i know something is wrong with the condition_wait_timeout function
-      for example
-    <teythoon> breaks sysvinit shutdown
-    <braunr> because it was taken without modification from libpthread
-    <braunr> it might be that, or something else
-    <teythoon> well, dhclient hangs releasing the lease
-    <braunr> that's still on my todo list
-    <teythoon> so I'm pretty sure it's related
-    <braunr> hm
-    <braunr> maybe
-    <braunr> :/
-
-
-## IRC, freenode, #hurd, 2014-02-11
-
-    <braunr> teythoon: looks like a netdde/pfinet freeze/deadlock
-    <braunr> yes a netdde deadlock
-    <braunr> i really have to fix that too one day :(
-    <teythoon> hehe :)
-    <braunr> the netdde locking privimites are copies of the "old" pthread
-      ones, instead of reusing pthread
-    <braunr> primitives*
-
-
-## IRC, freenode, #hurd, 2014-03-08
-
-    <gg0> what to do if network freezes?
-    <teythoon> gg0: depends on what caused the freeze
-    <teythoon> gg0: you could try to kill the netdde process
-    <gg0> it's just apt-get'ing, download phase
-    <braunr> yess kill netdde
-    <braunr> there are known deadlocks in netdde
-
-
-# IRC, freenode, #hurd, 2012-08-18
-
-    <braunr> hm looks like if netdde crashes, the kernel doesn't handle it
-      cleanly, and we can't attach another netdde instance
-
-[[!message-id "877gu8klq3.fsf@kepler.schwinge.homeip.net"]]
-
-
-# DDE for Filesystems
-
-## IRC, freenode, #hurd, 2012-10-07
-
-    * pinotree wonders whether the dde layer could aldo theorically support
-        also file systems
-    <antrik> pinotree: yeah, I also brought up the idea of creating a DDE
-      extension or DDE-like wrapper for Linux filesystems a while back... don't
-      know enough about it though to decide whether it's doable
-    <antrik> OTOH, I'm not sure it would be worthwhile. we still should
-      probably have a native (not GPLv2-only) implementation for the main FS at
-      least; so the wrapper would only be for accessing external
-      partitions/media...
-
-
-## IRC, freenode, #hurd, 2013-12-03
-
-    <gg0> how about porting linux block device layer via dde as mcsim wanted to
-      do? then all linux filesystems could be brought in, right?
-    <braunr> gg0: that should be done, but we need to correctly deal with
-      multiple pci devices in userspace and arbitration
-    <kilobug> wouldn't adding support to passive translator into Linux
-      filesystems be quite some work ? IIRC ext2fs needs a special "owner =
-      hurd" mode to handle them
-
-
-# [[virtio]]
diff --git a/open_issues/debian_cross_toolchain.mdwn b/open_issues/debian_cross_toolchain.mdwn
deleted file mode 100644
index e0665466..00000000
--- a/open_issues/debian_cross_toolchain.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!meta copyright="Copyright © 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_hurd]]
-
-Have a look at the Debian *Cross Toolchain* project,
-<https://alioth.debian.org/projects/crosstoolchain/>,
-<http://wiki.debian.org/ToolChain/Cross>.
diff --git a/open_issues/debootstrap.mdwn b/open_issues/debootstrap.mdwn
deleted file mode 100644
index 8e6c4900..00000000
--- a/open_issues/debootstrap.mdwn
+++ /dev/null
@@ -1,24 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-\#hurd, freenode, 2010
-
-    <azeem_> you know, you would really help the Hurd if you tried debootstrap instead
-    <tschwinge> Oh?  Does that have everying in place by now?
-    <azeem_> applying the patch in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498731#25
-    <azeem_> they are waiting for feedbacl
-    <azeem_> feedback*
-
-\#hurd, freenode, June (?) 2010
-
-    <azeem_> jd823592: if you want to use debootstrap, you should apply a patch
-    <azeem_> and test
-    <azeem_> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=25;filename=debootstrap_hurd.patch;att=1;bug=498731
-    <azeem_> we desperately need somebody to test the patch
diff --git a/open_issues/debugging.mdwn b/open_issues/debugging.mdwn
deleted file mode 100644
index 107acbf6..00000000
--- a/open_issues/debugging.mdwn
+++ /dev/null
@@ -1,56 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 2013 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]]."]]"""]]
-
-
-# Existing
-
-We have debugging infrastructure.  For example:
-
-  * [[GDB]]
-
-  * [[GNU Mach debugging|microkernel/mach/gnumach/debugging]]
-
-  * [[GNU Hurd debugging|hurd/debugging]], including
-    [[hurd/debugging/rpctrace]], and more.
-
-
-# To Do
-
-  * [[glibc]]'s sotruss
-
-  * [[ltrace]]
-
-  * [[latrace]]
-
-  * [[profiling]]
-
-  * *Checkpoint/restart allows the state of a set of processes to be saved to
-    persistent storage, then restarted at some future time* -- quoting from
-    Jonathan Corbet's [2010 Linux Kernel Summit
-    report](http://lwn.net/Articles/412749/).
-
-    This is surely a very useful facility to have for reproducing failures, for
-    example.  But on the other hand it's questionable how it can help with
-    debugging failures in [[GNU Hurd server|hurd/translator]]s' interactions,
-    as their state is typically spread between several processes.
-
-    Continues: <http://lwn.net/Articles/414264/>, which introduces
-    <http://dmtcp.sourceforge.net/>.
-
-  * [[crash_server}}, [[GDB_gcore]],
-    <http://code.google.com/p/google-coredumper/>
-
-  * [[community/gsoc/project_ideas/libdiskfs_locking]]
-
-  * <http://lwn.net/Articles/415728/>, or <http://lwn.net/Articles/415471/> --
-    just two examples; there's a lot of such stuff for Linux.
-
-  * [[debugging_gnumach_startup_QEMU_GDB]]
diff --git a/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn
deleted file mode 100644
index 68a04bfb..00000000
--- a/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn
+++ /dev/null
@@ -1,165 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 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]]."]]"""]]
-
-[[!meta title="Debugging GNU Mach's startup in QEMU with GDB"]]
-
-[[!tag open_issue_gdb open_issue_gnumach]]
-
-[[!toc]]
-
-
-# Memory Map
-
-## IRC, freenode, #hurd, 2010-06 (?)
-
-    <jkoenig> is there a way to get gdb to map addresses as required when
-      debugging mach with qemu ?
-    <jkoenig> I can examine the data if I manually map the addresses th
-      0xc0000000 but maybe there's an easier way...
-    <youpi> jkoenig: I haven't found a way
-    <youpi> I'm mostly using the internal kdb
-
-
-## IRC, freenode, #hurd, 2011-07-14
-
-    <mcsim> Hello. I have problem with debugging gnumach. I set 2 brakepoints
-      in file i386/i386at/model_dep.c on functions gdt_init and idt_init. Then
-      I start qemu with patched gnumach kernel and stop at gdt_init. When I
-      enter command "continue" in gdb, qemu hangs. But when I go step by step,
-      using command "next", I freely reach idt_init. What can cause this
-      problem?
-    <braunr> hm
-    <braunr> not sure
-    <braunr> let me try
-    <braunr> mcsim: works for me :/
-    <mcsim> it works without my patch, but with it qemu hangs
-    <braunr> oh, i thought it worked when not using continue
-    <mcsim> with my patch I can reach idt_init only using next
-    <mcsim> and without all works fine
-    <braunr> mcsim: are you sure you correctly built it with debugging symbols
-      ?
-    <mcsim> I've written in /etc/dpkg/buildflags.conf SET CFLAGS -g3 -O0
-    <braunr> hm
-    <braunr> i have internal kvm errors actually
-    <braunr> mcsim: do you use kvm ?
-    <braunr> mcsim: and why break on those functions ?
-    <braunr> i'm not sure the address space is already fine at this point
-    <mcsim> no. I don't have hardware virtualisation support.
-    <braunr> hm actually, you won't be able to use gdb
-    <braunr> i just remembered how gnumach is linked and mapped :/
-    <braunr> the addresses in the elf image are low addresses, matching the
-      image as it is loaded by the boot loader
-    <mcsim> I was wondering why qemu hangs.
-    <braunr> then the kernel uses segmentation to map itself at 2 (or 3
-      previously) GiB
-    <braunr> well, if the addresses are wrong, your breakpoints are wrong
-    <braunr> i even wonder how it can work when stepping
-    <braunr> i don't have the issue with x15 because of its linker script
-    <mcsim> Are there any ways of such debugging without qemu?
-    <braunr> i don't think so
-    <braunr> as antrik told you, the in kernel debugger needs many services
-      running before being usable
-    <braunr> you'll have to use printf, and there may be steps during bootstrap
-      when even that isn't available
-    <mcsim> So I need computer with hardware virtualisation?
-    <braunr> well, of course stepping works, since the breakpoints are relative
-    <braunr> no
-    <braunr> kvm has nothing to do with the problem
-    <braunr> it's just that the problem appears differently with kvm enabled
-    <mcsim> ok. thank you.
-    <braunr> good luck
-    <antrik> braunr: would it be hard to "fix" gnumach to avoid the
-      segmentation magic?...
-    <braunr> antrik: because of the linux drivers, it may
-    <antrik> or alternatively, implement something in GDB to deal with that?...
-    <braunr> antrik: i didn't study that part enough to know for sure
-    <antrik> uhm... why would the Linux drivers depend on that? does Linux also
-      do such magic?...
-    <braunr> well it should simply be a matter of shifting the address by a
-      fixed offset
-    <braunr> antrik: linux drivers rely on physical memory being allocated
-      through kmalloc
-    <braunr> so there must be a direct mapping between virtual kernel memory
-      and physical memory
-    <braunr> they don't specifically need that segmentation settings
-    <braunr> so if you remove the offset implemented through segmentation, you
-      have to replace it with page mapping
-    <braunr> and i don't know how much needs to be done for that
-    <braunr> you also need to link the kernel differently
-    <antrik> hm, OK
-    <antrik> so adding GDB support for the offset would probably be easier...
-    <braunr> yes
-    <braunr> but using the offset must only be done once segmentation is set up
-    <braunr> so you must break after gdt_init
-    <braunr> not on it
-    <braunr> mcsim: why do you break on these functions btw ?
-    <mcsim> I just wanted to find out why qemu hangs
-    <braunr> yes but why those ?
-    <mcsim> I found out that before gdt_init all workes fine, but after qemu
-      hangs. So idt_init is just the next function
-    <braunr> ok
-    <braunr> and does your patch change something to how segmentation is
-      initialized ?
-    <mcsim> now
-    <mcsim> no
-    <braunr> try to build it with the regular cflags
-    <braunr> i don't know if gnumach can work with -O0
-    <mcsim> I've tried. But all the same
-    <mcsim> Regular are -g -O2
-    <braunr> can you make your patch available ?
-    <mcsim> yes
-    <mcsim> it is available in gnumach repository at savannah 
-    <mcsim> tree mplaneta/libbraunr/master
-    <antrik> well, if the segmentation stuff is the thing GDB has problems
-      with, I don't see how it can work without your patch...
-    <braunr> without ?
-    <antrik> well, the patch shouldn't affect the segmentation... so I don't
-      see how it can make a difference
-    <braunr> he said qemu hanged
-    <braunr> so let's not introduce gdb yet
-    <braunr> qemu can hang for other reasons
-    <antrik> oh, right, without GDB...
-    <antrik> though if that's what he meant, his statement was very misleading
-      at least
-
-
-# <a name="multiboot">Multiboot</a>
-
-See also [[hurd/running/qemu#multiboot]].
-
-
-## IRC, freenode, #hurd, 2014-02-24
-
-    <congzhang> hi, will grub load mach kernel to fix address? and which
-      address?
-    <congzhang> I want to use qemu gdb support to debug mach
-    <congzhang> need add-symble-file to right address
-    <youpi> congzhang: see objdump gnumach
-    <youpi> grub simply follows what's provided by the ELF format of the ELF
-      file
-    <nalaginrut> I think it's default value of _start in ELF, right?
-    <nalaginrut> hmm...the actual entry point should plus the size of
-      multi_boot header, at least 0xc...
-    <congzhang> youpi: I try that, but not works
-    <congzhang> I start qemu with -s
-    <congzhang> the /bin/console was very easy to cause black death, and I want
-      to use gdb to check whether the mach is death
-    <congzhang> I will try again later
-    <congzhang> Anyone know some tutorial to debug mach with qemu?
-    <nalaginrut> for better debug, I suggest bochs
-    <nalaginrut> although it's slower
-    <congzhang> nalaginrut: maybe it's my problem, I did not do the right thing
-    <congzhang> qemu with kvm was great.
-    <nalaginrut> qemu with kvm is cool to run, but not so cool for debug kernel
-    <nalaginrut> anyway, it's personal taste
-    <nalaginrut> you may use gdb for that
-    <nalaginrut> for bochs, you don't have to use external debugger
-    <congzhang> thanks for explain
diff --git a/open_issues/default_pager.mdwn b/open_issues/default_pager.mdwn
deleted file mode 100644
index 38c9a2be..00000000
--- a/open_issues/default_pager.mdwn
+++ /dev/null
@@ -1,44 +0,0 @@
-[[!meta copyright="Copyright © 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_gnumach]]
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2011-08-31
-
-    <antrik> braunr: do you have any idea what could cause the paging errors
-      long before swap is exhausted?
-    <braunr> antrik: not really, but i know every project based on the mach vm
-      have rewritten their swap pager
-    <antrik> (and also I/O performance steadily dropping before that point is
-      reached?)
-
-[[performance/degradation]], [[ext2fs_page_cache_swapping_leak]].
-
-    <antrik> hm
-    <braunr> there could too many things
-    <antrik> perhaps we could "borrow" from one of them? :-)
-    <braunr> map entry fragmentation for example
-    <braunr> the freebsd one is the only possible candidate
-    <braunr> uvm is too different
-    <braunr> dragonflybsd maybe, but it's very close to freebsd
-    <braunr> i didn't look at darwin/xnu
-
-
-# [[trust_the_behavior_of_translators]]
-
-
-# IRC, freenode, #hurd, 2013-10-30
-
-    <braunr> it also seems that the kernel has trouble resuming processes that
-      have been swapped out
diff --git a/open_issues/dev_zero_size.mdwn b/open_issues/dev_zero_size.mdwn
deleted file mode 100644
index 20c5147e..00000000
--- a/open_issues/dev_zero_size.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-[[!meta copyright="Copyright © 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_hurd]]
-
-IRC, freenode, #hurd, 2011-10-18:
-
-    <pinotree> i guess it is not normal for /dev/zero have a size of
-      (size_t)-1, no?
-    <pinotree> (it isn't (size_t)-1, but (long long)-1)
-
-2011-10-19:
-
-    <pinotree> see the size you get with `stat /dev/zero`
diff --git a/open_issues/device_drivers_and_io_systems.mdwn b/open_issues/device_drivers_and_io_systems.mdwn
deleted file mode 100644
index 085a737a..00000000
--- a/open_issues/device_drivers_and_io_systems.mdwn
+++ /dev/null
@@ -1,100 +0,0 @@
-[[!meta copyright="Copyright © 2009, 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_gnumach open_issue_hurd]]
-
-This is a collection of resources concerning *device drivers* and *I/O systems*
-in general.
-
-Also see [[user-space device drivers]].
-[[community/gsoc/project ideas/driver glue code]].
-
-[[!toc levels=2]]
-
-
-# Documentation
-
-  * [An I/O System for Mach
-    3.0](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.56.3210),
-    1991, Alessandro Forin, David Golub, Brian Bershad
-
-  * [Linux Device Driver Emulation in
-    Mach](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.7252),
-    1996, Shantanu Goel, Dan Duchamp
-
-  * [Eliminating receive livelock in an interrupt-driven
-    kernel](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.127.8257),
-    1997, Jeffrey Mogul, Dec Western, Jeffrey C. Mogul, K. K. Ramakrishnan
-
-  * [IO-Lite: A Unified I/O Buffering and Caching
-    System](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.4224),
-    1997, Vivek S. Pai, Peter Druschel, Willy Zwaenepoel
-
-  * [The Flux OSKit: A substrate for kernel and language
-    research](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.118.534),
-    1997, Bryan Ford, Godmar Back, Greg Benson, Jay Lepreau, Albert Lin, Olin
-    Shivers
-
-  * [Reuse Linux Device Drivers in Embedded
-    Systems](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.26.6951),
-    1998, Chi-wei Yang, Paul C. H. Lee, Ruei-Chuan Chang
-
-  * [THINK: A Software Framework for Component-based Operating System
-    Kernels](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.133.9239),
-    2002, Jean-Philippe Fassino, Jean-Bernard Stefani, Julia Lawall, Gilles
-    Muller
-
-  * [An I/O Architecture for Microkernel-Based Operating
-    Systems](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.5.4337),
-    2003, Hermann Haertig, Jork Loeser, Jork Löser, Frank Mehnert, Lars
-    Reuther, Martin Pohlack, Alexander Warg
-
-  * [High-Speed I/O: The Operating System as a Signalling
-    Mechanism](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.9.6991),
-    2003, Matthew Burnside, Angelos D. Keromytis
-
-  * [Unmodified device driver reuse and improved system dependability via
-    virtual
-    machines](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.108.5317),
-    2004, Joshua Levasseur, Volkmar Uhlig, Jan Stoess, Stefan Götz
-
-
-# External Projects
-
-  * [[/DDE]]
-
-  * [Building Linux Device Drivers on
-    FreeBSD](http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html)
-
-  * [Project UDI](http://www.projectudi.org/), a multi-company effort to define
-    a Uniform Driver Interface
-
-      * [The Free Software Movement and
-        UDI](http://www.gnu.org/philosophy/udi.html)
-
-  * [OSKit](http://www.cs.utah.edu/flux/oskit/)
-
-      * [Unofficial OSKit source](http://www.nongnu.org/oskit/) on Savannah
-
-  * [[microkernel/Mach]]-like
-
-    It might be possible to integrate these systems' device drivers, as they're
-    expected to mostly be using the same interfaces as the current in-kernel
-    Mach drivers are.
-
-      * OSF Mach
-
-      * Darwin
-
-  * IRC, freenode, #hurd, 2013-08-26
-
-        < stargater> in haiku is a layer wraper for bsd driver 
-        < stargater>
-          https://www.haiku-os.org/news/2007-05-08/haiku_getting_a_freebsd_network_driver_compatibility_layer
diff --git a/open_issues/dir-lookup_authority.mdwn b/open_issues/dir-lookup_authority.mdwn
deleted file mode 100644
index 64866eb5..00000000
--- a/open_issues/dir-lookup_authority.mdwn
+++ /dev/null
@@ -1,68 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_hurd]]
-
-IRC, unknown channel, unknown date.
-
-    <cfhammar> I have discovered a bug in the dir-lookup protocol though
-    <cfhammar> Currently, I'm investigating the bug a bit further
-    <cfhammar> when doing dir-lookups with several path components, the look-up is done with the authority of the user who opened the directory, as opposed to the user doing the lookup
-    <cfhammar> e.g, consider foo/bar/baz, where bar can only be used by its owner and foo and baz are world readable
-    <cfhammar> if foo is opened, then transferred to another user, he can open baz, which he shouldn't be able to
-    <cfhammar> this is possible where foo/bar/baz is within a single translator, and the lookup is done in a single dir-lookup
-    <antrik> cfhammar: I'm not sure this is a bug
-    <cfhammar> I have a test case that triggers the bug, and another that doesn't which currently confuses me
-    <antrik> cfhammar: it's probably not very usual to pass around open directory ports; but if somebody does it, it's probably actually desired that it keeps the authority
-    <antrik> it's kinda consistent with passing normal FDs
-    <cfhammar> antrik: it should only allow accesses to entries not sub-entries
-    <cfhammar> antrik: it isn't allowed in Linux atleast, and I'm guessing it's mandated by posix
-    <cfhammar> also note that a more common scenario is a process that opens a directory and then drops authority
-    <cfhammar> probably more common, that is
-    <antrik> cfhammar: I'm not really familiar with directory access functions... I wasn't even aware that it's possible to pass around directory FDs
-    <antrik> but if it is, it would indeed be good to know what POSIX says about this
-    <antrik> cfhammar: I don't see how this is related?...
-    <cfhammar> antrik: after the process has dropped authority it can still make lookups in directories that it should no longer be able to
-    <antrik> cfhammar: interesting point...
-    <antrik> cfhammar: do you think this is fixable?
-    <cfhammar> antrik: Not without (defacto) changing the interface
-    <cfhammar> e.g only looking up a singe path component at a time
-    <cfhammar> or doing the auth check lazily on io_reauthenticate
-    <antrik> cfhammar: yeah, obviously it's not possible without an API change. I just wonder whether it's possible without throwing the current auth/lookup mechanism overboard alltogether...
-    <cfhammar> antrik: both my solutions are only minor changes to the API, but fairly major in the sense that we need to change all callers :-(
-    <cfhammar> diskfs_S_dir_lookup is a very large function, for example
-    <antrik> cfhammar: OK
-    <antrik> cfhammar: I wonder whether there is a possible transition path without breaking all existing installations...
-    <cfhammar> we could provide a new RPC while supporting the old one
-    <cfhammar> note that changing fs.defs only affects glibc and the Hurd, normal apps should be fine
-    <antrik> cfhammar: have you posted your findings to the ML yet?
-    <cfhammar> No, I'm still investigating why my second test-case doesn't trigger the bug
-    <cfhammar> Intrestingly it's the one using all POSIX functions...
-    <cfhammar> Perhaps its a bug that maskes the lookup bug ;-)
-    <antrik> I guess there is some quirk which you do not fully understand yet :-)
-    <cfhammar> Oh, there's always a new quirk to find in the Hurd :-)
-    <cfhammar> antrik: seems that dir_lookup isn't buggy after all
-    <cfhammar> antrik: as all FDs are reauthenticated on setauth
-    <antrik> ah
-    <cfhammar> antrik: and (presumably) ports are unauthenticated and reauthenticated when transfered
-    <antrik> yeah, that's the idea behind the auth protocol...
-    <antrik> users obtain specific capabilities by authenticating generic ports against their own ID
-    <cfhammar> I didn't really have a coherent view on how open flags are handled on reauth
-    <cfhammar> it seems open flags always win, so that a O_READ port that is unauthed is still readable
-    <antrik> not sure what you mean
-    <cfhammar> if I open a file to read it, then reauth it with a user that isn't permitted to read it, I can still read from it
-    <cfhammar> (as it should be)
-    <cfhammar> by contrast permission to do lookups in a directory is determined by who authed it
-    <cfhammar> so I won't be able to do lookups after a reauth, if it's not permitted by the file bits
-    <youpi> Mmm, openat should however be able to
-    <youpi> since you've first opened the directory with the auth
-    <cfhammar> it isn't since open FDs are reauthed on setauth
-    <cfhammar> not sure whether it should though, Linux behaves the same way atleast
-    <cfhammar> though it could be done with POSIX.2008's O_SEARCH open flag
diff --git a/open_issues/duplicate_inclusion_guards.mdwn b/open_issues/duplicate_inclusion_guards.mdwn
deleted file mode 100644
index 1bb8fc36..00000000
--- a/open_issues/duplicate_inclusion_guards.mdwn
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2009 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_mig]]
-
-E.g., both `/usr/include/hurd/process.h` and
-`/usr/include/hurd/process_request.h` use `_process_user_` as an inclusion
-guard.  This leads to problems when both are needed, as is the case in
-[[GDB]]'s `gdb/gnu-nat.c`.
diff --git a/open_issues/e2fsck_i_file_acl_hi.mdwn b/open_issues/e2fsck_i_file_acl_hi.mdwn
deleted file mode 100644
index d891ac6e..00000000
--- a/open_issues/e2fsck_i_file_acl_hi.mdwn
+++ /dev/null
@@ -1,40 +0,0 @@
-[[!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]]."]]"""]]
-
-IRC, unknown channel, unknown date.
-
-    <Duck> something's broken in ext2, fsck, or the like
-    <Duck>  /dev/hd0s1: i_file_acl_hi for inode 81872 (/proc) is 32, shoud be 0.
-    <Duck> youpi: the other problem is probably related to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526524
-    <Duck> i'll just check when it is fixed
-    <antrik> youpi: I've seen a lot of these fsck errors since the upgrade to 1.41.x
-    <antrik> youpi: seems to happen whenever a passive translator is still active while the machine reboots
-    <Duck> antrik: ho, so in my example this could be related to procfs then
-    <antrik> Duck: don't know... I got it with various terminal-related nodes
-    <antrik> other translators get terminated before ext2 it seems, so the problem doesn't happen there
-    <antrik> unless the machine crashes of course
-    <antrik> ah, right, it told you that it's the /proc node :-)
-    <antrik> was it the only node it complained about?
-    <antrik> Duck: ^
-    <Duck> antrik: yes, the only one
-    <youpi> so it's most probably i
-    <youpi> t
-    <Duck> but currently i don't have much translators around besides the base install
-    <antrik> that's strange... my theory about translators active at reboot seems wrong then
-    <youpi> well, maybe procps is not behaving properly
-    <youpi> procfs*
-    <antrik> youpi: I doubt it. I regularily get the same issue with various term nodes; and when the machine crashes rather than rebooting cleanly, many other nodes as well
-    <youpi> k
-    <antrik> but it's always passive translator nodes
-
-This is due to an erroneous read/write from e2fsck, see
-<http://sourceforge.net/tracker/?func=detail&aid=3379227&group_id=2406&atid=102406>.
-
-See [[!debbug 760275]]
diff --git a/open_issues/elinks.mdwn b/open_issues/elinks.mdwn
deleted file mode 100644
index ee372971..00000000
--- a/open_issues/elinks.mdwn
+++ /dev/null
@@ -1,28 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_porting]]
-
-IRC, unknown channel, 2008-05-26 and later
-
-    <paakku> In elinks/src/network/state.h, there is an assumption that values of errno are between 0 and 100000.  Now looking at glibc-2.5/sysdeps/mach/hurd/bits/errno.h, I see that you're using values outside this range.  Have there been problems because of this?
-    <youpi> eeerf
-    <youpi> I had never seen a program assuming that
-    <youpi> that sucks
-    <paakku> It can be fixed, but that'd require some work, so I'd like to first have a clear idea of the effects.
-    <youpi> fixed where ?
-    <paakku> in elinks
-    <youpi> k
-    <paakku> by allocating just one number from our enum connection_state for system errors, and then stashing the errno value in a separate variable.
-    <paakku> Anyway, if you see this cause any user-visible bugs in ELinks, please report.
-
-    <kahmalo> I mentioned here on 2008-05-26 that ELinks assumes errno values are between 0 and 100000 whereas the Hurd uses other values.  I fixed this in ELinks last weekend; the most recent 0.12 and 0.13 snapshots should include the fix.  If you find any remaining errno assumptions, please post to: http://bugzilla.elinks.cz/show_bug.cgi?id=1013
-    <kahmalo> or to one of our mailing lists.
-    <kahmalo> I guess the pflocal select() bug http://savannah.gnu.org/bugs/?22861 is the primary hindrance to running ELinks on the Hurd.  Has any decision been made on how that will be fixed?
diff --git a/open_issues/emacs.mdwn b/open_issues/emacs.mdwn
deleted file mode 100644
index 749649be..00000000
--- a/open_issues/emacs.mdwn
+++ /dev/null
@@ -1,1542 +0,0 @@
-[[!meta copyright="Copyright © 2009, 2013 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]]."]]"""]]
-
-[[!meta title="GNU Emacs"]]
-
-[[!tag open_issue_porting]]
-
-GNU Emacs mostly does work, however there are a few issues.
-
-  * `dired` on a directory hangs.  (Use `C-g C-g` to break the unresponsive
-    operation.)
-
-  * Configuration in `src/s/`: `gnu.h` uses `bsd-common.h`.  `gnu-kfreebsd.h`
-    uses `gnu-linux.h` -- we probably should too.
-
-      * `gnu-linux.h` makes a few things depend on `/proc` (also see
-        `HAVE_PROCFS`) -- either resort to our own ways, or enhance our
-        [[hurd/translator/procfs]] accordingly.
-
-          * `sysdep.c`
-
-  * Got a hang when compiling GNU Emacs 23, when it was compiling `.el` to
-    `.elc` files.  Looked like busy-looping inside glibc.  This was not
-    reproducible so far.
-
-  * Debian emacs23_23.1+1-2, grubber, (probably) busy-looping in `ext2fs` on
-    `/media/data` when resuming emacs23 build in `~/tmp/emacs/emacs23-*/`
-    (`dpkg-buildpackage -B -uc -nc 2>&1 | tee L`).  No modifications to
-    `emacs23-*` so far, I think.  Hangs always in the same place, it seems, and
-    reproducible.  Tarred to `emacs23-23.1+1.tar.bz2` (beware: empty and
-    zero-permission files:
-    `emacs23-23.1+1/.pc/debian-site-init-el.diff/lisp/site-init.el`,
-    `emacs23-23.1+1/.pc/autofiles.diff/src/config.in~`).  At hang-time: the
-    rootfs is fine (`syncfs -c -s /` works; `syncfs` involving `/media/data`
-    hangs).  Plan: GDB on that ext2fs, and see what's hanging / locked.  [[!tag
-    open_issue_hurd]]
-
-
----
-
-# 2010-10-11
-
-Apparently, none of the Debian emacs packages are installable at the moment.
-
-Try to compile bzr trunk.
-
-System (sort-of) crashed during build.  Perhaps while / or shortly after
-dumping `src/emacs`, as there was such a zero-sized file.  (Log file doesn't
-show anything useful.)  Removed the truncated `src/emacs`, continued build:
-
-    [...]
-    Compiling /home/tschwinge/tmp/emacs/trunk/lisp/cedet/srecode/mode.el
-    Parsing  *srecode-map-tmp* (LALR)...
-    Parsing  *srecode-map-tmp* (LALR)...done
-    Segmentation fault
-    make[2]: *** [cedet/srecode/mode.elc] Error 139
-    make[2]: Leaving directory `/media/data/home/tschwinge/tmp/emacs/trunk.build/lisp'
-    make[1]: *** [compile-main] Error 2
-    make[1]: Leaving directory `/media/data/home/tschwinge/tmp/emacs/trunk.build/lisp'
-    make: *** [lisp] Error 2
-
-Command line:
-
-    $ EMACSLOADPATH=/home/tschwinge/tmp/emacs/trunk/lisp LC_ALL=C /home/tschwinge/tmp/emacs/trunk.build/src/emacs -batch --no-site-file  -f batch-byte-compile /home/tschwinge/tmp/emacs/trunk/lisp/cedet/srecode/mode.el
-
-GDB:
-
-    Program received signal SIGSEGV, Segmentation fault.
-    mark_object (arg=1) at /home/tschwinge/tmp/emacs/trunk/src/alloc.c:5343
-    5343            if (STRING_MARKED_P (ptr))
-    (gdb) bt
-    #0  mark_object (arg=1) at /home/tschwinge/tmp/emacs/trunk/src/alloc.c:5343
-    #1  0x0818080f in Fgarbage_collect () at /home/tschwinge/tmp/emacs/trunk/src/alloc.c:4993
-    #2  0x08196db3 in Ffuncall (nargs=1, args=0x23fce70) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2987
-    #3  0x081ce8e1 in Fbyte_code (bytestr=139696577, vector=141708997, maxdepth=28) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
-    #4  0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
-    #5  0x08196bb3 in Ffuncall (nargs=1, args=0x23fcff0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
-    #6  0x081ce8e1 in Fbyte_code (bytestr=139922913, vector=141583493, maxdepth=28) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
-    #7  0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
-    #8  0x08196bb3 in Ffuncall (nargs=3, args=0x23fd170) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
-    #9  0x081ce8e1 in Fbyte_code (bytestr=140515737, vector=141583205, maxdepth=24) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
-    #10 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
-    #11 0x08196bb3 in Ffuncall (nargs=2, args=0x23fd2f0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
-    #12 0x081ce8e1 in Fbyte_code (bytestr=139911193, vector=139312997, maxdepth=12) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
-    #13 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
-    #14 0x08196bb3 in Ffuncall (nargs=3, args=0x23fd460) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
-    #15 0x081ce8e1 in Fbyte_code (bytestr=136508105, vector=136508125, maxdepth=20) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
-    #16 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
-    #17 0x08196bb3 in Ffuncall (nargs=3, args=0x23fd5e0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
-    #18 0x081ce8e1 in Fbyte_code (bytestr=136508849, vector=136508869, maxdepth=20) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
-    #19 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
-    #20 0x08195bff in apply_lambda (fun=136508805, args=139814646, eval_flag=1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3100
-    #21 0x08195ef4 in Feval (form=139814582) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2412
-    #22 0x081bb206 in readevalloop (readcharfun=138475290, stream=<value optimized out>, sourcename=139636697, printflag=0, unibyte=138364586, readfun=138364586,
-	start=138364586, end=138364586, evalfun=<value optimized out>) at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1734
-    #23 0x081bbad7 in Fload (file=140023529, noerror=138364586, nomessage=138364610, nosuffix=138364586, must_suffix=138364586)
-	at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1225
-    #24 0x081a1357 in Frequire (feature=141037690, filename=138364586, noerror=138364586) at /home/tschwinge/tmp/emacs/trunk/src/fns.c:2694
-    #25 0x08196d83 in Ffuncall (nargs=2, args=0x23fdb90) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2996
-    #26 0x081ce8e1 in Fbyte_code (bytestr=140023705, vector=141489853, maxdepth=8) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
-    #27 0x08196304 in Feval (form=141177630) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2358
-    #28 0x081bb206 in readevalloop (readcharfun=138475290, stream=<value optimized out>, sourcename=140023785, printflag=0, unibyte=138364586, readfun=138364586,
-	start=138364586, end=138364586, evalfun=<value optimized out>) at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1734
-    #29 0x081bbad7 in Fload (file=139743441, noerror=138364586, nomessage=138364610, nosuffix=138364586, must_suffix=138364586)
-	at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1225
-    #30 0x081a1357 in Frequire (feature=140528330, filename=138364586, noerror=138364586) at /home/tschwinge/tmp/emacs/trunk/src/fns.c:2694
-    #31 0x08196d83 in Ffuncall (nargs=2, args=0x23fe030) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2996
-    #32 0x081ce8e1 in Fbyte_code (bytestr=139743489, vector=139592949, maxdepth=8) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
-    #33 0x08196304 in Feval (form=139785254) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2358
-    #34 0x081bb206 in readevalloop (readcharfun=138475290, stream=<value optimized out>, sourcename=139743569, printflag=0, unibyte=138364586, readfun=138364586,
-	start=138364586, end=138364586, evalfun=<value optimized out>) at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1734
-    #35 0x081bbad7 in Fload (file=139985769, noerror=138364586, nomessage=138364610, nosuffix=138364586, must_suffix=138364586)
-	at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1225
-    #36 0x081a1357 in Frequire (feature=140528282, filename=138364586, noerror=138364586) at /home/tschwinge/tmp/emacs/trunk/src/fns.c:2694
-    #37 0x08196d83 in Ffuncall (nargs=2, args=0x23fe5c4) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2996
-    #38 0x0819879e in Fapply (nargs=2, args=0x23fe5c4) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2453
-    #39 0x08196e26 in Ffuncall (nargs=3, args=0x23fe5c0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2971
-    #40 0x081ce8e1 in Fbyte_code (bytestr=139665665, vector=140243293, maxdepth=12) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
-    #41 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
-    #42 0x08196bb3 in Ffuncall (nargs=2, args=0x23fe730) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
-    #43 0x081ce8e1 in Fbyte_code (bytestr=139663633, vector=140113917, maxdepth=16) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
-    #44 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
-    #45 0x08196bb3 in Ffuncall (nargs=2, args=0x23fe8a0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
-    #46 0x081ce8e1 in Fbyte_code (bytestr=139651313, vector=141733317, maxdepth=16) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
-    #47 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
-    #48 0x08196bb3 in Ffuncall (nargs=1, args=0x23fea20) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
-    #49 0x081961cd in Feval (form=142062606) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2324
-    #50 0x08198ec2 in internal_lisp_condition_case (var=139619738, bodyform=142062606, handlers=142059126) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1407
-    #51 0x081cdb3a in Fbyte_code (bytestr=139651065, vector=138947149, maxdepth=64) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:869
-    #52 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
-    #53 0x08196bb3 in Ffuncall (nargs=3, args=0x23fed10) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
-    #54 0x081ce8e1 in Fbyte_code (bytestr=139638617, vector=140190309, maxdepth=32) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
-    #55 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
-    #56 0x08195bff in apply_lambda (fun=141815293, args=139024998, eval_flag=1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3100
-    #57 0x08195ef4 in Feval (form=139025038) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2412
-    #58 0x08198ec2 in internal_lisp_condition_case (var=138727490, bodyform=139025038, handlers=138994086) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1407
-    #59 0x081cdb3a in Fbyte_code (bytestr=141397873, vector=139422605, maxdepth=12) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:869
-    #60 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
-    #61 0x08196bb3 in Ffuncall (nargs=2, args=0x23ff150) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
-    #62 0x081ce8e1 in Fbyte_code (bytestr=141396361, vector=138448733, maxdepth=20) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
-    #63 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
-    #64 0x08196bb3 in Ffuncall (nargs=1, args=0x23ff2d0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
-    #65 0x081ce8e1 in Fbyte_code (bytestr=136699577, vector=136699597, maxdepth=40) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
-    #66 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
-    #67 0x08196bb3 in Ffuncall (nargs=2, args=0x23ff460) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
-    #68 0x081ce8e1 in Fbyte_code (bytestr=136685793, vector=136685813, maxdepth=28) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
-    #69 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
-    #70 0x08196bb3 in Ffuncall (nargs=1, args=0x23ff5e0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047
-    #71 0x081ce8e1 in Fbyte_code (bytestr=136683265, vector=136683285, maxdepth=24) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679
-    #72 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174
-    #73 0x08195bff in apply_lambda (fun=136683245, args=138364586, eval_flag=1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3100
-    #74 0x08195ef4 in Feval (form=138740766) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2412
-    #75 0x0812dd83 in top_level_2 () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:1336
-    #76 0x081951dc in internal_condition_case (bfun=0x812dd70 <top_level_2>, handlers=138394034, hfun=0x8132020 <cmd_error>)
-	at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1460
-    #77 0x08131de5 in top_level_1 (ignore=138364586) at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:1344
-    #78 0x081952a9 in internal_catch (tag=138392170, func=0x8131d80 <top_level_1>, arg=138364586) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1204
-    #79 0x08131e53 in command_loop () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:1299
-    #80 0x0813220a in recursive_edit_1 () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:929
-    #81 0x08132332 in Frecursive_edit () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:991
-    #82 0x0812727b in main (argc=<value optimized out>, argv=0x23ffad8) at /home/tschwinge/tmp/emacs/trunk/src/emacs.c:1718
-
-Next: restarted from scratch, rebuilt without optimizations.
-`--prefix=$PWD.install --build=i686-pc-gnu --enable-asserts
---enable-checking=all CFLAGS=-g`
-
-    $ make
-    [...]
-    Dumping under the name emacs [sits here for a long time]
-
-    $ vmstat
-    pagesize:          4K
-    size:            324M
-    free:           9.16M
-    active:           56M
-    inactive:        242M
-    wired:          17.6M
-    zero filled:    8.75G
-    reactivated:       0 
-    pageins:         289M
-    pageouts:        371M
-    page faults: 12508128
-    cow faults:   1411724
-    memobj hit ratio: 99%
-    swap size:       512M
-    swap free:       512M
-
-Apparently low memory, but doesn't swap out.
-
-Uses a lot of CPU time, as observed with `xm top`.
-
-Creating another `screen` window as user tschwinge doesn't get to the shell
-prompt.
-
-Running `vmstat` works in a `screen` window that is already open, but running
-`ps -Af` just hangs; adding `-M` helps.
-
-Perhaps the /media/data/ file system (which backs /home/) is in a inconsistent
-state / deadlocked?
-
-More specifically, this does not work / does not exit:
-
-    login> syncfs -s -c /media/data/ &
-    [2] 10785
-
-But this works:
-
-    login> syncfs -s -c / &
-    [3] 10786
-    login> 
-    [3]+  Done                    syncfs -s -c /
-
-Thus, the rootfs still is responsive; /media/data/ is not.
-
-    login> ps -F hurd-long -T -M -w -A &
-    [4] 10796
-    login>   PID TH#  UID  PPID  PGrp  Sess TH  Vmem   RSS %CPU     User   System Args
-        0        0     1     1     1 16  132M    1M  0.0  0:04.84  0:54.84 /hurd/proc
-            0                                        0.0  0:00.00  0:00.13 
-            1                                        0.0  0:00.30  0:03.55 
-            2                                        0.0  0:00.30  0:04.21 
-            3                                        0.0  0:00.65  0:06.88 
-            4                                        0.0  0:00.02  0:00.31 
-            5                                        0.0  0:00.32  0:03.72 
-            6                                        0.0  0:00.00  0:00.23 
-            7                                        0.0  0:00.00  0:00.03 
-            8                                        0.0  0:00.30  0:03.17 
-            9                                        0.0  0:00.47  0:04.69 
-           10                                        0.0  0:00.62  0:06.42 
-           11                                        0.0  0:00.40  0:05.91 
-           12                                        0.0  0:00.47  0:04.18 
-           13                                        0.0  0:00.10  0:00.73 
-           14                                        0.0  0:00.56  0:05.97 
-           15                                        0.0  0:00.26  0:04.61 
-        1        0     1     1     1  1  146M  368K  0.0  0:00.00  0:00.03 /hurd/init root=device:hd0
-            0                                        0.0  0:00.00  0:00.03 
-        2        -     1     1     1  7  418M 19.5M  0.0  0:00.00  0:12.16 root=device:hd0
-            0                                        0.0  0:00.00  0:00.00 
-            1                                       92.6  0:00.00 46:33.66 
-            2                                        0.0  0:00.00  0:12.07 
-            3                                        0.0  0:00.00  0:00.05 
-            4                                        0.0  0:00.00  0:00.02 
-            5                                        0.0  0:00.00  0:00.00 
-            6                                        0.0  0:00.00  0:00.01 
-        3        0     1     1     1 173 409M 15.7M  0.2  4:39.39 34:08.86 ext2fs -A --multiboot-command-line=root=device:hd0 --host-priv-port=1 --device-master-port=2 --
-    M-exec-server-task=3 -T typed device:hd0
-            0                                        0.0  0:00.00  0:00.02 
-            1                                        0.0  0:21.78  2:32.67 
-            2                                        0.0  0:00.15  0:01.33 
-            3                                        0.0  0:00.07  0:01.13 
-            4                                        0.0  0:22.09  2:32.56 
-            5                                        0.0  0:00.11  0:01.30 
-            6                                        0.0  0:21.57  2:32.78 
-            7                                        0.2  0:04.10  0:54.37 
-            8                                        0.0  0:00.00  0:00.01 
-            9                                        0.0  0:20.96  2:30.00 
-           10                                        0.0  0:00.09  0:01.05 
-           11                                        0.0  0:00.09  0:00.94 
-           12                                        0.0  0:21.59  2:32.40 
-           13                                        0.0  0:21.50  2:32.02 
-           14                                        0.0  0:00.00  0:00.92 
-           15                                        0.0  0:00.07  0:00.60 
-           16                                        0.0  0:00.09  0:00.86 
-           17                                        0.0  0:00.04  0:00.88 
-           18                                        0.0  0:00.13  0:00.91 
-           19                                        0.0  0:00.04  0:00.91 
-           20                                        0.0  0:00.02  0:00.89 
-           21                                        0.0  0:00.08  0:00.97 
-           22                                        0.0  0:00.05  0:00.84 
-           23                                        0.0  0:00.04  0:00.86 
-           24                                        0.0  0:00.09  0:00.86 
-           25                                        0.0  0:00.11  0:00.88 
-           26                                        0.0  0:00.04  0:00.64 
-           27                                        0.0  0:21.10  2:32.22 
-           28                                        0.0  0:20.32  2:29.92 
-           29                                        0.0  0:20.58  2:31.51 
-           30                                        0.0  0:20.50  2:32.72 
-           31                                        0.0  0:21.05  2:30.05 
-           32                                        0.0  0:19.78  2:33.40 
-           33                                        0.0  0:20.55  2:31.88 
-           34                                        0.0  0:00.00  0:00.06 
-           35                                        0.0  0:00.00  0:00.07 
-           36                                        0.0  0:00.00  0:00.02 
-           37                                        0.0  0:00.01  0:00.05 
-           38                                        0.0  0:00.00  0:00.03 
-           39                                        0.0  0:00.00  0:00.02 
-           40                                        0.0  0:00.00  0:00.06 
-           41                                        0.0  0:00.02  0:00.02 
-           42                                        0.0  0:00.00  0:00.03 
-           43                                        0.0  0:00.00  0:00.05 
-           44                                        0.0  0:00.00  0:00.07 
-           45                                        0.0  0:00.00  0:00.02 
-           46                                        0.0  0:00.00  0:00.02 
-           47                                        0.0  0:00.00  0:00.04 
-           48                                        0.0  0:00.00  0:00.03 
-           49                                        0.0  0:00.00  0:00.03 
-           50                                        0.0  0:00.00  0:00.05 
-           51                                        0.0  0:00.00  0:00.05 
-           52                                        0.0  0:00.00  0:00.04 
-           53                                        0.0  0:00.00  0:00.04 
-           54                                        0.0  0:00.00  0:00.02 
-           55                                        0.0  0:00.00  0:00.03 
-           56                                        0.0  0:00.01  0:00.01 
-           57                                        0.0  0:00.03  0:00.01 
-           58                                        0.0  0:00.01  0:00.00 
-           59                                        0.0  0:00.00  0:00.00 
-           60                                        0.0  0:00.00  0:00.00 
-           61                                        0.0  0:00.00  0:00.03 
-           62                                        0.0  0:00.00  0:00.00 
-           63                                        0.0  0:00.00  0:00.08 
-           64                                        0.0  0:00.00  0:00.06 
-           65                                        0.0  0:00.01  0:00.00 
-           66                                        0.0  0:00.00  0:00.07 
-           67                                        0.0  0:00.00  0:00.01 
-           68                                        0.0  0:00.02  0:00.02 
-           69                                        0.0  0:00.01  0:00.02 
-           70                                        0.0  0:00.01  0:00.01 
-           71                                        0.0  0:00.01  0:00.04 
-           72                                        0.0  0:00.00  0:00.01 
-           73                                        0.0  0:00.01  0:00.00 
-           74                                        0.0  0:00.00  0:00.06 
-           75                                        0.0  0:00.00  0:00.04 
-           76                                        0.0  0:00.02  0:00.05 
-           77                                        0.0  0:00.00  0:00.03 
-           78                                        0.0  0:00.00  0:00.02 
-           79                                        0.0  0:00.00  0:00.05 
-           80                                        0.0  0:00.01  0:00.00 
-           81                                        0.0  0:00.00  0:00.02 
-           82                                        0.0  0:00.00  0:00.03 
-           83                                        0.0  0:00.00  0:00.00 
-           84                                        0.0  0:00.00  0:00.00 
-           85                                        0.0  0:00.00  0:00.04 
-           86                                        0.0  0:00.00  0:00.04 
-           87                                        0.0  0:00.00  0:00.02 
-           88                                        0.0  0:00.01  0:00.00 
-           89                                        0.0  0:00.00  0:00.04 
-           90                                        0.0  0:00.00  0:00.04 
-           91                                        0.0  0:00.00  0:00.05 
-           92                                        0.0  0:00.00  0:00.02 
-           93                                        0.0  0:00.00  0:00.03 
-           94                                        0.0  0:00.00  0:00.02 
-           95                                        0.0  0:00.00  0:00.01 
-           96                                        0.0  0:00.00  0:00.02 
-           97                                        0.0  0:00.00  0:00.03 
-           98                                        0.0  0:00.00  0:00.05 
-           99                                        0.0  0:00.00  0:00.04 
-          100                                        0.0  0:00.00  0:00.03 
-          101                                        0.0  0:00.00  0:00.01 
-          102                                        0.0  0:00.00  0:00.01 
-          103                                        0.0  0:00.00  0:00.05 
-          104                                        0.0  0:00.00  0:00.06 
-          105                                        0.0  0:00.01  0:00.04 
-          106                                        0.0  0:00.00  0:00.00 
-          107                                        0.0  0:00.01  0:00.02 
-          108                                        0.0  0:00.00  0:00.00 
-          109                                        0.0  0:00.00  0:00.02 
-          110                                        0.0  0:00.00  0:00.01 
-          111                                        0.0  0:00.00  0:00.02 
-          112                                        0.0  0:00.01  0:00.04 
-          113                                        0.0  0:00.01  0:00.01 
-          114                                        0.0  0:00.00  0:00.02 
-          115                                        0.0  0:00.01  0:00.02 
-          116                                        0.0  0:00.01  0:00.03 
-          117                                        0.0  0:00.00  0:00.03 
-          118                                        0.0  0:00.01  0:00.01 
-          119                                        0.0  0:00.00  0:00.01 
-          120                                        0.0  0:00.00  0:00.05 
-          121                                        0.0  0:00.00  0:00.02 
-          122                                        0.0  0:00.00  0:00.02 
-          123                                        0.0  0:00.00  0:00.04 
-          124                                        0.0  0:00.00  0:00.04 
-          125                                        0.0  0:00.00  0:00.02 
-          126                                        0.0  0:00.00  0:00.02 
-          127                                        0.0  0:00.01  0:00.01 
-          128                                        0.0  0:00.00  0:00.01 
-          129                                        0.0  0:00.01  0:00.03 
-          130                                        0.0  0:00.01  0:00.05 
-          131                                        0.0  0:00.00  0:00.02 
-          132                                        0.0  0:00.00  0:00.03 
-          133                                        0.0  0:00.00  0:00.03 
-          134                                        0.0  0:00.00  0:00.02 
-          135                                        0.0  0:00.00  0:00.00 
-          136                                        0.0  0:00.00  0:00.01 
-          137                                        0.0  0:00.01  0:00.03 
-          138                                        0.0  0:00.00  0:00.03 
-          139                                        0.0  0:00.00  0:00.02 
-          140                                        0.0  0:00.01  0:00.01 
-          141                                        0.0  0:00.01  0:00.02 
-          142                                        0.0  0:00.00  0:00.00 
-          143                                        0.0  0:00.00  0:00.02 
-          144                                        0.0  0:00.01  0:00.00 
-          145                                        0.0  0:00.00  0:00.01 
-          146                                        0.0  0:00.00  0:00.00 
-          147                                        0.0  0:00.00  0:00.00 
-          148                                        0.0  0:00.00  0:00.03 
-          149                                        0.0  0:00.00  0:00.00 
-          150                                        0.0  0:00.00  0:00.01 
-          151                                        0.0  0:00.00  0:00.00 
-          152                                        0.0  0:00.00  0:00.01 
-          153                                        0.0  0:00.00  0:00.00 
-          154                                        0.0  0:00.00  0:00.00 
-          155                                        0.0  0:00.00  0:00.00 
-          156                                        0.0  0:00.00  0:00.00 
-          157                                        0.0  0:00.00  0:00.01 
-          158                                        0.0  0:00.00  0:00.00 
-          159                                        0.0  0:00.00  0:00.01 
-          160                                        0.0  0:00.00  0:00.01 
-          161                                        0.0  0:00.00  0:00.00 
-          162                                        0.0  0:00.00  0:00.00 
-          163                                        0.0  0:00.00  0:00.00 
-          164                                        0.0  0:00.00  0:00.01 
-          165                                        0.0  0:00.00  0:00.00 
-          166                                        0.0  0:00.00  0:00.00 
-          167                                        0.0  0:00.00  0:00.00 
-          168                                        0.0  0:00.00  0:00.00 
-          169                                        0.0  0:00.00  0:00.00 
-          170                                        0.0  0:00.00  0:00.00 
-          171                                        0.0  0:00.00  0:00.00 
-          172                                        0.0  0:00.00  0:00.00 
-        4        0     3     1     1  6  131M 1.32M  0.0  0:02.20  0:26.26 /hurd/exec
-            0                                        0.0  0:00.43  0:05.32 
-            1                                        0.0  0:00.41  0:05.54 
-            2                                        0.0  0:00.44  0:05.38 
-            3                                        0.0  0:00.00  0:00.00 
-            4                                        0.0  0:00.45  0:05.05 
-            5                                        0.0  0:00.44  0:04.95 
-        5        0     1     1     1  6  130M  580K  0.0  0:01.17  0:14.92 /hurd/auth
-            0                                        0.0  0:00.20  0:02.99 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.24  0:03.03 
-            3                                        0.0  0:00.18  0:02.86 
-            4                                        0.0  0:00.22  0:03.01 
-            5                                        0.0  0:00.31  0:03.01 
-        6        0     1     6     6  2  147M 1.09M  0.0  0:00.01  0:00.13 /bin/bash /libexec/runsystem root=device:hd0
-            0                                        0.0  0:00.01  0:00.13 
-            1                                        0.0  0:00.00  0:00.00 
-        7        0     3     1     1  7  130M  880K  0.1  0:00.35  0:10.10 /hurd/term /dev/console device console
-            0                                        0.0  0:00.07  0:01.15 
-            1                                        0.0  0:00.00  0:00.01 
-            2                                        0.0  0:00.14  0:03.10 
-            3                                        0.1  0:00.10  0:01.87 
-            4                                        0.0  0:00.01  0:00.50 
-            5                                        0.0  0:00.00  0:01.54 
-            6                                        0.0  0:00.02  0:01.91 
-        9        0     3     1     1 19  131M 1.13M  0.0  0:05.41  1:17.29 /hurd/pflocal
-            0                                        0.0  0:00.06  0:00.48 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.05  0:00.48 
-            3                                        0.0  0:00.78  0:09.10 
-            4                                        0.0  0:00.49  0:06.13 
-            5                                        0.0  0:00.56  0:07.07 
-            6                                        0.0  0:00.30  0:03.41 
-            7                                        0.0  0:00.47  0:05.58 
-            8                                        0.0  0:00.27  0:06.00 
-            9                                        0.0  0:00.04  0:00.47 
-           10                                        0.0  0:00.43  0:06.17 
-           11                                        0.0  0:00.70  0:09.21 
-           12                                        0.0  0:00.00  0:00.04 
-           13                                        0.0  0:00.59  0:10.75 
-           14                                        0.0  0:00.14  0:01.86 
-           15                                        0.0  0:00.04  0:01.49 
-           16                                        0.0  0:00.02  0:00.76 
-           17                                        0.0  0:00.22  0:05.59 
-           18                                        0.0  0:00.16  0:02.62 
-       12        0     1    12    12  6  129M  1.2M  0.0  0:00.00  0:00.06 /hurd/mach-defpager
-            0                                        0.0  0:00.00  0:00.06 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.00  0:00.00 
-            3                                        0.0  0:00.00  0:00.00 
-            4                                        0.0  0:00.00  0:00.00 
-            5                                        0.0  0:00.00  0:00.00 
-       14        0     3     1     1  3  131M  504K  0.0  0:00.00  0:00.05 /hurd/storeio hd1
-            0                                        0.0  0:00.00  0:00.05 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.00  0:00.00 
-       18        0     3     1     1  3  131M  512K  0.0  0:00.39  0:06.71 /hurd/storeio hd0
-            0                                        0.0  0:00.13  0:01.66 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.25  0:05.04 
-       19        0     3     1     1  3  131M  656K  0.0  0:00.27  0:04.89 /hurd/storeio hd2
-            0                                        0.0  0:00.10  0:01.48 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.16  0:03.41 
-       21        0     3     1     1  4  130M  648K  0.0  0:00.55  0:06.94 /hurd/null
-            0                                        0.0  0:00.24  0:02.09 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.08  0:02.16 
-            3                                        0.0  0:00.22  0:02.68 
-       22        0     3     1     1  4  130M  820K  0.0  0:00.00  0:00.05 /hurd/procfs
-            0                                        0.0  0:00.00  0:00.04 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.00  0:00.00 
-            3                                        0.0  0:00.00  0:00.00 
-       71        1     1    71    71  2  146M  728K  0.0  0:00.00  0:00.03 /usr/sbin/atd
-            0                                        0.0  0:00.00  0:00.02 
-            1                                        0.0  0:00.00  0:00.00 
-       77        0     3     1     1  4  130M  896K  0.0  0:00.00  0:00.02 /hurd/streamio kmsg
-            0                                        0.0  0:00.00  0:00.02 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.00  0:00.00 
-            3                                        0.0  0:00.00  0:00.00 
-      117        0     1   117   117  2  146M 1.02M  0.0  0:00.00  0:00.04 /usr/sbin/cron
-            0                                        0.0  0:00.00  0:00.04 
-            1                                        0.0  0:00.00  0:00.00 
-      122      101     1   122   122  2 7.75M 1.07M  0.0  0:00.00  0:00.05 /usr/bin/dbus-daemon --system
-            0                                        0.0  0:00.00  0:00.05 
-            1                                        0.0  0:00.00  0:00.00 
-      128        0     3     1     1  4  130M  908K  0.0  0:00.00  0:00.02 /hurd/fifo
-            0                                        0.0  0:00.00  0:00.02 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.00  0:00.00 
-            3                                        0.0  0:00.00  0:00.00 
-      131        8     1     6     6  2  147M  880K  0.0  0:00.01  0:00.07 /usr/sbin/nullmailer-send -d
-            0                                        0.0  0:00.01  0:00.07 
-            1                                        0.0  0:00.00  0:00.00 
-      139        0     3     1     1 19  133M 2.19M  0.3  0:18.66  1:17.98 /hurd/pfinet -i eth0 -a 192.168.10.63 -g 192.168.10.1 -m 255.255.255.0
-            0                                        0.0  0:00.01  0:00.03 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.1  0:12.72  0:14.56 
-            3                                        0.2  0:01.65  0:12.23 
-            4                                        0.0  0:01.67  0:18.56 
-            5                                        0.0  0:00.50  0:05.93 
-            6                                        0.0  0:00.40  0:06.16 
-            7                                        0.0  0:00.57  0:05.95 
-            8                                        0.0  0:00.30  0:04.15 
-            9                                        0.0  0:00.15  0:01.92 
-           10                                        0.0  0:00.13  0:01.45 
-           11                                        0.0  0:00.14  0:01.47 
-           12                                        0.0  0:00.07  0:01.06 
-           13                                        0.0  0:00.08  0:01.23 
-           14                                        0.0  0:00.08  0:00.92 
-           15                                        0.0  0:00.03  0:00.63 
-           16                                        0.0  0:00.03  0:00.45 
-           17                                        0.0  0:00.05  0:00.72 
-           18                                        0.0  0:00.03  0:00.49 
-      140        0     3     1     1  3  131M 1.16M  0.0  0:00.00  0:00.05 /hurd/storeio --no-cache time
-            0                                        0.0  0:00.00  0:00.05 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.00  0:00.00 
-      142        0     1   142   142  2 10.5M 1.23M  0.0  0:00.00  0:00.05 /usr/sbin/sshd
-            0                                        0.0  0:00.00  0:00.05 
-            1                                        0.0  0:00.00  0:00.00 
-      157        0     3     1     1  6  130M    1M  0.0  0:00.02  0:00.01 /hurd/term /dev/tty1 hurdio /dev/vcs/1/console
-            0                                        0.0  0:00.00  0:00.00 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.00  0:00.00 
-            3                                        0.0  0:00.00  0:00.00 
-            4                                        0.0  0:00.00  0:00.01 
-            5                                        0.0  0:00.01  0:00.00 
-      158        0     6   158   158  2  146M  824K  0.0  0:00.00  0:00.01 /libexec/runttys
-            0                                        0.0  0:00.00  0:00.01 
-            1                                        0.0  0:00.00  0:00.00 
-      159        0     3     1     1 15  133M 1.67M  0.0  0:00.01  0:00.06 /hurd/console
-            0                                        0.0  0:00.01  0:00.02 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.00  0:00.00 
-            3                                        0.0  0:00.00  0:00.00 
-            4                                        0.0  0:00.00  0:00.01 
-            5                                        0.0  0:00.00  0:00.00 
-            6                                        0.0  0:00.00  0:00.00 
-            7                                        0.0  0:00.00  0:00.02 
-            8                                        0.0  0:00.00  0:00.00 
-            9                                        0.0  0:00.00  0:00.00 
-           10                                        0.0  0:00.00  0:00.00 
-           11                                        0.0  0:00.00  0:00.00 
-           12                                        0.0  0:00.00  0:00.01 
-           13                                        0.0  0:00.00  0:00.00 
-           14                                        0.0  0:00.00  0:00.00 
-      160        -   158   160   160  2  147M 1.82M  0.0  0:00.02  0:00.16 -login prompt (bash)
-            0                                        0.0  0:00.02  0:00.14 
-            1                                        0.0  0:00.00  0:00.02 
-      161        -   158   161   161  2  147M 1.78M  0.0  0:00.00  0:00.07 -login prompt (bash)
-            0                                        0.0  0:00.00  0:00.07 
-            1                                        0.0  0:00.00  0:00.00 
-      162        -   158   162   162  2  147M 1.78M  0.0  0:00.01  0:00.07 -login prompt (bash)
-            0                                        0.0  0:00.01  0:00.07 
-            1                                        0.0  0:00.00  0:00.00 
-      163        -   158   163   163  2  147M 1.78M  0.0  0:00.00  0:00.03 -login prompt (bash)
-            0                                        0.0  0:00.00  0:00.03 
-            1                                        0.0  0:00.00  0:00.00 
-      164        -   158   164   164  2  147M 1.78M  0.0  0:00.02  0:00.03 -login prompt (bash)
-            0                                        0.0  0:00.02  0:00.03 
-            1                                        0.0  0:00.00  0:00.00 
-      165        -   158   165   165  2  147M 1.78M  0.0  0:00.00  0:00.08 -login prompt (bash)
-            0                                        0.0  0:00.00  0:00.08 
-            1                                        0.0  0:00.00  0:00.00 
-      166        -   158   166   166  2  147M 1.78M  0.0  0:00.01  0:00.01 -login prompt (bash)
-            0                                        0.0  0:00.01  0:00.01 
-            1                                        0.0  0:00.00  0:00.00 
-      167        0     3     1     1  6  130M 1016K  0.0  0:00.01  0:00.11 /hurd/term /dev/tty2 hurdio /dev/vcs/2/console
-            0                                        0.0  0:00.01  0:00.06 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.00  0:00.00 
-            3                                        0.0  0:00.00  0:00.01 
-            4                                        0.0  0:00.00  0:00.03 
-            5                                        0.0  0:00.00  0:00.00 
-      168        0     3     1     1  6  130M 1016K  0.0  0:00.00  0:00.04 /hurd/term /dev/tty3 hurdio /dev/vcs/3/console
-            0                                        0.0  0:00.00  0:00.02 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.00  0:00.00 
-            3                                        0.0  0:00.00  0:00.01 
-            4                                        0.0  0:00.00  0:00.00 
-            5                                        0.0  0:00.00  0:00.01 
-      169        0     3     1     1  6  130M 1016K  0.0  0:00.00  0:00.04 /hurd/term /dev/tty5 hurdio /dev/vcs/5/console
-            0                                        0.0  0:00.00  0:00.00 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.00  0:00.00 
-            3                                        0.0  0:00.00  0:00.00 
-            4                                        0.0  0:00.00  0:00.04 
-            5                                        0.0  0:00.00  0:00.00 
-      170        0     3     1     1  6  130M 1016K  0.0  0:00.00  0:00.05 /hurd/term /dev/tty4 hurdio /dev/vcs/4/console
-            0                                        0.0  0:00.00  0:00.04 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.00  0:00.00 
-            3                                        0.0  0:00.00  0:00.00 
-            4                                        0.0  0:00.00  0:00.01 
-            5                                        0.0  0:00.00  0:00.00 
-      171        0     3     1     1  6  130M 1016K  0.0  0:00.00  0:00.01 /hurd/term /dev/tty6 hurdio /dev/vcs/6/console
-            0                                        0.0  0:00.00  0:00.01 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.00  0:00.00 
-            3                                        0.0  0:00.00  0:00.00 
-            4                                        0.0  0:00.00  0:00.00 
-            5                                        0.0  0:00.00  0:00.00 
-      172        0     3     1     1  4  130M  892K  0.0  0:00.00  0:00.01 /hurd/password
-            0                                        0.0  0:00.00  0:00.01 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.00  0:00.00 
-            3                                        0.0  0:00.00  0:00.00 
-      173        0   142   173   173  3 10.7M 3.09M  0.0  0:02.09  0:12.63 /usr/sbin/sshd -R
-            0                                        0.0  0:02.09  0:12.63 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.00  0:00.00 
-      174        0     3     1     1 632 2.99G 27.6M 100.3 16:43.18 52:54.41 /hurd/ext2fs /dev/hd2
-            0                                        0.0  0:00.01  0:00.03 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  1:34.24  6:26.66 
-            3                                        0.0  0:00.04  0:00.31 
-            4                                        0.0  0:00.13  0:00.47 
-            5                                        0.0  0:00.05  0:00.57 
-            6                                        0.0  1:36.91  6:26.41 
-            7                                        0.0  0:12.98  0:34.83 
-            8                                        0.0  1:37.85  6:26.20 
-            9                                        0.0  1:35.07  6:17.07 
-           10                                        0.0  0:00.05  0:00.50 
-           11                                        0.0  0:00.04  0:00.48 
-           12                                        0.0  0:00.07  0:00.55 
-           13                                        0.0  0:00.03  0:00.46 
-           14                                        0.0  0:00.03  0:00.42 
-           15                                        0.0  0:00.06  0:00.32 
-           16                                        0.0  0:00.05  0:00.56 
-           17                                        0.0  0:00.05  0:00.50 
-           18                                        0.0  0:00.05  0:00.48 
-           19                                        0.0  0:00.03  0:00.37 
-           20                                        0.0  0:00.08  0:00.48 
-           21                                        0.0  0:00.01  0:00.52 
-           22                                        0.0  0:00.02  0:00.44 
-           23                                        0.0  0:00.02  0:00.44 
-           24                                        0.0  0:00.03  0:00.31 
-           25                                        0.0  0:00.05  0:00.32 
-           26                                        0.0  0:00.04  0:00.37 
-           27                                        0.0  0:00.00  0:00.31 
-           28                                        0.0  0:00.03  0:00.23 
-           29                                        0.0  0:00.05  0:00.33 
-           30                                        0.0  0:00.04  0:00.31 
-           31                                        0.0  0:00.01  0:00.29 
-           32                                        0.0  0:00.07  0:00.27 
-           33                                        0.0  0:00.05  0:00.28 
-           34                                        0.0  0:00.04  0:00.23 
-           35                                        0.0  0:00.04  0:00.46 
-           36                                        0.0  0:00.02  0:00.31 
-           37                                        0.0  0:00.02  0:00.38 
-           38                                        0.0  0:00.06  0:00.29 
-           39                                        0.0  0:00.03  0:00.22 
-           40                                        0.0  0:00.02  0:00.28 
-           41                                        0.0  0:00.03  0:00.26 
-           42                                        0.0  0:00.05  0:00.39 
-           43                                        0.0  0:00.06  0:00.37 
-           44                                        0.0  0:00.03  0:00.36 
-           45                                        0.0  0:00.04  0:00.20 
-           46                                        0.0  0:00.02  0:00.28 
-           47                                        0.0  0:00.01  0:00.29 
-           48                                        0.0  0:00.03  0:00.23 
-           49                                        0.0  0:00.04  0:00.22 
-           50                                        0.0  0:00.07  0:00.25 
-           51                                        0.0  0:00.00  0:00.33 
-           52                                        0.0  0:00.05  0:00.49 
-           53                                        0.0  0:00.02  0:00.31 
-           54                                        0.0  0:00.00  0:00.27 
-           55                                        0.0  0:00.06  0:00.25 
-           56                                        0.0  0:00.05  0:00.35 
-           57                                        0.0  0:00.01  0:00.28 
-           58                                        0.0  0:00.06  0:00.25 
-           59                                        0.0  0:00.05  0:00.30 
-           60                                        0.0  0:00.03  0:00.36 
-           61                                        0.0  0:00.04  0:00.31 
-           62                                        0.0  0:00.05  0:00.18 
-           63                                        0.0  0:00.02  0:00.31 
-           64                                        0.0  0:00.00  0:00.27 
-           65                                        0.0  0:00.02  0:00.26 
-           66                                        0.0  0:00.00  0:00.31 
-           67                                        0.0  0:00.00  0:00.15 
-           68                                        0.0  0:00.04  0:00.32 
-           69                                        0.0  0:00.04  0:00.21 
-           70                                        0.0  0:00.01  0:00.31 
-           71                                        0.0  0:00.05  0:00.22 
-           72                                        0.0  0:00.01  0:00.28 
-           73                                        0.0  0:00.04  0:00.31 
-           74                                        0.0  0:00.06  0:00.20 
-           75                                        0.0  0:00.04  0:00.38 
-           76                                        0.0  0:00.03  0:00.37 
-           77                                        0.0  0:00.06  0:00.32 
-           78                                        0.0  0:00.04  0:00.22 
-           79                                        0.0  0:00.04  0:00.25 
-           80                                        0.0  0:00.04  0:00.29 
-           81                                        0.0  0:00.07  0:00.31 
-           82                                        0.0  0:00.04  0:00.27 
-           83                                        0.0  0:00.04  0:00.23 
-           84                                        0.0  0:00.02  0:00.37 
-           85                                        0.0  0:00.03  0:00.24 
-           86                                        0.0  0:00.01  0:00.29 
-           87                                        0.0  0:00.03  0:00.24 
-           88                                        0.0  0:00.01  0:00.31 
-           89                                        0.0  0:00.03  0:00.39 
-           90                                        0.0  0:00.00  0:00.30 
-           91                                        0.0  0:00.03  0:00.32 
-           92                                        0.0  0:00.00  0:00.24 
-           93                                        0.0  0:00.03  0:00.32 
-           94                                        0.0  0:00.04  0:00.30 
-           95                                        0.0  0:00.00  0:00.33 
-           96                                        0.0  0:00.02  0:00.24 
-           97                                        0.0  0:00.01  0:00.26 
-           98                                        0.0  0:00.04  0:00.33 
-           99                                        0.0  0:00.03  0:00.26 
-          100                                        0.0  0:00.05  0:00.29 
-          101                                        0.0  0:00.05  0:00.34 
-          102                                        0.0  0:00.04  0:00.38 
-          103                                        0.0  0:00.00  0:00.22 
-          104                                        0.0  0:00.03  0:00.38 
-          105                                        0.0  0:00.01  0:00.43 
-          106                                        0.0  0:00.03  0:00.37 
-          107                                        0.0  0:00.05  0:00.31 
-          108                                        0.0  0:00.02  0:00.31 
-          109                                        0.0  0:00.00  0:00.26 
-          110                                        0.0  0:00.03  0:00.27 
-          111                                        0.0  0:00.03  0:00.25 
-          112                                        0.0  0:00.02  0:00.30 
-          113                                        0.0  0:00.05  0:00.23 
-          114                                        0.0  0:00.02  0:00.32 
-          115                                        0.0  0:00.02  0:00.29 
-          116                                        0.0  0:00.04  0:00.22 
-          117                                        0.0  0:00.04  0:00.26 
-          118                                        0.0  0:00.02  0:00.36 
-          119                                        0.0  0:00.03  0:00.31 
-          120                                        0.0  0:00.04  0:00.26 
-          121                                        0.0  0:00.05  0:00.28 
-          122                                        0.0  0:00.01  0:00.27 
-          123                                        0.0  0:00.03  0:00.34 
-          124                                        0.0  0:00.03  0:00.36 
-          125                                        0.0  0:00.02  0:00.33 
-          126                                        0.0  0:00.04  0:00.36 
-          127                                        0.0  0:00.00  0:00.41 
-          128                                        0.0  0:00.02  0:00.33 
-          129                                        0.0  0:00.07  0:00.32 
-          130                                        0.0  0:00.03  0:00.29 
-          131                                        0.0  0:00.00  0:00.34 
-          132                                        0.0  0:00.04  0:00.28 
-          133                                        0.0  0:00.04  0:00.24 
-          134                                        0.0  0:00.03  0:00.35 
-          135                                        0.0  0:00.04  0:00.38 
-          136                                        0.0  0:00.04  0:00.37 
-          137                                        0.0  0:00.04  0:00.26 
-          138                                        0.0  0:00.00  0:00.26 
-          139                                        0.0  0:00.06  0:00.40 
-          140                                        0.0  1:23.58  6:28.86 
-          141                                        0.0  0:25.74  1:55.97 
-          142                                        0.0  0:00.00  0:00.00 
-          143                                        0.0  0:00.00  0:00.00 
-          144                                        0.0  0:00.00  0:00.00 
-          145                                        0.0  0:00.00  0:00.00 
-          146                                        0.0  0:00.00  0:00.00 
-          147                                        0.0  0:00.00  0:00.00 
-          148                                        0.0  0:00.00  0:00.00 
-          149                                        0.0  0:00.00  0:00.00 
-          150                                        0.0  0:00.00  0:00.00 
-          151                                        0.0  0:00.00  0:00.00 
-          152                                        0.0  0:00.00  0:00.00 
-          153                                        0.0  0:00.00  0:00.00 
-          154                                        0.0  0:00.00  0:00.00 
-          155                                        0.0  0:00.00  0:00.00 
-          156                                        0.0  0:00.00  0:00.00 
-          157                                        0.0  0:00.00  0:00.00 
-          158                                        0.0  0:00.00  0:00.00 
-          159                                        0.0  0:00.00  0:00.00 
-          160                                        0.0  0:00.00  0:00.00 
-          161                                        0.0  0:00.00  0:00.00 
-          162                                        0.0  0:00.00  0:00.00 
-          163                                        0.0  0:00.00  0:00.00 
-          164                                        0.0  0:00.00  0:00.00 
-          165                                        0.0  0:00.00  0:00.00 
-          166                                        0.0  0:00.00  0:00.00 
-          167                                        0.0  0:00.00  0:00.00 
-          168                                        0.0  0:00.00  0:00.00 
-          169                                        0.0  0:00.00  0:00.00 
-          170                                        0.0  0:00.00  0:00.00 
-          171                                        0.0  0:00.00  0:00.00 
-          172                                        0.0  0:00.00  0:00.00 
-          173                                        0.0  0:00.00  0:00.00 
-          174                                        0.0  0:00.00  0:00.00 
-          175                                        0.0  0:00.00  0:00.00 
-          176                                        0.0  0:00.00  0:00.00 
-          177                                        0.0  0:00.00  0:00.00 
-          178                                        0.0  0:00.00  0:00.00 
-          179                                        0.0  0:00.00  0:00.00 
-          180                                        0.0  0:00.00  0:00.00 
-          181                                        0.0  0:00.00  0:00.00 
-          182                                        0.0  0:00.00  0:00.00 
-          183                                        0.0  0:00.00  0:00.00 
-          184                                        0.0  0:00.00  0:00.00 
-          185                                        0.0  0:00.00  0:00.00 
-          186                                        0.0  0:00.00  0:00.00 
-          187                                        0.0  0:00.00  0:00.00 
-          188                                        0.0  0:00.00  0:00.00 
-          189                                        0.0  0:00.00  0:00.00 
-          190                                        0.0  0:00.00  0:00.00 
-          191                                        0.0  0:00.00  0:00.00 
-          192                                        0.0  0:00.00  0:00.00 
-          193                                        0.0  0:00.00  0:00.00 
-          194                                        0.0  0:00.00  0:00.00 
-          195                                        0.0  0:00.00  0:00.00 
-          196                                        0.0  0:00.00  0:00.00 
-          197                                        0.0  0:00.00  0:00.00 
-          198                                        0.0  0:00.00  0:00.00 
-          199                                        0.0  0:00.00  0:00.00 
-          200                                        0.0  0:00.00  0:00.00 
-          201                                        0.0  0:00.00  0:00.00 
-          202                                        0.0  0:00.00  0:00.00 
-          203                                        0.0  0:00.00  0:00.00 
-          204                                        0.0  0:00.00  0:00.00 
-          205                                        0.0  0:00.00  0:00.00 
-          206                                        0.0  0:00.00  0:00.00 
-          207                                        0.0  0:00.00  0:00.00 
-          208                                        0.0  0:00.00  0:00.00 
-          209                                        0.0  0:00.00  0:00.00 
-          210                                        0.0  0:00.00  0:00.00 
-          211                                        0.0  0:00.00  0:00.00 
-          212                                        0.0  0:00.00  0:00.00 
-          213                                        0.0  0:00.00  0:00.00 
-          214                                        0.0  0:00.00  0:00.00 
-          215                                        0.0  0:00.00  0:00.00 
-          216                                        0.0  0:00.00  0:00.00 
-          217                                        0.0  0:00.00  0:00.00 
-          218                                        0.0  0:00.00  0:00.00 
-          219                                        0.0  0:00.00  0:00.00 
-          220                                        0.0  0:00.00  0:00.00 
-          221                                        0.0  0:00.00  0:00.00 
-          222                                        0.0  0:00.00  0:00.00 
-          223                                        0.0  0:00.00  0:00.00 
-          224                                        0.0  0:00.00  0:00.00 
-          225                                        0.0  0:00.00  0:00.00 
-          226                                        0.0  0:00.00  0:00.00 
-          227                                        0.0  0:00.00  0:00.00 
-          228                                        0.0  0:00.00  0:00.00 
-          229                                        0.0  0:00.00  0:00.00 
-          230                                        0.0  0:00.00  0:00.00 
-          231                                        0.0  0:00.00  0:00.00 
-          232                                        0.0  0:00.00  0:00.00 
-          233                                        0.0  0:00.00  0:00.00 
-          234                                        0.0  0:00.00  0:00.00 
-          235                                        0.0  0:00.00  0:00.00 
-          236                                        0.0  0:00.00  0:00.00 
-          237                                        0.0  0:00.00  0:00.00 
-          238                                        0.0  0:00.00  0:00.00 
-          239                                        0.0  0:00.00  0:00.00 
-          240                                        0.0  0:00.00  0:00.00 
-          241                                        0.0  0:00.00  0:00.00 
-          242                                        0.0  0:00.00  0:00.00 
-          243                                        0.0  0:00.00  0:00.00 
-          244                                        0.0  0:00.00  0:00.00 
-          245                                        0.0  0:00.00  0:00.00 
-          246                                        0.0  0:00.00  0:00.00 
-          247                                        0.0  0:00.00  0:00.00 
-          248                                        0.0  0:00.00  0:00.00 
-          249                                        0.0  0:00.00  0:00.00 
-          250                                        0.0  0:00.00  0:00.00 
-          251                                        0.0  0:00.00  0:00.00 
-          252                                        0.0  0:00.00  0:00.00 
-          253                                        0.0  0:00.00  0:00.00 
-          254                                        0.0  0:00.00  0:00.00 
-          255                                        0.0  0:00.00  0:00.00 
-          256                                        0.0  0:00.00  0:00.00 
-          257                                        0.0  0:00.00  0:00.00 
-          258                                        0.0  0:00.00  0:00.00 
-          259                                        0.0  0:00.00  0:00.00 
-          260                                        0.0  0:00.00  0:00.00 
-          261                                        0.0  0:00.00  0:00.00 
-          262                                        0.0  0:00.00  0:00.00 
-          263                                        0.0  0:00.00  0:00.00 
-          264                                        0.0  0:00.00  0:00.00 
-          265                                        0.0  0:00.00  0:00.00 
-          266                                        0.0  0:00.00  0:00.00 
-          267                                        0.0  0:00.00  0:00.00 
-          268                                        0.0  0:00.00  0:00.00 
-          269                                        0.0  0:00.00  0:00.00 
-          270                                        0.0  0:00.00  0:00.00 
-          271                                        0.0  0:00.00  0:00.00 
-          272                                        0.0  0:00.00  0:00.00 
-          273                                        0.0  0:00.00  0:00.00 
-          274                                        0.0  0:00.00  0:00.00 
-          275                                        0.0  0:00.00  0:00.00 
-          276                                        0.0  0:00.00  0:00.00 
-          277                                        0.0  0:00.00  0:00.00 
-          278                                        0.0  0:00.00  0:00.00 
-          279                                        0.0  0:00.00  0:00.00 
-          280                                        0.0  0:00.00  0:00.00 
-          281                                        0.0  0:00.00  0:00.00 
-          282                                        0.0  0:00.00  0:00.00 
-          283                                        0.0  0:00.00  0:00.00 
-          284                                        0.0  0:00.00  0:00.00 
-          285                                        0.0  0:00.00  0:00.00 
-          286                                        0.0  0:00.00  0:00.00 
-          287                                        0.0  0:00.00  0:00.00 
-          288                                        0.0  0:00.00  0:00.00 
-          289                                        0.0  0:00.00  0:00.00 
-          290                                        0.0  0:00.00  0:00.00 
-          291                                        0.0  0:00.00  0:00.00 
-          292                                        0.0  0:00.00  0:00.00 
-          293                                        0.0  0:00.00  0:00.00 
-          294                                        0.0  0:00.00  0:00.00 
-          295                                        0.0  0:00.00  0:00.00 
-          296                                        0.0  0:00.00  0:00.00 
-          297                                        0.0  0:00.00  0:00.00 
-          298                                        0.0  0:00.00  0:00.00 
-          299                                        0.0  0:00.00  0:00.00 
-          300                                        0.0  0:00.00  0:00.00 
-          301                                        0.0  0:00.00  0:00.00 
-          302                                        0.0  0:00.00  0:00.00 
-          303                                        0.0  0:00.00  0:00.00 
-          304                                        0.0  0:00.00  0:00.00 
-          305                                        0.0  0:00.00  0:00.00 
-          306                                        0.0  0:00.00  0:00.00 
-          307                                        0.0  0:00.00  0:00.00 
-          308                                        0.0  0:00.00  0:00.00 
-          309                                        0.0  0:00.00  0:00.00 
-          310                                        0.0  0:00.00  0:00.00 
-          311                                        0.0  0:00.00  0:00.00 
-          312                                        0.0  0:00.00  0:00.00 
-          313                                        0.0  0:00.00  0:00.00 
-          314                                        0.0  0:00.00  0:00.00 
-          315                                        0.0  0:00.00  0:00.00 
-          316                                        0.0  0:00.00  0:00.00 
-          317                                        0.0  0:00.00  0:00.00 
-          318                                        0.0  0:00.00  0:00.00 
-          319                                        0.0  0:00.00  0:00.00 
-          320                                        0.0  0:00.00  0:00.00 
-          321                                        0.0  0:00.00  0:00.00 
-          322                                        0.0  0:00.00  0:00.00 
-          323                                        0.0  0:00.00  0:00.00 
-          324                                        0.0  0:00.00  0:00.00 
-          325                                        0.0  0:00.00  0:00.00 
-          326                                        0.0  0:00.00  0:00.00 
-          327                                        0.0  0:00.00  0:00.00 
-          328                                        0.0  0:00.00  0:00.00 
-          329                                        0.0  0:00.00  0:00.00 
-          330                                        0.0  0:00.00  0:00.00 
-          331                                        0.0  0:00.00  0:00.00 
-          332                                        0.0  0:00.00  0:00.00 
-          333                                        0.0  0:00.00  0:00.00 
-          334                                        0.0  0:00.00  0:00.00 
-          335                                        0.0  0:00.00  0:00.00 
-          336                                        0.0  0:00.00  0:00.00 
-          337                                        0.0  0:00.00  0:00.00 
-          338                                        0.0  0:00.00  0:00.00 
-          339                                        0.0  0:00.00  0:00.00 
-          340                                        0.0  0:00.00  0:00.00 
-          341                                        0.0  0:00.00  0:00.00 
-          342                                        0.0  0:00.00  0:00.00 
-          343                                        0.0  0:00.00  0:00.00 
-          344                                        0.0  0:00.00  0:00.00 
-          345                                        0.0  0:00.00  0:00.00 
-          346                                        0.0  0:00.00  0:00.00 
-          347                                        0.0  0:00.00  0:00.00 
-          348                                        0.0  0:00.00  0:00.00 
-          349                                        0.0  0:00.00  0:00.00 
-          350                                        0.0  0:00.00  0:00.00 
-          351                                        0.0  0:00.00  0:00.00 
-          352                                        0.0  0:00.00  0:00.00 
-          353                                        0.0  0:00.00  0:00.00 
-          354                                        0.0  0:00.00  0:00.00 
-          355                                        0.0  0:00.00  0:00.00 
-          356                                        0.0  0:00.00  0:00.00 
-          357                                        0.0  0:00.00  0:00.00 
-          358                                        0.0  0:00.00  0:00.00 
-          359                                        0.0  0:00.00  0:00.00 
-          360                                        0.0  0:00.00  0:00.00 
-          361                                        0.0  0:00.00  0:00.00 
-          362                                        0.0  0:00.00  0:00.00 
-          363                                        0.0  0:00.00  0:00.00 
-          364                                        0.0  0:00.00  0:00.00 
-          365                                        0.0  0:00.00  0:00.00 
-          366                                        0.0  0:00.00  0:00.00 
-          367                                        0.0  0:00.00  0:00.00 
-          368                                        0.0  0:00.00  0:00.00 
-          369                                        0.0  0:00.00  0:00.00 
-          370                                        0.0  0:00.00  0:00.00 
-          371                                        0.0  0:00.00  0:00.03 
-          372                                        0.0  0:00.00  0:00.00 
-          373                                        0.0  0:00.00  0:00.00 
-          374                                        0.0  0:00.00  0:00.00 
-          375                                        0.0  0:00.00  0:00.00 
-          376                                        0.0  0:00.00  0:00.00 
-          377                                        0.0  0:00.00  0:00.00 
-          378                                        0.0  0:00.00  0:00.00 
-          379                                        0.0  0:00.00  0:00.00 
-          380                                        0.0  0:00.00  0:00.00 
-          381                                        0.0  0:00.00  0:00.00 
-          382                                        0.0  0:00.00  0:00.00 
-          383                                        0.0  0:00.00  0:00.00 
-          384                                        0.0  0:00.00  0:00.00 
-          385                                        0.0  0:00.00  0:00.00 
-          386                                        0.0  0:00.00  0:00.00 
-          387                                        0.0  0:00.00  0:00.00 
-          388                                        0.0  0:00.00  0:00.00 
-          389                                        0.0  0:00.00  0:00.00 
-          390                                        0.0  0:00.00  0:00.00 
-          391                                        0.0  0:00.00  0:00.00 
-          392                                        0.0  0:00.00  0:00.00 
-          393                                        0.0  0:00.00  0:00.00 
-          394                                        0.0  0:00.00  0:00.00 
-          395                                        0.0  0:00.00  0:00.00 
-          396                                        0.0  0:00.00  0:00.00 
-          397                                        0.0  0:00.00  0:00.00 
-          398                                        0.0  0:00.00  0:00.00 
-          399                                        0.0  0:00.00  0:00.00 
-          400                                        0.0  0:00.00  0:00.00 
-          401                                        0.0  0:00.00  0:00.00 
-          402                                        0.0  0:00.00  0:00.00 
-          403                                        0.0  0:00.00  0:00.00 
-          404                                        0.0  0:00.00  0:00.00 
-          405                                        0.0  0:00.00  0:00.00 
-          406                                        0.0  0:00.00  0:00.00 
-          407                                        0.0  0:00.00  0:00.00 
-          408                                        0.0  0:00.00  0:00.00 
-          409                                        0.0  0:00.00  0:00.00 
-          410                                        0.0  0:00.00  0:00.00 
-          411                                        0.0  0:00.00  0:00.00 
-          412                                        0.0  0:00.00  0:00.00 
-          413                                        0.0  0:00.00  0:00.00 
-          414                                        0.0  0:00.00  0:00.00 
-          415                                        0.0  0:00.00  0:00.00 
-          416                                        0.0  0:00.00  0:00.00 
-          417                                        0.0  0:00.00  0:00.00 
-          418                                        0.0  0:00.00  0:00.00 
-          419                                        0.0  0:00.00  0:00.00 
-          420                                        0.0  0:00.00  0:00.00 
-          421                                        0.0  0:00.00  0:00.00 
-          422                                        0.0  0:00.00  0:00.00 
-          423                                        0.0  0:00.00  0:00.00 
-          424                                        0.0  0:00.00  0:00.00 
-          425                                        0.0  0:00.00  0:00.00 
-          426                                        0.0  0:00.00  0:00.00 
-          427                                        0.0  0:00.00  0:00.00 
-          428                                        0.0  0:00.00  0:00.00 
-          429                                        0.0  0:00.00  0:00.00 
-          430                                        0.0  0:00.00  0:00.00 
-          431                                        0.0  0:00.00  0:00.00 
-          432                                        0.0  0:00.00  0:00.00 
-          433                                        0.0  0:00.00  0:00.00 
-          434                                        0.0  0:00.00  0:00.00 
-          435                                        0.0  0:00.00  0:00.00 
-          436                                        0.0  0:00.00  0:00.00 
-          437                                        0.0  0:00.00  0:00.00 
-          438                                        0.0  0:00.00  0:00.00 
-          439                                        0.0  0:00.00  0:00.00 
-          440                                        0.0  0:00.00  0:00.00 
-          441                                        0.0  0:00.00  0:00.00 
-          442                                        0.0  0:00.00  0:00.00 
-          443                                        0.0  0:00.00  0:00.00 
-          444                                        0.0  0:00.00  0:00.00 
-          445                                        0.0  0:00.00  0:00.00 
-          446                                        0.0  0:00.00  0:00.00 
-          447                                        0.0  0:00.00  0:00.00 
-          448                                        0.0  0:00.00  0:00.00 
-          449                                        0.0  0:00.00  0:00.00 
-          450                                        0.0  0:00.00  0:00.00 
-          451                                        0.0  0:00.00  0:00.00 
-          452                                        0.0  0:00.00  0:00.00 
-          453                                        0.0  0:00.00  0:00.00 
-          454                                        0.0  0:00.00  0:00.00 
-          455                                        0.0  0:00.00  0:00.00 
-          456                                        0.0  0:00.00  0:00.00 
-          457                                        0.0  0:00.00  0:00.00 
-          458                                        0.0  0:00.00  0:00.00 
-          459                                        0.0  0:00.00  0:00.00 
-          460                                        0.0  0:00.00  0:00.00 
-          461                                        0.0  0:00.00  0:00.00 
-          462                                        0.0  0:00.00  0:00.00 
-          463                                        0.0  0:00.00  0:00.00 
-          464                                        0.0  0:00.00  0:00.00 
-          465                                        0.0  0:00.00  0:00.00 
-          466                                        0.0  0:00.00  0:00.00 
-          467                                        0.0  0:00.00  0:00.00 
-          468                                        0.0  0:00.00  0:00.00 
-          469                                        0.0  0:00.00  0:00.00 
-          470                                        0.0  0:00.00  0:00.00 
-          471                                        0.0  0:00.00  0:00.00 
-          472                                        0.0  0:00.00  0:00.00 
-          473                                        0.0  0:00.00  0:00.00 
-          474                                        0.0  0:00.00  0:00.00 
-          475                                        0.0  0:00.00  0:00.00 
-          476                                        0.0  0:00.00  0:00.00 
-          477                                        0.0  0:00.00  0:00.00 
-          478                                        0.0  0:00.00  0:00.00 
-          479                                        0.0  0:00.00  0:00.00 
-          480                                        0.0  0:00.00  0:00.00 
-          481                                        0.0  0:00.00  0:00.00 
-          482                                        0.0  0:00.00  0:00.00 
-          483                                        0.0  0:00.00  0:00.00 
-          484                                        0.0  0:00.00  0:00.00 
-          485                                        0.0  0:00.00  0:00.00 
-          486                                        0.0  0:00.00  0:00.00 
-          487                                        0.0  0:00.00  0:00.00 
-          488                                        0.0  0:00.00  0:00.00 
-          489                                        0.0  0:00.00  0:00.00 
-          490                                        0.0  0:00.00  0:00.00 
-          491                                        0.0  0:00.00  0:00.00 
-          492                                        0.0  0:00.00  0:00.00 
-          493                                        0.0  0:00.00  0:00.00 
-          494                                        0.0  0:00.00  0:00.00 
-          495                                        0.0  0:00.00  0:00.00 
-          496                                        0.0  0:00.00  0:00.00 
-          497                                        0.0  0:00.00  0:00.00 
-          498                                        0.0  0:00.00  0:00.00 
-          499                                        0.0  0:00.00  0:00.00 
-          500                                        0.0  0:00.00  0:00.00 
-          501                                        0.0  0:00.00  0:00.00 
-          502                                        0.0  0:00.00  0:00.00 
-          503                                        0.0  0:00.00  0:00.00 
-          504                                        0.0  0:00.00  0:00.00 
-          505                                        0.0  0:00.00  0:00.00 
-          506                                        0.0  0:00.00  0:00.00 
-          507                                        0.0  0:00.00  0:00.00 
-          508                                        0.0  0:00.00  0:00.00 
-          509                                        0.0  0:00.00  0:00.00 
-          510                                        0.0  0:00.00  0:00.00 
-          511                                        0.0  0:00.00  0:00.00 
-          512                                        0.0  0:00.00  0:00.00 
-          513                                        0.0  0:00.00  0:00.00 
-          514                                        0.0  0:00.00  0:00.00 
-          515                                        0.0  0:00.00  0:00.00 
-          516                                        0.0  0:00.00  0:00.00 
-          517                                        0.0  0:00.00  0:00.00 
-          518                                        0.0  0:00.00  0:00.00 
-          519                                        0.0  0:00.00  0:00.00 
-          520                                        0.0  0:00.00  0:00.00 
-          521                                        0.0  0:00.00  0:00.00 
-          522                                        0.0  0:00.00  0:00.00 
-          523                                        0.0  0:00.00  0:00.00 
-          524                                        0.0  0:00.00  0:00.00 
-          525                                        0.0  0:00.00  0:00.00 
-          526                                        0.0  0:00.00  0:00.00 
-          527                                        0.0  0:00.00  0:00.00 
-          528                                        0.0  0:00.00  0:00.00 
-          529                                        0.0  0:00.00  0:00.00 
-          530                                        0.0  0:00.00  0:00.00 
-          531                                        0.0  0:00.00  0:00.00 
-          532                                        0.0  0:00.00  0:00.00 
-          533                                        0.0  0:00.00  0:00.00 
-          534                                        0.0  0:00.00  0:00.00 
-          535                                        0.0  0:00.00  0:00.00 
-          536                                        0.0  0:00.00  0:00.00 
-          537                                        0.0  0:00.00  0:00.00 
-          538                                        0.0  0:00.00  0:00.00 
-          539                                        0.0  0:00.00  0:00.00 
-          540                                        0.0  0:00.00  0:00.00 
-          541                                        0.0  0:00.00  0:00.00 
-          542                                        0.0  0:00.00  0:00.00 
-          543                                        0.0  0:00.00  0:00.00 
-          544                                        0.0  0:00.00  0:00.00 
-          545                                        0.0  0:00.00  0:00.00 
-          546                                        0.0  0:00.00  0:00.00 
-          547                                        0.0  0:00.00  0:00.00 
-          548                                        0.0  0:00.00  0:00.00 
-          549                                        0.0  0:00.00  0:00.00 
-          550                                        0.0  0:00.00  0:00.00 
-          551                                        0.0  0:00.00  0:00.00 
-          552                                        0.0  0:00.00  0:00.00 
-          553                                        0.0  0:00.00  0:00.00 
-          554                                        0.0  0:00.00  0:00.00 
-          555                                        0.0  0:00.00  0:00.00 
-          556                                        0.0  0:00.00  0:00.00 
-          557                                        0.0  0:00.00  0:00.00 
-          558                                        0.0  0:00.00  0:00.00 
-          559                                        0.0  0:00.00  0:00.00 
-          560                                        0.0  0:00.00  0:00.00 
-          561                                        0.0  0:00.00  0:00.00 
-          562                                        0.0  0:00.00  0:00.00 
-          563                                        0.0  0:00.00  0:00.00 
-          564                                        0.0  0:00.00  0:00.00 
-          565                                        0.0  0:00.00  0:00.00 
-          566                                        0.0  0:00.00  0:00.00 
-          567                                        0.0  0:00.00  0:00.00 
-          568                                        0.0  0:00.00  0:00.00 
-          569                                        0.0  0:00.00  0:00.00 
-          570                                        0.0  0:00.00  0:00.00 
-          571                                        0.0  0:00.00  0:00.00 
-          572                                        0.0  0:00.00  0:00.00 
-          573                                        0.0  0:00.00  0:00.00 
-          574                                        0.0  0:00.00  0:00.00 
-          575                                        0.0  0:00.00  0:00.00 
-          576                                        0.0  0:00.00  0:00.00 
-          577                                        0.0  0:00.00  0:00.00 
-          578                                        0.0  0:00.00  0:00.00 
-          579                                        0.0  0:00.00  0:00.00 
-          580                                        0.0  0:00.00  0:00.00 
-          581                                        0.0  0:00.00  0:00.00 
-          582                                        0.0  0:00.00  0:00.00 
-          583                                        0.0  0:00.00  0:00.00 
-          584                                        0.0  0:00.00  0:00.00 
-          585                                        0.0  0:00.00  0:00.00 
-          586                                        0.0  0:00.00  0:00.00 
-          587                                        0.0  0:00.00  0:00.00 
-          588                                        0.0  0:00.00  0:00.00 
-          589                                        0.0  0:00.00  0:00.00 
-          590                                        0.0  0:00.00  0:00.00 
-          591                                        0.0  0:00.00  0:00.00 
-          592                                        0.0  0:00.00  0:00.00 
-          593                                        0.0  0:00.00  0:00.00 
-          594                                        0.0  0:00.00  0:00.00 
-          595                                        0.0  0:00.00  0:00.00 
-          596                                        0.0  0:00.00  0:00.00 
-          597                                        0.0  0:00.00  0:00.00 
-          598                                        0.0  0:00.00  0:00.00 
-          599                                        0.0  0:00.00  0:00.00 
-          600                                        0.0  0:00.00  0:00.00 
-          601                                        0.0  0:00.00  0:00.00 
-          602                                        0.0  0:00.00  0:00.00 
-          603                                        0.0  0:00.00  0:00.00 
-          604                                        0.0  0:00.00  0:00.00 
-          605                                        0.0  0:00.00  0:00.00 
-          606                                        0.0  0:00.00  0:00.00 
-          607                                        0.0  0:00.00  0:00.00 
-          608                                        0.0  0:00.00  0:00.00 
-          609                                        0.0  0:00.00  0:00.00 
-          610                                        0.0  0:00.00  0:00.00 
-          611                                        0.0  0:00.00  0:00.00 
-          612                                        0.0  0:00.00  0:00.00 
-          613                                        0.0  0:00.00  0:00.00 
-          614                                        0.0  0:00.00  0:00.00 
-          615                                        0.0  0:00.00  0:00.00 
-          616                                        0.0  0:00.00  0:00.00 
-          617                                        0.0  0:00.00  0:00.00 
-          618                                        0.0  0:00.00  0:00.00 
-          619                                        0.0  0:00.00  0:00.00 
-          620                                        0.0  0:00.00  0:00.00 
-          621                                        0.0  0:00.00  0:00.00 
-          622                                        0.0  0:00.00  0:00.00 
-          623                                        0.0  0:00.00  0:00.00 
-          624                                        0.0  0:00.00  0:00.00 
-          625                                        0.0  0:00.00  0:00.00 
-          626                                        0.0  0:00.00  0:00.00 
-          627                                        0.0  0:00.00  0:00.00 
-          628                                        0.0  0:00.00  0:00.00 
-          629                                        0.0  0:00.00  0:00.00 
-          630                                        0.0  0:00.00  0:00.00 
-          631                                       100.3 8:11.86 17:35.07 
-      175        0     3     1     1  6  130M 1.08M  0.0  0:03.06  0:33.84 /hurd/term /dev/ptyp0 pty-master /dev/ttyp0
-            0                                        0.0  0:00.80  0:07.55 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.56  0:05.97 
-            3                                        0.0  0:00.50  0:06.99 
-            4                                        0.0  0:00.56  0:06.99 
-            5                                        0.0  0:00.62  0:06.32 
-      176     1000   173   176   176  2  148M 2.19M  0.0  0:00.08  0:00.54 -bash
-            0                                        0.0  0:00.08  0:00.47 
-            1                                        0.0  0:00.00  0:00.07 
-      284     1000     1   284   284  2 20.5M  700K  0.0  0:00.00  0:00.00 ssh-agent
-            0                                        0.0  0:00.00  0:00.00 
-            1                                        0.0  0:00.00  0:00.00 
-      302     1000   176   302   176  3  148M 1.37M  0.0  0:00.03  0:00.14 screen -S S_main
-            0                                        0.0  0:00.02  0:00.07 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.01  0:00.06 
-      304     1000   302   304   304  3  148M 2.45M  0.0  0:02.86  0:13.03 SCREEN -S S_main
-            0                                        0.0  0:02.86  0:12.97 
-            1                                        0.0  0:00.00  0:00.03 
-            2                                        0.0  0:00.00  0:00.02 
-      305     1000     3     1     1  5  130M  960K  0.0  0:01.57  0:15.62 /hurd/fifo
-            0                                        0.0  0:00.31  0:04.04 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.31  0:03.95 
-            3                                        0.0  0:00.45  0:03.78 
-            4                                        0.0  0:00.49  0:03.84 
-      306        0     3     1     1  5  130M 1.02M  0.0  0:01.42  0:16.72 /hurd/term /dev/ptyp1 pty-master /dev/ttyp1
-            0                                        0.0  0:00.43  0:06.13 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.40  0:04.77 
-            3                                        0.0  0:00.00  0:00.14 
-            4                                        0.0  0:00.59  0:05.67 
-      309     1000   304   309   309  2  148M 2.12M  0.0  0:00.02  0:00.09 /bin/bash
-            0                                        0.0  0:00.02  0:00.09 
-            1                                        0.0  0:00.00  0:00.00 
-      319     1000   309   319   309  2  153M 7.29M  0.0  0:00.33  0:00.74 emacs
-            0                                        0.0  0:00.33  0:00.74 
-            1                                        0.0  0:00.00  0:00.00 
-      320        0     3     1     1  6  130M 1.48M  0.0  0:03.25  0:38.79 /hurd/term /dev/ptyp2 pty-master /dev/ttyp2
-            0                                        0.0  0:00.60  0:07.07 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.69  0:08.43 
-            3                                        0.0  0:00.78  0:07.78 
-            4                                        0.0  0:00.55  0:07.98 
-            5                                        0.0  0:00.60  0:07.52 
-      323     1000   304   323   323  2  148M 2.19M  0.0  0:00.12  0:00.60 /bin/bash
-            0                                        0.0  0:00.12  0:00.54 
-            1                                        0.0  0:00.00  0:00.06 
-      411        0     3     1     1  5  130M 1.02M  0.0  0:01.17  0:16.40 /hurd/term /dev/ptyp3 pty-master /dev/ttyp3
-            0                                        0.0  0:00.42  0:03.74 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.15  0:02.70 
-            3                                        0.0  0:00.24  0:05.48 
-            4                                        0.0  0:00.33  0:04.45 
-      414     1000   304   414   414  2  148M 2.13M  0.0  0:00.05  0:00.23 /bin/bash
-            0                                        0.0  0:00.04  0:00.21 
-            1                                        0.0  0:00.00  0:00.02 
-      425        0     3     1     1  3  130M  872K  0.0  0:00.02  0:00.05 /hurd/proxy-defpager
-            0                                        0.0  0:00.02  0:00.04 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.00  0:00.01 
-     3087        0     3     1     1  5  130M 1.02M  0.0  0:00.23  0:01.39 /hurd/term /dev/ptyp4 pty-master /dev/ttyp4
-            0                                        0.0  0:00.05  0:00.39 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.07  0:00.43 
-            3                                        0.0  0:00.07  0:00.31 
-            4                                        0.0  0:00.04  0:00.26 
-     3648        0     3     1     1  3  130M  876K  0.0  0:00.00  0:00.05 /hurd/crash --kill
-            0                                        0.0  0:00.00  0:00.05 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.00  0:00.00 
-     5512        0     3     1     1  5  130M 1.01M  0.0  0:00.05  0:00.70 /hurd/term /dev/ptyp5 pty-master /dev/ttyp5
-            0                                        0.0  0:00.00  0:00.26 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.03  0:00.16 
-            3                                        0.0  0:00.02  0:00.14 
-            4                                        0.0  0:00.00  0:00.14 
-    10286     1000   323 10286   323  2  135M 1.28M  0.0  0:00.06  0:00.20 make
-            0                                        0.0  0:00.06  0:00.20 
-            1                                        0.0  0:00.00  0:00.00 
-    10287     1000   323 10286   323  2  147M  884K  0.0  0:00.00  0:00.33 tee standard output L_ LC_PAPER=en_US.utf8 LC_ADDRESS=en_US.utf8 SSH_AGENT_PID=284 LC_MONETARY=
-    M=en_US.utf8 SP_REPLACE_LINKS=n SHELL=/bin/bash TERM=screen SP_STOP_AFTER=build HISTSIZE=10000 SSH_CLIENT=192.168.10.60 55972 22 LC_NUMERIC=en_US.utf8 OLDPWD=/home/tsch
-    Mhwinge SSH_TTY=/dev/ttyp0 USER=tschwinge HISTFILESIZE=10000 LD_LIBRARY_PATH= LC_TELEPHONE=en_US.utf8 SP_COMPAT=n LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;
-    M;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=0
-    M01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:
-    M:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35
-    M5:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=0
-    M01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm
-    Mm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.an
-    Mnx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.
-    M.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36: SSH_AUTH_SOCK=/home/tschwinge/.ssh/auth_sock.grubber.bddebian.com TERMCAP=SC|screen|VT 100/ANSI X3.64 virtual terminal
-    Ml:\^K^J:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\^K^J:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\^K^J:do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH
-    MH:up=\EM:\^K^J:le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\^K^J:li#50:co#166:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\^K^J:cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E
-    ME[P:DC=\E[%dP:\^K^J:im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\^K^J:ke=\E[?1l\E>:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\^K^J:ti=\E[?1049h:te=\E[?1049l:us=\E[4m:ue=\E
-    ME[24m:so=\E[3m:\^K^J:se=\E[23m:mb=\E[5m:md=\E[1m:mr=\E[7m:me=\E[m:ms:\^K^J:Co#8:pa#64:AF=\E[3%dm:AB=\E[4%dm:op=\E[39;49m:AX:\^K^J:vb=\Eg:G0:as=\E(0:ae=\E(B:\^K^J:ac=\1
-    M140\140aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~..--++,,hhII00:\^K^J:po=\E[5i:pf=\E[4i:k0=\E[10~:k1=\EOP:k2=\EOQ:k3=\EOR:\^K^J:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E
-    ME[18~:k8=\E[19~:\^K^J:k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:F3=\E[1;2P:\^K^J:F4=\E[1;2Q:F5=\E[1;2R:F6=\E[1;2S:F7=\E[15;2~:\^K^J:F8=\E[17;2~:F9=\E[18;2~:FA=\E[19;2~:k
-    Mkb=\177:K2=\EOE:\^K^J:kB=\E[Z:kF=\E[1;2B:kR=\E[1;2A:*4=\E[3;2~:*7=\E[1;2F:\^K^J:#2=\E[1;2H:#3=\E[2;2~:#4=\E[1;2D:%c=\E[6;2~:%e=\E[5;2~:\^K^J:%i=\E[1;2C:kh=\E[1~:@1=\E[
-    M[1~:kH=\E[4~:@7=\E[4~:\^K^J:kN=\E[6~:kP=\E[5~:kI=\E[2~:kD=\E[3~:ku=\EOA:kd=\EOB:\^K^J:kr=\EOC:kl=\EOD:km: have_bash_profile=y SPF_SOURCE_DEBUG=y PATH=/home/tschwinge/c
-    Mcommand:/home/tschwinge/shared/command:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games MAIL=/var/mail/tschwinge LC_MESSAGES=en_US.utf8 SP_TARDIR=/
-    M/home/tschwinge/tmp/source/package STY=304.S_main LC_COLLATE=C LC_IDENTIFICATION=en_US.utf8 SP_FOREIGN_DIR=/home/tschwinge/shared.old/package/host/schwinge.homeip.net/
-    M/sp-foreign-snippets/snippets PWD=/home/tschwinge/tmp/emacs/trunk.build _LD_LIBRARY_PATH= EDITOR=emacsclient  LANG=en_US.utf8 TZ=Europe/Berlin LC_MEASUREMENT=en_US.utf
-    Mf8 KRB5CCNAME=/tmp/krb5cc.tschwinge HISTCONTROL=ignoreboth HOME=/home/tschwinge SHLVL=2 SPF_COMPAT=n LOGNAME=tschwinge LESS=-M -R CVS_RSH=ssh WINDOW=1 SSH_CONNECTION=1
-    M192.168.10.60 55972 192.168.10.63 22 LC_CTYPE=en_US.utf8 LESSOPEN=| /usr/bin/lesspipe %s EMAIL=thomas@schwinge.name ALTERNATE_EDITOR=joe LC_TIME=en_US.utf8 LESSCLOSE=/
-    M/usr/bin/lesspipe %s %s SPF_SOURCE_DATA_DIR=/home/tschwinge/shared.old/source/package/misc/spf LC_NAME=en_US.utf8 _=/usr/bin/tee
-            0                                        0.0  0:00.00  0:00.33 
-            1                                        0.0  0:00.00  0:00.00 
-    10377     1000 10286 10286   323  2  146M  828K  0.0  0:00.00  0:00.00 /bin/sh -c boot=bootstrap-emacs;                         \^Kif [ ! -x "src/$boot" ]; then      
-    M                                \^K    cd src; make all                                    \^K      CC='gcc' CFLAGS='-g' CPPFLAGS='-DXASSERTS=1'         \^K      LDFLA
-    MAGS='-Wl,-znocombreloc ' MAKE='make' BOOTSTRAPEMACS="$boot"; \^Kfi;
-            0                                        0.0  0:00.00  0:00.00 
-            1                                        0.0  0:00.00  0:00.00 
-    10378     1000 10377 10286   323  2  135M 1.65M  0.0  0:00.71  0:02.12 make all CC=gcc CFLAGS=-g CPPFLAGS=-DXASSERTS=1 LDFLAGS=-Wl,-znocombreloc  MAKE=make BOOTSTRAPE
-    MEMACS=bootstrap-emacs
-            0                                        0.0  0:00.71  0:01.92 
-            1                                        0.0  0:00.00  0:00.19 
-    10770     1000 10378 10286   323  2  146M  852K  0.0  0:00.00  0:00.03 /bin/sh -c if test "no" = "yes"; then \^K  ln -f temacs bootstrap-emacs; \^Kelse \^K  `/bin/pwd
-    Md`/temacs --batch --load loadup bootstrap || exit 1; \^K  mv -f emacs bootstrap-emacs; \^Kfi
-            0                                        0.0  0:00.00  0:00.03 
-            1                                        0.0  0:00.00  0:00.00 
-    10772     1000 10770 10286   323  3  180M 38.8M  0.0  1:16.35  0:05.27 /media/data/home/tschwinge/tmp/emacs/trunk.build/src/temacs --batch --load loadup bootstrap
-            0                                        0.0  1:16.35  0:05.27 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  0:00.00  0:00.00 
-    10778     1000   304   304   304  2  148M  396K  0.0  0:00.00  0:00.00 SCREEN -S S_main
-            0                                        0.0  0:00.00  0:00.00 
-            1                                        0.0  0:00.00  0:00.00 
-    10784        -   160 10784   160  2  146M  672K  0.0  0:00.00  0:00.01 syncfs -s
-            0                                        0.0  0:00.00  0:00.01 
-            1                                        0.0  0:00.00  0:00.00 
-    10785        -   160 10785   160  2  146M  672K  0.0  0:00.00  0:00.02 syncfs -s -c /media/data/
-            0                                        0.0  0:00.00  0:00.02 
-            1                                        0.0  0:00.00  0:00.00 
-    10787        0   160 10787   160  2  146M  876K  0.0  0:00.00  0:00.06 ps -Af
-            0                                        0.0  0:00.00  0:00.06 
-            1                                        0.0  0:00.00  0:00.00 
-    10795        8   131     6     6  2  147M 1.38M  0.1  0:00.02  0:00.04 /usr/lib/nullmailer/qmqp -d -s mail.schwinge.homeip.net
-            0                                        0.1  0:00.02  0:00.04 
-            1                                        0.0  0:00.00  0:00.00 
-    10796        0   160 10796   160  2  146M 1.23M  0.0  0:00.00  0:00.08 ps -F hurd-long -T -M -w -A
-            0                                        0.0  0:00.00  0:00.03 
-            1                                        0.0  0:00.00  0:00.00 
-
-    [4]+  Done                    ps -F hurd-long -T -M -w -A
-    login> 
-
-TH# 631 of PID 174 (which is indeed ext2fs for /media/data) looks very
-suspicious, likely together in combination with TH# 1 of PID 2 (GNU Mach), so
-likely some IPC ping-pong?
-
-      PID TH#  UID  PPID  PGrp  Sess TH  Vmem   RSS %CPU     User   System Args
-        0        0     1     1     1 16  132M    1M  0.0  0:04.84  0:54.84 /hurd/proc
-    [...]
-        2        -     1     1     1  7  418M 19.5M  0.0  0:00.00  0:12.16 root=device:hd0
-            0                                        0.0  0:00.00  0:00.00 
-            1                                       92.6  0:00.00 46:33.66 
-            2                                        0.0  0:00.00  0:12.07 
-            3                                        0.0  0:00.00  0:00.05 
-            4                                        0.0  0:00.00  0:00.02 
-            5                                        0.0  0:00.00  0:00.00 
-            6                                        0.0  0:00.00  0:00.01 
-    [...]
-      174        0     3     1     1 632 2.99G 27.6M 100.3 16:43.18 52:54.41 /hurd/ext2fs /dev/hd2
-            0                                        0.0  0:00.01  0:00.03 
-            1                                        0.0  0:00.00  0:00.00 
-            2                                        0.0  1:34.24  6:26.66 
-            3                                        0.0  0:00.04  0:00.31 
-    [...]
-          630                                        0.0  0:00.00  0:00.00 
-          631                                       100.3 8:11.86 17:35.07 
-    [...]
-
-Attaching GDB hangs.  Should have used noninvasive mode...
-
-Having a look again after an hour or two, GNU Mach's thread 1's (system) time
-count has gone up to nearly 120 minutes, and ext2fs' thread 631's is up to 12
-minutes user and 26 minutes system time.
-
-I was able to get another root shell via plain `ssh root@grubber`, and I'm able
-to attach GDB in noninvasive mode.  Hopefully the first unsuccessful (but still
-running) GDB didn't cause any interference.
-
-Due to differences in [[thread_numbering_of_ps_and_gdb]], GDB's thread 632
-(which is the last one anyways) should be the offending one.  GDB's thread 631
-and earlier ones (manually checked down to 600) are sitting in `mach_msg_trap`.
-
-    (gdb) thread apply 632 bt
-
-    Thread 632 (Thread 174.632):
-    #0  0x010e408c in syscall_vm_allocate () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/syscall_vm_allocate.S:2
-    #1  0x010e423a in __vm_allocate (target_task=1, address=0xbfffbde0, size=65536, anywhere=0)
-	at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/vm_allocate.c:54
-    #2  0x010b023a in alloc_stack (p=0x83774a8) at /home/sthibaul-guest/hurd-debian/./libthreads/stack.c:397
-    #3  0x010ae9b3 in cproc_create () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:724
-    #4  0x010afe5a in cthread_fork (func=0x133ff42, arg=0x0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:341
-    #5  0x010b505d in internal_demuxer (inp=0xbfffdf20, outheadp=0xbfffbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:72
-    #6  0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109
-    #7  0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136
-    #8  0x010b0058 in cthread_body (self=0x8376c50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300
-    #9  0x00000000 in ?? ()
-
-    (gdb) thread apply 632 bt full
-
-    Thread 632 (Thread 174.632):
-    #0  0x010e408c in syscall_vm_allocate () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/syscall_vm_allocate.S:2
-    No locals.
-    #1  0x010e423a in __vm_allocate (target_task=1, address=0xbfffbde0, size=65536, anywhere=0)
-        at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/vm_allocate.c:54
-            err = <value optimized out>
-    #2  0x010b023a in alloc_stack (p=0x83774a8) at /home/sthibaul-guest/hurd-debian/./libthreads/stack.c:397
-            base = 321454080
-    #3  0x010ae9b3 in cproc_create () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:724
-            child = 0x83774a8
-            n = <value optimized out>
-    #4  0x010afe5a in cthread_fork (func=0x133ff42, arg=0x0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:341
-            t = 0x8377430
-    #5  0x010b505d in internal_demuxer (inp=0xbfffdf20, outheadp=0xbfffbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:72
-            status = <value optimized out>
-            pi = 0x0
-            link = {thread = 2050, next = 0x0, prevp = 0x2000, notifies = 0x12, interrupted_next = 0x0}
-            __PRETTY_FUNCTION__ = "internal_demuxer"
-            lock = -1073758644
-            nreqthreads = -1073750240
-            totalthreads = 137852072
-            bucket = 0x10b1c64
-            demuxer = 0x10b01eb <alloc_stack+11>
-    #6  0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109
-            request = 0xbfffdf20
-            reply = 0xbfffbf10
-            mr = 3
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #7  0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136
-            timeout = 0
-            err = <value optimized out>
-            hook = 0
-            global_timeout = 0
-            thread_timeout = 0
-            bucket = 0x805f6c0
-            lock = 0
-            totalthreads = 497
-            nreqthreads = 1
-    #8  0x010b0058 in cthread_body (self=0x8376c50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300
-            t = 0x8376bd8
-    #9  0x00000000 in ?? ()
-    No symbol table info available.
-
-May this simply be an out-of-memory situation where Mach won't / can't satisfy
-libports / libthreads demand?  (Looks like the latter library is currently
-creating a new thread.)  If yes, should the code be prepared for that?  Is it
-perhaps prepared (I did not yet have a look), and re-tries again and again?
-Why doesn't Mach page out some pages to make memory available?
-
-This is stock GNU Mach from Git, no patches, configured for Xen domU usage.
-
-
-# IRC, freenode, #hurd, 2013-10-04
-
-    <pinotree> given you are an emacs user: could you please pick the build
-      patch from deb#725099, recompile emacs24 and test it with your daily
-      work?
-
-
-## IRC, freenode, #hurd, 2013-10-07
-
-    <gnu_srs> Wow! emacs24 runs in X:-D
-    <gnu_srs> pinotree: I've now built and installed emacs 24.3. So far so good
-      ^
-    <pinotree> good, keep testing and stressing
diff --git a/open_issues/error_message_disk_full.mdwn b/open_issues/error_message_disk_full.mdwn
deleted file mode 100644
index f72cd66a..00000000
--- a/open_issues/error_message_disk_full.mdwn
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-IRC, unknown channel, unknown date:
-
-    <antrik> /usr/bin/install: writing `/usr/src/gnumach-20060408.dfsg.1/debian/gnumach-dbg/boot/gnumach': (os/kern) memory error
-    <antrik> interesting way to tell that the disk is full ;-)
diff --git a/open_issues/etc_fstab.mdwn b/open_issues/etc_fstab.mdwn
deleted file mode 100644
index eb2a34f9..00000000
--- a/open_issues/etc_fstab.mdwn
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!meta copyright="Copyright © 2009 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]]."]]"""]]
-
-[[!meta title="/etc/fstab"]]
-
-Even though we don't need a `/etc/fstab` for mounting filesystems
-(passive [[hurd/translator]]s to the rescue; they have problems on their
-own, see the [[hurd/critique]]), we still need this file for `fsck -a`
-and `swapon -a` to function.
-
-[[!tag open_issue_hurd]]
diff --git a/open_issues/exec.mdwn b/open_issues/exec.mdwn
deleted file mode 100644
index 05deaa7a..00000000
--- a/open_issues/exec.mdwn
+++ /dev/null
@@ -1,84 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2013 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_hurd]]
-
-[[!toc]]
-
-
-# IRC, unknown channel, unknown date.
-
-    <youpi> oh my, disabling gzip/bzip2 support makes apt preconfigure hang
-    <youpi> support in exec* I meant
-
-    <youpi> now a funny bug: if I disable gzip/bzip2 support from exec
-    <youpi> trying to run a zero-byte file hangs
-
-Justus: This doesn't seem to be an issue anymore (2013-09-08):
-
-    % touch empty
-    % chmod +x empty
-    % ./empty
-    zsh: exec format error: ./empty
-    % bash
-    $ ./empty
-    $ 
-
-Also I've never encountered a problem with apt.
-
-
-## IRC, freenode, #hurd, 2013-08-01
-
-    <teythoon> uh, all the non trivial exec server code has #ifdef'd BFD code
-      all over it and it looks like that isn't even used anymore
-    <teythoon> that's too bad actually, I figured out how to get the values
-      from BFD, not so for the other elf parser that is used instead
-
-
-## IRC, freenode, #hurd, 2013-08-05
-
-    <teythoon> btw, there is a Debian bug concerning zipped executables. now
-      I'm not sure if I understood the problem, but gziped and bzip2ed
-      executables work for me
-    <teythoon> (not that I'm a big fan of that particular feature)
-    <youpi> iirc these somehow got fixed yes
-    <youpi> something like a previous out of bound access
-    <teythoon> the exec server contains lot's of code that is unused and
-      probably bit rot (#ifdef BFD) or otherwise ignored (#if 0)
-    <youpi> yes :/
-    <teythoon> and there's gunzipping and bunzip2ing, which we probably don't
-      want anyway
-    <pinotree> why not?
-    <teythoon> we should strip all that from exec and start adding features
-    <teythoon> pinotree: b/c it's slow and the gain is questionable
-    <teythoon> it breaks mmapping the code in
-    <teythoon> exec/exec.c is huge (~2300 lines) and complex and it is an
-      essential server
-    <teythoon> and I wonder if the unzipping is done securely, e. g. if it's
-      not possible to crash exec with an maliciously compressed executable
-
-
-## IRC, freenode, #hurd, 2013-09-12
-
-    <rekado> The zip code in hurd/exec/ looks really complicated; does it
-      really just unpack zipped files in memory (which could be replaced by
-      library calls) or is there something else going on?
-    <braunr> rekado:
-      http://lists.gnu.org/archive/html/bug-hurd/2013-08/msg00049.html
-    <rekado> braunr: interesting. Thanks.
-    <rekado> Does this mean that the "small hack entry" on the contributing
-      page to use libz and libbz2 in exec is no longer valid?
-    <braunr> probably
-
----
-
-May want to have a look at using BFD / libiberty/simpleobject.
-
-Justus: The BFD code has been removed from the exec server.
diff --git a/open_issues/exec_memory_leaks.mdwn b/open_issues/exec_memory_leaks.mdwn
deleted file mode 100644
index 1fc5a928..00000000
--- a/open_issues/exec_memory_leaks.mdwn
+++ /dev/null
@@ -1,121 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 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_hurd]]
-
-There are is some memory leak in [[`exec`|hurd/translator/exec]].
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2012-08-11
-
-    <braunr> the exec servers seems to leak a lot
-    <braunr> server*
-    <braunr> exec now uses 109M on darnassus
-    <braunr> it really leaks a lot
-    <pinotree> only 109mb? few months ago, exec on exodar was taking more than
-      200mb after few days of uptime with builds done
-    <braunr> i wonder how much it takes on the buildds
-
-
-## IRC, freenode, #hurd, 2012-08-17
-
-    <braunr> the exec leak is tricky
-    <braunr> bddebian: btw, look at the TODO file in the hurd source code
-    <braunr> bddebian: there is a not from thomas bushnell about that
-    <braunr> "*** Handle dead name notifications on execserver ports. !
-    <braunr> not sure it's still a todo item, but it might be worth checking
-    <bddebian> braunr: diskfs_execboot_class = ports_create_class (0, 0);
-      This is what would need to change right?  It should call some cleanup
-      routine in the first argument?
-    <bddebian> Would be ideal if it could just use deadboot() from exec.
-    <braunr> bddebian: possible
-    <braunr> bddebian: hum execboot, i'm not so sure
-    <bddebian> Execboot is the exec task, no?
-    <braunr> i don't know what execboot is
-    <bddebian> It's from libdiskfs
-    <braunr> but "diskfs_execboot_class" looks like a class of ports used at
-      startup only
-    <braunr> ah
-    <braunr> then it's something run in the diskfs users ?
-    <bddebian> yes
-    <braunr> the leak is in exec
-    <braunr> if clients misbehave, it shouldn't affect that server
-    <bddebian> That's a different issue, this was about the TODO thing 
-    <braunr> ah
-    <braunr> i don't know
-    <bddebian> Me either :)
-    <bddebian> For the leak I'm still focusing on do-bunzip2 but I am baffled
-      at my results..
-    <braunr> ?
-    <bddebian> Where my counters are zero if I always increment on different
-      vars but wild freaking numbers if I increment on malloc and decrement on
-      free
-
-
-# 2012-11-25
-
-After twelve hours worth of `fork/exec` ([[GCC]]'s `check-c` part of the
-testsuite), we got:
-
-      PID  UID  PPID  PGrp  Sess TH  Vmem   RSS %CPU     User   System Args
-        4    0     3     1     1 10  392M  262M  0.0  2:18.29     2hrs /hurd/exec
-
-The *RSS* seems a tad high.  Also the system part of CPU time consumption is
-quite noticeable.  In comparison:
-
-        0    0     1     1     1 19  131M 1.14M  0.0  3:30.25  9:17.79 /hurd/proc
-        3    0     1     1     1 224 405M 12.6M  0.2 42:20.25    67min ext2fs --readonly --multiboot-command-line=root=device:hd0s6 --host-priv-port=1 --device-master-port=2 --exec-server-task=3 -T typed device:hd0s6
-      276    0     3     1     1 344 442M 28.2M  0.6 48:09.36    91min /hurd/ext2fs /dev/hd2s5
-
-
-# 2012-12-20
-
-After running the libtool testsuite for some time:
-
-      PID TH#  UID  PPID  PGrp  Sess TH  Vmem   RSS %CPU     User   System Args
-        4        0     3     1     1 11  334M  203M 60.8  3:19.73     4hrs /hurd/exec
-            0                                        0.0  0:20.33 27:02.47 
-            1                                        0.0  0:31.10 32:21.13 
-            2                                        0.0  0:25.68 27:42.33 
-            3                                        0.0  0:00.00  0:00.00 
-            4                                        5.1  0:34.93 34:07.59 
-            5                                        0.0  0:19.56 28:44.15 
-            6                                        3.4  0:18.73 28:17.89 
-            7                                        0.0  0:20.47 34:42.51 
-            8                                       39.5  0:15.60 28:48.57 
-            9                                        0.0  0:04.49 10:24.12 
-           10                                       12.8  0:08.84 19:34.45 
-
-
-# IRC, freenode, #hurd, 2013-10-08
-
-    * braunr hunting the exec leak
-    <braunr> and i think i found it
-    <braunr> yes :>
-    <braunr> testing a bit more and committing the fix later tonight
-    <braunr> pinotree: i've been building glibc for 40 mins and exec is still
-      consuming around 1m memory
-    <pinotree> wow nice
-    <pinotree> i've been noticing exec leaking quite some time ago, then forgot
-      to pay more attention to that
-    <braunr> it's been more annoying since darnassus provides web access to
-      cgis
-    <braunr> automated tools make requests every seconds
-    <braunr> the leak occurred when starting a shell script or using system()
-    <braunr> youpi: not sure you saw it, i fixed the exec leak
-
-
-## IRC, freenode, #hurd, 2013-10-10
-
-    <gg0> braunr: http://postimg.org/image/jd764wfpp/
-    <braunr> exec 797M
-    <braunr> this should be fixed with the release of the next hurd packages
diff --git a/open_issues/ext2fs_deadlock.mdwn b/open_issues/ext2fs_deadlock.mdwn
deleted file mode 100644
index 23f54a4a..00000000
--- a/open_issues/ext2fs_deadlock.mdwn
+++ /dev/null
@@ -1,54 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2012 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_hurd]]
-
-On 2010-10-26, [[I|tschwinge]]'ve been doing the following: `cp -a
-../tmpdir/dump*.o ./` (65 files), changed my mind, hit `C-c`, continued with
-`cp -a ../tmpdir/dump*.o ./` (to preserve timestamps), wondered why this takes
-so long, hit `C-c` again, then found the FS deadlocked (using no CPU; but
-`syncfs -s -c` wouldn't finish, for example).  Judging from the files'
-timestamps (after rebooting and `fsck`), I would assume that it already hung at
-the second `cp`'s time, and the deadlock thus is not due to the second `C-c`,
-but due to the first one.
-
-    # gdb /hurd/ext2fs
-    [...]
-    (gdb) set noninvasive on
-    (gdb) attach 177
-    [...]
-    [New Thread 177.535]
-    Reading symbols [...]
-    (gdb) info threads
-    [all the same from 177.535 down to...]
-      11 Thread 177.11  0x010e3efc in mach_msg_trap ()
-        at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-      10 Thread 177.10  0x010e3efc in mach_msg_trap ()
-        at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    [doesn't continue with thread 9, but hangs, taking all CPU time]
-
-New GDB instance, again noninvasive, I'm able to continue.
-
-Here are backtraces for threads [[1 to 8|bt_1-8]] and [[10 to 535|bt_10-535]],
-I didn't succeed to get any information about thread 9 (which thus would
-probably be the most interesting one...) -- GDB would always hang when
-accessing it, no matter whether noninvasive mode or not.  (Didn't have time to
-pull the information out of the process' memory manually (how to do that,
-anyways?), and also didn't have time to continue with debugging GDB itself, but
-this sounds like a [[!taglink open_issue_gdb]]...)
-
-
-# IRC, freenode, #hurd, 2010-10-27
-
-    <youpi> thread 8 hung on ports_begin_rpc
-    <youpi> that's probably where one could investigated first
-    <youpi> yes, a lot of threads are hung on that
-    <tschwinge> You mean 0x10b9488, right?
-    <youpi> yes
diff --git a/open_issues/ext2fs_dtime.mdwn b/open_issues/ext2fs_dtime.mdwn
deleted file mode 100644
index 592f1525..00000000
--- a/open_issues/ext2fs_dtime.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2012 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_hurd]]
-
-    /dev/hd0s1: Deleted inode 95849 has zero dtime.  FIXED.
-
-This is actually sorta benign.  What typically happens is that one upgrades e.g.
-a library, and there are still some processes using it (e.g. because it's libc).
-The library file is thus kept on the filesystem, so as to be able to load parts
-of it on demand.  The file is thus marked as deleted, but the deletion hasn't
-been effective yet, thus dtime being zero. e2fsck notices this and finishes
-deleting the file.  To really fix this, we would probably have to really unmount
-the filesystem.
diff --git a/open_issues/ext2fs_libports_reference_counting_assertion.mdwn b/open_issues/ext2fs_libports_reference_counting_assertion.mdwn
deleted file mode 100644
index 2b9f28e8..00000000
--- a/open_issues/ext2fs_libports_reference_counting_assertion.mdwn
+++ /dev/null
@@ -1,111 +0,0 @@
-[[!meta copyright="Copyright © 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_hurd]]
-
-    libports/port-ref.c:31: ports_port_ref: Assertion `pi->refcnt || pi->weakrefcnt' failed
-
-This is seen every now and then.
-
-
-# [[gnumach_page_cache_policy]]
-
-With that patch in place, the assertion failure is seen more often.
-
-
-## IRC, freenode, #hurd, 2012-07-14
-
-    <youpi> braunr: I'm getting ext2fs.static:
-      /usr/src/hurd-debian/./libports/port-ref.c:31: ports_port_ref: Assertion
-      `pi->refcnt || pi->weakrefcnt' failed.
-    <youpi> oddly enough, that happens on one of the buildds only
-    <braunr> :/
-    <braunr> i fear the patch can wake many of these issues
-
-
-## IRC, freenode, #hurd, 2012-07-15
-
-    <youpi> braunr: same assertion failed on a second buildd
-    <braunr> can you paste it again please ?
-    <youpi> ext2fs.static: /usr/src/hurd-debian/./libports/port-ref.c:31:
-      ports_port_ref: Assertion `pi->refcnt || pi->weakrefcnt' failed.
-    <braunr> or better, answer the ml thread for future reference
-    <braunr> thanks
-    <youpi> braunr: I can't keep your patch on the buildds, it makes them too
-      unreliable
-    <braunr> youpi: ok
-    <braunr> i never got this error though, that's weird
-    <braunr> youpi: was the failure during the same build ?
-    <youpi> no, it was during package installation, and not the same
-    <youpi> braunr: note that I've already seen such errors, it's not new, but
-      it was way rarer
-    <youpi> like every month only
-    <braunr> ah ok
-    <braunr> yes it's less surprising then
-    <braunr> a tricky reference counting / locking mistake somewhere in the
-      hurd :) ...
-    <braunr> ah ! just got it !
-    <bddebian> braunr: Got the error or found the problem? :)
-    <braunr> the former unfortunately :/
-
-
-## IRC, freenode, #hurd, 2012-07-19
-
-    <braunr> hm, i think those ext2fs port refs errors may also be due to stack
-      overflows
-    <pinotree> --verbose
-    <braunr> hm ?
-    <braunr> http://lists.gnu.org/archive/html/bug-hurd/2012-07/msg00051.html
-    <pinotree> i mean, why do you think they could be due to that?
-    <braunr> the error is that both strong and weak refs in a port are 0 when
-      adding a reference
-    <braunr> weak refs are almost never used so let's forget about them
-    <braunr> when a ref count drops to 0, the port is automatically deallocated
-    <braunr> so what other than memory corruption setting this counter to 0
-      could possibly do that ? :)
-    <pinotree> one could also guess an unbalanced ref/unref logic, somehow
-    <braunr> what do you mean ?
-    <pinotree> that for a bug, an early return, etc a port gets unref'ed often
-      than it is ref'ed
-    <braunr> highly unlikely, as they're protected by a lock
-    <braunr> pinotree: ah you mean, the object gets deallocated early because
-      of an deref overflow ?
-    <braunr> pinotree: could be, yes
-    <braunr> pinotree: i wonder if it could happen because of the periodic sync
-      duplicating the node table without holding references
-    <braunr> rah, libports uses a big lock in many places :(
-    <pinotree> braunr: yes, i meant that
-    <braunr> we could try using libduma some day
-    <braunr> i wonder if it could work out of the box
-    <pinotree> but that wouldn't help to find out whether a port gets deref'ed
-      too often, for instance
-    <pinotree> although it could be adapted to do so, i guess
-    <braunr> reproducing + a call trace or core would be best, but i'm not even
-      sure we can get that easily lol
-
-[[automatic_backtraces_when_assertions_hit]].
-
-
-# IRC, freenode, #hurd, 2013-10-09
-
-    <braunr> mhmm, i may have an explanation for the weird assertions we
-      sometimes see in ext2fs
-    <braunr> glibc uses alloca to reserve memory for one reply port per thread
-      in abort_all_rpcs
-    <braunr> if this erases the thread-specific area, we can expect all kinds
-      of wreckage
-    <braunr> i'm not sure how to fix this though
-
-
-# IRC, freenode, #hurd, 2014-01-29
-
-    <gg0> ext2fs: ../../libports/port-ref.c:30: ports_port_ref: Assertion
-      `pi->refcnt || pi->weakrefcnt' failed.
diff --git a/open_issues/ext2fs_page_cache_swapping_leak.mdwn b/open_issues/ext2fs_page_cache_swapping_leak.mdwn
deleted file mode 100644
index 81915492..00000000
--- a/open_issues/ext2fs_page_cache_swapping_leak.mdwn
+++ /dev/null
@@ -1,361 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012, 2013 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_gnumach open_issue_hurd]]
-
-There is a [[!FF_project 272]][[!tag bounty]] on this task.
-
-[[!toc]]
-
-
-# IRC, OFTC, #debian-hurd, 2011-03-24
-
-    <youpi> I still believe we have an ext2fs page cache swapping leak, however
-    <youpi> as the 1.8GiB swap was full, yet the ld process was only 1.5GiB big
-    <pinotree> a leak at swapping time, you mean?
-    <youpi> I mean the ext2fs page cache being swapped out instead of simply
-      dropped
-    <pinotree> ah
-    <pinotree> so the swap tends to accumulate unuseful stuff, i see
-    <youpi> yes
-    <youpi> the disk content, basicallyt :)
-
-
-# IRC, freenode, #hurd, 2011-04-18
-
-    <antrik> damn, a cp -a simply gobbles down swap space...
-    <braunr> really ?
-    <braunr> that's weird
-    <braunr> why would a copy use so much anonymous memory ?
-    <braunr> unless the external pager is so busy that the kernel falls back to
-      its default pager
-    <youpi> that's what I suggested some time ago
-    <braunr> maybe this case should be traced in the kernel
-    <braunr> a simple message in the kernel buffer to warn that this condition
-      happened may help
-    <youpi> I'm seeing swap space being kept used on buildds for no real reason
-      except possibly backing ext2fs pages
-    <youpi> that could help, yes
-    <antrik> youpi: I think it was actually slpz who suggested that...
-    <youpi> I think we're generally missing feedback from memory behavior
-    <antrik> youpi: do you think andrei's kernel instrumentation work might be
-      helpful with analyzing such things?
-    <youpi> antrik: I think I suggested it too, but never mind
-    <youpi> antrik: no, because it's not a trace of events that you want
-    <youpi> some specific events would be useful
-    <youpi> but then we don't really need a whole framework for that
-    <antrik> apt-get upgrade eats swap too
-    <youpi> the upgrade itself, or the computation of the ugprade?
-    <youpi> apt is a memory eater nowadays
-    <antrik> installing the packages
-    <antrik> seems to have stabilized though after a while...
-    <antrik> so perhaps it's not a leak in this case
-    <youpi> ideally we should have a way to know what was put in the swap
-    <braunr> how would you represent what's in the swap ?
-    <antrik> the apt-get process has 46M of virtual memory above the 128 M
-      baseline
-    <braunr> mostly libraries i guess
-    <braunr> are trheads stacks 8 MiB like on Linux ?
-    <youpi> braunr: at least knowing how much of each process is in the swap
-    <youpi> braunr: 2MiB
-    <braunr> ok
-    <youpi> vminfo could also report which parts of the address space are in
-      the swap
-    <antrik> youpi: would be nice to have some simple utility reporting how
-      much of a process' address space is anonymous
-    <antrik> (in fact, I wonder why it's not reported by standard tools such as
-      ps or top... this shouldn't be too difficult I would think?)
-    <antrik> it would be much more useful information than the total virt size,
-      which includes rather meaningless disk and device mappings...
-    <youpi> agreed
-    <braunr> well
-    <braunr> there are tools like pmap for this
-    <braunr> unfortunately, it's difficult in mach to know what backs a
-      non-anonymous mapping
-    <braunr> pagers should be able to name their mappings
-    <youpi> that'd be helpful for debugging yes
-    <braunr> there is almost no overhead in doing that, and it would be very
-      useful
-    <youpi> and could lead to /proc/pid/maps
-    <braunr> yes
-    <braunr> isn't there a maps already ?
-    <youpi> nope
-    <braunr> ok
-    <youpi> (probably not very useful without the names)
-    <braunr>  ithought i remembered maps without names, and guessed it might
-      have been on the hurd for that reason
-    <braunr> but i'm not sure
-    <youpi> there's the vminfo command, yes
-    <braunr> 14:06 < youpi> braunr: at least knowing how much of each process
-      is in the swap
-    <braunr> wouldn't it be clearer to do it the other way around ?
-    <braunr> like a swapinfo tool indicating what it contains ?
-    <youpi> sure, but it's a lot more difficult
-    <braunr> really ?
-    <braunr> why ?
-    <youpi> because you have to traverse all the mappings
-    <youpi> etc
-    <youpi> (in all processes, I mean)
-    <youpi> and you have to name what is waht
-    <braunr> there are other ways
-    <braunr> the swap is a central structure
-    <youpi> while simply introducing the swap %  in vminfo
-    <youpi> for a given process you know what is what
-    <braunr> right
-    <youpi> and doing that introduction is  probably very simple
-    <braunr> that's a good point
-    <braunr> top-down is effectively easier than bottom-up resolution in Mach
-      VM
-    <antrik> hm... the memory use caused by cp doesn't seem to be reflected in
-      the virtual size of any particular process
-    <antrik> ghost memory
-    <braunr> what's cp vmsize at the time of the problem ?
-    <antrik> it's at 134 M right now... so considering the 128 M baseline,
-      nothing worth speaking of
-    <braunr> right
-    <braunr> maybe a copy map during I/O
-    <braunr> but I don't know Mach copy maps in detail, as they have been
-      eliminated from UVM
-    <antrik> BTW, the memory eatup happens even before swap comes into
-      play... swapping seems to be a result of the problem, not the cause
-    <braunr> what do you mean ?
-    <braunr> I thought swapping was the issue
-    <braunr> you mean RAM is full before swapping ?
-    <antrik> well, I don't know what the actual problem is... I just don't
-      understand why the memory use increases without any particular process
-      seeing an increase in size
-    <antrik> the "free" size in vmstat decreses
-    <antrik> once it's eatun up, swap space use increases
-    <braunr> well it doesn't change much of it
-    <braunr> the anonymous memory pager will use RAM before resorting to the
-      external default-pager
-    <antrik> I would suspect normal block caching... but then, shouldn't this
-      show up in the memory info of the ext2 process?
-    <braunr> although, again, I'm not sure of the behaviour of the anonymous
-      memory pager
-    <braunr> antrik: I don't know how block caching behaves
-    <antrik> BTW, is it a know problem that doing ^C on a "cp -a" seems to hang
-      the whole system?...
-    <antrik> (the whole hurd instance that is... the other instance is not
-      affected)
-    <youpi> not that I know of
-    <braunr> seems like a deadlock in the anonymous memory handling
-    <youpi> (and I've never seen that)
-    <antrik> happens both in my main system (using ancient hurd/libc) and in my
-      subhurd (recently upgraded to current stuff)
-    <antrik> this make testing this stuff quite a lot harder... [sigh]
-    <antrik> any suggestions how to debug this hang?
-    <braunr> antrik: no :/
-
-2011-04-28: [[!taglink open_issue_documentation]]
-
-    <antrik> hm... is it normal that "swap free" doesn't increase as a process'
-      memory is paged back in?
-    <youpi> yes
-    <youpi> there's no real use cleaning swap
-    <youpi> on the contrary, it makes paging the process out again longer
-    <antrik> hm... so essentially, after swapping back and forth a bit, a part
-      of the swap equal to the size of physical RAM will be occupied with stuff
-      that is actually in RAM?
-    <youpi> yes
-    <youpi> so that that RAM can be freed immediately if needed
-    <antrik> hm... that means my effective swap size is only like 300 MB... no
-      wonder I see crashes under load
-    <antrik> err... make that 230 actually
-    <antrik> indeed, quitting the application freed both the physical RAM and
-      swap space
-    <braunr> 02:28 < antrik> hm... is it normal that "swap free" doesn't
-      increase as a process' memory is paged back in?
-    <braunr> swap is the backing store of anonymous memory, like ext2fs is the
-      backing store of memory objects created from its pager
-    <braunr> so you can view swap as the file system for everything that isn't
-      an external memory object
-
-
-# IRC, freenode, #hurd, 2011-11-15
-
-    <braunr> hm, now my system got unstable
-    <braunr> swap is increasing, without any apparent reason
-    <antrik> you mean without any load?
-    <braunr> with load, yes
-    <braunr> :)
-    <antrik> well, with load is "normal"...
-    <antrik> at least for some loads
-    <braunr> i can't create memory pressure to stress reclaiming without any
-      load
-    <antrik> what load are you using?
-    <braunr> ftp mirrorring
-    <antrik> hm... never tried that; but I guess it's similar to apt-get
-    <antrik> so yes, that's "normal". I talked about it several times, and also
-      wrote to the ML
-    <braunr> antrik: ok
-    <antrik> if you find out how to fix this, you are my hero ;-)
-    <braunr> arg :)
-    <antrik> I suspect it's the infamous double swapping problem; but that's
-      just a guess
-    <braunr> looks like this
-    <antrik> BTW, if you give me the exact command, I could check if I see it
-      too
-    <braunr> i use lftp (mirror -Re) from a linux git repository
-    <braunr> through sftp
-    <braunr> (lots of small files, big content)
-    <antrik> can't you just give me the exact command? I don't feel like
-      figuring it out myself
-    <braunr> antrik: cd linux-stable; lftp sftp://hurd_addr/
-    <braunr> inside lftp: mkdir linux-stable; cd linux-stable; mirror -Re
-    <braunr> hm, half of physical memory just got freed
-    <braunr> our page cache is really weird :/
-    <braunr> (i didn't delete any file when that happened)
-    <antrik> hurd_addr?
-    <braunr> ssh server ip address
-    <braunr> or name
-    <braunr> of your hurd :)
-    <antrik> I'm confused. you are mirroring *from* the Hurd box?
-    <braunr> no, to it
-    <antrik> ah, so you login via sftp and then push to it?
-    <braunr> yes
-    <braunr> fragmentation looks very fine
-    <braunr> even for the huge pv_entry cache and its 60k+ entries
-    <braunr> (and i'm running a kernel with the cpu layer enabled)
-    <braunr> git reset/status/diff/log/grep all work correctly
-    <braunr> anyway, mcsim's branch looks quite stable to me
-    <antrik> braunr: I can't reproduce the swap leak with ftp. free memory
-      idles around 6.5 k (seems to be the threshold where paging starts), and
-      swap use is constant
-    <antrik> might be because everything swappable is already present in swap
-      from previous load I guess...
-    <antrik> err... scratch that. was connected to the wrong host, silly me
-    <antrik> indeed swap gets eaten away, as expected
-    <antrik> but only if free memory actually falls below the
-      threshold. otherwise it just oscillates around a constant value, and
-      never touches swap
-    <antrik> so this seems to confirm the double swapping theory
-    <youpi> antrik: is that "double swap" theory written somewhere?
-    <youpi> (no, a quick google didn't tell me)
-
-
-## IRC, freenode, #hurd, 2011-11-16
-
-    <antrik> youpi:
-      http://lists.gnu.org/archive/html/l4-hurd/2002-06/msg00001.html talks
-      about "double paging". probably it's also the term others used for it;
-      however, the term is generally used in a completely different meaning, so
-      I guess it's not really suitable for googling either ;-)
-    <antrik> IIRC slpz (or perhaps someone else?) proposed a solution to this,
-      but I don't remember any details
-    <youpi> ok so it's the same thing I was thinking about with swap getting
-      filled
-    <youpi> my question was: is there something to release the double swap,
-      once the ext2fs pager managed to recover?
-    <antrik> apparently not
-    <antrik> the only way to free the memory seems to be terminating the FS
-      server
-    <youpi> uh :/
-
-
-# IRC, freenode, #hurd, 2011-11-30
-
-    <antrik> slpz: basically, whenever free memory goes below the paging
-      threshold (which seems to be around 6 MiB) while there is other I/O
-      happening, swap usage begins to increase continuously; and only gets
-      freed again when the filesystem translator in question exits
-    <antrik> so it sounds *very* much like pages go to swap because the
-      filesystem isn't quick enough to properly page them out
-    <antrik> slpz: I think it was you who talked about double paging a while
-      back?
-    <slpz> antrik: probably, sounds like me :-)
-    <antrik> slpz: I have some indication that the degenerating performance and
-      ultimate hang issues I'm seeing are partially or entirely caused by
-      double paging...
-    <antrik> slpz: I don't remember, did you propose some possible fix?
-    <slpz> antrik: hmm... perhaps it wasn't me, because I don't remember trying
-      to fix that problem...
-    <slpz> antrik: at which point do you think pages get duplicated?
-    <antrik> slpz: it was a question. I don't remember whether you proposed
-      something or not :-)
-    <antrik> slpz: basically, whenever free memory goes below the paging
-      threshold (which seems to be around 6 MiB) while there is other I/O
-      happening, swap usage begins to increase continuously; and only gets
-      freed again when the filesystem translator in question exits
-    <antrik> so it sounds *very* much like pages go to swap because the
-      filesystem isn't quick enough to properly page them out
-    <slpz> antrik: I see
-    <slpz> antrik: I didn't addressed this problem directly, but when I've
-      modified the pageout mechanism to provide a special treatment for
-      external pages, I also removed the possibility of sending them to the
-      default pager
-    <slpz> antrik: this was in my experimental environment, of course
-    <antrik> slpz: oh, nice... so it may fix the issues I'm seeing? :-)
-    <antrik> anything testable yet?
-    <slpz> antrik: yes, only anonymous memory could be swapped with that
-    <slpz> antrik: it works, but is ugly as hell
-    <antrik> tschwinge: these is also your observation about compilations
-      getting slower on further runs, and my followups... I *suspect* it's the
-      same issue
-
-[[performance/degradation]].
-
-    <slpz> antrik: I'm thinking about establishing a repository for these
-      experimental versions, so they don't get lost with the time
-    <antrik> slpz: please do :-)
-    <slpz> antrik: perhaps in savannah's HARD project
-    <antrik> even if it's not ready for upstream, it would be nice if I could
-      test it -- right now it's bothering me more than any other Hurd issues I
-      think...
-    <slpz> also, there's another problem which causes performance degradation
-      with the simple use of the system
-    <tschwinge> slpz: Please just push to Savannah Hurd.  Under your
-      slpz/... or similar.
-    <tschwinge> antrik: Might very well be, yes.
-    <slpz> and I almost sure it is the fragmentation of the task map
-    <slpz> tschwinge: ok
-    <slpz> after playing a bit with a translator, it can easily get more than
-      3000 entries in its map
-    <antrik> slpz: yeah, other issues might play a role here as well. I
-      observed that terminating the problematic FS servers does free most of
-      the memory and remove most of the performance degradation, but in some
-      cases it's still very slow
-    <slpz> that makes vm_map_lookup a lot slower
-    <antrik> on a related note: any idea what can cause paging errors and a
-      system hang even when there is plenty of free swap?
-    <antrik> (I'm not entirely sure, but my impression is that it *might* be
-      related to the swap usage and performance degradation problems)
-    <slpz> I think this degree of fragmentation has something to do with the
-      reiterative mapping of memory objects which is done in pager-memcpy.c
-    <slpz> antrik: which kind of paging errors?
-    <antrik> hm... I don't think I ever noted down the exact message; but I
-      think it's the same you get when actually running out of swap
-    <slpz> antrik: that could be the default pager dying for some internal bug
-    <antrik> well, but it *seems* to go along with the performance degradation
-      and/or swap usage
-    <slpz> I also have the impression that we're using memory objects the wrong
-      way
-    <antrik> basically, once I get to a certain level of swap use and slowness
-      (after about a month of use), the system eventually dies
-    <slpz> antrik: I never had a system running for that time, so it could be a
-      completely different problem from what I've seen before :-/
-    <slpz> Anybody has experience with block-level caches on microkernel
-      environments?
-    <antrik> slpz: yeah, it typically happens after about a month of my normal
-      use... but I can significantly accellerate it by putting some problematic
-      load on it, such as large apt-get runs...
-    <slpz> I wonder if it would be better to put them in kernel or in user
-      space. And in the latter, if it would be better to have one per-device
-      shared for all accesing translators, or just each task should have its
-      own cache...
-    <antrik> slpz:
-      http://lists.gnu.org/archive/html/bug-hurd/2011-09/msg00041.html is where
-      I described the issue(s)
-    <antrik> (should send another update for the most recent findings I
-      guess...)
-    <antrik> slpz: well, if we move to userspace drivers, the kernel part of
-      the question is already answered ;-)
-    <antrik> but I'm not sure about per-device cache vs. caching in FS server
diff --git a/open_issues/extern_inline.mdwn b/open_issues/extern_inline.mdwn
deleted file mode 100644
index a3a22b16..00000000
--- a/open_issues/extern_inline.mdwn
+++ /dev/null
@@ -1,109 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2012 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_hurd]]
-
-[[!toc]]
-
-
-# IRC, unknown channel, unknown date
-
-    <tschwinge> youpi: Did you ever review the Savannah hurd branch master-fix_extern_inline?
-    <youpi> why static inlines instead of extern lines ?
-    <youpi> +in
-    <youpi> static inlines can lead to space waste where it isn't inlined
-    <tschwinge> Are you sure about that -- I don't think so.
-    <tschwinge> At least with 99 inlining.
-    <youpi> what can the compiler do where it isn't inlined ?
-    <youpi> include a copy
-    <youpi> thus space waste
-    <youpi> 00000000004004b1 t f
-    <youpi> 00000000004004d5 t f
-    <youpi> I've juste checked
-    <youpi> two copies of my inline function
-    <youpi> one per .o
-    <tschwinge> Yes, but isn't it expected tobe that way?  ARen't these functions those that are never included in a libarary, as opposed to those which I switched to __extern_inline in the next patch?
-    <tschwinge> It's been a long time that I had a look at this...
-    <tschwinge> The problem with the patch from the Debian package is that the functions didn't end up in the libraries anymore.
-    <youpi> ah you mean these are private functions and thus shouldn't be exposed (unexpected_reply for instance)
-    <youpi> but the duplication issue still holds
-    <youpi> the functions not ending up in the library is a concern indeed
-    <tschwinge> That's what my second patch fixes, I think.
-    <youpi> grah, callisto rebooted for no reason
-    <youpi> ah, indeed the second patch fixes things correctly
-    <youpi> uh, indeed it's --dbg-package=hurd in there
-    <youpi> how odd
-    <youpi> tschwinge: for the libftpconn case, yes unexpected_reply should probably be a static inline
-    <tschwinge> Is this true:
-    <tschwinge> static inline -- either inline or emit a local symbol vs. extern inline -- either inline or emit a reference to an external symbol.
-    <youpi> so as to not expose it
-    <youpi> for other cases we can keep an extern inline as they are just programs
-    <tschwinge> Then everything that's not expected to end up in a libarary must be static inline, as otherwise, when the compiler can't inline, there wouldn't be a reference to it available.
-    <youpi> and that avoids duplicate code
-    <youpi> yes
-    <youpi> but as long as you provide the extern inlines by compiling an xinl.c there's no problem
-    <tschwinge> Sure, that'd be the alternative.
-    <youpi> for libraries you need to take care of the symbols you want to export (which can thus be in xinl.c), and those you don't want to export (and thus keep static inlines)
-    <tschwinge> So you say it'd be better to do that (xinl.c) instead of static inline?
-    <youpi> for programs, you can just keep them all extern inlines
-    <youpi> yes, it shares code
-    <youpi> it's only in the case of symbols that shouldn't be exported by the library that we need to use static inlines
-    <tschwinge> ANd in .c files that are part of programs I'd also use extern inline or static inline?
-    <youpi> for programs just always use extern lines
-    <youpi> +in
-    <youpi> as you don't care about symbol exposure
-    <youpi> unless the inline is defined in a .c file of course, in that case it's useless to make it extern
-    <tschwinge> But then I also always need xinl.c files for those, which we apparently don't have in a few places.
-    <youpi> yes
-    <tschwinge> But probably didn't notice so far, as the functions could always be inlined.
-    <youpi> probably because we used to have luck
-    <youpi> yes
-    <tschwinge> Yes, I was thinking about the term/munge.c thing.
-    <tschwinge> OK, I think I get it now.  Then I'll try to fix this accordingly.
-    <tschwinge> But not now.  Thanks for the help!
-    <youpi> ok, thanks
-    <tschwinge> It was quite a bit confusing to me.
-    <tschwinge> Due to the mostly reversed definition of extern inline in glibc (I think).
-    <youpi> inline definitely is confusing
-    <youpi> especially since the semantic has changed over time and according to standards :)
-    <tschwinge> And then GCC changing that according to C99.
-    <tschwinge> Yes.
-
-
-# IRC, freenode, #hurd, 2012-03-14
-
-    <youpi>
-      http://anonscm.debian.org/gitweb/?p=pkg-hurd/hurd.git;a=blob;f=debian/patches/extern_inline_fix.patch;h=b9eacbff97dc56e99a69ddb601a5fc948f6e44a7;hb=HEAD
-    <youpi> maybe review it, and then we apply it
-    <pinotree>
-      http://patch-tracker.debian.org/patch/series/view/hurd/20120222-1/extern_inline_fix.patch
-      ;)
-    <civodul> youpi: the #ifdef __USE_EXTERN_INLINES in there and the extra
-      "extern" decls look wrong to me
-    <youpi> iirc USE_EXTERN_INLINES is needed
-    <youpi> otherwise it's not compliant
-    <youpi> or maybe it's for -O0
-    <youpi> anyway IIRC it's needed
-    <civodul> when !defined __USE_EXTERN_INLINES, you end up with extern decls
-      with no corresponding definition
-    <youpi> yes
-    <youpi> they are defined in the code
-    <civodul> where?
-    <youpi> there's a special .c file in each lib
-    <youpi> libdiskfs/extern-inline.c
-    <youpi> etc
-    <civodul> oooh, right
-    <youpi> extern inline means that anyway
-    <youpi> the compiler is allowed to not always inline
-    <civodul> yes
-    <civodul> that looks good to me, then
-    <civodul> youpi: can you apply it, with proper authorship & co.?
-    <civodul> (no rush, though)
-    <youpi> sure
diff --git a/open_issues/faccessat.mdwn b/open_issues/faccessat.mdwn
deleted file mode 100644
index 911acbb6..00000000
--- a/open_issues/faccessat.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-[[!meta copyright="Copyright © 2012 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]]
-
-`faccessat()` fails on some cases; in particular when:
-
-* flags does not have `AT_EACCESS`
-* dirfd is not `AT_FDCWD`
-* pathname is not an absolute path
-
-In such case, it will return -1 setting `ENOTSUP` as errno.
-
-[[faccessat.c]]
diff --git a/open_issues/fakeroot_eagain.mdwn b/open_issues/fakeroot_eagain.mdwn
deleted file mode 100644
index 168ddf7d..00000000
--- a/open_issues/fakeroot_eagain.mdwn
+++ /dev/null
@@ -1,216 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 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_porting]]
-
-
-# IRC, freenode, #hurd, 2012-12-05
-
-    <braunr> rbraun   18813 R        2hrs ln -sf ../af_ZA/LC_NUMERIC
-      debian/locales-all/usr/lib/locale/en_BW/LC_NUMERIC
-    <braunr> when building glibc
-    <braunr> is this a known issue ?
-    <tschwinge> braunr: No.  Can you get a backtrace?
-    <braunr> tschwinge: with gdb you mean ?
-    <tschwinge> Yes.  If you have any debugging symbols (glibc?).
-    <braunr> or the build log leading to that ?
-    <braunr> ok, i will next time i have it
-    <tschwinge> OK.
-    <braunr> (i regularly had it when working on the pthreads port)
-    <braunr> tschwinge:
-      http://www.sceen.net/~rbraun/hurd_glibc_build_deadlock_trace
-    <braunr> youpi: ^
-    <youpi> Mmm, there's not so much we can do about this one
-    <braunr> youpi: what do you mean ?
-    <youpi> the problem is that it's really a reentrency issue of the libc
-      locale
-    <youpi> it would happen just the same on linux
-    <braunr> sure
-    <braunr> but hat doesn't mean we can't report and/or fix it :)
-    <youpi> (the _nl_state_lock)
-    <braunr> do you have any workaround in mind ?
-    <youpi> no
-    <youpi> actually that's what I meant by "there's not so much we can do
-      about this"
-    <braunr> ok
-    <youpi> because it's a bad interaction between libfakeroot and glibc
-    <youpi> glibc believe fxtstat64 would never call locale functions
-    <youpi> but with libfakeroot it does
-    <braunr> i see
-    <youpi> only because we get an EAGAIN here
-    <braunr> but hm, doesn't it happen on linux ?
-    <youpi> EAGAIN doesn't happen on linux for fxstat64, no :)
-    <braunr> why does it happen on the hurd ?
-    <youpi> I mean for fakeroot stuff
-    <youpi> probably because fakeroot uses socket functions
-    <youpi> for which we probably don't properly handleEAGAIN
-    <youpi> I've already seen such kind of issue
-    <youpi> in buildd failures
-    <braunr> ok
-    <youpi> (so the actual bug here is EAGAIN
-    <youpi> )
-    <braunr> yes, so we can do something about it
-    <braunr> worth a look
-    <pinotree> (implement sysv semaphores)
-    <youpi> pinotree: if we could also solve all these buildd EAGAIN issues
-      that'd be nice :)
-    <braunr> that EAGAIN error might also be what makes exim behave badly and
-      loop forever
-    <youpi> possibly
-    <braunr> i've updated the trace with debugging symbols
-    <braunr> it fails on connect
-    <pinotree> like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563342 ?
-    <braunr> it's EAGAIN, not ECONNREFUSED
-    <pinotree> ah ok
-    <braunr> might be an error in tcp_v4_get_port
-
-
-## IRC, freenode, #hurd, 2012-12-06
-
-    <braunr> hmm, tcp_v4_get_port sometimes fails indeed
-    <gnu_srs> braunr: may I ask how you found out, adding print statements in
-      pfinet, or?
-    <braunr> yes
-    <gnu_srs> OK, so that's the only (easy) way to debug.
-    <braunr> that's the last resort
-    <braunr> gdb is easy too
-    <braunr> i could have added a breakpoint too
-    <braunr> but i didn't want to block pfinet while i was away
-    <braunr> is it possible to force the use of fakeroot-tcp on linux ?
-    <braunr> the problem seems to be that fakeroot doesn't close the sockets
-      that it connected to faked-tcp
-    <braunr> which, at some point, exhauts the port space
-    <pinotree> braunr: sure
-    <pinotree> change the fakeroot dpkg alternative
-    <braunr> ok
-    <pinotree> calling it explicitly `fakeroot-tcp command` or
-      `dpkg-buildpackage -rfakeroot-tcp ...` should work too
-    <braunr> fakeroot-tcp looks really evil :p
-    <braunr> hum, i don't see any faked-tcp process on linux :/
-    <pinotree> not even with `fakeroot-tcp bash -c "sleep 10"`?
-    <braunr> pinotree: now yes
-    <braunr> but, does it mean faked-tcp is started for *each* process loading
-      fakeroot-tcp ?
-    <braunr> (the lib i mean)
-    <pinotree> i think so
-    <braunr> well the hurd doesn't seem to do that at all
-    <braunr> or maybe it does and i don't see it
-    <braunr> the stale faked-tcp processes could be those that failed something
-      only
-    <pinotree> yes, there's also that issue: sometimes there are stake
-      faked-tcp processes
-    <braunr> hum no, i see one faked-tcp that consumes cpu when building glibc
-    <pinotree> *stale
-    <braunr> it's the same process for all commands
-    <pinotree> <braunr> but, does it mean faked-tcp is started for *each*
-      process loading fakeroot-tcp ?
-    <pinotree> → everytime you start fakeroot, there's a new faked-xxx for it
-    <braunr> it doesn't look that way
-    <braunr> again, on the hurd, i see one faked-tcp, consuming cpu while
-      building so i assume it services libfakeroot-tcp requests
-    <pinotree> yes
-    <braunr> which means i probably won't reproduce the problem on linux
-    <pinotree> it serves that fakeroot under which the binary(-arch) target is
-      run
-    <braunr> or perhaps it's the normal fakeroot-tcp behaviour on sid
-    <braunr> pinotree: a faked-tcp that is started for each command invocation
-      will implicitely make the network stack close all its sockets when
-      exiting
-    <braunr> pinotree: as our fakeroot-tcp uses the same instance of faked-tcp,
-      it's a lot more likely to exhaust the port space
-    <pinotree> i see
-    <braunr> i'll try on sid and see how it behaves
-    <braunr> pinotree: on the other hand, forking so many processes at each
-      command invocation may make exec leak a lot :p
-    <braunr> or rather, a lot more
-    <braunr> (or maybe not, since it leaks only in some cases)
-
-[[exec_memory_leaks]].
-
-    <braunr> pinotree: actually, the behaviour under linux is the same with the
-      alternative correctly set, whereas faked-tcp is restarted (if used at
-      all) with -rfakeroot-tcp
-    <braunr> hm no, even that isn't true
-    <braunr> grr
-    <braunr> pinotree: i think i found a handy workaround for fakeroot
-    <braunr> pinotree: the range of local ports in our networking stack is a
-      lot more limited than what is configured in current systems
-    <braunr> by extending it, i can now build glibc \o/
-    <pinotree> braunr: what are the current ours and the usual one?
-    <braunr> see pfinet/linux-src/net/ipv4/tcp_ipv4.c
-    <braunr> the modern ones are the ones suggested in the comment
-    <braunr> sysctl_local_port_range is the symbol storing the range
-    <pinotree> i see
-    <pinotree> what's the current range on linux?
-    <braunr> 20:44 < braunr> the modern ones are the ones suggested in the
-      comment
-    <pinotree> i see
-    <braunr> $ cat /proc/sys/net/ipv4/ip_local_port_range 
-    <braunr> 32768   61000
-    <braunr> so, i'm not sure why we have the problem, since even on linux,
-      netstat doesn't show open bound ports, but it does help
-    <braunr> the fact faked-tcp can remain after its use is more problematic
-    <pinotree> (maybe pfinet could grow a (startup-only?) option to change it,
-      similar to that sysctl)
-    <braunr> but it can also stems from the same issue gnu_srs found about
-      closed sockets that haven't been shut down
-    <braunr> perhaps
-    <braunr> but i don't see the point actually
-    <braunr> we could simply change the values in the code
-
-    <braunr> youpi: first, in pfinet, i increased the range of local ports to
-      reduce the likeliness of port space exhaustion
-    <braunr> so we should get a lot less EAGAIN after that
-    <braunr> (i've not committed any of those changes)
-    <youpi> range of local ports?
-    <braunr> see pfinet/linux-src/net/ipv4/tcp_ipv4.c, tcp_v4_get_port function
-      and sysctl_local_port_range array
-    <youpi> oh
-    <braunr> EAGAIN is caused by tcp_v4_get_port failing at
-    <braunr>                 /* Exhausted local port range during search? */
-    <braunr>                 if (remaining <= 0)
-    <braunr>                         goto fail;
-    <youpi> interesting
-    <youpi> so it's not a hurd bug after all
-    <youpi> just a problem in fakeroot eating a lot of ports
-    <braunr> maybe because of the same issue gnu_srs worked on (bad socket
-      close when no clean shutdown)
-    <braunr> maybe, maybe not
-    <braunr> but increasing the range is effective
-    <braunr> and i compared with what linux does today, which is exactly what
-      is in the comment above sysctl_local_port_range
-    <braunr> so it looks safe
-    <youpi> so that means that the pfinet just uses ports 1024- 4999 for
-      auto-allocated ports?
-    <braunr> i guess so
-    <youpi> the linux pfinet I meant
-    <braunr> i haven't checked the whole code but it looks that way
-    <youpi> ./sysctl_net_ipv4.c:static int ip_local_port_range_min[] = { 1, 1
-      };
-    <youpi> ./sysctl_net_ipv4.c:static int ip_local_port_range_max[] = { 65535,
-      65535 };
-    <youpi> looks like they have increased it since then :)
-    <braunr> hum :)
-    <braunr> $ cat /proc/sys/net/ipv4/ip_local_port_range 
-    <braunr> 32768   61000
-    <youpi> yep, same here
-    <youpi> ./inet_connection_sock.c:	.range = { 32768, 61000 },
-    <youpi> so there are two things apparently
-    <youpi> but linux now defaults to 32k-61k
-    <youpi> braunr: please just push the port range upgrade to 32Ki-61K
-    <braunr> ok, will do
-    <youpi> there's not reason not to do it
-
-
-## IRC, freenode, #hurd, 2012-12-11
-
-    <braunr> youpi: at least, i haven't had any failure building eglibc since
-      the port range patch
-    <youpi> good :)
diff --git a/open_issues/fakeroot_exit_0.mdwn b/open_issues/fakeroot_exit_0.mdwn
deleted file mode 100644
index c6075b17..00000000
--- a/open_issues/fakeroot_exit_0.mdwn
+++ /dev/null
@@ -1,35 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-    $ fakeroot ./scripts/mkinstalldirs /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/debian/tmp-libc/usr/include
-    [...]
-    + LD_LIBRARY_PATH=/usr/lib/libfakeroot:/usr/lib64/libfakeroot:/usr/lib32/libfakeroot
-    + LD_PRELOAD=libfakeroot-tcp.so
-    + ./scripts/mkinstalldirs /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/debian/tmp-libc/usr/include
-    libfakeroot: connect: Interrupted system call
-    + RESULT=0
-    
-    exit $RESULT
-    + exit 0
-    kill -s HUP 23612
-    + kill -s HUP 23612
-
-(The `EINTR` issue has been [[!debbug desc="fixed" 641200]].)
-
-`connect() < 0` invokes `fail()` which invokes `exit(1)`.  Not yet figured out
-why the process exits 0 dispite that.  `LD_PRELOAD` issue?  ([[!taglink
-open_issue_glibc]].)
-
-
-# Build
-
-`libacl1-dev` is missing.
-
-    $ DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -uc -b -d
diff --git a/open_issues/fcntl_F_SETFL_FD.mdwn b/open_issues/fcntl_F_SETFL_FD.mdwn
deleted file mode 100644
index 4d270250..00000000
--- a/open_issues/fcntl_F_SETFL_FD.mdwn
+++ /dev/null
@@ -1,26 +0,0 @@
-[[!meta copyright="Copyright © 2012 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]]."]]"""]]
-
-[[!meta title="fcntl.*F_SETFL.*FD_.*"]]
-
-[[!tag open_issue_porting]]
-
-
-# IRC, OFTC, #debian-hurd, 2012-12-16
-
-    <pinotree> http://lists.debian.org/<50CE505F.3040106@pyro.eu.org>
-    <pinotree> or http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679198#123
-      too
-    <youpi> ouch, there are quite a few!
-    <pinotree> most are "duplicated", like the source in webkit2 copies (so
-      fixing it once upstream will make it fixed progressively once the copies
-      are upgraded)
-    <youpi> ah, ok
-    <pinotree> similar for ruby 1.8/1.9/jruby
diff --git a/open_issues/fcntl_locking_dev_null.mdwn b/open_issues/fcntl_locking_dev_null.mdwn
deleted file mode 100644
index 4c65a5c4..00000000
--- a/open_issues/fcntl_locking_dev_null.mdwn
+++ /dev/null
@@ -1,38 +0,0 @@
-[[!meta copyright="Copyright © 2012 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]]."]]"""]]
-
-[[!meta title="fcntl locking /dev/null"]]
-
-[[!tag open_issue_hurd]]
-
-
-# IRC, OFTC, #debian-hurd, 2012-07-06
-
-    <pinotree> regarding the libwibble failure (which holds libbuffy →
-      libbuffy-bindings), the failing test happens because it logs to /dev/null
-      as test file,
-    <pinotree> and while doing that, it wants to lock it first, having a
-      ENOTSUP in return
-    <youpi> oh
-    <youpi> locking null, how interesting
-    <youpi> what is that supposed to do ? :o)
-    <pinotree> from what i was reading posix, it would seem that such object is
-      considered a "File"
-    <youpi> is it our unimplemented record lock, or just the lock operation
-      that /dev/null doesn't support ?
-    <youpi> what size is null supposed to be? zero, right?
-    <pinotree> the latter
-    <youpi> ah
-    <youpi> so we can simply make lock return 0
-    <youpi> since there's no byte to lock?
-    <youpi> I don't remember whether you can lock unexistant bytes
-    <pinotree> indeed, if i change the libwibble unit test to use eg /tmp/foo,
-      they pas
-    <pinotree> s
diff --git a/open_issues/fdisk.mdwn b/open_issues/fdisk.mdwn
deleted file mode 100644
index ece8fc89..00000000
--- a/open_issues/fdisk.mdwn
+++ /dev/null
@@ -1,19 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-    Command (m for help): w
-    The partition table has been altered!
-    
-    Calling ioctl() to re-read partition table.
-    *Segmentation fault*
-    
-Changes have been saved, though.
-
-Perhaps realted to the [[BLKRRPART_IOCTL]]?
diff --git a/open_issues/fifo_O_RDWR.mdwn b/open_issues/fifo_O_RDWR.mdwn
deleted file mode 100644
index 730e5c6f..00000000
--- a/open_issues/fifo_O_RDWR.mdwn
+++ /dev/null
@@ -1,25 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-[[!meta title="fifo O_RDWR"]]
-
-[[!tag open_issue_hurd]]
-
-[[!debbug 646016]]
-
-IRC, OFTC, #debian-hurd, 2011-10-19:
-
-    <tschwinge> pinotree: Nice!  And that open(FIFO, O_RDWR) hanging issue may
-      warrant investigation on the Hurd side, too -- if the other systems
-      behave differently, we should probably have convincing reasons for our
-      behavior.
-    <pinotree> i gue somebody working on hurd never cared about that case - i
-      guess it falls back to one of O_RDONLY or O_WRONLY
-    <pinotree> *guess
diff --git a/open_issues/fifo_thread_explosion.mdwn b/open_issues/fifo_thread_explosion.mdwn
deleted file mode 100644
index 08f682f2..00000000
--- a/open_issues/fifo_thread_explosion.mdwn
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!meta copyright="Copyright © 2012 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_hurd]]
-
-As reported in [[!message-id "87sj80yb3e.fsf@kepler.schwinge.homeip.net"]],
-after a [[GCC]] build (native, so three stages bootstrap), we got:
-
-  PID  UID  PPID  PGrp  Sess TH  Vmem   RSS %CPU     User   System Args
-  449 1000     3     1     1 10118 782M 198M 0.0  0:40.78  2:26.65 /hurd/fifo
-
-The other processes, in particular two instances of ext2fs and one of [[exec]],
-looked reasonable.
diff --git a/open_issues/file_locking.mdwn b/open_issues/file_locking.mdwn
deleted file mode 100644
index 7dfbdb94..00000000
--- a/open_issues/file_locking.mdwn
+++ /dev/null
@@ -1,98 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 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_hurd open_issue_glibc]]
-
-[[!toc]]
-
-
-# Google Summer of Code Project Idea
-
-[[community/gsoc/project_ideas/File_Locking]].
-
-
-# visudo
-
-[[visudo]].
-
-
-# Existing Work
-
-[[!GNU_Savannah_patch 332]].
-
-
-# IRC, freenode, #hurd, 2010-12-31
-
-    <pinotree> youpi: i found the issue with python-apt
-    <pinotree> s/with/of/
-    <youpi> good!
-    <pinotree> lock file issue, though :/
-    <youpi> :/
-    <pinotree> this is the sample test case, derived from apt's code:
-      http://paste.debian.net/103536/
-    <pinotree> basically, it seems asking for a file lock in the same process
-      where there's already such lock on the file, fails
-    <pinotree> youpi: ↑
-    <youpi> uh, posix doesn't even define some nesting
-    <pinotree> it seems it just talks about concurrency with other processes
-    <youpi> posix tells more about it later
-    <youpi> saying that if a lock already exists, then it is replaced by the
-      new
-    <youpi> (when inside the same process)
-    <pinotree> yay, found a bug in hurd :p
-    <youpi> well, actually it's known
-    <youpi> i.e. setlk is completely bogus, based on flock
-    <youpi> and flock doesn't have the same semantic in that regard
-    <youpi> so we can't fix it without really implementing setlk
-    <pinotree> the XXX comment in glibc/sysdeps/mach/hurd/fcntl.c, by chance?
-      :)
-    <youpi> of course :)
-    <pinotree> youpi: hm, flock's man page says:
-    <pinotree> "A process may only hold one type of lock (shared or exclusive)
-      on a file. Subsequent flock() calls on an already locked file will
-      convert an existing lock to the new lock mode."
-    <pinotree> so a new lock in the same process over the original lock should
-      replace the old one?
-    <youpi> uh, that's not what I had seen
-    <pinotree> http://linux.die.net/man/2/flock
-    <youpi> An attempt to lock the file using one of these file  descrip-
-    <youpi>        tors  may  be  denied  by  a  lock that the calling process
-      has already
-    <youpi>        placed via another descriptor.
-    <youpi> so it's really not that easy
-    <pinotree> that's in case of trying to create a lock on a file with a
-      different fd than the existing lock
-    <youpi> that's what your testcase does
-    <pinotree> which, hm, is python-apt's case
-    <youpi> that being said, the sentence I pasted does not seem to appear in
-      posix
-    <pinotree> flock() does not seem posix
-    <youpi> it may have been the behavior of Linux at some point in the past
-    <youpi> it's not , but F_SETLK is
-    <youpi> and in linux world, flock <=> F_SETLK, iirc
-    <youpi> in glibc world, even
-    <youpi> (just checked it, see sysdeps/posix/flock.c
-    <youpi> pinotree: I guess your testcase works on Linux?
-    <pinotree> which means we should get a proper F_SETLK working, and then
-      just use this flock version (instead of the custom one), no?
-    <pinotree> yes, it works on linux (and on kfreebsd, see that python-apt
-      builds)
-    <youpi> no, I mean our flock() should probably be happy with locking part
-      of a file several times
-    <youpi> (that is, hurd's file_lock() RPC)
-    <youpi> ah, no, on Linux flock is its own system call
-    <youpi> (which is independant from lockf from the locking point of view,
-      iirc)
-
-
-# 2014-03-11
-
-[[!message-id "1394523876.28244.11.camel@workhorse-peter-baumgarten-com"]].
diff --git a/open_issues/file_system_exerciser.mdwn b/open_issues/file_system_exerciser.mdwn
deleted file mode 100644
index f8cca6a1..00000000
--- a/open_issues/file_system_exerciser.mdwn
+++ /dev/null
@@ -1,31 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012, 2013 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_hurd]]
-
-Test our file system implementations with the [File System
-Exerciser](http://codemonkey.org.uk/projects/fsx/).  See [[tmpfs
-discussion|hurd/translator/tmpfs/discussion]], and on [[Maksym_Planeta]].
-
-
-# Alternatives
-
-## fs_mark
-
-### IRC, freenode, #hurd, 2012-04-30
-
-    <pinotree> mcsim: http://sourceforge.net/projects/fsmark/
-    <pinotree> mcsim: just saw it in debian's NEW queue and from the
-      description it seemed like something it could be helpful for you
-    <pinotree> (and in general to test fs'es)
-
-
-## [[VFAT_Test_Suite]]
diff --git a/open_issues/fork_deadlock.mdwn b/open_issues/fork_deadlock.mdwn
deleted file mode 100644
index 08e53330..00000000
--- a/open_issues/fork_deadlock.mdwn
+++ /dev/null
@@ -1,3566 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 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]]
-
-This started appearing when Jérémie's [[glibc]] signal patches were integrated:
-very sporadically, but still now and then, `fork` will hang, as follows, and
-typically in `/bin/sh`.
-
-# I
-
-    depbase=`echo ptr_chck.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
-            /bin/dash ./libtool --tag=CC   --mode=compile [...]/gcc/xgcc [...] [...]/boehm-gc/ptr_chck.c &&\
-            mv -f $depbase.Tpo $depbase.Plo
-
-      PID  UID  PPID  PGrp  Sess TH  Vmem   RSS %CPU     User   System Args
-     9754 1000  9746  1695   480  2  134M 1.35M  0.0  0:00.05  0:00.04 make AR_FLAGS=rc CC_FOR_BUILD=gcc-4.6 CFLAGS=[...]
-    10174 1000  9754  1695   480  2  146M  876K  0.0  0:00.00  0:00.00 /bin/dash -c depbase=`echo ptr_chck.lo | sed [...]
-    10175 1000 10174  1695   480  2  146M  608K  0.0  0:00.00  0:00.00 /bin/dash -c depbase=`echo ptr_chck.lo | sed [...]
-    10177 1000 10175  1695   480  2  146M  204K 96.0  0:50.97    71min /bin/dash -c depbase=`echo ptr_chck.lo | sed [...]
-
-
-## 10174
-
-    Thread 2 (Thread 10174.2):
-    #0  0x0105b7cc in mach_msg_trap () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0105bfc9 in __mach_msg (msg=0x1221f90, option=3, send_size=32, rcv_size=4096, rcv_name=104, timeout=0, notify=0) at msg.c:110
-            ret = <optimized out>
-    #2  0x0105c6f9 in __mach_msg_server_timeout (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=104, option=0, timeout=0)
-        at msgserver.c:151
-            request = 0x1222fa0
-            reply = 0x1221f90
-            mr = <optimized out>
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #3  0x0105c7cb in __mach_msg_server (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=104) at msgserver.c:196
-    No locals.
-    #4  0x0106cecf in _hurd_msgport_receive () at msgportdemux.c:68
-    No locals.
-    #5  0x66688b92 in ?? ()
-    No symbol table info available.
-    
-    Thread 1 (Thread 10174.1):
-    #0  0x01078a5c in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:134
-            err = <optimized out>
-            err = <optimized out>
-            user_option = 3
-            user_timeout = 0
-            m = 0x1023f34
-            msgh_bits = 5395
-            remote_port = 110
-            msgid = 21001
-            __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg"
-    #1  0x012091a5 in __io_read (io_object=110, data=0x1024840, dataCnt=0x1024844, offset=-1, amount=128)
-        at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/hurd/RPC_io_read.c:137
-            Mess = {In = {Head = {msgh_bits = 5395, msgh_size = 0, msgh_remote_port = 110, msgh_local_port = 107, msgh_seqno = 0, 
-                  msgh_id = 21001}, offsetType = {msgt_name = 11, msgt_size = 64, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, 
-                  msgt_deallocate = 0, msgt_unused = 0}, offset = -1, amountType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, 
-                  msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, amount = 128}, Out = {Head = {msgh_bits = 5395, 
-                  msgh_size = 0, msgh_remote_port = 110, msgh_local_port = 107, msgh_seqno = 0, msgh_id = 21001}, RetCodeType = {msgt_name = 11, 
-                  msgt_size = 64, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, RetCode = -1, 
-                dataType = {msgtl_header = {msgt_name = 255, msgt_size = 255, msgt_number = 4095, msgt_inline = 1, msgt_longform = 1, 
-                    msgt_deallocate = 1, msgt_unused = 1}, msgtl_name = 8194, msgtl_size = 4097, msgtl_number = 128}, 
-                data = '\000' <repeats 812 times>, "\021 \001\020o\000\000\000\364O\035\001\000\000\000\000\300B\002\001\070<\006\001\030\000\000\000/H\002\001\000\000\000\000\000\000\000\000TC\002\001XC\002\001\224G\002\001\020C\002\001\275\340\005\001\030\000\000\000p\337\005\001\224G\002\001XC\002\001\001", '\000' <repeats 11 times>, " W \001\030\000\000\000\271\314B\002\001\351\n\002\004\000\000\000\\\244!\001\220K\b\001\000\000\000\000\364O\035\001dG\002\001\b\240!\001pG\002\001\336>\006\001p\337\005\001\020\306\a\001 W \001\001\000\000\000XC\002\001\000\000\000\000\000\000\000\000\224G\002\001\000\000\000\000\000\000\000\000\224G\002\001\000\000\000\000\000\000\000\000/H\002\001 W \001\001", '\000' <repeats 403 times>"\330"...}}
-            msg_result = <optimized out>
-            msgh_size = <optimized out>
-    #2  0x0107d321 in readfd (port=110) at fd-read.c:34
-            nbytes = 0x0
-            nread = 0
-            data = 0x0
-            offset = 0
-    #3  0x01083880 in _hurd_ctty_input (port=110, ctty=0, rpc=0x102484c) at ctty-input.c:32
-            err = <optimized out>
-    #4  0x0107cd44 in _hurd_fd_read (fd=0x1218e88, buf=0x1024914, offset=-1) at fd-read.c:39
-            __ulink = {resource = {next = 0x0, prevp = 0x1218e8c}, thread = {next = 0x0, prevp = 0x121a45c}, 
-              cleanup = 0x1084b90 <_hurd_port_cleanup>, cleanup_data = 0x6e}
-            __ctty_ulink = {resource = {next = 0x1024880, prevp = 0x107c794}, thread = {next = 0x121a008, prevp = 0x70}, cleanup = 0x10471c4, 
-              cleanup_data = 0x102db28}
-            ctty = 0
-            crit = <optimized out>
-            __result = 16927684
-            port = 110
-            err = <optimized out>
-            data = 0x1024914 "\004"
-            nbytes = 0x10248e8
-            nread = 128
-    #5  0x01141652 in __libc_read (fd=3, buf=0x1024914, nbytes=128) at ../sysdeps/mach/hurd/read.c:27
-            descriptor = <error reading variable descriptor (DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.)>
-            err = <optimized out>
-    #6  0x0804f53b in ?? ()
-    No symbol table info available.
-    #7  0x0804f772 in ?? ()
-    No symbol table info available.
-    #8  0x0804c26c in ?? ()
-    No symbol table info available.
-    #9  0x0804b589 in ?? ()
-    No symbol table info available.
-    #10 0x0804b61e in ?? ()
-    No symbol table info available.
-    #11 0x0804bf31 in ?? ()
-    No symbol table info available.
-    #12 0x08049b3f in ?? ()
-    No symbol table info available.
-    #13 0x0108666b in __libc_start_main (main=0x8049a90, argc=3, ubp_av=0x1024bb4, init=0x80597b0, fini=0x80597a0, rtld_fini=0xf5c0, 
-        stack_end=0x1024bac) at libc-start.c:257
-            result = <optimized out>
-    #14 0x08049c95 in ?? ()
-    No symbol table info available.
-
-
-## 10175
-
-    Thread 2 (Thread 10175.2):
-    #0  0x0105b7cc in mach_msg_trap () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0105bfc9 in __mach_msg (msg=0x1221f90, option=3, send_size=32, rcv_size=4096, rcv_name=104, timeout=0, notify=0) at msg.c:110
-            ret = <optimized out>
-    #2  0x0105c6f9 in __mach_msg_server_timeout (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=104, option=0, timeout=0)
-        at msgserver.c:151
-            request = 0x1222fa0
-            reply = 0x1221f90
-            mr = <optimized out>
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #3  0x0105c7cb in __mach_msg_server (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=104) at msgserver.c:196
-    No locals.
-    #4  0x0106cecf in _hurd_msgport_receive () at msgportdemux.c:68
-    No locals.
-    #5  0x66688b92 in ?? ()
-    No symbol table info available.
-    #6  0x00000000 in ?? ()
-    No symbol table info available.
-    
-    Thread 1 (Thread 10175.1):
-    #0  0x01078a5c in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:134
-            err = <optimized out>
-            err = <optimized out>
-            user_option = 3
-            user_timeout = 0
-            m = 0x1024638
-            msgh_bits = 5395
-            remote_port = 27
-            msgid = 24020
-            __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg"
-    #1  0x011f99df in __proc_wait (process=27, pid=-1, options=0, status=0x10247f4, sigcode=0x102476c, rusage=0x1024708, pid_status=0x1024770)
-        at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/hurd/RPC_proc_wait.c:182
-            Mess = {In = {Head = {msgh_bits = 5395, msgh_size = 132, msgh_remote_port = 27, msgh_local_port = 107, msgh_seqno = 0, 
-                  msgh_id = 24020}, pidType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, 
-                  msgt_deallocate = 0, msgt_unused = 0}, pid = -1, optionsType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, 
-                  msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, options = 0}, Out = {Head = {msgh_bits = 5395, msgh_size = 132, 
-                  msgh_remote_port = 27, msgh_local_port = 107, msgh_seqno = 0, msgh_id = 24020}, RetCodeType = {msgt_name = 2, msgt_size = 32, 
-                  msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, RetCode = -1, statusType = {
-                  msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, 
-                status = 0, sigcodeType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, 
-                  msgt_deallocate = 0, msgt_unused = 0}, sigcode = 0, rusageType = {msgt_name = 2, msgt_size = 32, msgt_number = 18, 
-                  msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, rusage = {ru_utime = {tv_sec = 0, tv_usec = 0}, 
-                  ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, ru_minflt = 0, ru_majflt = 0, 
-                  ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}, 
-                pid_statusType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, 
-                  msgt_unused = 0}, pid_status = 17243652}}
-            msg_result = <optimized out>
-            msgh_size = <optimized out>
-    #2  0x0110e49e in __wait4 (pid=-1, stat_loc=0x10247f4, options=0, usage=0x1024708) at ../sysdeps/mach/hurd/wait4.c:35
-            __p = 0x1219fac
-            __link = {resource = {next = 0x0, prevp = 0x1219fb0}, thread = {next = 0x0, prevp = 0x121a45c}, 
-              cleanup = 0x1084b90 <_hurd_port_cleanup>, cleanup_data = 0x1b}
-            port = 27
-            __result = <optimized out>
-            dead = <optimized out>
-            err = <optimized out>
-            ignored = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, 
-              ru_isrss = 0, ru_minflt = 0, ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, 
-              ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}
-            sigcode = 0
-            dummy = 16926356
-    #3  0x0110e2c7 in __wait3 (stat_loc=..., options=0, usage=0x0) at ../sysdeps/unix/bsd/bsd4.4/wait3.c:34
-    No locals.
-    #4  0x080509f2 in ?? ()
-    No symbol table info available.
-    #5  0x080519dc in ?? ()
-    No symbol table info available.
-    #6  0x0804b9f6 in ?? ()
-    No symbol table info available.
-    #7  0x0804b589 in ?? ()
-    No symbol table info available.
-    #8  0x0804c83f in ?? ()
-    No symbol table info available.
-    #9  0x0804f4e6 in ?? ()
-    No symbol table info available.
-    #10 0x0804f772 in ?? ()
-    No symbol table info available.
-    #11 0x0804c26c in ?? ()
-    No symbol table info available.
-    #12 0x0804b589 in ?? ()
-    No symbol table info available.
-    #13 0x0804b61e in ?? ()
-    No symbol table info available.
-    #14 0x0804bf31 in ?? ()
-    No symbol table info available.
-    #15 0x08049b3f in ?? ()
-    No symbol table info available.
-    #16 0x0108666b in __libc_start_main (main=0x8049a90, argc=3, ubp_av=0x1024bb4, init=0x80597b0, fini=0x80597a0, rtld_fini=0xf5c0, 
-        stack_end=0x1024bac) at libc-start.c:257
-            result = <optimized out>
-    #17 0x08049c95 in ?? ()
-    No symbol table info available.
-
-
-## 10177
-
-    Thread 2 (Thread 10177.2):
-    #0  0x0105b7cc in mach_msg_trap () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0105bfc9 in __mach_msg (msg=0x1221f90, option=3, send_size=32, rcv_size=4096, rcv_name=104, timeout=0, notify=0) at msg.c:110
-            ret = <optimized out>
-    #2  0x0105c6f9 in __mach_msg_server_timeout (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=104, option=0, timeout=0)
-        at msgserver.c:151
-            request = 0x1222fa0
-            reply = 0x1221f90
-            mr = <optimized out>
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #3  0x0105c7cb in __mach_msg_server (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=104) at msgserver.c:196
-    No locals.
-    #4  0x0106cecf in _hurd_msgport_receive () at msgportdemux.c:68
-    No locals.
-    #5  0x66688b92 in ?? ()
-    No symbol table info available.
-    #6  0x00000000 in ?? ()
-    No symbol table info available.
-    
-    Thread 1 (Thread 10177.1):
-    #0  0x0105b81c in swtch_pri () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2
-    No locals.
-    #1  0x0105d0a4 in __spin_lock_solid (lock=0x121a80c) at spin-solid.c:27
-    No locals.
-    #2  0x01071e57 in __spin_lock (__lock=<optimized out>) at ../mach/lock-intern.h:55
-    No locals.
-    #3  _hurd_sigstate_lock (ss=0x121a008) at hurdsig.c:172
-    No locals.
-    #4  0x0110f51c in _hurd_critical_section_unlock (our_lock=<optimized out>) at ../hurd/hurd/signal.h:235
-    No locals.
-    #5  __fork () at ../sysdeps/mach/hurd/fork.c:707
-            env = {{__jmpbuf = {18698228, 18976712, 134622020, 16926728, 16926356, 17887007}, __mask_was_saved = 0, __saved_mask = 4294967295}}
-            pid = 0
-            err = <optimized out>
-            __PRETTY_FUNCTION__ = "__fork"
-            ss = 0x121a008
-            threads = 0x0
-            nthreads = 0
-            stopped = 1
-            i = 6
-    #6  0x08051704 in ?? ()
-    No symbol table info available.
-    #7  0x0804b92c in ?? ()
-    No symbol table info available.
-    #8  0x0804b589 in ?? ()
-    No symbol table info available.
-    #9  0x0804c83f in ?? ()
-    No symbol table info available.
-    #10 0x0804f4e6 in ?? ()
-    No symbol table info available.
-    #11 0x0804f772 in ?? ()
-    No symbol table info available.
-    #12 0x0804c26c in ?? ()
-    No symbol table info available.
-    #13 0x0804b589 in ?? ()
-    No symbol table info available.
-    #14 0x0804b61e in ?? ()
-    No symbol table info available.
-    #15 0x0804bf31 in ?? ()
-    No symbol table info available.
-    #16 0x08049b3f in ?? ()
-    No symbol table info available.
-    #17 0x0108666b in __libc_start_main (main=0x8049a90, argc=3, ubp_av=0x1024bb4, init=0x80597b0, fini=0x80597a0, rtld_fini=0xf5c0, 
-        stack_end=0x1024bac) at libc-start.c:257
-            result = <optimized out>
-    #18 0x08049c95 in ?? ()
-    No symbol table info available.
-
-
-# II
-
-Rebuilt the dash package locally with `DEB_BUILD_OPTIONS=nostrip`.
-
-      PID  UID  PPID  PGrp  Sess TH  Vmem   RSS %CPU     User   System Args
-    22711 1000 22687  1698   453  2  134M 18.1M  0.0  0:02.78  0:07.81 make DESTDIR= RPATH_ENVVAR=LD_LIBRARY_PATH TARGET_SUBDIR=i686-unknown-gnu0.3 
-    24924    0     3     1     1  3  130M  912K  0.0  0:00.00  0:00.00 /hurd/proxy-defpager
-    26541 1000 22711  1698   453  2  146M  896K  0.0  0:00.00  0:00.00 /bin/dash -c if [ -d ../prev-gcc ]; then \^K  cd ../prev-gcc && \^K  make rea
-    26554 1000 26541  1698   453  2  146M 1.42M  0.0  0:00.34  0:02.73 /bin/dash ./fixinc.sh /usr/include
-    28134 1000 26554  1698   453  2  146M  284K 94.9  0:27.18    76min /bin/dash ./fixinc.sh /usr/include
-
-
-## 26541
-
-    Thread 2 (Thread 26541.2):
-    #0  0x0105b7cc in mach_msg_trap () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0105bfc9 in __mach_msg (msg=0x1221f90, option=3, send_size=32, rcv_size=4096, rcv_name=105, timeout=0, notify=0) at msg.c:110
-            ret = <optimized out>
-    #2  0x0105c6f9 in __mach_msg_server_timeout (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=105, option=0, timeout=0)
-        at msgserver.c:151
-            request = 0x1222fa0
-            reply = 0x1221f90
-            mr = <optimized out>
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #3  0x0105c7cb in __mach_msg_server (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=105) at msgserver.c:196
-    No locals.
-    #4  0x0106cecf in _hurd_msgport_receive () at msgportdemux.c:68
-    No locals.
-    #5  0x66688b92 in ?? ()
-    No symbol table info available.
-    
-    Thread 1 (Thread 26541.1):
-    #0  0x01078a5c in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:134
-            err = <optimized out>
-            err = <optimized out>
-            user_option = 3
-            user_timeout = 0
-            m = 0x1024708
-            msgh_bits = 5395
-            remote_port = 27
-            msgid = 24020
-            __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg"
-    #1  0x011f99df in __proc_wait (process=27, pid=-1, options=0, status=0x1024890, sigcode=0x102483c, rusage=0x10247d8, pid_status=0x1024840)
-        at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/hurd/RPC_proc_wait.c:182
-            Mess = {In = {Head = {msgh_bits = 5395, msgh_size = 0, msgh_remote_port = 27, msgh_local_port = 101, msgh_seqno = 0, msgh_id = 24020}, 
-                pidType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, 
-                  msgt_unused = 0}, pid = -1, optionsType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, 
-                  msgt_deallocate = 0, msgt_unused = 0}, options = 0}, Out = {Head = {msgh_bits = 5395, msgh_size = 0, msgh_remote_port = 27, 
-                  msgh_local_port = 101, msgh_seqno = 0, msgh_id = 24020}, RetCodeType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, 
-                  msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, RetCode = -1, statusType = {msgt_name = 2, 
-                  msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, status = 0, 
-                sigcodeType = {msgt_name = 0, msgt_size = 0, msgt_number = 0, msgt_inline = 0, msgt_longform = 0, msgt_deallocate = 0, 
-                  msgt_unused = 0}, sigcode = 40, rusageType = {msgt_name = 0, msgt_size = 18, msgt_number = 0, msgt_inline = 0, 
-                  msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, rusage = {ru_utime = {tv_sec = 32, tv_usec = 17152883}, ru_stime = {
-                    tv_sec = 16926556, tv_usec = 17687868}, ru_maxrss = 17243652, ru_ixrss = 18698228, ru_idrss = 17243488, ru_isrss = 18698228, 
-                  ru_minflt = 16926936, ru_majflt = 17888569, ru_nswap = 18980872, ru_inblock = 19046400, ru_oublock = 8, ru_msgsnd = 17, 
-                  ru_msgrcv = 16926872, ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}, pid_statusType = {msgt_name = 0, msgt_size = 0, 
-                  msgt_number = 0, msgt_inline = 0, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, pid_status = 17243652}}
-            msg_result = <optimized out>
-            msgh_size = <optimized out>
-    #2  0x0110e49e in __wait4 (pid=-1, stat_loc=0x1024890, options=0, usage=0x10247d8) at ../sysdeps/mach/hurd/wait4.c:35
-            __p = 0x1219fac
-            __link = {resource = {next = 0x0, prevp = 0x1219fb0}, thread = {next = 0x0, prevp = 0x121a45c}, 
-              cleanup = 0x1084b90 <_hurd_port_cleanup>, cleanup_data = 0x1b}
-            port = 27
-            __result = <optimized out>
-            dead = <optimized out>
-            err = <optimized out>
-            ignored = {ru_utime = {tv_sec = 134631884, tv_usec = 134546233}, ru_stime = {tv_sec = 18689656, tv_usec = 17}, ru_maxrss = 0, 
-              ru_ixrss = 18708608, ru_idrss = 18689652, ru_isrss = 18708608, ru_minflt = 0, ru_majflt = 75, ru_nswap = 31, ru_inblock = 31, 
-              ru_oublock = 31, ru_msgsnd = 0, ru_msgrcv = 18976712, ru_nsignals = 16926936, ru_nvcsw = 0, ru_nivcsw = 18698228}
-            sigcode = 31
-            dummy = 16926564
-    #3  0x0110e2c7 in __wait3 (stat_loc=stat_loc@entry=..., options=options@entry=0, usage=usage@entry=0x0)
-        at ../sysdeps/unix/bsd/bsd4.4/wait3.c:34
-    No locals.
-    #4  0x0805028a in waitproc (status=0x1024890, block=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:1139
-            mask = 1
-            oldmask = 0
-            flags = 0
-            err = <optimized out>
-    #5  dowait (block=block@entry=1, job=job@entry=0x80651c0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:1016
-            status = <optimized out>
-            jp = <optimized out>
-            thisjob = 0x0
-            state = <optimized out>
-    #6  0x080518dc in waitforjob (jp=jp@entry=0x80651c0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:976
-            st = <optimized out>
-    #7  0x0804be00 in evalsubshell (n=0x80646f4, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:470
-            jp = 0x80651c0
-            backgnd = 0
-            status = 0
-    #8  0x0804b5df in evaltree (n=0x80646f4, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = -1
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #9  0x0804b509 in evaltree (n=0x80646f4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #10 0x0804b586 in evaltree (n=0x8064e14, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #11 0x0804b586 in evaltree (n=0x8064ff4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #12 0x0804b586 in evaltree (n=0x8065074, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #13 0x0804b8f1 in evalfor (n=n@entry=0x80635c4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:392
-            arglist = {list = 0x80650ac, lastp = 0x80650ac}
-            argp = <optimized out>
-            sp = 0x80650ac
-            smark = {stackp = 0x8064fa8, stacknxt = 0x80650a4 ";", stacknleft = 256}
-    #14 0x0804b51c in evaltree (n=0x80635c4, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = 0x804b830 <evalfor>
-            isor = <optimized out>
-            status = <optimized out>
-    #15 0x0804b509 in evaltree (n=0x80635c4, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #16 0x0804b509 in evaltree (n=0x806508c, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #17 0x0804be81 in evalstring (
-        s=0x102500d "if [ -d ../prev-gcc ]; then \\\n  cd ../prev-gcc && \\\n  make real-install-headers-tar DESTDIR=`pwd`/../gcc/ \\\n    libsubdir=. ; \\\nelse \\\n  set -e; for ml in `cat fixinc_list`; do \\\n    sysroot_headers_s"..., flags=0, flags@entry=4)
-        at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:168
-            n = <optimized out>
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "if", stacknleft = 504}
-            status = 0
-    #18 0x08049b2f in main (argc=3, argv=0x1024b84) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:174
-            shinit = <optimized out>
-            state = 4
-            jmploc = {loc = {{__jmpbuf = {18698228, 142560, 134607808, 16927496, 16927424, 134519464}, __mask_was_saved = 0, 
-                  __saved_mask = 18698228}}}
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "if", stacknleft = 504}
-            login = <optimized out>
-
-## 26554
-
-    Thread 2 (Thread 26554.2):
-    #0  0x0105a7cc in mach_msg_trap () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0105afc9 in __mach_msg (msg=0x1220f90, option=3, send_size=32, rcv_size=4096, rcv_name=116, timeout=0, notify=0) at msg.c:110
-            ret = <optimized out>
-    #2  0x0105b6f9 in __mach_msg_server_timeout (demux=0x106bf00 <msgport_server>, max_size=4096, rcv_name=116, option=0, timeout=0)
-        at msgserver.c:151
-            request = 0x1221fa0
-            reply = 0x1220f90
-            mr = <optimized out>
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #3  0x0105b7cb in __mach_msg_server (demux=0x106bf00 <msgport_server>, max_size=4096, rcv_name=116) at msgserver.c:196
-    No locals.
-    #4  0x0106becf in _hurd_msgport_receive () at msgportdemux.c:68
-    No locals.
-    #5  0x66688b92 in ?? ()
-    No symbol table info available.
-    
-    Thread 1 (Thread 26554.1):
-    #0  0x01077a5c in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:134
-            err = <optimized out>
-            err = <optimized out>
-            user_option = 3
-            user_timeout = 0
-            m = 0x1024448
-            msgh_bits = 5395
-            remote_port = 114
-            msgid = 24020
-            __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg"
-    #1  0x011f89df in __proc_wait (process=114, pid=-1, options=0, status=0x10245d0, sigcode=0x102457c, rusage=0x1024518, pid_status=0x1024580)
-        at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/hurd/RPC_proc_wait.c:182
-            Mess = {In = {Head = {msgh_bits = 5395, msgh_size = 3, msgh_remote_port = 114, msgh_local_port = 117, msgh_seqno = 0, 
-                  msgh_id = 24020}, pidType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, 
-                  msgt_deallocate = 0, msgt_unused = 0}, pid = -1, optionsType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, 
-                  msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, options = 0}, Out = {Head = {msgh_bits = 5395, msgh_size = 3, 
-                  msgh_remote_port = 114, msgh_local_port = 117, msgh_seqno = 0, msgh_id = 24020}, RetCodeType = {msgt_name = 2, msgt_size = 32, 
-                  msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, RetCode = -1, statusType = {
-                  msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, 
-                status = 0, sigcodeType = {msgt_name = 0, msgt_size = 0, msgt_number = 0, msgt_inline = 0, msgt_longform = 0, msgt_deallocate = 0, 
-                  msgt_unused = 0}, sigcode = 117, rusageType = {msgt_name = 50, msgt_size = 89, msgt_number = 2, msgt_inline = 0, 
-                  msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, rusage = {ru_utime = {tv_sec = 23100, tv_usec = 268509186}, 
-                  ru_stime = {tv_sec = 0, tv_usec = 268509186}, ru_maxrss = 0, ru_ixrss = 268509203, ru_idrss = 1, ru_isrss = 18694132, 
-                  ru_minflt = 16926232, ru_majflt = 17884684, ru_nswap = 116, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 1, ru_msgrcv = 16926168, 
-                  ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}, pid_statusType = {msgt_name = 0, msgt_size = 0, msgt_number = 0, msgt_inline = 0, 
-                  msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, pid_status = 17239556}}
-            msg_result = <optimized out>
-            msgh_size = <optimized out>
-    #2  0x0110d49e in __wait4 (pid=-1, stat_loc=0x10245d0, options=0, usage=0x1024518) at ../sysdeps/mach/hurd/wait4.c:35
-            __p = 0x1218fac
-            __link = {resource = {next = 0x0, prevp = 0x1218fb0}, thread = {next = 0x0, prevp = 0x121945c}, 
-              cleanup = 0x1083b90 <_hurd_port_cleanup>, cleanup_data = 0x72}
-            port = 114
-            __result = <optimized out>
-            dead = <optimized out>
-            err = <optimized out>
-            ignored = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 18685560, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, 
-              ru_idrss = 18685556, ru_isrss = 0, ru_minflt = 0, ru_majflt = 75, ru_nswap = 31, ru_inblock = 31, ru_oublock = 31, ru_msgsnd = 0, 
-              ru_msgrcv = 18972616, ru_nsignals = 16926232, ru_nvcsw = 268509186, ru_nivcsw = 18694132}
-            sigcode = 31
-            dummy = 16925860
-    #3  0x0110d2c7 in __wait3 (stat_loc=stat_loc@entry=..., options=options@entry=0, usage=usage@entry=0x0)
-        at ../sysdeps/unix/bsd/bsd4.4/wait3.c:34
-    No locals.
-    #4  0x0805028a in waitproc (status=0x10245d0, block=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:1139
-            mask = 1
-            oldmask = 0
-            flags = 0
-            err = <optimized out>
-    #5  dowait (block=block@entry=1, job=job@entry=0x8063650) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:1016
-            status = <optimized out>
-            jp = <optimized out>
-            thisjob = 0x0
-            state = <optimized out>
-    #6  0x080518dc in waitforjob (jp=jp@entry=0x8063650) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:976
-            st = <optimized out>
-    #7  0x0804c470 in evalcommand (cmd=0x8066eb4, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:824
-            localvar_stop = 0x0
-            redir_stop = 0x0
-            smark = {stackp = 0x806cfd0, stacknxt = 0x8082d64 "rm", stacknleft = 168560}
-            argp = <optimized out>
-            arglist = {list = 0x8082d6c, lastp = 0x8082de4}
-            varlist = {list = 0x0, lastp = 0x1024694}
-            argv = 0x8082df0
-            argc = <optimized out>
-            sp = <optimized out>
-            cmdentry = {cmdtype = 0, u = {index = 5, cmd = 0x5, func = 0x5}}
-            jp = 0x8063650
-            lastarg = 0x0
-            path = 0x1027951 "/home/thomas/shared/command:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
-            spclbltin = -1
-            execcmd = 0
-            status = 0
-            nargv = <optimized out>
-    #8  0x0804b509 in evaltree (n=0x8066eb4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #9  0x0804b586 in evaltree (n=0x8066fec, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #10 0x0804b8f1 in evalfor (n=n@entry=0x8066e1c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:392
-            arglist = {list = 0x807e36c, lastp = 0x8082d5c}
-            argp = <optimized out>
-            sp = 0x807f9fc
-            smark = {stackp = 0x806c998, stacknxt = 0x806cb94 "\001\002", stacknleft = 0}
-    #11 0x0804b51c in evaltree (n=0x8066e1c, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = 0x804b830 <evalfor>
-            isor = <optimized out>
-            status = <optimized out>
-    #12 0x0804b509 in evaltree (n=0x8066e1c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #13 0x0804b586 in evaltree (n=0x8067064, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #14 0x0804b586 in evaltree (n=0x80670b4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #15 0x0804b586 in evaltree (n=0x8069bcc, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #16 0x0804b586 in evaltree (n=0x8069c14, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #17 0x0804b586 in evaltree (n=0x8069c8c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #18 0x0804b586 in evaltree (n=0x8069ccc, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #19 0x0804b586 in evaltree (n=0x806aa64, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #20 0x0804b586 in evaltree (n=0x806ab3c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #21 0x0804b586 in evaltree (n=0x806ab7c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #22 0x0804b586 in evaltree (n=0x806ba6c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #23 0x0804b586 in evaltree (n=0x806bb84, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #24 0x0804b586 in evaltree (n=0x806bbe4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #25 0x0804b586 in evaltree (n=0x806bcfc, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #26 0x0804b586 in evaltree (n=0x806be2c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #27 0x0804b586 in evaltree (n=0x806be84, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #28 0x0804b586 in evaltree (n=0x806c054, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #29 0x0804b586 in evaltree (n=0x806c2b4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #30 0x0804b586 in evaltree (n=0x806ca2c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #31 0x0804b586 in evaltree (n=0x806cb64, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #32 0x0804b8f1 in evalfor (n=n@entry=0x80617f4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:392
-            arglist = {list = 0x806cb8c, lastp = 0x806cb8c}
-            argp = <optimized out>
-            sp = 0x806cb8c
-            smark = {stackp = 0x806c998, stacknxt = 0x806cb7c "/usr/include", stacknleft = 24}
-    #33 0x0804b51c in evaltree (n=0x80617f4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = 0x804b830 <evalfor>
-            isor = <optimized out>
-            status = <optimized out>
-    #34 0x08051cbc in cmdloop (top=top@entry=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:245
-            skip = <optimized out>
-            n = <optimized out>
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "for", stacknleft = 504}
-            inter = <optimized out>
-            status = 0
-            numeof = 0
-    #35 0x08049b42 in main (argc=4, argv=0x1024b74) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:178
-            shinit = <optimized out>
-            state = 4
-            jmploc = {loc = {{__jmpbuf = {18694132, 142560, 134607808, 16927480, 16927408, 134519464}, __mask_was_saved = 0, 
-                  __saved_mask = 18694132}}}
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "for", stacknleft = 504}
-            login = <optimized out>
-
-
-## 28134
-
-    Thread 2 (Thread 28134.2):
-    #0  0x0105a7cc in mach_msg_trap () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0105afc9 in __mach_msg (msg=0x1220f90, option=3, send_size=32, rcv_size=4096, rcv_name=116, timeout=0, notify=0) at msg.c:110
-            ret = <optimized out>
-    #2  0x0105b6f9 in __mach_msg_server_timeout (demux=0x106bf00 <msgport_server>, max_size=4096, rcv_name=116, option=0, timeout=0)
-        at msgserver.c:151
-            request = 0x1221fa0
-            reply = 0x1220f90
-            mr = <optimized out>
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #3  0x0105b7cb in __mach_msg_server (demux=0x106bf00 <msgport_server>, max_size=4096, rcv_name=116) at msgserver.c:196
-    No locals.
-    #4  0x0106becf in _hurd_msgport_receive () at msgportdemux.c:68
-    No locals.
-    #5  0x66688b92 in ?? ()
-    No symbol table info available.
-    #6  0x00000000 in ?? ()
-    No symbol table info available.
-    
-    Thread 1 (Thread 28134.1):
-    #0  0x0105a81c in swtch_pri () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2
-    No locals.
-    #1  0x0105c0a4 in __spin_lock_solid (lock=0x121980c) at spin-solid.c:27
-    No locals.
-    #2  0x01070e57 in __spin_lock (__lock=<optimized out>) at ../mach/lock-intern.h:55
-    No locals.
-    #3  _hurd_sigstate_lock (ss=0x1219008) at hurdsig.c:172
-    No locals.
-    #4  0x0110e51c in _hurd_critical_section_unlock (our_lock=<optimized out>) at ../hurd/hurd/signal.h:235
-    No locals.
-    #5  __fork () at ../sysdeps/mach/hurd/fork.c:707
-            env = {{__jmpbuf = {18694132, 18972616, 0, 16926232, 16925860, 17882911}, __mask_was_saved = 0, __saved_mask = 0}}
-            pid = 0
-            err = <optimized out>
-            __PRETTY_FUNCTION__ = "__fork"
-            ss = 0x1219008
-            threads = 0x0
-            nthreads = 0
-            stopped = 1
-            i = 6
-    #6  0x08051620 in forkshell (jp=jp@entry=0x8063650, n=n@entry=0x8066eb4, mode=mode@entry=0)
-        at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:934
-            pid = <optimized out>
-    #7  0x0804c460 in evalcommand (cmd=0x8066eb4, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:823
-            localvar_stop = 0x0
-            redir_stop = 0x0
-            smark = {stackp = 0x806cfd0, stacknxt = 0x8082d64 "rm", stacknleft = 168560}
-            argp = <optimized out>
-            arglist = {list = 0x8082d6c, lastp = 0x8082de4}
-            varlist = {list = 0x0, lastp = 0x1024694}
-            argv = 0x8082df0
-            argc = <optimized out>
-            sp = <optimized out>
-            cmdentry = {cmdtype = 0, u = {index = 5, cmd = 0x5, func = 0x5}}
-            jp = 0x8063650
-            lastarg = 0x0
-            path = 0x1027951 "/home/thomas/shared/command:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
-            spclbltin = -1
-            execcmd = 0
-            status = 0
-            nargv = <optimized out>
-    #8  0x0804b509 in evaltree (n=0x8066eb4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #9  0x0804b586 in evaltree (n=0x8066fec, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #10 0x0804b8f1 in evalfor (n=n@entry=0x8066e1c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:392
-            arglist = {list = 0x807e36c, lastp = 0x8082d5c}
-            argp = <optimized out>
-            sp = 0x807f9fc
-            smark = {stackp = 0x806c998, stacknxt = 0x806cb94 "\001\002", stacknleft = 0}
-    #11 0x0804b51c in evaltree (n=0x8066e1c, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = 0x804b830 <evalfor>
-            isor = <optimized out>
-            status = <optimized out>
-    #12 0x0804b509 in evaltree (n=0x8066e1c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #13 0x0804b586 in evaltree (n=0x8067064, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #14 0x0804b586 in evaltree (n=0x80670b4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #15 0x0804b586 in evaltree (n=0x8069bcc, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #16 0x0804b586 in evaltree (n=0x8069c14, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #17 0x0804b586 in evaltree (n=0x8069c8c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #18 0x0804b586 in evaltree (n=0x8069ccc, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #19 0x0804b586 in evaltree (n=0x806aa64, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #20 0x0804b586 in evaltree (n=0x806ab3c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #21 0x0804b586 in evaltree (n=0x806ab7c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #22 0x0804b586 in evaltree (n=0x806ba6c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #23 0x0804b586 in evaltree (n=0x806bb84, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #24 0x0804b586 in evaltree (n=0x806bbe4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #25 0x0804b586 in evaltree (n=0x806bcfc, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #26 0x0804b586 in evaltree (n=0x806be2c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #27 0x0804b586 in evaltree (n=0x806be84, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #28 0x0804b586 in evaltree (n=0x806c054, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #29 0x0804b586 in evaltree (n=0x806c2b4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #30 0x0804b586 in evaltree (n=0x806ca2c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #31 0x0804b586 in evaltree (n=0x806cb64, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #32 0x0804b8f1 in evalfor (n=n@entry=0x80617f4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:392
-            arglist = {list = 0x806cb8c, lastp = 0x806cb8c}
-            argp = <optimized out>
-            sp = 0x806cb8c
-            smark = {stackp = 0x806c998, stacknxt = 0x806cb7c "/usr/include", stacknleft = 24}
-    #33 0x0804b51c in evaltree (n=0x80617f4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = 0x804b830 <evalfor>
-            isor = <optimized out>
-            status = <optimized out>
-    #34 0x08051cbc in cmdloop (top=top@entry=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:245
-            skip = <optimized out>
-            n = <optimized out>
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "for", stacknleft = 504}
-            inter = <optimized out>
-            status = 0
-            numeof = 0
-    #35 0x08049b42 in main (argc=4, argv=0x1024b74) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:178
-            shinit = <optimized out>
-            state = 4
-            jmploc = {loc = {{__jmpbuf = {18694132, 142560, 134607808, 16927480, 16927408, 134519464}, __mask_was_saved = 0, 
-                  __saved_mask = 18694132}}}
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "for", stacknleft = 504}
-            login = <optimized out>
-
-
-# III
-
-      PID  UID  PPID  PGrp  Sess TH  Vmem   RSS %CPU     User   System Args
-     3524 1000 28449  1701   455  2  146M 1.07M  0.0  0:00.19  0:01.25 /bin/dash ./config.status
-     4798 1000  3524  1701   455  2  134M 1.54M  0.0  0:00.07  0:00.05 make pch_build=
-     4989 1000  4798  1701   455  2  146M  900K  0.0  0:00.00  0:00.00 ?
-     5022 1000  4989  1701   455  2  146M  584K  0.0  0:00.00  0:00.00 ?
-     5024 1000  5022  1701   455  2  146M  200K 98.6  0:01.59  2:48.24 ?
-
-In such cases, can be reasonabily sure that the question mark ones are
-`/bin/dash`, too.
-
-
-## 3524
-
-    Thread 2 (Thread 3524.2):
-    #0  0x0105b7cc in mach_msg_trap () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0105bfc9 in __mach_msg (msg=0x1221f90, option=3, send_size=32, rcv_size=4096, rcv_name=106, timeout=0, notify=0) at msg.c:110
-            ret = <optimized out>
-    #2  0x0105c6f9 in __mach_msg_server_timeout (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=106, option=0, timeout=0) at msgserver.c:151
-            request = 0x1222fa0
-            reply = 0x1221f90
-            mr = <optimized out>
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #3  0x0105c7cb in __mach_msg_server (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=106) at msgserver.c:196
-    No locals.
-    #4  0x0106cecf in _hurd_msgport_receive () at msgportdemux.c:68
-    No locals.
-    #5  0x66688b92 in ?? ()
-    No symbol table info available.
-    
-    Thread 1 (Thread 3524.1):
-    #0  0x01078a5c in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:134
-            err = <optimized out>
-            err = <optimized out>
-            user_option = 3
-            user_timeout = 0
-            m = 0x1024768
-            msgh_bits = 5395
-            remote_port = 105
-            msgid = 24020
-            __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg"
-    #1  0x011f99df in __proc_wait (process=105, pid=-1, options=0, status=0x10248f0, sigcode=0x102489c, rusage=0x1024838, pid_status=0x10248a0)
-        at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/hurd/RPC_proc_wait.c:182
-            Mess = {In = {Head = {msgh_bits = 5395, msgh_size = 0, msgh_remote_port = 105, msgh_local_port = 109, msgh_seqno = 0, msgh_id = 24020}, pidType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, 
-                  msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, pid = -1, optionsType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, options = 0}, 
-              Out = {Head = {msgh_bits = 5395, msgh_size = 0, msgh_remote_port = 105, msgh_local_port = 109, msgh_seqno = 0, msgh_id = 24020}, RetCodeType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, 
-                  msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, RetCode = -1, statusType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, status = 0, 
-                sigcodeType = {msgt_name = 0, msgt_size = 0, msgt_number = 0, msgt_inline = 0, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, sigcode = 40, rusageType = {msgt_name = 0, msgt_size = 18, msgt_number = 0, 
-                  msgt_inline = 0, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, rusage = {ru_utime = {tv_sec = 32, tv_usec = 17152883}, ru_stime = {tv_sec = 16926652, tv_usec = 17687868}, ru_maxrss = 17243652, 
-                  ru_ixrss = 18698228, ru_idrss = 17243488, ru_isrss = 18698228, ru_minflt = 16927032, ru_majflt = 17888569, ru_nswap = 18980872, ru_inblock = 19042304, ru_oublock = 8, ru_msgsnd = 17, ru_msgrcv = 16926968, ru_nsignals = 0, 
-                  ru_nvcsw = 0, ru_nivcsw = 0}, pid_statusType = {msgt_name = 0, msgt_size = 0, msgt_number = 0, msgt_inline = 0, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, pid_status = 17243652}}
-            msg_result = <optimized out>
-            msgh_size = <optimized out>
-    #2  0x0110e49e in __wait4 (pid=-1, stat_loc=0x10248f0, options=0, usage=0x1024838) at ../sysdeps/mach/hurd/wait4.c:35
-            __p = 0x1219fac
-            __link = {resource = {next = 0x0, prevp = 0x1219fb0}, thread = {next = 0x0, prevp = 0x121a45c}, cleanup = 0x1084b90 <_hurd_port_cleanup>, cleanup_data = 0x69}
-            port = 105
-            __result = <optimized out>
-            dead = <optimized out>
-            err = <optimized out>
-            ignored = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 18689656, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 18689652, ru_isrss = 0, ru_minflt = 0, ru_majflt = 75, ru_nswap = 31, ru_inblock = 31, 
-              ru_oublock = 31, ru_msgsnd = 0, ru_msgrcv = 18976712, ru_nsignals = 16927032, ru_nvcsw = 268509186, ru_nivcsw = 18698228}
-            sigcode = 31
-            dummy = 16926660
-    #3  0x0110e2c7 in __wait3 (stat_loc=stat_loc@entry=..., options=options@entry=0, usage=usage@entry=0x0) at ../sysdeps/unix/bsd/bsd4.4/wait3.c:34
-    No locals.
-    #4  0x0805028a in waitproc (status=0x10248f0, block=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:1139
-            mask = 1
-            oldmask = 0
-            flags = 0
-            err = <optimized out>
-    #5  dowait (block=block@entry=1, job=job@entry=0x8063940) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:1016
-            status = <optimized out>
-            jp = <optimized out>
-            thisjob = 0x0
-            state = <optimized out>
-    #6  0x080518dc in waitforjob (jp=jp@entry=0x8063940) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:976
-            st = <optimized out>
-    #7  0x0804be00 in evalsubshell (n=0x8083abc, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:470
-            jp = 0x8063940
-            backgnd = 0
-            status = 0
-    #8  0x0804b509 in evaltree (n=0x8083abc, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #9  0x0804b81b in evalcase (n=0x8075b3c, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:428
-            cp = 0x8083a9c
-            patp = 0x8083aac
-            arglist = {list = 0x8083d8c, lastp = 0x8083d8c}
-            smark = {stackp = 0x8083d48, stacknxt = 0x8083d74 "generate-headers:C", stacknleft = 464}
-    #10 0x0804b509 in evaltree (n=0x8075b3c, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #11 0x0804b509 in evaltree (n=0x8075b3c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #12 0x0804b8f1 in evalfor (n=n@entry=0x80617f4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:392
-            arglist = {list = 0x8083ccc, lastp = 0x8083d6c}
-            argp = <optimized out>
-            sp = 0x8083d6c
-            smark = {stackp = 0x8083b48, stacknxt = 0x8083ba4 ":F", stacknleft = 416}
-    #13 0x0804b51c in evaltree (n=0x80617f4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = 0x804b830 <evalfor>
-            isor = <optimized out>
-            status = <optimized out>
-    #14 0x08051cbc in cmdloop (top=top@entry=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:245
-            skip = <optimized out>
-            n = <optimized out>
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "for", stacknleft = 504}
-            inter = <optimized out>
-            status = 0
-            numeof = 0
-    #15 0x08049b42 in main (argc=2, argv=0x1024bb4) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:178
-            shinit = <optimized out>
-            state = 4
-            jmploc = {loc = {{__jmpbuf = {18698228, 142560, 134607808, 16927544, 16927472, 134519464}, __mask_was_saved = 0, __saved_mask = 18698228}}}
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "for", stacknleft = 504}
-            login = <optimized out>
-
-    (gdb) print _hurd_global_sigstate
-    $1 = (struct hurd_sigstate *) 0x121a808
-    (gdb) print *_hurd_global_sigstate
-    $2 = {critical_section_lock = 0, lock = 0, thread = 0, next = 0x0, blocked = 4294967295, pending = 0, actions = {{__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {
-            sa_handler = 0x8056260 <onsig>, sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, 
-          sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, 
-          sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0x8056260 <onsig>, sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0x8056260 <onsig>, sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 12 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, 
-          error = 0} <repeats 20 times>, {exc = 0, exc_code = 19013424, exc_subcode = 85056, code = 1, error = 17261792}, {exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 12 times>}, suspended = 0, intr_port = 0, 
-      context = 0x0, active_resources = 0x0, cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_siglock
-    $3 = {held = 0, lock = 0, name = 0x0, queue = {head = 0x0, tail = 0x0}, holder = 0x0}
-    (gdb) print _hurd_sigstates
-    $4 = (struct hurd_sigstate *) 0x1224808
-    (gdb) print *_hurd_sigstates
-    $5 = {critical_section_lock = 0, lock = 0, thread = 108, next = 0x121a008, blocked = 0, pending = 0, actions = {{__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 33 times>}, sigaltstack = {
-        ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 33 times>}, suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, 
-      cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_self_sigstate()
-    $6 = (struct hurd_sigstate *) 0x121a008
-    (gdb) print *_hurd_self_sigstate()
-    warning: Can't wait for pid 3524: Keine Kind-Prozesse
-    $7 = {critical_section_lock = 0, lock = 0, thread = 23, next = 0x0, blocked = 0, pending = 0, actions = {{__sigaction_handler = {sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 32 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, 
-          error = 0} <repeats 20 times>, {exc = 0, exc_code = 19013424, exc_subcode = 85056, code = 1, error = 17261792}, {exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 12 times>}, suspended = 0, intr_port = 105, 
-      context = 0x0, active_resources = 0x1024880, cancel = 0, cancel_hook = 0}
-
-
-## 4798
-
-    Thread 2 (Thread 4798.2):
-    #0  0x0105f7cc in mach_msg_trap () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0105ffc9 in __mach_msg (msg=0x17fdf30, option=3, send_size=32, rcv_size=4096, rcv_name=122, timeout=0, notify=0) at msg.c:110
-            ret = <optimized out>
-    #2  0x010606f9 in __mach_msg_server_timeout (demux=0x1070f00 <msgport_server>, max_size=4096, rcv_name=122, option=0, timeout=0) at msgserver.c:151
-            request = 0x17fef40
-            reply = 0x17fdf30
-            mr = <optimized out>
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #3  0x010607cb in __mach_msg_server (demux=0x1070f00 <msgport_server>, max_size=4096, rcv_name=122) at msgserver.c:196
-    No locals.
-    #4  0x01070ecf in _hurd_msgport_receive () at msgportdemux.c:68
-    No locals.
-    #5  0x011e3c20 in entry_point (start_routine=0x1070e60 <_hurd_msgport_receive>, arg=0x0) at ./pthread/pt-create.c:50
-    No locals.
-    #6  0x00000000 in ?? ()
-    No symbol table info available.
-    
-    Thread 1 (Thread 4798.1):
-    #0  0x0107ca5c in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:134
-            err = <optimized out>
-            err = <optimized out>
-            user_option = 3
-            user_timeout = 0
-            m = 0x15fe048
-            msgh_bits = 5395
-            remote_port = 104
-            msgid = 24020
-            __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg"
-    #1  0x0120a9df in __proc_wait (process=104, pid=-1, options=0, status=0x15fe1e0, sigcode=0x15fe17c, rusage=0x15fe118, pid_status=0x15fe180)
-        at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/hurd/RPC_proc_wait.c:182
-            Mess = {In = {Head = {msgh_bits = 5395, msgh_size = 0, msgh_remote_port = 104, msgh_local_port = 106, msgh_seqno = 0, msgh_id = 24020}, pidType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, 
-                  msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, pid = -1, optionsType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, options = 0}, 
-              Out = {Head = {msgh_bits = 5395, msgh_size = 0, msgh_remote_port = 104, msgh_local_port = 106, msgh_seqno = 0, msgh_id = 24020}, RetCodeType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, 
-                  msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, RetCode = -1, statusType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, status = 0, 
-                sigcodeType = {msgt_name = 244, msgt_size = 143, msgt_number = 285, msgt_inline = 0, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, sigcode = 2, rusageType = {msgt_name = 1, msgt_size = 0, msgt_number = 0, 
-                  msgt_inline = 0, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, rusage = {ru_utime = {tv_sec = 1, tv_usec = 17903391}, ru_stime = {tv_sec = 23, tv_usec = 514}, ru_maxrss = 23060408, ru_ixrss = 31, 
-                  ru_idrss = 18714612, ru_isrss = 23068628, ru_minflt = 134641554, ru_majflt = 23060780, ru_nswap = 23060408, ru_inblock = 17903391, ru_oublock = 0, ru_msgsnd = 134675828, ru_msgrcv = 0, ru_nsignals = 155568, ru_nvcsw = 0, 
-                  ru_nivcsw = 17701606}, pid_statusType = {msgt_name = 144, msgt_size = 139, msgt_number = 264, msgt_inline = 0, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, pid_status = 17260036}}
-            msg_result = <optimized out>
-            msgh_size = <optimized out>
-    #2  0x0111249e in __wait4 (pid=-1, stat_loc=0x15fe1e0, options=0, usage=0x15fe118) at ../sysdeps/mach/hurd/wait4.c:35
-            __p = 0x25fac
-            __link = {resource = {next = 0x0, prevp = 0x25fb0}, thread = {next = 0x0, prevp = 0x122dc5c}, cleanup = 0x1088b90 <_hurd_port_cleanup>, cleanup_data = 0x68}
-            port = 104
-            __result = <optimized out>
-            dead = <optimized out>
-            err = <optimized out>
-            ignored = {ru_utime = {tv_sec = 134641554, tv_usec = 23060792}, ru_stime = {tv_sec = 17719530, tv_usec = 18724992}, ru_maxrss = 134641554, ru_ixrss = 17719434, ru_idrss = 135171864, ru_isrss = 0, ru_minflt = 17260036, 
-              ru_majflt = 134571847, ru_nswap = 17259872, ru_inblock = 18714612, ru_oublock = 23060856, ru_msgsnd = 17424911, ru_msgrcv = 19060744, ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}
-            sigcode = 134570472
-            dummy = 4836
-    #3  0x01112269 in __libc_wait (stat_loc=0x15fe1e0) at ../sysdeps/unix/bsd/bsd4.4/wait.c:29
-    No locals.
-    #4  0x080573c4 in ?? ()
-    No symbol table info available.
-    #5  0x0805780c in ?? ()
-    No symbol table info available.
-    #6  0x08060611 in ?? ()
-    No symbol table info available.
-    #7  0x08060a6c in ?? ()
-    No symbol table info available.
-    #8  0x0805f859 in ?? ()
-    No symbol table info available.
-    #9  0x08060a6c in ?? ()
-    No symbol table info available.
-    #10 0x0805f859 in ?? ()
-    No symbol table info available.
-    #11 0x08060a6c in ?? ()
-    No symbol table info available.
-    #12 0x0805f859 in ?? ()
-    No symbol table info available.
-    #13 0x08060f3e in ?? ()
-    No symbol table info available.
-    #14 0x0804b245 in ?? ()
-    No symbol table info available.
-    #15 0x0108a66b in __libc_start_main (main=0x8049d30, argc=2, ubp_av=0x15ff328, init=0x80656d0, fini=0x80656c0, rtld_fini=0xf5c0, stack_end=0x15ff31c) at libc-start.c:257
-            result = <optimized out>
-    #16 0x0804b9d1 in ?? ()
-    No symbol table info available.
-
-    (gdb) print _hurd_global_sigstate
-    $2 = (struct hurd_sigstate *) 0x122d008
-    (gdb) print *_hurd_global_sigstate
-    $3 = {critical_section_lock = 0, lock = 0, thread = 0, next = 0x0, blocked = 4294967295, pending = 0, actions = {{__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {
-            sa_handler = 0x804d570, sa_sigaction = 0x804d570}, sa_mask = 1, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x804d570, sa_sigaction = 0x804d570}, sa_mask = 2, sa_flags = 2}, {__sigaction_handler = {
-            sa_handler = 0x804d570, sa_sigaction = 0x804d570}, sa_mask = 4, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 11 times>, {__sigaction_handler = {
-            sa_handler = 0x804d570, sa_sigaction = 0x804d570}, sa_mask = 16384, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {
-            sa_handler = 0x8055670, sa_sigaction = 0x8055670}, sa_mask = 524288, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x804d570, sa_sigaction = 0x804d570}, sa_mask = 8388608, 
-          sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x804d570, sa_sigaction = 0x804d570}, sa_mask = 16777216, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x8057a60, sa_sigaction = 0x8057a60}, sa_mask = 536870912, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}}, sigaltstack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, 
-          exc_subcode = 0, code = 0, error = 0} <repeats 33 times>}, suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_siglock
-    $4 = {held = 0, lock = 0, name = 0x0, queue = {head = 0x0, tail = 0x0}, holder = 0x0}
-    (gdb) print _hurd_sigstates
-    $5 = (struct hurd_sigstate *) 0x26808
-    (gdb) print *_hurd_sigstates
-    $6 = {critical_section_lock = 0, lock = 0, thread = 124, next = 0x122d808, blocked = 0, pending = 0, actions = {{__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 33 times>}, sigaltstack = {
-        ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 33 times>}, suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, 
-      cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_self_sigstate()
-    $7 = (struct hurd_sigstate *) 0x122d808
-    (gdb) print *_hurd_self_sigstate()
-    warning: Can't wait for pid 4798: Keine Kind-Prozesse
-    $8 = {critical_section_lock = 0, lock = 0, thread = 24, next = 0x0, blocked = 0, pending = 0, actions = {{__sigaction_handler = {sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 32 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, 
-          error = 0} <repeats 33 times>}, suspended = 0, intr_port = 104, context = 0x0, active_resources = 0x15fe160, cancel = 0, cancel_hook = 0}
-
-
-## 4989
-
-    Thread 2 (Thread 4989.2):
-    #0  0x0105c7cc in mach_msg_trap () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0105cfc9 in __mach_msg (msg=0x1222f90, option=3, send_size=32, rcv_size=4096, rcv_name=129, timeout=0, notify=0) at msg.c:110
-            ret = <optimized out>
-    #2  0x0105d6f9 in __mach_msg_server_timeout (demux=0x106df00 <msgport_server>, max_size=4096, rcv_name=129, option=0, timeout=0) at msgserver.c:151
-            request = 0x1223fa0
-            reply = 0x1222f90
-            mr = <optimized out>
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #3  0x0105d7cb in __mach_msg_server (demux=0x106df00 <msgport_server>, max_size=4096, rcv_name=129) at msgserver.c:196
-    No locals.
-    #4  0x0106decf in _hurd_msgport_receive () at msgportdemux.c:68
-    No locals.
-    #5  0x66688b92 in ?? ()
-    No symbol table info available.
-    
-    Thread 1 (Thread 4989.1):
-    #0  0x01079a5c in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:134
-            err = <optimized out>
-            err = <optimized out>
-            user_option = 3
-            user_timeout = 0
-            m = 0x1023e84
-            msgh_bits = 5395
-            remote_port = 139
-            msgid = 21001
-            __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg"
-    #1  0x0120a1a5 in __io_read (io_object=139, data=0x1024790, dataCnt=0x1024794, offset=-1, amount=128) at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/hurd/RPC_io_read.c:137
-            Mess = {In = {Head = {msgh_bits = 5395, msgh_size = 44, msgh_remote_port = 139, msgh_local_port = 133, msgh_seqno = 0, msgh_id = 21001}, offsetType = {msgt_name = 11, msgt_size = 64, msgt_number = 1, msgt_inline = 1, 
-                  msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, offset = -1, amountType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, amount = 128}, 
-              Out = {Head = {msgh_bits = 5395, msgh_size = 44, msgh_remote_port = 139, msgh_local_port = 133, msgh_seqno = 0, msgh_id = 21001}, RetCodeType = {msgt_name = 11, msgt_size = 64, msgt_number = 1, msgt_inline = 1, 
-                  msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, RetCode = -1, dataType = {msgtl_header = {msgt_name = 255, msgt_size = 255, msgt_number = 4095, msgt_inline = 1, msgt_longform = 1, msgt_deallocate = 1, 
-                    msgt_unused = 1}, msgtl_name = 8194, msgtl_size = 4097, msgtl_number = 128}, 
-                data = "./detail/bin_search_tree_/node_iterators.hpp\npp\n\004\264\035\001\000\004\000\000\064\004\000\000\205", '\000' <repeats 12 times>, "\022\000\200\064\004\000\000\000\000\000\000\205\000\000\000\224\000\000\000\226N\000\000\002 \001\020\000\000\000\000\002 \001\020\001\000\000\000\f\b\000\024", '\000' <repeats 1008 times>, "\002 \001\020\000\000\000\000\002 \001\020\000\000\000\000\021 \001\020\211\000\000\000\364_\035\001\b\260!\001XC\002\001\070L\006\001\n\000\000\000Mg\006\b\000\000\000\000\004.\a\001\354C\002\001`-\a\001\364_\035\001\250C\002\001x\361\005\001\b\260!\001p\357\005\001,H\002\001\004.\a"...}}
-            msg_result = <optimized out>
-            msgh_size = <optimized out>
-    #2  0x0107e321 in readfd (port=139) at fd-read.c:34
-            nbytes = 0x0
-            nread = 0
-            data = 0x0
-            offset = 0
-    #3  0x01084880 in _hurd_ctty_input (port=139, ctty=0, rpc=0x102479c) at ctty-input.c:32
-            err = <optimized out>
-    #4  0x0107dd44 in _hurd_fd_read (fd=0x1219d88, buf=0x1024880, offset=-1) at fd-read.c:39
-            __ulink = {resource = {next = 0x0, prevp = 0x1219d8c}, thread = {next = 0x0, prevp = 0x121b45c}, cleanup = 0x1085b90 <_hurd_port_cleanup>, cleanup_data = 0x8b}
-            __ctty_ulink = {resource = {next = 0x10247d0, prevp = 0x107d794}, thread = {next = 0x121b008, prevp = 0x8c}, cleanup = 0x139e, cleanup_data = 0x8066840}
-            ctty = 0
-            crit = <optimized out>
-            __result = 16927684
-            port = 139
-            err = <optimized out>
-            data = 0x1024880 "\364_\035\001\340h\006\b \307\001"
-            nbytes = 0x1024838
-            nread = 128
-    #5  0x01142652 in __libc_read (fd=3, buf=buf@entry=0x1024880, nbytes=nbytes@entry=128) at ../sysdeps/mach/hurd/read.c:27
-            descriptor = <error reading variable descriptor (DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.)>
-            err = <optimized out>
-    #6  0x0804f480 in expbackq (flag=68, cmd=<optimized out>) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/expand.c:542
-            i = <optimized out>
-            buf = "\364_\035\001\340h\006\b \307\001\000\354H\002\001\065\360\r\001\214\211\035\001\002\000\000\000\b\000\000\000@\000\000\000\020\002\000\000@\000\000\000\374\001\000\000\225\343\033\001̈\035\001\252\313\033\001\264\345\033\001\000\002\000\000\000\000\000\000\000\000\000\000\254\343\033\001\200\210\035\001 \307\001\000Ĉ\035\001<N\006\b\000\000\000\000\214I\002\001\000\000\000\000\302a\005\b\000\000\000\000\003\000\000\000\064J\002\001\b\000\000"
-            dest = <optimized out>
-            startloc = 11
-            in = {fd = 3, buf = 0x0, nleft = 0, jp = 0x8066840}
-            p = <optimized out>
-            syntax = 0x805b922 ""
-            smark = {stackp = 0x80668e8, stacknxt = 0x80668f4 "build_name=./det|i\006\b\374h\006\b/home/thomas/tmp/gcc/hurd/master/libstdc++-v3/include/ext/pb_ds/detail/bin_search_tree_/node_iterators.hpp", stacknleft = 496}
-    #7  argstr (p=0x8064e28 "", flag=68, flag@entry=4) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/expand.c:350
-            spclchars = "=:\210\203\201\202\204\207"
-            reject = 0x8059b41 ":\210\203\201\202\204\207"
-            c = <optimized out>
-            breakall = 0
-            inquotes = 0
-            length = 0
-            startloc = 68
-    #8  0x0804f682 in expandarg (arg=arg@entry=0x8064e2c, arglist=arglist@entry=0x1024994, flag=flag@entry=4) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/expand.c:193
-            sp = <optimized out>
-            p = <optimized out>
-    #9  0x0804c1d4 in evalcommand (cmd=0x8064e3c, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:733
-            spp = 0x1024994
-            p = <optimized out>
-            localvar_stop = 0x0
-            redir_stop = 0x0
-            smark = {stackp = 0x8066440, stacknxt = 0x806663c  <incomplete sequence \321>, stacknleft = 0}
-            argp = 0x8064e2c
-            arglist = {list = 0x0, lastp = 0x102498c}
-            varlist = {list = 0x0, lastp = 0x1024994}
-            argv = 0x80668f0
-            argc = <optimized out>
-            sp = <optimized out>
-            cmdentry = {cmdtype = 2, u = {index = 134584628, cmd = 0x8059934, func = 0x8059934}}
-            jp = <optimized out>
-            lastarg = 0x0
-            path = 0x1028633 "PATH=/home/thomas/shared/command:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
-            spclbltin = <optimized out>
-            execcmd = <optimized out>
-            status = 0
-            nargv = <optimized out>
-    #10 0x0804b509 in evaltree (n=0x8064e3c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #11 0x0804b586 in evaltree (n=0x8064f2c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #12 0x0804b8f1 in evalfor (n=n@entry=0x80618fc, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:392
-            arglist = {list = 0x8064fdc, lastp = 0x8066634}
-            argp = <optimized out>
-            sp = 0x806552c
-            smark = {stackp = 0x8064f00, stacknxt = 0x8064f5c "/home/thomas/tmp/gcc/hurd/master/libstdc++-v3/include/ext/pb_ds/detail/bin_search_tree_/constructors_destructor_fn_imps.hpp", stacknleft = 416}
-    #13 0x0804b51c in evaltree (n=0x80618fc, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = 0x804b830 <evalfor>
-            isor = <optimized out>
-            status = <optimized out>
-    #14 0x0804b509 in evaltree (n=0x80618fc, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #15 0x0804b509 in evaltree (n=0x8064f44, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #16 0x0804be81 in evalstring (
-        s=0x1025eb5 "if [ ! -f stamp-pb ]; then \\\n    cd ./ext/pb_ds && for h in /home/thomas/tmp/gcc/hurd/master/libstdc++-v3/include/ext/pb_ds/detail/bin_search_tree_/constructors_destructor_fn_imps.hpp /home/thomas/tmp"..., flags=0, 
-        flags@entry=4) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:168
-            n = <optimized out>
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "if", stacknleft = 504}
-            status = 0
-    #17 0x08049b2f in main (argc=3, argv=0x1024bb4) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:174
-            shinit = <optimized out>
-            state = 4
-            jmploc = {loc = {{__jmpbuf = {18702324, 142560, 134607808, 16927544, 16927472, 134519464}, __mask_was_saved = 0, __saved_mask = 18702324}}}
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "if", stacknleft = 504}
-            login = <optimized out>
-
-    (gdb) print _hurd_global_sigstate
-    $1 = (struct hurd_sigstate *) 0x121b808
-    (gdb) print *_hurd_global_sigstate
-    $2 = {critical_section_lock = 0, lock = 0, thread = 0, next = 0x0, blocked = 4294967295, pending = 0, actions = {{__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 11 times>, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, 
-          sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {
-            sa_handler = 0x8056260 <onsig>, sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 12 times>}, sigaltstack = {
-        ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 33 times>}, suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, 
-      cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_siglock
-    $3 = {held = 0, lock = 0, name = 0x0, queue = {head = 0x0, tail = 0x0}, holder = 0x0}
-    (gdb) print _hurd_sigstates
-    $4 = (struct hurd_sigstate *) 0x1225808
-    (gdb) print *_hurd_sigstates
-    $5 = {critical_section_lock = 0, lock = 0, thread = 131, next = 0x121b008, blocked = 0, pending = 0, actions = {{__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 33 times>}, sigaltstack = {
-        ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 33 times>}, suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, 
-      cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_self_sigstate()
-    $6 = (struct hurd_sigstate *) 0x121b008
-    (gdb) print *_hurd_self_sigstate()
-    warning: Can't wait for pid 4989: Keine Kind-Prozesse
-    $7 = {critical_section_lock = 0, lock = 0, thread = 98, next = 0x0, blocked = 0, pending = 0, actions = {{__sigaction_handler = {sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 32 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, 
-          error = 0} <repeats 33 times>}, suspended = 0, intr_port = 139, context = 0x0, active_resources = 0x10247c0, cancel = 0, cancel_hook = 0}
-    
-
-## 5022
-
-    Thread 2 (Thread 5022.2):
-    #0  0x0105c7cc in mach_msg_trap () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0105cfc9 in __mach_msg (msg=0x1222f90, option=3, send_size=32, rcv_size=4096, rcv_name=129, timeout=0, notify=0) at msg.c:110
-            ret = <optimized out>
-    #2  0x0105d6f9 in __mach_msg_server_timeout (demux=0x106df00 <msgport_server>, max_size=4096, rcv_name=129, option=0, timeout=0) at msgserver.c:151
-            request = 0x1223fa0
-            reply = 0x1222f90
-            mr = <optimized out>
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #3  0x0105d7cb in __mach_msg_server (demux=0x106df00 <msgport_server>, max_size=4096, rcv_name=129) at msgserver.c:196
-    No locals.
-    #4  0x0106decf in _hurd_msgport_receive () at msgportdemux.c:68
-    No locals.
-    #5  0x66688b92 in ?? ()
-    No symbol table info available.
-    #6  0x00000000 in ?? ()
-    No symbol table info available.
-    
-    Thread 1 (Thread 5022.1):
-    #0  0x01079a5c in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:134
-            err = <optimized out>
-            err = <optimized out>
-            user_option = 3
-            user_timeout = 0
-            m = 0x1024588
-            msgh_bits = 5395
-            remote_port = 105
-            msgid = 24020
-            __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg"
-    #1  0x011fa9df in __proc_wait (process=105, pid=-1, options=0, status=0x1024710, sigcode=0x10246bc, rusage=0x1024658, pid_status=0x10246c0)
-        at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/hurd/RPC_proc_wait.c:182
-            Mess = {In = {Head = {msgh_bits = 5395, msgh_size = 132, msgh_remote_port = 105, msgh_local_port = 133, msgh_seqno = 0, msgh_id = 24020}, pidType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, 
-                  msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, pid = -1, optionsType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, options = 0}, 
-              Out = {Head = {msgh_bits = 5395, msgh_size = 132, msgh_remote_port = 105, msgh_local_port = 133, msgh_seqno = 0, msgh_id = 24020}, RetCodeType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, 
-                  msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, RetCode = -1, statusType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, status = 0, 
-                sigcodeType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, sigcode = 0, rusageType = {msgt_name = 2, msgt_size = 32, msgt_number = 18, 
-                  msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, rusage = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, 
-                  ru_minflt = 0, ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}, pid_statusType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, 
-                  msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, pid_status = 17247748}}
-            msg_result = <optimized out>
-            msgh_size = <optimized out>
-    #2  0x0110f49e in __wait4 (pid=-1, stat_loc=0x1024710, options=0, usage=0x1024658) at ../sysdeps/mach/hurd/wait4.c:35
-            __p = 0x121afac
-            __link = {resource = {next = 0x0, prevp = 0x121afb0}, thread = {next = 0x0, prevp = 0x121b45c}, cleanup = 0x1085b90 <_hurd_port_cleanup>, cleanup_data = 0x69}
-            port = 105
-            __result = <optimized out>
-            dead = <optimized out>
-            err = <optimized out>
-            ignored = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, ru_minflt = 0, ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, 
-              ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}
-            sigcode = 0
-            dummy = 16926180
-    #3  0x0110f2c7 in __wait3 (stat_loc=stat_loc@entry=..., options=options@entry=0, usage=usage@entry=0x0) at ../sysdeps/unix/bsd/bsd4.4/wait3.c:34
-    No locals.
-    #4  0x0805028a in waitproc (status=0x1024710, block=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:1139
-            mask = 1
-            oldmask = 1
-            flags = 0
-            err = <optimized out>
-    #5  dowait (block=block@entry=1, job=job@entry=0x8066840) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:1016
-            status = <optimized out>
-            jp = <optimized out>
-            thisjob = 0x0
-            state = <optimized out>
-    #6  0x080518dc in waitforjob (jp=jp@entry=0x8066840) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:976
-            st = <optimized out>
-    #7  0x0804bc58 in evalpipe (n=0x8064d4c, flags=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:566
-            jp = 0x8066840
-            lp = 0x0
-            pipelen = <optimized out>
-            prevfd = <optimized out>
-            pip = {3, -1}
-    #8  0x0804b509 in evaltree (n=n@entry=0x8064d4c, flags=flags@entry=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #9  0x0804c7df in evaltreenr (flags=1, n=0x8064d4c) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:324
-    No locals.
-    #10 evalbackcmd (n=n@entry=0x8064d4c, result=result@entry=0x1024870) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:606
-            pip = {3, 4}
-            jp = 0x8066840
-    #11 0x0804f43b in expbackq (flag=68, cmd=0x8064d4c) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/expand.c:529
-            i = <optimized out>
-            buf = "\364_\035\001\340h\006\b \307\001\000\354H\002\001\065\360\r\001\214\211\035\001\002\000\000\000\b\000\000\000@\000\000\000\020\002\000\000@\000\000\000\374\001\000\000\225\343\033\001̈\035\001\252\313\033\001\264\345\033\001\000\002\000\000\000\000\000\000\000\000\000\000\254\343\033\001\200\210\035\001 \307\001\000Ĉ\035\001<N\006\b\000\000\000\000\214I\002\001\000\000\000\000\302a\005\b\000\000\000\000\003\000\000\000\064J\002\001\b\000\000"
-            dest = <optimized out>
-            startloc = 11
-            in = {fd = -1, buf = 0x0, nleft = 0, jp = 0x0}
-            p = <optimized out>
-            syntax = 0x805b922 ""
-            smark = {stackp = 0x80668e8, stacknxt = 0x80668f4 "build_name=./det/bin/sed", stacknleft = 496}
-    #12 argstr (p=0x8064e28 "", flag=68, flag@entry=4) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/expand.c:350
-            spclchars = "=:\210\203\201\202\204\207"
-            reject = 0x8059b41 ":\210\203\201\202\204\207"
-            c = <optimized out>
-            breakall = 0
-            inquotes = 0
-            length = 0
-            startloc = 68
-    #13 0x0804f682 in expandarg (arg=arg@entry=0x8064e2c, arglist=arglist@entry=0x1024994, flag=flag@entry=4) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/expand.c:193
-            sp = <optimized out>
-            p = <optimized out>
-    #14 0x0804c1d4 in evalcommand (cmd=0x8064e3c, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:733
-            spp = 0x1024994
-            p = <optimized out>
-            localvar_stop = 0x0
-            redir_stop = 0x0
-            smark = {stackp = 0x8066440, stacknxt = 0x806663c  <incomplete sequence \321>, stacknleft = 0}
-            argp = 0x8064e2c
-            arglist = {list = 0x0, lastp = 0x102498c}
-            varlist = {list = 0x0, lastp = 0x1024994}
-            argv = 0x80668f0
-            argc = <optimized out>
-            sp = <optimized out>
-            cmdentry = {cmdtype = 2, u = {index = 134584628, cmd = 0x8059934, func = 0x8059934}}
-            jp = <optimized out>
-            lastarg = 0x0
-            path = 0x1028633 "PATH=/home/thomas/shared/command:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
-            spclbltin = <optimized out>
-            execcmd = <optimized out>
-            status = 0
-            nargv = <optimized out>
-    #15 0x0804b509 in evaltree (n=0x8064e3c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #16 0x0804b586 in evaltree (n=0x8064f2c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #17 0x0804b8f1 in evalfor (n=n@entry=0x80618fc, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:392
-            arglist = {list = 0x8064fdc, lastp = 0x8066634}
-            argp = <optimized out>
-            sp = 0x806552c
-            smark = {stackp = 0x8064f00, stacknxt = 0x8064f5c "/home/thomas/tmp/gcc/hurd/master/libstdc++-v3/include/ext/pb_ds/detail/bin_search_tree_/constructors_destructor_fn_imps.hpp", stacknleft = 416}
-    #18 0x0804b51c in evaltree (n=0x80618fc, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = 0x804b830 <evalfor>
-            isor = <optimized out>
-            status = <optimized out>
-    #19 0x0804b509 in evaltree (n=0x80618fc, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #20 0x0804b509 in evaltree (n=0x8064f44, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #21 0x0804be81 in evalstring (
-        s=0x1025eb5 "if [ ! -f stamp-pb ]; then \\\n    cd ./ext/pb_ds && for h in /home/thomas/tmp/gcc/hurd/master/libstdc++-v3/include/ext/pb_ds/detail/bin_search_tree_/constructors_destructor_fn_imps.hpp /home/thomas/tmp"..., flags=0, 
-        flags@entry=4) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:168
-            n = <optimized out>
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "if", stacknleft = 504}
-            status = 0
-    #22 0x08049b2f in main (argc=3, argv=0x1024bb4) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:174
-            shinit = <optimized out>
-            state = 4
-            jmploc = {loc = {{__jmpbuf = {18702324, 142560, 134607808, 16927544, 16927472, 134519464}, __mask_was_saved = 0, __saved_mask = 18702324}}}
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "if", stacknleft = 504}
-            login = <optimized out>
-
-    (gdb) print _hurd_global_sigstate
-    $1 = (struct hurd_sigstate *) 0x121b808
-    (gdb) print *_hurd_global_sigstate
-    $2 = {critical_section_lock = 0, lock = 0, thread = 0, next = 0x0, blocked = 4294967295, pending = 0, actions = {{__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 11 times>, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, 
-          sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {
-            sa_handler = 0x8056260 <onsig>, sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 12 times>}, sigaltstack = {
-        ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 33 times>}, suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, 
-      cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_siglock
-    $3 = {held = 0, lock = 0, name = 0x0, queue = {head = 0x0, tail = 0x0}, holder = 0x0}
-    (gdb) print _hurd_sigstates
-    $4 = (struct hurd_sigstate *) 0x121b008
-    (gdb) print *_hurd_sigstates
-    $5 = {critical_section_lock = 0, lock = 0, thread = 98, next = 0x1225808, blocked = 0, pending = 0, actions = {{__sigaction_handler = {sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 32 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, 
-          error = 0} <repeats 20 times>, {exc = 0, exc_code = 17169692, exc_subcode = 1, code = 1, error = EKERN_INVALID_ADDRESS}, {exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 12 times>}, suspended = 0, 
-      intr_port = 105, context = 0x0, active_resources = 0x10246a0, cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_self_sigstate()
-    $6 = (struct hurd_sigstate *) 0x121b008
-    (gdb) print *_hurd_self_sigstate()
-    warning: Can't wait for pid 5022: Keine Kind-Prozesse
-    $7 = {critical_section_lock = 0, lock = 0, thread = 98, next = 0x1225808, blocked = 0, pending = 0, actions = {{__sigaction_handler = {sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 32 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, 
-          error = 0} <repeats 20 times>, {exc = 0, exc_code = 17169692, exc_subcode = 1, code = 1, error = EKERN_INVALID_ADDRESS}, {exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 12 times>}, suspended = 0, 
-      intr_port = 105, context = 0x0, active_resources = 0x10246a0, cancel = 0, cancel_hook = 0}
-
-
-## 5024
-
-    Thread 2 (Thread 5024.2):
-    #0  0x0105c7cc in mach_msg_trap () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0105cfc9 in __mach_msg (msg=0x1222f90, option=3, send_size=32, rcv_size=4096, rcv_name=129, timeout=0, notify=0) at msg.c:110
-            ret = <optimized out>
-    #2  0x0105d6f9 in __mach_msg_server_timeout (demux=0x106df00 <msgport_server>, max_size=4096, rcv_name=129, option=0, timeout=0) at msgserver.c:151
-            request = 0x1223fa0
-            reply = 0x1222f90
-            mr = <optimized out>
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #3  0x0105d7cb in __mach_msg_server (demux=0x106df00 <msgport_server>, max_size=4096, rcv_name=129) at msgserver.c:196
-    No locals.
-    #4  0x0106decf in _hurd_msgport_receive () at msgportdemux.c:68
-    No locals.
-    #5  0x66688b92 in ?? ()
-    No symbol table info available.
-    #6  0x00000000 in ?? ()
-    No symbol table info available.
-    
-    Thread 1 (Thread 5024.1):
-    #0  0x0105c81c in swtch_pri () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2
-    No locals.
-    #1  0x0105e0a4 in __spin_lock_solid (lock=0x121b80c) at spin-solid.c:27
-    No locals.
-    #2  0x01072e57 in __spin_lock (__lock=<optimized out>) at ../mach/lock-intern.h:55
-    No locals.
-    #3  _hurd_sigstate_lock (ss=0x121b008) at hurdsig.c:172
-    No locals.
-    #4  0x0111051c in _hurd_critical_section_unlock (our_lock=<optimized out>) at ../hurd/hurd/signal.h:235
-    No locals.
-    #5  __fork () at ../sysdeps/mach/hurd/fork.c:707
-            env = {{__jmpbuf = {18702324, 18980808, 0, 16926552, 16926180, 17891103}, __mask_was_saved = 0, __saved_mask = 5}}
-            pid = 0
-            err = <optimized out>
-            __PRETTY_FUNCTION__ = "__fork"
-            ss = 0x121b008
-            threads = 0x0
-            nthreads = 0
-            stopped = 1
-            i = 6
-    #6  0x08051620 in forkshell (jp=jp@entry=0x8066840, n=0x8064e04, mode=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:934
-            pid = <optimized out>
-    #7  0x0804bbf8 in evalpipe (n=0x8064d4c, flags=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:544
-            jp = 0x8066840
-            lp = 0x8064d64
-            pipelen = <optimized out>
-            prevfd = <optimized out>
-            pip = {3, -1}
-    #8  0x0804b509 in evaltree (n=n@entry=0x8064d4c, flags=flags@entry=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #9  0x0804c7df in evaltreenr (flags=1, n=0x8064d4c) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:324
-    No locals.
-    #10 evalbackcmd (n=n@entry=0x8064d4c, result=result@entry=0x1024870) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:606
-            pip = {3, 4}
-            jp = 0x8066840
-    #11 0x0804f43b in expbackq (flag=68, cmd=0x8064d4c) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/expand.c:529
-            i = <optimized out>
-            buf = "\364_\035\001\340h\006\b \307\001\000\354H\002\001\065\360\r\001\214\211\035\001\002\000\000\000\b\000\000\000@\000\000\000\020\002\000\000@\000\000\000\374\001\000\000\225\343\033\001̈\035\001\252\313\033\001\264\345\033\001\000\002\000\000\000\000\000\000\000\000\000\000\254\343\033\001\200\210\035\001 \307\001\000Ĉ\035\001<N\006\b\000\000\000\000\214I\002\001\000\000\000\000\302a\005\b\000\000\000\000\003\000\000\000\064J\002\001\b\000\000"
-            dest = <optimized out>
-            startloc = 11
-            in = {fd = -1, buf = 0x0, nleft = 0, jp = 0x0}
-            p = <optimized out>
-            syntax = 0x805b922 ""
-            smark = {stackp = 0x80668e8, stacknxt = 0x80668f4 "build_name=./det/bin/sed", stacknleft = 496}
-    #12 argstr (p=0x8064e28 "", flag=68, flag@entry=4) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/expand.c:350
-            spclchars = "=:\210\203\201\202\204\207"
-            reject = 0x8059b41 ":\210\203\201\202\204\207"
-            c = <optimized out>
-            breakall = 0
-            inquotes = 0
-            length = 0
-            startloc = 68
-    #13 0x0804f682 in expandarg (arg=arg@entry=0x8064e2c, arglist=arglist@entry=0x1024994, flag=flag@entry=4) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/expand.c:193
-            sp = <optimized out>
-            p = <optimized out>
-    #14 0x0804c1d4 in evalcommand (cmd=0x8064e3c, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:733
-            spp = 0x1024994
-            p = <optimized out>
-            localvar_stop = 0x0
-            redir_stop = 0x0
-            smark = {stackp = 0x8066440, stacknxt = 0x806663c  <incomplete sequence \321>, stacknleft = 0}
-            argp = 0x8064e2c
-            arglist = {list = 0x0, lastp = 0x102498c}
-            varlist = {list = 0x0, lastp = 0x1024994}
-            argv = 0x80668f0
-            argc = <optimized out>
-            sp = <optimized out>
-            cmdentry = {cmdtype = 2, u = {index = 134584628, cmd = 0x8059934, func = 0x8059934}}
-            jp = <optimized out>
-            lastarg = 0x0
-            path = 0x1028633 "PATH=/home/thomas/shared/command:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
-            spclbltin = <optimized out>
-            execcmd = <optimized out>
-            status = 0
-            nargv = <optimized out>
-    #15 0x0804b509 in evaltree (n=0x8064e3c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #16 0x0804b586 in evaltree (n=0x8064f2c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #17 0x0804b8f1 in evalfor (n=n@entry=0x80618fc, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:392
-            arglist = {list = 0x8064fdc, lastp = 0x8066634}
-            argp = <optimized out>
-            sp = 0x806552c
-            smark = {stackp = 0x8064f00, stacknxt = 0x8064f5c "/home/thomas/tmp/gcc/hurd/master/libstdc++-v3/include/ext/pb_ds/detail/bin_search_tree_/constructors_destructor_fn_imps.hpp", stacknleft = 416}
-    #18 0x0804b51c in evaltree (n=0x80618fc, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = 0x804b830 <evalfor>
-            isor = <optimized out>
-            status = <optimized out>
-    #19 0x0804b509 in evaltree (n=0x80618fc, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #20 0x0804b509 in evaltree (n=0x8064f44, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #21 0x0804be81 in evalstring (
-        s=0x1025eb5 "if [ ! -f stamp-pb ]; then \\\n    cd ./ext/pb_ds && for h in /home/thomas/tmp/gcc/hurd/master/libstdc++-v3/include/ext/pb_ds/detail/bin_search_tree_/constructors_destructor_fn_imps.hpp /home/thomas/tmp"..., flags=0, 
-        flags@entry=4) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:168
-            n = <optimized out>
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "if", stacknleft = 504}
-            status = 0
-    #22 0x08049b2f in main (argc=3, argv=0x1024bb4) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:174
-            shinit = <optimized out>
-            state = 4
-            jmploc = {loc = {{__jmpbuf = {18702324, 142560, 134607808, 16927544, 16927472, 134519464}, __mask_was_saved = 0, __saved_mask = 18702324}}}
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "if", stacknleft = 504}
-            login = <optimized out>
-
-    (gdb) print _hurd_global_sigstate
-    $1 = (struct hurd_sigstate *) 0x121b808
-    (gdb) print *_hurd_global_sigstate
-    $2 = {critical_section_lock = 0, lock = 1, thread = 0, next = 0x0, blocked = 4294967295, pending = 0, actions = {{__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 11 times>, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, 
-          sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {
-            sa_handler = 0x8056260 <onsig>, sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 12 times>}, sigaltstack = {
-        ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 33 times>}, suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, 
-      cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_siglock
-    $3 = {held = 0, lock = 0, name = 0x0, queue = {head = 0x0, tail = 0x0}, holder = 0x0}
-    (gdb) print _hurd_sigstates
-    $4 = (struct hurd_sigstate *) 0x121b008
-    (gdb) print *_hurd_sigstates
-    $5 = {critical_section_lock = 1, lock = 0, thread = 98, next = 0x1225808, blocked = 0, pending = 0, actions = {{__sigaction_handler = {sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 32 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, 
-          error = 0} <repeats 33 times>}, suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_self_sigstate()
-    $6 = (struct hurd_sigstate *) 0x121b008
-    (gdb) print *_hurd_self_sigstate()
-    warning: Can't wait for pid 5024: Keine Kind-Prozesse
-    $7 = {critical_section_lock = 1, lock = 0, thread = 98, next = 0x1225808, blocked = 0, pending = 0, actions = {{__sigaction_handler = {sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 32 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, 
-          error = 0} <repeats 33 times>}, suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, cancel = 0, cancel_hook = 0}
-    (gdb) thread 1
-    [Switching to thread 1 (Thread 5024.1)]
-    #0  0x0105c81c in swtch_pri () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2
-    2       kernel_trap (__swtch_pri,-59,1)
-    (gdb) frame 5
-    #5  __fork () at ../sysdeps/mach/hurd/fork.c:707
-    707       _hurd_critical_section_unlock (ss);
-    (gdb) print ss
-    $8 = (struct hurd_sigstate * volatile) 0x121b008
-    (gdb) print _hurd_sigstates->next
-    $9 = (struct hurd_sigstate *) 0x1225808
-    (gdb) print *_hurd_sigstates->next
-    $10 = {critical_section_lock = 0, lock = 0, thread = 131, next = 0x0, blocked = 0, pending = 0, actions = {{__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 33 times>}, sigaltstack = {
-        ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 33 times>}, suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, 
-      cancel = 0, cancel_hook = 0}
-
-
-# IV
-
-      PID  UID  PPID  PGrp  Sess TH  Vmem   RSS %CPU     User   System Args
-    13103 1000 13085  1702   457  2  146M 1.96M  0.0  0:00.64  0:02.75 /bin/dash /home/thomas/tmp/gcc/hurd/master/libjava/configure --cache-file=./c
-    16929 1000 13103  1702   457  2  146M 1.09M  0.0  0:00.26  0:01.23 /bin/dash ./config.status
-    18200 1000 16929  1702   457  2  146M  284K 91.0  0:41.74    75min /bin/dash ./config.status
-
-
-## 13103
-
-    Thread 2 (Thread 13103.2):
-    #0  0x0105b7cc in mach_msg_trap () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0105bfc9 in __mach_msg (msg=0x1221f90, option=3, send_size=32, rcv_size=4096, rcv_name=75, timeout=0, notify=0) at msg.c:110
-            ret = <optimized out>
-    #2  0x0105c6f9 in __mach_msg_server_timeout (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=75, option=0, timeout=0)
-        at msgserver.c:151
-            request = 0x1222fa0
-            reply = 0x1221f90
-            mr = <optimized out>
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #3  0x0105c7cb in __mach_msg_server (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=75) at msgserver.c:196
-    No locals.
-    #4  0x0106cecf in _hurd_msgport_receive () at msgportdemux.c:68
-    No locals.
-    #5  0x66688b92 in ?? ()
-    No symbol table info available.
-    
-    Thread 1 (Thread 13103.1):
-    #0  0x01078a5c in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:134
-            err = <optimized out>
-            err = <optimized out>
-            user_option = 3
-            user_timeout = 0
-            m = 0x10244d8
-            msgh_bits = 5395
-            remote_port = 74
-            msgid = 24020
-            __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg"
-    #1  0x011f99df in __proc_wait (process=74, pid=-1, options=0, status=0x1024660, sigcode=0x102460c, rusage=0x10245a8, pid_status=0x1024610)
-        at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/hurd/RPC_proc_wait.c:182
-            Mess = {In = {Head = {msgh_bits = 5395, msgh_size = 0, msgh_remote_port = 74, msgh_local_port = 77, msgh_seqno = 0, msgh_id = 24020}, 
-                pidType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, 
-                  msgt_unused = 0}, pid = -1, optionsType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, 
-                  msgt_deallocate = 0, msgt_unused = 0}, options = 0}, Out = {Head = {msgh_bits = 5395, msgh_size = 0, msgh_remote_port = 74, 
-                  msgh_local_port = 77, msgh_seqno = 0, msgh_id = 24020}, RetCodeType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, 
-                  msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, RetCode = -1, statusType = {msgt_name = 2, 
-                  msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, status = 0, 
-                sigcodeType = {msgt_name = 0, msgt_size = 0, msgt_number = 0, msgt_inline = 0, msgt_longform = 0, msgt_deallocate = 0, 
-                  msgt_unused = 0}, sigcode = 40, rusageType = {msgt_name = 0, msgt_size = 18, msgt_number = 0, msgt_inline = 0, 
-                  msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, rusage = {ru_utime = {tv_sec = 32, tv_usec = 17152883}, ru_stime = {
-                    tv_sec = 16925996, tv_usec = 17687868}, ru_maxrss = 17243652, ru_ixrss = 18698228, ru_idrss = 17243488, ru_isrss = 18698228, 
-                  ru_minflt = 16926376, ru_majflt = 17888569, ru_nswap = 18980872, ru_inblock = 19046400, ru_oublock = 8, ru_msgsnd = 17, 
-                  ru_msgrcv = 16926312, ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}, pid_statusType = {msgt_name = 0, msgt_size = 0, 
-                  msgt_number = 0, msgt_inline = 0, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, pid_status = 17243652}}
-            msg_result = <optimized out>
-            msgh_size = <optimized out>
-    #2  0x0110e49e in __wait4 (pid=-1, stat_loc=0x1024660, options=0, usage=0x10245a8) at ../sysdeps/mach/hurd/wait4.c:35
-            __p = 0x1219fac
-            __link = {resource = {next = 0x0, prevp = 0x1219fb0}, thread = {next = 0x0, prevp = 0x121a45c}, 
-              cleanup = 0x1084b90 <_hurd_port_cleanup>, cleanup_data = 0x4a}
-            port = 74
-            __result = <optimized out>
-            dead = <optimized out>
-            err = <optimized out>
-            ignored = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 18689656, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 134541677, 
-              ru_idrss = 18689652, ru_isrss = 134585154, ru_minflt = 0, ru_majflt = 75, ru_nswap = 31, ru_inblock = 31, ru_oublock = 31, 
-              ru_msgsnd = 0, ru_msgrcv = 18976712, ru_nsignals = 16926376, ru_nvcsw = 268509186, ru_nivcsw = 18698228}
-            sigcode = 31
-            dummy = 16926004
-    #3  0x0110e2c7 in __wait3 (stat_loc=stat_loc@entry=..., options=options@entry=0, usage=usage@entry=0x0)
-        at ../sysdeps/unix/bsd/bsd4.4/wait3.c:34
-    No locals.
-    #4  0x0805028a in waitproc (status=0x1024660, block=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:1139
-            mask = 1
-            oldmask = 0
-            flags = 0
-            err = <optimized out>
-    #5  dowait (block=block@entry=1, job=job@entry=0x80638b0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:1016
-            status = <optimized out>
-            jp = <optimized out>
-            thisjob = 0x0
-            state = <optimized out>
-    #6  0x080518dc in waitforjob (jp=jp@entry=0x80638b0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:976
-            st = <optimized out>
-    #7  0x0804c470 in evalcommand (cmd=0x808576c, flags=2) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:824
-            localvar_stop = 0x0
-            redir_stop = 0x0
-            smark = {stackp = 0x8085d18, stacknxt = 0x8085e44 "/bin/dash", stacknleft = 208}
-            argp = <optimized out>
-            arglist = {list = 0x8085e54, lastp = 0x8085e6c}
-            varlist = {list = 0x0, lastp = 0x1024724}
-            argv = 0x8085e80
-            argc = <optimized out>
-            sp = <optimized out>
-            cmdentry = {cmdtype = 0, u = {index = -1, cmd = 0xffffffff, func = 0xffffffff}}
-            jp = 0x80638b0
-            lastarg = 0x0
-            path = 0x1027dd4 "/home/thomas/shared/command:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
-            spclbltin = -1
-            execcmd = 0
-            status = 0
-            nargv = <optimized out>
-    #8  0x0804b509 in evaltree (n=0x808576c, flags=flags@entry=2) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #9  0x0804b586 in evaltree (n=0x80857c4, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 1
-            status = <optimized out>
-    #10 0x0804b509 in evaltree (n=0x80857c4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #11 0x0804b586 in evaltree (n=0x8085d7c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #12 0x0804b586 in evaltree (n=0x8085e2c, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #13 0x0804b509 in evaltree (n=0x8085e2c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #14 0x08051cbc in cmdloop (top=top@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:245
-            skip = <optimized out>
-            n = <optimized out>
-            smark = {stackp = 0x80654d0, stacknxt = 0x80654ec "if", stacknleft = 480}
-            inter = <optimized out>
-            status = 0
-            numeof = 0
-    #15 0x08051e27 in dotcmd (argc=2, argv=0x80654e0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:337
-            status = 0
-    #16 0x0804bf47 in evalbltin (cmd=0x805afe0, argc=argc@entry=2, argv=argv@entry=0x80654e0, flags=flags@entry=0)
-        at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:900
-            savecmdname = 0x102500a "/home/thomas/tmp/gcc/hurd/master/libjava/configure"
-            savehandler = 0x1024ae0
-            jmploc = {loc = {{__jmpbuf = {0, 2, 1, 134632672, 16927008, 134528761}, __mask_was_saved = 0, __saved_mask = 0}}}
-            status = <optimized out>
-            i = 0
-    #17 0x0804c5b1 in evalcommand (cmd=0x8064734, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:840
-            localvar_stop = 0x0
-            redir_stop = 0x0
-            smark = {stackp = 0x80645e0, stacknxt = 0x80647b4 ".", stacknleft = 40}
-            argp = <optimized out>
-            arglist = {list = 0x80647bc, lastp = 0x80654d4}
-            varlist = {list = 0x0, lastp = 0x10249c4}
-            argv = 0x80654e0
-            argc = 2
-            sp = <optimized out>
-            cmdentry = {cmdtype = 2, u = {index = 134590432, cmd = 0x805afe0, func = 0x805afe0}}
-            jp = <optimized out>
-            lastarg = 0x0
-            path = <optimized out>
-            spclbltin = 1
-            execcmd = 0
-            status = 0
-            nargv = <optimized out>
-    #18 0x0804b509 in evaltree (n=0x8064734, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #19 0x0804b509 in evaltree (n=0x8064734, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #20 0x0804b586 in evaltree (n=0x806478c, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #21 0x0804b509 in evaltree (n=0x806478c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #22 0x08051cbc in cmdloop (top=top@entry=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:245
-            skip = <optimized out>
-            n = <optimized out>
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "eval", stacknleft = 504}
-            inter = <optimized out>
-            status = 0
-            numeof = 0
-    #23 0x08049b42 in main (argc=15, argv=0x1024b84) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:178
-            shinit = <optimized out>
-            state = 4
-            jmploc = {loc = {{__jmpbuf = {18698228, 142560, 134607808, 16927496, 16927424, 134519464}, __mask_was_saved = 0, 
-                  __saved_mask = 18698228}}}
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "eval", stacknleft = 504}
-            login = <optimized out>
-
-    (gdb) print _hurd_global_sigstate
-    $1 = (struct hurd_sigstate *) 0x121a808
-    (gdb) print *_hurd_global_sigstate
-    $2 = {critical_section_lock = 0, lock = 0, thread = 0, next = 0x0, blocked = 4294967295, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, 
-            sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, 
-            sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, 
-            sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, sa_sigaction = 0x8056260 <onsig>}, 
-          sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0x8056260 <onsig>, sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 12 times>}, sigaltstack = {ss_sp = 0x0, 
-        ss_size = 0, ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, 
-          error = 0} <repeats 20 times>, {exc = 0, exc_code = 19013424, exc_subcode = 85056, code = 1, error = 17261792}, {exc = 0, exc_code = 0, 
-          exc_subcode = 0, code = 0, error = 0} <repeats 12 times>}, suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, 
-      cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_siglock
-    $3 = {held = 0, lock = 0, name = 0x0, queue = {head = 0x0, tail = 0x0}, holder = 0x0}
-    (gdb) print _hurd_sigstates
-    $4 = (struct hurd_sigstate *) 0x1224808
-    (gdb) print *_hurd_sigstates
-    $5 = {critical_section_lock = 0, lock = 0, thread = 76, next = 0x121a008, blocked = 0, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 33 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, 
-        ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 33 times>}, 
-      suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_sigstates->next
-    $6 = (struct hurd_sigstate *) 0x121a008
-    (gdb) print *_hurd_sigstates->next
-    $7 = {critical_section_lock = 0, lock = 0, thread = 49, next = 0x0, blocked = 0, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 0, sa_flags = 2} <repeats 32 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, 
-      pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 20 times>, {exc = 0, exc_code = 19013424, 
-          exc_subcode = 85056, code = 1, error = 17261792}, {exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 12 times>}, 
-      suspended = 0, intr_port = 74, context = 0x0, active_resources = 0x10245f0, cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_self_sigstate()
-    warning: Can't wait for pid 13103: Keine Kind-Prozesse
-    $8 = (struct hurd_sigstate *) 0x121a008
-
-
-## 16929
-
-    Thread 2 (Thread 16929.2):
-    #0  0x0105b7cc in mach_msg_trap () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0105bfc9 in __mach_msg (msg=0x1221f90, option=3, send_size=32, rcv_size=4096, rcv_name=86, timeout=0, notify=0) at msg.c:110
-            ret = <optimized out>
-    #2  0x0105c6f9 in __mach_msg_server_timeout (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=86, option=0, timeout=0)
-        at msgserver.c:151
-            request = 0x1222fa0
-            reply = 0x1221f90
-            mr = <optimized out>
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #3  0x0105c7cb in __mach_msg_server (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=86) at msgserver.c:196
-    No locals.
-    #4  0x0106cecf in _hurd_msgport_receive () at msgportdemux.c:68
-    No locals.
-    #5  0x66688b92 in ?? ()
-    No symbol table info available.
-    
-    Thread 1 (Thread 16929.1):
-    #0  0x01078a5c in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:134
-            err = <optimized out>
-            err = <optimized out>
-            user_option = 3
-            user_timeout = 0
-            m = 0x1024568
-            msgh_bits = 5395
-            remote_port = 82
-            msgid = 24020
-            __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg"
-    #1  0x011f99df in __proc_wait (process=82, pid=-1, options=0, status=0x10246f0, sigcode=0x102469c, rusage=0x1024638, pid_status=0x10246a0)
-        at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/hurd/RPC_proc_wait.c:182
-            Mess = {In = {Head = {msgh_bits = 5395, msgh_size = 132, msgh_remote_port = 82, msgh_local_port = 89, msgh_seqno = 0, 
-                  msgh_id = 24020}, pidType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, 
-                  msgt_deallocate = 0, msgt_unused = 0}, pid = -1, optionsType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, 
-                  msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, options = 0}, Out = {Head = {msgh_bits = 5395, msgh_size = 132, 
-                  msgh_remote_port = 82, msgh_local_port = 89, msgh_seqno = 0, msgh_id = 24020}, RetCodeType = {msgt_name = 2, msgt_size = 32, 
-                  msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, RetCode = -1, statusType = {
-                  msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, 
-                status = 0, sigcodeType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, 
-                  msgt_deallocate = 0, msgt_unused = 0}, sigcode = 0, rusageType = {msgt_name = 2, msgt_size = 32, msgt_number = 18, 
-                  msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, rusage = {ru_utime = {tv_sec = 0, tv_usec = 0}, 
-                  ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, ru_minflt = 0, ru_majflt = 0, 
-                  ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}, 
-                pid_statusType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, 
-                  msgt_unused = 0}, pid_status = 17243652}}
-            msg_result = <optimized out>
-            msgh_size = <optimized out>
-    #2  0x0110e49e in __wait4 (pid=-1, stat_loc=0x10246f0, options=0, usage=0x1024638) at ../sysdeps/mach/hurd/wait4.c:35
-            __p = 0x1219fac
-            __link = {resource = {next = 0x0, prevp = 0x1219fb0}, thread = {next = 0x0, prevp = 0x121a45c}, 
-              cleanup = 0x1084b90 <_hurd_port_cleanup>, cleanup_data = 0x52}
-            port = 82
-            __result = <optimized out>
-            dead = <optimized out>
-            err = <optimized out>
-            ignored = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, 
-              ru_isrss = 0, ru_minflt = 0, ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, 
-              ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}
-            sigcode = 0
-            dummy = 16926148
-    #3  0x0110e2c7 in __wait3 (stat_loc=stat_loc@entry=..., options=options@entry=0, usage=usage@entry=0x0)
-        at ../sysdeps/unix/bsd/bsd4.4/wait3.c:34
-    No locals.
-    #4  0x0805028a in waitproc (status=0x10246f0, block=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:1139
-            mask = 1
-            oldmask = 0
-            flags = 0
-            err = <optimized out>
-    #5  dowait (block=block@entry=1, job=job@entry=0x8063998) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:1016
-            status = <optimized out>
-            jp = <optimized out>
-            thisjob = 0x0
-            state = <optimized out>
-    #6  0x080518dc in waitforjob (jp=jp@entry=0x8063998) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:976
-            st = <optimized out>
-    #7  0x0804bc58 in evalpipe (n=0x807a114, flags=3) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:566
-            jp = 0x8063998
-            lp = 0x0
-            pipelen = <optimized out>
-            prevfd = <optimized out>
-            pip = {3, -1}
-    #8  0x0804b509 in evaltree (n=0x807a114, flags=flags@entry=2) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #9  0x0804b53b in evaltree (n=0x807a06c, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:283
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #10 0x0804b509 in evaltree (n=0x807a06c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #11 0x0804b586 in evaltree (n=0x807ab6c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #12 0x0804b586 in evaltree (n=0x807ac2c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #13 0x0804b586 in evaltree (n=0x807ad74, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #14 0x0804b586 in evaltree (n=0x807ae34, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #15 0x0804b586 in evaltree (n=0x807af74, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #16 0x0804b586 in evaltree (n=0x807b08c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #17 0x0804b586 in evaltree (n=0x807bd54, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #18 0x0804b8f1 in evalfor (n=n@entry=0x8079f04, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:392
-            arglist = {list = 0x8085fd4, lastp = 0x8086034}
-            argp = <optimized out>
-            sp = 0x808600c
-            smark = {stackp = 0x8084180, stacknxt = 0x8085edc "Makefile", stacknleft = 2056}
-    #19 0x0804b51c in evaltree (n=0x8079f04, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = 0x804b830 <evalfor>
-            isor = <optimized out>
-            status = <optimized out>
-    #20 0x0804b509 in evaltree (n=0x8079f04, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #21 0x0804b509 in evaltree (n=0x807bd6c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #22 0x0804b81b in evalcase (n=0x8079ae4, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:428
-            cp = 0x8079c74
-            patp = 0x8079c84
-            arglist = {list = 0x8085ed4, lastp = 0x8085ed4}
-            smark = {stackp = 0x8084180, stacknxt = 0x8085ec4 "depfiles:C", stacknleft = 2080}
-    #23 0x0804b509 in evaltree (n=0x8079ae4, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #24 0x0804b509 in evaltree (n=0x8079ae4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #25 0x0804b8f1 in evalfor (n=n@entry=0x80617f4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:392
-            arglist = {list = 0x8085d84, lastp = 0x8085ebc}
-            argp = <optimized out>
-            sp = 0x8085eb4
-            smark = {stackp = 0x8084180, stacknxt = 0x80857b4 ":F", stacknleft = 3888}
-    #26 0x0804b51c in evaltree (n=0x80617f4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = 0x804b830 <evalfor>
-            isor = <optimized out>
-            status = <optimized out>
-    #27 0x08051cbc in cmdloop (top=top@entry=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:245
-            skip = <optimized out>
-            n = <optimized out>
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "for", stacknleft = 504}
-            inter = <optimized out>
-            status = 0
-            numeof = 0
-    #28 0x08049b42 in main (argc=2, argv=0x1024ba4) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:178
-            shinit = <optimized out>
-            state = 4
-            jmploc = {loc = {{__jmpbuf = {18698228, 142560, 134607808, 16927528, 16927456, 134519464}, __mask_was_saved = 0, 
-                  __saved_mask = 18698228}}}
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "for", stacknleft = 504}
-            login = <optimized out>
-
-    (gdb) print _hurd_global_sigstate
-    $1 = (struct hurd_sigstate *) 0x121a808
-    (gdb) print *_hurd_global_sigstate
-    $2 = {critical_section_lock = 0, lock = 0, thread = 0, next = 0x0, blocked = 4294967295, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, 
-            sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, 
-            sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, 
-            sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, sa_sigaction = 0x8056260 <onsig>}, 
-          sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0x8056260 <onsig>, sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 12 times>}, sigaltstack = {ss_sp = 0x0, 
-        ss_size = 0, ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, 
-          error = 0} <repeats 20 times>, {exc = 0, exc_code = 19013424, exc_subcode = 85056, code = 1, error = 17261792}, {exc = 0, exc_code = 0, 
-          exc_subcode = 0, code = 0, error = 0} <repeats 12 times>}, suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, 
-      cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_siglock
-    $3 = {held = 0, lock = 0, name = 0x0, queue = {head = 0x0, tail = 0x0}, holder = 0x0}
-    (gdb) print _hurd_sigstates
-    $4 = (struct hurd_sigstate *) 0x1224808
-    (gdb) print *_hurd_sigstates
-    $5 = {critical_section_lock = 0, lock = 0, thread = 88, next = 0x121a008, blocked = 0, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 33 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, 
-        ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 33 times>}, 
-      suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_sigstates->next
-    $6 = (struct hurd_sigstate *) 0x121a008
-    (gdb) print *_hurd_sigstates->next
-    $7 = {critical_section_lock = 0, lock = 0, thread = 23, next = 0x0, blocked = 0, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 0, sa_flags = 2} <repeats 32 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, 
-      pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 20 times>, {exc = 0, exc_code = 19013424, 
-          exc_subcode = 85056, code = 1, error = 17261792}, {exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 12 times>}, 
-      suspended = 0, intr_port = 82, context = 0x0, active_resources = 0x1024680, cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_self_sigstate()
-    $8 = (struct hurd_sigstate *) 0x121a008
-
-
-## 18200
-
-    Thread 2 (Thread 18200.2):
-    #0  0x0105b7cc in mach_msg_trap () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0105bfc9 in __mach_msg (msg=0x1221f90, option=3, send_size=32, rcv_size=4096, rcv_name=86, timeout=0, notify=0) at msg.c:110
-            ret = <optimized out>
-    #2  0x0105c6f9 in __mach_msg_server_timeout (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=86, option=0, timeout=0)
-        at msgserver.c:151
-            request = 0x1222fa0
-            reply = 0x1221f90
-            mr = <optimized out>
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #3  0x0105c7cb in __mach_msg_server (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=86) at msgserver.c:196
-    No locals.
-    #4  0x0106cecf in _hurd_msgport_receive () at msgportdemux.c:68
-    No locals.
-    #5  0x66688b92 in ?? ()
-    No symbol table info available.
-    #6  0x00000000 in ?? ()
-    No symbol table info available.
-    
-    Thread 1 (Thread 18200.1):
-    #0  0x0105b81c in swtch_pri () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2
-    No locals.
-    #1  0x0105d0a4 in __spin_lock_solid (lock=0x121a80c) at spin-solid.c:27
-    No locals.
-    #2  0x01071e57 in __spin_lock (__lock=<optimized out>) at ../mach/lock-intern.h:55
-    No locals.
-    #3  _hurd_sigstate_lock (ss=0x121a008) at hurdsig.c:172
-    No locals.
-    #4  0x0110f51c in _hurd_critical_section_unlock (our_lock=<optimized out>) at ../hurd/hurd/signal.h:235
-    No locals.
-    #5  __fork () at ../sysdeps/mach/hurd/fork.c:707
-            env = {{__jmpbuf = {18698228, 18976712, 0, 16926520, 16926148, 17887007}, __mask_was_saved = 0, __saved_mask = 16926608}}
-            pid = 0
-            err = <optimized out>
-            __PRETTY_FUNCTION__ = "__fork"
-            ss = 0x121a008
-            threads = 0x0
-            nthreads = 0
-            stopped = 1
-            i = 6
-    #6  0x08051620 in forkshell (jp=jp@entry=0x8063998, n=0x807a1bc, mode=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:934
-            pid = <optimized out>
-    #7  0x0804bbf8 in evalpipe (n=0x807a114, flags=3) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:544
-            jp = 0x8063998
-            lp = 0x807a12c
-            pipelen = <optimized out>
-            prevfd = <optimized out>
-            pip = {3, -1}
-    #8  0x0804b509 in evaltree (n=0x807a114, flags=flags@entry=2) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #9  0x0804b53b in evaltree (n=0x807a06c, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:283
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #10 0x0804b509 in evaltree (n=0x807a06c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #11 0x0804b586 in evaltree (n=0x807ab6c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #12 0x0804b586 in evaltree (n=0x807ac2c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #13 0x0804b586 in evaltree (n=0x807ad74, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #14 0x0804b586 in evaltree (n=0x807ae34, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #15 0x0804b586 in evaltree (n=0x807af74, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #16 0x0804b586 in evaltree (n=0x807b08c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #17 0x0804b586 in evaltree (n=0x807bd54, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #18 0x0804b8f1 in evalfor (n=n@entry=0x8079f04, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:392
-            arglist = {list = 0x8085fd4, lastp = 0x8086034}
-            argp = <optimized out>
-            sp = 0x808600c
-            smark = {stackp = 0x8084180, stacknxt = 0x8085edc "Makefile", stacknleft = 2056}
-    #19 0x0804b51c in evaltree (n=0x8079f04, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = 0x804b830 <evalfor>
-            isor = <optimized out>
-            status = <optimized out>
-    #20 0x0804b509 in evaltree (n=0x8079f04, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #21 0x0804b509 in evaltree (n=0x807bd6c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #22 0x0804b81b in evalcase (n=0x8079ae4, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:428
-            cp = 0x8079c74
-            patp = 0x8079c84
-            arglist = {list = 0x8085ed4, lastp = 0x8085ed4}
-            smark = {stackp = 0x8084180, stacknxt = 0x8085ec4 "depfiles:C", stacknleft = 2080}
-    #23 0x0804b509 in evaltree (n=0x8079ae4, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #24 0x0804b509 in evaltree (n=0x8079ae4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #25 0x0804b8f1 in evalfor (n=n@entry=0x80617f4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:392
-            arglist = {list = 0x8085d84, lastp = 0x8085ebc}
-            argp = <optimized out>
-            sp = 0x8085eb4
-            smark = {stackp = 0x8084180, stacknxt = 0x80857b4 ":F", stacknleft = 3888}
-    #26 0x0804b51c in evaltree (n=0x80617f4, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = 0x804b830 <evalfor>
-            isor = <optimized out>
-            status = <optimized out>
-    #27 0x08051cbc in cmdloop (top=top@entry=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:245
-            skip = <optimized out>
-            n = <optimized out>
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "for", stacknleft = 504}
-            inter = <optimized out>
-            status = 0
-            numeof = 0
-    #28 0x08049b42 in main (argc=2, argv=0x1024ba4) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:178
-            shinit = <optimized out>
-            state = 4
-            jmploc = {loc = {{__jmpbuf = {18698228, 142560, 134607808, 16927528, 16927456, 134519464}, __mask_was_saved = 0, 
-                  __saved_mask = 18698228}}}
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "for", stacknleft = 504}
-            login = <optimized out>
-
-    (gdb) print _hurd_global_sigstate
-    $1 = (struct hurd_sigstate *) 0x121a808
-    (gdb) print *_hurd_global_sigstate
-    $2 = {critical_section_lock = 0, lock = 1, thread = 0, next = 0x0, blocked = 4294967295, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, 
-            sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, 
-            sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, 
-            sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, sa_sigaction = 0x8056260 <onsig>}, 
-          sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0x8056260 <onsig>, sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 12 times>}, sigaltstack = {ss_sp = 0x0, 
-        ss_size = 0, ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, 
-          error = 0} <repeats 20 times>, {exc = 0, exc_code = 19013424, exc_subcode = 85056, code = 1, error = 17261792}, {exc = 0, exc_code = 0, 
-          exc_subcode = 0, code = 0, error = 0} <repeats 12 times>}, suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, 
-      cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_siglock
-    $3 = {held = 0, lock = 0, name = 0x0, queue = {head = 0x0, tail = 0x0}, holder = 0x0}
-    (gdb) print _hurd_sigstates
-    $4 = (struct hurd_sigstate *) 0x121a008
-    (gdb) print *_hurd_sigstates
-    $5 = {critical_section_lock = 1, lock = 0, thread = 23, next = 0x1224808, blocked = 0, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 0, sa_flags = 2} <repeats 32 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, 
-      pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 20 times>, {exc = 0, exc_code = 19013424, 
-          exc_subcode = 85056, code = 1, error = 17261792}, {exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 12 times>}, 
-      suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_sigstates->next
-    $6 = (struct hurd_sigstate *) 0x1224808
-    (gdb) print *_hurd_sigstates->next
-    $7 = {critical_section_lock = 0, lock = 0, thread = 88, next = 0x0, blocked = 0, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 33 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, 
-        ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 33 times>}, 
-      suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_self_sigstate()
-    $8 = (struct hurd_sigstate *) 0x121a008
-
-
-# V
-
-      PID  UID  PPID  PGrp  Sess TH  Vmem   RSS %CPU     User   System Args
-     9057 1000 21254  1703   457  2  146M  944K  0.0  0:00.00  0:00.03 /bin/dash -c r=`${PWDCMD-pwd}`; export r; \^Ks=`cd ../master; ${PWDCMD-pwd}`;
-     9076 1000  9057  1703   457  2  146M 1.41M  0.0  0:00.31  0:00.94 /bin/dash /home/thomas/tmp/gcc/hurd/master/libffi/configure --cache-file=./co
-    10360 1000  9076  1703   457  2  146M  492K  0.0  0:00.00  0:00.00 /bin/dash /home/thomas/tmp/gcc/hurd/master/libffi/configure --cache-file=./co
-    10362 1000 10360  1703   457  2  146M  200K 87.2  0:02.91  4:40.12 /bin/dash /home/thomas/tmp/gcc/hurd/master/libffi/configure --cache-file=./co
-
-
-## 9057
-
-    Thread 2 (Thread 9057.2):
-    #0  0x0105c7cc in mach_msg_trap () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0105cfc9 in __mach_msg (msg=0x1221f90, option=3, send_size=32, rcv_size=4096, rcv_name=59, timeout=0, notify=0) at msg.c:110
-            ret = <optimized out>
-    #2  0x0105d6f9 in __mach_msg_server_timeout (demux=0x106df00 <msgport_server>, max_size=4096, rcv_name=59, option=0, timeout=0)
-        at msgserver.c:151
-            request = 0x1222fa0
-            reply = 0x1221f90
-            mr = <optimized out>
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #3  0x0105d7cb in __mach_msg_server (demux=0x106df00 <msgport_server>, max_size=4096, rcv_name=59) at msgserver.c:196
-    No locals.
-    #4  0x0106decf in _hurd_msgport_receive () at msgportdemux.c:68
-    No locals.
-    #5  0x66688b92 in ?? ()
-    No symbol table info available.
-    
-    Thread 1 (Thread 9057.1):
-    #0  0x01079a5c in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:134
-            err = <optimized out>
-            err = <optimized out>
-            user_option = 3
-            user_timeout = 0
-            m = 0x10247f8
-            msgh_bits = 5395
-            remote_port = 27
-            msgid = 24020
-            __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg"
-    #1  0x011f99df in __proc_wait (process=27, pid=-1, options=0, status=0x1024980, sigcode=0x102492c, rusage=0x10248c8, pid_status=0x1024930)
-        at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/hurd/RPC_proc_wait.c:182
-            Mess = {In = {Head = {msgh_bits = 5395, msgh_size = 0, msgh_remote_port = 27, msgh_local_port = 68, msgh_seqno = 0, msgh_id = 24020}, 
-                pidType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, 
-                  msgt_unused = 0}, pid = -1, optionsType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, 
-                  msgt_deallocate = 0, msgt_unused = 0}, options = 0}, Out = {Head = {msgh_bits = 5395, msgh_size = 0, msgh_remote_port = 27, 
-                  msgh_local_port = 68, msgh_seqno = 0, msgh_id = 24020}, RetCodeType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, 
-                  msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, RetCode = -1, statusType = {msgt_name = 2, 
-                  msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, status = 0, 
-                sigcodeType = {msgt_name = 0, msgt_size = 0, msgt_number = 0, msgt_inline = 0, msgt_longform = 0, msgt_deallocate = 0, 
-                  msgt_unused = 0}, sigcode = 40, rusageType = {msgt_name = 0, msgt_size = 18, msgt_number = 0, msgt_inline = 0, 
-                  msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, rusage = {ru_utime = {tv_sec = 32, tv_usec = 17156979}, ru_stime = {
-                    tv_sec = 16926796, tv_usec = 17691964}, ru_maxrss = 17247748, ru_ixrss = 18702324, ru_idrss = 17247584, ru_isrss = 18702324, 
-                  ru_minflt = 16927176, ru_majflt = 17892665, ru_nswap = 18980872, ru_inblock = 19046400, ru_oublock = 8, ru_msgsnd = 17, 
-                  ru_msgrcv = 16927112, ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}, pid_statusType = {msgt_name = 0, msgt_size = 0, 
-                  msgt_number = 0, msgt_inline = 0, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, pid_status = 17247748}}
-            msg_result = <optimized out>
-            msgh_size = <optimized out>
-    #2  0x0110f49e in __wait4 (pid=-1, stat_loc=0x1024980, options=0, usage=0x10248c8) at ../sysdeps/mach/hurd/wait4.c:35
-            __p = 0x1219fac
-            __link = {resource = {next = 0x0, prevp = 0x1219fb0}, thread = {next = 0x0, prevp = 0x121a45c}, 
-              cleanup = 0x1085b90 <_hurd_port_cleanup>, cleanup_data = 0x1b}
-            port = 27
-            __result = <optimized out>
-            dead = <optimized out>
-            err = <optimized out>
-            ignored = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 18693752, tv_usec = 134639448}, ru_maxrss = 17693790, 
-              ru_ixrss = 134541780, ru_idrss = 18693748, ru_isrss = 48, ru_minflt = 0, ru_majflt = 75, ru_nswap = 31, ru_inblock = 31, 
-              ru_oublock = 31, ru_msgsnd = 0, ru_msgrcv = 18976712, ru_nsignals = 16927176, ru_nvcsw = 0, ru_nivcsw = 18702324}
-            sigcode = 31
-            dummy = 16926804
-    #3  0x0110f2c7 in __wait3 (stat_loc=stat_loc@entry=..., options=options@entry=0, usage=usage@entry=0x0)
-        at ../sysdeps/unix/bsd/bsd4.4/wait3.c:34
-    No locals.
-    #4  0x0805028a in waitproc (status=0x1024980, block=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:1139
-            mask = 1
-            oldmask = 0
-            flags = 0
-            err = <optimized out>
-    #5  dowait (block=block@entry=1, job=job@entry=0x8067328) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:1016
-            status = <optimized out>
-            jp = <optimized out>
-            thisjob = 0x0
-            state = <optimized out>
-    #6  0x080518dc in waitforjob (jp=jp@entry=0x8067328) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:976
-            st = <optimized out>
-    #7  0x0804c470 in evalcommand (cmd=0x806725c, flags=2) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:824
-            localvar_stop = 0x0
-            redir_stop = 0x0
-            smark = {stackp = 0x8067128, stacknxt = 0x80672dc "/bin/dash", stacknleft = 72}
-            argp = <optimized out>
-            arglist = {list = 0x80672ec, lastp = 0x806ab74}
-            varlist = {list = 0x806abdc, lastp = 0x806abdc}
-            argv = 0x806ab80
-            argc = <optimized out>
-            sp = <optimized out>
-            cmdentry = {cmdtype = 0, u = {index = -1, cmd = 0xffffffff, func = 0xffffffff}}
-            jp = 0x8067328
-            lastarg = 0x0
-            path = 0x1027eb1 "/home/thomas/shared/command:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
-            spclbltin = -1
-            execcmd = 0
-            status = 0
-            nargv = <optimized out>
-    #8  0x0804b509 in evaltree (n=0x806725c, flags=flags@entry=2) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #9  0x0804b586 in evaltree (n=0x80672bc, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 1
-            status = <optimized out>
-    #10 0x0804b509 in evaltree (n=0x80672bc, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #11 0x0804be81 in evalstring (
-        s=0x10253ad "r=`${PWDCMD-pwd}`; export r; \\\ns=`cd ../master; ${PWDCMD-pwd}`; export s; \\\necho \"Checking multilib configuration for libffi...\"; \\\n/bin/dash ../master/mkinstalldirs i686-unknown-gnu0.3/libffi ; \\\n/ho"..., flags=0, flags@entry=4)
-        at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:168
-            n = <optimized out>
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "${PWDCMD-pwd}", stacknleft = 504}
-            status = 0
-    #12 0x08049b2f in main (argc=3, argv=0x1024bd4) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:174
-            shinit = <optimized out>
-            state = 4
-            jmploc = {loc = {{__jmpbuf = {18702324, 142560, 134607808, 16927576, 16927504, 134519464}, __mask_was_saved = 0, 
-                  __saved_mask = 18702324}}}
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "${PWDCMD-pwd}", stacknleft = 504}
-            login = <optimized out>
-
-    (gdb) print _hurd_global_sigstate
-    $1 = (struct hurd_sigstate *) 0x121a808
-    (gdb) print *_hurd_global_sigstate
-    $2 = {critical_section_lock = 0, lock = 0, thread = 0, next = 0x0, blocked = 4294967295, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, 
-          sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, 
-          sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 11 times>, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, 
-          sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, 
-          sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, 
-          sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 12 times>}, sigaltstack = {
-        ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, 
-          error = 0} <repeats 33 times>}, suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_siglock
-    $3 = {held = 0, lock = 0, name = 0x0, queue = {head = 0x0, tail = 0x0}, holder = 0x0}
-    (gdb) print _hurd_sigstates
-    $4 = (struct hurd_sigstate *) 0x1224808
-    (gdb) print *_hurd_sigstates
-    $5 = {critical_section_lock = 0, lock = 0, thread = 65, next = 0x121a008, blocked = 0, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 33 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, 
-        ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 33 times>}, 
-      suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_sigstates->next
-    $6 = (struct hurd_sigstate *) 0x121a008
-    (gdb) print *_hurd_sigstates->next
-    $7 = {critical_section_lock = 0, lock = 0, thread = 43, next = 0x0, blocked = 0, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 0, sa_flags = 2} <repeats 32 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, 
-      pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 33 times>}, suspended = 0, intr_port = 27, 
-      context = 0x0, active_resources = 0x1024910, cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_self_sigstate()
-    $8 = (struct hurd_sigstate *) 0x121a008
-
-
-## 9076
-
-Thread 2 (Thread 9076.2):
-#0  0x0105b7cc in mach_msg_trap () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-No locals.
-#1  0x0105bfc9 in __mach_msg (msg=0x1221f90, option=3, send_size=32, rcv_size=4096, rcv_name=75, timeout=0, notify=0) at msg.c:110
-        ret = <optimized out>
-#2  0x0105c6f9 in __mach_msg_server_timeout (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=75, option=0, timeout=0)
-    at msgserver.c:151
-        request = 0x1222fa0
-        reply = 0x1221f90
-        mr = <optimized out>
-        __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-#3  0x0105c7cb in __mach_msg_server (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=75) at msgserver.c:196
-No locals.
-#4  0x0106cecf in _hurd_msgport_receive () at msgportdemux.c:68
-No locals.
-#5  0x66688b92 in ?? ()
-No symbol table info available.
-
-Thread 1 (Thread 9076.1):
-#0  0x01078a5c in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:134
-        err = <optimized out>
-        err = <optimized out>
-        user_option = 3
-        user_timeout = 0
-        m = 0x1023b74
-        msgh_bits = 5395
-        remote_port = 94
-        msgid = 21001
-        __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg"
-#1  0x012091a5 in __io_read (io_object=94, data=0x1024480, dataCnt=0x1024484, offset=-1, amount=128)
-    at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/hurd/RPC_io_read.c:137
-        Mess = {In = {Head = {msgh_bits = 5395, msgh_size = 44, msgh_remote_port = 94, msgh_local_port = 77, msgh_seqno = 0, msgh_id = 21001}, 
-            offsetType = {msgt_name = 11, msgt_size = 64, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, 
-              msgt_unused = 0}, offset = -1, amountType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, 
-              msgt_deallocate = 0, msgt_unused = 0}, amount = 128}, Out = {Head = {msgh_bits = 5395, msgh_size = 44, msgh_remote_port = 94, 
-              msgh_local_port = 77, msgh_seqno = 0, msgh_id = 21001}, RetCodeType = {msgt_name = 11, msgt_size = 64, msgt_number = 1, 
-              msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, RetCode = -1, dataType = {msgtl_header = {
-                msgt_name = 255, msgt_size = 255, msgt_number = 4095, msgt_inline = 1, msgt_longform = 1, msgt_deallocate = 1, 
-                msgt_unused = 1}, msgtl_name = 8194, msgtl_size = 4097, msgtl_number = 128}, 
-            data = "_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*\nol_pipe | $SED '\\''s/.* //'\\'' | sort | uniq > $export_symbols\n\377flags ${wl}-soname $wl$sLL=\201/bin\201/sh\203\nCC\201=\"\202\001CC=\"\nCXX\201=\"\202\001CXX=\"\nGFORTRAN\201=\"\202\001GFORTRAN=\"\nGCJ\201\244\211\a\001GCJ=\"\nAMDEP_T"...}}
-        msg_result = <optimized out>
-        msgh_size = <optimized out>
-#2  0x0107d321 in readfd (port=94) at fd-read.c:34
-        nbytes = 0x68018222
-        nread = 1031894131
-        data = 0x6f680a22 <Address 0x6f680a22 out of bounds>
-        offset = 4427717263544709889
-#3  0x01083880 in _hurd_ctty_input (port=94, ctty=0, rpc=0x102448c) at ctty-input.c:32
-        err = <optimized out>
-#4  0x0107cd44 in _hurd_fd_read (fd=0x1218c48, buf=0x1024570, offset=-1) at fd-read.c:39
-        __ulink = {resource = {next = 0x0, prevp = 0x1218c4c}, thread = {next = 0x0, prevp = 0x121a45c}, 
-          cleanup = 0x1084b90 <_hurd_port_cleanup>, cleanup_data = 0x5e}
-        __ctty_ulink = {resource = {next = 0x10244c0, prevp = 0x107c794}, thread = {next = 0x121a008, prevp = 0x5f}, cleanup = 0x2878, 
-          cleanup_data = 0x8063898}
-        ctty = 0
-        crit = <optimized out>
-        __result = 16927680
-        port = 94
-        err = <optimized out>
-        data = 0x1024570 "_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*\nol_pipe | $SED '\\''s/.* //'\\'' | sort | uniq > $export_symbols\n_flags ${wl}-soname $wl$s\374E\002\001Q"
-        nbytes = 0x1024528
-        nread = 128
-#5  0x01141652 in __libc_read (fd=8, buf=buf@entry=0x1024570, nbytes=nbytes@entry=128) at ../sysdeps/mach/hurd/read.c:27
-        descriptor = <error reading variable descriptor (DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.)>
-        err = <optimized out>
-#6  0x0804f480 in expbackq (flag=256, cmd=<optimized out>) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/expand.c:542
-        i = <optimized out>
-        buf = "_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*\nol_pipe | $SED '\\''s/.* //'\\'' | sort | uniq > $export_symbols\n_flags ${wl}-soname $wl$s"
-        dest = <optimized out>
-        startloc = 7784
-        in = {fd = 8, buf = 0x0, nleft = 0, jp = 0x8063898}
-        p = <optimized out>
-        syntax = 0x805b802 ""
-        smark = {stackp = 0x80914f0, 
-          stacknxt = 0x80914f4 "#\n# INIT-COMMANDS\n#\n\nsrcdir=\"../../../master/libffi\"\nhost=\"i686-unknown-gnu0.3\"\ntarget=\"i686-unknown-gnu0.3\"\nwith_multisubdir=\"\"\nwith_multisrctop=\"\"\nwith_target_subdir=\"i686-unknown-gnu0.3\"\nac_configu"..., stacknleft = 8704}
-#7  argstr (
-    p=0x808f72b "'\nprelink_cmds\201='\204'\nfile_list_spec\201='\204'\nvariables_saved_for_relink\201='\204'\nneed_lib_prefix\201='\204'\nneed_version\201='\204'\nversion_type\201='\204'\nrunpath_var\201='\204'\nshlibpath_var\201='\204'\nshlibpath_overrides_runpath\201='\204'\nli"..., 
-    flag=flag@entry=256) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/expand.c:350
-        spclchars = "=:\210\203\201\202\204\207"
-        reject = 0x8059b42 "\210\203\201\202\204\207"
-        c = <optimized out>
-        breakall = 0
-        inquotes = 0
-        length = 0
-        startloc = 256
-#8  0x0804f682 in expandarg (arg=0x80903a4, arglist=arglist@entry=0x0, flag=flag@entry=256)
-    at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/expand.c:193
-        sp = <optimized out>
-        p = <optimized out>
-#9  0x08056028 in openhere (redir=<optimized out>) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/redir.c:307
-        pip = {3, 4}
-        len = 0
-        p = 0x808ecec "#\n# INIT\201-COMMANDS\n#\n\nsrcdir\201=\"\202\001srcdir=\"\nhost\201=\"\202\001host=\"\ntarget\201=\"\202\001target=\"\nwith_multisubdir\201=\"\202\001with_multisubdir=\"\nwith_multisrctop\201=\"\202\001with_multisrctop=\"\nwith_target_subdir\201=\"\202\001with_target_subdir="...
-#10 openredirect (redir=0x8064814) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/redir.c:230
-        fname = <optimized out>
-        sb = {st_fstype = 0, st_fsid = 0, st_ino = 33024, st_gen = 136, st_rdev = 0, st_mode = 0, st_nlink = 0, st_uid = 0, st_gid = 17689694, 
-          st_size = 0, st_atim = {tv_sec = 0, tv_nsec = 0}, st_mtim = {tv_sec = 0, tv_nsec = 0}, st_ctim = {tv_sec = 0, tv_nsec = 0}, 
-          st_blksize = 0, st_blocks = 0, st_author = 6, st_flags = 44, st_spare = {0, 18708684, 0, 0, 48, 0, 0, 0}}
-        f = <optimized out>
-#11 redirect (redir=redir@entry=0x80647bc, flags=flags@entry=3) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/redir.c:121
-        n = 0x8064814
-        sv = 0x80b4540
-        i = <optimized out>
-        fd = <optimized out>
-        p = <optimized out>
-#12 0x080561c2 in redirectsafe (redir=0x80647bc, flags=flags@entry=3) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/redir.c:424
-        err = <optimized out>
-        saveint = 0
-        savehandler = 0x1024950
-        jmploc = {loc = {{__jmpbuf = {16926620, 1, 16926620, 0, 16926464, 134570321}, __mask_was_saved = 0, __saved_mask = 16926536}}}
-#13 0x0804c19b in evalcommand (cmd=0x806483c, flags=2) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:725
-        localvar_stop = 0x0
-        redir_stop = 0x0
-        smark = {stackp = 0x808ece8, stacknxt = 0x80903b4 "cat", stacknleft = 4408}
-        argp = 0x0
-        arglist = {list = 0x80903bc, lastp = 0x80903bc}
-        varlist = {list = 0x0, lastp = 0x10247a4}
-        argv = 0x80903c8
-        argc = <optimized out>
-        sp = <optimized out>
-        cmdentry = {cmdtype = 2, u = {index = 134584628, cmd = 0x8059934, func = 0x8059934}}
-        jp = <optimized out>
-        lastarg = 0x0
-        path = <optimized out>
-        spclbltin = <optimized out>
-        execcmd = <optimized out>
-        status = <optimized out>
-        nargv = <optimized out>
-#14 0x0804b509 in evaltree (n=0x806483c, flags=flags@entry=2) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-        checkexit = 0
-        evalfn = <optimized out>
-        isor = <optimized out>
-        status = <optimized out>
-#15 0x0804b586 in evaltree (n=0x806488c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-        checkexit = 0
-        evalfn = <optimized out>
-        isor = 1
-        status = <optimized out>
-#16 0x08051cbc in cmdloop (top=top@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:245
-        skip = <optimized out>
-        n = <optimized out>
-        smark = {stackp = 0x8064788, stacknxt = 0x80647a4 "cat", stacknleft = 480}
-        inter = <optimized out>
-        status = 0
-        numeof = 0
-#17 0x08051e27 in dotcmd (argc=2, argv=0x8064798) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:337
-        status = 0
-#18 0x0804bf47 in evalbltin (cmd=0x805afe0, argc=argc@entry=2, argv=argv@entry=0x8064798, flags=flags@entry=0)
-    at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:900
-        savecmdname = 0x102500a "/home/thomas/tmp/gcc/hurd/master/libffi/configure"
-        savehandler = 0x1024ae0
-        jmploc = {loc = {{__jmpbuf = {0, 2, 1, 134629272, 16927008, 134528761}, __mask_was_saved = 0, __saved_mask = 0}}}
-        status = <optimized out>
-        i = 0
-#19 0x0804c5b1 in evalcommand (cmd=0x80646dc, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:840
-        localvar_stop = 0x0
-        redir_stop = 0x0
-        smark = {stackp = 0x8064588, stacknxt = 0x806475c ".", stacknleft = 40}
-        argp = <optimized out>
-        arglist = {list = 0x8064764, lastp = 0x806478c}
-        varlist = {list = 0x0, lastp = 0x10249c4}
-        argv = 0x8064798
-        argc = 2
-        sp = <optimized out>
-        cmdentry = {cmdtype = 2, u = {index = 134590432, cmd = 0x805afe0, func = 0x805afe0}}
-        jp = <optimized out>
-        lastarg = 0x0
-        path = <optimized out>
-        spclbltin = 1
-        execcmd = 0
-        status = 0
-        nargv = <optimized out>
-#20 0x0804b509 in evaltree (n=0x80646dc, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-        checkexit = 0
-        evalfn = <optimized out>
-        isor = <optimized out>
-        status = <optimized out>
-#21 0x0804b509 in evaltree (n=0x80646dc, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-        checkexit = 0
-        evalfn = <optimized out>
-        isor = <optimized out>
-        status = <optimized out>
-#22 0x0804b586 in evaltree (n=0x8064734, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-        checkexit = 0
-        evalfn = <optimized out>
-        isor = 2
-        status = <optimized out>
-#23 0x0804b509 in evaltree (n=0x8064734, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-        checkexit = 0
-        evalfn = <optimized out>
-        isor = <optimized out>
-        status = <optimized out>
-#24 0x08051cbc in cmdloop (top=top@entry=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:245
-        skip = <optimized out>
-        n = <optimized out>
-        smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "eval", stacknleft = 504}
-        inter = <optimized out>
-        status = 0
-        numeof = 0
-#25 0x08049b42 in main (argc=14, argv=0x1024b84) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:178
-        shinit = <optimized out>
-        state = 4
-        jmploc = {loc = {{__jmpbuf = {18698228, 142560, 134607808, 16927496, 16927424, 134519464}, __mask_was_saved = 0, 
-              __saved_mask = 18698228}}}
-        smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "eval", stacknleft = 504}
-        login = <optimized out>
-
-    (gdb) print _hurd_global_sigstate
-    $1 = (struct hurd_sigstate *) 0x121a808
-    (gdb) print *_hurd_global_sigstate
-    $2 = {critical_section_lock = 0, lock = 0, thread = 0, next = 0x0, blocked = 4294967295, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, 
-            sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, 
-            sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, 
-            sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, sa_sigaction = 0x8056260 <onsig>}, 
-          sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0x8056260 <onsig>, sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 12 times>}, sigaltstack = {ss_sp = 0x0, 
-        ss_size = 0, ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, 
-          error = 0} <repeats 20 times>, {exc = 0, exc_code = 19013424, exc_subcode = 85056, code = 1, error = 17261792}, {exc = 0, exc_code = 0, 
-          exc_subcode = 0, code = 0, error = 0} <repeats 12 times>}, suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, 
-      cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_siglock
-    $3 = {held = 0, lock = 0, name = 0x0, queue = {head = 0x0, tail = 0x0}, holder = 0x0}
-    (gdb) print _hurd_sigstates
-    $4 = (struct hurd_sigstate *) 0x1224808
-    (gdb) print *_hurd_sigstates
-    $5 = {critical_section_lock = 0, lock = 0, thread = 76, next = 0x121a008, blocked = 0, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 33 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, 
-        ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 33 times>}, 
-      suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_sigstates->next
-    $6 = (struct hurd_sigstate *) 0x121a008
-    (gdb) print *_hurd_sigstates->next
-    $7 = {critical_section_lock = 0, lock = 0, thread = 49, next = 0x0, blocked = 0, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 0, sa_flags = 2} <repeats 32 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, 
-      pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 20 times>, {exc = 0, exc_code = 19013424, 
-          exc_subcode = 85056, code = 1, error = 17261792}, {exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 12 times>}, 
-      suspended = 0, intr_port = 94, context = 0x0, active_resources = 0x10244b0, cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_self_sigstate()
-    $8 = (struct hurd_sigstate *) 0x121a008
-
-
-## 10360
-
-    Thread 2 (Thread 10360.2):
-    #0  0x0105b7cc in mach_msg_trap () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0105bfc9 in __mach_msg (msg=0x1221f90, option=3, send_size=32, rcv_size=4096, rcv_name=75, timeout=0, notify=0) at msg.c:110
-            ret = <optimized out>
-    #2  0x0105c6f9 in __mach_msg_server_timeout (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=75, option=0, timeout=0)
-        at msgserver.c:151
-            request = 0x1222fa0
-            reply = 0x1221f90
-            mr = <optimized out>
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #3  0x0105c7cb in __mach_msg_server (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=75) at msgserver.c:196
-    No locals.
-    #4  0x0106cecf in _hurd_msgport_receive () at msgportdemux.c:68
-    No locals.
-    #5  0x66688b92 in ?? ()
-    No symbol table info available.
-    #6  0x00000000 in ?? ()
-    No symbol table info available.
-    
-    Thread 1 (Thread 10360.1):
-    #0  0x01078a5c in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:134
-            err = <optimized out>
-            err = <optimized out>
-            user_option = 3
-            user_timeout = 0
-            m = 0x1024278
-            msgh_bits = 5395
-            remote_port = 74
-            msgid = 24020
-            __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg"
-    #1  0x011f99df in __proc_wait (process=74, pid=-1, options=0, status=0x1024400, sigcode=0x10243ac, rusage=0x1024348, pid_status=0x10243b0)
-        at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/hurd/RPC_proc_wait.c:182
-            Mess = {In = {Head = {msgh_bits = 5395, msgh_size = 132, msgh_remote_port = 74, msgh_local_port = 77, msgh_seqno = 0, 
-                  msgh_id = 24020}, pidType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, 
-                  msgt_deallocate = 0, msgt_unused = 0}, pid = -1, optionsType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, 
-                  msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, options = 0}, Out = {Head = {msgh_bits = 5395, msgh_size = 132, 
-                  msgh_remote_port = 74, msgh_local_port = 77, msgh_seqno = 0, msgh_id = 24020}, RetCodeType = {msgt_name = 2, msgt_size = 32, 
-                  msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, RetCode = -1, statusType = {
-                  msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, 
-                status = 0, sigcodeType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, 
-                  msgt_deallocate = 0, msgt_unused = 0}, sigcode = 0, rusageType = {msgt_name = 2, msgt_size = 32, msgt_number = 18, 
-                  msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, rusage = {ru_utime = {tv_sec = 0, tv_usec = 0}, 
-                  ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, ru_minflt = 0, ru_majflt = 0, 
-                  ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}, 
-                pid_statusType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, 
-                  msgt_unused = 0}, pid_status = 17243652}}
-            msg_result = <optimized out>
-            msgh_size = <optimized out>
-    #2  0x0110e49e in __wait4 (pid=-1, stat_loc=0x1024400, options=0, usage=0x1024348) at ../sysdeps/mach/hurd/wait4.c:35
-            __p = 0x1219fac
-            __link = {resource = {next = 0x0, prevp = 0x1219fb0}, thread = {next = 0x0, prevp = 0x121a45c}, 
-              cleanup = 0x1084b90 <_hurd_port_cleanup>, cleanup_data = 0x4a}
-            port = 74
-            __result = <optimized out>
-            dead = <optimized out>
-            err = <optimized out>
-            ignored = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, 
-              ru_isrss = 0, ru_minflt = 0, ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, 
-              ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}
-            sigcode = 0
-            dummy = 16925396
-    #3  0x0110e2c7 in __wait3 (stat_loc=stat_loc@entry=..., options=options@entry=0, usage=usage@entry=0x0)
-        at ../sysdeps/unix/bsd/bsd4.4/wait3.c:34
-    No locals.
-    #4  0x0805028a in waitproc (status=0x1024400, block=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:1139
-            mask = 1
-            oldmask = 1
-            flags = 0
-            err = <optimized out>
-    #5  dowait (block=block@entry=1, job=job@entry=0x8063898) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:1016
-            status = <optimized out>
-            jp = <optimized out>
-            thisjob = 0x0
-            state = <optimized out>
-    #6  0x080518dc in waitforjob (jp=jp@entry=0x8063898) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:976
-            st = <optimized out>
-    #7  0x0804bc58 in evalpipe (n=0x8089934, flags=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:566
-            jp = 0x8063898
-            lp = 0x0
-            pipelen = <optimized out>
-            prevfd = <optimized out>
-            pip = {8, -1}
-    #8  0x0804b509 in evaltree (n=n@entry=0x8089934, flags=flags@entry=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #9  0x0804c7df in evaltreenr (flags=1, n=0x8089934) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:324
-    No locals.
-    #10 evalbackcmd (n=n@entry=0x8089934, result=result@entry=0x1024560) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:606
-            pip = {8, 9}
-            jp = 0x8063898
-    #11 0x0804f43b in expbackq (flag=256, cmd=0x8089934) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/expand.c:529
-            i = <optimized out>
-            buf = "_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*\nol_pipe | $SED '\\''s/.* //'\\'' | sort | uniq > $export_symbols\n_flags ${wl}-soname $wl$s"
-            dest = <optimized out>
-            startloc = 7784
-            in = {fd = -1, buf = 0x0, nleft = 0, jp = 0x0}
-            p = <optimized out>
-            syntax = 0x805b802 ""
-            smark = {stackp = 0x80914f0, 
-              stacknxt = 0x80914f4 "#\n# INIT-COMMANDS\n#\n\nsrcdir=\"../../../master/libffi\"\nhost=\"i686-unknown-gnu0.3\"\ntarget=\"i686-unknown-gnu0.3\"\nwith_multisubdir=\"\"\nwith_multisrctop=\"\"\nwith_target_subdir=\"i686-unknown-gnu0.3\"\nac_configu"..., stacknleft = 8704}
-    #12 argstr (
-        p=0x808f72b "'\nprelink_cmds\201='\204'\nfile_list_spec\201='\204'\nvariables_saved_for_relink\201='\204'\nneed_lib_prefix\201='\204'\nneed_version\201='\204'\nversion_type\201='\204'\nrunpath_var\201='\204'\nshlibpath_var\201='\204'\nshlibpath_overrides_runpath\201='\204'\nli"..., 
-        flag=flag@entry=256) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/expand.c:350
-            spclchars = "=:\210\203\201\202\204\207"
-            reject = 0x8059b42 "\210\203\201\202\204\207"
-            c = <optimized out>
-            breakall = 0
-            inquotes = 0
-            length = 0
-            startloc = 256
-    #13 0x0804f682 in expandarg (arg=0x80903a4, arglist=arglist@entry=0x0, flag=flag@entry=256)
-        at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/expand.c:193
-            sp = <optimized out>
-            p = <optimized out>
-    #14 0x08056028 in openhere (redir=<optimized out>) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/redir.c:307
-            pip = {3, 4}
-            len = 0
-            p = 0x808ecec "#\n# INIT\201-COMMANDS\n#\n\nsrcdir\201=\"\202\001srcdir=\"\nhost\201=\"\202\001host=\"\ntarget\201=\"\202\001target=\"\nwith_multisubdir\201=\"\202\001with_multisubdir=\"\nwith_multisrctop\201=\"\202\001with_multisrctop=\"\nwith_target_subdir\201=\"\202\001with_target_subdir="...
-    #15 openredirect (redir=0x8064814) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/redir.c:230
-            fname = <optimized out>
-            sb = {st_fstype = 0, st_fsid = 0, st_ino = 33024, st_gen = 136, st_rdev = 0, st_mode = 0, st_nlink = 0, st_uid = 0, st_gid = 17689694, 
-              st_size = 0, st_atim = {tv_sec = 0, tv_nsec = 0}, st_mtim = {tv_sec = 0, tv_nsec = 0}, st_ctim = {tv_sec = 0, tv_nsec = 0}, 
-              st_blksize = 0, st_blocks = 0, st_author = 6, st_flags = 44, st_spare = {0, 18708684, 0, 0, 48, 0, 0, 0}}
-            f = <optimized out>
-    #16 redirect (redir=redir@entry=0x80647bc, flags=flags@entry=3) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/redir.c:121
-            n = 0x8064814
-            sv = 0x80b4540
-            i = <optimized out>
-            fd = <optimized out>
-            p = <optimized out>
-    #17 0x080561c2 in redirectsafe (redir=0x80647bc, flags=flags@entry=3) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/redir.c:424
-            err = <optimized out>
-            saveint = 0
-            savehandler = 0x1024950
-            jmploc = {loc = {{__jmpbuf = {16926620, 1, 16926620, 0, 16926464, 134570321}, __mask_was_saved = 0, __saved_mask = 16926536}}}
-    #18 0x0804c19b in evalcommand (cmd=0x806483c, flags=2) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:725
-            localvar_stop = 0x0
-            redir_stop = 0x0
-            smark = {stackp = 0x808ece8, stacknxt = 0x80903b4 "cat", stacknleft = 4408}
-            argp = 0x0
-            arglist = {list = 0x80903bc, lastp = 0x80903bc}
-            varlist = {list = 0x0, lastp = 0x10247a4}
-            argv = 0x80903c8
-            argc = <optimized out>
-            sp = <optimized out>
-            cmdentry = {cmdtype = 2, u = {index = 134584628, cmd = 0x8059934, func = 0x8059934}}
-            jp = <optimized out>
-            lastarg = 0x0
-            path = <optimized out>
-            spclbltin = <optimized out>
-            execcmd = <optimized out>
-            status = <optimized out>
-            nargv = <optimized out>
-    #19 0x0804b509 in evaltree (n=0x806483c, flags=flags@entry=2) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #20 0x0804b586 in evaltree (n=0x806488c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 1
-            status = <optimized out>
-    #21 0x08051cbc in cmdloop (top=top@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:245
-            skip = <optimized out>
-            n = <optimized out>
-            smark = {stackp = 0x8064788, stacknxt = 0x80647a4 "cat", stacknleft = 480}
-            inter = <optimized out>
-            status = 0
-            numeof = 0
-    #22 0x08051e27 in dotcmd (argc=2, argv=0x8064798) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:337
-            status = 0
-    #23 0x0804bf47 in evalbltin (cmd=0x805afe0, argc=argc@entry=2, argv=argv@entry=0x8064798, flags=flags@entry=0)
-        at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:900
-            savecmdname = 0x102500a "/home/thomas/tmp/gcc/hurd/master/libffi/configure"
-            savehandler = 0x1024ae0
-            jmploc = {loc = {{__jmpbuf = {0, 2, 1, 134629272, 16927008, 134528761}, __mask_was_saved = 0, __saved_mask = 0}}}
-            status = <optimized out>
-            i = 0
-    #24 0x0804c5b1 in evalcommand (cmd=0x80646dc, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:840
-            localvar_stop = 0x0
-            redir_stop = 0x0
-            smark = {stackp = 0x8064588, stacknxt = 0x806475c ".", stacknleft = 40}
-            argp = <optimized out>
-            arglist = {list = 0x8064764, lastp = 0x806478c}
-            varlist = {list = 0x0, lastp = 0x10249c4}
-            argv = 0x8064798
-            argc = 2
-            sp = <optimized out>
-            cmdentry = {cmdtype = 2, u = {index = 134590432, cmd = 0x805afe0, func = 0x805afe0}}
-            jp = <optimized out>
-            lastarg = 0x0
-            path = <optimized out>
-            spclbltin = 1
-            execcmd = 0
-            status = 0
-            nargv = <optimized out>
-    #25 0x0804b509 in evaltree (n=0x80646dc, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #26 0x0804b509 in evaltree (n=0x80646dc, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #27 0x0804b586 in evaltree (n=0x8064734, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #28 0x0804b509 in evaltree (n=0x8064734, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #29 0x08051cbc in cmdloop (top=top@entry=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:245
-            skip = <optimized out>
-            n = <optimized out>
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "eval", stacknleft = 504}
-            inter = <optimized out>
-            status = 0
-            numeof = 0
-    #30 0x08049b42 in main (argc=14, argv=0x1024b84) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:178
-            shinit = <optimized out>
-            state = 4
-            jmploc = {loc = {{__jmpbuf = {18698228, 142560, 134607808, 16927496, 16927424, 134519464}, __mask_was_saved = 0, 
-                  __saved_mask = 18698228}}}
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "eval", stacknleft = 504}
-            login = <optimized out>
-
-    (gdb) print _hurd_global_sigstate
-    $1 = (struct hurd_sigstate *) 0x121a808
-    (gdb) print *_hurd_global_sigstate
-    $2 = {critical_section_lock = 0, lock = 0, thread = 0, next = 0x0, blocked = 4294967295, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 4294967295, sa_flags = 0}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, 
-          sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, 
-          sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, 
-            sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 0, sa_flags = 2} <repeats 12 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, 
-      pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 20 times>, {exc = 0, exc_code = 19013424, 
-          exc_subcode = 85056, code = 1, error = 17261792}, {exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 12 times>}, 
-      suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_siglock
-    $3 = {held = 0, lock = 0, name = 0x0, queue = {head = 0x0, tail = 0x0}, holder = 0x0}
-    (gdb) print _hurd_sigstates
-    $4 = (struct hurd_sigstate *) 0x121a008
-    (gdb) print *_hurd_sigstates
-    $5 = {critical_section_lock = 0, lock = 0, thread = 49, next = 0x1224808, blocked = 0, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 0, sa_flags = 2} <repeats 32 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, 
-      pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 20 times>, {exc = 0, exc_code = 17165596, 
-          exc_subcode = 1, code = 1, error = EKERN_INVALID_ADDRESS}, {exc = 0, exc_code = 0, exc_subcode = 0, code = 0, 
-          error = 0} <repeats 12 times>}, suspended = 0, intr_port = 74, context = 0x0, active_resources = 0x1024390, cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_sigstates->next
-    $6 = (struct hurd_sigstate *) 0x1224808
-    (gdb) print *_hurd_sigstates->next
-    $7 = {critical_section_lock = 0, lock = 0, thread = 76, next = 0x0, blocked = 0, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 33 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, 
-        ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 33 times>}, 
-      suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_self_sigstate()
-    $8 = (struct hurd_sigstate *) 0x121a008
-
-
-## 10362
-
-    Thread 2 (Thread 10362.2):
-    #0  0x0105b7cc in mach_msg_trap () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0105bfc9 in __mach_msg (msg=0x1221f90, option=3, send_size=32, rcv_size=4096, rcv_name=75, timeout=0, notify=0) at msg.c:110
-            ret = <optimized out>
-    #2  0x0105c6f9 in __mach_msg_server_timeout (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=75, option=0, timeout=0)
-        at msgserver.c:151
-            request = 0x1222fa0
-            reply = 0x1221f90
-            mr = <optimized out>
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #3  0x0105c7cb in __mach_msg_server (demux=0x106cf00 <msgport_server>, max_size=4096, rcv_name=75) at msgserver.c:196
-    No locals.
-    #4  0x0106cecf in _hurd_msgport_receive () at msgportdemux.c:68
-    No locals.
-    #5  0x66688b92 in ?? ()
-    No symbol table info available.
-    #6  0x00000000 in ?? ()
-    No symbol table info available.
-    
-    Thread 1 (Thread 10362.1):
-    #0  0x0105b81c in swtch_pri () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2
-    No locals.
-    #1  0x0105d0a4 in __spin_lock_solid (lock=0x121a80c) at spin-solid.c:27
-    No locals.
-    #2  0x01071e57 in __spin_lock (__lock=<optimized out>) at ../mach/lock-intern.h:55
-    No locals.
-    #3  _hurd_sigstate_lock (ss=0x121a008) at hurdsig.c:172
-    No locals.
-    #4  0x0110f51c in _hurd_critical_section_unlock (our_lock=<optimized out>) at ../hurd/hurd/signal.h:235
-    No locals.
-    #5  __fork () at ../sysdeps/mach/hurd/fork.c:707
-            env = {{__jmpbuf = {18698228, 18976712, 0, 16925768, 16925396, 17887007}, __mask_was_saved = 0, __saved_mask = 16925856}}
-            pid = 0
-            err = <optimized out>
-            __PRETTY_FUNCTION__ = "__fork"
-            ss = 0x121a008
-            threads = 0x0
-            nthreads = 0
-            stopped = 1
-            i = 6
-    #6  0x08051620 in forkshell (jp=jp@entry=0x8063898, n=0x808999c, mode=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:934
-            pid = <optimized out>
-    #7  0x0804bbf8 in evalpipe (n=0x8089934, flags=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:544
-            jp = 0x8063898
-            lp = 0x808994c
-            pipelen = <optimized out>
-            prevfd = <optimized out>
-            pip = {8, -1}
-    #8  0x0804b509 in evaltree (n=n@entry=0x8089934, flags=flags@entry=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #9  0x0804c7df in evaltreenr (flags=1, n=0x8089934) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:324
-    No locals.
-    #10 evalbackcmd (n=n@entry=0x8089934, result=result@entry=0x1024560) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:606
-            pip = {8, 9}
-            jp = 0x8063898
-    #11 0x0804f43b in expbackq (flag=256, cmd=0x8089934) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/expand.c:529
-            i = <optimized out>
-            buf = "_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*\nol_pipe | $SED '\\''s/.* //'\\'' | sort | uniq > $export_symbols\n_flags ${wl}-soname $wl$s"
-            dest = <optimized out>
-            startloc = 7784
-            in = {fd = -1, buf = 0x0, nleft = 0, jp = 0x0}
-            p = <optimized out>
-            syntax = 0x805b802 ""
-            smark = {stackp = 0x80914f0, 
-              stacknxt = 0x80914f4 "#\n# INIT-COMMANDS\n#\n\nsrcdir=\"../../../master/libffi\"\nhost=\"i686-unknown-gnu0.3\"\ntarget=\"i686-unknown-gnu0.3\"\nwith_multisubdir=\"\"\nwith_multisrctop=\"\"\nwith_target_subdir=\"i686-unknown-gnu0.3\"\nac_configu"..., stacknleft = 8704}
-    #12 argstr (
-        p=0x808f72b "'\nprelink_cmds\201='\204'\nfile_list_spec\201='\204'\nvariables_saved_for_relink\201='\204'\nneed_lib_prefix\201='\204'\nneed_version\201='\204'\nversion_type\201='\204'\nrunpath_var\201='\204'\nshlibpath_var\201='\204'\nshlibpath_overrides_runpath\201='\204'\nli"..., 
-        flag=flag@entry=256) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/expand.c:350
-            spclchars = "=:\210\203\201\202\204\207"
-            reject = 0x8059b42 "\210\203\201\202\204\207"
-            c = <optimized out>
-            breakall = 0
-            inquotes = 0
-            length = 0
-            startloc = 256
-    #13 0x0804f682 in expandarg (arg=0x80903a4, arglist=arglist@entry=0x0, flag=flag@entry=256)
-        at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/expand.c:193
-            sp = <optimized out>
-            p = <optimized out>
-    #14 0x08056028 in openhere (redir=<optimized out>) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/redir.c:307
-            pip = {3, 4}
-            len = 0
-            p = 0x808ecec "#\n# INIT\201-COMMANDS\n#\n\nsrcdir\201=\"\202\001srcdir=\"\nhost\201=\"\202\001host=\"\ntarget\201=\"\202\001target=\"\nwith_multisubdir\201=\"\202\001with_multisubdir=\"\nwith_multisrctop\201=\"\202\001with_multisrctop=\"\nwith_target_subdir\201=\"\202\001with_target_subdir="...
-    #15 openredirect (redir=0x8064814) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/redir.c:230
-            fname = <optimized out>
-            sb = {st_fstype = 0, st_fsid = 0, st_ino = 33024, st_gen = 136, st_rdev = 0, st_mode = 0, st_nlink = 0, st_uid = 0, st_gid = 17689694, 
-              st_size = 0, st_atim = {tv_sec = 0, tv_nsec = 0}, st_mtim = {tv_sec = 0, tv_nsec = 0}, st_ctim = {tv_sec = 0, tv_nsec = 0}, 
-              st_blksize = 0, st_blocks = 0, st_author = 6, st_flags = 44, st_spare = {0, 18708684, 0, 0, 48, 0, 0, 0}}
-            f = <optimized out>
-    #16 redirect (redir=redir@entry=0x80647bc, flags=flags@entry=3) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/redir.c:121
-            n = 0x8064814
-            sv = 0x80b4540
-            i = <optimized out>
-            fd = <optimized out>
-            p = <optimized out>
-    #17 0x080561c2 in redirectsafe (redir=0x80647bc, flags=flags@entry=3) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/redir.c:424
-            err = <optimized out>
-            saveint = 0
-            savehandler = 0x1024950
-            jmploc = {loc = {{__jmpbuf = {16926620, 1, 16926620, 0, 16926464, 134570321}, __mask_was_saved = 0, __saved_mask = 16926536}}}
-    #18 0x0804c19b in evalcommand (cmd=0x806483c, flags=2) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:725
-            localvar_stop = 0x0
-            redir_stop = 0x0
-            smark = {stackp = 0x808ece8, stacknxt = 0x80903b4 "cat", stacknleft = 4408}
-            argp = 0x0
-            arglist = {list = 0x80903bc, lastp = 0x80903bc}
-            varlist = {list = 0x0, lastp = 0x10247a4}
-            argv = 0x80903c8
-            argc = <optimized out>
-            sp = <optimized out>
-            cmdentry = {cmdtype = 2, u = {index = 134584628, cmd = 0x8059934, func = 0x8059934}}
-            jp = <optimized out>
-            lastarg = 0x0
-            path = <optimized out>
-            spclbltin = <optimized out>
-            execcmd = <optimized out>
-            status = <optimized out>
-            nargv = <optimized out>
-    #19 0x0804b509 in evaltree (n=0x806483c, flags=flags@entry=2) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #20 0x0804b586 in evaltree (n=0x806488c, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 1
-            status = <optimized out>
-    #21 0x08051cbc in cmdloop (top=top@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:245
-            skip = <optimized out>
-            n = <optimized out>
-            smark = {stackp = 0x8064788, stacknxt = 0x80647a4 "cat", stacknleft = 480}
-            inter = <optimized out>
-            status = 0
-            numeof = 0
-    #22 0x08051e27 in dotcmd (argc=2, argv=0x8064798) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:337
-            status = 0
-    #23 0x0804bf47 in evalbltin (cmd=0x805afe0, argc=argc@entry=2, argv=argv@entry=0x8064798, flags=flags@entry=0)
-        at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:900
-            savecmdname = 0x102500a "/home/thomas/tmp/gcc/hurd/master/libffi/configure"
-            savehandler = 0x1024ae0
-            jmploc = {loc = {{__jmpbuf = {0, 2, 1, 134629272, 16927008, 134528761}, __mask_was_saved = 0, __saved_mask = 0}}}
-            status = <optimized out>
-            i = 0
-    #24 0x0804c5b1 in evalcommand (cmd=0x80646dc, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:840
-            localvar_stop = 0x0
-            redir_stop = 0x0
-            smark = {stackp = 0x8064588, stacknxt = 0x806475c ".", stacknleft = 40}
-            argp = <optimized out>
-            arglist = {list = 0x8064764, lastp = 0x806478c}
-            varlist = {list = 0x0, lastp = 0x10249c4}
-            argv = 0x8064798
-            argc = 2
-            sp = <optimized out>
-            cmdentry = {cmdtype = 2, u = {index = 134590432, cmd = 0x805afe0, func = 0x805afe0}}
-            jp = <optimized out>
-            lastarg = 0x0
-            path = <optimized out>
-            spclbltin = 1
-            execcmd = 0
-            status = 0
-            nargv = <optimized out>
-    #25 0x0804b509 in evaltree (n=0x80646dc, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #26 0x0804b509 in evaltree (n=0x80646dc, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #27 0x0804b586 in evaltree (n=0x8064734, flags=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:267
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = 2
-            status = <optimized out>
-    #28 0x0804b509 in evaltree (n=0x8064734, flags=flags@entry=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/eval.c:278
-            checkexit = 0
-            evalfn = <optimized out>
-            isor = <optimized out>
-            status = <optimized out>
-    #29 0x08051cbc in cmdloop (top=top@entry=1) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:245
-            skip = <optimized out>
-            n = <optimized out>
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "eval", stacknleft = 504}
-            inter = <optimized out>
-            status = 0
-            numeof = 0
-    #30 0x08049b42 in main (argc=14, argv=0x1024b84) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/main.c:178
-            shinit = <optimized out>
-            state = 4
-            jmploc = {loc = {{__jmpbuf = {18698228, 142560, 134607808, 16927496, 16927424, 134519464}, __mask_was_saved = 0, 
-                  __saved_mask = 18698228}}}
-            smark = {stackp = 0x80617e0, stacknxt = 0x80617e4 "eval", stacknleft = 504}
-            login = <optimized out>
-
-    (gdb) print _hurd_global_sigstate
-    $1 = (struct hurd_sigstate *) 0x121a808
-    (gdb) print *_hurd_global_sigstate
-    $2 = {critical_section_lock = 0, lock = 1, thread = 0, next = 0x0, blocked = 4294967295, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 4294967295, sa_flags = 0}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, 
-          sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, 
-          sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x8056260 <onsig>, 
-            sa_sigaction = 0x8056260 <onsig>}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 0, sa_flags = 2} <repeats 12 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, 
-      pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 20 times>, {exc = 0, exc_code = 19013424, 
-          exc_subcode = 85056, code = 1, error = 17261792}, {exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 12 times>}, 
-      suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_siglock
-    $3 = {held = 0, lock = 0, name = 0x0, queue = {head = 0x0, tail = 0x0}, holder = 0x0}
-    (gdb) print _hurd_sigstates
-    $4 = (struct hurd_sigstate *) 0x121a008
-    (gdb) print *_hurd_sigstates
-    $5 = {critical_section_lock = 1, lock = 0, thread = 49, next = 0x1224808, blocked = 0, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 0, sa_flags = 2} <repeats 32 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, 
-      pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 20 times>, {exc = 0, exc_code = 19013424, 
-          exc_subcode = 85056, code = 1, error = 17261792}, {exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 12 times>}, 
-      suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_sigstates->next
-    $6 = (struct hurd_sigstate *) 0x1224808
-    (gdb) print *_hurd_sigstates->next
-    $7 = {critical_section_lock = 0, lock = 0, thread = 76, next = 0x0, blocked = 0, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 33 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, 
-        ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 33 times>}, 
-      suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, cancel = 0, cancel_hook = 0}
-    (gdb) print _hurd_self_sigstate()
-    $8 = (struct hurd_sigstate *) 0x121a008
-
-
-# IRC, OFTC, #debian-hurd, 2012-11-24
-
-    <youpi> the lockups are about a SIGCHLD which gets lost
-    <pinotree> ah, ok
-    <youpi> which makes bash spin
-    <pinotree> is that happening more often recently, or it's just something i
-      just noticed?
-    <youpi> it's more often recently
-    <youpi> where "recently" means "some months ago"
-    <youpi> I didn't notice exactly when
-    <pinotree> i see
-    <youpi> it's at most since june, apparently
-    <youpi> (libtool managed to build without a fuss, while now it's a pain)
-    <youpi> (libtool building is a good test, it seems to be triggering quite
-      reliably)
-
-
-## IRC, freenode, #hurd, 2012-11-27
-
-    <youpi> we also have the shell wait issue
-    <youpi> it's particularly bad on libtool calls
-    <youpi> the libtool package (with testsuite) is a good reproducer :)
-    <youpi> the symptom is shell scripts eating CPU
-    <youpi> busy-waiting for a SIGCHLD which never gets received
-    <braunr> that could be what i got
-    <braunr>
-      http://www.gnu.org/software/hurd/microkernel/mach/gnumach/memory_management.html
-    <braunr> last part
-    <youpi> perhaps watch has the same issue as the shell, yes
-
-
-# [[!message-id "877govry7a.fsf@kepler.schwinge.homeip.net"]]
-
-## 2013-02-08
-
-With Richard's `2.13-39+hurd.rbraun.3` packages (but doesn't seem related to
-the issues he's working on), which includes the hack from the email above,
-during a GDB build's `make install`:
-
-      PID  UID  PPID  PGrp  Sess TH  Vmem   RSS %CPU     User   System Args
-     1988 1000  1986  1715   420  2  146M  204K 97.6  0:01.49  3:19.91 /bin/dash -c catalogs='da.gmo de.gmo es.gmo fi.gmo fr.gmo ga.gmo id.gmo it.gm
-
-    Thread 1 (Thread 1988.1):
-    #0  0x0105b82c in swtch_pri () at /home/rbraun/devel/debian/packages/eglibc/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2
-    No locals.
-    #1  0x0105d0b4 in __spin_lock_solid (lock=0x121900c) at spin-solid.c:27
-    No locals.
-    #2  0x01071e73 in __spin_lock (__lock=<optimized out>) at ../mach/lock-intern.h:55
-    No locals.
-    #3  _hurd_sigstate_lock (ss=0x1219008) at hurdsig.c:174
-    No locals.
-    #4  0x0110f59c in _hurd_critical_section_unlock (our_lock=<optimized out>) at ../hurd/hurd/signal.h:235
-    No locals.
-    #5  __fork () at ../sysdeps/mach/hurd/fork.c:716
-            env = {{__jmpbuf = {18698228, 18972616, 0, 16926424, 16926052, 17887119}, __mask_was_saved = 0, __saved_mask = 5}}
-            pid = 0
-            err = <optimized out>
-            __PRETTY_FUNCTION__ = "__fork"
-            ss = 0x1219008
-            threads = 0x0
-            nthreads = 0
-            stopped = 1
-            i = 6
-    #6  0x08051620 in forkshell (jp=jp@entry=0x8064600, n=0x806378c, mode=0) at /home/thomas/tmp/dash/debian/dash-0.5.7/build-tmp/../src/jobs.c:934
-            pid = <optimized out>
-    [...]
-
-This time, it's our own sigstate, not the global one:
-
-    (gdb) print _hurd_global_sigstate
-    $1 = (struct hurd_sigstate *) 0x1219808
-
-
-## 2013-02-19
-
-Reproduced the 2013-02-08 findings with Richard's `2.13-39+hurd.rbraun.6`
-packages (but doesn't seem related to the issues he's working on), which
-includes the hack from the email above, after a GCC build's `make` has been
-running for 14.25 h (so very near the end of the build, darn):
-
-      PID  UID  PPID  PGrp  Sess TH  Vmem   RSS %CPU     User   System Args
-     2792 1000  2773  1728   409  2  146M 1.19M  0.0  0:00.20  0:00.80 /bin/dash /home/thomas/tmp/gcc/hurd/master/libatomic/configure --cache-fil
-     3839 1000  2792  1728   409  2  146M  532K  0.0  0:00.00  0:00.00 /bin/dash /home/thomas/tmp/gcc/hurd/master/libatomic/configure --cache-fil
-     3841 1000  3839  1728   409  2  146M  272K 95.4  4:13.12     5hrs /bin/dash /home/thomas/tmp/gcc/hurd/master/libatomic/configure --cache-fil
-
-    #0  0x0105a87c in swtch_pri () at /home/rbraun/devel/debian/packages/eglibc/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2
-    No locals.
-    #1  0x0105c104 in __spin_lock_solid (lock=0x121d00c) at spin-solid.c:27
-    No locals.
-    #2  0x01070f43 in __spin_lock (__lock=<optimized out>) at ../mach/lock-intern.h:55
-    No locals.
-    #3  _hurd_sigstate_lock (ss=0x121d008) at hurdsig.c:174
-    No locals.
-    #4  0x0110e66c in _hurd_critical_section_unlock (our_lock=<optimized out>) at ../hurd/hurd/signal.h:235
-    No locals.
-    #5  __fork () at ../sysdeps/mach/hurd/fork.c:716
-            env = {{__jmpbuf = {18694132, 18989000, 134637636, 16926072, 16925700, 17883231}, __mask_was_saved = 0, __saved_mask = 4294967295}}
-            pid = 0
-            err = <optimized out>
-            __PRETTY_FUNCTION__ = "__fork"
-            ss = 0x121d008
-            threads = 0x0
-            nthreads = 0
-            stopped = 1
-            i = 6
-    [...]
-    (gdb) frame 5
-    #5  __fork () at ../sysdeps/mach/hurd/fork.c:716
-    warning: Source file is more recent than executable.
-    716       _hurd_critical_section_unlock (ss);
-    (gdb) list
-    711              ! symbol_set_end_p (_hurd_fork_locks, p);
-    712              ++p)
-    713           __mutex_unlock (*p);
-    714       }
-    715     
-    716       _hurd_critical_section_unlock (ss);
-    717     
-    718       return err ? __hurd_fail (err) : pid;
-    719     }
-    720     libc_hidden_def (__fork)
-    (gdb) frame 4
-    #4  0x0110e66c in _hurd_critical_section_unlock (our_lock=<optimized out>) at ../hurd/hurd/signal.h:235
-    warning: Source file is more recent than executable.
-    235           _hurd_sigstate_lock (ss);
-    (gdb) list
-    230       else
-    231         {
-    232           /* It was us who acquired the critical section lock.  Unlock it.  */
-    233           struct hurd_sigstate *ss = (struct hurd_sigstate *) our_lock;
-    234           sigset_t pending;
-    235           _hurd_sigstate_lock (ss);
-    236           __spin_unlock (&ss->critical_section_lock);
-    237           pending = _hurd_sigstate_pending(ss) & ~ss->blocked;
-    238           _hurd_sigstate_unlock (ss);
-    239           if (! __sigisemptyset (&pending))
-    (gdb) frame 3
-    #3  _hurd_sigstate_lock (ss=0x121d008) at hurdsig.c:174
-    warning: Source file is more recent than executable.
-    174       __spin_lock (&ss->lock);
-    (gdb) list
-    169     void
-    170     _hurd_sigstate_lock (struct hurd_sigstate *ss)
-    171     {
-    172       if (sigstate_is_global_rcv (ss))
-    173         __spin_lock (&_hurd_global_sigstate->lock);
-    174       __spin_lock (&ss->lock);
-    175     }
-    176     void
-    177     _hurd_sigstate_unlock (struct hurd_sigstate *ss)
-    178     {
-    (gdb) print _hurd_global_sigstate
-    $1 = (struct hurd_sigstate *) 0x121d808
-    (gdb) print *_hurd_global_sigstate
-    $2 = {critical_section_lock = 0, lock = 1, thread = 0, next = 0x0, blocked = 4294967295, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 4294967295, sa_flags = 0}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {
-          __sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, 
-            sa_sigaction = 0}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, 
-          sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, 
-          sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0x80564f0, 
-            sa_sigaction = 0x80564f0}, sa_mask = 4294967295, sa_flags = 0}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 0, sa_flags = 2} <repeats 12 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, 
-      pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 33 times>}, suspended = 0, intr_port = 0, 
-      context = 0x0, active_resources = 0x0, cancel = 0, cancel_hook = 0}
-    (gdb) print ss
-    $3 = (struct hurd_sigstate *) 0x121d008
-    (gdb) print *ss
-    $4 = {critical_section_lock = 1, lock = 1, thread = 73, next = 0x1227808, blocked = 0, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = 0, sa_flags = 2}, {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, 
-          sa_mask = 0, sa_flags = 2} <repeats 32 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, preemptors = 0x0, 
-      pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 20 times>, {exc = 0, exc_code = 19025712, 
-          exc_subcode = 85056, code = 1, error = 17257936}, {exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 12 times>}, 
-      suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, cancel = 0, cancel_hook = 0}
-    (gdb) print ss->next
-    $5 = (struct hurd_sigstate *) 0x1227808
-    (gdb) print *ss->next
-    $6 = {critical_section_lock = 0, lock = 0, thread = 76, next = 0x0, blocked = 0, pending = 0, actions = {{__sigaction_handler = {
-            sa_handler = 0, sa_sigaction = 0}, sa_mask = 0, sa_flags = 2} <repeats 33 times>}, sigaltstack = {ss_sp = 0x0, ss_size = 0, 
-        ss_flags = 0}, preemptors = 0x0, pending_data = {{exc = 0, exc_code = 0, exc_subcode = 0, code = 0, error = 0} <repeats 33 times>}, 
-      suspended = 0, intr_port = 0, context = 0x0, active_resources = 0x0, cancel = 0, cancel_hook = 0}
-
-So again, it's our own sigstate that already is locked, not the global one.
diff --git a/open_issues/fork_mach_port_mod_refs_ekern_urefs_owerflow.mdwn b/open_issues/fork_mach_port_mod_refs_ekern_urefs_owerflow.mdwn
deleted file mode 100644
index 39003ae4..00000000
--- a/open_issues/fork_mach_port_mod_refs_ekern_urefs_owerflow.mdwn
+++ /dev/null
@@ -1,185 +0,0 @@
-[[!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]]."]]"""]]
-
-[[!meta title="fork: mach_port_mod_refs: EKERN_UREFS_OWERFLOW"]]
-
-[[!toc]]
-
-
-# Original Report
-
-In the [[GCC testsuite|gcc]], at this point:
-
-    Running /home/tschwinge/tmp/gcc/hurd/gcc/testsuite/gcc.c-torture/unsorted/unsorted.exp ...
-
-... `expect` had gone bonkers:
-
-    $ ps --all --format=hurd-long -w
-      PID  UID  PPID  PGrp  Sess TH  Vmem   RSS %CPU     User   System Args
-    [...]
-     3567 1000 10295  3567  3567  2  137M  856K 98.2     5hrs 28 hours expect -- /usr/share/dejagnu/runtest.exp --tool gcc
-    [...]
-
-Last lines of `gcc/testsuite/gcc/gcc.sum`:
-
-    PASS: gcc.c-torture/unsorted/q.c,  -O2 -flto -flto-partition=none  
-    PASS: gcc.c-torture/unsorted/q.c,  -O2 -flto  
-    PASS: gcc.c-torture/unsorted/r.c,  -O0  
-    PASS: gcc.c-torture/unsorted/r.c,  -O1  
-    PASS: gcc.c-torture/unsorted/r.c,  -O2  
-    PASS: gcc.c-torture/unsorted/r.c,  -O3 -fomit-frame-pointer  
-    PASS: gcc.c-torture/unsorted/r.c,  -O3 -g  
-    PASS: gcc.c-torture/unsorted/r.c,  -Os  
-    PASS: gcc.c-torture/unsorted/r.c,  -O2 -flto -flto-partition=none  
-
-Last lines of `gcc/testsuite/gcc/gcc.log`:
-
-    Executing on host: /media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/xgcc -B/media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/  -w  -O2 -flto -flto-partition=none   -c  -o /home/tschwinge/tmp/gcc/hurd.build/gcc/testsuite/gcc/r.o /home/tschwinge/tmp/gcc/hurd/gcc/testsuite/gcc.c-torture/unsorted/r.c    (timeout = 300)
-    spawn /media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/xgcc -B/media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/ -w -O2 -flto -flto-partition=none -c -o /home/tschwinge/tmp/gcc/hurd.build/gcc/testsuite/gcc/r.o /home/tschwinge/tmp/gcc/hurd/gcc/testsuite/gcc.c-torture/unsorted/r.c
-    PASS: gcc.c-torture/unsorted/r.c,  -O2 -flto -flto-partition=none  
-    Executing on host: /media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/xgcc -B/media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/  -w  -O2 -flto   -c  -o /home/tschwinge/tmp/gcc/hurd.build/gcc/testsuite/gcc/r.o /home/tschwinge/tmp/gcc/hurd/gcc/testsuite/gcc.c-torture/unsorted/r.c    (timeout = 300)
-    spawn /media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/xgcc -B/media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/ -w -O2 -flto -c -o /home/tschwinge/tmp/gcc/hurd.build/gcc/testsuite/gcc/r.o /home/tschwinge/tmp/gcc/hurd/gcc/testsuite/gcc.c-torture/unsorted/r.c
-
-The root filesystem is sort-of deadlocked: `syncfs -c /` doesn't finish
--- even without `-s`.  But it is fine to spawn new processes, execute new
-commands, etc.
-
-GDB on 3567:
-
-    (gdb) info threads
-      2 Thread 3567.2  0x011aaf4c in mach_msg_trap () at /build/buildd-eglibc_2.11.2-7-hurd-i386-6JVoJz/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    * 1 Thread 3567.1  0x011aaf9c in swtch_pri () at /build/buildd-eglibc_2.11.2-7-hurd-i386-6JVoJz/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/swtch_pri.S:2
-    (gdb) bt
-    #0  0x011aaf9c in swtch_pri () at /build/buildd-eglibc_2.11.2-7-hurd-i386-6JVoJz/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/swtch_pri.S:2
-    #1  0x011ac824 in __spin_lock_solid (lock=0x131e8e0) at spin-solid.c:27
-    #2  0x011aca1d in __mutex_lock_solid (lock=0x131e8e0) at mutex-solid.c:31
-    #3  0x0122dd0b in __mutex_lock (oldmem=0x8076458, bytes=94) at ../mach/lock-intern.h:89
-    #4  __libc_realloc (oldmem=0x8076458, bytes=94) at malloc.c:3814
-    #5  0x0121de62 in _IO_vasprintf (result_ptr=0x15f40c0, format=0x13098a8 "%s%s%s:%u: %s%sUnexpected error: %s.\n", args=0x15f3c9c "") at vasprintf.c:86
-    #6  0x01206d1b in ___asprintf (string_ptr=0x15f40c0, format=0x13098a8 "%s%s%s:%u: %s%sUnexpected error: %s.\n") at asprintf.c:37
-    #7  0x011e2fc8 in __assert_perror_fail (errnum=19, file=0x1305a98 "../sysdeps/mach/hurd/fork.c", line=466, function=0x1305acf "__fork") at assert-perr.c:62
-    #8  0x012586c8 in __fork () at ../sysdeps/mach/hurd/fork.c:466
-    #9  0x011f92e9 in do_system (line=0x15f42dc "/bin/stty sane > /dev/ttypa") at ../sysdeps/posix/system.c:119
-    #10 0x0105bea6 in ?? () from /usr/lib/libexpect.so.5.44.1.15
-    #11 0x0105bf6d in ?? () from /usr/lib/libexpect.so.5.44.1.15
-    #12 0x0105c229 in exp_getptyslave () from /usr/lib/libexpect.so.5.44.1.15
-    #13 0x0103e4b2 in ?? () from /usr/lib/libexpect.so.5.44.1.15
-    #14 0x01087d79 in ?? () from /usr/lib/libtcl8.5.so.0
-    #15 0x01088beb in ?? () from /usr/lib/libtcl8.5.so.0
-    #16 0x0108826a in Tcl_EvalEx () from /usr/lib/libtcl8.5.so.0
-    #17 0x0108985f in TclEvalObjEx () from /usr/lib/libtcl8.5.so.0
-    [...]
-    (gdb) bt full
-    #0  0x011aaf9c in swtch_pri () at /build/buildd-eglibc_2.11.2-7-hurd-i386-6JVoJz/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/swtch_pri.S:2
-    No locals.
-    #1  0x011ac824 in __spin_lock_solid (lock=0x131e8e0) at spin-solid.c:27
-    No locals.
-    #2  0x011aca1d in __mutex_lock_solid (lock=0x131e8e0) at mutex-solid.c:31
-    No locals.
-    #3  0x0122dd0b in __mutex_lock (oldmem=0x8076458, bytes=94) at ../mach/lock-intern.h:89
-    No locals.
-    #4  __libc_realloc (oldmem=0x8076458, bytes=94) at malloc.c:3814
-            ar_ptr = <value optimized out>
-            nb = 104
-            newp = 0x68
-            oldp = 0x8076450
-            oldsize = 104
-            __func__ = "__libc_realloc"
-    #5  0x0121de62 in _IO_vasprintf (result_ptr=0x15f40c0, format=0x13098a8 "%s%s%s:%u: %s%sUnexpected error: %s.\n", args=0x15f3c9c "") at vasprintf.c:86
-            sf = {_sbf = {_f = {_flags = -72515584, 
-                  _IO_read_ptr = 0x8076458 "expect: ../sysdeps/mach/hurd/fork.c:466: __fork: Unexpected error: (os/kern) urefs overflow.\n", 
-                  _IO_read_end = 0x8076458 "expect: ../sysdeps/mach/hurd/fork.c:466: __fork: Unexpected error: (os/kern) urefs overflow.\n", 
-                  _IO_read_base = 0x8076458 "expect: ../sysdeps/mach/hurd/fork.c:466: __fork: Unexpected error: (os/kern) urefs overflow.\n", 
-                  _IO_write_base = 0x8076458 "expect: ../sysdeps/mach/hurd/fork.c:466: __fork: Unexpected error: (os/kern) urefs overflow.\n", 
-                  _IO_write_ptr = 0x80764b5 "", _IO_write_end = 0x80764bc "\201\004", 
-                  _IO_buf_base = 0x8076458 "expect: ../sysdeps/mach/hurd/fork.c:466: __fork: Unexpected error: (os/kern) urefs overflow.\n", 
-                  _IO_buf_end = 0x80764bc "\201\004", _IO_save_base = 0x0, _IO_backup_base = 0x0, _IO_save_end = 0x0, _markers = 0x0, _chain = 0x0, _fileno = 20046008, 
-                  _flags2 = 0, _old_offset = 23018464, _cur_column = 0, _vtable_offset = 49 '1', _shortbuf = "\001", _lock = 0x0, _offset = 85643859813466072, 
-                  _codecvt = 0x1304583, _wide_data = 0x15f3bc0, _freeres_list = 0x0, _freeres_buf = 0x15f3c58, _freeres_size = 0, _mode = -1, 
-                  _unused2 = "\240;_\001\236D0\001\005\000\000\000\340;_\001(K3\001\000\000\000\000\005\000\000\000\000\000\000\000\250\230\060\001\260\303\031\001"}, 
-                vtable = 0x131b9c0}, _s = {_allocate_buffer = 0x122cdf0 <__libc_malloc>, _free_buffer = 0x122cd20 <__libc_free>}}
-            ret = <value optimized out>
-            needed = 94
-    #6  0x01206d1b in ___asprintf (string_ptr=0x15f40c0, format=0x13098a8 "%s%s%s:%u: %s%sUnexpected error: %s.\n") at asprintf.c:37
-            done = 1
-    #7  0x011e2fc8 in __assert_perror_fail (errnum=19, file=0x1305a98 "../sysdeps/mach/hurd/fork.c", line=466, function=0x1305acf "__fork") at assert-perr.c:62
-            errbuf = "\334\r", '\000' <repeats 14 times>, "\f\265\032\001\000\000\000\000x\262\004\b\000\000\000\000\000\000\000\000\377\377\377\377 \262\004\b\250\065\063\001\070A_\001k\000\000\000\000\000\000\000ı2\001\002", '\000' <repeats 11 times>"\366, \377\377\377\270\235\004\bk\000\000\000X=_\001\037\343\037\001\377\377\377\377\000\000\000\000s=_\001\361\t\006\001\070A_\001\362\t\006\001\350\t\006\001\000\000\000\000\304B_\001\350\t\006\001\330\377_\001\033\000\000\000)\036\024\001\364\267\025\001x=_\001Bq\022\001\000\000\000\000\350:\b\b\230=_\001\364\267\025\001X\313\031\b S\005\b\230=_\001\004\334\f\001X\313\031\b\000\022\030\b\300L\005\b\364\267\025\001\370\021\030\b S\005\b\bB_\001\a\365\f\001 S\005\b\320\021\030\b\001\000\000\000\274A_\001,\316\024\001\001\000\000\000\001\000\000\000\344"...
-            buf = <value optimized out>
-    #8  0x012586c8 in __fork () at ../sysdeps/mach/hurd/fork.c:466
-            newproc = 122
-            sigthread_refs = 4
-            portnames = 0x63000
-            porttypes = 0x64000
-            sigthread = 130
-            state = {gs = 1, fs = 18236712, es = 20390776, ds = 17004532, edi = 1, esi = 143348, ebp = 23020160, esp = 0, ebx = 23020088, edx = 23020016, 
-              ecx = 23020028, eax = 3966371413, eip = 23020088, cs = 18236712, efl = 0, uesp = 20138312, ss = 18488015}
-            newtask = 121
-            thread = 139
-            thread_refs = 65534
-            statecount = <value optimized out>
-            nportnames = 142
-            nporttypes = 142
-            env = {{__jmpbuf = {20037620, 23068628, 23020252, 23020128, 23019736, 19231503}, __mask_was_saved = 0, __saved_mask = 4222451713}}
-            pid = <value optimized out>
-            err = EKERN_INVALID_ADDRESS
-            __PRETTY_FUNCTION__ = "__fork"
-            ss = 0x1376808
-            threads = 0x65000
-            nthreads = 2
-            stopped = 0
-            i = 2
-    #9  0x011f92e9 in do_system (line=0x15f42dc "/bin/stty sane > /dev/ttypa") at ../sysdeps/posix/system.c:119
-            status = <value optimized out>
-            save = <value optimized out>
-            pid = <value optimized out>
-            sa = {__sigaction_handler = {sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = 524288, sa_flags = 0}
-            omask = 0
-    [...]
-
-`fork` failed here:
-
-       458        /* We have one extra user reference created at the beginning of this
-       459           function, accounted for by mach_port_names (and which will thus be
-       460           accounted for in the child below).  This extra right gets consumed
-       461           in the child by the store into _hurd_sigthread in the child fork.  */
-       462        if (thread_refs > 1 &&
-       463            (err = __mach_port_mod_refs (newtask, ss->thread,
-       464                                         MACH_PORT_RIGHT_SEND,
-       465                                         thread_refs)))
-       466          LOSE;
-
-This is in the parent, before signal thread setup, registering with the
-proc server, and starting the new process.
-
-The error is 19, `EKERN_UREFS_OVERFLOW`.
-
-(This is likely also the reason why the error path did not execute
-successfully.)
-
-[[!tag open_issue_glibc]]
-
-On 2010-11-30 and 2010-12-04, when I had again started the GCC testsuite, it
-failed again, but at another position (understandably), but with the same
-symptoms as shown below.  In particular, the `thread_refs` values were the same
-ones.
-
-
-# Discussion
-
-  * <http://lists.gnu.org/archive/html/bug-hurd/2010-11/msg00028.html>
-
-  * <http://lists.gnu.org/archive/html/bug-hurd/2010-12/msg00002.html>
-
-This is likely *simply* a programming error in glibc's fork implementation. 
-
-
-# Bounty
-
-There is a [[!FF_project 273]][[!tag bounty]] on this task.
diff --git a/open_issues/formal_verification.mdwn b/open_issues/formal_verification.mdwn
deleted file mode 100644
index 474670c3..00000000
--- a/open_issues/formal_verification.mdwn
+++ /dev/null
@@ -1,33 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012 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]]."]]"""]]
-
-*Formal verification* ([[!wikipedia Formal_verification desc="Wikipedia
-article"]]) deals with formally reasoning about a program's correctness.
-
-Especially in the field of [[DSL]]s, this is used for asserting program codes'
-correctness, as explained in {{$microkernel/barrelfish#fof_plos09}}, for
-example.
-
-See also [[code_analysis]].
-
-[[!toc]]
-
-
-# Issues
-
-  * [[locking_issues]]
-
-  * [[term_blocking]]
-
-
-# Bounty
-
-There is a [[!FF_project 276]][[!tag bounty]] on some of these tasks.
diff --git a/open_issues/fsync.mdwn b/open_issues/fsync.mdwn
deleted file mode 100644
index d36a75ad..00000000
--- a/open_issues/fsync.mdwn
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_hurd]]
-
-IRC, unknown channel, unknown date
-
-    <youpi> azeem: I think I found why apt-get throws Hurd down sometimes
-    <youpi> the problem is that it basically write(file, 20MB); fsync();
-    <youpi> i.e. it throws a storm of dirty-writeback to ext2fs
-    <youpi> which thus goes into throttling threads
-    <youpi> since posix explicitely says that fsync() can be void, I think  I'll patch apt-get on the buildd
-    <youpi> (that bug has bitten me too many times in the past days to let it go further)
-    <youpi> for now it works
-    * youpi crosses fingers
diff --git a/open_issues/gcc.mdwn b/open_issues/gcc.mdwn
deleted file mode 100644
index a2a67632..00000000
--- a/open_issues/gcc.mdwn
+++ /dev/null
@@ -1,1354 +0,0 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009, 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_gcc]]
-
-Here's what's to be done for maintaining GCC.
-
-Apart from the target-specific configuration machinery, there shouldn't be any
-major differences within GCC between the GNU/Hurd and GNU/Linux ports, for
-example.  Especially all the compiler magic is all the same.
-
-[[!toc levels=2]]
-
-
-# [[General information|/gcc]]
-
-
-# [[Sources|source_repositories/gcc]]
-
-
-# Configuration
-
-<!--
-
-git checkout reviewed
-git diff --patience --stat=$COLUMNS,$COLUMNS --patch --src-prefix=./ --dst-prefix=./ --find-renames --ignore-space-change ..upstream/master | awk '/^diff/ { c = $0; } /^@@/ { print c; } { print; }' | less
--i
-/^---.*/([^.]*|.*\.texi.*|[^/]*gnu[^/]*)$|hurd|linux|nacl|nptl|glibc|gs:
-
--->
-
-Last reviewed up to the [[Git mirror's 3a930d3fc68785662f5f3f4af02474cb21a62056
-(2013-06-06) sources|source_repositories/gcc]].
-
-<http://gcc.gnu.org/install/configure.html> has documentation for the
-`configure` switches.
-
-  * Configure fragments that have `*linux*` cases might/should often contain
-    those for us (and GNU/k*BSD) as well.
-
-      * `configure.ac`
-
-      * `libstdc++-v3`
-
-          * `configure.host`
-
-            `abi_baseline_pair` etc. setting.  `config/abi/post/*-linux-gnu`.
-            TODO.
-
-          * `config/os/gnu-linux`
-
-            Is used for all GNU systems, as per `configure.host`.  Should
-            rename to `gnu-user` to reflect this?  TODO.
-
-      * `gcc/acinclude.m4`:`gcc_GAS_FLAGS`: always pass `--32` to assembler for
-        x86 Linux.  (Why?)
-
-      * `lib-prefix.m4` (present twice in GCC sources) contains one remaining
-        `linux`-only case.
-
-      * `libjava`
-
-        TODO:
-
-            classpath/include/jni_md-x86-linux-gnu.h
-
-        See below (`log_build`).
-
-            Makefile.am:## _GNU_SOURCE defined for some Linux builds.  It doesn't hurt to
-            Makefile.am:## always define it.  Some systems, including Linux, need
-            Makefile.am:# certain linuxthread functions get linked:
-            Makefile.am:## This is specific to Linux/{Free,Net,Open}BSD/Hurd and perhaps few others.
-            Makefile.am:  $(mkinstalldirs) $(DESTDIR)$(SDK_INCLUDE_DIR)/linux; \
-            Makefile.am:      $(DESTDIR)$(SDK_INCLUDE_DIR)/linux); \
-            Makefile.am:      $(DESTDIR)$(SDK_INCLUDE_DIR)/linux/$$headername.h; \
-            classpath/NEWS:  the epoll notification mechanism on Linux 2.6.
-            classpath/config.rpath:    linux* | k*bsd*-gnu)
-            classpath/config.rpath:    gnu* | linux* | k*bsd*-gnu)
-            classpath/config.rpath:  linux*oldld* | linux*aout* | linux*coff*)
-            classpath/config.rpath:  linux* | k*bsd*-gnu)
-            classpath/configure.ac:    *linux*)
-            classpath/configure.ac:    target_os=linux-gnu 
-            classpath/configure.ac:    AC_MSG_WARN(no, using x86-linux-gnu)
-            classpath/doc/cp-vmintegration.texinfo:has been primarily tested against Linux and lacks garbage collections, a
-            classpath/doc/cp-vmintegration.texinfo:Linux and Windows 2000.  As of June, 2004, it does not appear that ORP
-            classpath/doc/cp-vmintegration.texinfo:This is a free Java Virtual Machine that is being developed on GNU/Linux
-            classpath/doc/cp-vmintegration.texinfo:Runs on the x86 and PowerPC architectures, on the AIX, Linux, and Mac
-            classpath/gnu/classpath/SystemProperties.java:        && "Linux".equals(defaultProperties.get("os.name")))
-            classpath/gnu/java/nio/EpollSelectorImpl.java: * notification mechanism on GNU/Linux.
-            classpath/java/io/File.java:   * <strong>Implementation note</strong>: Unlike the RI, on Linux and UNIX
-            classpath/java/net/MimeTypeMapper.java:        // On Linux this usually means /etc/mime.types.
-            classpath/ltcf-cxx.sh:  linux*)
-            classpath/ltcf-cxx.sh:    linux*)
-            classpath/ltconfig:# Transform linux* to *-*-linux-gnu*, to support old configure scripts.
-            classpath/ltconfig:linux-gnu*) ;;
-            classpath/ltconfig:linux*) host=`echo $host | sed 's/^\(.*-.*-linux\)\(.*\)$/\1-gnu\2/'`
-            classpath/ltconfig:  version_type=linux
-            classpath/ltconfig:  version_type=linux
-            classpath/ltconfig:  version_type=linux
-            classpath/ltconfig:  version_type=linux
-            classpath/ltconfig:  version_type=linux
-            classpath/ltconfig:    version_type=linux
-            classpath/ltconfig:# No shared lib support for Linux oldld, aout, or coff.
-            classpath/ltconfig:linux-gnuoldld* | linux-gnuaout* | linux-gnucoff*)
-            classpath/ltconfig:# This must be Linux ELF.
-            classpath/ltconfig:linux-gnu*)
-            classpath/ltconfig:  version_type=linux
-            classpath/ltconfig:  # powerpc, because MkLinux only supported shared libraries with the
-            classpath/ltconfig:  # most powerpc-linux boxes support dynamic linking these days and
-            classpath/ltconfig:  # assume the GNU/Linux dynamic linker is in use.
-            classpath/ltconfig:  dynamic_linker='GNU/Linux ld.so'
-            classpath/ltconfig:  version_type=linux
-            classpath/ltconfig:  version_type=linux
-            classpath/ltconfig:  version_type=linux
-            classpath/ltconfig:  version_type=linux
-            classpath/ltconfig:  dynamic_linker='GNU/Linux ld.so'
-            classpath/ltconfig:  version_type=linux
-            classpath/ltconfig:  version_type=linux
-            classpath/ltconfig:    version_type=linux
-            classpath/ltmain.sh:#         compiler flags:		$LTCFLAGS
-            classpath/ltmain.sh:	  *-*-linux*)
-            classpath/ltmain.sh:	  darwin|linux|osf|windows|none)
-            classpath/ltmain.sh:	  # Like Linux, but with the current version available in
-            classpath/ltmain.sh:	linux)
-            classpath/m4/lib-link.m4:              dnl   2. if it's /usr/local/include and we are using GCC on Linux,
-            classpath/m4/lib-link.m4:                      linux* | gnu* | k*bsd*-gnu) haveit=yes;;
-            classpath/m4/lib-link.m4:                    dnl   2. if it's /usr/local/lib and we are using GCC on Linux,
-            classpath/m4/lib-link.m4:                            linux* | gnu* | k*bsd*-gnu) haveit=yes;;
-            classpath/m4/lib-prefix.m4:    dnl   3. if it's /usr/local/include and we are using GCC on Linux,
-            classpath/m4/lib-prefix.m4:              linux* | gnu* | k*bsd*-gnu) haveit=yes;;
-            classpath/m4/lib-prefix.m4:            CPPFLAGS="${CPPFLAGS}${CPPFLAGS:+ }-I$additional_includedir"
-            classpath/m4/lib-prefix.m4:    dnl   3. if it's /usr/local/lib and we are using GCC on Linux,
-            classpath/m4/lib-prefix.m4:              linux*) haveit=yes;;
-            classpath/m4/lib-prefix.m4:            LDFLAGS="${LDFLAGS}${LDFLAGS:+ }-L$additional_libdir"
-            classpath/m4/lib-prefix.m4:  dnl On glibc systems, the current practice is that on a system supporting
-            classpath/native/jni/java-net/javanet.c:      /* Not writable on Linux */
-            classpath/native/jni/java-nio/gnu_java_nio_VMChannel.c: * vector based read call (currently readv on Linux).
-            classpath/native/jni/java-nio/gnu_java_nio_VMChannel.c: * vector based read call (currently readv on Linux).
-            classpath/vm/reference/java/lang/VMProcess.java:  // Linux use a process-per-thread model, which means the same thread
-
-            configure.ac:     *-*-linux*)
-            configure.ac: AC_DEFINE(LINUX_THREADS, 1, [Define if using POSIX threads on Linux.])
-            include/config.h.in:/* Define if using POSIX threads on Linux. */
-            include/config.h.in:#undef LINUX_THREADS
-            include/posix-threads.h:# ifdef LOCK_DEBUG /* Assumes Linuxthreads */
-            include/posix-threads.h:#ifndef LINUX_THREADS
-            include/posix-threads.h:// pthread_mutex_destroy does nothing on Linux and it is a win to avoid
-            include/posix-threads.h:#endif /* LINUX_THREADS */
-            include/posix-threads.h:      // For linux_threads this is really a pointer to its thread data
-            include/posix-threads.h:// E.g. on X86 Linux, pthread_self() is too slow for our purpose.
-            include/posix-threads.h:// This code should probably go away when Linux/X86 starts using a
-            posix-threads.cc:#if defined(LINUX_THREADS) || defined(FREEBSD_THREADS)
-            posix-threads.cc:  // LinuxThreads (prior to glibc 2.1) usurps both SIGUSR1 and SIGUSR2.
-            posix-threads.cc:#else /* LINUX_THREADS */
-            posix-threads.cc:#endif /* LINUX_THREADS */
-            posix-threads.cc:      // In older glibc's (prior to 2.1.3), the cond_wait functions may 
-            posix-threads.cc:  // glibc 2.1.3 doesn't set the value of `thread' until after start_routine
-
-            configure.ac:      # We can save a little space at runtime if the mutex has m_count
-            configure.ac:      # or __m_count.  This is a nice hack for Linux.
-            configure.ac:      AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include <pthread.h>]], [[
-            configure.ac:          extern pthread_mutex_t *mutex; int q = mutex->m_count;
-
-        Makes sense to implement in our [[/libpthread]] ([[!taglink
-        open_issue_libpthread]])?
-
-            configure.ac: i?86-*-linux*)
-            configure.ac:    SIGNAL_HANDLER=include/i386-signal.h
-            configure.ac:    SIGNAL_HANDLER_AUX=include/x86_64-signal.h
-            include/i386-signal.h:// on an i386 based Linux system.
-            include/i386-signal.h:   directly rather than via glibc.  The sigaction structure that the
-            include/i386-signal.h: * called _directly_ by the kernel, because linuxthreads wraps signal
-            include/i386-signal.h: * handler to a linuxthreads wrapper, we will lose the PC adjustment
-            include/i386-signal.h: * Also, there may not be any unwind info in the linuxthreads
-
-            configure.ac:      *-linux*)
-            configure.ac:        host_os=linux;;
-
-            configure.host:  i[34567]86*-linux* | \
-            configure.host:  	can_unwind_signal=yes
-            configure.host:	libgcj_ld_symbolic='-Wl,-Bsymbolic'
-            configure.host:	if test x$slow_pthread_self = xyes \
-            configure.host:       [...]
-            configure.host:  i[34567]86*-kfreebsd*-gnu | x86_64*-kfreebsd*-gnu)
-            configure.host:        libgcj_ld_symbolic='-Wl,-Bsymbolic'
-            configure.host:        slow_pthread_self=
-
-            java/lang/natObject.cc:// What follows currenly assumes a Linux-like platform.
-            java/lang/natObject.cc:// Some of it specifically assumes X86 or IA64 Linux, though that
-            java/lang/natObject.cc:#   define INVALID_THREAD_ID 0  // Works for Linux?
-            java/lang/natObject.cc:  const unsigned MIN_SLEEP_USECS = 2001; // Shorter times spin under Linux.
-            java/lang/natVMClassLoader.cc:      // a module named (eg, on Linux) `lib-gnu-pkg-quux.so', followed
-
-            libltdl/acinclude.m4:x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*|s390*-*linux*|sparc*-*linux*)
-            libltdl/acinclude.m4:        x86_64-*linux*)
-            libltdl/acinclude.m4:        ppc64-*linux*|powerpc64-*linux*)
-            libltdl/acinclude.m4:          LD="${LD-ld} -m elf32ppclinux"
-            libltdl/acinclude.m4:        s390x-*linux*)
-            libltdl/acinclude.m4:        sparc64-*linux*)
-            libltdl/acinclude.m4:        x86_64-*linux*)
-            libltdl/acinclude.m4:        ppc*-*linux*|powerpc*-*linux*)
-            libltdl/acinclude.m4:        s390*-*linux*)
-            libltdl/acinclude.m4:        sparc*-*linux*)
-            libltdl/acinclude.m4:    # Under GNU Hurd, this test is not required because there is
-            libltdl/acinclude.m4:  version_type=linux
-            libltdl/acinclude.m4:  version_type=linux
-            libltdl/acinclude.m4:  version_type=linux
-            libltdl/acinclude.m4:  version_type=linux
-            libltdl/acinclude.m4:  version_type=linux
-            libltdl/acinclude.m4:  version_type=linux
-            libltdl/acinclude.m4:		version_type=linux
-            libltdl/acinclude.m4:# No shared lib support for Linux oldld, aout, or coff.
-            libltdl/acinclude.m4:linux*oldld* | linux*aout* | linux*coff*)
-            libltdl/acinclude.m4:# This must be Linux ELF.
-            libltdl/acinclude.m4:linux*)
-            libltdl/acinclude.m4:  version_type=linux
-            libltdl/acinclude.m4:  # powerpc, because MkLinux only supported shared libraries with the
-            libltdl/acinclude.m4:  # most powerpc-linux boxes support dynamic linking these days and
-            libltdl/acinclude.m4:  # assume the GNU/Linux dynamic linker is in use.
-            libltdl/acinclude.m4:  dynamic_linker='GNU/Linux ld.so'
-            libltdl/acinclude.m4:  version_type=linux
-            libltdl/acinclude.m4:  version_type=linux
-            libltdl/acinclude.m4:  version_type=linux
-            libltdl/acinclude.m4:  version_type=linux
-            libltdl/acinclude.m4:  version_type=linux
-            libltdl/acinclude.m4:    version_type=linux
-            libltdl/acinclude.m4:  version_type=linux
-            libltdl/acinclude.m4:# This must be Linux ELF.
-            libltdl/acinclude.m4:linux*)
-            libltdl/acinclude.m4:  linux*)
-            libltdl/acinclude.m4:linux*)
-            libltdl/acinclude.m4:      linux*)
-            libltdl/acinclude.m4:	    # Linux and Compaq Tru64 Unix objects are PIC.
-            libltdl/acinclude.m4:	    # Linux and Compaq Tru64 Unix objects are PIC.
-            libltdl/acinclude.m4:    linux*)
-            libltdl/acinclude.m4:    linux*)
-            libltdl/acinclude.m4:  gnu* | linux* | kfreebsd*-gnu | knetbsd*-gnu)
-            libltdl/acinclude.m4:    # GNU and its variants, using gnu ld.so (Glibc)
-            libltdl/ltmain.sh:	  darwin|linux|osf|windows)
-            libltdl/ltmain.sh:	  # Like Linux, but with the current version available in
-            libltdl/ltmain.sh:	linux)
-            shlibpath.m4:  version_type=linux
-            shlibpath.m4:  version_type=linux
-            shlibpath.m4:  version_type=linux
-            shlibpath.m4:  version_type=linux
-            shlibpath.m4:  version_type=linux
-            shlibpath.m4:		version_type=linux
-            shlibpath.m4:# No shared lib support for Linux oldld, aout, or coff.
-            shlibpath.m4:linux*oldld* | linux*aout* | linux*coff*)
-            shlibpath.m4:# This must be Linux ELF.
-            shlibpath.m4:linux*|k*bsd*-gnu)
-            shlibpath.m4:  version_type=linux
-            shlibpath.m4:  # powerpc, because MkLinux only supported shared libraries with the
-            shlibpath.m4:  # most powerpc-linux boxes support dynamic linking these days and
-            shlibpath.m4:  # assume the GNU/Linux dynamic linker is in use.
-            shlibpath.m4:  dynamic_linker='GNU/Linux ld.so'
-            shlibpath.m4:  version_type=linux
-            shlibpath.m4:  version_type=linux
-            shlibpath.m4:  version_type=linux
-            shlibpath.m4:  version_type=linux
-            shlibpath.m4:    version_type=linux
-            shlibpath.m4:  version_type=linux
-
-            testsuite/lib/libjava.exp:    if { [regexp "linux" $target_triplet] } {
-
-        Adds `-specs=libgcj-test.spec`, which is created by `configure`.  *This
-        spec file is read by gcj when linking.  It is only used by the testing
-        harnesses (in libjava and gdb).*  TODO.  [[!taglink open_issue_gdb]].
-
-      * `libgcc`
-
-        TODO:
-
-          * `config/t-linux`
-          * `config/i386/t-linux`
-          * `config/i386/linux-unwind.h`
-
-      * `libitm`
-
-        TODO:
-
-          * `libitm/config/linux`
-
-  * `hurd/usr`
-
-    `NATIVE_SYSTEM_HEADER_DIR`, `638454a19c1c08f01c10517bc72a114250fc4f33`,
-    [[!message-id "mcrzkhcbftp.fsf@coign.corp.google.com"]].
-
-    Debian.
-
-      * Eventually: get rid of this special-casing.  [[!message-id
-        "gckk1s$e0b$1@ger.gmane.org"]].
-
-  * [[`libmudflap`|libmudflap]].
-
-  * [`-fsplit-stack`](http://nickclifton.livejournal.com/6889.html)
-
-    IRC, freenode, #hurd, 2014-01-10:
-
-        <gnu_srs1> Hi, I assume gcc -fsplit-stack is not yet supported?
-        <braunr> gnu_srs1:
-          https://lists.gnu.org/archive/html/bug-hurd/2013-06/msg00100.html
-        <gnu_srs1> braunr: That's exactly where the problem is:
-          src/libgcc/generic-morestack.c:814:__morestack_load_mmap
-        <gnu_srs1> no return value recorded
-        <gnu_srs1> creating a call: page = mmap ((void*)0x0, 0, 4, 2, -1, 0);,
-          returning EINVAL
-        <braunr> lenght of 0 ?
-        <gnu_srs1> yes, __morestack_current_segment, is zero
-        <braunr> mmap is expected to return einval if the requested mapping has
-          a size of 0 ..
-        <braunr> i don't know what split stack is, but i remember it's a
-          problem for the hurd
-        <gnu_srs1> sorry, the address is zero from the above, and the length in
-          the call is zero too
-        <braunr> yes that's what i understood
-        <braunr> and i'm telling you it's normal
-        <braunr> the size is invalid
-        <gnu_srs1> libgcc/generic-morestack.c:  mmap
-          (__morestack_current_segment, 0, PROT_READ, MAP_ANONYMOUS, -1, 0);
-        <braunr> well this is wrong
-        <gnu_srs1> and the error code stays, not being reset in subsequent
-          calls
-        <gnu_srs1> causing an error later on
-        <braunr> as roland says in
-          https://lists.gnu.org/archive/html/bug-hurd/2013-06/msg00102.html, it
-          should be possible to support split-stack now that we have tls
-        <gnu_srs1> as thomas reported
-        <braunr> i don't see the relation between split-stack and the mmap
-          invocation
-        <gnu_srs1> tls s in 2.17-97, right? that's the one I tried
-        <braunr> tls is there, but not split stack support
-        <braunr> and libpthread still has bugs related to changing the stack
-          apparently
-        <braunr> fixed upstream but not yet in debian packages
-        <braunr> unless you want to try with the thread destruction packages
-        <braunr> not sure it will change much though
-
-      * Also see `libgcc/config/i386/morestack.S`: comments w.r.t
-        `TARGET_THREAD_SPLIT_STACK_OFFSET`/`%gs:0x30` usage; likely needs
-        porting.
-
-      * As per `libgcc/config/i386/t-stack-i386`, the former file is only used
-        for `-fsplit-stack` support -- which is currently enabled for us in
-        `libgcc/config.host`.
-
-      * `gcc/config/gnu-user.h` defines `*SPLIT_STACK*` macros -- which aren't
-        valid for us (yet), I think.
-
-      * Also see [[!sourceware_PR 10686]], glibc commit
-        ecbf434213c0333d81706074e4d107ac45011635 `Reserve new TLS field for x86
-        and x86_64` (`__private_ss`).
-
-      * Might `-fsplit-stack` be useful for us with respect to our
-        [[multithreaded|multithreading]] libraries?
-
-  * `gcc/ada`, `gcc/testsuite/ada`, `gcc/testsuite/gnat.dg`, `gnattools`,
-    `libada` (not reviewed)
-
-      * [[Ada (GNAT)|GNAT]] support is work in progress.
-
-  * `gcc/go`, `gcc/testsuite/go.test`, `libgo` (not reviewed)
-
-      * The [[Google Go's libgo|gccgo]] (introduced in
-        e440a3286bc89368b8d3a8fd6accd47191790bf2 (2010-12-03)) needs
-        OS configuration / support.
-
-  * `--enable-frame-pointer`
-
-    `gcc/configure.ac`: `enable_frame_pointer=no`
-
-  * `--with-dwarf2`?
-
-  * `--enable-werror`
-
-  * `--enable-checking`
-
-  * `--enable-linker-build-id`
-
-  * `--enable-gnu-unique-object`
-
-  * `--enable-lto`
-
-  * `--enable-indirect-function`
-
-    [[IFUNC]]
-
-  * <http://gcc.gnu.org/ml/gcc/2007-11/msg00289.html>,
-    <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00672.html>
-
-      * `gcc/config/t-linux` should be named `gcc/config/t-gnu-user` or
-        similar.  Likewise for `gcc/config/i386/t-linux`.
-
-  * Debian's GCC package has Hurd-specific patches.  Some have been forwarded
-    upstream (and have been ignored).  [[Thomas_Schwinge|tschwinge]] is working
-    on getting them integrated.
-
-  * [\[meta-bug\] bootstrap bugs for
-    \*-gnu\*](http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21824)
-
-  * [build system: gcc\_cv\_libc\_provides\_ssp and
-    NATIVE\_SYSTEM\_HEADER\_DIR](http://gcc.gnu.org/ml/gcc/2008-10/msg00130.html)
-
-  * [-fstack-protector shouldn't use TLS in freestanding
-    mode](http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838)
-
-      * See also commit bf1c0af128f33bd342636c4afeaa8f3a8a7cf8ca (reverted in
-        commit a204f0622242865ffea889bd698bc7c7bd236bd1), commit
-        05c1aa95e6c37b3b281d749c76c673392941a031.
-
-  * Check before/after Joseph changes.  (Should be fine.)
-
-  * 34618b3190c110b8926cc2b1db4b4eac95451995 »config-list.mk«
-
-    What's this used for?  (Check ML.)  Ask to include i686-pc-gnu (once it is
-    buildable out of the box)?  See also
-    73905b5de0d9a086f22ded7638bb1c0ae1b91326.
-
-  * [low] [[toolchain/cross-gnu]] toolchain bootstrap vs. `fenv.h` in libgcc's
-    libbid:
-
-        [...]/xgcc [...] -DIN_LIBGCC2 -fbuilding-libgcc [...] -Dinhibit_libc [...] -o bid_decimal_globals.o [...] -c [...]/libgcc/config/libbid/bid_decimal_globals.c
-        [...]/libgcc/config/libbid/bid_decimal_globals.c:47:18: fatal error: fenv.h: No such file or directory
-        compilation terminated.
-        make[1]: *** [bid_decimal_globals.o] Error 1
-        make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj/i686-pc-gnu/libgcc'
-        make: *** [all-target-libgcc] Error 2
-
-    See threads at [[!message-id
-    "AANLkTinY1Cd4_qO_9euYJN8zev4hdr7_ANpjNG+yGRMn@mail.gmail.com"]],
-    [[!message-id "20110328225532.GE5293@synopsys.com"]], [[!message-id
-    "4D52D522.1040804@gmail.com"]].  Can simply configure the first GCC with
-    `--disable-decimal-float`.
-
-    Alternatively, can we use `#ifndef inhibit_libc` for this (these?) file(s)?
-    See `generic-nonstrack.c`, for example.  The latter (and also
-    `generic-morestack-thread.c`) also has a nice explanation of `inhibit_libc`
-    which could be centralized at one place, for example definition of
-    `inhibit_libc`.
-
-  * [low] [[toolchain/cross-gnu]]
-
-        The directory that should contain system headers does not exist:
-          /media/boole-data/thomas/tmp/gnu-0/sys_root/usr/include
-        make[2]: *** [stmp-fixinc] Error 1
-        make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj/gcc'
-        make[1]: *** [all-gcc] Error 2
-        make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj'
-
-    `mkdir` the directory for now, but what is really going on?  GCC has *use
-    `/usr/include` patch*, but glibc still installs into `/include/`?
-
-  * `__GLIBC__`
-
-    IRC, freenode, #hurd, 2012-01-05:
-
-        <civodul> on GNU/kFreeBSD, it's GCC that defines __GLIBC__, funny
-        <youpi> ??
-        <youpi> not from features.h ?
-        <civodul> in gcc/config/kfreebsd-gnu.h
-        <civodul> :-)
-        <pinotree> correct, it's enabled in gcc's config
-        <pinotree> i discovered that after banging my head on the wall trying
-          to find out why some stuff wasn't compiling even after kfreebsd
-          porting patches adding preprocessors checks for __GLIBC__
-
-    GNU/kFreeBSD and GNU/kNetBSD: commit
-    6396cc37141180db4d2c8f73cab4f5977d8a1e19 (2004-06-24, r83577),
-    GNU/kOpenSolaris: commit 3bef40126fb1633018fce47828df0fa9f65f110c
-    (2009-01-29, r143768).  See also GDB commits
-    fda1b24c62843f81d31de2af57b1ed9c55f1e348 and
-    1acb4f4ff73d20850a7524fc939d2651be75f47b, and binutils commits
-    e3081899be7570eb90ccfd5d767950d3a62871ee,
-    127c4d4a4fe65bd17ea64db1be7f3c93d393afcb,
-    47dbf5b634b955c2db1221715d15751e1281546a, and
-    ad2be7e8b846f4cd67fa1e032f98d5dc1cdb6b8d.
-
-    IRC, freenode, #hurd, 2012-05-25:
-
-        <gnu_srs> Hi, looks like __GLIBC__ is not defined by default for GNU?
-        <gnu_srs> touch foo.h; cpp -dM foo.h|grep LIBC: empty
-        <braunr> gnu_srs: well, this only tells your the compiler defaults
-        <tschwinge> gnu_srs: See the email I just sent.
-
-    [[!message-id "87396od3ej.fsf@schwinge.name"]]
-
-        <braunr> __GLIBC__ would probably be introduced by a glibc header
-        <gnu_srs> tschwinge: I saw your email. I wonder if features.h is
-          included in the kFreeBSD build of webkit.
-        <gnu_srs> It is defined in their build, but not in the Hurd build.
-        <pinotree> gcc on kfreebsd unconditionally defines __GLIBC__
-        <pinotree> (a bit stupid choice imho, but hardly something that could
-          be changed now...)
-        <braunr> :/
-        <braunr> personally i don't consider this only "a bit" stupid, as
-          kfreebsd is one of the various efforts pushing towards portability
-        <braunr> and using such hacks actually hinders portability ...
-        <pinotree> yeah don't tell me, i can remember at least half dozen of
-          occasions when a code wouldn't have been compiling at all on other
-          glibc platforms otherwise
-        <pinotree> sure, i have nothing against kfreebsd's efforts, but making
-          gcc define something which is proper of the libc used is stupid
-        <braunr> it is
-        <pinotree> i spotted changes like:
-        <pinotree> -#ifdef __linux
-        <pinotree> +#if defined(__linux__) || defined(__GLIBC__)
-        <pinotree> and wondered why they wouldn't work at all for us... and
-          then realized there were no #include in that file before that
-          preprocessor check
-        <tschwinge> This is even in upstream GCC gcc/config/kfreebsd-gnu.h:
-        <tschwinge> #define GNU_USER_TARGET_OS_CPP_BUILTINS()               \
-        <tschwinge>   do                                            \
-        <tschwinge>     {                                           \
-        <tschwinge>         builtin_define ("__FreeBSD_kernel__");  \
-        <tschwinge>         builtin_define ("__GLIBC__");           \
-        <tschwinge>         builtin_define_std ("unix");            \
-        <tschwinge>         builtin_assert ("system=unix");         \
-        <tschwinge>         builtin_assert ("system=posix");        \
-        <tschwinge>     }                                           \
-        <tschwinge>   while (0)
-        <tschwinge> I might raise this upstream at some point.
-        <pinotree> tschwinge: i could guess the change was proposed by the
-          kfreebsd people, so asking them before at d-bsd@d.o would be a start
-        <tschwinge> pinotree: Ack.
-        <pinotree> especially that they would need to fix stuff afterwards
-        <pinotree> imho we could propose them the change, and if they agree put
-          that as local patch to debian's gcc4.6/.7 after wheezy, so there is
-          plenty of time for them to fix stuff
-        <pinotree> what should be done first is, however, find out why that
-          define has been added to gcc
-
-    [[!message-id "201211061305.02565.pino@debian.org"]].
-
-    IRC, freenode, #hurd, 2014-01-08:
-
-        <gnu_srs> How come __GLIBC__ is defined in gcc for kFreeBSD and not
-          GNU? They sometimes use that instead of __FreeBSD_kernel__
-        <pochu> it's defined by libc's /usr/include/features.h
-        <gnu_srs> pochu: __GLIBC__ is defined in features.h both for GNU and
-          kFreeBSD, but only in gcc/cpp for kFreeBSD: touch foo.h;gcc -E -dM
-          foo.h|grep GLIBC
-        <pochu> gnu_srs: #include <stdlib.h>
-        <gnu_srs> pochu: they both include <features.h>
-        <pochu> gnu_srs: I get __GLIBC__ defined if I include features.h
-        <pochu> with an empty file (as suggested by your `touch foo.h') I don't
-          get it defined, whether on hurd or linux, but I think that's expected
-        <gnu_srs> pochu: might be so but it is not pre-defined in CPP, as it is
-          for kFreeBSD.
-        <gnu_srs> I think it should not be defined, or it should be defined by
-          all three: GNU,.kFreeBSD and Linux
-        <gnu_srs> an anomaly, something for tschwinge
-        <braunr> https://lists.debian.org/debian-bsd/2012/11/msg00016.html
-        <gnu_srs> braunr: good finding, I assume nothing has happened since
-          then?
-        <braunr> not likely
-
-  * [low] Does `-mcpu=native` etc. work?  (For example,
-    2ae1f0cc764e998bfc684d662aba0497e8723e52.)
-
-  * transactional memory, 4c0315d05fa0f707875686abc4f91f7a979a7c7b
-
-      * `config/mmap.m4`
-
-      * In `libitm/config/`, is the generic stuff (`tls.h`, etc.) enough for
-        us?
-
-      * f29a2041f32773464e226a83f41762c2e9cf658e
-        (e53a96c2136f7cdff4699475fea41afeed9dece3)
-
-    Testresults same as for GNU/Linux.
-
-  * [high] 3efc00f6f17778172d3fa7ac737fa1473b3b4d5a, `Check __GLIBC__ when
-    using __SIGRTMIN`.  GCC PR52390.  Fixed by
-    8d2259c83f94c082ad8a00b5d00bb639ce24efce.
-
-  * 15ac1e637ad0cb92bf7629205c617ea847a4b810 `Build 64-bit libffi multilib for
-    i?86-linux`.
-
-  * `libstdc++`: uses `_GLIBCXX_HAVE_TLS`, but where is this defined?  Supposed
-    to come from `config/tls.m4:GCC_CHECK_TLS`?
-
-  * `libgcc/gthr-posix.h:__gthread_active_p` -- is this suitable for us?  This
-    is used in libgcc for ObjC wrapper stuff and similar in libstdc++.
-    C.f. [[!message-id "x57jobtqx89w.fsf@frobland.mtv.corp.google.com"]],
-    [[!message-id "x57jd359fkx3.fsf@frobland.mtv.corp.google.com"]] as well as
-    [[!debbug 629866]]/[[!message-id
-    "20110609002620.GA16719@const.famille.thibault.fr"]].  commit
-    026e608ecebcb2a6193971006a85276307d79b00.
-
-  * [[`libsanitizer`|_san]] (not reviewed)
-
-    A lot of Linux-specific things.
-
-  * `libcilkrts`
-
-    IRC, freenode, #hurd, 2014-01-10:
-
-        <youpi> bwaarf, libcilkrts in gcc-4.9
-        <p2-mate> libcilkrts?
-        <youpi> the runtime for the cilk language I guess
-        <tschwinge> Yes.  That most likely needs disabling for us.
-        <tschwinge> I'll hve a look eventually.
-        <tschwinge> As soon as I get
-          <http://news.gmane.org/find-root.php?message_id=%3C87wqjjo5kx.fsf%40kepler.schwinge.homeip.net%3E>
-          resolved, actually.
-
-    [[!debbug 734973]].
-
-  * `WCONTINUED`
-
-    IRC, OFTC, #debian-hurd, 2014-02-25:
-
-        <gnu_srs> youpi: some gcc-4.9 packages (and source) are needed for
-          gnat-4.9 to build: Is it OK to propose this patch:
-          http://paste.debian.net/84079/
-          --- a/src/gcc/lto_lto.c.orig    2014-02-14 19:22:14.000000000 +0100
-          +++ b/src/gcc/lto/lto.c 2014-02-25 20:50:20.000000000 +0100
-          @@ -2476,7 +2476,11 @@
-             int status;
-             do
-               {
-          +#ifdef __GNU__
-          +      int w = waitpid(0, &status, WUNTRACED);
-          +#else
-                 int w = waitpid(0, &status, WUNTRACED | WCONTINUED);
-          +#endif
-                 if (w == -1)
-                  fatal_error ("waitpid failed");
-        <youpi> gnu_srs: rather ifndef WCONTINUED
-
-
-
-# Build
-
-Here's a log of a GCC build run; this is from our [[Git repository's
-2a3496bebfe9d89f11d0b7a591afac55e11d5263 (2013-06-06;
-3a930d3fc68785662f5f3f4af02474cb21a62056 (2013-06-06))
-sources|source_repositories/gcc]], run on kepler.SCHWINGE and coulomb.SCHWINGE.
-
-    $ export LC_ALL=C
-    $ (cd ../master/ && contrib/gcc_update --touch)
-    $ ../master/configure --prefix="$PWD".install SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 --enable-languages=all,ada 2>&1 | tee log_build
-    [...]
-    $ make 2>&1 | tee log_build_
-    [...]
-
-Different hosts may default to different shells and compiler versions; thus
-harmonized.
-
-We're stuck with GCC 4.6 until there are Debian *gnat-4.7*/*gnat-4.8* packages
-avaible.
-
-This takes up around 3.5 GiB, and needs roughly 3.5 h on kepler.SCHWINGE and
-15.25 h on coulomb.SCHWINGE.
-
-<!--
-
-    $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-test) 2>&1 | tee log_install && test -f .go-test && make -k check 2>&1 | tee log_test
-
--->
-
-
-## Analysis
-
-    $ toolchain/logs/process gcc build
-
-  * [[`checking if gcc static flag -static
-    works... no`|glibc_madvise_vs_static_linking]]
-
-    Addressed in Debian glibc.
-
-  * `gcc/config/host-linux.c` vs. `host-default.c`
-
-      * `gcc/config/x-linux`
-
-  * *fixincludes* stuff
-
-  * malloc?
-
-        -cat ../../hurd/gcc/config/i386/pmm_malloc.h > mm_malloc.h
-        +cat ../../hurd/gcc/config/i386/gmm_malloc.h > mm_malloc.h
-
-    Comes from `gcc/config.gcc`: `i386/t-pmm_malloc` vs. `i386/t-gmm_malloc`
-    for `i[34567]86-*-linux*` vs. `i[34567]86-*-*`.
-
-  * `libgomp`
-
-      * `libgomp/config/linux`, `libgomp/config/linux/x86`
-
-    `sed`ed away in `log_build*`.  TODO.
-
-      * `-march=i486 -mtune=i686`
-
-    `sed`ed away in `log_build*`.  This comes from `libgomp/configure.tgt`,
-    where this is added to `XCFLAGS` for `i[456]86-*-linux*` only.  TODO?
-
-  * Missing `EOWNERDEAD`, `ENOTRECOVERABLE`.  What're they used for?
-
-  * `RLIMIT_VMEM`.  Usage kosher?
-
-  * `libtool: link: ar rc .libs/libstdc++.a [...]`
-
-    Just different order of object files, or another problem?  TODO
-
-  * `libobjc/encoding.c`:
-
-         libtool: compile:  [...]/hurd/master.build/./gcc/xgcc [...] [...]/hurd/master/libobjc/encoding.c -c [...]
-        +[...]/hurd/master/libobjc/encoding.c:128:1: warning: '_darwin_rs6000_special_round_type_align' defined but not used [-Wunused-function]
-
-  * `libobjc/thr.c`: `gcc/gthr-posix.h`
-
-         libtool: compile:  [...]/hurd/master.build/./gcc/xgcc [...] [...]/hurd/master/libobjc/thr.c -c [...]
-        +In file included from [...]/hurd/master/libobjc/../libgcc/gthr.h:142:0,
-        +                 from [...]/hurd/master/libobjc/thr.c:45:
-        +../libgcc/gthr-default.h: In function '__gthread_objc_thread_set_priority':
-        +../libgcc/gthr-default.h:388:41: warning: unused parameter 'priority' [-Wunused-parameter]
-
-  * `/proc/self/*`
-
-        -checking for /proc/self/exe... yes
-        -checking for /proc/self/maps... yes
-        +checking for /proc/self/exe... no
-        +checking for /proc/self/maps... no
-
-  * GCJ: `java-signal.h`, `java-signal-aux.h`
-
-        -config.status: linking ../../../hurd/libjava/include/i386-signal.h to include/java-signal.h
-        -config.status: linking ../../../hurd/libjava/include/i386-signal.h to include/java-signal-aux.h
-        +config.status: linking ../../../hurd/libjava/include/default-signal.h to include/java-signal.h
-        +config.status: linking ../../../hurd/libjava/include/default-signal.h to include/java-signal-aux.h
-
-  * GCJ: `jni_md.h`
-
-        -checking jni_md.h support... yes
-        +checking jni_md.h support... configure: WARNING: no
-
-  * *default library search path*
-
-        -checking for the default library search path... /lib /usr/lib /lib/i386-linux-gnu /usr/lib/i386-linux-gnu /lib/i486-linux-gnu /usr/lib/i486-linux-gnu /usr/local/lib
-        +checking for the default library search path... /lib /usr/lib
-
-    [[binutils]] issue?  Should be aligned by Samuel's binutils patch.
-
-  * `./classpath/[...]/*.properties`
-
-    Just different order of files, or another problem?
-
-  * `libjava/gnu/gcj/util/natGCInfo.cc`
-
-         libtool: compile:  [...]/hurd/master.build/./gcc/xgcc [...] -c ../../../master/libjava/gnu/gcj/util/natGCInfo.cc [...]
-        +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:440:1: warning: unused parameter 'name' [-Wunused-parameter]
-        +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:446:1: warning: unused parameter 'name' [-Wunused-parameter]
-        +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:452:1: warning: unused parameter 'name' [-Wunused-parameter]
-
-  * `libgcj.la`
-
-    Just different order of object files, or another problem?
-
-    Is there a pattern that GNU/Hurd hands out the files alphabetically sorted
-    where it wouldn't need to ([[!taglink open_issue_hurd]])?
-
-  * `libjvm.la`, `.libs/libjvm.so`, `libgij.la`, `.libs/libgij.so.12.0.0`
-
-    `-Wl,-Bsymbolic` vs. `-Wl,-Bsymbolic-functions`
-
-  * `jar`
-
-         make[2]: Entering directory `[...]/hurd/master.build/[ARCH]/libjava'
-        -: make ; exec make "AR_FLAGS=rc" [...] "RANLIB=ranlib" "DESTDIR=" "JAR=[...]/hurd/master.build/[ARCH]/libjava/scripts/jar" DO=all multi-do
-        +: make ; exec make "AR_FLAGS=rc" [...] "RANLIB=ranlib" "DESTDIR=" "JAR=jar" DO=all multi-do
-
-    Probably because kepler.SCHWINGE has an OpenJDK `/usr/bin/jar`, and
-    coulomb.SCHWINGE a GCJ one.
-
-    There are other instances of this in the following.
-
-  * `value-unwind.h`
-
-        -DEFINES='' HEADERS='../../../master/libgcc/config/i386/value-unwind.h' \
-        +DEFINES='' HEADERS='' \
-                        ../../../master/libgcc/mkheader.sh > tmp-libgcc_tm.h
-
-    Comes from `gcc/config.gcc`: for `i[34567]86-*-linux*`
-    vs. `i[34567]86-*-*`, but apparently is important only for *x86_64* anyway.
-
-  * `soft-fp` prototypes
-
-         ../../../master/libgcc/soft-fp/eqtf2.c:34:9: warning: no previous prototype for '__eqtf2' [-Wmissing-prototypes]
-        +../../../master/libgcc/soft-fp/eqtf2.c:50:1: warning: no previous prototype for '__netf2' [-Wmissing-prototypes]
-
-         ../../../master/libgcc/soft-fp/getf2.c:34:9: warning: no previous prototype for '__getf2' [-Wmissing-prototypes]
-        +../../../master/libgcc/soft-fp/getf2.c:50:1: warning: no previous prototype for '__gttf2' [-Wmissing-prototypes]
-
-         ../../../master/libgcc/soft-fp/letf2.c:34:9: warning: no previous prototype for '__letf2' [-Wmissing-prototypes]
-        +../../../master/libgcc/soft-fp/letf2.c:50:1: warning: no previous prototype for '__lttf2' [-Wmissing-prototypes]
-
-  * `libatomic` on GNU/Linux compiles several more files than on GNU/Hurd.  Is
-    that correct?  Probably futex support.
-
-  * 2e2db3f92b534460c68c2f9ae64455884424beb6..3336556d2cb32f46322922a83015f760cfb79d8f
-
-    Both GNU/Linux and GNU/Hurd:
-
-        -checking assembler for rep and lock prefix... yes
-        +checking assembler for rep and lock prefix... no
-
-    TODO.
-
-
-# Install
-
-    $ make install 2>&1 | tee log_install
-    [...]
-
-This takes up around 1.1 GiB, and needs roughly 5 min on kepler.SCHWINGE and 37
-min on coulomb.SCHWINGE.
-
-
-## Analysis
-
-    $ toolchain/logs/process gcc install
-
-  * `libtool: finish`: `ldconfig` is not run for the Hurd.
-
-    [[libtool]].
-
-  * `libjvm.la`, `.libs/libjvm.so`, `libgij.la`, `.libs/libgij.so.12.0.0`
-
-    `-Wl,-Bsymbolic` vs. `-Wl,-Bsymbolic-functions` (as above)
-
-  * `jar`: as above.
-
-
-# Testsuite
-
-<http://gcc.gnu.org/install/test.html>
-
-kepler.SCHWINGE:
-
-    $ make -k check 2>&1 | tee log_test
-    [...]
-
-coulomb.SCHWINGE:
-
-    $ awk '/^maybe-check-target/ { next; }; /^maybe-check-[^:]*:./ { print; };' < Makefile
-    maybe-check-fixincludes: check-fixincludes
-    maybe-check-gcc: check-gcc
-    maybe-check-intl: check-intl
-    maybe-check-libbacktrace: check-libbacktrace
-    maybe-check-libcpp: check-libcpp
-    maybe-check-libdecnumber: check-libdecnumber
-    maybe-check-libiberty: check-libiberty
-    maybe-check-zlib: check-zlib
-    maybe-check-gnattools: check-gnattools
-    maybe-check-lto-plugin: check-lto-plugin
-    $ grep ^CHECK_TARGETS < gcc/Makefile
-    CHECK_TARGETS =  check-ada check-c check-c++ check-fortran check-java check-lto check-objc
-
-    $ export LC_ALL=C
-
-    [reboot]
-    $ make -k check-fixincludes 2>&1 | tee log_test_1_check-fixincludes
-    [...]
-    $ make -k -C gcc check-ada 2>&1 | tee log_test_2_gcc_check-ada
-    [...]
-    [reboot]
-    $ make -k -C gcc check-c 2>&1 | tee log_test_2_gcc_check-c
-    [...]
-    [reboot]
-    $ make -k -C gcc check-c++ 2>&1 | tee log_test_2_gcc_check-c++
-    [...]
-    [reboot]
-    $ make -k -C gcc check-fortran check-java check-lto check-objc 2>&1 | tee log_test_2_gcc_check-fortran,check-java,check-lto,check-objc
-    [...]
-    [reboot]
-    $ make -k check-intl check-libbacktrace check-libcpp check-libdecnumber check-libiberty check-zlib check-gnattools check-lto-plugin 2>&1 | tee log_test_3
-    [...]
-    $ make -k check-target 2>&1 | tee log_test_4_check-target
-    [...]
-
-This needs roughly 7.5 h on kepler.SCHWINGE and 3.75 h (`check-fixincludes`,
-`gcc/check-ada`) + 14 h (`gcc/check-c`) + 4.5 h (`gcc/check-c++`) + 7.25 h
-(`gcc/check-fortran`, `gcc/check-java`, `gcc/check-lto`, `gcc/check-objc`) +
-10.25 h (`check-intl`, [...], `check-lto-plugin`, `check-target`) = 39.75 h on
-coulomb.SCHWINGE.
-
-
-## Analysis
-
-  A lot of the failures are due to gcc's unwind support not knowing about signal trampoline on GNU/Hurd, this is a TODO.
-
-
-    $ toolchain/logs/process gcc test
-
-  * PTYs
-
-    Occasionally tests FAIL due to:
-
-        spawn -open -1 failed, 1 5, The system has no more ptys.  Ask your system administrator to create more.
-
-    TODO.
-
-  * Some are correctly UNSUPPORTED:
-
-      * [[IFUNC]]
-
-        Also multiversioning, `g++.dg/ext/mv*`, for example (several of which
-        started FAILing (ICE) on kepler.SCHWINGE).
-
-      * SSE2 (`sse2_runtime`)
-
-        `g++.dg/other/i386-1.C`, `g++.dg/other/pr40446.C`,
-        `g++.dg/other/pr49133.C`, `gcc.dg/compat/union-m128-1_main.c`,
-        `gcc.dg/compat/vector-1a_main.c`, `gcc.dg/compat/vector-2a_main.c`,
-        `gcc.dg/pr36584.c`, `gcc.dg/pr37544.c`, `gcc.dg/torture/pr16104-1.c`,
-        `gcc.dg/torture/pr35771-1.c`, `gcc.dg/torture/pr50444.c`,
-        `gcc.dg/torture/stackalign/alloca-2.c`,
-        `gcc.dg/torture/stackalign/alloca-3.c`,
-        `gcc.dg/torture/stackalign/push-1.c`,
-        `gcc.dg/torture/stackalign/vararg-3.c`, `gcc.target/i386/pr39315-2.c`,
-        `gcc.target/i386/pr39315-4.c`, `gcc.target/i386/pr44948-2a.c`,
-        `gcc.target/i386/pr46880.c`, `gcc.target/i386/pr52736.c`,
-        `gcc.target/i386/pr54703.c`, `gcc.target/i386/sse2-extract-1.c`,
-        several from `gfortran.fortran-torture`
-
-      * [[`asan.exp`|_san]]
-
-      * missing profiling C library (`-lc_p`)
-
-        `g++.old-deja/g++.law/profile1.C`, `gcc.dg/20021014-1.c`,
-        `gcc.dg/nest.c`, `gcc.dg/nested-func-4.c`, `gcc.dg/pr32450.c`,
-        `gcc.dg/pr43643.c`
-
-      * other C libraries
-
-        `gcc.target/i386/long-double-64-2.c`,
-        `gcc.target/i386/long-double-80-3.c`
-
-  * `gcc`
-
-        spawn [open ...]
-        FAIL: gcc.dg/split-2.c execution test
-
-        FAIL: gcc.dg/split-5.c execution test
-
-    TODO.
-
-        xgcc: internal compiler error: Aborted (program cc1)
-        libbacktrace could not find executable to open
-        Please submit a full bug report, [...]
-        FAIL: largefile.c  -O0 -g -I. -Dwith_PCH (internal compiler error)
-        [...]
-
-    TODO.
-
-  * `g++`
-
-        spawn [open ...]
-        terminate called after throwing an instance of 'int'
-        FAIL: g++.dg/eh/sighandle.C -std=gnu++98 execution test
-
-        FAIL: g++.dg/eh/sighandle.C -std=gnu++11 execution test
-
-    TODO.
-
-        spawn [open ...]
-        FAIL: g++.dg/cdce3.C -std=gnu++98 execution test
-
-        FAIL: g++.dg/cdce3.C -std=gnu++11 execution test
-
-    TODO.
-
-        FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 execution test
-        FAIL: g++.dg/tls/thread_local3g.C -std=gnu++11 execution test
-        FAIL: g++.dg/tls/thread_local4.C -std=gnu++11 execution test
-        FAIL: g++.dg/tls/thread_local4g.C -std=gnu++11 execution test
-        FAIL: g++.dg/tls/thread_local5.C -std=gnu++11 execution test
-        FAIL: g++.dg/tls/thread_local5g.C -std=gnu++11 execution test
-
-    They used to PASS, but FAIL as of
-    769bf18a20ee2540ca7601cdafabd62b18b9751b..be3860ba8df48cca3253da4f02fd2d42d856ce80.
-    TODO.
-
-        -PASS: g++.dg/vect/pr36648.cc -std=c++98 execution test
-        -PASS: g++.dg/vect/pr36648.cc -std=c++11 execution test
-
-    On kepler.SCHWINGE, executables are generated (and run), on
-    coulomb.SCHWINGE only assembler code is generated.  TODO.  Likewise for
-    execution tests from `gcc.dg/vect` and `gfortran.dg/vect`.
-
-  * `gcc`, `g++`
-
-        FAIL: gcc.dg/cleanup-10.c execution test
-        FAIL: gcc.dg/cleanup-11.c execution test
-        FAIL: gcc.dg/cleanup-8.c execution test
-        FAIL: gcc.dg/cleanup-9.c execution test
-        FAIL: g++.dg/ext/cleanup-10.C -std=gnu++98 execution test
-        FAIL: g++.dg/ext/cleanup-10.C -std=gnu++11 execution test
-        FAIL: g++.dg/ext/cleanup-11.C -std=gnu++98 execution test
-        FAIL: g++.dg/ext/cleanup-11.C -std=gnu++11 execution test
-        FAIL: g++.dg/ext/cleanup-8.C -std=gnu++98 execution test
-        FAIL: g++.dg/ext/cleanup-8.C -std=gnu++11 execution test
-        FAIL: g++.dg/ext/cleanup-9.C -std=gnu++98 execution test
-        FAIL: g++.dg/ext/cleanup-9.C -std=gnu++11 execution test
-
-    TODO.
-
-        spawn [open ...]
-        gdb: took too long to attach
-        testcase [...]/gcc/testsuite/gcc.dg/guality/guality.exp completed in 16 seconds
-
-        spawn [open ...]
-        gdb: took too long to attach
-        testcase [...]/gcc/testsuite/g++.dg/guality/guality.exp completed in 20 seconds
-
-    TODO.  The gfortran ones worked fine.
-
-  * `[ARCH]/libgomp`
-
-    As of dcdba5abca23716daa6aeb5c92f367e0978e4539 (2013-05-27;
-    0479dc77cf50ee78769b55563051cf72d39b3d60 (2013-05-27)), plus
-    `id:"87txlnlg0z.fsf@kepler.schwinge.homeip.net"`, about a dozen of them
-    (but different ones per each run) FAIL on coulomb.SCHWINGE:
-
-        spawn [open ...]
-        
-        Program aborted. Backtrace:
-        #0  0x1042523
-        #1  0x1043D6F
-        #2  0x10F9BC7
-        FAIL: libgomp.fortran/lib1.f90  -O1  execution test
-
-    All have basically the same backtrace.  TODO.
-
-  * `[ARCH]/libjava`
-
-        spawn [open ...]
-        Exception in thread "main" java.io.IOException: Invalid argument
-           at gnu.java.nio.channels.FileChannelImpl.write(natFileChannelImpl.cc:202)
-           at java.io.FileOutputStream.write(libgcj.so.14)
-           at java.io.DataOutputStream.write(libgcj.so.14)
-           at java.io.RandomAccessFile.write(libgcj.so.14)
-           at LargeFile.main(LargeFile.exe)
-        FAIL: LargeFile execution - source compiled test
-        UNTESTED: LargeFile output - source compiled test
-
-        FAIL: LargeFile -findirect-dispatch execution - source compiled test
-        UNTESTED: LargeFile -findirect-dispatch output - source compiled test
-        FAIL: LargeFile -O3 execution - source compiled test
-        UNTESTED: LargeFile -O3 output - source compiled test
-        FAIL: LargeFile -O3 -findirect-dispatch execution - source compiled test
-        UNTESTED: LargeFile -O3 -findirect-dispatch output - source compiled test
-
-    TODO.
-
-        spawn [open ...]
-        1
-        FAIL: Throw_2 execution - source compiled test
-        UNTESTED: Throw_2 output - source compiled test
-
-        FAIL: Throw_2 -findirect-dispatch execution - source compiled test
-        UNTESTED: Throw_2 -findirect-dispatch output - source compiled test
-        FAIL: Throw_2 -O3 execution - source compiled test
-        UNTESTED: Throw_2 -O3 output - source compiled test
-        FAIL: Throw_2 -O3 -findirect-dispatch execution - source compiled test
-        UNTESTED: Throw_2 -O3 -findirect-dispatch output - source compiled test
-
-    TODO.
-
-  * `[ARCH]/libmudflap`
-
-        spawn [open ...]
-        FAIL: libmudflap.cth/pass37-frag.c (-O0) execution test
-        FAIL: libmudflap.cth/pass37-frag.c (-O0) output pattern test
-
-        FAIL: libmudflap.cth/pass37-frag.c (-O0) (rerun 1) execution test
-        FAIL: libmudflap.cth/pass37-frag.c (-O0) (rerun 1) output pattern test
-        [...]
-
-    TODO.  Seems like not just timeouts (though, reported before: [[!GCC_PR
-    20003]]).  If GDB is to believed, it seems like confusion between
-    libmudflap and glibc startup (while setting up the signal thread?):
-
-        #0  getenv (name=0x12dabee "LANGUAGE") at getenv.c:81
-        #1  0x011b2c78 in guess_category_value (categoryname=<optimized out>, category=<optimized out>) at dcigettext.c:1359
-        #2  __dcigettext (domainname=0x12dab1b <_libc_intl_domainname> "libc", msgid1=0x12e1cd8 "Error in unknown error system: ", msgid2=0x0, plural=0, n=0, category=5) at dcigettext.c:575
-        #3  0x011b1c53 in __dcgettext (domainname=0x12dab1b <_libc_intl_domainname> "libc", msgid=0x12e1cd8 "Error in unknown error system: ", category=5) at dcgettext.c:53
-        #4  0x01203728 in __strerror_r (errnum=-1, buf=0x15ff648 "", buflen=1024) at ../sysdeps/mach/_strerror.c:57
-        #5  0x011b0f30 in __assert_perror_fail (errnum=-1, file=0x1133969 "./pthread/cthreads-compat.c", line=45, function=0x1133985 <__PRETTY_FUNCTION__.5356> "cthread_fork") at assert-perr.c:62
-        #6  0x011324d4 in cthread_fork (func=0x118b0b0 <_hurd_msgport_receive>, arg=0x0) at ./pthread/cthreads-compat.c:45
-        #7  0x01192a96 in _hurdsig_init (intarray=0x102a000, intarraysize=5) at hurdsig.c:1499
-        #8  0x0117b9f8 in _hurd_new_proc_init (argv=0x15ffb88, intarray=0x102a000, intarraysize=5) at hurdinit.c:138
-        #9  0x0117bfef in _hurd_init (flags=8, argv=0x15ffb88, portarray=0x1029000, portarraysize=6, intarray=0x102a000, intarraysize=5) at hurdinit.c:94
-        #10 0x011a47c4 in init1 (argc=1, arg0=0x1025000 "/media/erich/home/thomas/tmp/gcc/hurd/master.build/i686-unknown-gnu0.3/libmudflap/testsuite/pass37-frag.exe") at ../sysdeps/mach/hurd/i386/init-first.c:136
-        #11 0x00001ec6 in _dl_start_user () from /lib/ld.so
-
-    pthread/cthreads-compat.c:
-
-            38  cthread_t
-            39  cthread_fork (cthread_fn_t func, void *arg)
-            40  {
-            41    pthread_t thread;
-            42    int err;
-            43
-            44    err = pthread_create (&thread, NULL, func, arg);
-            45    assert_perror (err);
-
-        Breakpoint 2, cthread_fork (func=0x118b0b0 <_hurd_msgport_receive>, arg=0x0) at ./pthread/cthreads-compat.c:44
-        44        err = pthread_create (&thread, NULL, func, arg);
-        (gdb) info threads 
-          Id   Target Id         Frame 
-        * 4    Thread 17597.16   cthread_fork (func=0x118b0b0 <_hurd_msgport_receive>, arg=0x0) at ./pthread/cthreads-compat.c:44
-        (gdb) s
-        40      {
-        (gdb) 
-        44        err = pthread_create (&thread, NULL, func, arg);
-        (gdb) 
-        
-        Breakpoint 1, pthread_create (thr=0x15ffa70, attr=0x0, start=0x118b0b0 <_hurd_msgport_receive>, arg=0x0) at ../../../master/libmudflap/mf-hooks3.c:272
-        272     {
-        (gdb) s
-        275       TRACE ("pthread_create\n");
-        (gdb) 
-        278       si = CALL_REAL (malloc, sizeof (*si));
-        (gdb) n
-        279       si->user_fn = start;
-        (gdb) 
-        283       return CALL_REAL (pthread_create, thr, attr, __mf_pthread_spawner, si);
-        (gdb) s
-        279       si->user_fn = start;
-        (gdb) 
-        280       si->user_arg = arg;
-        (gdb) 
-        283       return CALL_REAL (pthread_create, thr, attr, __mf_pthread_spawner, si);
-        (gdb) 
-        280       si->user_arg = arg;
-        (gdb) 
-        283       return CALL_REAL (pthread_create, thr, attr, __mf_pthread_spawner, si);
-        (gdb) 
-        __mf_0fn_pthread_create (thr=thr@entry=0x15ffa70, attr=attr@entry=0x0, start=start@entry=0x1041070 <__mf_pthread_spawner>, arg=arg@entry=0x108e520 <__mf_0fn_bufs+12288>) at ../../../master/libmudflap/mf-hooks3.c:265
-        265     }
-        (gdb) s
-        pthread_create (thr=0x15ffa70, attr=0x0, start=0x118b0b0 <_hurd_msgport_receive>, arg=0x0) at ../../../master/libmudflap/mf-hooks3.c:284
-        284     }
-        (gdb) s
-        cthread_fork (func=0x118b0b0 <_hurd_msgport_receive>, arg=0x0) at ./pthread/cthreads-compat.c:45
-        45        assert_perror (err);
-        (gdb) s
-        __assert_perror_fail (errnum=-1, file=0x1133969 "./pthread/cthreads-compat.c", line=45, function=0x1133985 <__PRETTY_FUNCTION__.5356> "cthread_fork") at assert-perr.c:55
-
-    Is this `libmudflap/mf-hooks3.c:__mf_0fn_pthread_create`, *a special
-    bootstrap variant*, that indeed just returns `-1`?
-
-  * `[ARCH]/libstdc++-v3`
-
-        FAIL: libstdc++-abi/abi_check
-
-    TODO.
-
-        $ readelf --symbols --wide i686-unknown-gnu0.3/./libstdc++-v3/src/.libs/libstdc++.so | grep pthread_mutex
-          1065: 00000000     0 FUNC    WEAK   DEFAULT  UND pthread_mutex_unlock@GLIBC_2.13_DEBIAN_31 (37)
-          2515: 00000000     0 FUNC    WEAK   DEFAULT  UND pthread_mutex_lock@GLIBC_2.13_DEBIAN_31 (37)
-          2978: 00068430    15 FUNC    GLOBAL DEFAULT   11 _ZNSt12__basic_fileIcEC2EP15__pthread_mutex@@GLIBCXX_3.4
-          3790: 00068430    15 FUNC    GLOBAL DEFAULT   11 _ZNSt12__basic_fileIcEC1EP15__pthread_mutex@@GLIBCXX_3.4
-          2085: 00000000     0 FUNC    WEAK   DEFAULT  UND pthread_mutex_unlock@@GLIBC_2.13_DEBIAN_31
-          3535: 00000000     0 FUNC    WEAK   DEFAULT  UND pthread_mutex_lock@@GLIBC_2.13_DEBIAN_31
-          3998: 00068430    15 FUNC    GLOBAL DEFAULT   11 _ZNSt12__basic_fileIcEC2EP15__pthread_mutex
-          4810: 00068430    15 FUNC    GLOBAL DEFAULT   11 _ZNSt12__basic_fileIcEC1EP15__pthread_mutex
-
-    `_ZNSt12__basic_fileIcEC1EP15__pthread_mutex`
-    (`std::__basic_file<char>::__basic_file(__pthread_mutex*)`), but
-    `_ZNSt12__basic_fileIcEC2EP15pthread_mutex_t`
-    (`std::__basic_file<char>::__basic_file(pthread_mutex_t*)`) is expected.
-
-        FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
-        FAIL: 27_io/basic_filebuf/close/char/4879.cc execution test
-        FAIL: 27_io/basic_filebuf/close/char/9964.cc execution test
-        FAIL: 27_io/basic_filebuf/imbue/char/13171-2.cc execution test
-        FAIL: 27_io/basic_filebuf/imbue/wchar_t/14975-2.cc execution test
-        WARNING: program timed out.
-        FAIL: 27_io/basic_filebuf/open/char/9507.cc execution test
-        FAIL: 27_io/basic_filebuf/seekoff/char/26777.cc execution test
-        WARNING: program timed out.
-        FAIL: 27_io/basic_filebuf/showmanyc/char/9533-1.cc execution test
-        FAIL: 27_io/basic_filebuf/underflow/char/10097.cc execution test
-        FAIL: 27_io/objects/char/7.cc execution test
-        FAIL: 27_io/objects/char/9661-1.cc execution test
-        FAIL: 27_io/objects/wchar_t/7.cc execution test
-        FAIL: 27_io/objects/wchar_t/9661-1.cc execution test
-        FAIL: 30_threads/async/42819.cc execution test
-        FAIL: 30_threads/async/49668.cc execution test
-        FAIL: 30_threads/async/54297.cc execution test
-        FAIL: 30_threads/async/any.cc execution test
-        FAIL: 30_threads/async/async.cc execution test
-        FAIL: 30_threads/async/sync.cc execution test
-        FAIL: 30_threads/call_once/39909.cc execution test
-        FAIL: 30_threads/call_once/49668.cc execution test
-        FAIL: 30_threads/call_once/call_once1.cc execution test
-        FAIL: 30_threads/condition_variable/54185.cc execution test
-        FAIL: 30_threads/condition_variable_any/50862.cc execution test
-        FAIL: 30_threads/condition_variable_any/53830.cc execution test
-        FAIL: 30_threads/future/members/45133.cc execution test
-        FAIL: 30_threads/future/members/get.cc execution test
-        FAIL: 30_threads/future/members/get2.cc execution test
-        FAIL: 30_threads/future/members/share.cc execution test
-        FAIL: 30_threads/future/members/valid.cc execution test
-        FAIL: 30_threads/future/members/wait.cc execution test
-        FAIL: 30_threads/future/members/wait_for.cc execution test
-        FAIL: 30_threads/future/members/wait_until.cc execution test
-        FAIL: 30_threads/lock/2.cc execution test
-        FAIL: 30_threads/lock/4.cc execution test
-        FAIL: 30_threads/mutex/try_lock/2.cc execution test
-        FAIL: 30_threads/packaged_task/49668.cc execution test
-        FAIL: 30_threads/packaged_task/cons/3.cc execution test
-        FAIL: 30_threads/packaged_task/cons/alloc.cc execution test
-        FAIL: 30_threads/packaged_task/members/get_future.cc execution test
-        FAIL: 30_threads/packaged_task/members/invoke.cc execution test
-        FAIL: 30_threads/packaged_task/members/invoke2.cc execution test
-        FAIL: 30_threads/packaged_task/members/invoke3.cc execution test
-        FAIL: 30_threads/packaged_task/members/invoke4.cc execution test
-        FAIL: 30_threads/packaged_task/members/invoke5.cc execution test
-        FAIL: 30_threads/packaged_task/members/reset2.cc execution test
-        FAIL: 30_threads/promise/cons/alloc.cc execution test
-        FAIL: 30_threads/promise/cons/move.cc execution test
-        FAIL: 30_threads/promise/cons/move_assign.cc execution test
-        FAIL: 30_threads/promise/members/get_future.cc execution test
-        FAIL: 30_threads/promise/members/set_exception.cc execution test
-        FAIL: 30_threads/promise/members/set_exception2.cc execution test
-        FAIL: 30_threads/promise/members/set_value.cc execution test
-        FAIL: 30_threads/promise/members/set_value2.cc execution test
-        FAIL: 30_threads/promise/members/set_value3.cc execution test
-        FAIL: 30_threads/promise/members/swap.cc execution test
-        FAIL: 30_threads/shared_future/members/get.cc execution test
-        FAIL: 30_threads/shared_future/members/get2.cc execution test
-        FAIL: 30_threads/shared_future/members/valid.cc execution test
-        FAIL: 30_threads/shared_future/members/wait.cc execution test
-        FAIL: 30_threads/shared_future/members/wait_for.cc execution test
-        FAIL: 30_threads/shared_future/members/wait_until.cc execution test
-        FAIL: 30_threads/this_thread/3.cc execution test
-        FAIL: 30_threads/this_thread/4.cc execution test
-        FAIL: 30_threads/thread/cons/2.cc execution test
-        FAIL: 30_threads/thread/cons/3.cc execution test
-        FAIL: 30_threads/thread/cons/4.cc execution test
-        FAIL: 30_threads/thread/cons/49668.cc execution test
-        FAIL: 30_threads/thread/cons/5.cc execution test
-        FAIL: 30_threads/thread/cons/6.cc execution test
-        FAIL: 30_threads/thread/cons/7.cc execution test
-        FAIL: 30_threads/thread/cons/8.cc execution test
-        FAIL: 30_threads/thread/cons/9.cc execution test
-        FAIL: 30_threads/thread/cons/moveable.cc execution test
-        FAIL: 30_threads/thread/members/1.cc execution test
-        FAIL: 30_threads/thread/members/2.cc execution test
-        FAIL: 30_threads/thread/members/3.cc execution test
-        FAIL: 30_threads/thread/native_handle/cancel.cc execution test
-        FAIL: 30_threads/thread/swap/1.cc execution test
-        FAIL: 30_threads/timed_mutex/try_lock/2.cc execution test
-        FAIL: 30_threads/timed_mutex/try_lock_for/3.cc execution test
-        FAIL: 30_threads/timed_mutex/try_lock_until/2.cc execution test
-        FAIL: 30_threads/try_lock/2.cc execution test
-        FAIL: 30_threads/try_lock/4.cc execution test
-
-    TODO.  Perhaps just timeouts?  [[!message-id
-    "200609052027.NAA09861@hpsje.cup.hp.com"]].  [[!message-id
-    "1227217275.6205.6.camel@janis-laptop"]].  If needed, can re-implement in
-    GCC DejaGnu's `remote.exp:remote_wait` to get rid of (that is, ignore) its
-    `timeout` parameter which, in DejaGnu code, is often invoked with a
-    hard-coded value (that we may want to override) (or is that what
-    `gcc/testsuite/lib/timeout.exp:standard_wait` is for?).  While at it,
-    `libmudflap/testsuite/libmudflap.c++/ctors.exp` and
-    `libmudflap/testsuite/libmudflap.c/externs.exp` use hard-coded timeout
-    values in `remote_wait` calls (also, why don't these use the usual way of
-    running tests?).
-
-  * What is `gcc/testsuite/gcc.test-framework/test-framework.exp` and should we
-    define `CHECK_TEST_FRAMEWORK` to run these tests?
-
-
-## Enhancements
-
-
-### `contrib/testsuite-management/`, `contrib/regression/`
-
-  * 35a27ee8c4b349fea44fd1fadc9614ab3cc9d578 `Add an xfail manifest for
-    x86_64-unknown-linux-gnu to trunk.`
-
-
-### Parallel Testing
-
-[[!message-id "20110331070322.GI11563@sunsite.ms.mff.cuni.cz"]].
-
-
-### Distributed Testing
-
-
-#### IRC, OFTC, #gcc, 2012-05-31
-
-    <dnovillo> jsm28: in your mentor testing, you have the source and build
-      tree available for make check?  or it's a pure installed-tree test?
-    <jsm28> dnovillo: Source tree, install tree, no build tree.
-    <dnovillo> jsm28: so, you run make check on top of the source tree or copy
-      the */testsuite trees to a testing area?
-    <jsm28> Create a site.exp and do runtest in a temporary directory.  runtest
-      is pointed to the source tree to find sources.
-    <jsm28> For cross testing for GNU/Linux targets, the temporary directory is
-      mounted at the same path on host and target.
-    <dnovillo> jsm28: thanks.  i guess i'll have to find the slice of the
-      source tree i need to copy.
-    <dnovillo> jsm28: for libstdc++ do you write a different site.exp? 
-    <dnovillo> i noticed that it generates a different site,exp there.
-    <jsm28> The site.exp is mostly the same for all testsuites (so includes
-      settings that only some testsuites use).
-    <dnovillo> ok, thanks.
-    <dnovillo> and when you say "pointed to the source tree" you mean "set
-      srcdir /path/to/top/of/gcc" ?
-    <dnovillo> (in site.exp)
-    <jsm28> The GDB testsuite requires that you run the GDB testsuite's
-      configure script in the temporary directory where you will run runtest.
-      I don't think any GCC testsuites we use have requirements like that.
-    <jsm28> dnovillo: --srcdir option to runtest.
-    <dnovillo> ah, yes.
-    <jsm28> (and --tool, --target_board etc.)
-    <dnovillo> right
-    <dnovillo> since i'm distributing the tests. i want each node to only do a
-      bunch of files.  this means that i either use 'tool.exp=file-pattern' or
-      simply copy the subset of files i want tool.exp to find.
-    <dnovillo> i chose the second approach, but that breaks in a handful of
-      cases that need files from other sub-directories.
-    <dnovillo> like g++.dg gcc.dg using stuff from c-c++-common.
-    <dnovillo> for libstdc++, the possibilities for splitting are enormous as
-      it has many directories.
-    <dnovillo> but i'm not setting it right.  runtest runs without even trying
-      to test anything.
-    <dnovillo> i'm not having it pick up the right driver.
-    <jsm28> Probably all .exp files should be copied to anywhere running
-      testsuites, since some read .exp files from other directories.
-    <dnovillo> jsm28: that could be it too.  it's irritating that libstdc++
-      does not even error out.  runtest just does nothing and returns 0.
-
-##### IRC, OFTC, #gcc, 2012-06-06
-
-    <dnovillo> any libstdc++ maintainer around?
-    <dnovillo> or, does anyone know when the testsuite/data files are copied
-      into the running testsuite/ dir?
-    <dnovillo> seems to be done in advance by make.
-
-##### [[!message-id "4FC7791E.6040407@gmail.com"]]
diff --git a/open_issues/gcc/libmudflap.mdwn b/open_issues/gcc/libmudflap.mdwn
deleted file mode 100644
index f14ca1bc..00000000
--- a/open_issues/gcc/libmudflap.mdwn
+++ /dev/null
@@ -1,74 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2009 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_porting open_issue_gcc]]
-
-Single-threaded use appears to work:
-
-    $ echo 'int main(void) { int *a; a[10]=0; return a[5]; }' | ↩
-      gcc -o a -fmudflap -x c - -lmudflap
-    $ ./a
-    *******
-    mudflap violation 1 (check/write): time=1227208721.922064 ptr=0x1023de0 size=4
-    pc=0x1037a33 location=`<stdin>:1:26 (main)'
-          /usr/lib/libmudflap.so.0(__mf_check+0x33) [0x1037a33]
-          ./a(main+0x7c) [0x80486c4]
-          /usr/lib/libmudflap.so.0(__wrap_main+0x49) [0x1037239]
-    Nearby object 1: checked region begins 68B before and ends 65B before
-    mudflap object 0x80ca268: name=`argv[]'
-    bounds=[0x1023e24,0x1023e2b] size=8 area=static check=0r/0w liveness=0
-    alloc time=1227208721.922064 pc=0x10371d3
-    Nearby object 2: checked region begins 76B before and ends 73B before
-    mudflap object 0x80cb448: name=`environ[]'
-    bounds=[0x1023e2c,0x1023ed7] size=172 area=static check=0r/0w liveness=0
-    alloc time=1227208721.922064 pc=0x10371d3
-    number of nearby objects: 2
-    *******
-    mudflap violation 2 (check/read): time=1227208721.942109 ptr=0x1023dcc size=4
-    pc=0x1037a33 location=`<stdin>:1:35 (main)'
-          /usr/lib/libmudflap.so.0(__mf_check+0x33) [0x1037a33]
-          ./a(main+0xf3) [0x804873b]
-          /usr/lib/libmudflap.so.0(__wrap_main+0x49) [0x1037239]
-    Nearby object 1: checked region begins 88B before and ends 85B before
-    mudflap object 0x80ca268: name=`argv[]'
-    Nearby object 2: checked region begins 96B before and ends 93B before
-    mudflap object 0x80cb448: name=`environ[]'
-    number of nearby objects: 2
-
-Multi-threaded use doesn't:
-
-    $ echo 'int main(void) { int *a; a[10]=0; return a[5]; }' | ↩
-      gcc -include pthread.h -o a -fmudflapth -x c - -lmudflapth -lpthread
-    $ ./a 
-    Killed
-    $ gdb a
-    [...]
-    Starting program: /media/data/home/tschwinge/a 
-    
-    Program received signal EXC_BAD_ACCESS, Could not access memory.
-    0x01180653 in getenv () from /lib/libc.so.0.3
-    (gdb) bt
-    #0  0x01180653 in getenv () from /lib/libc.so.0.3
-    #1  0x01177a02 in __dcigettext () from /lib/libc.so.0.3
-    #2  0x01176a57 in dcgettext () from /lib/libc.so.0.3
-    #3  0x011c03b5 in strerror_r () from /lib/libc.so.0.3
-    #4  0x01175b57 in __assert_perror_fail () from /lib/libc.so.0.3
-    #5  0x0111f1ad in cthread_fork (func=0x114f630 <_hurd_msgport_receive>, arg=0x0)
-        at /build/buildd/hurd-20080607/build-tree/hurd/libpthread/pthread/cthreads-compat.c:41
-    #6  0x0115713e in _hurdsig_init () from /lib/libc.so.0.3
-    #7  0x01140852 in _hurd_proc_init@@GLIBC_2.2.6 () from /lib/libc.so.0.3
-    #8  0x01140e86 in _hurd_init () from /lib/libc.so.0.3
-    #9  0x011690ce in init1 () from /lib/libc.so.0.3
-    #10 0x00001e96 in _dl_start_user () from /lib/ld.so
-    #11 0x00000001 in ?? ()
-    #12 0x01024000 in ?? ()
-    #13 0x00000000 in ?? ()
-
-Also `libmudflap` is pthread-only.
diff --git a/open_issues/gcc/pie.mdwn b/open_issues/gcc/pie.mdwn
deleted file mode 100644
index 5ae4bdcb..00000000
--- a/open_issues/gcc/pie.mdwn
+++ /dev/null
@@ -1,51 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 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]]."]]"""]]
-
-[[!meta title="Position-Independent Executables"]]
-
-[[!tag open_issue_glibc]]
-
-
-# IRC, freenode, #hurd, 2012-11-08
-
-    <pinotree> tschwinge: i'm not totally sure, but it seems the pie options
-      for gcc/ld are causing issues
-    <pinotree> namely, producing executables that sigsegv straight away
-    <tschwinge> pinotree: OK, I do remember some issues about these, too.
-    <tschwinge> Also for -pg.
-    <tschwinge> These have in common that they use different crt*.o files for
-      linking.
-    <tschwinge> Might well be there's some bugs there.
-    <pinotree> one way is to try the w3m debian build: the current build
-      configuration enables also pie, which in turns makes an helper executable
-      (mktable) sigsegv when invoked
-    <pinotree> if «,-pie» is appended to the DEB_BUILD_MAINT_OPTIONS variable
-      in debian/rules, pie is not added and the resulting mktable runs
-      correctly
-
-
-## IRC, OFTC, #debian-hurd, 2012-11-09
-
-    <pinotree> youpi: ah, as i noted to tschwinge earlier, it seems -fPIE -pie
-      miscompile stuff
-    <youpi> uh
-    <pinotree> this causes the w3m build failure and (indirectly, due to elinks
-      built with -pie) aptitude
-
-
-## IRC, freenode, #hurd, 2013-01-19
-
-    <gnu_srs> pinotree: I can confirm that -fPIE -pie fails and only -fPIE
-      works for mktable in w3m. Still have to check with elinks. What's up doc?
-
-
-## [[!message-id "20130211040854.GN5926@type.youpi.perso.aquilenet.fr"]]
-
-[[glibc]] `t/pie-sbrk` branch.
diff --git a/open_issues/gccgo.mdwn b/open_issues/gccgo.mdwn
deleted file mode 100644
index 0b90ac75..00000000
--- a/open_issues/gccgo.mdwn
+++ /dev/null
@@ -1,149 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2013 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]]."]]"""]]
-
-[[!meta title="Enable Google Go programming (GCC: gccgo)"]]
-
-[[!tag open_issue_gcc]]
-
-Make the [Google Go programming language](http://golang.org/) available on
-GNU/Hurd in its [[GCC]] *gccgo* implementation, and enable Hurd-specific
-features.
-
-There is a [[!FF_project 263]][[!tag bounty]] on this task.
-
----
-
-
-# Part I
-
-First, make the language functional, have its test suite pass without errors.
-
-
-## Original [[community/GSoC]] Task Description
-
-[[!inline pages=community/gsoc/project_ideas/gccgo feeds=no]]
-
-
-## `tschwinge/t/hurd/go`
-
-There is now a `tschwinge/t/hurd/go` branch in GCC's Git repository, where the
-Hurd port for Go is being polished.
-
-
-## `getcontext`/`makecontext`/`setcontext`/`swapcontext` usage analysis
-
-In context of [[glibc/t/tls-threadvar]].  Looking at GCC trunk commit
-f6568ea476aa52a6e23c6db43b3e240cde55783a (2013-04-26).
-
-The check in `libgo/configure.ac` *whether setcontext clobbers TLS variables*
-is invalid on GNU Hurd.
-
-The `*context` functions are used in `libgo/runtime/go-signal.c` and
-`libgo/runtime/proc.c`.
-
-`__splitstack_getcontext`, `__splitstack_setcontext`,
-`__splitstack_makecontext`, `__splitstack_resetcontext`,
-`__splitstack_block_signals_context` are to be provided by libgcc.  However, in
-said libgo runtime files, they're used only `#ifdef USING_SPLIT_STACK`.
-[[I|tschwinge]] would assume that before we can enable split stacks, first
-[[open_issues/glibc/t/tls-threadvar]] needs to be fixed.
-
-In `libgo/runtime/proc.c`:`runtime_gogo`, `setcontext` is used to *switch
-context to a different goroutine*.  TODO.
-
-In `libgo/runtime/proc.c`:`runtime_mcall`, which *save[s] context and call[s]
-fn passing g as a parameter*, `getcontext` and `setcontext` are used; this is
-only called from `libgo/runtime/proc.c`:`runtime_gosched`.  TODO.
-
-In `libgo/runtime/proc.c`:`runtime_tracebackothers`, `getcontext` is used to
-*switch context to the goroutine*.  TODO.
-
-In `libgo/runtime/proc.c`:`runtime_mstart`, which is *called to start an M*,
-`getcontext` is used.  TODO.
-
-In `libgo/runtime/proc.c`:`runtime_entersyscall`, which is called when *the
-goroutine g is about to enter a system call*, `getcontext` is used to *save the
-registers in the g structure so that any pointers held in registers will be
-seen by the garbage collector*.  Should be fine.
-
-In `libgo/runtime/proc.c`:`__go_go`, `getcontext` and `makecontext` are used.
-TODO.
-
-In `libgo/runtime/thread.c`:`runtime_minit`, which is *[c]alled to initialize a
-new m (including the bootstrap m)*, `ss.ss_sp` is set to a new stack retrieved
-via `libgo/runtime/proc.c:runtime_malg`, which *allocate[s] a new g, with a
-stack [...]*, and then `sigaltstack` is called.  TODO.
-
-    libgo/runtime/go-signal.c:  /* We are now running on the stack registered via sigaltstack.
-    libgo/runtime/go-signal.c:     and sigaltstack when the program starts.)  */
-    
-    libgo/runtime/proc.c:         vnewg->context.uc_stack.ss_sp = vsp;
-    libgo/runtime/proc.c:         vnewg->context.uc_stack.ss_sp += vspsize;
-    libgo/runtime/proc.c:         vnewg->context.uc_stack.ss_size = vspsize;
-
-Also, in `libgo/runtime/proc.c`:`runtime_newm`, `pthread_attr_setstacksize` is
-used, which we also can't support yet, for the same reason.
-
-
-========================
-
-**gccgo manages to get compiled and pass a fair amount of its tests, however its library is failing all but one of its tests.**
-
-Following are the results of the passing suite between the libgo tests run on linux (x86) and the Hurd:
-
-# the Hurd:
-
-    Test Run By root on Fri Jul 12 17:56:44 UTC 2013
-    Native configuration is i686-unknown-gnu0.3
-
-		    === libgo tests ===
-
-    Schedule of variations:
-        unix
-
-    ...
-
-		    === libgo Summary ===
-
-    # of expected passes		1
-    # of unexpected failures	130
-    /root/gcc_new/gccbuild/./gcc/gccgo version 4.9.0 20130606 (experimental) (GCC)
-
-# Linux results:
-
-    Test Run By fotis on Τρι 02 Ιούλ 2013 09:20:20 μμ EEST
-    Native configuration is i686-pc-linux-gnu
-
-		    === libgo tests ===
-
-    Schedule of variations:
-        unix
-
-    ...
-
-		    === libgo Summary ===
-
-    # of expected passes		131
-    /home/fotis/Software/gcc_build/./gcc/gccgo version 4.9.0 20130702 (experimental) (GCC)
-
-
----
-
-
-# Part II
-
-Next, Hurd-specific features can be added.  Add an interface to the
-language/environment for being able to do [[RPC]] calls, in order to program
-[[hurd/translator]]s natively in the Google Go programming language.
-
-
-## Original [[community/GSoC]] Task Description
-
-[[!inline pages=community/gsoc/project_ideas/language_bindings feeds=no]]
diff --git a/open_issues/gdb-heap.mdwn b/open_issues/gdb-heap.mdwn
deleted file mode 100644
index 75c31bbe..00000000
--- a/open_issues/gdb-heap.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_gdb]]
-
-Might be interesting to have a look at
-[*gdb-heap*](https://fedorahosted.org/gdb-heap/) with respect to our
-long-lived [[hurd/translator]] processes.
diff --git a/open_issues/gdb.mdwn b/open_issues/gdb.mdwn
deleted file mode 100644
index 9d82d728..00000000
--- a/open_issues/gdb.mdwn
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!meta copyright="Copyright © 2007, 2008, 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]]."]]"""]]
-
-[[!meta redir=binutils]]
diff --git a/open_issues/gdb/gdbserver.mdwn b/open_issues/gdb/gdbserver.mdwn
deleted file mode 100644
index fe239bbc..00000000
--- a/open_issues/gdb/gdbserver.mdwn
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!meta copyright="Copyright © 2012 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_gdb]]
-
-Needs porting.  Can probably use/share most code from GDB proper.
-
-# Miscellaneous Issues
-
-  * ``m addr,length'`
-
-    What is `errno`?  Is is *the* `errno`?  If yes, of the system GDB is
-    running on, or the system gdbserver is running on?  Clarify documentation.
diff --git a/open_issues/gdb_attach.mdwn b/open_issues/gdb_attach.mdwn
deleted file mode 100644
index b9114b69..00000000
--- a/open_issues/gdb_attach.mdwn
+++ /dev/null
@@ -1,83 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 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]]."]]"""]]
-
-[[!meta title="GDB: attach"]]
-
-[[!tag open_issue_gdb]]
-
-
-# [[gdb_thread_ids]]
-
-
-# IRC, freenode, #hurd, 2012-06-30
-
-    <braunr> hm, gdb isn't able to determine which thread is running when
-      attaching to a process
-
-
-# IRC, freenode, #hurd, 2012-07-02
-
-    <braunr> woah, now that's a weird message !
-    <braunr> when using gdb on a hanged ext2fs :
-    <braunr> Pid 938 has an additional task suspend count of 1; clear it? (y or
-      n) 
-    <braunr> when hanged, gdb thinks the target task is already being debugged
-      :/
-    <braunr> no wonder why it's completely stuck
-    <braunr> hm, the task_suspend might actually be the crash-dump-core server
-      attempting to create the core :/
-    <braunr> hm interesting, looks like a problem with the
-      diskfs_catch_exception macro
-    <pinotree> braunr: what's up with it?
-    <braunr> pinotree: it uses setjmp
-    <braunr> hm random corruptions :/
-    <braunr> definitely looks like a concurrency problem
-
-
-# IRC, freenode, #hurd, 2012-05-23
-
-    <pinotree>
-      /build/buildd-gdb_7.4really-1-hurd-i386-UKStgK/gdb-7.4really/gdb/thread.c:72:
-      internal-error: inferior_thread: Assertion `tp' failed.
-    <pinotree> arg
-    <tschwinge> pinotree: Been doing anything "special"?   Is it reproducible? 
-    <pinotree> trying to debug something
-    <tschwinge> Indeed.  ;-)
-    <pinotree> i'm not sure i'm doing anything special, just trying to attach a
-      process
-    <tschwinge> That is supposed to work.
-    <tschwinge> If the permission match.
-
-
-# `gdb --pid [PID]`
-
-That is, not explicitly specifying an `executable-file`.
-
-
-## IRC, OFTC, debian-hurd, 2013-04-15
-
-    <paravoid> I don't seem to be able to run gdb
-    <paravoid> that happened on the buildd and happens on exodar too
-    <paravoid> #0  0x010c07cc in ?? ()
-    <paravoid> #1  0x010c1078 in ?? ()
-    <paravoid> #2  0x0109eabf in ?? ()
-    <paravoid> [...]
-    <paravoid> Backtrace stopped: previous frame inner to this frame (corrupt
-      stack?)
-    <paravoid> that's pid 24235 on exodar
-    <paravoid> I did gdb -p 24235 and then bt
-    <paravoid> just the output above
-    <youpi> I don't know about gdb -p
-    <youpi> I usually run gdb
-      /home/paravoid/gdnsd-1.8.1/plugins/meta/libgdmaps/t/.libs/lt-t17_extn_empty.bin
-      24235
-    <paravoid> okay, that indeed works 
-    <youpi> I guess the support for finding out the binary automatically wasn't
-      done yet on hurd
diff --git a/open_issues/gdb_catch_syscall.mdwn b/open_issues/gdb_catch_syscall.mdwn
deleted file mode 100644
index a875b211..00000000
--- a/open_issues/gdb_catch_syscall.mdwn
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!meta copyright="Copyright © 2011, 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]]."]]"""]]
-
-[[!meta title="GDB: catch syscall"]]
-
-    (gdb) catch syscall 
-    The feature 'catch syscall' is not supported on this architeture yet.
-
-[[!tag open_issue_gdb]]
-
-Perhaps can ``marry'' that one with [[hurd/debugging/rpctrace]]?
diff --git a/open_issues/gdb_gcore.mdwn b/open_issues/gdb_gcore.mdwn
deleted file mode 100644
index cadd9be1..00000000
--- a/open_issues/gdb_gcore.mdwn
+++ /dev/null
@@ -1,30 +0,0 @@
-[[!meta copyright="Copyright © 2009, 2011, 2013 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]]."]]"""]]
-
-[[!meta title="GDB: gcore"]]
-
-[[!tag open_issue_gdb]]
-
-GDB's `gcore` command doesn't work / needs to be implemented / ported in GDB:
-
-    tschwinge@flubber:~ $ gcore 8371
-    [New Thread 8371.1]
-    [New Thread 8371.2]
-    [New Thread 8371.3]
-    /media/data/home/tschwinge/core.cA0ICY:2: Error in sourced command file:
-    Undefined command: "gcore".  Try "help".
-    gcore: failed to create core.8371
-
-Will probably need to implement `gdb/gdbarch.sh:gdb_signal_from_target`,
-`gdb/gdbarch.sh:gdb_signal_to_target`.
-
-If someone is working in this area, they may want to port
-<http://code.google.com/p/google-coredumper/>, too.
diff --git a/open_issues/gdb_non-stop_mode.mdwn b/open_issues/gdb_non-stop_mode.mdwn
deleted file mode 100644
index adaff102..00000000
--- a/open_issues/gdb_non-stop_mode.mdwn
+++ /dev/null
@@ -1,26 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2009, 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]]."]]"""]]
-
-[[!meta title="GDB's non-stop mode"]]
-
-[[!tag open_issue_gdb]]
-
-GNU GDB's `gnu-nat.c` doesn't support *non-stop* mode.
-
-Also, from [[!message-id "200810131935.35253.pedro@codesourcery.com"]],
-GNU GDB's Pedro Alves:
-
-> I also notice that when going through the shell in non-stop mode, it would be
-> more correct to resume all threads --- we don't want non-stop and its
-> scheduler-locking to apply to the shell.  Basically, non-stop should be off
-> if there are pending execs.  This was an existing issue, and doesn't affect
-> linux today, so I'll just ignore that for now, as it needs more tweaking to
-> fix.
diff --git a/open_issues/gdb_noninvasive_mode_new_threads.mdwn b/open_issues/gdb_noninvasive_mode_new_threads.mdwn
deleted file mode 100644
index 9b3992f4..00000000
--- a/open_issues/gdb_noninvasive_mode_new_threads.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!meta copyright="Copyright © 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_gdb]]
-
-Debugging a translator.  `gdb binary`.  `set noninvasive on`.  `attach [PID]`.
-Translator does some work.  GDB doesn't notice new threads.  `detach`.  `attach
-[PID]` -- now new threads are visible.
diff --git a/open_issues/gdb_pending_execs.mdwn b/open_issues/gdb_pending_execs.mdwn
deleted file mode 100644
index 37a92cb7..00000000
--- a/open_issues/gdb_pending_execs.mdwn
+++ /dev/null
@@ -1,30 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2009, 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]]."]]"""]]
-
-[[!meta title="GDB: pending_execs"]]
-
-[[!tag open_issue_gdb]]
-
-[[!message-id "200810131935.35253.pedro@codesourcery.com"]]
-
-GNU GDB's Ulrich Weigand:
-
-> Hmm.  It would appear that "set exec-wrapper" is currently broken with
-> the gnu-nat.c target, right?
-
-GNU GDB's Pedro Alves:
-
->> Yeah, it appears so.  Don't know if it's possible to get rid of the local
->> pending execs handling in gnu-nat.c.  An alternative would be to make
->> pending_execs a property of inferior.h:`struct inferior' instead of of
->> gnu-nat.c:`struct inf'.
-
-[[!message-id "8738kyi30l.fsf@kepler.schwinge.homeip.net"]]
diff --git a/open_issues/gdb_signal_handler.mdwn b/open_issues/gdb_signal_handler.mdwn
deleted file mode 100644
index 5e27a099..00000000
--- a/open_issues/gdb_signal_handler.mdwn
+++ /dev/null
@@ -1,474 +0,0 @@
-[[!meta copyright="Copyright © 2013 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_gdb open_issue_glibc]]
-
-
-# IRC, freenode, #hurd, 2013-07-07
-
-    <zyg> Hi, I'm in GDB inside a handler for SIGHUP, after stepping out, gdb
-      will hang on instruction: <_hurd_sigstate_lock+88>:  xchg
-      %edx,0x4(%eax)
-    <zyg> here is my signal test pasted: http://pastebin.com/U72qw3FC
-        #include <stdio.h>
-        #include <stdlib.h>
-        #include <signal.h>
-         
-        void *
-        my_handler(int signal, void *info, void *context)
-        {
-          printf("got SIGHUP\n");
-          return NULL;
-        }
-         
-        void
-        install_handler (int signal)
-        {
-          struct sigaction sa;
-          sa.sa_sigaction = my_handler;
-          sa.sa_flags = SA_SIGINFO;
-          sigemptyset(&sa.sa_mask);
-          sigaction(signal, &sa, NULL);
-        }
-         
-        void test_sighup(void)
-        {
-          raise(SIGHUP);
-        }
-         
-        int main(int argc, char **argv){
-          install_handler(SIGHUP);
-          test_sighup();
-          exit(1);
-        }
-    <braunr> zyg: thanks
-    <braunr> zyg: what is the problem exactly ?
-    <braunr> zyg: i mean, does it hand before attaching with gdb ?
-    <zyg> braunr: it doesn't hang if runned without gdb. I've pasted here when
-      I step out of the handler, and get to the hanging instruction:
-      http://pastebin.com/nUyCx6Wj
-        $ gdb --args a.out
-        GNU gdb (GDB) 7.6-debian
-        Copyright (C) 2013 Free Software Foundation, Inc.
-        License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
-        This is free software: you are free to change and redistribute it.
-        There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
-        and "show warranty" for details.
-        This GDB was configured as "i486-gnu".
-        For bug reporting instructions, please see:
-        <http://www.gnu.org/software/gdb/bugs/>...
-        Reading symbols from /home/shrek/a.out...(no debugging symbols found)...done.
-        (gdb)
-         
-        (gdb) display/i $pc
-        (gdb) handle SIGHUP pass stop print
-        Signal        Stop      Print   Pass to program Description
-        SIGHUP        Yes       Yes     Yes             Hangup
-        (gdb)
-         
-        (gdb) run
-        Starting program: /home/shrek/a.out
-        [New Thread 3571.5]
-         
-        Program received signal SIGHUP, Hangup.
-        0x010548ec in mach_msg_trap ()
-            at /build/buildd-eglibc_2.17-6-hurd-i386-g946kE/eglibc-2.17/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-        2       /build/buildd-eglibc_2.17-6-hurd-i386-g946kE/eglibc-2.17/build-tree/hurd-i386-libc/mach/mach_msg_trap.S: No such file or directory.
-        1: x/i $pc
-        => 0x10548ec <mach_msg_trap+12>:        ret
-        (gdb)
-         
-        (gdb) si
-        0x0804862d in my_handler ()
-        1: x/i $pc
-        => 0x804862d <my_handler>:      push   %ebp
-        (gdb) x/20xi 0x804862d
-        => 0x804862d <my_handler>:      push   %ebp
-           0x804862e <my_handler+1>:    mov    %esp,%ebp
-           0x8048630 <my_handler+3>:    sub    $0x18,%esp
-           0x8048633 <my_handler+6>:    movl   $0x8048750,(%esp)
-           0x804863a <my_handler+13>:   call   0x8048500 <puts@plt>
-           0x804863f <my_handler+18>:   mov    $0x0,%eax
-           0x8048644 <my_handler+23>:   leave
-           0x8048645 <my_handler+24>:   ret
-           0x8048646 <install_handler>: push   %ebp
-           0x8048647 <install_handler+1>:       mov    %esp,%ebp
-           0x8048649 <install_handler+3>:       sub    $0x28,%esp
-           0x804864c <install_handler+6>:       movl   $0x804862d,-0x14(%ebp)
-           0x8048653 <install_handler+13>:      movl   $0x40,-0xc(%ebp)
-           0x804865a <install_handler+20>:      lea    -0x14(%ebp),%eax
-           0x804865d <install_handler+23>:      add    $0x4,%eax
-           0x8048660 <install_handler+26>:      mov    %eax,(%esp)
-           0x8048663 <install_handler+29>:      call   0x80484d0 <sigemptyset@plt>
-           0x8048668 <install_handler+34>:      movl   $0x0,0x8(%esp)
-           0x8048670 <install_handler+42>:      lea    -0x14(%ebp),%eax
-           0x8048673 <install_handler+45>:      mov    %eax,0x4(%esp)
-        (gdb)
-         
-        (gdb) break *0x804863f
-        Breakpoint 1 at 0x804863f
-        (gdb) c
-        Continuing.
-        got SIGHUP
-         
-        Breakpoint 1, 0x0804863f in my_handler ()
-        1: x/i $pc
-        => 0x804863f <my_handler+18>:   mov    $0x0,%eax
-        (gdb)
-         
-        (gdb) si
-        0x08048644 in my_handler ()
-        1: x/i $pc
-        => 0x8048644 <my_handler+23>:   leave
-        (gdb)
-        0x08048645 in my_handler ()
-        1: x/i $pc
-        => 0x8048645 <my_handler+24>:   ret
-        (gdb)
-        0x010708b2 in trampoline () from /lib/i386-gnu/libc.so.0.3
-        1: x/i $pc
-        => 0x10708b2 <trampoline+2>:    add    $0xc,%esp
-        (gdb)
-        0x010708b5 in trampoline () from /lib/i386-gnu/libc.so.0.3
-        1: x/i $pc
-        => 0x10708b5 <trampoline+5>:    ret
-        (gdb)
-        __sigreturn (scp=0x102988c) at ../sysdeps/mach/hurd/i386/sigreturn.c:30
-        30      ../sysdeps/mach/hurd/i386/sigreturn.c: No such file or directory.
-        1: x/i $pc
-        => 0x1096340 <__sigreturn>:     push   %ebp
-        (gdb)
-        0x01096341      30      in ../sysdeps/mach/hurd/i386/sigreturn.c
-        1: x/i $pc
-        => 0x1096341 <__sigreturn+1>:   push   %edi
-        (gdb)
-        0x01096342      30      in ../sysdeps/mach/hurd/i386/sigreturn.c
-        1: x/i $pc
-        => 0x1096342 <__sigreturn+2>:   push   %esi
-        (gdb)
-        0x01096343      30      in ../sysdeps/mach/hurd/i386/sigreturn.c
-        1: x/i $pc
-        => 0x1096343 <__sigreturn+3>:   push   %ebx
-        (gdb)
-        0x01096344      30      in ../sysdeps/mach/hurd/i386/sigreturn.c
-        1: x/i $pc
-        => 0x1096344 <__sigreturn+4>:   sub    $0x2c,%esp
-        (gdb)
-        0x01096347      30      in ../sysdeps/mach/hurd/i386/sigreturn.c
-        1: x/i $pc
-        => 0x1096347 <__sigreturn+7>:   mov    0x40(%esp),%esi
-        (gdb)
-        0x0109634b      30      in ../sysdeps/mach/hurd/i386/sigreturn.c
-        1: x/i $pc
-        => 0x109634b <__sigreturn+11>:  call   0x11a0609 <__x86.get_pc_thunk.bx>
-        (gdb)
-        0x011a0609 in __x86.get_pc_thunk.bx () from /lib/i386-gnu/libc.so.0.3
-        1: x/i $pc
-        => 0x11a0609 <__x86.get_pc_thunk.bx>:   mov    (%esp),%ebx
-        (gdb)
-        0x011a060c in __x86.get_pc_thunk.bx () from /lib/i386-gnu/libc.so.0.3
-        1: x/i $pc
-        => 0x11a060c <__x86.get_pc_thunk.bx+3>: ret
-        (gdb)
-        0x01096350 in __sigreturn (scp=0x102988c) at ../sysdeps/mach/hurd/i386/sigreturn.c:30
-        30      in ../sysdeps/mach/hurd/i386/sigreturn.c
-        1: x/i $pc
-        => 0x1096350 <__sigreturn+16>:  add    $0x15ccb0,%ebx
-        (gdb)
-        35      in ../sysdeps/mach/hurd/i386/sigreturn.c
-        1: x/i $pc
-        => 0x1096356 <__sigreturn+22>:  test   %esi,%esi
-        (gdb)
-        0x01096358      35      in ../sysdeps/mach/hurd/i386/sigreturn.c
-        1: x/i $pc
-        => 0x1096358 <__sigreturn+24>:  je     0x10964f0 <__sigreturn+432>
-        (gdb)
-        0x0109635e      35      in ../sysdeps/mach/hurd/i386/sigreturn.c
-        1: x/i $pc
-        => 0x109635e <__sigreturn+30>:  testl  $0x10100,0x4(%esi)
-        (gdb)
-        0x01096365      35      in ../sysdeps/mach/hurd/i386/sigreturn.c
-        1: x/i $pc
-        => 0x1096365 <__sigreturn+37>:  jne    0x10964f0 <__sigreturn+432>
-        (gdb)
-        __hurd_threadvar_location_from_sp (__sp=<optimized out>, __index=<optimized out>) at ../hurd/hurd/threadvar.h:94
-        94      ../hurd/hurd/threadvar.h: No such file or directory.
-        1: x/i $pc
-        => 0x109636b <__sigreturn+43>:  mov    -0x38(%ebx),%ebp
-        (gdb)
-        __hurd_threadvar_location (__index=_HURD_THREADVAR_SIGSTATE) at ../hurd/hurd/threadvar.h:116
-        116     in ../hurd/hurd/threadvar.h
-        1: x/i $pc
-        => 0x1096371 <__sigreturn+49>:  mov    %esp,%edx
-        (gdb)
-        __hurd_threadvar_location_from_sp (__sp=0x1029848, __index=_HURD_THREADVAR_SIGSTATE) at ../hurd/hurd/threadvar.h:94
-        94      in ../hurd/hurd/threadvar.h
-        1: x/i $pc
-        => 0x1096373 <__sigreturn+51>:  cmp    0x0(%ebp),%esp
-        (gdb)
-        0x01096376      94      in ../hurd/hurd/threadvar.h
-        1: x/i $pc
-        => 0x1096376 <__sigreturn+54>:  jae    0x10964d0 <__sigreturn+400>
-        (gdb)
-        0x0109637c      94      in ../hurd/hurd/threadvar.h
-        1: x/i $pc
-        => 0x109637c <__sigreturn+60>:  mov    -0x15c(%ebx),%eax
-        (gdb)
-        0x01096382      94      in ../hurd/hurd/threadvar.h
-        1: x/i $pc
-        => 0x1096382 <__sigreturn+66>:  and    (%eax),%edx
-        (gdb)
-        0x01096384      94      in ../hurd/hurd/threadvar.h
-        1: x/i $pc
-        => 0x1096384 <__sigreturn+68>:  mov    -0x90(%ebx),%eax
-        (gdb)
-        0x0109638a      94      in ../hurd/hurd/threadvar.h
-        1: x/i $pc
-        => 0x109638a <__sigreturn+74>:  add    (%eax),%edx
-        (gdb)
-        _hurd_self_sigstate () at ../hurd/hurd/signal.h:165
-        165     ../hurd/hurd/signal.h: No such file or directory.
-        1: x/i $pc
-        => 0x109638c <__sigreturn+76>:  mov    0x8(%edx),%edi
-        (gdb)
-        0x0109638f      165     in ../hurd/hurd/signal.h
-        1: x/i $pc
-        => 0x109638f <__sigreturn+79>:  test   %edi,%edi
-        (gdb)
-        0x01096391      165     in ../hurd/hurd/signal.h
-        1: x/i $pc
-        => 0x1096391 <__sigreturn+81>:  je     0x1096598 <__sigreturn+600>
-        (gdb)
-        __sigreturn (scp=0x102988c) at ../sysdeps/mach/hurd/i386/sigreturn.c:42
-        42      ../sysdeps/mach/hurd/i386/sigreturn.c: No such file or directory.
-        1: x/i $pc
-        => 0x1096397 <__sigreturn+87>:  mov    %edi,(%esp)
-        (gdb)
-        0x0109639a      42      in ../sysdeps/mach/hurd/i386/sigreturn.c
-        1: x/i $pc
-        => 0x109639a <__sigreturn+90>:  call   0x1051d70 <_hurd_sigstate_lock@plt>
-        (gdb)
-        0x01051d70 in _hurd_sigstate_lock@plt () from /lib/i386-gnu/libc.so.0.3
-        1: x/i $pc
-        => 0x1051d70 <_hurd_sigstate_lock@plt>: jmp    *0x864(%ebx)
-        (gdb)
-        _hurd_sigstate_lock (ss=ss@entry=0x1244008) at hurdsig.c:170
-        170     hurdsig.c: No such file or directory.
-        1: x/i $pc
-        => 0x106bb90 <_hurd_sigstate_lock>:     sub    $0x1c,%esp
-        (gdb)
-        0x0106bb93      170     in hurdsig.c
-        1: x/i $pc
-        => 0x106bb93 <_hurd_sigstate_lock+3>:   mov    %ebx,0x14(%esp)
-        (gdb)
-        0x0106bb97      170     in hurdsig.c
-        1: x/i $pc
-        => 0x106bb97 <_hurd_sigstate_lock+7>:   call   0x11a0609 <__x86.get_pc_thunk.bx>
-        (gdb)
-        0x011a0609 in __x86.get_pc_thunk.bx () from /lib/i386-gnu/libc.so.0.3
-        1: x/i $pc
-        => 0x11a0609 <__x86.get_pc_thunk.bx>:   mov    (%esp),%ebx
-        (gdb)
-        0x011a060c in __x86.get_pc_thunk.bx () from /lib/i386-gnu/libc.so.0.3
-        1: x/i $pc
-        => 0x11a060c <__x86.get_pc_thunk.bx+3>: ret
-        (gdb)
-        0x0106bb9c in _hurd_sigstate_lock (ss=ss@entry=0x1244008) at hurdsig.c:170
-        170     in hurdsig.c
-        1: x/i $pc
-        => 0x106bb9c <_hurd_sigstate_lock+12>:  add    $0x187464,%ebx
-        (gdb)
-        0x0106bba2      170     in hurdsig.c
-        1: x/i $pc
-        => 0x106bba2 <_hurd_sigstate_lock+18>:  mov    %esi,0x18(%esp)
-        (gdb)
-        170     in hurdsig.c
-        1: x/i $pc
-        => 0x106bba6 <_hurd_sigstate_lock+22>:  mov    0x20(%esp),%esi
-        (gdb)
-        sigstate_is_global_rcv (ss=0x1244008) at hurdsig.c:162
-        162     in hurdsig.c
-        1: x/i $pc
-        => 0x106bbaa <_hurd_sigstate_lock+26>:  lea    0x57c0(%ebx),%eax
-        (gdb)
-        0x0106bbb0      162     in hurdsig.c
-        1: x/i $pc
-        => 0x106bbb0 <_hurd_sigstate_lock+32>:  mov    (%eax),%eax
-        (gdb)
-        163     in hurdsig.c
-        1: x/i $pc
-        => 0x106bbb2 <_hurd_sigstate_lock+34>:  test   %eax,%eax
-        (gdb)
-        0x0106bbb4      163     in hurdsig.c
-        1: x/i $pc
-        => 0x106bbb4 <_hurd_sigstate_lock+36>:  je     0x106bbbc <_hurd_sigstate_lock+44>
-        (gdb)
-        0x0106bbb6      163     in hurdsig.c
-        1: x/i $pc
-        => 0x106bbb6 <_hurd_sigstate_lock+38>:  cmpl   $0x1,0x18(%esi)
-        (gdb)
-        0x0106bbba      163     in hurdsig.c
-        1: x/i $pc
-        => 0x106bbba <_hurd_sigstate_lock+42>:  je     0x106bbe0 <_hurd_sigstate_lock+80>
-        (gdb)
-        _hurd_sigstate_lock (ss=ss@entry=0x1244008) at hurdsig.c:172
-        172     in hurdsig.c
-        1: x/i $pc
-        => 0x106bbe0 <_hurd_sigstate_lock+80>:  lea    0x4(%eax),%ecx
-        (gdb)
-        __spin_try_lock (__lock=0x124480c) at ../sysdeps/mach/i386/machine-lock.h:59
-        59      ../sysdeps/mach/i386/machine-lock.h: No such file or directory.
-        1: x/i $pc
-        => 0x106bbe3 <_hurd_sigstate_lock+83>:  mov    $0x1,%edx
-        (gdb)
-        0x0106bbe8      59      in ../sysdeps/mach/i386/machine-lock.h
-        1: x/i $pc
-        => 0x106bbe8 <_hurd_sigstate_lock+88>:  xchg   %edx,0x4(%eax)
-        (gdb)
-    <braunr> zyg: i don't get what you mean
-    <braunr> are you starting it with gdb ?
-    <zyg> braunr: yes: "gdb --args a.out"
-    <braunr> ok
-    <braunr> can't reproduce it
-    <braunr> i get "Program received signal SIGHUP, Hangup.
-    <braunr> "
-    <braunr> then continue, then the program has exited
-    <zyg> braunr: do you run it in gdb or without?
-    <zyg> braunr: Ah "Program received signal SIGHUP, Hangup." is from
-      gdb.. try issue continue, not sure why gdb stops at SIGHUP (default?).
-    <braunr> 10:34 < braunr> then continue, then the program has exited
-    <braunr> gdb stops at signals
-    <zyg> braunr: yes, try repeating that, but instead of continue, just issue
-      "si"
-    <zyg> braunr: sorry.. you would need to remove that printf/fprintf, else it
-      gets too long. That's why I put a breakpoint.
-    <braunr> a breakpoint ?
-    <braunr> on the signal handler ?
-    <zyg> braunr: yes, put a break after having entered the handler. Or edit
-      the pasted C code an remove that printf("got SIGHUP\n");
-    <braunr> i'm not sure that's correctly supported
-    <braunr> and i can see why glibc would deadlock on the sigstate lock
-    <braunr> don't do that :p
-    <zyg> braunr: why does it deadlock?
-    <braunr> because both the signal handler and messages from gdb will cause
-      common code paths to be taken
-    <zyg> braunr: oh.. when I step instruction I'm inside an SIGTRAP handler
-      probably?
-    <braunr> possible
-    <braunr> i don't know the details but that's the kind of things i expect
-    <braunr> and signals on the hurd are definitely buggy
-    <braunr> i don't know if we support nesting them
-    <braunr> i'd say we don't
-    <zyg> braunr: I'll try to put a break beyond that xchg and continue
-    <braunr> xhcg is probably the sigstate spinlock
-    <braunr> xchg*
-    <braunr> you'd need to reach the unlock instruction, which is probably
-      executed once the handler has finished running
-    <zyg> braunr: yes :) ... one instruction beyond didn't help
-    <zyg> braunr: thanks alot, putting a break in __sigreturn, after that
-      function has called _hurd_sigstate_unlock@plt works!
-    <braunr> works ?
-    <braunr> what did you want to do ?
-    <zyg> braunr: I want to trace user code inside the signal handler, also how
-      we enter and how we leave.
-    <braunr> well you can't do that inside, so no it doesn't work for you :/
-    <braunr> but that's a start i guess
-    <zyg> braunr: I seem to do most normal things inside the handler,
-      step-instruction and put breaks.
-    <braunr> ?
-    <braunr> i thought that's what made the program deadlock
-    <zyg> braunr: as you said earlier, the deadlock came when i "step
-      instruction" into the area between _hurd_sigstate_lock and
-      _hurd_sigstate_unlock. Otherwise I havn't had any issues.
-    <braunr> but isn't the sigstate locked during the handler execution ?
-    <zyg> braunr: no it locks and unlocks in __sigreturn which is done when
-      leaving the handler.
-    <braunr> than how could it deadlock on handler entry ?
-    <braunr> or perhaps the fact your handler was empty made the entry point
-      directly reach __sigreturn
-    <braunr> hm no i don't buy it
-    <braunr> the sigstate must also be locked on entry
-    <zyg> braunr: there was never any problem with entering
-    <braunr> then describe the problem with more details please
-    <braunr> ah sorry
-    <zyg> braunr: are you sure? there is minimal user-code run before the
-      signal is going into the handler.
-    <braunr> you "step out of the handler"
-
-
-# IRC, freenode, #hurd, 2013-10-24
-
-    <gnu_srs> how come some executables are not debuggable with gdb, e.g Cannot
-      access memory at address xxx. -fPIC flag?
-    <braunr> no
-    <braunr> i'm not sure but it's certainly not -fPIC
-    <gnu_srs> Another example is localedef: ./debian/tmp-libc/usr/bin/localedef
-      -i en_GB -c -f UTF-8 -A /usr/share/locale/locale.alias en_GB.UTF-8
-      segfailts
-    <gnu_srs> and in gdb hangs after creating a thread., after C-c no useful
-      info: stack ends with: Cannot access memory at address 0x8382c385
-    <braunr> if it's on the stack, it's probably a stack corruption
-    <nalaginrut> gnu_srs:  are u using 'x' command or 'print' in GDB? IIRC
-      print may throw such message, but x may not
-    <gnu_srs> bt
-    <braunr> x may too
-    <braunr> what you're showing looks like an utf-8 string
-    <braunr> c385 is Å
-    <braunr> 83 is a special f
-    <braunr> 82 is a comma
-    <gnu_srs> so the stack is corrupted:-(
-    <braunr> probably
-    <braunr> well, certainly
-    <braunr> but gdb should show you where the program counter is
-    <gnu_srs> is that: ECX: the count register 
-    <braunr> no
-    <braunr> eip
-    <braunr> program counter == instruction pointer
-    <gnu_srs> k!, the program counter is at first entry in bt: #0  0x01082612
-      in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:133
-    <braunr> this is the hurd interruptible version of mach_msg
-    <braunr> so it probably means the corruption was made by a signal handler
-    <braunr> which is one of the reasons why gdb can't handle Ctrl-c
-    <gnu_srs> what to do in such a case, follow the source code
-      single-stepping?
-    <braunr> single stepping also uses signals
-    <braunr> and using printf will probably create an infinite recursion
-    <braunr> in those cases, i use mach_print
-    <braunr> as a first step, you could make sure a signal is actually received
-    <braunr> and which one
-    <braunr> hmm
-    <braunr> also, before rushing into conclusions, make sure you're looking at
-      the right thread
-    <braunr> i don't expect localedef to be multithreaded
-    <braunr> but gdb sometimes just doesn't get the thread where the segfault
-      actually occurred
-    <gnu_srs> two threads: 1095.4 and 1095.5 (created when starting localedef
-      in gdb)
-    <braunr> no, at the time of the crash
-    <braunr> the second thread is always the signal thread
-    <gnu_srs> OK,in gdb the program hangs, interrupted by C-c, outside it
-      segfaults
-    <braunr> when you use bt to get the corrupted stack, you can also use info
-      threads and thread apply all bt
-    <gnu_srs> I did: http://paste.debian.net/61170/
-    <braunr> ok so it confirms there is only one real application thread, the
-      main one
-    <braunr> and that the corruption probably occurs during signal handling
-    <gnu_srs> rpctrace (edited out non-printable characters):
-      http://paste.debian.net/61178/
-    <gnu_srs> Ah, have to do it again as root;-)
-    <braunr> yes .. :p
-    <gnu_srs> new last part: http://paste.debian.net/61181/
-    <braunr> so, there is a seek, then a stat, then a close perhaps (port
-      deallocation) and then a signal received (probably sigsegv)
-    <braunr> gnu_srs: when you try running it in gdb, do you get a sigkill ?
-    <braunr> damn, gdb on darnassus is bugged :-(
-    <gnu_srs> It hangs, interrupted with C-c.
-    <braunr> ok
diff --git a/open_issues/gdb_signal_thread_bt.mdwn b/open_issues/gdb_signal_thread_bt.mdwn
deleted file mode 100644
index 74065922..00000000
--- a/open_issues/gdb_signal_thread_bt.mdwn
+++ /dev/null
@@ -1,31 +0,0 @@
-[[!meta copyright="Copyright © 2009 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]]."]]"""]]
-
-[[!meta title="GDB: bt on the signal thread"]]
-
-[[!tag open_issue_gdb]]
-
-    (gdb) r
-    Starting program: /media/data/home/tschwinge/tmp/h 
-    [New Thread 26731.15]
-    
-    Breakpoint 1, 0x08048236 in main ()
-    (gdb) info threads
-      5 Thread 26731.15  0x080a97fc in mach_msg_trap ()
-    * 4 Thread 26731.14  0x08048236 in main ()
-    (gdb) thread 5
-    [Switching to thread 5 (Thread 26731.15)]#0  0x080a97fc in mach_msg_trap ()
-    (gdb) bt
-    #0  0x080a97fc in mach_msg_trap ()
-    #1  0x080a272e in mach_msg ()
-    #2  0x080a9934 in mach_msg_server_timeout ()
-    #3  0x080a99ff in mach_msg_server ()
-    #4  0x080a327e in _hurd_msgport_receive ()
-    Cannot access memory at address 0x1012000
diff --git a/open_issues/gdb_thread_ids.mdwn b/open_issues/gdb_thread_ids.mdwn
deleted file mode 100644
index 64173b1b..00000000
--- a/open_issues/gdb_thread_ids.mdwn
+++ /dev/null
@@ -1,31 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 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]]."]]"""]]
-
-[[!meta title="GDB: thread ids"]]
-
-[[!tag open_issue_gdb]]
-
-GNU GDB's Pedro Alves:
-
-> One thing [[!message-id desc="I asked myself"
-> "200810131935.35253.pedro@codesourcery.com"]]
-> was, if gnu-nat.c couldn't be using the port's id as thread ids instead of a
-> locally auto-generated number.  Maybe the thread id of the main thread would
-> be preserved across execs this way
-
-
-Also see [[thread numbering of ps and GDB]].
-
----
-
-`attach` to a multi-threaded process.  See threads 1 to 5.  `detach`.  `attach`
-again -- thread numbers continue where they stopped last time: now they're
-threads 6 to 10.
diff --git a/open_issues/git-core-2.mdwn b/open_issues/git-core-2.mdwn
deleted file mode 100644
index a92b3ebb..00000000
--- a/open_issues/git-core-2.mdwn
+++ /dev/null
@@ -1,323 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2013 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]]."]]"""]]
-
-[[!meta title="Hiccups of Git"]]
-
-[[!tag open_issue_porting]]
-
-[[!toc]]
-
-
-# 2008-12
-
-On the otherwise-idle flubber:
-
-    $ git clone git://sources.redhat.com/git/glibc.git
-    Initialized empty Git repository in /media/data/home/tschwinge/tmp/glibc/glibc/.git/
-    remote: Generating pack...
-    remote: Done counting 380933 objects.
-    remote: Deltifying 380933 objects...
-    remote:  100% (380933/380933) done
-    remote: Total 380933 (delta 294166), reused 380686 (delta 294002)
-    Receiving objects: 100% (380933/380933), 70.31 MiB | 27 KiB/s, done.
-    Resolving deltas: 100% (294166/294166), done.
-    error: git-checkout-index: unable to create file iconvdata/ibm1122.c (Interrupted system call)
-    error: git-checkout-index: unable to create file localedata/charmaps/IBM862 (Interrupted system call)
-    Checking out files: 100% (10676/10676), done.
-    $ git status
-    # On branch master
-    # Changed but not updated:
-    #   (use "git add <file>..." to update what will be committed)
-    #
-    #       modified:   iconvdata/ibm1122.c
-    #       modified:   localedata/charmaps/IBM862
-    #
-    no changes added to commit (use "git add" and/or "git commit -a")
-    $ ls -l iconvdata/ibm1122.c localedata/charmaps/IBM862
-    -rw-r--r-- 1 tschwinge tschwinge 0 2008-12-15 15:49 iconvdata/ibm1122.c
-    -rw-r--r-- 1 tschwinge tschwinge 0 2008-12-15 15:49 localedata/charmaps/IBM862
-
-So these files are indeed of zero-length in the checked-out tree.  Is this
-Git's fault or something else's?
-
-Fixing this situation is easy enough:
-
-    $ git checkout -- iconvdata/ibm1122.c localedata/charmaps/IBM862
-    $ git status
-    # On branch master
-    nothing to commit (working directory clean)
-
-
-## 2010-03-16
-
-Still seen.
-
-
-## IRC, freenode, #hurd, 2013-10-10
-
-    <sea`> Huh? I've cloned the 'hurd' repository and I'm attempting to compile
-      it, but the 'rtnetlink.h' header in
-      'hurd/pfinet/linux-src/include/linux/' is just blank. (Which leads to an
-      error later down when a macro that's supposed to be defined in there is
-      first used)
-    <sea`> So I'm just wondering, is that file really blank? Or is this some
-      unexpected error of decompression? 
-    <braunr> clone again and see
-    <braunr> the file is definitely not empty
-    <sea`> I cloned it twice, both have that file blank. BUT, I want to point
-      out that both clones do have some decompression errors. (Some files are
-      missing chunks in /both/ cloned repositories).
-    <braunr> where did you clone it from ?
-    <sea`> git.sv.gnu.org/hurd/hurd.git
-    <braunr> hum decompression errors ?
-    <braunr> can you paste them please ?
-    <sea`> Hmm, I can clone again and show you an example if I find one
-    <sea`> This was on the hurd. When I run: git clone $repo;, it seems to fail
-      almost randomly with "incorrect header check", but when it does succeed,
-      occasionally some files are missing chunks
-    <sea`> and apparently entire files can be blank
-    <braunr> http or git ?
-    <sea`> git.
-    <braunr> that's really weird
-    <braunr> actually i don't even have problems with http any more nowadays ..
-    <sea`> This is using the hurd image from sthibault
-    <sea`> So once I get it recompiled and shuffle in the new binaries, the
-      problem should probably go away
-    <braunr> no
-    <braunr> well maybe but
-    <braunr> don't recompile
-    <braunr> upgrade packages instead
-    <sea`> Alright, I'll do an upgrade instead. Why that path specifically?
-    <braunr> rebuilding is long
-    <braunr> i wonder if the image you got is corrupted
-    <braunr> compute the checksum
-    <braunr> we've had weird reports in the past about the images he provides
-    <braunr> well not the images themselves, but differences after dowloading
-      ..
-    <braunr> downloading*
-    <sea`> The MD5SUMS file on his site isn't including the values for the most
-      recent images.
-    <sea`> It stops at 2012-12-28
-    <braunr> hummm
-    <sea`> Anyway, let's see. git clone failed again:
-    <sea`> Receiving objects: 100% (50955/50955), 15.48 MiB | 42 KiB/s, done.
-    <sea`> error: inflate: date stream error (incorrect header check) <- This
-      is the interesting part
-    <sea`> fatal: serious inflate inconsistency
-    <sea`> fatal: index-pack failed
-    <braunr> not intereseting enough unfortunately
-    <braunr> but it might come from savannah too
-    <braunr> try the mirrors at
-      http://darnassus.sceen.net/gitweb/?a=project_list;pf=savannah_mirror
-    <sea`> Let's see..if I try: 'git clone
-      git://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git', I get:
-      'fatal: remote error: access denied or repository not exported:
-      /gitweb/savannah_mirror/hurd.git'
-    <braunr> my bad
-    <braunr> that's weird, it should work ..
-    <braunr> oh, stupid translation error
-    <sea`> translation? From one human language to another?
-    <braunr> not translation actually
-    <braunr> typo :)
-    <braunr> it's either
-    <braunr> git://darnassus.sceen.net/savannah_mirror/hurd.git
-    <braunr> or
-    <braunr> http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git
-    <braunr> copy paste the url exactly please
-    <braunr> /gitweb/ is only present in the http url
-    <sea`> Ah, right. Okay, I'll paste it exactly
-    <sea`> Ehm. The whole thing locked up badly. I'll reboot it and try again.
-    <braunr> are you sure it locked oO ?
-    <braunr> the hurd can easily become unresponsive when performing io
-      operations
-    <braunr> but you need more than such a git repository to reach that state
-    <sea`> Yeah, that happens occasionally. It's not related to git, but rather
-      it happens when I cancel some command.
-    <braunr> your image must be corrupted
-    <braunr> have you enabled host io caching btw ?
-    <sea`> By now it's corrupted for sure..everytime it crashes the filesystem
-      gets into a weird state. 
-    <sea`> I'll unpack a fresh image, then update the packages, and then try
-      cloning this git repository.
-    <braunr> i'll get the image too so we can compare sums
-    <sea`> 957bb0768c9558564f0c3e0adb9b317e  ./debian-hurd.img.tar.gz
-    <sea`> Which unpacks to: debian-hurd-20130504.img
-    <azeem_> the NSA might backdoor the Hurd, in anticipation of our scheduled
-      world-dominance
-    <braunr> for now they're doing it passively :
-    <braunr> :p
-    <braunr> sea`: same thing here
-    <braunr> sea`: if you still have problems, the image itself might be wrong
-    <braunr> in which case you should try with the debian network installer
-    <sea`> Ah, so if problems persist, try with the network installer. Okay
-    <sea`> Is there some recipe for constructing a hurd/mach minimal
-      environment? 
-    <sea`> A system with only just enough tools and libraries to compile and
-      poke at things.
-    <braunr> not currently
-    <braunr> we all work in debian environments
-    <braunr> the reason being that a lot of patches are queued for integration
-      upstream
-
-
-# 2010-11-17
-
-A very similar issue.  The working tree had a lot of
-differences to HEAD.
-
-    tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD
-    error: unable to unlink old 'gcc/config/darwin.h' (Interrupted system call)
-    Checking out files: 100% (1149/1149), done.
-    fatal: Could not reset index file to revision 'HEAD'.
-    tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD
-    error: unable to unlink old 'gcc/config/iq2000/iq2000.md' (Interrupted system call)
-    error: git checkout-index: unable to create file gcc/config/lm32/lm32.c (File exists)
-    Checking out files: 100% (1149/1149), done.
-    fatal: Could not reset index file to revision 'HEAD'.
-    tschwinge@grubber:~/tmp/gcc/hurd $ ls -l gcc/config/iq2000/iq2000.md gcc/config/lm32/lm32.c
-    ls: cannot access gcc/config/iq2000/iq2000.md: No such file or directory
-    -rw-r--r-- 1 tschwinge tschwinge 32159 Nov 17 19:09 gcc/config/lm32/lm32.c
-    tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD
-    error: git checkout-index: unable to create file gcc/fortran/expr.c (Interrupted system call)
-    Checking out files: 100% (1149/1149), done.
-    fatal: Could not reset index file to revision 'HEAD'.
-    tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD
-    error: git checkout-index: unable to create file gcc/config/sol2.h (Interrupted system call)
-    Checking out files: 100% (1149/1149), done.
-    fatal: Could not reset index file to revision 'HEAD'.
-    tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD
-    error: unable to unlink old 'gcc/config/i386/i386.c' (Interrupted system call)
-    Checking out files: 100% (1149/1149), done.
-    fatal: Could not reset index file to revision 'HEAD'.
-    tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD
-    Checking out files: 100% (1149/1149), done.
-    HEAD is now at fe3e43c Merge commit 'refs/top-bases/hurd/master' into hurd/master
-
-
-## 2010-12-22
-
-grubber:
-
-    $ git remote update
-    Fetching savannah
-    remote: Counting objects: 582331, done.
-    remote: Compressing objects: 100% (124133/124133), done.
-    remote: Total 582331 (delta 460856), reused 578352 (delta 457598)
-    Receiving objects: 100% (582331/582331), 525.15 MiB | 204 KiB/s, done.
-    fatal: cannot pread pack file: Interrupted system call
-    fatal: index-pack failed
-    error: Could not fetch savannah
-
-
-## 2011-06-10
-
-coulomb.SCHWINGE, checking out [[binutils]]' master branch,
-starting from an empty working directory (after an external `git push`):
-
-    $ git checkout -f
-    fatal: cannot create directory at 'gas/testsuite/gas/bfin': Interrupted system call
-    $ git checkout -f
-    error: unable to create file gas/testsuite/gas/i386/ilp32/x86-64-sse4_1-intel.d (File exists)
-    warning: unable to unlink gas/testsuite/gas/m68k-coff: Operation not permitted
-    fatal: cannot create directory at 'gas/testsuite/gas/m68k-coff': Operation not permitted
-    $ git checkout -f
-    error: unable to create file gas/testsuite/gas/h8300/h8300.exp (File exists)
-    error: unable to create file gas/testsuite/gas/i386/x86-64-addr32-intel.d (File exists)
-    error: unable to create file gas/testsuite/gas/ia64/secname.d (File exists)
-    error: unable to create file gas/testsuite/gas/m68k/pr11676.s (File exists)
-    Checking out files: 100% (12315/12315), done.
-    $ git status
-    # On branch master
-    # Changes not staged for commit:
-    #   (use "git add <file>..." to update what will be committed)
-    #   (use "git checkout -- <file>..." to discard changes in working directory)
-    #
-    #       modified:   gas/testsuite/gas/h8300/h8300.exp
-    #       modified:   gas/testsuite/gas/i386/x86-64-addr32-intel.d
-    #       modified:   gas/testsuite/gas/ia64/secname.d
-    #       modified:   gas/testsuite/gas/m68k/pr11676.s
-    #
-    no changes added to commit (use "git add" and/or "git commit -a")
-    $ rm gas/testsuite/gas/h8300/h8300.exp gas/testsuite/gas/i386/x86-64-addr32-intel.d gas/testsuite/gas/ia64/secname.d gas/testsuite/gas/m68k/pr11676.s
-    $ git checkout -f
-    $ git status
-    # On branch master
-    nothing to commit (working directory clean)
-
-
-# Analysis
-
-## 2011-06-13
-
-Running `git checkout -f` under GDB:
-
-    error: git checkout-index: unable to create file gas/testsuite/gas/cris/string-1.s (File exists)
-    error: git checkout-index: unable to create file gas/testsuite/gas/i386/x86-64-sse-check.d (File exists)
-    error: git checkout-index: unable to create file gas/testsuite/gas/i386/x86-64-sse4_1.d (File exists)
-    error: git checkout-index: unable to create file gas/testsuite/gas/ppc/astest.d (File exists)
-    error: git checkout-index: unable to create file gas/testsuite/gas/tic6x/reloc-bad-4.s (File exists)
-    warning: unable to unlink include/cgen: Operation not permitted
-    fatal: cannot create directory at 'include/cgen': Operation not permitted
-
-Again:
-
-    error: git checkout-index: unable to create file gas/config/te-vxworks.h (File exists)
-    error: git checkout-index: unable to create file gas/testsuite/gas/cris/string-1.s (File exists)
-    error: git checkout-index: unable to create file gas/testsuite/gas/d10v/warning-019.s (File exists)
-    error: git checkout-index: unable to create file gas/testsuite/gas/i860/dual03.s (File exists)
-    error: git checkout-index: unable to create file ld/testsuite/ld-mmix/sec-7a.s (File exists)
-    warning: unable to unlink ld/testsuite/ld-powerpc: Operation not permitted
-    fatal: cannot create directory at 'ld/testsuite/ld-powerpc': Operation not permitted
-
-And: [[git_duplicated_content]].
-
-All these (very likely) have the same root cause: `SA_RESTART` restarting too
-much.
-
-With `git checkout`, Git uses in progress.c a SIGALRM handler (`SA_RESTART`;
-invoked every second via `setitimer(ITIMER_REAL)`) to display status messages:
-*x % already checked out*.
-
-To avoid the status update signals every second, in
-`[git]/progress.c:start_progress_delay` we can just return `NULL` (manually in
-GDB, for example), then both the *error: git checkout-index* and the
-[[duplicated content|git_duplicated_content]] issues go away.
-
-I'm guessing that when returning from a `SA_RESTART` signal handler, too much
-of the \`\`syscall''s is being restarted.  For example, if a file has already
-been created, the restarted creation attempt would fail: *File exists*.  If
-data has been written, it might get written again (duplication issue). Then,
-there are cases where `unlink` apparently returns EINTR, which is not kosher
-either.  Etc.
-
-Do we have problems with `SA_RESTART` vs. the atomicity of our syscall-alikes?
-
-
-## IRC, freenode, #hurd, 2013-01-30
-
-    <braunr> hm, let's try to clone a huge repository
-    <braunr> hm, cloning a whole linux repo, and still no problem :)
-    <pinotree> weren't most/all the issues at unpack time?
-    <braunr> i don't remember
-    <braunr> we'll see when it gets there
-    <braunr> the longest part is "resolving deltas", for which ext2fs is
-      clearly the big bottleneck (no I/O, page-cache only, but still)
-    <braunr> pinotree: well, slow, but no error
-
-
-### IRC, freenode, #hurd, 2013-01-31
-
-    <braunr> fyi, i've tried several checkouts of big repositories, and never
-      got a single error
-    <braunr> youpi: looks like the recent fixes also solved some git issues we
-      had
-    <braunr> i could clone big repositories without any problem
-    <youpi> cool :)
diff --git a/open_issues/git_duplicated_content.mdwn b/open_issues/git_duplicated_content.mdwn
deleted file mode 100644
index f0ffad77..00000000
--- a/open_issues/git_duplicated_content.mdwn
+++ /dev/null
@@ -1,128 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2013 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_porting]]
-
-    $ git-new-workdir ~/tmp/binutils/git /media/hd1s1/tmp/master master
-    error: unable to create file gas/testsuite/gas/arm/attr-mfpu-vfpv3-d16.d (Interrupted system call)
-    Checking out files: 100% (12315/12315), done.
-    Already on 'master'
-    $ cd /media/hd1s1/tmp/master
-    $ git status
-    # On branch master
-    # Changes not staged for commit:
-    #   (use "git add <file>..." to update what will be committed)
-    #   (use "git checkout -- <file>..." to discard changes in working directory)
-    #
-    #       modified:   gas/testsuite/gas/arm/attr-mfpu-vfpv3-d16.d
-    #
-    no changes added to commit (use "git add" and/or "git commit -a")
-    $ git checkout -f
-    $ git status
-    # On branch master
-    nothing to commit (working directory clean)
-
-([[Git issue|git-core-2]] is known.)
-
-    $ git-new-workdir ~/tmp/binutils/git /media/hd1s2/tmp/master master
-    error: unable to create file bfd/elf32-dlx.c (Interrupted system call)
-    error: unable to create file bfd/sunos.c (Interrupted system call)
-    error: unable to create file gas/testsuite/gas/arm/attr-mfpu-vfpv3-d16.d (Interrupted system call)
-    error: unable to create file gas/testsuite/gas/mmix/regx-op.d (Interrupted system call)
-    error: unable to create file gas/testsuite/gas/tic6x/reloc-bad-4.s (Interrupted system call)
-    error: unable to create file gold/testsuite/script_test_2.t (Interrupted system call)
-    error: unable to create file ld/testsuite/ld-mmix/loc7m.d (Interrupted system call)
-    error: unable to create file ld/testsuite/ld-powerpc/tlsexe.g (Interrupted system call)
-    Checking out files: 100% (12315/12315), done.
-    Already on 'master'
-    $ cd /media/hd1s2/tmp/master
-    $ git status
-    # On branch master
-    # Changes not staged for commit:
-    #   (use "git add <file>..." to update what will be committed)
-    #   (use "git checkout -- <file>..." to discard changes in working directory)
-    #
-    #       modified:   bfd/elf32-dlx.c
-    #       modified:   bfd/sunos.c
-    #       modified:   gas/testsuite/gas/arm/attr-mfpu-vfpv3-d16.d
-    #       modified:   gas/testsuite/gas/mmix/regx-op.d
-    #       modified:   gas/testsuite/gas/tic6x/reloc-bad-4.s
-    #       modified:   gold/testsuite/script_test_2.t
-    #       modified:   ld/testsuite/ld-mmix/loc7m.d
-    #       modified:   ld/testsuite/ld-powerpc/tlsexe.g
-    #
-    no changes added to commit (use "git add" and/or "git commit -a")
-    $ git checkout -f
-    $ git status
-    # On branch master
-    nothing to commit (working directory clean)
-
-Now you'd expect these directories to have identical content, but:
-
-    $ diff -x .git -ru /media/hd1s{1,2}/tmp/master/ > /tmp/diff
-    $ ls -l /tmp/diff
-    -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:12 /tmp/diff
-    $ grep '^[^ @+-]' < /tmp/diff
-    diff -x .git -ru /media/hd1s1/tmp/master//ld/configure /media/hd1s2/tmp/master//ld/configure
-
-(Note that this isn't a file that Git had issues with.)
-
-Try again:
-
-    $ diff -x .git -ru /media/hd1s{1,2}/tmp/master/ > /tmp/diff_
-    $ ls -l /tmp/diff*
-    -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:12 /tmp/diff
-    -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:17 /tmp/diff_
-    $ cmp /tmp/diff{,_}; echo $?
-    0
-
-At least it's consistent.  Force a reload:
-
-    # settrans -ag /media/hd1s1
-    # settrans -ag /media/hd1s2
-
-Try again:
-
-    $ diff -x .git -ru /media/hd1s{1,2}/tmp/master/ > /tmp/diff__
-    $ ls -l /tmp/diff*
-    -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:12 /tmp/diff
-    -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:17 /tmp/diff_
-    -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:30 /tmp/diff__
-    $ cmp /tmp/diff{,__}; echo $?
-    0
-
-Consistent; thus very likely corrupt on-disk.
-
-After a few tries, the pattern generally is that for the files where there are
-differences, once the file regularely ends, its content appears once more.
-That is, the files' content appears once (regularely), and then the same again.
-
-Some more copying:
-
-    $ (cd /media/hd1s1/tmp/ && cp -a master master_)
-    $ (cd /media/hd1s2/tmp/ && cp -a master master_)
-    $ diff -x .git -ru /media/hd1s1/tmp/master{,_}/ > /tmp/diff1
-    $ diff -x .git -ru /media/hd1s2/tmp/master{,_}/ > /tmp/diff2
-    $ ls -l /tmp/diff{1,2}
-    -rw-r--r-- 1 thomas thomas 0 10. Jun 19:46 /tmp/diff1
-    -rw-r--r-- 1 thomas thomas 0 10. Jun 19:46 /tmp/diff2
-
-No further difference.
-
-    $ git-new-workdir git master master
-    $ diff -x .git -ur tar_master/ master/ > master.diff
-
-    $ rm -rf ar_master* && (cd git/ && git archive master) | (mkdir ar_master && cd ar_master/ && tar -x) && diff -x .git -ru tar_master/ ar_master/ > ar_master.diff; ls -l ar_master.diff
-    $ (cd git/ && git archive master) | md5sum
-
-
-# 2011-06-13
-
--> [[git-core-2]]
diff --git a/open_issues/git_nfs_mmap.mdwn b/open_issues/git_nfs_mmap.mdwn
deleted file mode 100644
index e6726dfa..00000000
--- a/open_issues/git_nfs_mmap.mdwn
+++ /dev/null
@@ -1,55 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012 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_porting]]
-
-    $ git-new-workdir /media/kepler-data/home/thomas/tmp/source/binutils/git master master
-    fatal: Out of memory? mmap failed: No such device
-    $ echo $?
-    128
-    $ showtrans /media/kepler-data
-    /hurd/nfs kepler.schwinge.homeip.net:/media/data
-
-With `sh -x`:
-
-    [...]
-    + ln -s /media/kepler-data/home/thomas/tmp/source/binutils/git/.git/remotes master/.git/remotes
-    + ln -s /media/kepler-data/home/thomas/tmp/source/binutils/git/.git/rr-cache master/.git/rr-cache
-    + ln -s /media/kepler-data/home/thomas/tmp/source/binutils/git/.git/svn master/.git/svn
-    + cd master
-    + cp /media/kepler-data/home/thomas/tmp/source/binutils/git/.git/HEAD .git/HEAD
-    + git checkout -f master
-    fatal: Out of memory? mmap failed: No such device
-
-As one can easily guess (and confirm with [[hurd/debugging/rpctrace]]), `git`
-tries to [[glibc/mmap]] a file via the [[hurd/translator/nfs]] translator, this
-fails, and it isn't prepared to cope with that:
-
-    [...]
-      88->dir_lookup (".git/objects/pack/pack-37ca560e7877fa0cc6e5ddcd556aa73e5a3e3f40.idx" 2049 0) = 0 3 "/media/kepler-data/home/thomas/tmp/source/binutils/git/.git/objects/pack/pack-37"  (null)
-      62->dir_lookup ("media/kepler-data/home/thomas/tmp/source/binutils/git/.git/objects/pack/pack-37c" 2049 0) = 0 1 "/home/thomas/tmp/source/binutils/git/.git/objects/pack/pack-37ca560e7877fa0cc6e5"   61
-      61->dir_lookup ("home/thomas/tmp/source/binutils/git/.git/objects/pack/pack-37ca560e7877fa0cc6e5d" 2049 0) = 0 1 ""   84
-    task3741-> 3206 (pn{ 33}) = 0
-      84->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID)
-      84->io_stat_request () = 0 {1 704 0 36308992 0 0 -1 33060 1 1000 1000 4712 0 1307711395 0 1307657003 0 1307657003 0 4096 16 0 1000 0 0 100663296 1836017780 29537 0 0 0 0}
-      84->io_map_request () = 0x4000002d (Operation not supported)
-      84->io_map_request () = 0x4000002d (Operation not supported)
-      76->io_write_request ("fatal: Out of memory? mmap failed: No such device
-    " -1) = 0 50
-      64->proc_mark_exit_request (32768 0) = 0
-    task3741-> 2008 () = 0
-    Child 3741 exited with 128
-
-This is the [[libnetfs: `io_map`|open_issues/libnetfs_io_map]] issue.
-
-There is a `NO_MMAP` conditional in Git's source code, but it is a compile-time
-conditional.  The fallback code in `compat/mmap.c:git_mmap` only supports
-`MAP_PRIVATE`, and simply `pread`s in the requested portion of a file.  This
-could be made a runtime fallback, too.
diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn
deleted file mode 100644
index 33041e71..00000000
--- a/open_issues/glibc.mdwn
+++ /dev/null
@@ -1,3422 +0,0 @@
-[[!meta copyright="Copyright © 2007, 2008, 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]]
-
-Here's what's to be done for maintaining glibc.
-
-[[!toc levels=2]]
-
-
-# [[General information|/glibc]]
-
-  * [[Versioning]]
-
-
-# [[Sources|source_repositories/glibc]]
-
-
-# [[Debian Cheat Sheet|debian]]
-
-
-# Configuration
-
-<!--
-
-git checkout reviewed
-git log --reverse --topo-order --pretty=fuller --stat=$COLUMNS,$COLUMNS -b -p -C --cc ..sourceware/master
--i
-/^commit |^merge:|^---$|mach[^i]|hurd|linux|gs:|__assume
-
--->
-
-Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852
-(2013-12-19) sources|source_repositories/glibc]].
-
-  * <a id=t_hurdsig-fixes>`t/hurdsig-fixes`</a>
-
-        hurdsig.c: In function '_hurd_internal_post_signal':
-        hurdsig.c:1188:26: warning: 'pending' may be used uninitialized in this function [-Wmaybe-uninitialized]
-        hurdsig.c:1168:12: note: 'pending' was declared here
-
-  * <a id=t_host-independency>`t/host-independency`</a>
-
-    [[!message-id "87bougerfb.fsf@kepler.schwinge.homeip.net"]], [[!message-id
-    "20120525202732.GA31088@intel.com"]], commit
-    918b56067a444572f1c71b02f18255ae4540b043.  [[!GCC_PR 53183]], GCC commit
-    c05436a7e361b8040ee899266e15bea817212c37.
-
-  * <a id=t_pie-sbrk>`t/pie-sbrk`</a>
-
-    [[gcc/PIE]].
-
-  * <a id=t_sysvshm>`t/sysvshm`</a>
-
-        ../sysdeps/mach/hurd/shmat.c: In function '__shmat':
-        ../sysdeps/mach/hurd/shmat.c:57:7: warning: implicit declaration of function '__close' [-Wimplicit-function-declaration]
-        ../sysdeps/mach/hurd/shmget.c: In function 'get_exclusive':
-        ../sysdeps/mach/hurd/shmget.c:85:8: warning: variable 'is_private' set but not used [-Wunused-but-set-variable]
-        ../sysdeps/mach/hurd/shmget.c:102:8: warning: 'dir' may be used uninitialized in this function [-Wmaybe-uninitialized]
-        ../sysdeps/mach/hurd/shmget.c:102:8: warning: 'file' may be used uninitialized in this function [-Wmaybe-uninitialized]
-
-  * <a id=t_tls>[[`t/tls`|t/tls]]</a>
-
-  * <a id=t_tls-threadvar>[[`t/tls-threadvar`|t/tls-threadvar]]</a>
-
-  * <a id=t_verify.h>`t/verify.h`</a>
-
-    People didn't like this too much.
-
-    Other examples:
-
-      * 11988f8f9656042c3dfd9002ac85dff33173b9bd -- `static_assert`
-
-  * <a id=toolchain_cross-gnu>[[toolchain/cross-gnu]], without `--disable-multi-arch`</a>
-
-        i686-pc-gnu-gcc ../sysdeps/i386/i686/multiarch/strcmp.S -c [...]
-        ../sysdeps/i386/i686/multiarch/../strcmp.S: Assembler messages:
-        ../sysdeps/i386/i686/multiarch/../strcmp.S:31: Error: symbol `strcmp' is already defined
-        make[2]: *** [/media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/string/strcmp.o] Error 1
-        make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc/string'
-
-    Might simply be a missing patch(es) from master.
-
-  * <a id=disable-multi-arch>`--disable-multi-arch`</a>
-
-    IRC, freenode, #hurd, 2012-11-22
-
-        <pinotree> tschwinge: is your glibc build w/ or w/o multiarch?
-        <tschwinge> pinotree: See open_issues/glibc: --disable-multi-arch
-        <pinotree> ah, because you do cross-compilation?
-        <tschwinge> No, that's natively.
-        <tschwinge> There is also a not of what happened in cross-gnu when I
-          enabled multi-arch.
-        <tschwinge> No idea whether that's still relevant, though.
-        <pinotree> EPARSE
-        <tschwinge> s%not%note
-        <tschwinge> Better?
-        <pinotree> yes :)
-        <tschwinge> As for native builds: I guess I just didn't (want to) play
-          with it yet.
-        <pinotree> it is enabled in debian since quite some time, maybe other
-          i386/i686 patches (done for linux) help us too
-        <tschwinge> I though we first needed some CPU identification
-          infrastructe before it can really work?
-        <tschwinge> I thought [...].
-        <pinotree> as in use the i686 variant as runtime automatically? i guess
-          so
-        <tschwinge> I thought I had some notes about that, but can't currently
-          find them.
-        <tschwinge> Ah, I probably have been thinking about open_issues/ifunc
-          and open_issues/libc_variant_selection.
-
-  * <a id=buildX>--build=X</a>
-
-    `long double` test: due to `cross_compiling = maybe` wants to execute a
-    file, which fails.  Thus `--build=X` has to be set.
-
-  * <a id=check>Check what all these are:</a>
-
-        running configure fragment for sysdeps/mach/hurd
-        checking Hurd header version... ok
-        running configure fragment for sysdeps/mach
-        checking for i586-pc-gnu-mig... i586-pc-gnu-mig
-        checking for mach/mach_types.h... yes
-        checking for mach/mach_types.defs... yes
-        checking for task_t in mach/mach_types.h... task_t
-        checking for thread_t in mach/mach_types.h... thread_t
-        checking for creation_time in task_basic_info... yes
-        checking for mach/mach.defs... yes
-        checking for mach/mach4.defs... yes
-        checking for mach/clock.defs... no
-        checking for mach/clock_priv.defs... no
-        checking for mach/host_priv.defs... no
-        checking for mach/host_security.defs... no
-        checking for mach/ledger.defs... no
-        checking for mach/lock_set.defs... no
-        checking for mach/processor.defs... no
-        checking for mach/processor_set.defs... no
-        checking for mach/task.defs... no
-        checking for mach/thread_act.defs... no
-        checking for mach/vm_map.defs... no
-        checking for mach/memory_object.defs... yes
-        checking for mach/memory_object_default.defs... yes
-        checking for mach/default_pager.defs... yes
-        checking for mach/i386/mach_i386.defs... yes
-        checking for egrep... grep -E
-        checking for host_page_size in mach_host.defs... no
-        checking for mach/machine/ndr_def.h... no
-        checking for machine/ndr_def.h... no
-        checking for i386_io_perm_modify in mach_i386.defs... yes
-        checking for i386_set_gdt in mach_i386.defs... yes
-        checking whether i586-pc-gnu-mig supports the retcode keyword... yes
-
-  * <a id=stackguard>`sysdeps/i386/stackguard-macros.h`</a>
-
-    See [[t/tls|t/tls]].
-
-  * <a id=77c84aeb81808c3109665949448dba59965c391e>Verify 77c84aeb81808c3109665949448dba59965c391e against
-    `~/shared/glibc/make_TAGS.patch`.</a>
-
-  * <a id=HP_SMALL_TIMING_AVAIL>`HP_SMALL_TIMING_AVAIL` not defined anywhere.</a>
-
-  * <a id=CPUCLOCK_WHICH>Unify `CPUCLOCK_WHICH` stuff in `clock_*` files.</a>
-
-  * <a id=tests-clean>Not all tests are re-run in a `make -k tests; make tests-clean; make -k
-    tests` cycle.  For example, after `make tests-clean`:</a>
-
-        $ find ./ -name \*.out
-        ./localedata/tst-locale.out
-        ./localedata/sort-test.out
-        ./localedata/de_DE.out
-        ./localedata/en_US.out
-        ./localedata/da_DK.out
-        ./localedata/hr_HR.out
-        ./localedata/sv_SE.out
-        ./localedata/tr_TR.out
-        ./localedata/fr_FR.out
-        ./localedata/si_LK.out
-        ./localedata/tst-mbswcs.out
-        ./iconvdata/iconv-test.out
-        ./iconvdata/tst-tables.out
-        ./stdlib/isomac.out
-        ./posix/wordexp-tst.out
-        ./posix/annexc.out
-        ./posix/tst-getconf.out
-        ./elf/check-textrel.out
-        ./elf/check-execstack.out
-        ./elf/check-localplt.out
-        ./c++-types-check.out
-        ./check-local-headers.out
-        ./begin-end-check.out
-
-  * <a id=t_cpuclock>`CPUCLOCK_WHICH`, `t/cpuclock`</a>
-
-        /media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/rt/librt_pic.a(clock_settime.os): In function `clock_settime':
-        /media/boole-data/thomas/tmp/gnu-0/src/glibc/rt/../sysdeps/unix/clock_settime.c:113: undefined reference to `CPUCLOCK_WHICH'
-        /media/boole-data/thomas/tmp/gnu-0/src/glibc/rt/../sysdeps/unix/clock_settime.c:114: undefined reference to `CPUCLOCK_WHICH'
-        collect2: error: ld returned 1 exit status
-        make[2]: *** [/media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/rt/librt.so] Error 1
-        make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc/rt'
-        make[1]: *** [rt/others] Error 2
-        make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc'
-        make: *** [all] Error 2
-
-  * <a id=missing>Missing Interfaces</a>
-
-    We have posted a [[Google Summer of Code project proposal|community/gsoc]]:
-
-    [[!inline pages="community/gsoc/project_ideas/testsuites" show=0 feeds=no
-    actions=yes]]
-
-    Many are missing for GNU Hurd, some of which have been announced in
-    [`NEWS`](https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS), others
-    typically haven't (like new flags to existing functions).  Typically,
-    porters will notice missing functionaly.  But in case you're looking for
-    something to work on, here's a bit of a commented list, otherwise go
-    looking in `/usr/include/i386-gnu/gnu/stubs.h` on a Debian GNU/Hurd system,
-    or the respective file from a fresh glibc build.
-
-    `AT_EMPTY_PATH`, `CLOCK_BOOTTIME`, `CLOCK_BOOTTIME_ALARM`,
-    `CLOCK_REALTIME_ALARM`, `O_PATH`, `O_TMPFILE`
-    (ffdd31816a67f48697ea4d6b852e58d2886d42ca),
-    `PTRACE_*` (for example, cbff0d9689c4d68578b6a4f0a17807232506ea27,
-    b1b2aaf8eb9eed301ea8f65b96844568ca017f8b,
-    521c6785e1fc94d1f501743e9a40af9e02797df3),
-    `RLIMIT_RTTIME`, `SEEK_DATA` (`unistd.h`), `SEEK_HOLE` (`unistd.h`)
-    `clock_adjtime`, `fallocate`, `fallocate64`, `name_to_handle_at`,
-    `open_by_handle_at`,
-    `posix_openpt`, `process_vm_readv`, `process_vm_writev`,
-    `setns`, `sync_file_range`, [[`mremap`|mremap]] and [[several
-    `MAP_*`|glibc/mmap]]
-
-    Check also the content of `gnu/stubs.h`, which lists all the functions
-    marked as stub which only return `ENOSYS`.
-
-      * <a id=chflags>`chflags`</a>
-
-        Patch sent, [[!message-id "20120427012130.GZ19431@type.famille.thibault.fr"]].
-
-        IRC, OFTC, #debian-hurd, 2012-04-27:
-
-            <Steap> Does anyone have any idea why int main(void) { return
-              chflags(); } will compile with gcc but not with g++ ? It says
-              that "chflags" was not declared in this scope.
-            <Steap> I get the same error on FreeBSD, but including sys/stat.h
-              makes it work
-            <Steap> Can't find a solution on Hurd though :/
-            <youpi> the Hurd doesn't have chflags
-            <youpi> apparently linux neither
-            <youpi> what does it do?
-            <Steap> change flags :)
-            <Steap> Are you sure the Hurd does not have chflags ? Because gcc
-              does not complain
-            <youpi> there is no chflags function in /usr/include
-            <youpi> but what flags does it change?
-            <Steap> According to the FreeBSD manpage, it can set flags such as
-              UF_NODUMP, UF_IMMUTABLE etc.
-            <youpi> Hum, there is actually a chflags() definition
-            <youpi> but no declaration
-            <youpi> so actually chflags is supported, but the declaration was
-              forgotten
-            <youpi> probably because since linux doens't have it, it has never
-              been a problem up to now
-            <youpi> so I'd say ignore the error for now, we'll add the
-              declaration
-
-      * <a id=t_tls-threadvar>[[t/tls-threadvar]]</a>
-
-      * <a id=futimesat>`futimesat`</a>
-
-        If we have all of 'em (check Linux kernel), `#define __ASSUME_ATFCTS`.
-
-      * `futimens`
-
-        IRC, freenode, #hurd, 2014-02-09:
-
-            <youpi> it seems apt 0.9.15.1 has troubles downloading packages
-              etc., as opposed to apt 0.9.15
-            <youpi> ah, that version uses futimens unconditionally
-            <youpi> and we haven't implemented that yet
-            <azeem> did somebody file a bug for that apt-get issue?
-            <youpi> I haven't
-            <youpi> I'll commit the fix in eglibc
-            <youpi> but perhaps a bug report would be good for the kfreebsd
-              case
-
-      * <a id=bits_stat.h>`bits/stat.h [__USE_ATFILE]`: `UTIME_NOW`, `UTIME_OMIT`</a>
-
-      * <a id=__USE_ATFILE>`io/fcntl.h [__USE_ATFILE]`</a>
-
-        Do we support `AT_FDCWD` et al.?
-        (80b4e5f3ef231702b24d44c33e8dceb70abb3a06.)
-
-      * <a id=t_opendirat>`t/opendirat`: `opendirat` (`scandirat`, `scandirat64`)</a>
-
-        Need changes equivalent to c55fbd1ea768f9fdef34a01377702c0d72cbc213 +
-        14d96785125abee5e9a49a1c3037f35a581750bd.
-
-      * <a id=madvise>`madvise`, `MADV_DONTNEED`, `MADV_DONTDUMP`, `MADV_DODUMP`</a>
-
-        [[glibc_madvise_vs_static_linking]].
-
-        IRC, OFTC, #debian-hurd, 2013-09-09:
-
-            <gg0> does hurd MADV_DONTNEED or MADV_FREE or none?
-              http://sources.debian.net/src/jemalloc/3.4.0-1/include/jemalloc/jemalloc_defs.h.in#L239
-            <gg0> seems it builds by defining JEMALLOC_PURGE_MADVISE_DONTNEED
-              but i don't know what i'm talking about, so it could build with
-              JEMALLOC_PURGE_MADVISE_FREE as well
-
-        IRC, OFTC, #debian-hurd, 2013-09-10:
-
-            <youpi> gg0: it implements none, even if it defines DONTNEED (but
-              not FREE)
-
-        See also:
-
-            gnash (0.8.11~git20130903-1) unstable; urgency=low
-            
-              * Git snapshot.
-                + Embedded jemalloc copy has been replaced by system one.
-                  [...]
-                  - Disable jemalloc on hurd and kfreebsd-*. No longer disabled upstream.
-
-      * <a id=msync>`msync`</a>
-
-        Then define `_POSIX_MAPPED_FILES`, `_POSIX_SYNCHRONIZED_IO`.
-
-      * <a id=epoll>`epoll`, `sys/epoll.h`</a>
-
-        Used by [[wayland]], for example.
-
-        IRC, freenode, #hurd, 2013-08-08:
-
-            <nalaginrut> is there any possible to have kquque/epoll alike
-              things in hurd? or there is one?
-            <braunr> nalaginrut: use select/poll
-            <nalaginrut> is it possible to implement epoll?
-            <braunr> it is
-            <braunr> we don't care enough about it to do it
-            <braunr> (for now)
-            <nalaginrut> well, since I wrote a server with Guile, and it could
-              take advantage of epoll, never mind, if there's no, it'll use
-              select automatically
-            <nalaginrut> but if someday someone care about it, I'll be
-              interested on it
-            <braunr> epoll is a scalability improvement over poll
-            <braunr> the hurd being full of scalability issues, this one is
-              clearly not a priority
-            <nalaginrut> ok
-
-        IRC, freenode, #hurd, 2013-09-26:
-
-            <nalaginrut> if I want to have epoll/kqueue like things, where
-              should it dwell? kernel or some libs?
-            <braunr> libs
-            <pinotree> userland
-            <braunr> that would be a good project to work on, something i
-              intended to do (so i can help) but it requires a lot of work
-            <braunr> you basically need to add a way to explicitely install and
-              remove polling requests (instead of the currently way that
-              implicitely remove polling requests when select/poll returns)
-            <braunr> while keeping the existing way working for some time
-            <braunr> glibc implements select
-            <braunr> the hurd io interface shows the select interface
-            <braunr> servers such as pfinet/pflocal implement it
-            <braunr> glibc implements the client-side of the call
-            <nalaginrut> where's poll? since epoll just added edge-trigger in
-              poll
-            <braunr> both select and poll are implemented on top of the hurd io
-              select call (which isn't exactly select)
-            <braunr>
-              http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/blob/HEAD:/hurd/io.defs
-            <braunr> this is the io interface
-            <braunr>
-              http://darnassus.sceen.net/gitweb/savannah_mirror/glibc.git/blob/refs/heads/tschwinge/Roger_Whittaker:/hurd/hurdselect.c
-            <braunr> this is the client side implementation
-
-        IRC, freenode, #hurd, 2014-02-14:
-
-            <desrt> also: do you know if hurd has a modern-day poll()
-              replacement? ala epoll, kqueue, iocp, port_create(), etc?
-            <pochu_> last thing I remember was that there was no epoll
-              equivalent, but that was a few years ago :)
-            <pochu_> braunr: ^
-            * desrt is about to replace gmaincontext in glib with something
-                more modern
-            * desrt really very much wants not to have to write a poll()
-                backend....
-            <desrt> it seems that absolutely every system that i care about,
-              except for hurd, has a new approach here :/
-            <desrt> even illumos has solaris-style ports
-            <azeem> desrt: I suggest you bring up the question on bug-hurd
-            <azeem> the poll() system call there to satisfy POSIX, but there
-              might be a better Hurd-specific thing you could use
-            <azeem> is there*
-            <desrt> that would be ideal
-            <desrt> i have to assume that a system that passes to many messages
-              has some other facilities :)
-            <desrt> *so many
-            <desrt> the question is if they work with fds....
-            <desrt> bug-hurd doesn't seem like a good place to ask open-ended
-              questions....
-            <azeem> it's the main development lists, it's just old GNU naming
-            <azeem> list*
-            <desrt> k.  thanks.
-            <azeem> bug-hurd@gnu.org is the address
-            * desrt goes to bug... hurd
-            <desrt> written.  thanks.
-            <braunr> desrt: the hurd has only select/poll
-            <braunr> it suffers from so many scalability issues there isn't
-              much point providing one currently
-            <braunr> we focus more on bug fixing and posix compliance right now
-            <desrt> fair answer
-            <braunr> you should want a poll-based backend
-            <braunr> it's the most portable one, and doesn't suck as much as
-              select
-            <braunr> very easy to write
-            <braunr> although, internally, our select/poll works just like a
-              bare epoll
-            <braunr> i.e. select requests are installed, the client waits for
-              one or more messages, then uninstalls the requests
-
-        IRC, freenode, #hurd, 2014-02-23:
-
-            <desrt> brings me to another question i asked here recently that
-              nobody had a great answer for: any plan to do kqueue?
-            <braunr> not for now
-            <braunr> i remember answering you about that
-            <desrt> ah.  on IRC or the list?
-            <braunr> that internally, our select/poll implementation works just
-              like epoll
-            <braunr> on irc
-            <braunr> well "just like" is a bit far from the truth
-            <desrt> well... poll() doesn't really work like epoll :p
-            <braunr> internally, it does
-            <braunr> even on linux
-            <desrt> since both of us have to do the linear scan on the list
-            <desrt> which is really the entire difference
-            <braunr> that's the user interface part
-            <braunr> i'm talking about the implementation
-            <desrt> ya -- but it's the interface that makes it unscalable
-            <braunr> i know
-            <braunr> what i mean is
-            <braunr> since the implementation already works like a more modern
-              poll
-            <braunr> we could in theory add such an interface
-            <braunr> but epoll adds some complicated detail
-            <desrt> you'll have to forgive me a bit -- i wasn't around from a
-              time that i could imagine what a non-modern poll would look like
-              inside of a kernel :)
-            <braunr> what i mean with a modern poll is a scalable poll-like
-              interface
-            <braunr> epoll being the reference
-            * desrt is not super-crazy about the epoll interface....
-            <braunr> me neither
-            <desrt> kevent() is amazing -- one syscall for everything you need
-            <braunr> i don't know kqueue enough to talk about it
-            <desrt> no need to do 100 epollctls when you have a whole batch of
-              updates to do
-            <desrt> there's two main differences
-            <desrt> first is that instead of having a bunch of separate fds for
-              things like inotify, timerfd, eventfd, signalfd, etc -- they're
-              all built in as different 'filter' types
-            <desrt> second is that instead of a separate epoll_ctl() call to
-              update the list of monitored things, the kevent() call
-              (epoll_wait() equivalent) takes two lists: one is the list of
-              updates to make and the other is the list of events to
-              return.... so you only do one syscall
-            <braunr> well, again, that's the interface
-            <braunr> internally, there still are updates and waits
-            <braunr> and on a multiserver system like the hurd, this would mean
-              one system call per update per fd
-            <braunr> and then one per wait
-            <desrt> on the implementation side, i think kqueue also has a nice
-              feature: the kernel somehow has some magic that lets it post
-              events to a userspace queue.... so if you're not making updates
-              and you do a kevent() that would not block, you don't even enter
-              the kernel
-            <braunr> ok
-            <desrt> hm.  that's an interesting point
-            <desrt> "unix" as such is just another server for you guys, right?
-            <braunr> no
-            <braunr> that's a major difference between the hurd and other
-              microkernel based systems
-            <braunr> even multiserver ones like minix
-            <braunr> we don't have a unix server
-            <braunr> we don't have a vfs server or even an "fd server"
-            <desrt> so mach knows about things like fds?
-            <braunr> no
-            <braunr> only glibc
-            <desrt> oh.  weird!
-            <braunr> yes
-            <braunr> that's the hurd's magic :)
-            <braunr> being so posix compliant despite how exotic it is
-            <desrt> this starts to feel like msvcrt :p
-            <braunr> maybe, i wouldn't know
-            <braunr> windows is a hybrid after all
-            <braunr> with multiple servers for its file system
-            <braunr> so why not
-            <braunr> anyway
-            <desrt> so windows doesn't have fds in the kernel either... the C
-              library runtime emulates them
-            <braunr> mach has something close to file descriptors
-            <desrt> which is fun when you get into dll hell -- sometimes you
-              have multiple copies of the C library runtime in the same program
-              -- and you have to take care not to use fds from one of them with
-              th o ther one
-            <braunr> yes ..
-            <braunr> that, i knew :)
-            <braunr> but back to the hurd
-            <braunr> since fds are a glibc thing here, and because "files" can
-              be implemented by multiple servers
-            <braunr> (sockets actually most of the time with select/poll)
-            <braunr> we have to make per fd requests
-            <braunr> the implementation uses the "port set" kernel abstraction
-            <desrt> right -- we could have different "fd" coming from different
-              places
-            <braunr> do you know what a mach port is ?
-            <desrt> not even a little bit
-            <braunr> hm
-            <desrt> i think it's what a plane does when it goes really fast,
-              right?
-            <braunr> let's say it's a kernel message queue
-            <braunr> no it's not a sonic boom
-            <desrt> :)
-            <braunr> ;p
-            <braunr> so
-            <braunr> ports are queues
-            <desrt> (aside: i did briefly run into mach ports recently on macos
-              where they modified their kqueue to support them...)
-            <braunr> queues of RPC requests usually
-            <desrt> (but i didn't use them or look into them at all)
-            <braunr> they can be referenced through mach port names, which are
-              integers much like file descriptors
-            <braunr> they're also used for replies but, except for weird calls
-              like select/poll, you don't need to know that :)
-            <braunr> a port set is one object containing multiple ports
-            <desrt> sounds like dbus :)
-            <braunr> the point of a port set is to provide the ability to
-              perform a single operation (wait for a message) on multiple ports
-            <desrt> sounds like an epoll fd....
-            <desrt> is the port set itself a port?
-            <braunr> so, when a client calls select, it translates the list of
-              fds into port names, creates reply ports for each of them, puts
-              them into a port set, send one select request for each, and does
-              one blocking wait on the port set
-            <braunr> no, but you can wait for a message on a port set the same
-              way you do on a port
-            <braunr> and that's all it does
-            <desrt> does that mean that you can you put a port set inside of
-              another port set?
-            <braunr> hm maybe
-            <desrt> i guess in some way that doesn't actually make sense
-            <braunr> i guess
-            <desrt> because i assume that the message you sent to each port in
-              your example is "tell me when you have some stuff"
-            <braunr> yes
-            <desrt> and you'd have to send an equivalent message to the port
-              set.... and that just doesn't make sense
-            <desrt> since it's not really a thing, per se
-            <braunr> it would
-            <braunr> insteaf of port -> port set, it would just be port -> port
-              set -> port set
-            <braunr> but we don't have any interface where an fd stands for a
-              port set
-            <braunr> what i'm trying to tell here is that
-            <braunr> considering how it's done, you can easily see that there
-              has to be non trivial communication
-            <braunr> each with the cost of a system call
-            <braunr> and not just any system call, a messaging one
-            <braunr> mach is clearly not as good as l4 when it comes to that
-            <desrt> hrmph
-            <braunr> and the fact that most pollable fds are either unix or
-              inet/inet6 sockets mean that there will be contention in the
-              socket servers anyway
-            <desrt> i've seen some of the crazy things you guys can do as a
-              result of the way mach works and way that hurd uses it, in
-              particular
-            <desrt> normal users setting up little tcp/ip universes for
-              themselves, and so on
-            <braunr> yes :)
-            <desrt> but i guess this all has a cost
-            <braunr> the cost here comes more from the implementation than the
-              added abstractions
-            <braunr> mach provides async ipc, which can partially succeed
-            <desrt> if i spin up a subhurd, it's using the same mach, right?
-            <braunr> yes
-            <desrt> that's neat
-            <braunr> we tend to call them neighbour hurds because of that
-            <braunr> i'm not sure it is
-            <desrt> it puts it half way between linux containers and outright
-              VMs
-            <desrt> because you have a new kernel.... ish...
-            <braunr> well, it is for the same reasons hypervisors are neat
-            <desrt> but the kernel exists within this construct....
-            <braunr> a new kernel ?
-            <desrt> a new hurd
-            <braunr> yes
-            <desrt> but not a new mach
-            <braunr> exactly
-            <desrt> ya -- that's very cool
-            <braunr> it's halfway between hypervisors and containers/jails
-            <braunr> what matters is that we didn't need to write much code to
-              make it work
-            <braunr> and that the design naturally guarantees strong isolation
-            <desrt> right.  that's what i'm getting at
-            <braunr> unlike containers
-            <desrt> it shows that the interaction between mach and these set of
-              crazy things collectively referred to as the hurd is really
-              proper
-            <braunr> usually
-            <braunr> sometimes i think it's not
-            <braunr> but that's another story :)
-            <desrt> don't worry -- you can fix it when you port to L4 ;)
-            <braunr> eh, no :)
-            <desrt> btw: is this fundamentally the same mach as darwin?
-            <braunr> yes
-            <desrt> so i guess there are multiple separate implementations of a
-              standard set of interfaces?
-            <braunr> ?
-            * desrt has to assume that apple wouldn't be using GNU mach, for
-                example...
-            <braunr> no it's the same code base
-            <braunr> they couldn't
-            <braunr> but only because the forks have diverged a bit
-            <desrt> ah
-            <braunr> and they probably changed a lot of things in their virtual
-              memory implementation
-            <desrt> so i guess original mach was under some BSDish type thing
-              and GNU mach forked from that and started adding GPL code?
-            <braunr> something like that
-            <desrt> makes sense
-            <braunr> we have very few "non-standard" mach interfaces
-            <braunr> but we now rely on them so we couldn't use another mach
-              either
-            <braunr> back to the select/poll stuff
-            * desrt gets a lesson tonight :)
-            <braunr> it costs, it's not scalable
-            <braunr> but
-            <braunr> we have scalability problems in our servers
-            <braunr> they're old code, they use global locks
-            <desrt> right.  this is the story i heard last time.
-            <braunr> probably from me
-            <braunr> poll works good enough for us right now
-            <braunr> we're more interested in bug fixes than scalability
-              currently
-            <desrt> the reason this negative impacts me is because now i need
-              to write a bunch more code ;p
-            <braunr> i hope this changes but we still get weird errors that
-              many applications don't expect and they react badly to those
-            <braunr> well, poll really is the posix fallback
-            <desrt> every other OS that we want to support has some sort of new
-              scalable epoll-type interface or is Windows (which needs separate
-              code anyway)
-            <desrt> a very large number of them have kqueue... linux has
-              epoll... solaris/illumos is the odd one out with this weird thing
-              that's sort of like epoll
-            <braunr> i would think you want a posix fallback for such a
-              commonly used interface
-            <braunr> hm
-            <desrt> braunr: hurd is pretty much the only one that doesn't
-              already have something better....
-            <braunr> linux can be built without epoll
-            <desrt> and the nice thing about all of these things is that every
-              single one of them gives me an fd that can be polled when any
-              event is ready
-            <braunr> i don't see why anyone would do that, but it's a compile
-              time option ;p
-            <braunr> yes ...
-            <braunr> we don't have xxxfd() :)
-            <desrt> and we want to expose that fd on our API... so people can
-              chain gmaincontext into other mainloops
-            <braunr> that's expected
-            <desrt> so for hurd this means that i will need to spin up a
-              separate thread doing poll() and communicating back to the main
-              thread when anything becomes ready
-            <desrt> i was looking forward to not having to do that :)
-            <braunr> it matches the unix "everything is a file" idea, and
-              windows concept of "events"
-            <braunr> i understand but again, it's a posix fallback
-            <braunr> you probably want it anyway
-            <desrt> probably
-            <braunr> it could help new systems trying to be posix like
-            <desrt> i honestly thought i'd get away with it, though
-            <desrt> this is true...
-            <desrt> CLOCK_MONOTONIC is an easy enough requirement to implement
-              or fake.... "modern event polling framework" is another story...
-
-        [[clock_gettime]].
-
-            <braunr> yes, but again, we do have the underlying machinery to add
-              it
-            <desrt> i appreciate if your priorities are elsewhere ;)
-            <braunr> it's just not worth the effort right now
-            <braunr> although we do have performance and latency improvements
-              in our patch queues currently
-            <braunr> if our network stack gets replaced, it would become
-              interesting
-            <braunr> we need to improve posix compliance first
-            <braunr> make more applications not choke on unecpected errors
-            <braunr> and then we can think of improving scalability
-            <desrt> +1 vote from me for implementing monotonic time :)
-            <desrt> (and also pthread_condattr_setclock())
-            <braunr> and we probably won't implement the epoll interface ;p
-            <braunr> yes
-            <desrt> it's worth noting that there is also a semi-widely
-              available non-standard extension called
-              pthread_cond_timedwait_relative_np that you could implement
-              instead
-            <desrt> it takes a (relative) timeout instead of an absolute one --
-              we can use that if it's available
-            <braunr> desrt: why would you want relative timeouts ?
-            <desrt> braunr: if you're willing to take the calculations into
-              your own hands and you don't have another way to base it on
-              monotonic time it starts to look like a good alternative
-            <desrt> and indeed, this is the case on android and macos at least
-            <braunr> hm
-            <desrt> not great as a user-facing API of course.... due to the
-              spurious wakeup possibility and need to retry
-            <braunr> so it's non standard alternative to a monotonic clock ?
-            <desrt> no -- these systems have monotonic clocks
-            <desrt> what they lack is pthread_condattr_setclock()
-            <braunr> oh right
-            <desrt> which is documented in POSIX but labelled as 'optional'
-            <braunr> so relative is implicitely monotonic
-            <desrt> yes
-            <desrt> i imagine it would be the same 'relative' you get as the
-              timeout you pass to poll()
-            <desrt> since basing anything like this on wallclock time is
-              absolutely insane
-            <desrt> (which is exactly why we refuse to use wallclock time on
-              our timed waits)
-            <braunr> sure
-            <braunr> i'm surprised clock_monotonic is even optional in posix
-              2008
-            <braunr> but i guess that's to give some transition margin for
-              small embedded systems
-            <desrt> when you think about it, CLOCK_REALTIME really ought to
-              have been the optional feature
-            <desrt> monotonic time is so utterly basic
-            <braunr> yes
-            <braunr> and that's how it's normally implemented
-            <braunr> kernels provide a monotonic clock, and realtime is merely
-              shifted from it
-
-      * <a id=sys_eventfd.h>`sys/eventfd.h`</a>
-
-      * <a id=sys_inotify.h>`sys/inotify.h`</a>
-
-      * <a id=sys_signalfd.h>`sys/signalfd.h`</a>
-
-      * <a id=sys_timerfd.h>`sys/timerfd.h`</a>
-
-      * <a id=timespec_get>`timespec_get` (74033a2507841cf077e31221de2481ff30b43d51,
-        87f51853ce3671f4ba9a9953de1fff952c5f7e52)</a>
-
-      * <a id=waitflags.h>`waitflags.h` (`WEXITED`, `WNOWAIT`, `WSTOPPED`, `WCONTINUED`)</a>
-
-        IRC, freenode, #hurd, 2012-04-20:
-
-            <pinotree> in glibc, we use the generic waitflags.h which, unlike
-              linux's version, does not define WEXITED, WNOWAIT, WSTOPPED,
-              WCONTINUED
-            <pinotree> should the generic bits/waitflags.h define them anyway,
-              since they are posix?
-            <youpi> well, we'd have to implement them anyway
-            <youpi> but otherwise, I'd say yes
-            <pinotree> sure, but since glibc headers should expose at least
-              everything declared by posix, i thought they should be defined
-              anyway
-            <youpi> that might bring bugs
-            <youpi> some applications might be #ifdefing them
-            <youpi> and break when they are defined but not working
-            <pinotree> i guess they would define them to 0, andd having them to
-              non-zero values shouldn't break them (since those values don't do
-              anything, so they would act as if they were 0.. or not?)
-            <youpi> no, I mean they would do something else, not define them to
-              0
-            <pinotree> like posix/tst-waitid.c, you mean?
-            <youpi> yes
-
-        See `posix/tst-waitid.out` failure below.
-
-      * <a id=getconf>`getconf` things (see below the results of `tst-getconf.out`)</a>
-
-      * <a id=getsockopt>`getsockopt`, `setsockopt`</a>
-
-        IRC, freenode, #hurd, 2013-02-14
-
-            <gnu_srs> Hi, {get,set}sockopt is not supported on Hurd. This shows
-              e.g. in the gnulib's test-{poll,select} code.
-            <gnu_srs> Reading
-              http://hea-www.harvard.edu/~fine/Tech/addrinuse.html there might
-              be reasons _not_ to implement them, comments?
-            <pinotree> uh? they are supported on hurd
-            <gnu_srs> not  SO_REUSEPORT for setsockopt()
-            <pinotree> that isn't the same as claiming "get/setsockopt is not
-              supported on hurd"
-            <pinotree> most probably that option is not implemented by the
-              socket family you are using
-            <gnu_srs> OK, some options like  SO_REUSEPORT then, more info in
-              the link.
-            <pinotree> note also SO_REUSEPORT is not posix
-            <pinotree> and i don't see SO_REUSEPORT mentioned in the page you
-              linked
-            <gnu_srs> No, but SO_REUSEADDR
-
-        IRC, freenode, #hurd, 2013-02-23
-
-            <gnu_srs> as an example, the poll test code from gnulib fails due
-              to that problem (and I've told you before)
-            <pinotree> gnu_srs: what's the actual failure?
-            <pinotree> can you provide a minimal test case showing the issue?
-            <gnu_srs> pinotree: A smaller test program:
-              http://paste.debian.net/237495/
-            <pinotree> gnu_srs: setting SO_REUSEADDR before binding the socket
-              works...
-            <pinotree> and it seems it was a bug in the gnulib tests, see
-              http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=6ed6dffbe79bcf95e2ed5593eee94ab32fcde3f4
-            <gnu_srs> pinotree: You are right, still the code I pasted pass on
-              Linux, not on Hurd.
-            <pinotree> so?
-            <pinotree> the code is wrong
-            <pinotree> you cannot change what bind does after you have called
-              it
-            * pinotree → out
-            <gnu_srs> so linux is buggy?
-            <braunr> no, linux is more permissive
-            <braunr> (at least, on this matter)
-
-      * <a id=getcontext>`getcontext`/`makecontext`/`setcontext`/`swapcontext`</a>
-
-        Support for these functions within the Hurd threadvar environment has
-        been added, but for multi-threaded applications ([[libpthread]]), it is
-        a bit clunky: as a practical requirement, a thread's stack size always
-        has to be equal to `PTHREAD_STACK_DEFAULT`, 2 MiB, and also has to be
-        naturally aligned.  The idea is still to [[get rid of Hurd threadvars
-        and replace them with TLS|t/tls-threadvar]].
-
-        Aside from [[gccgo]], the following packages might make use of these
-        functions, searching on <http://codesearch.debian.net/> for
-        `\b(get|set|make|swap)context\s*\(` on 2013-05-18: boost1.49,
-        chromium-browser, gtk-vnc, guile-1.8, iceape, icedove, iceweasel,
-        libgc, libsigsegv, luatex, mono, nspr, pth, ruby1.8, texlive-bin, uim,
-        and more.
-
-        IRC, OFTC, #debian-hurd, 2013-09-08:
-
-            <pinotree> oh, and even ruby2.0 suffers because of fixed-stack
-              threads
-            <youpi> yes, we definitely need to finish fixing it
-            <youpi> my current work is in our glibc repo, youpi/tls-threadvar
-            <pinotree> | *** makecontext: a stack at 0xbc000 with size 0x40000
-              is not usable with threadvars
-            <pinotree> all 8 failing tests with that
-            <youpi> maybe we can hand-disable the use of contexts in ruby for
-              now?
-            <pinotree> gg0: ↑ :)
-            <gg0> after the pseudo-patch i RFCed, i don't deserve to say
-              anything else about that :)
-            <pinotree> i mean, feel free to investigate and "fix" ruby2.0 as
-              above :)
-            <gg0> eh maybe i'd just be able to hand-disable failing
-              thread-related _tests_ :)
-            <gg0> i'm still hoping some real developer picks and actually fixes
-              it, seems it's not enough interesting though
-            <azeem> 21:37 < youpi> yes, we definitely need to finish fixing it
-            <gg0> afaiu youpi is working on threadvars-tls migration, which
-              would mean fixing them all. i just meant fixing ruby, which would
-              mean having puppet btw
-            <youpi> gg0: "actually fixing" means fixing threadvars-tls
-              migration
-            <youpi> "just fixing" ruby can be done by simply disabling context
-              use in ruby
-
-        IRC, OFTC, #debian-hurd, 2013-09-10:
-
-            <gg0> this one fixes make test by disabling context and giving more
-              time to timing related tests http://paste.debian.net/plain/37977/
-            <gg0> make test-all is another story
-            <youpi> gg0: AIUI, the sleep part should get fixed by the next
-              glibc upload, which will include the getclk patch
-            <youpi> but the disabling context part could be good to submit to
-              the debian ruby package, mentioning that this is a workaround for
-              now
-            <gg0> unfortunately still not enough, test-all still fails
-            <youpi> does it make the package not build?
-            <gg0> test-all is the second part of what we call tests
-            <gg0> they build and package (they produce all ruby packages),
-              after that they run debian/run-test-suites.bash which is make
-              test + make test-all
-            <gg0> well after or during the build doesn't matter, it's their
-              testsuite
-            <gg0> ok just failed:
-            <gg0> TestBug4409#test_bug4409 = Illegal instruction
-            <gg0> make: *** [yes-test-all] Error 132
-            <gg0> what to do with Illegal instruction?
-            <gg0> just found 2 words that make everybody shut up :p
-            <pinotree> same as above: debug it
-            <teythoon> gg0: have you confirmed that this is reproducible? I've
-              once had a process die with SIGILL and it was not and I figured
-              it might have been a (qemu?) glitch
-            <gg0> seems i'm running tests which are disabled on _all_ archs,
-              better so
-            <gg0> well, this should be reproducible. i just got it on a qemu, i
-              could try to reproduce it on real hardware but as just said, i
-              was testing tests disabled by maintainer so completely useless
-            <teythoon> gg0: yeah, I'm running all my hurd instances on qemu/kvm
-              as well, I meant did you get this twice in a row?
-            <gg0> to be honest i got another illegal instruction months ago but
-              don't recall doing what
-            <gg0> nope not twice, i've commented it out. then run the remaining
-              and then found out i should not have done what i was doing
-            <gg0> but i could try to reproduce it
-            <gg0> ok now i recall i got it another one few hours ago on real
-              hardware, from logs:
-            <gg0> TestIO#test_copy_stream_socket = Illegal instruction
-            <gg0> teythoon: on real hardware though
-            <gg0> and this is the one i should debug once it finishes, still
-              running
-
-        IRC, freenode, #hurd, 2013-09-11:
-
-            <gg0_> ../sysdeps/mach/hurd/jmp-unwind.c:53: _longjmp_unwind:
-              Assertion `! __spin_lock_locked (&ss->critical_section_lock)'
-              failed.
-            <gg0_> and
-            <gg0_> ../libpthread/sysdeps/mach/pt-thread-halt.c:51:
-              __pthread_thread_halt: Unexpected error: (ipc/send) invalid
-              destination port.
-            <tschwinge> gg0_: Which libpthread source are these?  Stock Debian
-              package?
-            <gg0_> tschwinge: everything debian, ruby rebuilt with
-              http://paste.debian.net/plain/38519/ which should disable
-              *context
-
-        IRC, OFTC, #debian-hurd, 2013-09-11:
-
-            <gg0_> wrt ruby, i'd propose a patch that disables *context and
-              comments out failed tests (a dozen). most of them are timing
-              related, don't always fail
-            <gg0_> if they failed gracefully, we could leave them enabled and
-              just ignoring testsuite result, but most of them block testsuite
-              run when fail
-            <gg0_> anyone against? any better idea (and intention to implement
-              it? :p)?
-            <gg0_> youpi: is disabling some tests acceptable? ^
-            <youpi> it'd be good to at least know what is failing
-            <youpi> so as to know what impact hiding these failures will have
-            <youpi> remember that hiding bugs usually means getting bitten by
-              them even harder later :)
-            <gg0_> many of them use pipes
-            <gg0_> here the final list, see commented out ones
-              http://paste.debian.net/plain/38426
-            <gg0_> and as said some don't always fails
-            <gg0_> test_copy_stream_socket uses a socket
-            <youpi> note that we can still at least build packages with notest
-            <youpi> at least to get the binaries uploaded
-            <youpi> disabling *context should however really be done
-            <youpi> and the pipe issues are concerning
-            <youpi> I don't remember other pipe issues
-            <youpi> so maybe it's a but in the ruby bindings
-            <gg0_> i just remember they didn't die, then something unknown
-              fixed it
-            <youpi> I see something frightening in io.c
-            <youpi> #if BSD_STDIO
-            <youpi>          preserving_errno(fseeko(f, lseek(fileno(f),
-              (off_t)0, SEEK_CUR), SEEK_SET));
-            <youpi> #endif
-            <youpi> this looks very much like a workaround for an odd thing in
-              BSD
-            <youpi> it happens that that gets enabled on hurd too, since
-              __MACH__ is defined
-            <youpi> you could try to drop these three lines, just to see
-            <youpi> this is very probably very worth investigating, at any rate
-            <youpi> even just test_gets_limit_extra_arg is a very simple test,
-              that I fail to see why it should ever fail on hurd-i386
-            <youpi> starting debugging it would be a matter of putting printfs
-              in io.c, to check what gets called, with what parameters, etc.
-            <youpi> just a matter of taking the time to do it, it's not very
-              complex
-            <gg0_> youpi: are you looking at 1.8? no BSD_STDIO here
-            <youpi> yes, 1.8
-            <gg0_> 1.9.3.448
-            <gg0_> landed to sid few days ago
-            <youpi> ah, I have 1.87
-            <youpi> +.
-            <gg0_> my favourites are TestIO#test_copy_stream_socket and
-              TestIO#test_cross_thread_close_fd -> Illegal instruction
-            <gg0_> TestIO#test_io_select_with_many_files sometimes Illegal
-              instruction, sometimes ruby1.9.1:
-              ../sysdeps/mach/hurd/jmp-unwind.c:53: _longjmp_unwind: Assertion
-              `! __spin_lock_locked (&ss->critical_section_lock)' failed.
-
-        [[thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock]]?
-
-            <gg0_> trying to debug illegal instruction
-              http://paste.debian.net/plain/38585/
-            <gg0_> (yes, i'm not even good at gdbing)
-            <gg0_> any hint?
-            <gg0_> oh found out there's an intree .gdbinit, that might
-              complicate things
-
-        IRC, OFTC, #debian-hurd, 2013-09-13:
-
-            <gg0_> where should it be implemented MAP_STACK? plus, is it worth
-              doing it considering migration to tls, wouldn't it be useless?
-            <gg0_> sysdeps/mach/hurd/mmap.c i should reduce stupid questions
-              frequency from daily to weekly basis
-
-        IRC, OFTC, #debian-hurd, 2013-09-14:
-
-            <gg0_> say i managed to mmap 0x200000-aligned memory
-            <gg0_> now i get almost the same failed tests i get disabling
-              *context
-            <gg0_> that would mean they don't depend on threading
-
-        IRC, freenode, #hurd, 2013-09-16:
-
-            <gg0> i get many ../sysdeps/mach/hurd/jmp-unwind.c:53:
-              _longjmp_unwind: Assertion `! __spin_lock_locked
-              (&ss->critical_section_lock)' failed.
-            <gg0> by running ruby testsuite, especially during test_read* tests
-              http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L972
-            <gg0> read/write operations with pipes
-            <braunr> gg0: that's weird
-            <braunr> gg0: debian glibc ?
-            <gg0> braunr: yep, debian 2.17-92
-            <gg0> sometimes assertion above, sometimes tests in question get
-              stuck reading
-            <gg0> it would be nice reproducing it w/o ruby
-            <gg0> probably massive io on pipes could do the job
-            <gg0> also more nice finding someone who finds it interesting to
-              fix :p
-            <gg0> ruby is rebuilt with http://paste.debian.net/plain/40755/, no
-              *context
-            <gg0> pipe function in tests above creates one thread for write,
-              one for read
-              http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L26
-            <tschwinge> gg0: About the jmp-unwind assertion failure: is it be
-              chance this issue:
-              <http://www.gnu.org/software/hurd/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.html>?
-              I didn't look in detail.
-            <braunr> tschwinge: that's what i thought too about the assertion,
-              which is why i find it strange
-            <gg0> asserting it's not locked then locking it doesn't exclude
-              race conditions
-
-        IRC, OFTC, #debian-hurd, 2013-09-17:
-
-            <gg0> youpi: i guess no one saw it anymore since
-              tg-thread-cancel.diff patch
-            <gg0> it =
-              http://www.gnu.org/software/hurd/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.html
-            <gg0> this one comes from sysdeps/mach/hurd/jmp-unwind.c:53 though
-            <gg0> another assertion to remove?
-            <youpi> gg0: it's not exactly the same: in hurd_thread_cancel we
-              hold no lock at all at the assertion point
-            <youpi> in jmp-unwind.c, we do hold a lock
-            <youpi> and the assertion might be actually true because all other
-              threads are supposed to hold the first lock before taking the
-              other one
-            <youpi> you could check for that in other places
-            <youpi> and maybe it's the other place which wouldhave to be fixed
-            <youpi> also look for documentation which would say that
-
-        IRC, freenode, #hurd, 2013-09-17:
-
-            <braunr_> gg0: is that what we do ??
-            <gg0> braunr: well, i was looking at
-              http://sources.debian.net/src/eglibc/2.17-92/debian/patches/hurd-i386/tg-thread-cancel.diff
-            <gg0> which afaics fixes
-              http://www.gnu.org/software/hurd/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.html
-            <gg0> the one i get now is
-              http://sources.debian.net/src/eglibc/2.17-92/sysdeps/mach/hurd/jmp-unwind.c#L53
-            <gg0> 09:12 < youpi> gg0: it's not exactly the same: in
-              hurd_thread_cancel we hold no lock at all at the assertion point
-            <gg0> 09:13 < youpi> in jmp-unwind.c, we do hold a lock
-            <gg0> 09:13 < youpi> and the assertion might be actually true
-              because all other threads are supposed to hold the first lock
-              before taking the other one
-            <braunr> gg0: that assertion is normal
-            <braunr> it says there is a deadlock
-            <braunr> ss->critical_section_lock must be taken before ss->lock
-            <gg0> you mean ss->lock before ss->critical_section_lock
-            <braunr> no
-            <gg0> ah ok got it
-            <braunr> that's a bug
-            <braunr> longjmp
-            <braunr> ugh
-            <braunr> you could make a pass through the various uses of those
-              locks and check what the intended locking protocol should be
-            <braunr> i inferred ss->critical_section_lock before ss->lock from
-              hurd_thread_cancel
-            <braunr> this might be wrong too but considering this function is
-              used a lot, i doubt it
-            <gg0> (no, i hadn't got it, i was looking at jmp-unwind.c where
-              lock is before critical_section_lock)
-            <gg0> could we get useful info from gdb'ing the assertion?
-            <tschwinge> gg0: Only if you first get an understanding why it is
-              happening, what you expect to happen instead/why it shall not
-              happen/etc.  Then you can perhaps use GDB to verify that.
-            <gg0> i can offer an irc interface if anyone is interested, it's
-              ready, just to attach :)
-            <gg0> this is the test
-              http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L937
-            <gg0> pipe function creates two threads
-              http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L26
-            <gg0> Attaching to pid 15552
-            <gg0> [New Thread 15552.1]
-            <gg0> [New Thread 15552.2]
-            <gg0> (gdb) 
-
-        IRC, freenode, #hurd, 2013-09-21:
-
-            <youpi> gg0: it seems the assert (! __spin_lock_locked
-              (&ss->critical_section_lock)); is bogus
-            <youpi> but it'd be good to catch a call trace
-            <youpi> well, it may not be bogus, in case that lock is only ever
-              taken by the thread itself
-            <youpi> in that case, inside longjmp_unwind we're not supposed to
-              have it already
-            <youpi> ok, that's what we had tried to discuss with Roland
-            <youpi> it can happen when playing with thread cancelation
-            <braunr> youpi: the assertion isn't exactly bogus
-            <braunr> the lock ordering is
-            <youpi> braunr: which one are you talking about?
-            <youpi> the one in hurd_thread_cancel looks really wrong
-            <youpi> and some parts of the code keep the critical section lock
-              without ss->lock held, so I don't see how lock ordering can help
-
-        IRC, OFTC, #debian-hurd, 2013-09-22:
-
-            <gg0> how much does this patch suck on a scale from 1 to 10?
-              http://paste.debian.net/plain/44810/
-            <youpi> well, the stack allocation issue will go away once I get
-              the threadvars away
-            <youpi> I'm working on it right now
-            <youpi> about the lib paths, it makes sense to add the gnu case,
-              but i386-gnu shouldn't be put in the path
-            <gg0> that's great
-            <gg0> so seems the wrong moment for what i've already done
-              ie. asking terceiro what he thinks about patch above :/
-            <gg0> any distro-independent way to get libc.so and libm.so path?
-            <gg0> ruby as last resource takes them from "ldd ruby"
-            <pinotree> gg0: should work fine then
-            <gg0> well it does. but gnu doesn't have a case so it hits default
-              which is broken
-              http://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/40235/entry/test/dl/test_base.rb
-            <gg0> btw even linux and kfreebsd with debian multipath have broken
-              cases but they don't hit default and get fixed by ldd later
-            <pinotree> why it is broken? are arguments passed to that script?
-            <gg0> i'm not sure about what propose. a broken case so it doesn't
-              hit default like linux and kfbsd
-            <gg0> yes they are :/
-            <pinotree> and which ones are? who executes that script and which
-              arguments does it pass to it?
-            <gg0> other ruby scripts which have nothing to do with libc/libm
-            <pinotree> well, if they pass arguments which should be the paths
-              to libc and libm, they must be getting such paths, aren't they?
-            <gg0> they don't. arguments are other ruby scripts, don't know why,
-              maybe something else broken before
-            <gg0> but that would mean that before there's a smarter path
-              detection way, i doubt
-            <pinotree> then add the case for hurd, but setting both libc and
-              libm as nil
-            <pinotree> so they will be fetched again
-            <gg0> yep and would really ugly
-            <gg0> +be
-            <gg0> "please commit this one which wrongly sets paths."
-            <gg0> an alternative would be removing default case
-            <gg0> or pointing it out by proposing ldd in hurd case might make
-              them review the whole detection
-            <gg0> by setting correct paths like in patch above it wouldn't
-              break a possible hurd-amd64, it would work due to ldd
-            <youpi> gg0: that's why I said the patch is fine, but without the
-              i386-gnu part of the path
-            <youpi> just like it happens to be on linux & kfreebsd
-            <gg0> i might take ldconfig -p output
-            <gg0> to make it uselessly correct from start
-            <gg0> http://bugs.ruby-lang.org/issues/8937
-            <pinotree> note thar ruby 1.8 is EOL
-            <pinotree> *that
-            <gg0> -- If you're reporting a bug in both Ruby 1.9/2.0 and Ruby
-              1.8: ruby-trunk, and write like "this bug can be reproduced in
-              Ruby 1.8 as well." --
-            <gg0> i suspect this one won't be the only one i'll file. unless
-              upcoming youpi's tls and braunr's thread destruction patches fix
-              all ruby tests
-            <pinotree> did you check ruby2.0 too, btw?
-            <gg0> switched to ruby2 few hours ago. i pointed out 2nd part of
-              testsuite is not enabled, probably terceiro will enable it soon
-            <gg0> by applying my patch above we'd completely fix current
-              ruby2.0 build (yes because tests are not completely enabled)
-            <pinotree> what you run those extra tests?
-            <gg0>
-              http://anonscm.debian.org/gitweb/?p=collab-maint/ruby1.9.1.git;a=blob;f=debian/run-test-suites.bash
-            <gg0> make test + make test-all
-            <gg0> (test-all is 2nd part)
-            <gg0> many are problematic. i didn't finish yet to suppress them
-              one-by-one. one i suppress, another one pops up
-            <gg0> either get stuck or well known assertion
-            <pinotree> check those that get stuck :)
-            <gg0> which kind of check?
-            <pinotree> "check" as in "debug"
-            <gg0> btw i tested puppet few days ago (with ruby1.8), it seems to
-              be working, at least at trasferring files from master
-            <gg0> don't know about any advanced usage
-            <pinotree> ruby 1.8 is going to die soon, so testing things against
-              it is not totally useful
-            <gg0> so you assume 1.8 is less broken than 1.9/2.0, right?
-            <pinotree> no
-            <gg0> i just can see it's been built without tests itself too
-            <pinotree> erm no
-            <gg0> well ok, if i can be wrong, i'll be wrong
-            <gg0> i say that after a quick check time ago, might be wrong
-            <pinotree> `getbuildlogs ruby1.8 last hurd-i386`, see the last
-              build log
-            <gg0> ah from pkg-kde-tools
-            <gg0> i hate kde :)
-            <pinotree> no?
-            <gg0> no what?
-            <pinotree> devscripts: /usr/bin/getbuildlog
-            <gg0> pkg-kde-tools: /usr/bin/pkgkde-getbuildlogs
-            <pinotree> which is not what i said
-            <gg0> wait that's what apt-file found
-            <gg0> maybe i should update it
-            <gg0> is it so recent?
-            <pinotree> no
-            <pinotree> i just added an 's' more at the end of the command, but
-              typing getbu<tab> could have been helpful anyway...
-            <gg0> yeah just got it
-            <gg0> my fault not to have tried to run it before looking for it
-            <pinotree> and btw, i don't see what hating kde has to do with
-              tools developed by qt/kde debian packagers
-            <gg0> j/k i simply don't use kde, never used and apt-file search
-              told me it was from pkg-kde-tools
-            <gg0> btw build log says "make test" fails, doesn't even start. and
-              its failure doesn't block the build
-            <pinotree> exactly
-            <gg0> s/make test/make test-all/
-            <gg0> "make test" (aka "1st part" above) doesn't run. i guess it's
-              missing in packaging
-
-        IRC, freenode, #hurd, 2013-09-22:
-
-            <braunr> youpi: i mean the lock order where the assertion occurs is
-              reserved compared to the one in hurd_thread_cancel
-            <braunr> (and the one in hurd_thread_cancel is the same used in
-              hurd condition-related functions)
-            <youpi> "reserved" ?
-            <braunr> reversed
-            <braunr> :)
-            <youpi> by "the assertion occurs", you mean gg0's spot?
-            <braunr> yes
-            <youpi> well , the assertion also happens in hurd_thread_cancel
-            <braunr> it does oO
-            <braunr> i didn't see that
-            <youpi> but otherwise yes, it's completely bogus that we have both
-              locking in different orders
-            <youpi> could you submit the fix for jmp-unwind.c to upstream?
-            <braunr> what fix ?
-            <youpi> reversing the lock order
-            <braunr> ah, simply that
-            <youpi> (well, provided that hurd_thread_cancel is right)
-            <braunr> that's what i suggested to gg0
-            <braunr> to check where those locks are held and determine the
-              right order
-
-        IRC, OFTC, #debian-hurd, 2013-09-28:
-
-            <gg0_> now we'd just need tls
-            <gg0_> http://bugs.ruby-lang.org/issues/8937
-            <gg0_> well, it would pass makecheck at least. makecheckall would
-              keep hanging on threads/pipes tests i guess, unless tls/thread
-              destruction patches fix them
-
-        IRC, OFTC, #debian-hurd, 2013-10-05:
-
-            <youpi> so what is missing for ruby2.0, only disabling use of
-              context for now, no?
-            <pinotree> i'm not tracking it closely, gg0_ is
-            <gg0_> maybe terceiro would accept a patch which only disables
-              *context, "maybe" because he rightly said changes must go
-              upstream
-            <gg0_> anyway with or without *context, many many tests in
-              makecheckall fail by making it hang, first with and without
-              assertion you removed, now they all simply hang
-            <gg0_> youpi: what do we want to do? if you're about finishing tls
-              migration (as i thought a couple of weeks ago), i won't propose
-              anything upstream. otherwise i could but that will have to be
-              reverted upstream once you finish
-            <gg0_> about tests, current ruby2.0 doesn't run makecheckall, only
-              makecheck which succeeds on hurd (w/o context)
-            <gg0_> if anyone wants to give it a try:
-              http://paste.debian.net/plain/51089
-            <gg0_> first hunk makes makecheck (not makecheckall) succeed and
-              has been upstreamed, not packaged yet
-            <pinotree> what about makecheckall for ruby2.0?
-            <gg0_> 16:58 < gg0_> anyway with or without *context, many many
-              tests in makecheckall fail by making it hang, first with and
-              without assertion you  removed, now they all simply hang
-            <pinotree> i for a moment thought it as for 1.9.1, ok
-            <pinotree> these hangs should be debugged, yes
-            <gg0_> nope, tests behavior doesn't change between 1.9 and 2.0. i
-              started suppressing tests onebyone on 2.0 as well and as happened
-              on 1.9, i gave up cause there were too many
-            <gg0_> yep a smart mind could start debugging them, starting from
-              patch above pasted by a lazy one owner
-            <gg0_> one problem is that one can't reproduce them by isolate
-              them, they don't fail. start makecheckall then wait for one fail
-            <gg0_> now after my stupid report, someone like pinotree could take
-              it over, play with it for half an hour/an hour (which equals to
-              half a gg0's year/a gg0's year
-            <gg0_> )
-            <gg0_> and fix them all
-
-            <gg0_> 17:05 < gg0_> youpi: what do we want to do? if you're about
-              finishing tls migration (as i thought a couple of weeks ago), i
-              won't propose  anything upstream. otherwise i could but that will
-              have to be reverted upstream once you finish
-            <youpi> gg0_: I don't really know what to answer
-            <youpi> that's why I didn't answer :)
-            <gg0_> youpi: well then we could upstream context disable and keep
-              it disabled even if you fix tls. ruby won't be as fast as it
-              would be with context but i don't think anyone will complain
-              about that. then once packaged, if terceiro doesn't enable
-              makecheckall, we will have ruby2.0 in main
-            <youpi> that can be a plan yes
-            <gg0_> btw reverting it upstream should not be a problem eventually
-            <youpi> sure, the thing is remembering to do it
-            <gg0_> filed http://bugs.ruby-lang.org/issues/8990
-            <gg0_> please don't fix tls too soon :)
-            <gg0_> s/makecheck/maketest/g
-
-        IRC, OFTC, #debian-hurd, 2013-10-08:
-
-            <gg0_> ok. *context disabled http://bugs.ruby-lang.org/issues/8990
-
-            <gg0> bt full of an attached stuck ruby test
-              http://paste.debian.net/plain/53788/
-            <gg0> anything useful?
-            <youpi> uh, is that really all?
-            <youpi> there's not much interesting unfortunately
-            <youpi> did you run thread apply all bt full ?
-            <youpi> (not just bt full)
-            <gg0> no just bt full
-            <gg0> http://paste.debian.net/plain/53790/
-            <gg0> wait, there's a child
-            <gg0> damn ctrl-c'ing while it was loading symbols made it crash :/
-            <gg0> restarted testsuite
-            <gg0> isn't it interesting that failed tests fail only if testsuite
-              runs from beginning, whereas if run singularly, they succeed?
-            <gg0> as it got out of whatever resources
-            <gg0> youpi: http://paste.debian.net/plain/53798/
-            <youpi> the interesting part is actually right at the top
-            <youpi> it's indeed stuck in the critical section spinlock
-            <youpi> question being what is keeping it
-            <youpi> iirc I had already checked in the whole glibc code that all
-              paths which lock  critical_section_lock actually release it in
-              all cases, but maybe I have missed some
-            <youpi> (I did find some missing paths, which I fixed)
-            <gg0> i guess the same check you and braunr talk about in
-              discussion just before this anchor
-              http://darnassus.sceen.net/~hurd-web/open_issues/glibc/#recvmmsg
-            <youpi> yes, but the issue we were discussing there is not what
-              happens here
-            <youpi> we would see another thread stuck in the other way roudn,
-              otherwise
-            <gg0> no way to get what is locking?
-            <youpi> no, that's not recorded
-            <gg0> and what about writing it somewhere right after getting the
-              lock?
-            <youpi> one will have to do that in all spots taking that lock
-            <youpi> but yes, that's the usual approach
-            <gg0> i would give it try but eglibc rebuild takes too much time,
-              that conflicts with my laziness
-            <gg0> i read even making locks timed would help
-
-        IRC, OFTC, #debian-hurd, 2013-10-09:
-
-            <gg0> so correct order would be:
-            <gg0> __spin_lock (&ss->lock); // locks sigstate
-            <gg0> __spin_lock (&ss->critical_section_lock);
-            <gg0> [do critical stuff]
-            <gg0> __spin_unlock (&ss->critical_section_lock);
-            <gg0> __spin_unlock (&ss->lock);  // unlocks sigstate
-            <gg0> ?
-
-            <gg0> 21:44 < gg0> terceiro: backported to 2.0 (backport to 1.9 is
-              waiting) https://bugs.ruby-lang.org/issues/9000
-            <gg0> 21:46 < gg0> that means that if you take a 2.0 snapshot,
-              it'll build fine on hurd (unless you introduce maketestall as in
-              1.9, that would make it get stuck like 1.9)
-            <gg0> 21:48 < terceiro> gg0: nice
-            <gg0> 21:48 < terceiro> I will try to upload a snapshot as soon as
-              I can
-            <gg0> 21:52 < gg0> no problem. you might break my "conditional
-              satisfaction" by adding maketestall. better if you do that on
-              next+1 upload so we'll have at least one 2.0 built :)
-
-            <gg0> would it be a problem granting me access to a porter box to
-              rebuild eglibc+ruby2.0?
-            <gg0> i'm already doing it on another vm but host often loses power
-            <pinotree> you cannot install random stuff on a porterbox though
-            <gg0> i know i'd just need build-deps of eglibc+ruby2.0 i guess
-            <gg0> (already accessed to porter machines in the past, account
-              lele, mips iirc)
-            <gg0> ldap should remember that
-            <gg0> don't want to disturb anyone else work btw. if it's not a
-              problem, nice. otherwise no problem
-            <pinotree> please send a request to admin@exodar.debian.net so it
-              is not forgotten
-            <gg0> following this one would be too "official"?
-              http://dsa.debian.org/doc/guest-account/
-            <pinotree> hurd is not a release architecture, so hurd machines are
-              not managed by DSA
-            <gg0> ok
-            <pinotree> the general procedure outlines is ok though, just need
-              to be sent to the address above
-            <gg0> sent
-            <gg0> (1st signed mail with mutt, in the worst case i've attached
-              passphrase :))
-            <youpi> gg0: could you send me an ssh key?
-            <pinotree> no alioth account?
-            <youpi> yes, but EPERM
-            <gg0> youpi: sent to youpi@
-            <youpi> youpi@ ?
-            <gg0> (... which doesn't exist :/)
-            <gg0> sthibault@
-            <youpi> please test gg0-guest@exodar.debian.net ?
-            <youpi> (I'd rather not adduser the ldap name, who knows what might
-              happen when you get your DD account)
-            <gg0> i'm in. thanks
-            <youpi> you're welcome
-            <gg0> ldap users need to be adduser'ed?
-            <youpi> I'm not getting your ldap user account from ud-replicate,
-              at least
-            <gg0> (btw i never planned to apply nm, i'd be honoured but i
-              simply think not to deserve it)
-            <youpi> never say never ;)
-            <gg0> bah i like failing. that would be a success. i can't :)
-            <gg0> gg0-guest@exodar:~$ dchroot   
-            <gg0> E: Access not authorised
-            <gg0> I: You do not have permission to access the schroot service.
-            <gg0> I: This failure will be reported.
-            <youpi> ah, right, iirc I need to add you somewhere
-            <youpi> gg0: please retry?
-            <gg0> works
-            <youpi> good
-            <gg0> are there already eglibc+ruby2.0 build-deps?
-            <youpi> yes
-            <gg0> oh that means i should do something myself now :)
-            <youpi> yep, that had to happen at some point :)
-            <gg0> my laziness thanks: "at some point" is better than "now" :)
-
-        IRC, freenode, #hurd, 2013-10-10:
-
-            <gg0> ok just reproduced the
-              former. ../sysdeps/mach/hurd/jmp-unwind.c:53 waits
-            <braunr> 20:37 < braunr> gg0: does ruby create and destroy threads
-              ?
-            <gg0> no idea
-            <gg0> braunr: days ago you and youpi talked about locking order
-              (just before this anchor
-              http://darnassus.sceen.net/~hurd-web/open_issues/glibc/#recvmmsg)
-            <braunr> oh right
-            <gg0> <youpi> could you submit the fix for jmp-unwind.c to
-              upstream?
-            <braunr> it didn't made it in the todo list
-            <gg0> so correct order is in hurd_thread_cancel, right?
-            <braunr> sorry about that
-            <braunr> we need to make a pass to make sure it is
-            <gg0> that means locking first ss->critical_section_lock _then_
-              ss->lock
-            <gg0> correct?
-            <braunr> but considering how critical hurd_thread_cancel is, i
-              expect so
-
-            <gg0> i get the same deadlock by swapping locks
-            <gg0> braunr: youpi: fyi ^
-            <gg0> 20:51 < braunr> 20:37 < braunr> gg0: does ruby create and
-              destroy threads ?
-            <gg0> how could i check it?
-            <braunr> gg0: ps -eflw
-            <youpi> gg0: that's not surprising, since in the b acktrace you
-              posted there isn't another thread locked in the other order
-            <youpi> so it's really that somehow the thread is already in
-              critical sesction
-            <braunr> youpi: you mean there is ?
-            <braunr> ah, it's not the same bug
-            <youpi> no, in what he posted, no other thread is stuck 
-            <youpi> so it's not a locking order
-            <youpi> just that the critical section is actually busy
-            <gg0> youpi: ack
-            <gg0> braunr: what's the other bug? ext2fs one?
-            <braunr> gg0: idk
-            <gg0> braunr: thanks. doesn't show threads (found -T for that) but
-              at least doesn't limit columns number if piped (thanks to -w)
-            <braunr> it does
-            <braunr> there is a TH column
-            <gg0> ok thread count. -T gives more info
-
-        IRC, freenode, #hurd, 2013-10-24:
-
-            <youpi> ruby2.0 builds fine with the to-be-uploaded libc btw
-            <gg0> youpi: without d-ports patches? surprise me :)
-            <youpi> gg0: plain main archive source
-            <gg0> you did it. surprised
-            <gg0> ah ok you just pushed your tls. great!
-            <braunr> tls will fix a lot of things
-
-        IRC, OFTC, #debian-hurd, 2013-11-03:
-
-            <youpi> gg0: 
-            <youpi> #252 test_fork.rb:30:in `<top (required)>': core dumped
-              [ruby-core:28924]
-            <youpi> FAIL 1/949 tests failed
-            <youpi> with the to-be-uploaded glibc
-            <gg0> why does it coredump?
-            <gg0> that's the test i had workarounded by increasing sleep from 1
-              to 3 but i don't recall it coredump'ed
-            <gg0> *recall if
-            <gg0> "sleep 1" at bootstraptest/test_fork.rb:33
-            <youpi> how can I run the test alone?
-
-        IRC, OFTC, #debian-hurd, 2013-11-04:
-
-            <youpi> gg0: ^
-            <gg0> it should not take much
-            <gg0> run $ make OPTS=-v test
-            <gg0> found out how to minimize
-            <gg0> mkdir _youpi && cp bootstraptest/{runner,test_fork}.rb _youpi
-            <gg0> then run $ ./miniruby -I./lib -I. -I.ext/common
-              ./tool/runruby.rb --extout=.ext  -- --disable-gems
-              "./_youpi/runner.rb" --ruby="ruby2.0 -I./lib" -q -v
-            <gg0> youpi: that should work
-            <youpi> #1 test_fork.rb:1:in `<top (required)>': No such file or
-              directory - /usr/src/ruby1.9.1-1.9.3.448/ruby2.0
-              -I/usr/src/ruby1.9.1-1.9.3.448/lib -W0  bootstraptest.tmp.rb
-              [ruby-dev:32404]
-            <gg0> seems it can't find /usr/src/ruby1.9.1-1.9.3.448/ruby2.0
-            <youpi> well it's ruby1.9.1 indeed :)
-            <youpi> ok, got core
-            <gg0> replace 2.0 with 1.9, check what you have in rootdir
-            <gg0> k
-            <youpi> Mmm, no, there's no core file
-            <gg0> does stupidly increasing sleep time work?
-            <youpi> nope
-            <gg0> without *context it runs "make test" fine. real problems come
-              later with "make test-all"
-            <gg0> wrt test_fork, is correspondence between signals correct? i
-              recall i read something about USR1 not implemented
-            <youpi> USR1 is implemented, it's SIGRT which is not implemented
-            <gg0> my next wild guess is that that has something to do with
-              atfork, whatever that means
-            <gg0> it makes 2 forks: one sleeps for 1 sec then kills -USR1
-              itself, the second traps USR1 in getting current time. in the
-              meanwhile parent sleeps for 2 secs
-
-        IRC, OFTC, #debian-hurd, 2013-11-07:
-
-            <gg0> ruby2.0 just built on unstable
-
-        IRC, OFTC, #debian-hurd, 2013-11-09:
-
-            <gg0> youpi: just found out a more "official" way to run one test
-              only
-              http://anonscm.debian.org/gitweb/?p=collab-maint/ruby1.9.1.git;a=blob;f=debian/README.porters;h=94aff7dd3ecd9f748498f2e285b4a4313b4b8f36;hb=HEAD
-            <gg0> btw still getting coredumps?
-
-        IRC, OFTC, #debian-hurd, 2013-11-13:
-
-            <gg0> wrt the other test test_fork i suppose you made it not to
-              segfault anymore, it simply does fail
-            <youpi> I haven't taken any particular care
-            <youpi> didn't have any time to deal with it
-
-        IRC, OFTC, #debian-hurd, 2013-11-14:
-
-            <gg0> btw patches to disable *context have been backported to 1.9
-              as well so next 1.9 point release should have *context disabled
-            <gg0> as 2.0 have
-            <gg0> *has
-            <gg0> i guess you'd like to get them reverted now
-            <gg0> youpi: ^
-            <youpi> after testing that *context work, yes
-
-      * `sigaltstack`
-
-        IRC, freenode, #hurd, 2013-10-09:
-
-            <gnu_srs1> Hi, is sigaltstack() really supported, even if it is
-              defined as well as SA_ONSTACK?
-            <braunr> probably not
-            <braunr> well,
-            <braunr> i don't know actually, mistaking with something else
-            <braunr> it may be supported
-            <pinotree> iirc no
-            <gnu_srs1> pinotree: are you sure?
-            <pinotree> this is what i remember
-            <pinotree> if you want to be sure that $foo works, just do the
-              usual way: test it yourself
-            <gnu_srs1> found it: hurd/TODO: *** does sigaltstack/sigstack
-              really work? -- NO
-            <pinotree> well TODO is old and there were signal-related patches
-              by jk in the meanwhile, although i don't think they would have
-              changed this lack
-            <pinotree> in any case, test it
-            <gnu_srs1> anybody fluent in assembly? Looks like this code
-              destroys the stack: http://paste.debian.net/54331/
-            <braunr> gnu_srs1: why would it ?
-            <braunr> it does something special with the stack pointer but it
-              just looks like it aligns it to 16 bytes, maybe because of sse2
-              restrictions (recent gcc align the stack already anyway)
-            <gnu_srs1> Well, in that case it is the called function:
-              http://paste.debian.net/54341/
-            <braunr> how do you know there is a problem with the stack in the
-              first place ?
-            <gnu_srs1> tracing up to here, everything is OK. then esp and ebp
-              are destroyed.
-            <gnu_srs1> and single stepping goes backward until it segfaults
-            <braunr> "destroyed" ?
-            <gnu_srs1> zero if I remember correctly now. the x86 version built
-              for is i586, should that be changed to i486?
-            <braunr> this shouldn't change anything
-            <braunr> and they shouldn't get to 0
-            <braunr> use gdb to determine exactly which instruction resets the
-              stack pointer
-            <gnu_srs1> how to step into the assembly part? using 's' steps
-              through the function since no line information:
-            <gnu_srs1> Single stepping until exit from function
-              wine_call_on_stack,
-            <gnu_srs1> which has no line number information.
-            <braunr> gnu_srs1: use break on the address
-            <gnu_srs1> how do i get the address of where the assembly starts?
-
-      * <a id=recvmmsg>`recvmmsg`/`sendmmsg` (`t/sendmmsg`)</a>
-
-        From [[!message-id "20120625233206.C000A2C06F@topped-with-meat.com"]],
-        Roland McGrath: *They are generally useful interfaces and there is
-        nothing intrinsically Linuxoid about them.  At least when not given a
-        timeout, they could be implemented in terms of sendmsg/recvmsg.  So
-        perhaps we ought to have a sysdeps/posix implementation that the Hurd
-        would use instead of stubs (and folks can consider adding new RPCs).
-        Then perhaps the Linux fallback case should be that instead of stubs,
-        too.*
-
-      * <a id=SOCK_CLOEXEC>`SOCK_CLOEXEC`</a>
-
-        IRC, freenode, #hurd, 2013-09-02:
-
-            <gnu_srs1> Do we support  accept4  with the SOCK_CLOEXEC flag?
-            <gnu_srs1> According to the code in  sysdeps/mach/hurd/accept4.c
-              that case is not covered 
-            <gnu_srs1> (only O_NONBLOCK, not SOCK_NONBLOCK??))
-            <pinotree> gnu_srs1: we do
-            <pinotree> but only for accept4, not for socket and socketpair
-            <gnu_srs1> pinotree: cannot find the case for O_CLOEXEC covered in
-              __libc_accept4()
-            <pinotree> gnu_srs1: no, you need SOCK_*
-            <gnu_srs1> The only code for accept4() is in sysdeps/mach/hurd/ and
-              it uses O_* for flags ?
-            <pinotree>   flags = sock_to_o_flags (flags);
-            <pinotree> tried checking it?
-            <gnu_srs1> Aha, tks:-D
-            <pinotree> and you don't need an explicit case of O_CLOEXEC, since
-              it is handled in other ways
-
-        [[!message-id "1378154151.21738.15.camel@G3620.my.own.domain"]].
-
-        IRC, freenode, #hurd, 2013-09-03:
-
-            <gnu_srs> any ideas about the SOCK_CLOEXEC issue?
-            <pinotree> didn't i tell already about it?
-            <gnu_srs> I did not find any hurd related code in tschwinges
-              branches.
-            <pinotree> you didn't check deep then...
-            <gnu_srs> so why does socket/socketpair not return ENOSYS then?
-            <pinotree> why should it, since they are implemented?
-            <braunr> ...
-            <gnu_srs> for socket/socketpair?
-            <braunr> gnu_srs: enosys means no system call
-            <gnu_srs> s/ENOSYS/EINVAL/
-            <gnu_srs> see the mail to the bug-hurd/debian-hurd ML for more info
-            <gnu_srs> and tschwinges reply
-            <pinotree> which is what i knew already?
-            <gnu_srs> pinotree: please reply on the mailing list on the EINVAL
-              vs EPROTOTYPE issue to clarify things
-            <pinotree> gnu_srs:
-              https://sourceware.org/ml/libc-alpha/2013-02/msg00092.html
-            <pinotree> gnu_srs: things were clear already...
-            <gnu_srs> pinotree: I've read that patch and still pflocal/pf.c
-              returns EPROTOTYPE not changed by the __socket wrapper in eglibc
-            <pinotree> gnu_srs: what about realizing SOCK_CLOEXEC and friends
-              are NOT posix?
-            <gnu_srs> since socket/socketpair does not return EINVAL the dbus
-              code has to be patched then?
-            <pinotree> pflocal should never ever get such flags mixed to the
-              protocol, so any invalid value of protocol correctly returns
-              EPROTOTYPE
-            <gnu_srs> this is the question I need answered: Which way to go?
-            <pinotree> all of them
-            <gnu_srs> ?
-            <pinotree> - applications should not assume that because you have
-              accept4 (which is not posix) then SOCK_CLOEXEC and SOCK_NONBLOCK
-              (flags for it) are usable to socket and socketpair
-            <pinotree> - glibc should (as the idea of my patch) handle
-              implementations providing SOCK_* but not supporting them for
-              socket/socketpair
-            <pinotree> - finally the hurd part of glibc could implement them
-            <gnu_srs> to conclude: should I send a bug report for dbus then?
-            <gnu_srs> pinotree: yes or no?
-            <pinotree> gnu_srs: *shrug* i wrote it above, so an *upstream*
-              report (not a debian one)
-
-        IRC, freenode, #hurd, 2013-09-06:
-
-            <gnu_srs> I've found another error code issue, now in  glib2.0 (and
-              dbus). Are you really sure the error code 
-            <gnu_srs> for protocol of pflocal/pf.c should be
-              EPROTONOSUPPORT. The code expects EINVAL for a protocol with
-            <gnu_srs>  SOCK_CLOEXEC, which is a flag. Maybe pf.c should add
-              this case and return EINVAL instead of 
-            <gnu_srs> submitting bug reports upstream. Yes, I know this is not
-              POSIX, but it is defined for Hurd too, 
-            <gnu_srs> currently only supported for accept4, not socket or
-              socketpair. 
-            <pinotree> gnu_srs: no, and i explained already why it is wrong
-              this way
-            <pinotree> pflocal shouldn't even get such flags
-            <pinotree> (pflocal or any other server implementing socket_create)
-            <gnu_srs> (20:19:35) pinotree: pflocal shouldn't even get such
-              flags
-            <gnu_srs> then the glibc wrapper code is missing to catch this
-              flag:(
-            <gnu_srs> youpi: ?
-            <pinotree> gnu_srs: because, as told many times, socket and
-              socketpair do not support such flags
-            <pinotree> given they don't do, they filter nothing
-            <pinotree> and no, you need to file bugs upstream, since having
-              SOCK_* and accept4 does not imply at all that socket and
-              socketpair support them
-
-        IRC, freenode, #hurd, 2013-09-07:
-
-            <gnu_srs> A correction from yesterdays discussion:
-              s/EPROTONOSUPPORT/EPROTOTYPE
-
-        IRC, freenode, #hurd, 2013-09-10:
-
-            <gnu_srs> for dbus2.0 I found out that the third SOCK_CLOEXEC case
-              needs a patch too (more working tests),
-            <gnu_srs> the updated patch is at http://paste.debian.net/37948/ if
-              you have the time, otherwise I'll do it.
-            <pinotree> gnu_srs: which is what i wrote in my bug report...
-            <gnu_srs> Yes you wrote that, but the patch is not updated yet?
-            <pinotree> it refers to a different socket access, recently added,
-              which is not used by default
-            <gnu_srs> I got two more tests running when adding that patch:-/
-            <pinotree> tests of what?
-            <gnu_srs>  run-test.sh and run-test-systemserver.sh:P
-            <pinotree> tests of what?
-            <pinotree> i don't have the universal knowledge of the files in all
-              the sources
-            <gnu_srs> dbus-1.6.14/test/name-test/*
-
-        [[!message-id "523A3D6C.2030200@gmx.de"]].
-
-        IRC, OFTC, #debian-hurd, 2013-09-19:
-
-            <pinotree> tschwinge: ehm, regarding the SOCK_* patches for
-              socket/socketpair, didn't we talk about them when i worked on
-              eglibc 2.17?
-
-      * `mlock`, `munlock`, `mlockall`, `munlockall`
-
-        IRC, freenode, #hurd, 2014-01-09:
-
-            <gnu_srs> Hi, is mlock, mlockall et al implemented?
-            <braunr> i doubt it
-            <braunr> mlock could be, but mlockall only partially
-
-      * [[glibc_IOCTLs]]
-
-      * Support for `$ORIGIN` in the dynamic linker, `ld.so`
-
-        IRC, freenode, #hurd, 2014-02-23:
-
-            <sjamaan>
-              https://www.gnu.org/software/hurd/user/jkoenig/java/report.html
-              says $ORIGIN patches have been added to Hurd.  Have those hit the
-              mainline codebase?
-
-        [[user/jkoenig/java]], [[user/jkoenig/java/report]].
-
-            <sjamaan> It doesn't seem to work here, but perhaps I'm missing
-              something (I'm using the prebuilt Debian/Hurd 2014-02-11 VM
-              image)
-            <sjamaan> objdump -x says the value of RPATH is $ORIGIN
-            <sjamaan> But it doesn't load a library I placed in the same dir as
-              the binary
-            <braunr> sjamaan: i'm not sure
-            <braunr> sjamaan: what are you trying to do ?
-
-        IRC, freenode, #hurd, 2014-02-24:
-
-            <sjamaan> braunr: I am working on a release of the CHICKEN Scheme
-              compiler. Its test suite is currently failing on the stand-alone
-              deployment tests.  Either it should work and use $ORIGIN, or the
-              test should be disabled, saying Hurd is not supported for
-              stand-alone deployment-directories
-            <sjamaan> braunr: The basic idea is to be able to create "appdirs"
-              like on OS X or PC-BSD, containing all the dependencies a program
-              needs, which can then simply be untarred
-            <braunr> sjamaan: ok so you do need $ORIGIN
-            <sjamaan> yeah
-            <sjamaan> iiuc, so does Java.  Does Java work on Hurd?
-            <braunr> we had packages at the time jkoenig worked on it
-            <braunr> integration of patches may have been incomplete, i wasn't
-              there at the time and i'm not sure
-            <sjamaan> So it's safest to claim it's unsupported, for now?
-            <braunr> yes
-            <sjamaan> Thank you, I'll do that and revisit it later
-
-      * `mig_reply_setup`
-
-        IRC, freenode, #hurd, 2014-02-24:
-
-            <teythoon> braunr: neither hurd, gnu mach or glibc provides
-              mig_reply_setup
-            <teythoon> i want to provide this function, where should i put it ?
-            <teythoon> i found some mach source that put it in libmach afaic
-            <teythoon>
-              ftp://ftp.sra.co.jp/.a/pub/os/mach/extracted/mach3/mk/user/libmach/mig_reply_setup.c
-            <braunr> teythoon: what does it do ?
-            <teythoon> braunr: not much, it just initializes the reply message
-            <teythoon> libports does this as well, in the
-              ports_manage_port_operations* functions
-            <braunr> teythoon: is it a new function you're adding ?
-            <teythoon> braunr: yes
-            <teythoon> braunr: glibc has a declaration for it, but no
-              implementation
-            <braunr> teythoon: i think it should be in glibc
-            <braunr> maybe in mach/
-
-      * [[POSIX file record locking|file_locking]]
-
-      * <a name="execve_relative_paths">`execve` with relative paths</a>
-
-        [[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id
-        "4BFA500A.7030502@gmail.com"]].
-
-        IRC, freenode, #hurd, 2014-03-05:
-
-            <teythoon> youpi: what about the exec_filename patch series? [...]
-            <youpi> Roland was disagreeing with it
-
-      * <a name="mount">`mount`/`umount`</a>
-
-        IRC, freenode, #hurd, 2014-03-01:
-
-            <gnu_srs1> Hi, how to handle packages depending on mount.h, et al?
-              On Hurd mount/umount is supplied by hurd is not in libc?
-            <azeem> gnu_srs1: mount or mount.h?
-            <gnu_srs1> mount.h et al
-            <gnu_srs1> man 2 mount
-            <azeem> what is the question then?
-            <gnu_srs1> some packages expect the mount 2 functionality
-              available, not by the external command mount/umonut
-            <gnu_srs1> umount*
-            <gnu_srs1> azeem: one example is fuse
-            <teythoon> gnu_srs1: that is correct
-            <teythoon> gnu_srs1: i put a small hacks entry in the list about
-              moving the mount/umount functionality from our utilities to the
-              libc
-
-      * <a name="posix_timers">POSIX Timers</a>
-
-        `timer_create`, `timer_delete`, [[`clock_gettime`|clock_gettime]], and
-        so on.
-
-    For specific packages:
-
-      * <a id=octave>[[octave]]</a>
-
-  * <a id=t_cleanup_kernel-features.h>Create `t/cleanup_kernel-features.h`.</a>
-
-  * <a id=Secure_file_descriptor_handling>[[Secure_file_descriptor_handling]].</a>
-
-  * <a id=sendfile>In `sysdeps/unix/sysv/linux/Makefile`, there are a bunch of
-    `-DHAVE_SENDFILE` -- but we do have `sendfile`, too.</a>
-
-    Define `__ASSUME_SENDFILE` to 1 in `kernel-features.h`, if `sendfile`
-    works.
-
-  * <a id=pthreadoverwrite>`/usr/include/pthread.h` overwrite issue</a>
-
-    `make`, after editing `nss/nss_db/db-initgroups.c`:
-
-        [...]
-        make[2]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/resolv'
-        make  subdir=nss -C nss ..=../ others
-        make[2]: Entering directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/nss'
-        /usr/bin/install -c -m 644 ../include/pthread.h /usr/include/pthread.h
-        /usr/bin/install: cannot remove `/usr/include/pthread.h': Permission denied
-        make[2]: *** [/usr/include/pthread.h] Error 1
-        make[2]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/nss'
-        make[1]: *** [nss/others] Error 2
-        make[1]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker'
-        make: *** [all] Error 2
-
-    See [[!message-id "871uv99c59.fsf@kepler.schwinge.homeip.net"]].  Passing
-    `install_root=/INVALID` to `make`/`make check` is a cheap cure.  For `make
-    install`, prepending an additional slash to `install_root` (that is,
-    `install_root=//[...]`) is enough to obfuscate the Makefile rules.
-
-  * <a id=syslog.c>`sysdeps/unix/sysv/linux/syslog.c`</a>
-
-  * <a id=fsync>`fsync` on a pipe</a>
-
-    IRC, freenode, #hurd, 2012-08-21:
-
-        <braunr> pinotree: i think gnu_srs spotted a conformance problem in
-          glibc
-        <pinotree> (only one?)
-        <braunr> pinotree: namely, fsync on a pipe (which is actually a
-          socketpair) doesn't return EINVAL when the "operation not supported"
-          error is returned as a "bad request message ID"
-        <braunr> pinotree: what do you think of this case ?
-        <pinotree> i'm far from an expert on such stuff, but seems a proper E*
-          should be returned
-        <braunr> (there also is a problem in clisp falling in an infinite loop
-          when trying to handle this, since it uses fsync inside the error
-          handling code, eww, but we don't care :p)
-        <braunr> basically, here is what clisp does
-        <braunr> if fsync fails, and the error isn't EINVAL, let's report the
-          error
-        <braunr> and reporting the error in turn writes something on the
-          output/error stream, which in turn calls fsync again
-        <pinotree> smart
-        <braunr> after the stack is exhausted, clisp happily crashes
-        <braunr> gnu_srs: i'll alter the clisp code a bit so it knows about our
-          mig specific error
-        <braunr> if that's the problem (which i strongly suspect), the solution
-          will be to add an error conversion for fsync so that it returns
-          EINVAL
-        <braunr> if pinotree is willing to do that, he'll be the only one
-          suffering from the dangers of sending stuff to the glibc maintainers
-          :p
-        <pinotree> that shouldn't be an issue i think, there are other glibc
-          hurd implementations that do such checks
-        <gnu_srs> does fsync return EINVAL for other OSes?
-        <braunr>        EROFS, EINVAL
-        <braunr>               fd is bound to a special file which does not
-          support synchronization.
-        <braunr> obviously, pipes and sockets don't
-        <pinotree>
-          http://pubs.opengroup.org/onlinepubs/9699919799/functions/fsync.html
-        <braunr> so yes, other OSes do just that
-        <pinotree> now that you speak about it, it could be the failure that
-          the gnulib fsync+fdatasync testcase have when being run with `make
-          check` (although not when running as ./test-foo)
-        <braunr> hm we may not need change glibc
-        <braunr> clisp has a part where it defines a macro IS_EINVAL which is
-          system specific
-        <braunr> (but we should change it in glibc for conformance anyway)
-        <braunr> #elif defined(UNIX_DARWIN) || defined(UNIX_FREEBSD) ||
-          defined(UNIX_NETBSD) || defined(UNIX_OPENBSD) #define IS_EINVAL_EXTRA
-          ((errno==EOPNOTSUPP)||(errno==ENOTSUP)||(errno==ENODEV))
-        <pinotree> i'd rather add nothing to clisp
-        <braunr> let's see what posix says
-        <braunr> EINVAL
-        <braunr> so right, we should simply convert it in glibc
-        <gnu_srs> man fsync mentions EINVAL
-        <braunr> man pages aren't posix, even if they are usually close
-        <gnu_srs> aha
-        <pinotree> i think checking for MIG_BAD_ID and EOPNOTSUPP (like other
-          parts do) will b enough
-        <pinotree> *be
-        <braunr> gnu_srs: there, it finished correctly even when piped
-        <gnu_srs> I saw that, congrats!
-        <braunr> clisp is quite tricky to debug
-        <braunr> i never had to deal with a program that installs break points
-          and handles segfaults itself in order to implement growing stacks :p
-        <braunr> i suppose most interpreters do that
-        <gnu_srs> So the permanent change will be in glibc, not clisp?
-        <braunr> yes
-
-    IRC, freenode, #hurd, 2012-08-24:
-
-        <gnu_srs1> pinotree: The changes needed for fsync.c is at
-          http://paste.debian.net/185379/ if you want to try it out (confirmed
-          with rbraun)
-        <youpi> I agree with the patch, posix indeed documents einval as the
-          "proper"  error value
-        <pinotree> there's fdatasync too
-        <pinotree> other places use MIG_BAD_ID instead of EMIG_BAD_ID
-        <braunr> pinotree: i assume that if you're telling us, it's because
-          they have different values
-        <pinotree> braunr: tbh i never seen the E version, and everywhere in
-          glibc the non-E version is used
-        <gnu_srs1> in sysdeps/mach/hurd/bits/errno.h only the E version is
-          defined
-        <pinotree> look in gnumach/include/mach/mig_errors.h
-        <pinotree> (as the comment in errno.h say)
-        <gnu_srs1> mig_errors.h yes. Which comment: from errors.h: /* Errors
-          from <mach/mig_errors.h>.  */ and then the EMIG_ stuff?
-        <gnu_srs1> Which one is used when building libc?
-        <gnu_srs1> Answer: At least in fsync.c errno.h is used: #include
-          <errno.h>
-        <gnu_srs1> Yes, fdatasync.c should be patched too.
-        <gnu_srs1> pinotree: You are right: EMIG_ or MIG_ is confusing. 
-        <gnu_srs1> /usr/include/i386-gnu/bits/errno.h:     /* Errors from
-          <mach/mig_errors.h>.  */
-        <gnu_srs1> /usr/include/hurd.h:#include <mach/mig_errors.h>
-
-    IRC, freenode, #hurd, 2012-09-02:
-
-        <antrik> braunr: regarding fsync(), I agree that EOPNOTSUPP probably
-          should be translated to EINVAL, if that's what POSIX says. it does
-          *not* sound right to translate MIG_BAD_ID though. the server should
-          explicitly return EOPNOTSUPP, and that's what the default trivfs stub
-          does. if you actually do see MIG_BAD_ID, there must be some other
-          bug...
-        <braunr> antrik: right, pflocal doesn't call the trivfs stub for socket
-          objects
-        <braunr> trivfs_demuxer is only called by the pflocal node demuxer, for
-          socket objects it's another call, and i don't think it's the right
-          thing to call trivfs_demuxer there either
-        <pinotree> handling MAG_BAD_ID isn't a bad idea anyway, you never know
-          what the underlying server actually implements
-        <pinotree> (imho)
-        <braunr> for me, a bad id is the same as a not supported operation
-        <pinotree> ditto
-        <pinotree> from fsync's POV, both the results are the same anyway, ie
-          that the server does not support a file_sync operation
-        <antrik> no, a bad ID means the server doesn't implement the protocol
-          (or not properly at least)
-        <antrik> it's usually a bug IMHO
-        <antrik> there is a reason we have EOPNOTSUPP for operations that are
-          part of a protocol but not implemented by a particular server
-        <pinotree> antrik: even if it could be the case, there's no reason to
-          make fsync fail anyway
-        <antrik> pinotree: I think there is. it indicates a bug, which should
-          not be hidden
-        <pinotree> well, patches welcome then...
-        <antrik> thing is, if sock objects are actually not supposed to
-          implement the file interface, glibc shouldn't even *try* to call
-          fsync on them
-        <pinotree> how?
-        <pinotree> i mean, can you check whether the file interface is not
-          implemented, without doing a roundtrip^
-        <pinotree> ?
-        <antrik> well, the sock objects are not files, i.e. they were *not*
-          obtained by file_name_lookup(), but rather a specific call. so glibc
-          actually *knows* that they are not files.
-        <braunr> antrik: this way of thinking means we need an "fd" protocol
-        <braunr> so that objects accessed through a file descriptor implement
-          all fd calls
-        <antrik> now I wonder though whether there are conceivable use cases
-          where it would make sense for objects obtained through the socket
-          call to optionally implement the file interface...
-        <antrik> which could actually make sense, if libc lets through other
-          file calls as well (which I guess it does, if the sock ports are
-          wrapped in normal fd structures?)
-        <braunr> antrik: they are
-        <braunr> and i'd personally be in favor of such an fd protocol, even if
-          it means implementing stubs for many useless calls
-        <braunr> but the way things are now suggest a bad id really means an
-          operation is simply not supported
-        <antrik> the question in this case is whether we should make the file
-          protocol mandatory for anything that can end up in an FD; or whether
-          we should keep it optional, and add the MIG_BAD_ID calls to *all* FD
-          operations
-        <antrik> (there is no reason for fsync to be special in this regard)
-        <braunr> yes
-        <antrik> braunr: BTW, I'm rather undecided whether the right approach
-          is a) requiring an FD interface collection, b) always checking
-          MIG_BAD_ID, or perhaps c) think about introducing a mechanism to
-          explicitly query supported interfaces...
-
-    IRC, freenode, #hurd, 2012-09-03:
-
-        <braunr> antrik: querying interfaces sounds like an additional penalty
-          on performance
-        <antrik> braunr: the query usually has to be done only once. in fact it
-          could be integrated into the name lookup...
-        <braunr> antrik: once for every object
-        <braunr> antrik: yes, along with the lookup would be a nice thing
-
-    [[!message-id "1351231423.8019.19.camel@hp.my.own.domain"]].
-
-  * <a id=t_no-hp-timing>`t/no-hp-timing`</a>
-
-    IRC, freenode, #hurd, 2012-11-16
-
-        <pinotree> tschwinge: wrt the glibc topgit branch t/no-hp-timing,
-          couldn't that file be just replaced by #include
-          <sysdeps/generic/hp-timing.h>?
-
-  * <a id=flockfile>`flockfile`/`ftrylockfile`/`funlockfile`</a>
-
-    IRC, freenode, #hurd, 2012-11-16
-
-        <pinotree> youpi: uhm, in glibc we use
-          stdio-common/f{,try,un}lockfile.c, which do nothing (as opposed to eg
-          the nptl versions, which do lock/trylock/unlock); do you know more
-          about them?
-        <youpi> pinotree: ouch
-        <youpi> no, I don't know
-        <youpi> well, I do know what they're supposed to do
-        <pinotree> i'm trying fillig them, let's see
-        <youpi> but not why we don't have them
-        <youpi> (except that libpthread is "recent")
-        <youpi> yet another reason to build libpthread in glibc, btw
-        <youpi> oh, but we do provide lockfile in libpthread, don't we ?
-        <youpi> pinotree: yes, and libc has weak variants, so the libpthread
-          will take over
-        <pinotree> youpi: sure, but that in stuff linking to pthreads
-        <pinotree> if you do a simple application doing eg main() { fopen +
-          fwrite + fclose }, you get no locking
-        <youpi> so?
-        <youpi> if you don't have threads, you don't need locks :)
-        <pinotree> ... unless there is some indirect recursion
-        <youpi> ?
-        <pinotree> basically, i was debugging why glibc tests with mtrace() and
-          ending with muntrace() would die (while tests without muntrace call
-          wouldn't)
-        <youpi> well, I still don't see what a lock will bring
-        <pinotree> if you look at the muntrace implementation (in
-          malloc/mtrace.c), basically fclose can trigger a malloc hook (because
-          of the free for the FILE*)
-        <youpi> either you have threads, and it's need, or you don't, and it's
-          a nop
-        <youpi> yes, and ?
-        <braunr> does the signal thread count ?
-        <youpi> again, in linux, when you don't have threads, the lock is a nop
-        <youpi> does the signal thread use IO ?
-        <braunr> that's the question :)
-        <braunr> i hope not
-        <youpi> IIRC the signal thread just manages signals, and doesn't
-          execute the handler itself
-        <braunr> sure
-        <braunr> i was more thinking about debug stuff
-        <youpi> can't hurt to add them anyway, but let me still doubt that it'd
-          fix muntrace, I don't see why it would, unless you have threads
-        <pinotree> that's what i'm going next
-        <pinotree> pardon, it seems i got confused a bit
-        <pinotree> it'd look like a genuine muntrace bug (muntrace → fclose →
-          free hook → lock lock → fprint (since the FILE is still set) → malloc
-          → malloc hook → lock lock → spin)
-        <pinotree> at least i got some light over the flockfile stuff, thanks
-          ;)
-        <pinotree> youpi: otoh, __libc_lock_lock (etc) are noop in the base
-          implementation, while doing real locks on hurd in any case, and on
-          linux only if nptl is loaded, it seems
-        <pinotree> that would explain why on linux you get no deadlock
-        <youpi> unless using nptl, that is?
-        <pinotree> hm no, even with pthread it works
-        <pinotree> but hey, at least the affected glibc test now passes
-        <pinotree> will maybe try to do investigation on why it works on linux
-          tomorrow
-
-    [[!message-id "201211172058.21035.toscano.pino@tiscali.it"]].
-
-    In context of [[libpthread]].
-
-    IRC, freenode, #hurd, 2013-01-21
-
-        <braunr> ah, found something interesting
-        <braunr> tschwinge: there seems to be a race on our file descriptors
-        <braunr> the content written by one thread seems to be retained
-          somewhere and another thread writing data to the file descriptor will
-          resend what the first already did
-        <braunr> it could be a FILE race instead of fd one though
-        <braunr> yes, it's not at the fd level, it's above
-        <braunr> so good news, seems like the low level message/signalling code
-          isn't faulty here
-        <braunr> all right, simple explanation: our IO_lockfile functions are
-          no-ops
-        <pinotree> braunr: i found that out days ago, and samuel said they were
-          okay
-        <braunr> well, they're not no-ops in libpthreads
-        <braunr> so i suppose they replace the default libc stubs, yes
-        <pinotree> so the issue happens in cthreads-using apps?
-        <braunr> no
-        <braunr> we don't have cthreads apps any more
-        <braunr> and aiui, libpthreads provides cthreads compatibility calls to
-          libc, so everything is actually using pthreads
-        <braunr> more buffer management debugging needed :/
-        <pinotree> hm, so how can it be that there's a multithread app with no
-          libpthread-provided file locking?
-        <braunr> ?
-        <braunr> file locking looks fine
-        <braunr> hm, the recursive locking might be wrong though
-        <braunr> ./sysdeps/mach/hurd/bits/libc-lock.h:#define
-          __libc_lock_owner_self() ((void *) __hurd_threadvar_location (0))
-        <braunr> nop, looks fine too
-        <braunr> indeed, without stream buffering, the problem seems to go away
-        <braunr> pinotree: it really looks like the stub IO_flockfile is used
-        <braunr> i'll try to make sure it's the root of the problem
-        <pinotree> braunr: you earlier said that there's some race with
-          different threads, no?
-        <braunr> yes
-        <braunr> either a race or an error in the iostream management code
-        <braunr> but i highly doubt the latter
-        <pinotree> if the stub locks are used, then libpthread is not
-          loaded... so which different threads are running?
-        <braunr> that's the thing
-        <braunr> the libpthread versions should be used
-        <pinotree> so the application is linked to pthread?
-        <braunr> yes
-        <pinotree> i see, that was the detail i was missing earlier
-        <braunr> the common code looks fine, but i can see wrong values even
-          there
-        <braunr> e.g. when vfprintf calls write, the buffer is already wrong
-        <braunr> i've made similar tests on linux sid, and it behaves as it
-          should
-        <pinotree> hm
-        <braunr> i even used load to "slow down" my test program so that
-          preemption is much more likely to happen
-        <pinotree> note we have slightly different behaviour in glibc's libio,
-          ie different memory allocation ways (mmap on linux, malloc for us)
-        <braunr> the problem gets systematic on the hurd while it never occurs
-          on linux
-        <braunr> that shouldn't matter either
-        <pinotree> ok
-        <braunr> but i'll make sure it doesn't anyway
-        <braunr> this mach_print system call is proving very handy :)
-        <braunr> and also, with load, unbuffered output is always correct too
-        <pinotree> braunr: you could try the following hack
-          http://paste.debian.net/227106/
-        <braunr> what does it do ?
-        <pinotree> (yes, ugly as f**k)
-        <braunr> does it force libio to use mmap ?
-        <braunr> or rather, enable ?
-        <pinotree> provides a EXEC_PAGESIZE define in libio, so it makes it use
-          mmap (like on linux) instead of malloc
-
-  * <a id=t_pagesize>`t/pagesize`.</a>
-
-        <braunr> yes, the stub is used instead of the libpthreads code
-        <braunr> tschwinge: ^
-        <braunr> i'll override those to check that it fixes the problem
-        <braunr> hm, not that easy actually
-        <pinotree> copy their files from libpthreads to sysdeps/mach/hurd
-        <pinotree> hm right, in libpthread they are not that split as in glibc
-        <braunr> let's check symbol declaration to understand why the stubs
-          aren't overriden by ld
-        <braunr> _IO_vfprintf correctly calls @plt versions
-        <braunr> i don't know enough about dynamic linking to see what causes
-          the problem :/
-        <braunr> youpi: it seems our stdio functions use the stub IO_flockfile
-          functions
-        <youpi> really? I thought we were going through cthreads-compat.c
-        <braunr> yes really
-        <braunr> i don't know why, but that's the origin of the "duplicated"
-          messages issue
-        <braunr> messages aren't duplicated, there is a race that makes on
-          thread reuse the content of the stream buffer
-        <braunr> one*
-        <youpi> k, quite bad
-        <braunr> at least we know where the problem comes from now
-        <braunr> youpi: what would be the most likely reason why weak symbols
-          in libc wouldn't be overriden by global ones from libpthread ?
-        <youpi> being loaded after libc
-        <braunr> i tried preloading it
-        <braunr> i'll compare with what is done on wheezy
-        <youpi> you have the local-dl-dynamic-weak.diff patch, right?
-        <braunr> (on squeeze, the _IO_flockfile function in libc seems to do
-          real work unlike our noop stub)
-        <braunr> it's the debian package, i have all patches provided there
-        <braunr> indeed, on linux, libc provides valid IO_flock functions
-        <braunr> ./sysdeps/pthread/flockfile.c:strong_alias (__flockfile,
-          _IO_flockfile)
-        <braunr> that's how ntpl exports it
-        <braunr> nptl*
-        <pinotree> imho we should restructure libpthread to be more close to
-          nptl
-        <braunr> i wish i knew what it involves
-        <pinotree> file structing for sources and tests, for example
-        <braunr> well yes obviously :)
-        <braunr> i've just found a patch that does exactly that for linuxthreads
-        <pinotree> that = fix the file locking?
-        <braunr> in addition to linuxthreads/lockfile.c (which we also
-          equivalently provide), there is
-          linuxthreads/sysdeps/pthread/flockfile.c
-        <braunr> no, restructiring
-        <braunr> restructuring*
-        <braunr> i still have only a very limited idea of how the glibc sources
-          are organized
-        <pinotree> the latter is used as source file when compiling flockfile.c
-          in stdio-common
-        <braunr> shouldn't we provide one too ?
-        <pinotree> that would mean it would be compiled as part of libc proper,
-          not libpthread
-        <braunr> yes
-        <braunr> that's what both linuxthreads and nptl seem to do
-        <braunr> and the code is strictly the same, i.e. a call to the internal
-          _IO_lock_xxx functions
-        <youpi> I guess that's for the hot-dlopen case
-        <youpi> you need to have locks properly taken at dlopen time
-        <braunr> youpi: do you mean adding an flockfile.c file to our sysdeps
-          will only solve the problem by side effect ?
-        <braunr> and that the real problem is that the libpthread versions
-          aren't used ?
-        <youpi>  yes
-        <braunr> ok
-        <braunr> youpi: could it simply be a versioning issue ?
-        <youpi> could be
-        <braunr> it seems so
-        <braunr> i've rebuilt with the flockfile functions versioned to 2.2.6
-          (same as in libc) and the cthreads_compat functions are now used
-        <braunr> and the problem doesn't occur any more with my test code
-        <braunr> :)
-        <youpi> could you post a patch?
-        <braunr> i need a few info before
-        <youpi> it'd be good to check which such functions are hooked
-        <braunr> i suppose the version for functions declared in libpthreads
-          shouldn't change, right ?
-        <youpi> yes
-        <braunr> ok
-        <youpi> they didn't have a vresion before
-        <braunr> shall i commit directly ?
-        <youpi> so it should be fine
-        <braunr> well, they did
-        <braunr> 2.12
-        <youpi> yes, but please tell me when it's done
-        <braunr> sure
-        <youpi> so I can commit that to debian's eglibc
-        <youpi> I mean, before we integrated libpthread build into glibc
-        <youpi> so they never had any version before 2.12
-        <braunr> ok
-        <youpi> basically we need to check the symbols which are both in
-          libpthread and referenced in libc
-        <youpi> to make sure they have the same version in the reference
-        <braunr> ok
-        <youpi> only weak references need to be checked, others would have
-          produced a runtime error
-        <braunr> youpi: done
-        <braunr> arg, the version i mention in the comment is wrong
-        <braunr> i suppose people understand nonetheless
-        <youpi> probably, yes
-        <braunr> ah, i can now appreciate the headache this bug hunting gave me
-          these last days :)
-
-    IRC, freenode, #hurd, 2013-01-22
-
-        <youpi> braunr: commited to debian glibc
-        <youpi> btw, it's normal that the program doesn't terminate, right?
-        <youpi> (i.e. it's the original bug you were chasing)
-        <braunr> youpi: about your earlier question (yesterday) about my test
-          code, it's expected to block, which is the problem i was initially
-          working on
-        <youpi> ok, so all god
-        <youpi> +o
-
-  * <a id=t_pagesize2>`t/pagesize`</a>
-
-    IRC, freenode, #hurd, 2012-11-16
-
-        <pinotree> tschwinge: somehow related to your t/pagesize branch: due to
-          the fact that EXEC_PAGESIZE is not defined on hurd, libio/libioP.h
-          switches the allocation modes from mmap to malloc
-
-    [[!message-id "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]].
-
-    IRC, freenode, #hurd, 2013-01-21
-
-        <braunr> why is it a hack ?
-        <pinotree> because most probably glibc shouldn't rely on EXEC_PAGESIZE
-          like that
-        <braunr> ah
-        <pinotree> there's a mail from roland, replying to thomas about this
-          issue, that this use of EXEC_PAGESIZE to enable mmap or not is just
-          wrong
-        <braunr> ok
-        <pinotree> (the above is
-          http://thread.gmane.org/87mxd9hl2n.fsf@kepler.schwinge.homeip.net )
-        <braunr> thanks
-        <pinotree> (just added the reference to that in the wiki)
-        <braunr> pinotree: btw, what's wrong with using malloc instead of mmap
-          in libio ?
-        <pinotree> braunr: i'm still not totally sure, most probably it should
-          be slightly slower currently
-        <braunr> locking contention ?
-        <braunr> pinotree:
-          http://www.sourceware.org/ml/libc-alpha/2006-11/msg00061.html
-        <braunr> pinotree: it looks to me there is now no valid reason not to
-          use malloc
-        <braunr> the best argument for mmap is that libio requires zeroed
-          memory, but as the OP says, zeroing a page is usually more expensive
-          than a small calloc (even on kernel that keep a list of zeroed pages
-          for quick allocations, frequent mmaps() often make this list empty)
-        <pinotree> braunr: mmap allocations in libio are rounded to the page
-          size
-        <braunr> well they have to
-
-  * <a id=LD_DEBUG>`LD_DEBUG`</a>
-
-    IRC, freenode, #hurd, 2012-11-22
-
-        <pinotree> woot, `LD_DEBUG=libs /bin/ls >/dev/null` prints stuff and
-          then sigsegv
-        <tschwinge> Yeah, that's known for years...  :-D
-        <tschwinge> Probably not too difficult to resolve, though.
-
-  * IRC, OFTC, #debian-hurd, 2013-08-16:
-
-        <pinotree> http://paste.debian.net/25934/ ← _hurd_thread_sigstate calls
-          malloc, boom
-
-  * <a id=conformtest>`conformtest`</a>
-
-    IRC, OFTC, #debian-hurd, 2013-09-22:
-
-        <youpi> btw, I noticed that glibc has a head conformance test which we
-          happily fail quite a bit :)
-        <youpi> it's not so awful, we don't have twice as many failures as
-          linux, but not so far
-        <pinotree> youpi: do you mean "header" for "head", right?
-        <youpi> err, where ? :)
-        <pinotree> <youpi> btw, I noticed that glibc has a head conformance
-          test which we happily fail quite a bit :)
-        <youpi> ah, yes
-        <pinotree> noticed that too
-        <youpi> I had a quick look at the POSIX part, some things are probably
-          not too hard to change (e.g. exposing pthread_kill in signal.h)
-        <youpi> others will by quite hard to fix (short type instead of int
-          type for some flock structure field)
-        <youpi> s/by/be/
-
-  * `truncate`/`ftruncate`
-
-    Hurd fixed with 2013-10-03 commit 6c3825f2b750bf9b913c6ea986739e648c470603,
-    glibc still to be done?
-
-    IRC, freenode, #hurd, 2013-10-01:
-
-        <pinotree> libdiskfs/node-drop.c:      assert (np->dn_stat.st_size == 0); ←
-          this one?
-        <pinotree> iirc you constantly get that when building ustr
-        <braunr> is ustr a package ?
-        <pinotree> yes
-        <pinotree> iirc the ustr tests are mostly disk-intensive
-
-    IRC, freenode, #hurd, 2013-10-02:
-
-        <braunr> i've traced the problem up to truncate
-        <braunr> which gets a negative size
-        <braunr> shouldn't take long to find out where it comes from now
-        <pinotree> it seems our truncate doesn't handle negative values well though
-        <braunr>        EINVAL The argument length is negative or larger than the
-          maximum file size.
-        <braunr> i still have to see whether it comes from the user (unlikely) or
-          if it's an internal inconsistency
-        <braunr> i suspect some code wrongly handles vm_map failures
-        <braunr> leading to that inconsistency
-        <braunr> pinotree: looks like glibc doesn't check for length >= 0
-        <pinotree> yeah
-        <braunr> servers should do it nonetheless
-        <pinotree> should we fix glibc, libdiskfs/libnetfs/libtrivfs/etc, or both?
-        <braunr> it appears a client does the truncate
-        <braunr> i'd say both
-        <braunr> can you take the glibc part ? :)
-        <pinotree> i was going to do the hurd part... :p
-        <pinotree> ok, i'll pick libc
-        <braunr> well i'm doing it already
-        <braunr> i want to write a test case first
-        <braunr> to make sure that's the problem
-        <pinotree> already on the hurd part, you mean?
-        <braunr> yes
-        <pinotree> ok
-        <braunr> ok looks like it
-        <braunr> i can't reproduce the assertion but it does make ext2fs freeze
-        <braunr> pinotree: http://darnassus.sceen.net/~rbraun/test_ftruncate.c
-        <pinotree> merci
-        <braunr> pinotree: ustr builds
-        <pinotree> wow
-        <braunr> the client code (ustr) seems to perform a ftruncate with size
-          ((size_t)-1) whereas lengths are signed ..
-        <braunr> i'll check other libraries and send a patch soon
-
-    IRC, freenode, #hurd, 2013-10-03:
-
-        <braunr> youpi: i've committed a fix to hurd that checks for negative sizes
-          when truncating files
-        <braunr> this allows building the ustr package without making ext2fs choke
-          on an assertion
-        <braunr> pinotree is preparing a patch for glibc
-        <braunr> see truncate/ftruncate
-        <braunr> with an off_t size parameter, which can be negative
-        <braunr>        EINVAL The argument length is negative or larger than the
-          maximum file size.
-        <braunr> hurd servers were not conforming to that before my change
-
-  * `t/ptrmangle`: `PTR_MANGLE`/`PTR_DEMANGLE`
-
-      * <https://sourceware.org/glibc/wiki/PointerEncryption>
-
-      * See also [[t/tls|t/tls]].
-
-      * b7f2d27dbd85f6a0966dc389ad4f8205085b7ae8 `ARM: Add pointer encryption
-        support.` may help to find all the places that need to be touched when
-        adding support.
-
-  * <a id=baselinechanges>Verify baseline changes, if we need any follow-up changes:</a>
-
-      * a11ec63713ea3903c482dc907a108be404191a02
-      * 7e2b0c8562b35155820f87b5ff02a8b6850344cc
-      * 8c0677fe5d91b7269364ca08fa08ed09e4c2d8c9
-      * 5a2a1d75043138e696222ced4560de2fb90b8024
-      * 5ae958d74180e2572d198bd7872c86f391de6da7
-      * 5b08ac571ff8e94fe96511a532f0d20997de5f52
-      * 3d04ff3a5d3ce3616837e1d15e03b6e1b360cf26
-      * b2ef2c014b9c66995a3eb4f310ae7c5c510279bf
-      * 63c4ed22b5048c8701d8806026c23cc95f0df756
-      * ac2b484c02b01307ab6bbe5d45ddbf16d64edf8c
-      * e35fcef8b739ed24e083ff8a3078ac14e101cf67
-      * 6fb8cbcb58a29fff73eb2101b34caa19a7f88eba
-      * 8a492a675e566dc1e666df0a86cbf541442cb179
-      * 5dbc3b6cc0b759bf4b22d851ccb9cbf3e3cbc6ef
-      * c86434ccb576a3ce35b5a74f72b9f03bd45b522a
-      * d22e4cc9397ed41534c9422d0b0ffef8c77bfa53
-      * 15bac72bac03faeb3b725b1d208c62160f0c3ad7
-      * c08fb0d7bba4015078406b28d3906ccc5fda9d5a
-      * 10b3bedcb03386cc280113f552479793e4bac35f
-      * 754f7da38b0904b4b989d3500cc8dd5be625cf6a
-      * 3cdaa6adb113a088fdfb87aa6d7747557eccc58d
-      * 962dba7828cf251a9025ccb43bc6effa30379b72
-      * 3162f12e58c3a848db883916843b332b9f8c9d39
-      * 1c06ba3100847da6bd1f2e011dc24fa8debd9615
-      * 84b9230c404aed4fd3a7bb3d045ca367043dde8c
-      * 090555538d4347a52807ba9f08cf20ed13206afe
-      * 817328eea788c746131cf151b64fd250200da333
-      * c3758feebf7c8786231465da664743c6f0ec79cc
-      * 1ac7a2c7b448c851eb8976fcc290a906a4075203
-      * c21cc9bcb38a87ff638d1099ca871d94a2192b31
-      * 6484ba5ef092b62b7d2112c0d976dbd6d1a40fde
-      * b8b4863d78bf26b39918fc753b03ed98ef262903
-      * b76b818e6fe2061e778b3a9bbe63c554c3f9b3c1
-      * 8e9f92e9d5d7737afdacf79b76d98c4c42980508 -- `_dl_map_object` in
-        `sysdeps/mach/hurd/dl-sysdep.c`
-      * 0e516e0e14f2f9783a21cd1727bc53776341f857
-      * a1fb5e3ebe9d38b5ae6c5bfbfaa04882d52355bc
-      * cf7c9078a5acdbb435498ace92cd81009637a971
-      * db753e2cfb2051ebf20dc089f87c5b1297cc2cff
-      * 4a531bb0b3b582cb693de9f76d2d97d970f9a5d5 -- looks good.
-      * 5bd6dc5c2c68fe98691db9b40f87d9b68ea9565b
-      * 451f001b50870604e1f2daef12f04f9f460d3997 +
-        a85b5cb4d4a5fc56e2b38638d270bf2daa67eb6c -- BZ10484.  `nptl/Versions
-        [libc] (GLIBC_PRIVATE): Export __libc_alloca_cutoff`.  We don't even
-        define it yet.  Also see
-        [[glibc___libc_alloca_cutoff_should_be_lowered]].
-      * 1086d70d916fd0eb969b3d89ff88abd35f6a5c34
-      * cfa28e560ef69372b9e15e9a2d924a0fbcfc7bca
-      * 8cf8ce1702c354a8266e3cfa6ab54c2467d1873f
-      * 68dc949774cb651d53541df4abdc60327f7e096b
-      * 70181fddf1467996bea393d13294ffe76b8a0853
-      * a77e8cbc394ab098aa1fc3f0a6645a38348d21ca
-      * 32465c3ea007065acd8ca8199f130cdf4068130d
-      * 18ba70a559c52719fd94a713cc380514d9d19125
-      * 620a05296fe3380b7441ba7720e8b25c48a8c28c
-      * [low] e6c61494125126d2ba77e5d99f83887a2ed49783 -- `Fix memory leak in
-        TLS of loaded objects.` Do we need to replicate `nptl/allocatestack.c`
-        hunk?
-      * 6e04cbbe79f5965809fdbf1f28d7ae8b4af74d31 +
-        1bfbe0d335d3fc44a492648b974a0db19975f6d8 -- `Fix
-        pathconf(_PC_BUF_SIZE).`
-      * 28377d1bf58625172a1734b92e835591d4d23a18 -- `Optimize fdopendir a bit.`
-      * 7fb90fb89bbdf273ab7ab96517fe1b156cd7aee1 +
-        6fb2dde3f1aa3a1419cb6c2dfa53dd1d506722a4 -- `Fix Linux getcwd for long
-        paths`
-      * f574184a0e4b6ed69a5d9a3234543fba6d2a7367 -- `Fix sched_setscheduler
-        call in spawn implementation`
-      * 3b85df27870a47ed1db84e948e37a5a50a178a92 +
-        f50ef8f1efdd1f2b040acbb8324604f168e8832a -- sysconf
-      * 68a3f91fcad464c4737c1eaed4ae0bf539801fb2 -- `Fix reporting of invalid
-        timeouts in emulated pselect`
-      * ea389b12b3b65c4a7fa91fa76f8c99867eb37865 -- `strndup -> __strndup`;
-        strndupa?
-      * 7e4afad5bcf49e03c3b987399c6a8f66a9018660 -- `Nicer output for negative
-        error numbers in strerror_r`.  Change needed for
-        `sysdeps/mach/_strerror.c`?
-      * 7ea72f99966a65a56aedba817ee2413ff9b1f23c +
-        adcd5c15d2a37794d021104160b425ff61f88219 -- `Always fill output buffer
-        in XPG strerror function`.  Change needed for
-        `sysdeps/mach/xpg-strerror.c`?
-      * a91710475294c66d0005bdaae0919d36ef8ce3d2 -- sotruss ([[debugging]],
-        [[profiling]]).  Does it work?
-      * b1ebd700c5295a449f8d114740f0d1fb6e6b2eb5 +
-        80e2212d8e59933a1641f029ebd360526ff0e074 +
-        4997db742946d08be4378cf91221f558f928bc73 -- `Don't document si_code
-        used for raise()`.  Also for `bits/siginfo.h`?
-      * 11988f8f9656042c3dfd9002ac85dff33173b9bd -- pldd, Does it work?
-        Probably not: needs `/proc/[PID]/auxv`, `/proc/[PID]/exe`,
-        `/proc/[PID]/mem` ([[!tag open_issue_hurd]],
-        [[hurd/translator/procfs]]).
-      * 9113ea1f3f29b3aee710efc829e85a9772bcb836 -- `--experimental-malloc`.
-        Watch what happens.
-      * 4e34ac6a1e256f40ab0d8eeed37aa1ea83440e76 -- `-defsym=_begin=0`.  Watch
-        what happens.  Native build: apparently OK.
-      * f781ef4015504e8a1da649c266584976238aa079 (`--with-default-link`) +
-        1b74661a6b93a892ecb1c717dedeedba5c2a976c +
-        fd5e21c75d8e9221d766f4bc922a237265514ec2.  Watch what happens.  Native
-        build: `use-default-link = no`.
-      * de283087c74f720cf8a7171972e72b5fa2b45e79 (`Handle Lustre filesystem`),
-        4e5f31c847982997c856f03bbc35134e9fd0f61f (`Handle ext4 in
-        {,f}pathconf`).  What about stuff like that for us?
-      * d30cf5bb00bfb286ff14d931fb69f5b53724bcdc (`Find readelf with
-        AC_CHECK_TOOL`).  Aren't there more in other configure.in and Makefile
-        files?
-      * 7a03a9c8c4b37b88ac5e82b557d974f3161ddaf9 (`Add read barriers in
-        cancellation initialization`).  Is this needed in other places, too?
-      * [low] 5744c68d78f6ca6c6500e2c8d3d85b3a31f4ed2a (`Align x86 TCB to 64
-        bytes`).  Probably we have hidden somewhere such a constant, too (in
-        libpthread).
-      * d96de9634a334af16c0ac711074c15ac1762b23c +
-        ecb1482ffd85fd3279642b1dc045aa867ad4d415 (`Try shell in posix_spawn*
-        only in compat mode`).  Change looks good, but what about
-        `SPAWN_XFLAGS_TRY_SHELL` for us?
-      * 3ce1f2959437e952b9db4eaeed2407424f11a4d1 (`Make several tool features
-        mandatory and simplify the code.`).  Generally looks good.
-          * `locale/global-locale.c`: Apparently, no one is using
-            `_HURD_THREADVAR_LOCALE`.  But it is exported via
-            `hurd/threadvar.h`.
-          * `mach/devstream.c`: reversed.  Fixed in
-            `t/repair-mach_devstream.c`.
-          * `malloc/arena.c`: should be OK.
-      * `Remove support for !USE___THREAD`.
-        d063d164335938d557460bebaa7cfe388157b627 (generally looks good;
-        `csu/errno-loc.c` (should be OK); `include/errno.h` (fixed)) +
-        (de82006d43e198fd162807c9adc720c7ebd728a3 +
-        037e9fe21c92216ef7032ea2796781ec27ca182a) +
-        995a80dfbcb443ead5aa22682c884ec5c827a2ea (discussing) +
-        bc7e1c3667b577ad418f7520df2a7dbccea04ee9 (should be ok).
-      * [OK] 22a89187139a9083ca73989bfd11597e0f85cb61 (`malloc: Remove all
-        kinds of unused configuration options and dead code.`).  `NO_STARTER`
-        changes (should be OK).
-      * [high] `pagesize`, 02d46fc4b969e25e4ba0c54aa95fa98d7279bd05 (`Simplify
-        malloc initialization`); aebae0537dcb408100b88c6b7647a7e858c43237,
-        [[!sourceware_PR 11929]].  Is this all kosher for us?  See
-        [[!message-id "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]].
-      * [OK] 83cd14204559abbb52635006832eaf4d2f42514a (`Remove --wth-tls
-        option, TLS support is required`).
-      * a7c8e6a1478de9f990b11e5e853318ccbe4330f2 (`Fix invalid conversion in
-        __cmsg_nxthdr`).  Probably just a C++ thing and not relevant for us;
-        see [[!message-id "87r52nk1kx.fsf@kepler.schwinge.homeip.net"]].
-      * [low] `mmap`, 110946e473b38fc3896212e416d9d7064fecd5b7.  Kosher with
-        respect to our [[glibc/mmap]] peculiarities?
-      * [OK] `__attribute__ ((__leaf__))`, `BZ #13344`,
-        aa78043a4aafe5db1a1a76d544a833b63b4c5f5c +
-        49a43d80ec5c97cf6136b1ee2687414773b2d5aa +
-        3871f58f065dac3917eb18220a479e9591769c8c +
-        9beb2334930db81ceada5aa6051fe5ac0554db32 +
-        0ffc4f3ebaace42cd545db55a2ac50b6e0cc7d89 +
-        edc5984d4d18296d7aa3d8f4ed8f7336a743170e +
-        57769839788e2c62b68d9dfbf4b35052321278ba.
-        <http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>.
-      * [low] `conformtest`, 3134156779108fe8b46e0f4cd60d837572faaa93 +
-        4efeffc1d583597e4f52985b9747269e47b754e2 +
-        d94a4670800de6e8f088b8630ad5142866127980 -- should probably mirror
-        `bits/siginfo.h` changes.
-      * [low] stack guard, 6c6a98c983c44b440ae66d2aa8f32529a9dd7bfe,
-        [[!message-id "4F3BE241.9090409@mentor.com"]] -- anything needed for
-        us?
-      * [low] `libc-lockP.h` 9463518d0d314d7bd0160315e0ef30e15be08985 --
-        probably should do similar changes, also to the generic file.
-      * [low] `bits/socket.h`/`bits/socket_type.h` [[!message-id
-        "Pine.LNX.4.64.1203090206420.18868@digraph.polyomino.org.uk"]]
-        02a6f887cb3e2c048937111eb4cf150d397609de -- probably should do the same
-        for the generic version as used by GNU Hurd.
-      * [low] CFI for `_start`, 6a1bd2a100c958d30bbfe8c9b8f9071d24b7c3f4,
-        [[!message-id "20120316180551.GA6291@host2.jankratochvil.net"]] -- what
-        about other architectures?
-      * `linkobj/libc.so`, 510bbf14b4f25fec8ee3a2d24de3f24bdbf84333 -- need to
-        adapt for (conditional?) Sun RPC reversion (if that was the original
-        cause for the patch)?
-      * [low] `Add __fsword_t and use it in bits/statfs.h`,
-        3e5aef87d76cfa7354f2b0d82b96e59280720796, [[!message-id
-        "20120517134700.GA19046@intel.com"]] -- only updates one copy of
-        `bits/statfs.h`; update the others, too, for consistency.
-      * [low] 789bd351b45f024b7f51e4886bf46b8e887ab6da: remove
-        `libc_hidden_def` in `sysdeps/mach/hurd/accept4.c`?
-      * 0948c3af9dfb3bc1312d6bed2f3a6bfd4e96eef4,
-        b80af2f40631871cf53a5e39d08d5d5516473b96,
-        04570aaa8ad88caad303f8afe469beb4cf851e17 `_dl_initial_dtv`: OK?
-      * [very low] ea4d37b3169908615b7c17c9c506c6a6c16b3a26 `Implement
-        POSIX-generic sleep via nanosleep rather than SIGARLM.`: any benefit
-        using that one (with `sysdeps/mach/nanosleep.c`) instead of
-        `sysdeps/mach/sleep.c`?
-      * ea4d37b3169908615b7c17c9c506c6a6c16b3a26 -- IRC, freenode, #hurd,
-        2012-11-20, pinotree: »tschwinge: i agree on your comments on
-        ea4d37b3169908615b7c17c9c506c6a6c16b3a26, especially since mach's
-        sleep.c is buggy (not considers interruption, extra time() (= RPC)
-        call)«.
-      * ba384f6ed9275f3966505f2375b56d169e3dc588,
-        0409959c86f6840510851a851a1588677a2e537b,
-        e57b0c6100e63bfd816ae59339452eafc81f1d3a `C++11 thread_local
-        destructors support`.  Anything needed to be done in our [[libpthread]]
-        and configured for us in [[GCC]]?  Probably need to replicate the
-        `nptl/pthread_create.c` change, and fix
-        `stdlib/Makefile`:`$(objpfx)tst-tls-atexit`.
-
-            +++ include/link.h
-            @@ -302,6 +302,9 @@ struct link_map
-            +    /* Number of thread_local objects constructed by this DSO.  */
-            +    size_t l_tls_dtor_count;
-            
-            +++ include/stdlib.h
-            @@ -100,6 +100,11 @@ extern int __cxa_atexit (void (*func) (void *), void *arg, void *d);
-            +extern int __cxa_thread_atexit_impl (void (*func) (void *), void *arg,
-            +                                    void *d);
-            +extern void __call_tls_dtors (void);
-            +libc_hidden_proto (__call_tls_dtors);
-            
-            +++ nptl/pthread_create.c
-            @@ -311,6 +311,9 @@ start_thread (void *arg)
-             [after the thread function returns]
-            +  /* Call destructors for the thread_local TLS variables.  */
-            +  __call_tls_dtors ();
-            
-            +++ stdlib/Makefile
-            +$(objpfx)tst-tls-atexit = $(common-objpfx)nptl/libpthread.so \
-            +                        $(common-objpfx)dlfcn/libdl.so
-            
-            +++ stdlib/cxa_thread_atexit_impl.c
-            
-            +++ stdlib/exit.c
-             __run_exit_handlers (int status, struct exit_function_list **listp,
-                                 bool run_list_atexit)
-             {
-            +  /* First, call the TLS destructors.  */
-            +  __call_tls_dtors ();
-
-            +gcc-4.7 tst-tls-atexit.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parenth
-            +gcc-4.7 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build/stdlib/tst-tls-atexit   [...]/tschwinge/Roger_Whittaker.build/nptl/lib
-            +gcc-4.7: error: [...]/tschwinge/Roger_Whittaker.build/nptl/libpthread.so: No such file or directory
-            +make[2]: *** [[...]/tschwinge/Roger_Whittaker.build/stdlib/tst-tls-atexit] Error 1
-            +gcc-4.7 tst-tls-atexit-lib.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-par
-            +tst-tls-atexit-lib.c: In function 'do_foo':
-            +tst-tls-atexit-lib.c:35:3: warning: implicit declaration of function '__cxa_thread_atexit_impl' [-Wimplicit-function-declaration]
-      * a600e5cef53e10147932d910cdb2fdfc62afae4e `Consolidate Linux and POSIX
-        libc_fatal code.` -- is `backtrace_and_maps` specific to Linux?
-
-        IRC, freenode, #hurd, 2014-02-06:
-
-            <braunr> why wouldn't glibc double free detection code also print
-              the backtrace on hurd ?
-            <youpi> I don't see any reason why
-            <youpi> except missing telling glibc that it's essentially like on
-              linux
-
-      * 288f7d79fe2dcc8e62c539f57b25d7662a2cd5ff `Use __ehdr_start, if
-        available, as fallback for AT_PHDR.` -- once we require Binutils 2.23,
-        can we simplify [[glibc's process startup|glibc/process]]
-        (initialization of `_dl_phdr` and `_dl_phnum`)?  As these are only used
-        for `[!SHARED]`, can we completely remove them (that is, the `phdr` and
-        `phdrsz` members) from `hurd_startup_data`, and simplify
-        [[hurd/interface/exec_startup_get_info]], or do we still require these
-        for the `[SHARED]` case?
-      * fab7ce3f5b4060bf62659e8b58529de4156b5a2f `Link extra-libs consistently
-        with libc and ld.so.`  Alright for us?  Probably have to adjust
-        [libpthread]/Makefile.
-      * b8c61b4b1d6afb69190169764c1b141f4659e48b `Remove trailing whitespace
-        from mach/*.sub.`  Update `mach/Makefile`: generated
-        `mach/errsystems.c` is no longer checked in as of
-        66e3dda448406399136e6f144a1b46679d5b2613.  Rule had been disabled in
-        421f82e5cc8f81ab003247d771bcecbad799be85, then re-enabled in
-        8e3cc80f6d4f69ce003c82d3561ac324692792ad, but comment not removed.
-      * [low] 61dd6208fb1e59a423b6dfa712a3c896c34b2590 `New API to set default
-        thread attributes`.  Implement in libpthread ([[!taglink
-        open_issue_libpthread]])?
-      * [high] e4608715e6e1dd2adc91982fd151d5ba4f761d69 `CVE-2013-2207, BZ
-        #15755: Disable pt_chown. -- [[!message-id
-        "51E8D4C1.9000705@redhat.com"]]; do we need it (`--enable-pt_chown`)?
-	cdfc721b8d2d5079325ea9f0beb5673d72b4cdd0.
-      * 91ce40854d0b7f865cf5024ef95a8026b76096f3 `CVE-2013-4237, BZ #14699:
-        Buffer overflow in readdir_r` -- [[!message-id
-        "519220C7.6050705@redhat.com"]]; do we need corresponding changes to
-        Hurd sysdep files?
-      * 8cc3269f95fa7faa8f448d741f68cbc40efbf4ee `Flesh out 4.4 bits/socket.h
-        with SOCK_CLOEXEC, SOCK_NONBLOCK.`,
-        e041fb8b6557882b6710a655a97bbf3541b56b54 `Replace generic bits/socket.h
-        with 4.4 file.` -- `sysdeps/mach/hurd/bits/socket.h` differs from the
-        generic `bits/socket.h` now only in the values of
-        [[`SOCK_CLOEXEC`|secure_file_descriptor_handling]] and
-        `SOCK_NONBLOCK`.  If possible (no conflicts), would it make sense to
-        transition to the latter file, continuing to accept the former values
-        as deprecated for some time?
-      * [high] 6a97b62a5b4f18aea849d6f4d8de58d1469d2521 `Fix unsafe compiler
-        optimization` -- have to revert, see [[!sourceware_PR 15605]].  For
-        analysis/fix also look at 384ca551743318bd9c9e24a496d6397f2e3f2a49.
-      * 6c82a2f8d7c8e21e39237225c819f182ae438db3 `Coordinate IPv6 definitions
-        for Linux and glibc` -- alright for us?
-      * c61b4d41c9647a54a329aa021341c0eb032b793e `POINTER_CHK_GUARD` -- see
-        [[t/tls|t/tls]].
-      * 5f855e3598a576c35e54623a13b256f3e87fcd4d `Fix erroneous (and circular)
-        implied pattern rule for linkobj/libc.so.` -- alright for us?
-      * [high] 7b7bab1391a3b16fff7e325e2c8a36b68eacba90 [Hurd] `Add fork hooks
-        for pthread_atfork` -- is that from a topic branch that can then be
-        annihilated?  Verify emails.  Verify no further changes in topic
-        branch.
-      * [high] 43d5c02c72bdaf59a8e0d4b06f2ae87e42269cbd `Fix build on hurd` --
-        is that from a topic branch that can then be annihilated?  Verify
-        emails.  Verify no further changes in topic branch.
-      * 69a17d9d245dc3551792e95e1823cc2d877592f3 `Patch [1/4] async-signal safe
-        TLS.` -- do we also need an implementation of this?  (Not yet called
-        from anywhere?)
-      * *baseline*
-
-
-## Update
-
-`baseline`, `t/regenerate_configure` (could now be removed),
-`t/master_backports`, `t/eglibc_backports`, `t/host-independency`,
-`tschwinge/Roger_Whittaker`
-
-
-# Build
-
-Here's a log of a glibc build run; this is from our [[Git repository's
-f57644d0bdfc1ebe2201a677a33af27e09a5bab6 (2013-12-20;
-64a17f1adde4715bb6607f64decd73b2df9e6852 (2013-12-19))
-plus 6a97b62a5b4f18aea849d6f4d8de58d1469d2521 reverted,
-`id:"87zjnvn688.fsf@kepler.schwinge.homeip.net"`,
-`id:"87ioujn0eq.fsf@kepler.schwinge.homeip.net"`,
-1226676cd6f6f4451e6e6b75b8fbd9a35c949e8e reverted,
-56798c444bc584c118b69a3506c4050b34edc35f reverted,
-`id:"878uvfmwvs.fsf@kepler.schwinge.homeip.net"`
-sources|source_repositories/glibc]], run on coulomb.SCHWINGE.
-
-    $ export LC_ALL=C
-    $ ../Roger_Whittaker/configure --prefix=/usr --disable-profile --disable-multi-arch --build=i486-gnu --host=i486-gnu CC=gcc-4.7 CXX=g++-4.7 2>&1 | tee log_build
-    [...]
-    $ make install_root=/INVALID 2>&1 | tee log_build_
-    [...]
-
-This takes up around 600 MiB, and needs roughly X min on kepler.SCHWINGE and
-105 min on coulomb.SCHWINGE.
-
-<!--
-
-    $ (make install_root=/INVALID && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install_root="$PWD".install install && touch .go-test) 2>&1 | tee log_install && test -f .go-test && ln -s /usr/lib/i386-*gnu/libstdc++.so.6 /lib/i386-*gnu/libgcc_s.so.1 mach/libmachuser.so.1 hurd/libhurduser.so.0.3 ./ && make -k install_root=/INVALID check fast-check=yes 2>&1 | tee log_test
-
--->
-
-
-## Analysis
-
-    $ toolchain/logs/process glibc build fetch coulomb.SCHWINGE
-
-TODO.
-
-  * baseline
-    fd5bdc0924e0cfd1688b632068c1b26f3b0c88da..2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b
-    (or probably Samuel's mmap backport) introduces:
-
-        ../sysdeps/mach/hurd/mmap.c: In function '__mmap':
-        ../sysdeps/mach/hurd/mmap.c:54:15: warning: comparison between pointer and integer [enabled by default]
-        ../sysdeps/mach/hurd/mmap.c:66:21: warning: comparison between pointer and integer [enabled by default]
-        ../sysdeps/mach/hurd/mmap.c:143:13: warning: comparison between pointer and integer [enabled by default]
-        ../sysdeps/mach/hurd/mmap.c:165:24: warning: comparison between pointer and integer [enabled by default]
-
-  * baseline
-    fd5bdc0924e0cfd1688b632068c1b26f3b0c88da..2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b
-    introduces:
-
-        nscd_gethst_r.c: In function '__nscd_get_nl_timestamp':
-        nscd_gethst_r.c:112:4: warning: implicit declaration of function 'time' [-Wimplicit-function-declaration]
-
-    This was already present before:
-
-        nscd_gethst_r.c: In function 'nscd_gethst_r':
-        nscd_gethst_r.c:426:5: warning: implicit declaration of function '__close' [-Wimplicit-function-declaration]
-
-  * baseline
-    2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b..7a270350a9bc3110cd5ba12bbd8c5c8c365e0032
-    introduces:
-
-        tst-relsort1.c:6:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]
-
-  * baseline
-    fc56c5bbc1a0d56b9b49171dd377c73c268ebcfd..cbc818d0ee66065f3942beffdca82986615aa19a
-    introduces
-
-        +gcc-4.6 tst-printf-round.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes         -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4.
-        +tst-printf-round.c: In function 'do_test':
-        +tst-printf-round.c:203:11: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default]
-        +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*'
-        +tst-printf-round.c:208:8: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default]
-        +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*'
-        +tst-printf-round.c:216:8: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default]
-        +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*'
-        +tst-printf-round.c:224:8: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default]
-        +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*'
-
-         gcc-4.6 test-wcschr.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes         -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486
-        +In file included from test-wcschr.c:2:0:
-        +../string/test-strchr.c: In function 'check1':
-        +../string/test-strchr.c:249:3: warning: passing argument 1 of 'stupid_STRCHR' from incompatible pointer type [enabled by default]
-        +../string/test-strchr.c:77:1: note: expected 'const wchar_t *' but argument is of type 'char *'
-        +../string/test-strchr.c:249:22: warning: initialization from incompatible pointer type [enabled by default]
-        +../string/test-strchr.c:252:5: warning: passing argument 2 of 'check_result' from incompatible pointer type [enabled by default]
-        +../string/test-strchr.c:92:1: note: expected 'const wchar_t *' but argument is of type 'char *'
-        +../string/test-strchr.c:252:5: warning: passing argument 4 of 'check_result' from incompatible pointer type [enabled by default]
-        +../string/test-strchr.c:92:1: note: expected 'const wchar_t *' but argument is of type 'char *'
-
-
-# Install
-
-TODO.
-
-    $ make install_root="$PWD".install install 2>&1 | tee log_install
-    [...]
-
-This takes up around 100 MiB, and needs roughly X min on kepler.SCHWINGE and 16
-min on coulomb.SCHWINGE.
-
-
-## Analysis
-
-    $ toolchain/logs/process glibc install fetch coulomb.SCHWINGE
-
-TODO.
-
-
-# Testsuite
-
-    $ make -k install_root=/INVALID check fast-check=yes 2>&1 | tee log_test
-    [...]
-
-This needs roughly X min on kepler.SCHWINGE and 130 min on coulomb.SCHWINGE.
-
-Specifying `fast-check=yes` disables the `conformtest` which takes 1.75 h (out
-of 2.75 h total) on coulomb.SCHWINGE, doesn't pass anyway, and clearly isn't
-our most critical issue to solve.
-`elf/tst-xmmymm.out` is another candidate to disable: needs 90 min to run.
-
-
-## Analysis
-
-    $ toolchain/logs/process glibc test fetch coulomb.SCHWINGE
-
-Failures, mostly in order of appearance:
-
-  * `check-abi`, `check-abi-libmachuser`, `check-abi-libhurduser`,
-    `check-abi-libBrokenLocale`, `check-abi-libm`, `check-abi-libdl`,
-    `check-abi-libcrypt`, `check-abi-libresolv`, `check-abi-librt`,
-    `check-abi-libnsl`, `check-abi-libutil`, `check-abi-libc`, `check-abi-ld`,
-    `c++-types.data`
-
-    Reference files are missing.
-
-  * `math/test-float.out`, `math/test-double.out`
-
-    A handful of ULP failures.
-
-  * `math/test-ldouble`, `math/test-ildoubl`, `math/test-ifloat`,
-    `math/test-idouble`
-
-    SIGSEGV.  Or SIGILL.
-
-  * `stdlib/tst-secure-getenv.out`
-
-        open (/proc/self/exe): No such file or directory
-
-    Needs [[`/proc/self/exe`|hurd/translator/procfs/jkoenig/discussion]].
-
-  * `stdlib/tst-strtod-round.out`
-
-        strtold (-0x0.7p-16445) returned -0x0.0000000000008p-16385 not -0x0.000000000000001p-16385 (FE_DOWNWARD)
-        strtold (-0x0.7p-16494) returned -0x0.0000000000008p-16385 not -0x0.000000000000001p-16385 (FE_DOWNWARD)
-
-  * `stdio-common/bug22.out`
-
-        Timed out: killed the child process
-
-    Known problem.
-
-  * `libio/tst-atime.out`, `dirent/tst-fdopendir.out`
-
-    [[!message-id "201305102256.56636.toscano.pino@tiscali.it"]].
-
-    `libio/tst-atime.out`:
-
-        atime has not changed
-
-    Due to `ext2fs --no-atime`.
-
-      * IRC, OFTC, #debian-hurd, 2013-05-08
-
-            <youpi> bah, tst-atime failure :)
-            <pinotree> do you have its output?
-            <youpi> well it's very simple
-            <youpi> I have the noatime option on / :)
-            <pinotree> oh
-            <youpi> fortunately fsysopts works :)
-            <pinotree> the test checks whether ST_NOATIME is in the mount
-              options, maybe it would be a good idea to provide it
-            <youpi> yes
-            <pinotree> unfortunately it isn't in posix, so i'm not sure whether
-              adding it to the general bits/statvfs.h would be welcome
-            <pinotree> or whether we should fork it, like it is done for linux 
-            <pinotree> oh no, we fork it already
-            <pinotree> \o/
-
-    `dirent/tst-fdopendir.out`:
-
-        directory atime changed
-
-    Due to `ext2fs --atime` (default).
-
-  * `libio/tst-fopenloc.check`, `posix/bug-regex31-mem`,
-    `posix/tst-fnmatch-mem`, `misc/tst-error1-mem`
-
-        Memory not freed:
-        -----------------
-           Address     Size     Caller
-        0x0807e268   0x8000  at 0x10c71c4
-
-    Caused by different memory allocation way in libio, see
-    [[!message-id "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]]
-
-  * `dlfcn/bug-atexit3.out`
-
-    Originally:
-
-        dlopen failed: libstdc++.so.6: cannot open shared object file: No such file or directory
-
-    See [[!message-id "20090420002344.11798.qmail@s461.sureserver.com"]].
-    Hacked around with `ln -s /usr/lib/i386-*gnu/libstdc++.so.6
-    /lib/i386-*gnu/libpthread-stubs.so.0 /lib/i386-*gnu/libgcc_s.so.1 ./`.
-    This is a bug in the glibc test harness.  Should probably use some
-    `configure` magic akin to the `fixincludes` stuff (`gcc-4.4
-    -print-file-name=libstdc++.so.6`, etc.).
-
-    Even if that that is being worked around, the tests nowadays
-    ([[packaging_libpthread]]) fail with:
-
-        dlopen failed: [...]/libc.so.0.3: version `GLIBC_2.13_DEBIAN_31' not found (required by [...]/libstdc++.so.6)
-
-  * `dlfcn/tststatic.out`, `dlfcn/tststatic2.out`, `dlfcn/tststatic3.out`,
-    `dlfcn/tststatic4.out`, `dlfcn/tststatic5.out`
-
-    SIGSEGV.
-
-    `LD_LIBRARY_PATH` doesn't contain the `mach` and `hurd` directories; yet
-    the test shouldn't just SIGSEGV.
-
-  * `dirent/opendir-tst1.out`, `dirent/tst-fdopendir2.out`
-
-    `dirent/opendir-tst1.out`:
-
-        `opendir' succeeded on a FIFO???
-
-    `dirent/tst-fdopendir2.out`:
-
-        fdopendir with normal file descriptor did not fail
-
-    `opendir` and `fdopendir` do not return `ENOTDIR` if `fd` is not a
-    directory.
-
-  * `posix/tst-waitid.out`
-
-    Intermittent.
-
-        SIGCHLD for stopped status 0
-        SIGCHLD for stopped pid -1
-        SIGCHLD for killed code 1
-        SIGCHLD for killed status 0
-        SIGCHLD for killed pid -1
-
-  * `posix/bug-glob2.out`
-
-    Intermittent.
-
-        Timed out: killed the child process
-
-  * `posix/annexc.out`
-
-    Failure ignored by the glibc testsuite.
-
-  * `posix/tst-getconf.out`
-
-    Ends with:
-
-        getconf POSIX_ALLOC_SIZE_MIN /: [...]/posix/getconf: pathconf: /: Invalid argument
-
-    It fails because of unimplemented pathconf cases: `_PC_ALLOC_SIZE_MIN`,
-    `_PC_REC_INCR_XFER_SIZE`, `_PC_REC_MAX_XFER_SIZE`, `_PC_REC_MIN_XFER_SIZE`,
-    `_PC_REC_XFER_ALIGN`, `_PC_SYMLINK_MAX`, `_PC_2_SYMLINKS`.
-
-    `_CS_GNU_LIBPTHREAD_VERSION` is provided by libpthread when compiled as
-    add-on.
-
-  * `posix/tst-vfork3-mem`
-
-        + 0x0804cee0 Alloc 10 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
-        + 0x0804cf90 Alloc 11 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
-        + 0x0804cfa8 Alloc 12 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
-        + 0x00000008 Alloc 17 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
-        + 0x0804cee0 Alloc 18 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
-        + 0x0804cf90 Alloc 19 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
-        + 0x0804cfa8 Alloc 20 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
-        + 0x00000008 Alloc 25 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
-        + 0x0804cee0 Alloc 26 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
-        + 0x0804cf90 Alloc 27 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
-        + 0x0804cfa8 Alloc 28 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
-        + 0x00000008 Alloc 33 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
-        + 0x0804cee0 Alloc 34 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
-        + 0x0804cf90 Alloc 35 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
-        + 0x0804cfa8 Alloc 36 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
-        + 0x00000008 Alloc 41 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
-        + 0x0804cee0 Alloc 42 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
-        + 0x0804cf90 Alloc 43 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
-        + 0x0804cfa8 Alloc 44 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
-        + 0x00000008 Alloc 49 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
-        + 0x0804cee0 Alloc 50 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
-        + 0x0804cf90 Alloc 51 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
-        + 0x0804cfa8 Alloc 52 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
-        + 0x00000008 Alloc 57 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
-        + 0x0804cee0 Alloc 58 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
-        + 0x0804cf90 Alloc 59 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
-        + 0x0804cfa8 Alloc 60 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
-        + 0x00000008 Alloc 65 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
-        + 0x0804cee0 Alloc 66 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
-        + 0x0804cf90 Alloc 67 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
-        + 0x0804cfa8 Alloc 68 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
-        + 0x00000008 Alloc 73 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
-        + 0x0804cee0 Alloc 74 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
-        + 0x0804cf90 Alloc 75 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
-        + 0x0804cfa8 Alloc 76 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
-        + 0x00000008 Alloc 81 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
-        + 0x0804cee0 Alloc 82 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
-        + 0x0804cf90 Alloc 83 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
-        - 0x0804c8d8 Free 84 was never alloc'd 0x10955fc
-        - 0x0804c960 Free 87 was never alloc'd 0x115672f
-        - 0x0804c9b8 Free 88 was never alloc'd 0x1156737
-        
-        Memory not freed:
-        -----------------
-           Address     Size     Caller
-        0x0804cfa8     0x73  at 0x10df0c8
-        0x00000008        0  at 0x10df0c8
-
-    Perhps because we implement `vfork` in terms of `fork` (`posix/vfork.c`)?
-
-  * `posix/tst-pathconf.out`
-
-        pathconf on directory failed: (os/kern) successful
-
-  * `io/test-lfs.out`
-
-        /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build/io/test-lfs: cannot write test string to large file: Invalid argument
-
-  * `io/tst-futimesat.out`
-
-        file created
-        futimesat failed
-
-    `futimesat` is a stub.
-
-  * `misc/tst-pselect.o`
-
-        tst-pselect.c: In function 'do_test':
-        tst-pselect.c:33:17: error: 'SA_NOCLDWAIT' undeclared (first use in this function)
-
-  * `gmon/tst-sprofil.out`
-
-        Floating point exception
-
-  * `nss//libnss_test1.so`
-
-        [...]/nss/nss_test1.os: In function `_nss_test1_getpwent_r':
-        [...]/nss/nss_test1.c:60: undefined reference to `pthread_mutex_lock'
-        [...]/nss/nss_test1.c:85: undefined reference to `pthread_mutex_unlock'
-
-  * `rt/tst-shm.out`
-
-        read file outside of SHMDIR directory: (os/kern) successful
-
-  * `rt/tst-timer.out`
-
-    No message.
-
-  * `rt/tst-timer2.o`
-
-        tst-timer2.c: In function 'do_test':
-        tst-timer2.c:33:23: error: 'SIGRTMIN' undeclared (first use in this function)
-
-  * `rt/tst-aio2`, `rt/tst-aio3`, `rt/tst-aio9`, `rt/tst-aio10`,
-    `rt/tst-mqueue3`, `rt/tst-mqueue5.o`, `rt/tst-mqueue6`, `rt/tst-mqueue8`,
-    `rt/tst-timer3`, `rt/tst-timer4.o`, `rt/tst-timer5.o`,
-    `rt/tst-cputimer1.o`, `rt/tst-cputimer2.o`, `rt/tst-cputimer3.o`,
-    `elf/tst-thrlock`
-
-        [...]/rt/tst-aio2.o: In function `do_test':
-        [...]/rt/tst-aio2.c:62: undefined reference to `pthread_barrier_init'
-        [...]/rt/tst-aio2.c:94: undefined reference to `pthread_barrier_wait'
-        [...]/rt/tst-aio2.o: In function `thrfct':
-        [...]/rt/tst-aio2.c:35: undefined reference to `pthread_barrier_wait'
-
-        tst-mqueue5.c: In function 'rtmin_handler':
-        tst-mqueue5.c:50:14: error: 'SIGRTMIN' undeclared (first use in this function)
-
-        [...]/rt/tst-mqueue6.o: In function `do_test':
-        [...]/rt/tst-mqueue6.c:127: undefined reference to `pthread_attr_init'
-        [...]/rt/tst-mqueue6.c:149: undefined reference to `pthread_attr_setguardsize'
-        [...]/rt/tst-mqueue6.c:211: undefined reference to `pthread_attr_setguardsize'
-        [...]/rt/tst-mqueue6.c:262: undefined reference to `pthread_attr_destroy'
-        [...]/rt/tst-mqueue6.c:128: undefined reference to `pthread_attr_setguardsize'
-        [...]/rt/tst-mqueue6.o: In function `fct':
-        [...]/rt/tst-mqueue6.c:79: undefined reference to `pthread_self'
-        [...]/rt/tst-mqueue6.c:79: undefined reference to `pthread_getattr_np'
-        [...]/rt/tst-mqueue6.c:88: undefined reference to `pthread_attr_getguardsize'
-        [...]/rt/tst-mqueue6.c:95: undefined reference to `pthread_attr_destroy'
-        [...]/rt/tst-mqueue6.c:95: undefined reference to `pthread_attr_destroy'
-
-        [...]/elf/tst-thrlock.o: In function `do_test':
-        [...]/elf/tst-thrlock.c:38: undefined reference to `pthread_create'
-        [...]/elf/tst-thrlock.c:48: undefined reference to `pthread_join'
-
-  * `rt/tst-aio8.out`
-
-        r = -1, e = 1073741902 (Function not implemented)
-
-    Should work with [[!message-id
-    "201209302353.51055.toscano.pino@tiscali.it"]] in libpthread.
-
-  * `debug/tst-chk1.out`
-
-    Intermittent.  Timeout.  Unknown.
-
-  * `debug/tst-chk2.out`, `debug/tst-chk3.out`, `debug/tst-lfschk2.out`,
-    `debug/tst-lfschk3.out`
-
-    Unknown.
-
-  * `debug/tst-chk4.out`, `debug/tst-chk5.out`, `debug/tst-chk6.out`,
-    `debug/tst-lfschk4.out`, `debug/tst-lfschk5.out`, `debug/tst-lfschk6.out`
-
-        [...]/debug/tst-chk4: [...]/libc.so.0.3: version `GLIBC_2.13_DEBIAN_31' not found (required by [...]/libstdc++.so.6)
-        [...]/debug/tst-chk4: [...]/libc.so.0.3: version `GLIBC_2.13_DEBIAN_31' not found (required by [...]/libgcc_s.so.1)
-
-  * `debug/tst-longjmp_chk2.out`
-
-    SIGSEGV.
-
-        not on alternate stack
-         in signal handler
-         on alternate stack
-         out of signal handler
-         on alternate stack
-
-    It says *alternate stack*.
-
-  * `inet/tst-ether_line.o`
-
-        tst-ether_line.c: In function 'do_test':
-        tst-ether_line.c:19:19: error: 'ETH_ALEN' undeclared (first use in this function)
-
-    Will either need a `hurd/netinet/if_ether.h` that includes
-    `<net/if_ether.h>`, or can do that in the generic `netinet/if_ether.h`?
-    See also [[!sourceware_PR 11142]].
-
-  * `login/tst-grantpt.out`
-
-        posix_openpt(O_RDWR) failed
-        errno 1073741902 (Function not implemented)
-
-    `posix_openpt` is a stub.
-
-        grantpt(): expected: return = -1, errno = 1073741846
-                   got: return = -1, errno = -303
-
-    `grantpt` (actually `ptsname_r`), does not fail with `ENOTTY` when the `fd`
-    does not refer to a PTY master.
-
-  * `elf/tst-auxv.out`
-
-    SIGSEGV.
-
-  * `elf/tst-stackguard1-static.out`, `elf/tst-stackguard1.out`
-
-        differences 0 defaults 0
-        stack guard canaries are not randomized enough
-        nor equal to the default canary value
-
-    Sometimes times out.
-
-  * `elf/tst-ptrguard1-static.o`, `elf/tst-ptrguard1.o`
-
-        In file included from tst-ptrguard1-static.c:1:0:
-        tst-ptrguard1.c: In function 'con':
-        tst-ptrguard1.c:42:24: error: 'tcbhead_t' has no member named 'pointer_guard'
-        tst-ptrguard1.c: In function 'do_test':
-        tst-ptrguard1.c:65:29: error: 'tcbhead_t' has no member named 'pointer_guard'
-        tst-ptrguard1.c:104:30: error: 'tcbhead_t' has no member named 'pointer_guard'
-
-    See [[t/tls|t/tls]].
-
-  * `elf/tst-tls9-static.out`
-
-    SIGSEGV.
-
-  * `elf/tst-dlmopen1.out`
-
-    SIGSEGV.
-
-  * `elf/tst-audit1.out`, `elf/tst-audit2.out`, `elf/tst-audit8.out`
-
-    SIGKILL.
-
-  * `elf/tst-null-argv.out`
-
-        Inconsistency detected by ld.so: ../sysdeps/mach/hurd/dl-sysdep.c: 338: open_file: Assertion `!(flags & ~(0x0001 | 0x00400000))' failed!
-
-  * `elf/check-textrel.out`
-
-        $BUILDDIR/libc.so.dyn: *** text relocations used
-
-  * `elf/check-execstack.out`
-
-        $BUILDDIR/libc.so.phdr: *** executable stack signaled
-
-  * `elf/check-localplt.out`
-
-    Around 500 or so `Extra PLT reference`.
-
-  * `check-local-headers.out`
-
-    A lot.  Including `/usr/include/device/*.h`, `/usr/include/mach/*.h`,
-    `/usr/include/hurd/*.h`.
-
-  * `debug/tst-longjmp_chk2.out`, `debug/tst-longjmp_chk3.out`,
-    `debug/tst-longjmp_chk4.out`, `debug/tst-longjmp_chk5.out`,
-    `debug/tst-backtrace2.out`, `debug/tst-backtrace3.out`,
-    `debug/tst-backtrace4.out`, `debug/tst-backtrace5.out`
-    `debug/tst-backtrace6.out`
-
-    All say: `Obtained backtrace with 0 functions`.
-
-Earlier failures; no longer seen:
-
-  * `test-assert-perr.out`
-
-    Fails intermittently.  Unknown.
-
-  * `test-multiarch.out`
-
-    Needs [[`/proc/cpuinfo`|hurd/translator/procfs/jkoenig/discussion]]
-    providing the `flags` line.
-
-  * `elf/tst-array*`
-
-    No longer fail with GCC 4.7.
-    [[!message-id "50950082.1070906@df1tl.local.here"]].
-
-  * `io/ftwtest`, `posix/globtest`, `iconvdata/iconv-test`, `intl/tst-gettext`,
-    `malloc/tst-mtrace`, `elf/tst-pathopt`, `iconvdata/tst-tables`,
-    `grp/tst_fgetgrent`,
-    `posix/wordexp-tst`, `localedata/bug-setlocale1.out`, `posix/tst-getconf`
-
-        /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/io/ftwtest: error while loading shared libraries: libmachuser.so.1: cannot open shared object file: No such file or directory
-
-    Looking into `localedata/bug-setlocale1.c`, it is clear what it going on:
-    only the root of the build directory is added for `--library-path`, but
-    none of the other directories that are additionally used.  This is a bug in
-    the glibc test harness.  Hacked around by `ln -s mach/libmachuser.so.1
-    hurd/libhurduser.so.0.3 ./`.  Hopefully the other instances are similar.
-
-  * `assert/test-assert.out`
-
-    Fails sometimes...
-
-  * `math/test-fenv.out`
-
-    Used to fail (is listed in Debian eglibc-2.13-21's
-    `expected-results-i486-gnu-libc`), but something between
-    22bcba37dd3b782b1a1ec7bf51da468e48f4d2eb and
-    005b7594ffe209639dd1ef2b9ed9a4c22307dec1 causes it to passe -- very likely
-    Jérémie's signaling work.
-
-  * `elf/tst-unused-dep.out` (1f393a11f65dcaa1952bdcaf0317a65a5f8aff9d,
-    [[!sourceware_PR 13706]], [[!message-id "4F4210C1.1090704@redhat.com"]])
-
-        Unused direct dependencies:
-                /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.6-486/dlfcn/libdl.so.2
-
-    As of 8958805c11c741d9211e20612c86271d906c9a0b, this test now passes --
-    correct?
-
-  * `stdlib/bug-getcontext.out`
-
-        getcontext failed, errno: 1073741902.
-
-    Fixed, implemented in `t/context_functions`.
-
-  * `resource/bug-ulimit1.out`
-
-        Result of ulimit (UL_SETFSIZE, 10000): 0
-        Result of ulimit(UL_GETFSIZE): 10000
-
-    Buggy `sysdeps/unix/bsd/ulimit.c` return values.
-
-    Fixed, [[!message-id "201211182342.51619.toscano.pino@tiscali.it"]].
-
-Compared to Debian:
-
-    $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/convertlog.sh log_test  > log_test.filtered
-    $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/compare.sh ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/expected-results-i486-gnu-libc log_test.filtered
diff --git a/open_issues/glibc/debian.mdwn b/open_issues/glibc/debian.mdwn
deleted file mode 100644
index 2ef2c474..00000000
--- a/open_issues/glibc/debian.mdwn
+++ /dev/null
@@ -1,168 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2013 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]]."]]"""]]
-
-
-# Open Issues
-
-`threads = yes` is set in `debian/sysdeps/linux.mk` and
-`debian/sysdeps/kfreebsd.mk`, `debian/sysdeps/hurd.mk` set to `no`.  But this
-is only read in `debian/rules` for deciding some `nscd` package issue?
-
-`debian/sysdeps/hurd.mk`'s `libc_extra_install` for `ld.so`: check with GCC
-configuration.
-
-Could add a toggle to `$(stamp)build_%` in `debian/rules.d/build.mk` to skip
-locale stuff.
-
-`--disable-compatible-utmp`?
-
-
-## IRC, freenode, #hurd, 2013-08-28
-
-    <youpi> uh, the i686 profiles have much more progression than i386
-    <youpi> it seems they don't actually run these
-    <pinotree> youpi: what do you mean with "we don't run those"?
-    <pinotree> iirc there are three build profiles done, but there are 4
-      regression test files
-    <youpi> yes, but some failing tests are not run in the three build profiles
-    <youpi> even if they are built for all of them
-    <pinotree> not even run? which ones?
-    <youpi> see for instance test-ifloat.out
-    <youpi> test-ifloat is built in all profiles, but only run in the libc one
-    <pinotree> don't have a glibc built tree around atm, sorry :/
-    <youpi> perhaps because glibc thinks it's not useful to run it again if it
-      fails on i386
-    <youpi> you can check the logs
-    <pinotree> do you think glibc's build system is that smart? :)
-    <pinotree> all the builds are done in separate builddirs, so theorically
-      they should not touch each other...
-    <youpi> yes
-    <youpi> that's why I'm surprised
-    <pinotree> could it be they get not run in optimized/particular builds?
-    <pinotree> what about linux/kfreebsd i386?
-    <youpi> I don't see what  makes them not run
-    <youpi> or at least be treated particularly by th eMakefile
-    <youpi> not run on kfreebsd either
-    <youpi> pinotree: also, most of the tests now working have been marked as
-      failing by your patches for 2.17, would it be possible to retry them on
-      the box you used at that time?
-    <pinotree> that's the vm on my machine
-    <youpi> which kind of vm?
-    <youpi> kvm?
-    <pinotree> y
-    <youpi> they are working here
-    <youpi> with kvm
-
-
-# Building
-
-Run `debian/rules patch` to apply patches (instead of having it done during the
-build).  Then you can edit files manually.
-
-Several passes: `libc`, `i686`, `xen`; `EGLIBC_PASSES='libc i686'`, etc.
-
-If building with `EGLIBC_PASSES=libc` (more specifically, without `xen`), the
-`libc0.3-dev_extra_pkg_install` rule in `debian/sysdeps/hurd-i386.mk` will
-fail.  (Same for `libc6-dev_extra_pkg_install` in `debian/sysdeps/i386.mk`, for
-example.)  Why is this special handling only done for `xen`, but not for
-`i686`?
-
-> Samuel: Historically because it's done that way in linux-i386. I don't know
-> the real reason.
-
-Do `export LC_ALL=C` before building, otherwise the testsuite/make error
-messages will be different from those stored in the
-`debian/testsuite-checking/expected-results-*` files, resulting in a spurious
-build failure.
-
-Run `debian/rules build-arch DEB_BUILD_OPTIONS=parallel=2 [EGLIBC_PASSES=...]`
-to build (or `build` instead of `build-arch` to build the arch-independent
-stuff, too).  Can interrupt with `C-c` during locale stuff or testsuite if only
-interested in the build tree.
-
-Run `fakeroot debian/rules binary DEB_BUILD_OPTIONS=parallel=2
-[EGLIBC_PASSES=...]` to build Debian packages or `binary-arch` for just the
-architecture-dependent ones.
-
-The latter two steps can also be combined as `dpkg-buildpackage -R'debian/rules
-EGLIBC_PASSES=libc' -nc -b -uc`.  `-nc` will prevent the *clean step* which
-would first try to un-patch, which may conflict if you have done any edits
-apter applying patches.
-
-If the Debian symbol versioning file is not up to date and the build of Debian
-packages fails due to this, putting `DPKG_GENSYMBOLS_CHECK_LEVEL=0` in the
-environment \`\`helps''; see `man dpkg-gensymbols`.
-
-
-# IRC, freenode, #hurd, 2013-07-01
-
-    <braunr> something seems to have changed with regard to patch handling in
-      eglibc 2.17
-    <braunr> pinotree: when i add a patch to series and use dpkg-buildpackage,
-      i'm told there are local modifications and the build stops :/
-    <braunr> any idea what i'm doing wrong ?
-    <pinotree> which steps do you do?
-    <braunr> i extract the sources, copy the patch to debian/patches/hurd-i386,
-      add the appropriate line to debian/patches/series, call dch -i, then
-      dpkg-buildpackage
-    <pinotree> eglibc is a "3.0 (quilt)" format source package
-    <pinotree> this means its default patches are in a quilt-style system, and
-      they are applied on extraction
-    <braunr> ok
-    <braunr> and it can't detect new patches ?
-    <pinotree> so if you add a new patch to the global serie, you have to push
-      it manually
-    <braunr> i have to revert them all ?
-    <braunr> ok
-    <braunr> how do i do that ?
-    <pinotree> quilt push -a
-    <braunr> ok
-    <braunr> thanks
-    <pinotree> remember to do that before starting the build, since the rest
-      assumes the quilt-style patches are fully applied
-    <bddebian> No push applies them, quilt pop -a reverts them
-    <pinotree> yeah, and he has to push the new over the dpkg-applied ones
-    <bddebian> Oh, aye
-    <braunr> does quilt change series ?
-    <pinotree> no
-    <braunr> ok
-    <pinotree> i mean, some commands do that
-    <braunr> so i do everything i did, with an additional push, right ?
-    <pinotree> ok, screw me, i didn't get your question above :P
-    <braunr> does that change your answer ?
-    <pinotree> <braunr> does quilt change series ?
-    <braunr> yes
-    <pinotree> if you import or create a new patch, it changes series indeed
-    <braunr> ok
-    <pinotree> push or pop of patches does not
-    <braunr> i'm doing it wron
-    <braunr> g
-    <pinotree> btw, in a quilt patch stack you can easily import a new patch
-      using the import command
-    <pinotree> so for example you could do
-    <pinotree> apt-get source eglibc # or get it somehow else
-    <pinotree> cd eglibc-*
-    <pinotree> quilt import /location/of/my/patch
-    <pinotree> quilt push # now your patch is applied
-    <braunr> ah thanks
-    <pinotree> dpkg-buildpackage as usual
-    <braunr> that's what i was looking for
-    <bddebian> quilt new adds a new entry in series
-    <pinotree> y
-    <bddebian> or import, aye
-    <pinotree> braunr: if you want to learn quilt, a very good doc is its own,
-      eg /usr/share/doc/quilt/quilt.txt.gz
-    * bddebian has never actually used import
-    <braunr> ok
-    <pinotree> it is basically a simple stack of patches
-
-    <youpi> braunr: yes, patch handling is a bit different
-    <youpi> the arch-independant patches are applied by dpkg-source -x
-    <youpi> and the arch-dependent patches are applied during build
diff --git a/open_issues/glibc/debian/experimental.mdwn b/open_issues/glibc/debian/experimental.mdwn
deleted file mode 100644
index 4ae9807b..00000000
--- a/open_issues/glibc/debian/experimental.mdwn
+++ /dev/null
@@ -1,338 +0,0 @@
-[[!meta copyright="Copyright © 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]]
-
-Issues with the current 2.17 version of glibc/EGLIBC in Debian experimental.
-Now in unstable.
-
-
-# IRC, OFTC, #debian-hurd, 2013-03-14
-
-    <markus_w1nner> I have a strange tcp via localhost question:
-    <markus_wanner> The other side closes the connection, but I haven't read
-      all data, yet. I should still be able to read the pending data, no?
-    <markus_wanner> At least it seems to work that way on Linux, but not on
-      Hurd.
-    <markus_wanner> Got a simple repro with nc, if you're interested...
-    <youpi> markus_wanner: yes, we're interested
-    <markus_wanner> youpi: okay, here we go:
-    <markus_wanner> session 1: nc -l -p 7777 localhost
-    <markus_wanner> session 2: nc 127.0.0.1 7777
-    <markus_wanner> session 2: a <RET> b <RET> c <RET>
-    <markus_wanner> session 1: [ pause with Ctrl-Z ]
-    <markus_wanner> session 2: [ send more data ] d <RET> e <RET> f <RET>
-    <markus_wanner> session 2: [ quit with Ctrl-C ]
-    <markus_wanner> session 1: [ resume with 'fg' ]
-    <markus_wanner> The server on session 1 doesn't get the data sent after it
-      paused and before the client closed the connection.
-    <markus_wanner> I'm not sure if that's a valid TCP thing. However, on
-      Linux, the server still gets the data. On hurd it doesn't.
-    <markus_wanner> I'm working on a C-code test case, ATM.
-    <youpi> markus_wanner: on which box are you seeing this behavior?
-    <youpi> exodar does not have it
-    <youpi> i.e. I do get the d e f
-    <markus_wanner> a private VM (I'm not a DD)
-    <markus_wanner> ..updated to latest experimental stuff.
-    <markus_wanner> GNU lematur 0.3 GNU-Mach 1.3.99-486/Hurd-0.3 i686-AT386 GNU
-    <youpi> ok, I can't reproduce it on my vm either
-    <youpi> maybe the C program will help
-    <markus_wanner> Hm.. cannot corrently reproduce that in C. (Netcat still
-      shows the issue, though).
-    <markus_wanner> I'll try to strace netcat...
-    <markus_wanner> ..Meh. strace not available on Hurd?
-    <pinotree> no, but there is rpctrace to show the various rpc
-    <markus_wanner> Cool, looks helpful.
-    <markus_wanner> Thx
-    <markus_wanner> Uh.. that introduces another error:
-    <markus_wanner> rpctrace: ../../utils/rpctrace.c:1287: trace_and_forward:
-      Assertion `reply_type == 18' failed.
-
-[[hurd/debugging/rpctrace]].
-
-    <youpi> I'm checking on a box without ipv6 configuration
-    <youpi> maybe that's the difference between you and me
-    <youpi> I guess your /etc/alternatives/nc is /bin/nc.traditional ?
-    <markus_wanner> Yup, nc.traditional.
-    <markus_wanner> Looks like that box only has IPv4 configured.
-    <markus_wanner> Something very strange is going on here. No matter how hard
-      I try, I cannot reproduce this with netcat, anymore.
-    <pinotree> not even after a reboot?
-    <markus_wanner> Woo.. here, it happened, again! This is driving me crazy!
-    <markus_wanner> Now, nc seemingly connects, but is unable to send data
-      between the two. Netcat would somehow complain, if it failed to connect,
-      no?
-    <markus_wanner> No it worked.
-    <markus_wanner> So this seems to be an intermittent issue. So far, I could
-      only ever repro it as a normal user, not as root. May be coincidental,
-      though.
-    <markus_wanner> Now, 'a' and 'b' made it through, but not the 'c' sent
-      manually just after that. Something with that TCP/IP stack is definitely
-      fishy.
-    <markus_wanner> Anything I can try to investigate? Or shall I simply
-      restart and see if the problem persists?
-    <youpi> maybe restart, yes
-    <youpi> did you restart since the upgrade ?
-    <markus_wanner> Yes, I restarted after that.
-    <markus_wanner> Hm.. okay, restarted. Some problem persists.
-    <markus_wanner> I currently have two netcat processes connected, the
-      listening one got some first two messages and seems stuck now.
-    <markus_wanner> With the client, I tried to send more data, but the server
-      doesn't get it, anymore.
-    <markus_wanner> Any idea on what I can do to analyze the situation?
-    <youpi> for the netcat issue, I haven't experienced this
-    <youpi> are you running in kvm or virtualbox or something else?
-    <markus_wanner> I'm currently puzzled about what "experimental" actually
-      ships.
-    <markus_wanner> On kvm.
-    <markus_wanner> My libc0.3 used to be 2.13-39+hurd.3.
-    <markus_wanner> But packages.d.o already shows 2.17.0experimental2.
-    <youpi> experimental ships experimental versions, which you aren't supposed
-      to use
-    <youpi> unless you know what you are doing
-    <youpi> iirc 2.17 is known to be quite broken for now
-    <markus_wanner> Okay. So I guess I'll try to "downgrade" to unstable, then.
-    <markus_wanner> Phew, okay, successfully downgraded to unstable.
-    <markus_wanner> Hopefully monotone's test suite runs through fine, now.
-    <markus_wanner> Yup, WORKING! Looks like some experimental packages caused
-      the problem. The netcat test as well as that one failing monotone test
-      work fine, now.
-
-
-## IRC, OFTC, #debian-hurd, 2013-03-19
-
-    <tschwinge> pinotree, youpi: Is there anything from that markus_wanner
-      discussion about pfinet/netcat/signals that needs to be filed?  I guess
-      we don't know what exactly he changed so that everything workedd fine
-      eventually?  (Some experimental package(s), but which?)
-    <youpi> that was libc0.3 packages
-    <youpi> which are indeed known to break the network
-
-
-# IRC, freenode, #hurd, 2013-06-18
-
-    <braunr> root@darnassus:~# dpkg-reconfigure locales
-    <braunr> Generating locales (this might take a
-      while)... en_US.UTF-8...Segmentation fault
-    <braunr> is it known ?
-    <youpi> uh, no
-
-
-## IRC, OFTC, #debian-hurd, 2013-06-19
-
-    <pinotree> btw i saw too the segmentation fault when generating locales
-
-
-## IRC, freenode, #hurd, 2014-02-04
-
-    <bu^> hello
-    <bu^> I just updated
-    <bu^> Setting up locales (2.17-98~0) ...
-    <bu^> Generating locales (this might take a while)...
-    <bu^>   en_US.UTF-8...Segmentation fault
-    <bu^>  done
-    <gnu_srs> bu^: That's known, it still seems to work, though. If you have
-      the time please debug. I've tried but not found the solution yet:-(
-    <bu^> ok, just wanted to notify
-
-
-## IRC, freenode, #hurd, 2014-02-19
-
-    <braunr> for info, the localedef segfault has been fixed upstream
-    <braunr> or rather, upstream has been written in a way that won't trigger
-      the segfault
-    <braunr> it is caused by the locale archive code that maps the locale
-      archive file in the address space, enlarging the mapping as needed, but
-      unmaps the complete reserved size of 512M on close
-    <braunr> munmap is implemented through vm_deallocate, but it looks like the
-      latter doesn't allow deallocating unmapped regions of the address space
-    <braunr> (to be confirmed)
-    <braunr> upstream code tracks the mapping size so vm_deallocate won't whine
-    <braunr> i expect we'll have that in eglibc 2.18
-    <braunr> hm actually, posix says munmap must refer to memory obtained with
-      mmap :)
-    <braunr> (or actually, that the behaviour is undefined, which most unix
-      systems allow anyway, but not us)
-
-    <braunr> also, before i leave, i have partially traced the localedef
-      segfault
-    <youpi> ah, cool
-    <braunr> localedef maps the locale archive, and enlarges the mapping as
-      needed
-    <braunr> but munmaps the complete 512m reserved area
-    <braunr> and i strongly suspect it unmaps something it shouldn't on the
-      hurd
-    <braunr> since linux mmap has different boundaries depending on the mapping
-      use
-    <braunr> while our glibc will happily maps stacks below text
-    <braunr> the good news is that it looks fixed upstream
-    <youpi> ah :)
-    <braunr>
-      https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=17db6e8d6b12f55e312fcab46faf5d332c806fb6
-    <braunr> see the change about close_archive
-    <braunr> i haven't tested it though
-
-
-## IRC, freenode, #hurd, 2014-02-21
-
-    <gg0> just upgraded to 2.18, locales still segfaults
-    <braunr> ok
-
-
-## IRC, freenode, #hurd, 2014-02-23
-
-    <braunr> ok, as expected, the localdef bug is because of some mmap issue
-
-[[glibc/mmap]].
-
-    <braunr> looks like our mmap doesn't like mapping files with PROT_NONE
-    <braunr> shouldn't be too hard to fix
-    <braunr> gg0: i should have a fix ready soon for localedef
-
-    <braunr> youpi: i have a patch for glibc about the localedef segfault
-    <youpi> is that the backport we talked about, or something else?
-    <braunr> something else
-    <braunr> in short
-    <braunr> mmap() PROT_NONE on files return 0
-    <youpi> ok
-    <youpi> seems like fixable indeed
-    <braunr> nothing is mapped, and the localdef code doesn't consider this an
-      error
-    <braunr> my current fix is to handle PROT_NONE like PROT_READ
-    <youpi> doesn't vm_protect allow to map something without giving read
-      right?
-    <braunr> it probably does
-    <braunr> the problem is in glibc
-    <youpi> ok
-    <braunr> when i say like PROT_READ, i mean a memory object gets a reference
-    <braunr> on the read port returned by io_map
-    <braunr> since it's not accessible anyway, it shouldn't make a difference
-    <braunr> but i preferred to have the memory object referenced anyway to
-      match what i expect is done by other systems
-
-
-## IRC, freenode, #hurd, 2014-02-24
-
-    <youpi> braunr: ah ok
-
-    <braunr> ok that mmap fix looks fine, i'll add comments and commit it soon
-
-
-## IRC, freenode, #hurd, 2014-03-03
-
-    <youpi> braunr: did you test whether
-      https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=17db6e8d6b12f55e312fcab46faf5d332c806fb6
-      does indeed fix locale generation?
-    <braunr> youpi: it doesn't, which is why i applied
-      http://git.sceen.net/hurd/glibc.git/commitdiff/da2d6e677ade278bf34afaa35c6ed4ff2489e7d8?hp=9a079e270a9bec7e1fe28aeda63e07c1bb808d44
-
-
-# IRC, OFTC, #debian-hurd, 2013-06-20
-
-    <youpi> damn
-    <youpi> hang at ext2fs boot
-    <youpi> static linking issue, clearly
-
-
-## IRC, freenode, #hurd, 2013-06-30
-
-    <youpi> Mmm
-    <youpi>  __access ("/etc/ld.so.nohwcap", F_OK) at startup of ext2fs
-    <youpi> deemed to fail....
-    <pinotree> when does that happen?
-    <youpi> at hwcap initialization
-    <youpi> at least that's were ext2fs.static linked against libc 2.17 hangs
-      at startup
-    <youpi> and this is indeed a very good culprit :)
-    <pinotree> ah, a debian patch
-    <youpi> does anybody know a quick way to know whether one is the / ext2fs ?
-      :)
-    <pinotree> isn't the root fs given a special port?
-    <youpi> I was thinking about something like this, yes
-    <youpi> ok, boots
-    <youpi> I'll build a 8~0 that includes the fix
-    <youpi> so people can easily build the hurd package
-    <youpi> Mmm, no, the bootstrap port is also NULL for normally-started
-      processes :/
-    <youpi> I don't understand why
-    <youpi> ah, only translators get a bootstrap port :/
-    <youpi> perhaps CRDIR then
-    <youpi> (which makes a lot of sense)
-
-
-## IRC, freenode, #hurd, 2013-07-01
-
-    <braunr> youpi: what is local-no-bootstrap-fs-access.diff supposed to fix ?
-    <youpi> ext2fs.static linked againt debian glibc 2.17
-    <youpi> well, as long as you don't build & use ext2fs.static with it...
-    <braunr> that's thing, i want to :)
-    <braunr> +the
-    <youpi> I'd warmly welcome a way to detect whether being the / translator
-      process btw
-    <youpi> it seems far from trivial
-
-
-# glibc 2.18 vs. GCC 4.8
-
-## IRC, freenode, #hurd, 2013-11-25
-
-    <youpi> grmbl, installing a glibc 2.18 rebuilt with gcc-4.8 brings an
-      unbootable system
-
-
-## IRC, freenode, #hurd, 2013-11-29
-
-    <teythoon> so, what do I do? rebuild the glibc 2.18 package with gcc4.8 and
-      see what breaks ?
-    <teythoon> when I boot a system with that libc that is ?
-    <teythoon> I wish youpi would have been more specific, I've never built the
-      libc before...
-    <braunr> debian/rules build in the debian package
-    <braunr> ctrl-c when you see gcc invocations
-    <braunr> cd buildir; make lib others
-    <braunr> although hm
-    <braunr> what breaks is at boot time right ?
-    <teythoon> yes
-    <braunr> heh ..
-    <braunr> then dpkg-buildpackage
-    <braunr> DEB_BUILD_OPTIONS=nocheck speeds things up
-    <braunr> just answer on the mailing list and ask him
-    <braunr> he usually answers quickly
-
-
-## IRC, freenode, #hurd, 2013-12-18
-
-    <gnu_srs> teythoon: k!, any luck with eglibc-2.18?
-    <teythoon> tbh i didn't look into this after two unsuccessful attempts at
-      building the libc package
-    <teythoon> there was a post over at the libc-alpha list that sounded
-      familiar
-    <teythoon> http://www.cygwin.com/ml/libc-alpha/2013-12/msg00281.html
-    <braunr> wow
-    <teythoon> ?
-    <braunr> this looks tricky
-    <braunr> and why ia64 only
-    <teythoon> indeed
-    <braunr> it's rare to see aurel32 ask such questions
-
-
-## IRC, freenode, #hurd, 2014-01-22
-
-    <youpi> btw, did anybody investigate the glibc-built-with-gcc-4.8 issue?
-    <youpi> oddly enough, a subhurd boots completely fine with it
-    <braunr> i didn't
-    <teythoon> no, sorry
-    <youpi> I was wondering whether the bogus deallocation at boot might have
-      something to do
-    <braunr> which one ?
-    <braunr> ah
-    <braunr> yes
-    <braunr> maybe
-    <youpi> quoted earlier here
diff --git a/open_issues/glibc/mremap.mdwn b/open_issues/glibc/mremap.mdwn
deleted file mode 100644
index c17506d7..00000000
--- a/open_issues/glibc/mremap.mdwn
+++ /dev/null
@@ -1,70 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012 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]]
-
-The Hurd does not currently support the `mremap` function.
-
-For the `MREMAP_MAYMOVE` case it is easy to work around; see
-`[binutils]/gold/mremap.c`, for example.
-
-Also see the discussion of [[glibc/mmap]].
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2011-01-12
-
-    <antrik> maybe it would be easiest actually to implement mremap()?...
-    <braunr> antrik: i'm nto sure
-    <braunr> antrik: implementing mremap could be relatively easy to do
-      actually
-    <braunr> antrik: IIRC, vm_map() supports overlapping
-    <antrik> braunr: yes, I think so too
-    <antrik> braunr: haven't checked, but I have a vague recollection that the
-      fundamentals are pretty much there
-
-[[!taglink open_issue_glibc]]: check if it is possible to implement `mremap`.
-[[I|tschwinge]] remember some discussion about this, but have not yet worked on
-locating it.  [[Talk to me|tschwinge]] if you'd like to have a look at this.
-
-
-# IRC, OFTC, #debian-hurd, 2012-06-19
-
-    <bdefreese> OK, how the heck do you get an undefined reference to mremap?
-    <youpi> simply because we don't have it
-    <pinotree> mremap exists only on linux
-    <bdefreese> It's in sys/mman.h
-    <pinotree> on linux?
-    <bdefreese> No, on GNU/Hurd
-    <bdefreese>  /usr/include/i386-gnu/sys/mman.h
-    <youpi> that's just the common file with linux
-    <youpi> containing just the prototype
-    <youpi> that doesn't mean there's an implementation behind
-    <pinotree> youpi: hm no, linux has an own version
-    <youpi> uh
-    <bdefreese> Ah, aye, I didn't look at the implementation.. :(
-    <youpi> it's then odd that it was added to the generic sys/mman.h :)
-    <bdefreese> Just another stub?
-    <pinotree> ah, only few linux archs have own versions
-    <youpi> for the macro values I guess
-    <pinotree> http://paste.debian.net/175173/ on glibc/master
-    <bdefreese> Hmm, so where is MREMAP_MAYMOVE coming in from?
-    <youpi> rgrep on a linux box ;)
-    <youpi> <bits/mman.h>
-    <youpi> but that's again linuxish
-    <bdefreese> Aye but with us having that in the header it is causing some
-      code to be run which utilizes mremap.  If that wasn't defined we wouldn't
-      be calling it.
-    <youpi> ah
-    <youpi> we could try to remove it indeed
-    <bdefreese> Should I change the code to #ifdef MREMAP_MAYMOVE & !defined
-      __GNU__?
-    <youpi> no, I said we could remove the definition of MREMAP_MAYMOVE itself
diff --git a/open_issues/glibc/octave.mdwn b/open_issues/glibc/octave.mdwn
deleted file mode 100644
index b12b7558..00000000
--- a/open_issues/glibc/octave.mdwn
+++ /dev/null
@@ -1,35 +0,0 @@
-[[!meta copyright="Copyright © 2012 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]]
-
-
-# IRC, OFTC, #debian-hurd, 2012-04-23
-
-    <pinotree> diffing the octave i386 vs hurd-i386 build logs gives
-      interesting surprises
-    <youpi>   checking whether this system has an arbitrary file name length
-      limit... no              |  checking whether this system has an arbitrary
-      file name length limit... yes
-    <youpi> ?
-    <pinotree> not only that
-    <youpi>   checking whether getcwd handles long file names properly... yes
-      |  checking whether getcwd handles long file names properly... no, but it
-      is partly worki+
-    <youpi> ?
-    <pinotree> -checking whether fdopendir works... yes
-    <pinotree> +checking whether fdopendir works... no
-    <pinotree> (- is i386, + is hurd-i386)
-    <pinotree> -checking whether getlogin_r works with small buffers... yes
-    <pinotree> +checking whether getlogin_r works with small buffers... no
-    <pinotree> -checking for working mkstemp... yes
-    <pinotree> +checking for working mkstemp... no
-    <pinotree> +checking for working nanosleep... no (mishandles large
-      arguments)
diff --git a/open_issues/glibc/t/tls-threadvar.mdwn b/open_issues/glibc/t/tls-threadvar.mdwn
deleted file mode 100644
index 40d1463e..00000000
--- a/open_issues/glibc/t/tls-threadvar.mdwn
+++ /dev/null
@@ -1,155 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012, 2013 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_libpthread]]
-
-This basically means to get rid of `sysdeps/mach/hurd/bits/libc-tsd.h` (and
-thus the `_HURD_THREADVAR_*`/`_hurd_threadvar_location` interface), and
-directly use `__thread` instead.
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2011-10-23
-
-    <tschwinge> youpi: If we want to replace threadvars with TLS, there is one
-      problem: the threadvars interface is publically exported:
-      /usr/include/hurd/threadvar.h.
-    <tschwinge> youpi: But I am somewhat inclined to say that the only user of
-      this is libthreads/libpthread.  Do you think differently?
-    <youpi> tschwinge: that's very probable
-    <youpi> so I think we can just drop it
-    <youpi> (people should use TLS anyway)
-
-[[libpthread_set_stack_size]].
-
-After this has been done, probably the whole `__libc_tsd_*` stuff can be
-dropped altogether, and `__thread` directly be used in glibc.
-
-
-# IRC, freenode, #hurd, 2012-08-07
-
-    <tschwinge> r5219: Update libpthread patch to replace threadvar with tls
-      for pthread_self
-    <tschwinge> r5224: revert r5219 too, it's not ready either
-    <youpi> as the changelog says, the __thread revertal is because it posed
-      problems
-    <youpi> and I just didn't have any time to check them while the freeze was
-      so close
-    <tschwinge> OK.  What kind of problems?  Should it be reverted upstream,
-      too?
-    <youpi> I don't remember exactly
-    <youpi> it should just be fixed
-    <youpi> we can revert it upstream, but it'd be good that we manage to
-      progress, at some point...
-    <tschwinge> Of course -- however as long as we don't know what kind of
-      problem, it is a bit difficult.  ;-)
-    <youpi> since I didn't left a note, it was most probably a mere glibc run,
-      or boot with the patched libpthread
-    <youpi> *testsuite run
-    <tschwinge> OK.
-    <tschwinge> The libpthread testsuite doesn't show any issues with that
-      patch applied, though.  But I didn'T test anything else.
-    <tschwinge> youpi: Also, you have probably seen my glibc __thread errno
-      email -- rmcgrath wanted to find some time this week to comment/help, and
-      I take it you don't have any immediate comments to that issue?
-    <youpi> I saw the mails, but didn't investigate at all
-
-[[!message-id "878vdyqht3.fsf@kepler.schwinge.homeip.net"]].
-
-
-# IRC, freenode, #hurd, 2013-07-08
-
-    <youpi> tschwinge: apparently there were a lot of changes missing in the
-      threadvars branch I had commited long time ago
-    <youpi> I'm gathering things
-    <tschwinge> youpi: t/tls-threadvar you mean?
-    <youpi> yes
-    <youpi> tschwinge: yes, there were a lot other occurences of threadvars
-      stuff in various places
-    <youpi> I'm building libc again, and will see what issue would remain
-
-
-## IRC, freenode, #hurd, 2013-07-12
-
-    <youpi> braunr: about the per-thread ports, there is also the mig reply
-      port
-    <youpi> (stored in _HURD_THREADVAR_MIG_REPLY)
-
-
-## IRC, freenode, #hurd, 2013-07-15
-
-    <braunr> and with the branch youpi pushed where he removes threadvars, it
-      shouldn't get "too" hard
-    <braunr> (save for the tricky bugs you may encounter)
-    <youpi> well, that branch is not working yet
-
-
-## IRC, OFTC, #debian-hurd, 2013-09-22
-
-    <youpi> I'm currently tracking bugs with my threadvars changes
-    <youpi> some of them seem fine, others, not
-    <youpi> of course the most complex ones are the most probable culprits for
-      the issues I'm getting
-    <youpi> fortunately they're after the process bootstrap
-    <youpi> so basically that works
-    <youpi> just a few dozen tests fail
-    <youpi> mostly about loading .so  or raising signals
-    <youpi> dlopen("bug-dlsym1-lib1.so"): bug-dlsym1-lib1.so: cannot open
-      shared object file: Function not implemented
-    <youpi> after having changed errno a bit
-    <youpi> doesn't that look odd ? :)
-    <youpi> good, I found an issue with the sigstate
-    <youpi> now running testsuite again, to see whether there are other issues
-      with it :)
-    <youpi> s/sigstate/reply_port/ actually
-
-
-## IRC, OFTC, #debian-hurd, 2013-09-23
-
-    <youpi> yay, errno threadvar conversion success
-
-
-## IRC, OFTC, #debian-hurd, 2013-10-05
-
-    <gg0_> youpi: any ETA for tls?
-    <youpi> gg0_: one can't have an ETA for bugfixing
-    <gg0_> i don't call them bugs if there's something missing to implement btw
-    <youpi> no, here it's bugs
-    <youpi> the implementation is already in the glibc branches in our
-      repository
-    <youpi> it just makes some important regressions
-
-
-## IRC, OFTC, #debian-hurd, 2013-10-07
-
-    <youpi> about tls, I've made some "progress": now I'm wondering how raise()
-      has ever been working before :)
-
-
-## IRC, OFTC, #debian-hurd, 2013-10-15
-
-    <youpi> good, reply_port tls  is now ok
-    <youpi> last but not least, sigstate
-
-
-## IRC, OFTC, #debian-hurd, 2013-10-21
-
-    <youpi> started testsuite with threadvars dropped completely
-    <youpi> so far so good
-
-
-## IRC, OFTC, #debian-hurd, 2013-10-24
-
-    <youpi> ok, hurd boots with full-tls libc, no threadvars at all any more
-    <gg0> \o/
-    <gg0> good bye threadvars bugs, welcome tls ones ;)
-    <youpi> now I need to check that threads can really use another stack :)
diff --git a/open_issues/glibc/t/tls.mdwn b/open_issues/glibc/t/tls.mdwn
deleted file mode 100644
index b10703fd..00000000
--- a/open_issues/glibc/t/tls.mdwn
+++ /dev/null
@@ -1,81 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012, 2013 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_libpthread]]
-
-# To Do
-
-  * Discuss d2431f633e6139a62e1575ec18830f7e81160cf0 with Samuel.
-
-  * Validate our implementation against
-    <https://sourceware.org/glibc/wiki/TLSandSignals>.
-
-
-# Documentation
-
-[[!taglink open_issue_documentation]]
-
-  * IRC, freenode, #hurd, 2011-11-26
-
-        <tschwinge> In glibc multiarch support (strcasecmp for i686 SSE3, etc.)
-          there is access to memory via gs: -- this will need to be changed for
-          us, right?
-        <youpi> depends on the access
-        <tschwinge>       * `optimized strcasecmp and strncasecmp for x86-32`
-          (multiarch),
-        <tschwinge>         76e3966e9efc3808a9e7ad09121c5dfc1211c20b +
-        <tschwinge>         6abf346582ba678f4850a88b4a5950593841df1d +
-        <tschwinge>         5583a0862cf94f71cbcde91c4043a20af65facca.  `gs`
-          access.
-        <youpi> +       movl    __libc_tsd_LOCALE@GOTNTPOFF(%ebx), %eax
-        <youpi> that's handled by the linker fine
-        <youpi> it's only the things held in the tcb_t structure which can pose
-          problem
-        <tschwinge> tcbhead_t?
-        <tschwinge> I'm looking at this.
-        <tschwinge> So, at gs:0, there is the TCB.
-        <tschwinge> And we have the same layout as NPTL/Linux, just that we
-          don't have as much data there as they have.
-        <tschwinge> We're missing multiple_threads, sysinfo, sttack_guard,
-          pointer_guard, gscope_flag, private_futex, __private_tm[5].
-        <tschwinge> So, if one of these is referenced (be it my name or by
-          numeric offset), this is invalid for us.
-        <tschwinge> Anything else should work equivalently.
-        <youpi> yes
-        <youpi> usually the only numeric offset being used is 0
-        <youpi> so it would simply not build
-        <tschwinge> And the other offsers are generated via tcb-offsets.sym.
-        <tschwinge> glibc's elf/stackguard-macros.h is wrong for us (but not
-          used anywhere apart from elf/tst-stackguard1.c, I think).
-
-After commit a9538892adfbb9f092e0bb14ff3a1703973968af, it's
-`sysdeps/i386/stackguard-macros.h`; problem remains.
-
-        <tschwinge> __thread __locale_t __libc_tsd_LOCALE = &_nl_global_locale;
-          -- this means that a __libc_tsd_LOCALE values will be in the TLS
-          segment, and this is what is being accessed from the assembler code
-          with %gs:__libc_tsd_LOCALE@NTPOFF, and the linker will resolve this.
-        <youpi> yes
-        <youpi> see in the nm output, the libc_tsd symbols
-        <youpi> these provide the offsets
-        <tschwinge> youpi: Thank you, I'm now understanding this part of TLS
-          much better.
-        <youpi> have you had a look at the tls.pdf from Uli ?
-        <youpi> all the gory details are there :)
-
-Commit c61b4d41c9647a54a329aa021341c0eb032b793e, [[!sourceware_PR 15754]], adds
-`sysdeps/i386/stackguard-macros.h:POINTER_CHK_GUARD`, which is not correct for
-us (at the moment), but it also shouldn't cause any harm, as this file is only
-used in `elf/tst-ptrguard1.c` and `elf/tst-stackguard1.c`, which now will fail
-to build for us, as we don't have a `pointer_guard` member in
-`sysdeps/mach/hurd/tls.h:tcbhead_t`.
-
-We don't define `THREAD_SET_POINTER_GUARD`.
diff --git a/open_issues/glibc___libc_alloca_cutoff_should_be_lowered.mdwn b/open_issues/glibc___libc_alloca_cutoff_should_be_lowered.mdwn
deleted file mode 100644
index 6d1b4bea..00000000
--- a/open_issues/glibc___libc_alloca_cutoff_should_be_lowered.mdwn
+++ /dev/null
@@ -1,19 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-[[!meta title="glibc: __libc_alloca_cutoff should be lowered"]]
-
-[[!tag open_issue_hurd open_issue_glibc]]
-
-Ognyan Kulev, *[LIBC] \_\_libc\_alloca\_cutoff should be lowered*, bug-hurd,
-2003-06-12, <http://lists.gnu.org/archive/html/bug-hurd/2003-06/msg00050.html>
-
-Replace second link (mail.gnu.org) with
-<http://lists.gnu.org/archive/html/bug-hurd/2002-09/msg00143.html>.
diff --git a/open_issues/glibc_ioctls.mdwn b/open_issues/glibc_ioctls.mdwn
deleted file mode 100644
index 3f396754..00000000
--- a/open_issues/glibc_ioctls.mdwn
+++ /dev/null
@@ -1,171 +0,0 @@
-[[!meta copyright="Copyright © 2010, 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]]
-
-
-# IRC, unknown channel, unknown date
-
-    <pinotree> d'oh, broken defines for ioctl()!
-    <pinotree> http://paste.debian.net/45021/ ← any idea about this? looks like something fishy with the SIO* defines
-    <pinotree> tschwinge: ↑ know anything about this?
-    <pinotree> #define _IOT_arpreq       _IOT_SIMPLE (struct arpreq) ← looks like it is missing for bits/ioctls.h
-    <pinotree> eglibc patch submitted-ioctl-unsigned-size_t.diff should be pimped a bit
-
-    <pinotree> youpi: while trying to compile ossp-uuid (needed by pgsql 8.4, needed by various other stuff), i found a bug in a hurd libc header
-    <youpi> that's possible
-    <pinotree> it has a ioctrl() using an id with a value having type 'struct arpreq'
-    <youpi> ah, that's not a bug then
-    <youpi> see the ioctl section of the porting page of the wiki
-    <pinotree> due to the sort of "mangling" done in bits/ioctrls.h, there should be an helper macro for the size of the struct arpreq
-    <pinotree> +#define _IOT_arpreq       _IOT_SIMPLE (struct arpreq)  ← adding this before any header was enough
-    * pinotree looks
-    <youpi> it's not to be done so simply
-    <youpi> see the page :)
-    <youpi> I'm afraid _IOT_arpreq can't be properly defined
-    * pinotree is not finding it...
-    <pinotree> the closest i see is http://lists.gnu.org/archive/html/bug-hurd/2006-03/msg00025.html
-    <youpi> that's it yes
-    <youpi> I mean, that's the kind of thing
-    <youpi> but not the wiki page, let me look
-    <youpi> http://www.gnu.org/software/hurd/hurd/porting/guidelines.html
-    <pinotree> i also saw a glib patch adding few types like that (char, short, int)
-    <youpi> yes that's the same kind of thing
-    <pinotree> i see
-    <youpi> setting it to _IOT_SIMPLE(struct arpreq) would probably work with 32bit gnumach and 32bit userland, but may not with e.g. 64bit gnumach and 32bit userland and such
-    <pinotree> hmmm, sockaddr,sockaddr,int,sockaddr,char[16]
-    <pinotree> so basically it would support at most 3 elements in a passed struct?
-    <pinotree> s/elements/fields/
-    <youpi> 3 kinds of fields
-    <youpi> as you provide a count
-    <pinotree> youpi: so basically: #define _IOT_arpreq _IOT (_IOTS (struct sockaddr), 3, _IOTS (int), 1, _IOTS (char), 16) ?
-    <pinotree> ie the order of the fields in the struct does not matter, it seems?
-    <youpi> the order of the fields does matter
-    <youpi> as this encodes how mig will read the struct to send them
-    <pinotree> uhm
-    <youpi> also, _IOTS(struct sockaddr) won't work
-    <pinotree> yeah i should define it too
-    <youpi> no, it even needs to be replaced by its content
-    <pinotree> ah
-    <pinotree> it is possible to compose the _IOTS()?
-    <pinotree> (to build structs with more than 3 kind of fields)
-    <youpi> no
-    <pinotree> d'oh
-    <youpi> that's a hard shortcoming of the whole ioctl encoding
-    * pinotree scratches his head
-    <youpi> there's no way but redefining ioctl(), really
-    <youpi> it was a funny trick to encode it this way, but unrealistic
-    <pinotree> i see, yes
-    <youpi> not to mention ioctls which contain pointers, which just can not be passed to mig
-    <pinotree> indeed
-    <youpi> actually it's not mach's ioctl issue
-    <youpi> as mach doesn't know ioctl
-    <youpi> but the hurd ioctl interface
-    <pinotree> right
-    <youpi> which might end up in mach, other processes, other machines, etc.
-    * pinotree s/Mach/Hurd/ :)
-
-
-# `TIOCCONS`
-
-## IRC, freenode, #hurd, 2014-02-05
-
-    <gnu_srs> Hi, anybody have time to look at what fails with: ioctl(0,
-      TIOCCONS, NULL)?
-    <gnu_srs> found a program doing the same function call as bootlogd:
-      http://paste.debian.net/80231/
-    <gnu_srs> rpctrace: http://paste.debian.net/80232/
-    <youpi> gnu_srs: it seems there  is a misunderstanding between linux and
-      *bsd on this one
-    <youpi> to be able to work on *bsd (and on hurd too), the source code
-      should replace its NULL parameter with the address of an integer
-      containing 1
-    <youpi> see
-      http://lists.freebsd.org/pipermail/freebsd-current/2011-January/022116.html
-      for the bsd implementation, for instance
-    <gnu_srs> youpi: replacing 0 with &i where int i=1 gives: TIOCCONS:
-      Inappropriate ioctl for device
-    <youpi> so be it, but that's clearly needed to be able to work on bsd
-    <youpi> and probably the implementation is just missing on the Hurd for now
-    <gnu_srs> jus to be clear: do you mean 0 or NULL in: ioctl(0, TIOCCONS,
-      NULL)?
-    <youpi> yes, for instance there is an implementation do_tiocsctty in glibc,
-      but no to_tioccons
-    <youpi> I mean NULL
-    <gnu_srs> OK, that's where I changed, the first argument id the FD
-    <youpi> well, when I wrote "NULL", I really meant "NULL" ...
-    <gnu_srs> yes sure, so you say that it is not yet implemented?
-    <youpi> yes, for instance there is an implementation do_tiocsctty in glibc,
-      but no to_tioccons
-    <gnu_srs> easy to do?
-    <youpi> no idea, I don't even know what that is suppsoed to do
-    <youpi> it's probably something like tiocsctty, but I don't really know
-    <gnu_srs> Redirecting console output to a pseudotty
-    <youpi> omg that ioctl is so ugly
-    <youpi> the way I can see it working is to add an RPC to the /dev/console
-      translator (i.e. /hurd/term) to give it the fd, and have /hurd/term write
-      to it whenever it gets writes, instead of writing to the console device
-    <youpi> gnu_srs: what do you need that for?
-    <gnu_srs> bootlogd in sysvinit use that for logging.
-    <gnu_srs> should I propose a patch to avoid the segfault when booting then?
-    <youpi> at least, yes
-    <youpi> *bsd will need it anyway
-    <gnu_srs> youpi: btw: hurd console does not work when running openrc,
-      neither is halt/reboot. Maybe you should try it out?
-    <gnu_srs> bootlogd use  ioctl(0, TIOCCONS, NULL) a Linux (only) construct
-    <gnu_srs> ?
-    <youpi> gnu_srs: I had infinite time in the day, I would be able to try it
-      out, yes
-    <braunr> heh
-    <youpi> giving NULL to TIOCCONS is a linux-only construct, yes
-    <youpi> to be compatible with *BSD, you have to pass the parameter
-      mentioned above
-    <youpi> instead of NULL
-    <gnu_srs> well bootlogd is from sysvinit, so it is a matter if we move to
-      that for init.
-    <gnu_srs> ***checking if bootlogd segfaults on kFreeBSD too
-
-
-# Non-constant structures as IOCTL parameter
-
-[[!debbug 413734]].
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-16
-
-    <gg0> https://bugs.debian.org/413734
-    <gg0> patch #2 has become http://paste.debian.net/plain/82412/
-    <gg0> ie. almost entirely ifdef'ing DeviceEnum
-    <gg0> ok final patch is http://paste.debian.net/plain/82440/
-    <gg0> could anyone review it, especially last 3 oss hunks?
-    <azeem> gg0: well probably it would be cleaner to have autoconf check for
-      any of the three soundcard.h include locations?
-    <gg0> azeem: i think if upstream is ok with 2 it could be ok with 3 too
-    <gg0> my concern is about linux/ in header path (hurd is not linux) and
-      about ways cleaner than last 2 hunks
-    <azeem> well yeah, #ifdef __GNU__ #include <linux/foo.h> certainly looks
-      ugly
-    <gg0> i'll ifdef ioctls only
-
-
-### IRC, OFTC, #debian-hurd, 2014-02-17
-
-    <gg0> http://paste.debian.net/plain/82446/
-    <gg0> https://trac.videolan.org/vlc/ticket/10696
-
-
-### IRC, freenode, #hurd, 2014-02-17
-
-    <gg0> porting vlc with http://paste.debian.net/plain/82446/ +
-      http://paste.debian.net/plain/82510/
-    <gg0> what's the proper way to fix ioctl instead of ifdef'ing them?
-    <gg0> see https://bugs.debian.org/413734
-    <braunr> gg0: defining them in libc
-    <braunr> and in servers implementing them ofc
diff --git a/open_issues/glibc_libpthread_robust_mutexes.mdwn b/open_issues/glibc_libpthread_robust_mutexes.mdwn
deleted file mode 100644
index a92c984d..00000000
--- a/open_issues/glibc_libpthread_robust_mutexes.mdwn
+++ /dev/null
@@ -1,54 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_libpthread]]
-
-libpthread: glibc 44e2ad5ab8c21dbfed3e384ba2ed31d7a8fc4744
-998e5fc14595229101561d76282036839e5b66ab -- The robust mutex functions are in
-POSIX 2008.
-
----
-
-IRC, #hurd, unknown date.
-
-    <youpi> neal: bad news: you remember the PTHREAD_RECURSIVE_MUTEX_INITIALIZER that points to a global __pthread_recursive_mutexattr?
-    <youpi> that doesn't work
-    <youpi> because some libraries like libstdc++ do not link against libpthread, while still using pthread_mutex_lock/unlock (counting on them being provided by either libc or libpthread-stubs)
-    <CIA-1> sthibaul-guest * r626 pkg-hurd/hurd/trunk/debian/ (changelog patches/series): 
-    <CIA-1> * debian/patches/libpthread_rwlock_initializer.patch: Disable patch for now:
-    <CIA-1> our initializer does not work when the application does not link against
-    <CIA-1> libpthread.
-
-    <CIA-1> sthibaul-guest * r629 pkg-hurd/hurd/trunk/debian/ (changelog patches/series): do not disable adding PTHREAD_RWLOCK_INITIALIZER, that's not the one that poses problems
-    <CIA-1> sthibaul-guest * r630 pkg-hurd/hurd/trunk/debian/ (3 files in 2 dirs): 
-    <CIA-1> * debian/patches/libpthread_no_recursive_mutex_initializer.patch: New patch
-    <CIA-1> to drop undefined references to __pthread_recursive_mutexattr.
-
-    <youpi> I'm thinking about how to fix the PTHREAD_RECURSIVE_MUTEX_INITIALIZER
-    <youpi> instead of a pointer to a static attribute variable, which posed problem
-    <youpi> could we perhaps consider that page 0 is never mapped
-    <youpi> and thus not only pointer 0 but also 1 2, etc. are invalid
-    <neal> I think that is a good solution
-    <youpi> and use them as special values
-    <neal> alternatively, we could assume that -PAGESIZE is never valid
-    <youpi> that makes us test it in all pthread_mutex_* functions, but it's not so bad
-    <neal> I'm not sure which is better
-    <youpi> why isn't it?
-    <neal> because the kernel is mapped there normally
-    <youpi> the kernel could be elsewhere
-    <neal> true
-    <youpi> in a 64bit adressing space for instance
-    <neal> I think your solution is a good one
-    <youpi> ok
-
-    <CIA-1> sthibault * r633 pkg-hurd/hurd/trunk/debian/ (3 files in 2 dirs): 
-    <CIA-1> * debian/patches/libpthread_recursive_mutex_initializer.patch: New patch
-    <CIA-1> to fix the recursive mutex initializers usage in libraries not linking
-    <CIA-1> against libpthread.
diff --git a/open_issues/glibc_madvise_vs_static_linking.mdwn b/open_issues/glibc_madvise_vs_static_linking.mdwn
deleted file mode 100644
index 4af41931..00000000
--- a/open_issues/glibc_madvise_vs_static_linking.mdwn
+++ /dev/null
@@ -1,48 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 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]]
-
-[[!sourceware_PR 4822]].
-
-    $ echo 'int main() {}' | gcc -o /dev/null -static -x c -
-    /usr/lib/gcc/i486-gnu/4.4.5/../../../libcrt.a(malloc.o): In function `_int_free':
-    (.text+0xdc3): warning: warning: madvise is not implemented and will always fail
-
-This is correct, but it does confuse GNU Autoconf, for example, which then
-thinks that static linking is not supported and sets a flag accordingly, which
-luckly no / not many packages use.
-
-*This call does not influence the semantics of the application (except in the
-case of MADV_DONTNEED), but may influence its performance.  The kernel is free
-to ignore the advice.* (`man madvise`), so we may simply want to turn it into a
-no-op in glibc, avoiding the link-time warning.
-
-GCC c5db973fdab3db3e13db575e5650c0bcfd3630f4 (2011-10-17) makes use of this.
-As we now export the symbol (and `MADV_DONTNEED`, too), GCC will no longer
-`munmap` pages, but will keep them mapped for later re-use.  This may increase
-memory usage.  The discussion in [[!message-id
-"20120720162519.734e02eb@spoyarek"]] touches related topics.
-
-2011-07: This is what Samuel has [done for Debian
-glibc](http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/hurd-i386/local-madvise_warn.diff).
-
-
-# IRC, freenode, #hurd, 2012-02-16
-
-    <tschwinge> youpi: With Roland's fix the situation will be that just using
-      gcc -static doesn't emit the stub warning, but still will do so in case
-      that the source code itself links in madvise.  Is this acceptable for
-      you/Debian/...?
-    <youpi> packages with -Werror will still bug out
-    <youpi> not that I consider -Werror to be a good idea, though :)
-    <tschwinge> youpi: Indeed.  Compiler warnings can be caused by all kinds of
-      things.  -Werror is good for development, but not for releases.
diff --git a/open_issues/glibc_ptrace.mdwn b/open_issues/glibc_ptrace.mdwn
deleted file mode 100644
index 7ca07077..00000000
--- a/open_issues/glibc_ptrace.mdwn
+++ /dev/null
@@ -1,43 +0,0 @@
-[[!meta copyright="Copyright © 2009, 2012 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]]."]]"""]]
-
-[[!meta title="glibc: ptrace"]]
-
-[[!tag open_issue_glibc]]
-
-`ptrace` has some issues (`sysdeps/mach/hurd/ptrace.c`).
-
-  * Our implementation (and the generic one in `misc/ptrace.c`) differ
-    from the Linux one (`sysdeps/unix/sysv/linux/ptrace.c`)
-    w.r.t. handling of...
-
-      * the third argument: `int data` vs. `void *data`;
-
-      * `void *addr2` -- Linux doesn't have this, but we provide some
-        additional functionalty using this;
-
-      * function declaration: Linux has **`long`** `int ptrace (enum
-        __ptrace_request __request, ...)` **`__THROW`**, we have `int ptrace
-        (enum __ptrace_request __request, ...)`;
-
-      * interface do differ, e.g., Linux' `PTRACE_GETREGS` uses `void
-        *data`, we use `void *addr` for returning the struct, and in
-	Linux this is a `struct user_regs_struct` from `linux/user.h`,
-        and for us it is a `struct i386_thread_state` from
-        `mach/i386/thread_status.h`;
-
-      * Linux provides some functionality that we don't provide:
-        `PTRACE_GETFPXREGS` , `PTRACE_SINGLESTEP`.
-
-  * Some parts are wrongly implemented, e.g., `PTRACE_GETREGS` and
-    `PTRACE_SETREGS` both do the same thing.
-
-Also consider the `sysdeps/generic/sys/ptrace.h` and
-`sysdeps/unix/sysv/linux/sys/ptrace.h` files.
diff --git a/open_issues/glibc_tls_segment_tcbhead_t_dtv_offset.mdwn b/open_issues/glibc_tls_segment_tcbhead_t_dtv_offset.mdwn
deleted file mode 100644
index 47f104c6..00000000
--- a/open_issues/glibc_tls_segment_tcbhead_t_dtv_offset.mdwn
+++ /dev/null
@@ -1,28 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]
-
-IRC, unknown channel, unknown date.
-
-    <youpi> you can hardcode DTV_OFFSET as 4 for now
-    <youpi> it's the offset of the dtv field in the tcbhead_t structure from hurd/libpthread
-    <tschwinge> youpi: May very well be that I'm misunderstanding something, but wouldn't it rather be the offset of tcb in __pthread + the offset of dtv in tcbhead_t (which indeed is 4)?
-    <youpi> what you don't know is that DTV_OFFSET is not relative to __pthread, but to the tls segment
-    <tschwinge> Oh, aha.  Thanks.
-    <youpi> and drepper abused the fact that in nptl __pthread appears at the start of the tls segment
-
-kFreeBSD, glibc:
-
-    ++#if 0
-    + DTV_OFFSET                    offsetof(struct pthread, header.dtv)
-    ++#else
-    ++DTV_OFFSET                      offsetof(struct _pthread_descr_struct, p_header.data.dtvp)
-    ++#endif
diff --git a/open_issues/glusterfs.mdwn b/open_issues/glusterfs.mdwn
deleted file mode 100644
index 68518938..00000000
--- a/open_issues/glusterfs.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-IRC, unknown channel, unknown date.
-
-    <antrik> "GlusterFS is one of the most sophisticated file system in terms of features and extensibility. It
-    <antrik> borrows a powerful concept called Translators from GNU Hurd kernel."
-    <antrik> seems to be more similar to libstore than actual translators, though
diff --git a/open_issues/gnat.mdwn b/open_issues/gnat.mdwn
deleted file mode 100644
index 84e8f60b..00000000
--- a/open_issues/gnat.mdwn
+++ /dev/null
@@ -1,167 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012, 2013 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]]."]]"""]]
-
-[[!meta title="Enable Ada programming (GCC: GNAT)"]]
-
-[[!tag open_issue_gcc]]
-
-Make the Ada programming language available on GNU/Hurd in its [[GCC]] GNAT
-implementation, and enable Hurd-specific features.
-
-There is a [[!FF_project 259]][[!tag bounty]] on this task.
-
----
-
-
-# Part I
-
-First, make the language functional, have its test suite pass without errors.
-
-
-## Original [[community/GSoC]] Task Description
-
-[[!inline pages=community/gsoc/project_ideas/gnat feeds=no]]
-
-
-## Debian GCC
-
-There has a patch been added for GNU/kFreeBSD:
-`bfe081336914729fc0180c07ab4afa41965100f2`, `git-svn-id:
-svn://svn.debian.org/gcccvs/branches/sid@5638
-6ca36cf4-e1d1-0310-8c6f-e303bb2178ca'
-
-
-## IRC, freenode, #hurd, 2012-07-17
-
-    <gnu_srs> I've found the remaining problem with gnat backtrace for Hurd!
-      Related to the stack frame.
-    <gnu_srs> This version does not work: one relying on static assumptions
-      about the frame layout
-    <gnu_srs> Causing segfaults.
-    <gnu_srs> Any interest to create a test case out of that piece of code,
-      taken from gcc/ada/tracebak.c?
-    <braunr> gnu_srs: sure
-
-
-### IRC, freenode, #hurd, 2012-07-18
-
-    <braunr> "Digging further revealed that the GNU/Hurd stack frame does not
-      seem to
-    <braunr> be static enough to define USE_GENERIC_UNWINDER in
-      gcc/ada/tracebak.c.
-    <braunr> "
-    <braunr> what do you mean by a "stack frame does not seem to be static
-      enough" ?
-    <gnu_srs> I can qoute from the source file if you want. Otherwise look at
-      the code yourself: gcc/ada/tracebak,c
-    <gnu_srs> I mean that something is wrong with the stack frame for
-      Hurd. This is the code I wanted to use as a test case for the stack.
-    <gnu_srs> Remember?
-    <braunr> more or less
-    <braunr> ah, "static assumptions"
-    <braunr> all right, i don't think anything is "wrong" with stack frames
-    <braunr> but if you use a recent version of gcc, as indicated in the code,
-      -fomit-frame-pointer is enabled by default
-    <braunr> so your stack frame won't look like it used to be without the
-      option
-    <braunr> hence the need for USE_GCC_UNWINDER
-    <braunr> http://en.wikipedia.org/wiki/Call_stack explains this very well
-    <gnu_srs> However, kfreebsd does not seem to need USE_GCC_UNWINDER, how
-      come?
-    <braunr> i guess they don't omit the frame pointer
-    <braunr> your fix is good btw
-    <gnu_srs> thanks
-
-
-### IRC, freenode, #hurd, 2012-07-19
-
-    <gnu_srs> tschwinge: The bug in #681998 should go upstream. Applied in
-      Debian already. Hopefully this is the last patch needed for the port of
-      GNAT to Hurd.
-
-
-## Svante's patch
-
-A basic port has been done by Svante, [[!debbug 668425]], [[!debbug 681998]],
-[[!message-id "1333104917.2962.439.camel@s1499.it.kth.se"]], but there's still
-lots of work remaining.
-The port is not yet upstream: the maintainer raised some concerns that
-[[I|tschwinge]] have not yet found the time to follow up on, [[!message-id
-"1339857758-5032-1-git-send-email-thomas@codesourcery.com"]].
-While the test
-results of the GCC/GNAT testsuite don't look bad (but there are a few
-unresolved issues, and the testsuite appears to be a rather small one), I don't
-know if the port has yet seen any real-world usage, such as using it for any
-bigger Ada code bases, or any Ada testsuites.
-
-
-## `getcontext`/`makecontext`/`setcontext`/`swapcontext` usage analysis
-
-In context of [[glibc/t/tls-threadvar]].  Looking at GCC trunk commit
-f6568ea476aa52a6e23c6db43b3e240cde55783a (2013-04-26).
-
-    gcc/ada/init.c:  sigaltstack (&stack, NULL);
-    gcc/ada/init.c:      sigaltstack (&stack, NULL);
-    gcc/ada/init.c:  sigaltstack (&stack, NULL);
-    gcc/ada/s-osinte-aix.ads:   function sigaltstack
-    gcc/ada/s-osinte-aix.ads:   pragma Import (C, sigaltstack, "sigaltstack");
-    gcc/ada/s-osinte-android.ads:   function sigaltstack
-    gcc/ada/s-osinte-android.ads:   pragma Import (C, sigaltstack, "sigaltstack");
-    gcc/ada/s-osinte-darwin.ads:   function sigaltstack
-    gcc/ada/s-osinte-darwin.ads:   pragma Import (C, sigaltstack, "sigaltstack");
-    gcc/ada/s-osinte-freebsd.ads:   function sigaltstack
-    gcc/ada/s-osinte-freebsd.ads:   pragma Import (C, sigaltstack, "sigaltstack");
-    gcc/ada/s-osinte-hpux.ads:   function sigaltstack
-    gcc/ada/s-osinte-hpux.ads:   pragma Import (C, sigaltstack, "sigaltstack");
-    gcc/ada/s-osinte-kfreebsd-gnu.ads:   function sigaltstack
-    gcc/ada/s-osinte-kfreebsd-gnu.ads:   pragma Import (C, sigaltstack, "sigaltstack");
-    gcc/ada/s-osinte-linux.ads:   function sigaltstack
-    gcc/ada/s-osinte-linux.ads:   pragma Import (C, sigaltstack, "sigaltstack");
-    gcc/ada/s-osinte-rtems.adb:   -- sigaltstack --
-    gcc/ada/s-osinte-rtems.adb:   function sigaltstack
-    gcc/ada/s-osinte-rtems.adb:   end sigaltstack;
-    gcc/ada/s-osinte-rtems.ads:   function sigaltstack
-    gcc/ada/s-osinte-solaris-posix.ads:   function sigaltstack
-    gcc/ada/s-osinte-solaris-posix.ads:   pragma Import (C, sigaltstack, "sigaltstack");
-    gcc/ada/s-taprop-linux.adb:            Result := sigaltstack (Stack'Access, null);
-    gcc/ada/s-taprop-posix.adb:            Result := sigaltstack (Stack'Access, null);
-    gcc/ada/init.c:  stack.ss_sp = __gnat_alternate_stack;
-    gcc/ada/init.c:      stack.ss_sp = __gnat_alternate_stack;
-    gcc/ada/init.c:  stack.ss_sp = __gnat_alternate_stack;
-    gcc/ada/s-osinte-aix.ads:      ss_sp    : System.Address;
-    gcc/ada/s-osinte-android.ads:      ss_sp    : System.Address;
-    gcc/ada/s-osinte-darwin.ads:      ss_sp    : System.Address;
-    gcc/ada/s-osinte-darwin.ads:      uc_stack    : stack_t;          --  Stack Used By This Context
-    gcc/ada/s-osinte-freebsd.ads:      ss_sp    : System.Address;
-    gcc/ada/s-osinte-hpux.ads:      ss_sp    : System.Address;
-    gcc/ada/s-osinte-kfreebsd-gnu.ads:      ss_sp    : System.Address;
-    gcc/ada/s-osinte-linux.ads:      ss_sp    : System.Address;
-    gcc/ada/s-osinte-rtems.ads:      ss_sp    : System.Address;
-    gcc/ada/s-osinte-solaris-posix.ads:      ss_sp    : System.Address;
-    gcc/ada/s-osinte-solaris.ads:      ss_sp        : System.Address;
-    gcc/ada/s-osinte-solaris.ads:      uc_stack     : record_type_2;
-    gcc/ada/s-taprop-linux.adb:            Stack.ss_sp    := Self_ID.Common.Task_Alternate_Stack;
-    gcc/ada/s-taprop-posix.adb:            Stack.ss_sp    := Self_ID.Common.Task_Alternate_Stack;
-
-
----
-
-
-# Part II
-
-Next, Hurd-specific features can be added.  Add an interface to the
-language/environment for being able to do [[RPC]] calls, in order to program
-[[hurd/translator]]s natively in Ada.
-
-
-## Original [[community/GSoC]] Task Description
-
-[[!inline pages=community/gsoc/project_ideas/language_bindings feeds=no]]
diff --git a/open_issues/gnumach_PCI_access.mdwn b/open_issues/gnumach_PCI_access.mdwn
deleted file mode 100644
index dc099563..00000000
--- a/open_issues/gnumach_PCI_access.mdwn
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-Currently, GNU Mach requires the presence of the BIOS32 Service Directory for PCI access. 
-The other possible methods are direct access, which is somewhat dangerous and using mmconfig, the preferred default in Linux.
-Direct access is already supported, but only used if BIOS32 is present for safety reasons.
-The relevant Linux code could be adapted and reused.
-
-
-[[!tag open_issue_gnumach]]
-
diff --git a/open_issues/gnumach_console_timestamp.mdwn b/open_issues/gnumach_console_timestamp.mdwn
deleted file mode 100644
index 52b574d5..00000000
--- a/open_issues/gnumach_console_timestamp.mdwn
+++ /dev/null
@@ -1,29 +0,0 @@
-[[!meta copyright="Copyright © 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_gnumach]]
-
-There is a [[!FF_project 267]][[!tag bounty]] on this task.
-
-IRC, freenode, #hurd, 2011-02-17
-
-    <azeem> task 39011c10 deallocating an invalid port 349, most probably a
-      bug.
-    <azeem> kernel: Page fault (14), code=6
-    <azeem> Stopped at  0x28b9c7:   orb     %bh,0(%ecx,%edi,2)
-    <azeem> db> 
-    [...]
-    <antrik> tschwinge: I doubt the deallocating warning is related to the
-      later fault
-    <tschwinge> antrik: YOu may be right.
-    <tschwinge> Perhaps it'd be a good idea to add some sort of timestamp to
-      Mach messages.
-    <tschwinge> Like in Linux' dmesg.
-    <tschwinge> Or just RDTSC (internal processor counter).
diff --git a/open_issues/gnumach_constants.mdwn b/open_issues/gnumach_constants.mdwn
deleted file mode 100644
index 16c8cf41..00000000
--- a/open_issues/gnumach_constants.mdwn
+++ /dev/null
@@ -1,32 +0,0 @@
-[[!meta copyright="Copyright © 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_gnumach]]
-
-At compile-time, GNU Mach is parameterized with several constants.  These might
-need some tuning.  Debian has some patches.
-
-
-# IRC, freenode, #hurd, 2011-06-09
-
-    <braunr> youpi: in ipc/ipc_hash.c, there is code which computes the size of
-      the global (space, port)->entry hash table
-    <braunr> youpi: you may be interested in tuning this one too
-    <youpi> I know
-    <braunr> ok
-    <youpi> the current value is not so bad
-    <youpi> it's big enough for buildds to run fine
-    <braunr> 256 if i'm right
-    <braunr> well
-    <braunr> it won't fail
-    <youpi> we're limited by the 4000 object limitation anyway
-    <braunr> since it's a chained hash table
-    <braunr> but increasing it may help performances a bit
-    <braunr> and it certainly can't hurt much
diff --git a/open_issues/gnumach_general_protection_trap_gdb_vm_read.mdwn b/open_issues/gnumach_general_protection_trap_gdb_vm_read.mdwn
deleted file mode 100644
index 2df74301..00000000
--- a/open_issues/gnumach_general_protection_trap_gdb_vm_read.mdwn
+++ /dev/null
@@ -1,142 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_gnumach]]
-
-IRC, unknown channel, unknown date.
-
-    <antrik> youpi: I have found an interesting Mach problem, but I'm a bit scared of debugging it...
-    <antrik> (it is related to VM stuff)
-    <antrik> I have a memory region that is mapped by the iopl device (it's an mmio region -- graphics memory to be precise)
-    <antrik> when gdb tries to read that region with vm_read() (for a "print" command), it triggers a general protection trap...
-    <youpi> antrik: does the general protection trap kill the whole kernel or just gdb?
-    <antrik> kernel
-    <antrik> kernel: General protection trap (13), code=0
-    <antrik> pmap_copy_page(41000000,49f2000,1,0,1)
-    <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../i386/i386/phys.c:62
-    <antrik> vm_object_copy_slowly(209c1c54,41000000,1000,1,20994908)
-    <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1150
-    <antrik> vm_object_copy_strategically(209c1c54,41000000,1000,20994908,2099490c)
-    <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1669
-    <antrik> vm_map_copyin(209ba6e4,2c000,1000,0,25394ec8)
-    <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_map.c:3297
-    <antrik> vm_read(209ba6e4,2c000,1000,208d303c,25394f00)
-    <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_user.c:228
-    <antrik> _Xvm_read(2095cfe4,208d3010,0,1fff3e48,2095cfd4)
-    <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/kern/mach.server.c:1164
-    <antrik> ipc_kobject_server(2095cfd4,2095cfe4,28,127ca0,0)
-    <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../kern/ipc_kobject.c:201
-    <antrik> mach_msg_trap(1024440,3,28,30,2c)
-    <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../ipc/mach_msg.c:1367
-    <antrik> Bad frame pointer: 0x102441c
-    <antrik> BTW, is it useful at all to write down the paramenters as well?...
-    <antrik> argments I mean
-    <youpi> in the trace you mean?
-    <antrik> yes
-    <youpi> apparently the problem here is that the call to vm_fault_page() didn't perform its task
-    <youpi> which address is faulty?
-    <antrik> not sure what you mean
-    <youpi> ah shit the gpf wouldn't tell you
-    <youpi> does examine 49f2000 work?
-    <youpi> oh, wait, 4100000, that can't work
-    <youpi> +0
-    <youpi> which physical address is your mmio at?
-    <antrik> haven't tried it... but I can provoke the fault again if it helps :-)
-    <youpi> we have the 1GB limitation issue
-    <antrik> oh... lemme check
-    <youpi> no need to, I think the problem is that
-    <youpi> the iopl driver should check that it's not above phys_last_addr
-    <antrik> it's only vm_read() that fails, though...
-    <antrik> the actual program I debugged in gdb works perfectly fine
-    <youpi> yes, but that's because it's accessing the memory in a different way
-    <youpi> in the case of direct reads it just uses the page table
-    <youpi> in the case of vm_read() it uses kernel's projection
-    <youpi> but in that case it's not in the kernel projection
-    <antrik> phys = 1090519040
-    <youpi> that's it, it's beyond 1GB
-    <youpi> there's not much to do except changing mach's adressing organization
-    <antrik> yeah, that's the 0x41000000
-    <antrik> hm... I guess we could make the vm_read() bail out instead of crashing?...
-    <youpi> yes
-    <youpi> but there are a lot of places like this
-    <antrik> still, it's not exactly fun when trying to debug a program and the kernel crashes :-)
-    <youpi> right :)
-    <antrik> I could try to add the check... if you tell me where it belongs ;-)
-    <youpi> antrik: it's not just one place, that's the problem
-    <youpi> it's all the places that call pmap_zero_page, pmap_copy_page, copy_to_phys or copy_from_phys
-    <youpi> and since we do want to let the iopl device create such kind of page, in principle we have to cope with them all
-    <youpi> pmap_zero_page should be ok, though
-    <youpi> the rest isn't
-    <antrik> is that tricky, or just a matter of doing it in all places?
-
-    <antrik> hm... now it crashed in "normal" usage as well...
-    <antrik> hm... a page fault trap for a change...
-    <antrik> hm... now gdb tried to vm_read() something that is mapped to physical address 0x0...
-    <antrik> so I guess I fucked something up in the mapping code
-    <antrik> is it expected that such a vm_read() causes a kernel page fault, though?...
-    <antrik> youpi: ^
-    <youpi> nope
-    <youpi> in principle the check for validity of the page is done earlier
-    <youpi> physical address 0x0 makes sense, though
-    <antrik> OK, here is the trace:
-    <antrik> Kernel page fault (14), code=0 at address 0x0
-    <antrik> pmap_copy_page(0,6e54000,1,0,1)
-    <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../i386/i386/phys.c:62
-    <antrik> vm_object_copy_slowly(20a067b0,0,1000,1,0acacec)
-    <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1150
-    <antrik> vm_object_copy_strategically(20a067b0,0,1000,20acacec,20acacf0)
-    <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1669
-    <antrik> vm_map_copyin(20a0f1c4,120d000,1000,0,253cdec8)
-    <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_map.c:3297
-    <antrik> vm_read(20a0f1c4,120d000,1000,20a5703c,253cdf00)
-    <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_user.c:228
-    <antrik> _Xvm_read(20a52c80,20a57010,253cdf40,20ae33cc,20a52c70)
-    <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/kern/mach.server.c:1164
-    <antrik> ipc_kobject_server(20a52c70,20a52c80,28,20873074,20873070)
-    <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../kern/ipc_kobject.c:201
-    <antrik> mach_msg_trap(10247d0,3,28,30,2f)
-    <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../ipc/mach_msg.c:1367
-    <antrik> Bad frame pointer: 0x10247ac
-    <antrik> seems to be exactly the same, except for the different arguments...
-    <antrik> hm... interesting... it *does* write something to the framebuffer, before it crashes...
-    <antrik> (which unfortunately makes it a bit hard to read the panic message... ;-) )
-    <LarstiQ> heh :)
-    <antrik> wait, it must write to something else than the frame buffer as well, or else the debugger should just paint over the crap...
-    <antrik> or perhaps it crashes so hard that the debugger doesn't even work? ;-)
-    <antrik> hm... I guess the first thing I should actually do is finding out what's up with e2fsck... this make testing crashes kinda annoying :-(
-    <antrik> oh, "interesting"... I ran it on one of my other hurd partitions, and it complained about an endless number of files... (perhaps all)
-    <antrik> however, the value for the normal files was different than for the passive translator nodes
-    <antrik> it doesn't happen only on crashes; it seems that all passive translators that are still in use at time of shutdown (or crash) have the offending bit set in the inode
-    <antrik> ouch... seems it doesn't write into the framebuffer after all, but rather scribbles all over the first 4 MiB of memory -- which includes also the VGA window, before it goes on killing the kernel...
-    <youpi> which iopl driver are you using ?
-    <antrik> ?
-    <youpi> the one from the debian patch?
-    <youpi> upstream, gnumach doesn't have an iopl device any more
-    <antrik> I guess so... standard Debian stuff here
-    <antrik> oh. how does X map the memory, then?
-    <youpi> X does yes
-    <antrik> ?
-    <youpi> X uses the iopl() device to access the video memory, yes
-    <youpi> I don't know if that was what you were asking for, but that's what I meant by my answer :)
-    <antrik> yeah, I know how it does *currently* do it -- I stole the code from there :-)
-    <antrik> my question is, how is X supposed to get at the framebuffer, when there is no iopl device anymore?
-    <youpi> ah, I hadn't noticed the "how" word
-    <youpi> in Debian there is
-    <LarstiQ> !debian → !x?
-    <youpi> the clean "access device memory" interface is yet to be done
-    <antrik> err... that sounds like Xorg philosophy
-    <youpi> what, to wait for a nice interface ?
-    <antrik> "let's kill the old stuff, fuck regressions... maybe someone will figure out how to do it with the new stuff at some point. if not, not our problem"
-    <youpi> that's also a GNU philosophy
-    <youpi> ah, that one
-    <antrik> anyone know how device_map() is supposed to behave? the documentation isn't really clear...
-    <antrik> my understanding was then when an offset is specified, then the resulting object will be relative to that object; i.e. the offset of a later vm_map() on this object is applied on top of the object's internal offset...
-    <antrik> but that doesn't seem to be how it works for the iopl device, if I read the xf86 code correctly...
-    <antrik> yeah, the offset parameter seems a nop when doing device_map() on the iopl device
diff --git a/open_issues/gnumach_i686.mdwn b/open_issues/gnumach_i686.mdwn
deleted file mode 100644
index b34df73b..00000000
--- a/open_issues/gnumach_i686.mdwn
+++ /dev/null
@@ -1,26 +0,0 @@
-[[!meta copyright="Copyright © 2012 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_gnumach]]
-
-
-# IRC, freenode, #hurd, 2012-07-05
-
-    <braunr> we could use a gnumach-i686 too
-    <pinotree> how would you compile gnumach as i686 variant btw? add
-      -march=.. or something like that in CFLAGS?
-    <braunr> yes
-    <braunr> at least we'll get some cmovs :)
-
-
-## IRC, freenode, #hurd, 2012-07-07
-
-    <braunr> it was rejected in the past because we didn't think it would bring
-      real performance benefit, but it actually may
diff --git a/open_issues/gnumach_integer_overflow.mdwn b/open_issues/gnumach_integer_overflow.mdwn
deleted file mode 100644
index 08a29268..00000000
--- a/open_issues/gnumach_integer_overflow.mdwn
+++ /dev/null
@@ -1,50 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 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_gnumach]]
-
-
-# IRC, freenode, #hurd, 2012-07-04
-
-    <braunr> yes, we have integer overflows on resident_page_count, but
-      luckily, the member is rarely used
-
-See also [[gnumach_vm_object_resident_page_count]].
-
-
-## IRC, freenode, #hurd, 2013-06-04
-
-    <elmig> this is declared as int on vm_object.h
-    <elmig> and as it as counter it's always positive
-    <braunr> yes it should be unsigned
-    <elmig> ok
-    <braunr> but leave it as it is for consistency with the rest
-    <elmig> i send patch :)
-    <braunr> please no
-    <braunr> unless you've fully determined the side effects
-    <elmig> i've grepped the vars and saw only comparisons > and = 0
-    <elmig> never less than 0
-    <braunr> > 0 is the same
-    <braunr> well
-    <braunr> > not, but >= would be a problem
-    <elmig> http://paste.debian.net/plain/8527
-    <elmig> asctually no >=0
-    <braunr> still, i don't want to change that unless it's strictly necessary
-    <braunr> hum, you're grepping ref_count, not resident_page_count
-    <elmig> i did both
-    <elmig> on resident_page_count theres resident_page_count >= 0
-    <elmig> = 0, == 0
-    <braunr> this isn't the only possible issue
-    <braunr> anyway
-    <braunr> for now there is no reason to change anything unless you do a full
-      review
-    <elmig> only place i see resdent_page_count and page_count being decreased
-      it's on vm/vm_resident.c
-    <elmig> vm_page_remove() and vm_page_replace()
diff --git a/open_issues/gnumach_kernel_threads.mdwn b/open_issues/gnumach_kernel_threads.mdwn
deleted file mode 100644
index 9591986b..00000000
--- a/open_issues/gnumach_kernel_threads.mdwn
+++ /dev/null
@@ -1,23 +0,0 @@
-[[!meta copyright="Copyright © 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_gnumach]]
-
-IRC, freenode, #hurd, 2011-07-13
-
-    <braunr> jkoenig: why does gnumach appear as "root=device:hd0s1" in ps ?
-    <jkoenig> braunr, it's the closest we can do to its command line
-    <braunr> doesn't it deserve something special like kernel threads in linux
-      ?
-    <braunr> so that it's actually clear that it's a special task/process
-    <jkoenig> you mean something like [mach root=device:hd0s1] ?
-    <braunr> something like that yes
-    <braunr> also, it would be nice if gnumach threads could actually be seen,
-      i don't remember if the mach interface allows it though
diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn
deleted file mode 100644
index b36c674a..00000000
--- a/open_issues/gnumach_memory_management.mdwn
+++ /dev/null
@@ -1,2391 +0,0 @@
-[[!meta copyright="Copyright © 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_gnumach]]
-
-There is a [[!FF_project 266]][[!tag bounty]] on this task.
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2011-04-12
-
-    <antrik> braunr: do you think the allocator you wrote for x15 could be used
-      for gnumach? and would you be willing to mentor this? :-)
-    <braunr> antrik: to be willing to isn't my current problem
-    <braunr> antrik: and yes, I think my allocator can be used
-    <braunr> it's a slab allocator after all, it only requires reap() and
-      grow()
-    <braunr> or mmap()/munmap() whatever you want to call it
-    <braunr> a backend
-    <braunr> antrik: although i've been having other ideas recently
-    <braunr> that would have more impact on our usage patterns I think
-    <antrik> mcsim: have you investigated how the zone allocator works and how
-      it's hooked into the system yet?
-    <braunr> mcsim: now let me give you a link
-    <braunr> mcsim:
-      http://git.sceen.net/rbraun/libbraunr.git/?a=blob;f=mem.c;h=330436e799f322949bfd9e2fedf0475660309946;hb=HEAD
-    <braunr> mcsim: this is an implementation of the slab allocator i've been
-      working on recently
-    <braunr> mcsim: i haven't made it public because i reworked the per
-      processor layer, and this part isn't complete yet
-    <braunr> mcsim: you could use it as a reference for your project
-    <mcsim> braunr: ok
-    <braunr> it used to be close to the 2001 vmem paper
-    <braunr> but after many tests, fragmentation and accounting issues have
-      been found
-    <braunr> so i rewrote it to be closer to the linux implementation (cache
-      filling/draining in bukl transfers)
-    <braunr> bulk*
-    <braunr> they actually use the word draining in linux too :)
-    <mcsim> antrik: not complete yet.
-    <antrik> braunr: oh, it's unfinished? that's unfortunate...
-    <braunr> antrik: only the per processor part
-    <braunr> antrik: so it doesn't matter much for gnumach
-    <braunr> and it's not difficult to set up
-    <antrik> mcsim: hm, OK... but do you think you will have a fairly good
-      understanding in the next couple of days?...
-    <antrik> I'm asking because I'd really like to see a proposal a bit more
-      specific than "I'll look into things..."
-    <antrik> i.e. you should have an idea which things you will actually have
-      to change to hook up a new allocator etc.
-    <antrik> braunr: OK. will the interface remain unchanged, so it could be
-      easily replaced with an improved implementation later?
-    <braunr> the zone allocator in gnumach is a badly written bare object
-      allocator actually, there aren't many things to understand about it
-    <braunr> antrik: yes
-    <antrik> great :-)
-    <braunr> and the per processor part should be very close to the phys
-      allocator sitting next to it
-    <braunr> (with the slight difference that, as per cpu caches have variable
-      sizes, they are allocated on the free path rather than on the allocation
-      path)
-    <braunr> this is a nice trick in the vmem paper i've kept in mind
-    <braunr> and the interface also allows to set a "source" for caches
-    <antrik> ah, good point... do you think we should replace the physmem
-      allocator too? and if so, do it in one step, or one piece at a time?...
-    <braunr> no
-    <braunr> too many drivers currently depend on the physical allocator and
-      the pmap module as they are
-    <braunr> remember linux 2.0 drivers need a direct virtual to physical
-      mapping
-    <braunr> (especially true for dma mappings)
-    <antrik> OK
-    <braunr> the nice thing about having a configurable memory source is that
-    <antrik> whot do you mean by "allocated on the free path"?
-    <braunr> even if most caches will use the standard vm_kmem module as their
-      backend
-    <braunr> there is one exception in the vm_map module, allowing us to get
-      rid of either a static limit, or specific allocation code
-    <braunr> antrik: well, when you allocate a page, the allocator will lookup
-      one in a per cpu cache
-    <braunr> if it's empty, it fills the cache
-    <braunr> (called pools in my implementations)
-    <braunr> it then retries
-    <braunr> the problem in the slab allocator is that per cpu caches have
-      variable sizes
-    <braunr> so per cpu pools are allocated from their own pools
-    <braunr> (remember the magazine_xx caches in the output i showed you, this
-      is the same thing)
-    <braunr> but if you allocate them at allocation time, you could end up in
-      an infinite loop
-    <braunr> so, in the slab allocator, when a per cpu cache is empty, you just
-      fall back to the slab layer
-    <braunr> on the free path, when a per cpu cache doesn't exist, you allocate
-      it from its own cache
-    <braunr> this way you can't have an infinite loop
-    <mcsim> antrik: I'll try, but I have exams now.
-    <mcsim> As I understand amount of elements which could be allocated we
-      determine by zone initialization. And at this time memory for zone is
-      reserved. I'm going to change this. And make something similar to kmalloc
-      and vmalloc (support for pages consecutive physically and virtually). And
-      pages in zones consecutive always physically.
-    <mcsim> Am I right?
-    <braunr> mcsim: don't try to do that
-    <mcsim> why?
-    <braunr> mcsim: we just need a slab allocator with an interface close to
-      the zone allocator
-    <antrik> mcsim: IIRC the size of the complete zalloc map is fixed; but not
-      the number of elements per zone
-    <braunr> we don't need two allocators like kmalloc and vmalloc
-    <braunr> actually we just need vmalloc
-    <braunr> IIRC the limits are only present because the original developers
-      wanted to track leaks
-    <braunr> they assumed zones would be large enough, which isn't true any
-      more today
-    <braunr> but i didn't see any true reservation
-    <braunr> antrik: i'm not sure i was clear enough about the "allocation of
-      cpu caches on the free path"
-    <braunr> antrik: for a better explanation, read the vmem paper ;)
-    <antrik> braunr: you mean there is no fundamental reason why the zone map
-      has a limited maximal size; and it was only put in to catch cases where
-      something eats up all memory with kernel object creation?...
-    <antrik> braunr: I think I got it now :-)
-    <braunr> antrik: i'm pretty certin of it yes
-    <antrik> I don't see though how it is related to what we were talking
-      about...
-    <braunr> 10:55 < braunr> and the per processor part should be very close to
-      the phys allocator sitting next to it
-    <braunr> the phys allocator doesn't have to use this trick
-    <braunr> because pages have a fixed size, so per cpu caches all have the
-      same size too
-    <braunr> and the number of "caches", that is, physical segments, is limited
-      and known at compile time
-    <braunr> so having them statically allocated is possible
-    <antrik> I see
-    <braunr> it would actually be very difficult to have a phys allocator
-      requiring dynamic allocation when the dynamic allocator isn't yet ready
-    <antrik> hehe :-)
-    <mcsim> total size of all zone allocations is limited to 12 MB. And is "was
-      only put in to catch cases where something eats up all memory with kernel
-      object creation?"
-    <braunr> mcsim: ah right, there could be a kernel submap backing all the
-      zones
-    <braunr> but this can be increased too
-    <braunr> submaps are kind of evil :/
-    <antrik> mcsim: I think it's actually 32 MiB or something like that in the
-      Debian version...
-    <antrik> braunr: I'm not sure I ever fully understood what the zalloc map
-      is... I looked through the code once, and I think I got a rough
-      understading, but I was still pretty uncertain about some bits. and I
-      don't remember the details anyways :-)
-    <braunr> antrik: IIRC, it's a kernel submap
-    <braunr> it's named kmem_map in x15
-    <antrik> don't know what a submap is
-    <braunr> submaps are vm_map objects
-    <braunr> in a top vm_map, there are vm_map_entries
-    <braunr> these entries usually point to vm_objects
-    <braunr> (for the page cache)
-    <braunr> but they can point to other maps too
-    <braunr> the goal is to reduce fragmentation by isolating allocations
-    <braunr> this also helps reducing contention
-    <braunr> for exemple, on BSD, there is a submap for mbufs, so that the
-      network code doesn't interfere too much with other kernel allocations
-    <braunr> antrik: they are similar to spans in vmem, but vmem has an elegant
-      importing mechanism which eliminates the static limit problem
-    <antrik> so memory is not directly allocated from the physical allocator,
-      but instead from another map which in turn contains physical memory, or
-      something like that?...
-    <braunr> no, this is entirely virtual
-    <braunr> submaps are almost exclusively used for the kernel_map
-    <antrik> you are using a lot of identifies here, but I don't remember (or
-      never knew) what most of them mean :-(
-    <braunr> sorry :)
-    <braunr> the kernel map is the vm_map used to represent the ~1 GiB of
-      virtual memory the kernel has (on i386)
-    <braunr> vm_map objects are simple virtual space maps
-    <braunr> they contain what you see in linux when doing /proc/self/maps
-    <braunr> cat /proc/self/maps
-    <braunr> (linux uses entirely different names but it's roughly the same
-      structure)
-    <braunr> each line is a vm_map_entry
-    <braunr> (well, there aren't submaps in linux though)
-    <braunr> the pmap tool on netbsd is able to show the kernel map with its
-      submaps, but i don't have any image around
-    <mcsim> braunr: is limit for zones is feature and shouldn't be changed?
-    <braunr> mcsim: i think we shouldn't have fixed limits for zones
-    <braunr> mcsim: this should be part of the debugging facilities in the slab
-      allocator
-    <braunr> is this fixed limit really a major problem ?
-    <braunr> i mean, don't focus on that too much, there are other issues
-      requiring more attention
-    <antrik> braunr: at 12 MiB, it used to be, causing a lot of zalloc
-      panics. after increasing, I don't think it's much of a problem anymore...
-    <antrik> but as memory sizes grow, it might become one again
-    <antrik> that's the problem with a fixed size...
-    <braunr> yes, that's the issue with submaps
-    <braunr> but gnumach is full of those, so let's fix them by order of
-      priority
-    <antrik> well, I'm still trying to digest what you wrote about submaps :-)
-    <braunr> i'm downloading netbsd, so you can have a good view of all this
-    <antrik> so, when the kernel allocates virtual address space regions
-      (mostly for itself), instead of grabbing chunks of the address space
-      directly, it takes parts out of a pre-reserved region?
-    <braunr> not exactly
-    <braunr> both statements are true
-    <mcsim> antrik: only virtual addresses are reserved
-    <braunr> it grabs chunks of the address space directly, but does so in a
-      reserved region of the address space
-    <braunr> a submap is like a normal map, it has a start address, a size, and
-      is empty, then it's populated with vm_map_entries
-    <braunr> so instead of allocating from 3-4 GiB, you allocate from, say,
-      3.1-3.2 GiB
-    <antrik> yeah, that's more or less what I meant...
-    <mcsim> braunr: I see two problems: limited zones and absence of caching. 
-    <mcsim> with caching absence of readahead paging will be not so significant
-    <braunr> please avoid readahead
-    <mcsim> ok
-    <braunr> and it's not about paging, it's about kernel memory, which is
-      wired
-    <braunr> (well most of it)
-    <braunr> what about limited zones ?
-    <braunr> the whole kernel space is limited, there has to be limits
-    <braunr> the problem is how to handle them
-    <antrik> braunr: almost all. I looked through all zones once, and IIRC I
-      found exactly one that actually allows paging...
-    <braunr> currently, when you reach the limit, you have an OOM error
-    <braunr> antrik: yes, there are
-    <braunr> i don't remember which implementation does that but, when
-      processes haven't been active for a minute or so, they are "swapedout"
-    <braunr> completely
-    <braunr> even the kernel stack
-    <braunr> and the page tables
-    <braunr> (most of the pmap structures are destroyed, some are retained)
-    <antrik> that might very well be true... at least inactive processes often
-      show up with 0 memory use in top on Hurd
-    <braunr> this is done by having a pageable kernel map, with wired entries
-    <braunr> when the swapper thread swaps tasks out, it unwires them
-    <braunr> but i think modern implementations don't do that any more
-    <antrik> well, I was talking about zalloc only :-)
-    <braunr> oh
-    <braunr> so the zalloc_map must be pageable
-    <braunr> or there are two submaps ?
-    <antrik> not sure whether "morden implementations" includes Linux ;-)
-    <braunr> no, i'm talking about the bsd family only
-    <antrik> but it's certainly true that on Linux even inactive processes
-      retain some memory
-    <braunr> linux doesn't make any difference between processor-bound and
-      I/O-bound processes
-    <antrik> braunr: I have no idea how it works. I just remember that when
-      creating zones, one of the optional flags decides whether the zone is
-      pagable. but as I said, IIRC there is exactly one that actually is...
-    <braunr> zone_map = kmem_suballoc(kernel_map, &zone_min, &zone_max,
-      zone_map_size, FALSE);
-    <braunr> kmem_suballoc(parent, min, max, size, pageable)
-    <braunr> so the zone_map isn't
-    <antrik> IIRC my conclusion was that pagable zones do not count in the
-      fixed zone map limit... but I'm not sure anymore
-    <braunr> zinit() has a memtype parameter
-    <braunr> with ZONE_PAGEABLE as a possible flag
-    <braunr> this is wierd :)
-    <mcsim> There is no any zones which use ZONE_PAGEABLE flag
-    <antrik> mcsim: are you sure? I think I found one...
-    <braunr> if (zone->type & ZONE_PAGEABLE) {
-    <antrik> admittedly, it is several years ago that I looked into this, so my
-      memory is rather dim...
-    <braunr> if (kmem_alloc_pageable(zone_map, &addr, ...
-    <braunr> calling kmem_alloc_pageable() on an unpageable submap seems wrong
-    <mcsim> I've greped gnumach code and there is no any zinit procedure call
-      with ZONE_PAGEABLE flag
-    <braunr> good
-    <antrik> hm... perhaps it was in some code that has been removed
-      alltogether since ;-)
-    <antrik> actually I think it would be pretty neat to have pageable kernel
-      objects... but I guess it would require considerable effort to implement
-      this right
-    <braunr> mcsim: you also mentioned absence of caching
-    <braunr> mcsim: the zone allocator actually is a bare caching object
-      allocator
-    <braunr> antrik: no, it's easy
-    <braunr> antrik: i already had that in x15 0.1
-    <braunr> antrik: the problem is being sure the objects you allocate from a
-      pageable backing store are never used when resolving a page fault
-    <braunr> that's all
-    <antrik> I wouldn't expect that to be easy... but surely you know better
-      :-)
-    <mcsim> braunr: indeed. I was wrong.
-    <antrik> braunr: what is a caching object allocator?...
-    <braunr> antrik: ok, it's not easy
-    <braunr> antrik: but once you have vm_objects implemented, having pageable
-      kernel object is just a matter of using the right options, really
-    <braunr> antrik: an allocator that caches its buffers
-    <braunr> some years ago, the term "object" would also apply to
-      preconstructed buffers
-    <antrik> I have no idea what you mean by "caches its buffers" here :-)
-    <braunr> well, a memory allocator which doesn't immediately free its
-      buffers caches them
-    <mcsim> braunr: but can it return objects to system?
-    <braunr> mcsim: which one ?
-    <antrik> yeah, obviously the *implementation* of pageable kernel objects is
-      not hard. the tricky part is deciding which objects can be pageable, and
-      which need to be wired...
-    <mcsim> Can zone allocator return cached objects to system as in slab?
-    <mcsim> I mean reap()
-    <braunr> well yes, it does so, and it does that too often
-    <braunr> the caching in the zone allocator is actually limited to the
-      pagesize
-    <braunr> once page is completely free, it is returned to the vm
-    <mcsim> this is bad caching
-    <braunr> yes
-    <mcsim> if object takes all page than there is now caching at all
-    <braunr> caching by side effect
-    <braunr> true
-    <braunr> but the linux slab allocator does the same thing :p
-    <braunr> hm
-    <braunr> no, the solaris slab allocator does so
-    <mcsim> linux's slab returns objects only when system ask
-    <antrik> without preconstructed objects, is there actually any point in
-      caching empty slabs?...
-    <mcsim> Once I've changed my allocator to slab and it cached more than 1GB
-      of my memory)
-    <braunr> ok wait, need to fix a few mistakes first
-    <mcsim> s/ask/asks
-    <braunr> the zone allocator (in gnumach) actually has a garbage collector
-    <antrik> braunr: well, the Solaris allocator follows the slab/magazine
-      paper, right? so there is caching at the magazine layer... in that case
-      caching empty slabs too would be rather redundant I'd say...
-    <braunr> which is called when running low on memory, similar to the slab
-      allocaotr
-    <braunr> antrik: yes
-    <antrik> (or rather the paper follows the Solaris allocator ;-) )
-    <braunr> mcsim: the zone allocator reap() is zone_gc()
-    <antrik> braunr: hm, right, there is a "collectable" flag for zones... but
-      I never understood what it means
-    <antrik> braunr: BTW, I heard Linux has yet another allocator now called
-      "slob"... do you happen to know what that is?
-    <braunr> slob is a very simple allocator for embedded devices
-    <mcsim> AFAIR this is just heap allocator
-    <braunr> useful when you have a very low amount of memory
-    <braunr> like 1 MiB
-    <braunr> yes
-    <antrik> just googled it :-)
-    <braunr> zone and slab are very similar
-    <antrik> sounds like a simple heap allocator
-    <mcsim> there is another allocator that calls slub, and it better than slab
-      in many cases
-    <braunr> the main difference is the data structures used to store slabs
-    <braunr> mcsim: i disagree
-    <antrik> mcsim: ah, you already said that :-)
-    <braunr> mcsim: slub is better for systems with very large amounts of
-      memory and processors
-    <braunr> otherwise, slab is better
-    <braunr> in addition, there are accounting issues with slub
-    <braunr> because of cache merging
-    <mcsim> ok. This strange that slub is default allocator
-    <braunr> well both are very good
-    <braunr> iirc, linus stated that he really doesn't care as long as its
-      works fine
-    <braunr> he refused slqb because of that
-    <braunr> slub is nice because it requires less memory than slab, while
-      still being as fast for most cases
-    <braunr> it gets slower on the free path, when the cpu performing the free
-      is different from the one which allocated the object
-    <braunr> that's a reasonable cost
-    <mcsim> slub uses heap for large object. Are there any tests that compare
-      what is better for large objects?
-    <antrik> well, if slub requires less memory, why do you think slab is
-      better for smaller systems? :-)
-    <braunr> antrik: smaller is relative
-    <antrik> mcsim: for large objects slab allocation is rather pointless, as
-      you don't have multiple objects in a page anyways...
-    <braunr> antrik: when lameter wrote slub, it was intended for systems with
-      several hundreds processors
-    <antrik> BTW, was slqb really refused only because the other ones are "good
-      enough"?...
-    <braunr> yes
-    <antrik> wow, that's a strange argument...
-    <braunr> linus is already unhappy of having "so many" allocators
-    <antrik> well, if the new one is better, it could replace one of the others
-      :-)
-    <antrik> or is it useful only in certain cases?
-    <braunr> that's the problem
-    <braunr> nobody really knows
-    <antrik> hm, OK... I guess that should be tested *before* merging ;-)
-    <antrik> is anyone still working on it, or was it abandonned?
-    <antrik> mcsim: back to caching...
-    <antrik> what does caching in the kernel object allocator got to do with
-      readahead (i.e. clustered paging)?...
-    <mcsim> if we cached some physical pages we don't need to find new ones for
-      allocating new object. And that's why there will not be a page fault.
-    <mcsim> antrik: Regarding kam. Hasn't he finished his project?
-    <antrik> err... what?
-    <antrik> one of us must be seriously confused
-    <antrik> I totally fail to see what caching of physical pages (which isn't
-      even really a correct description of what slab does) has to do with page
-      faults
-    <antrik> right, KAM didn't finish his project
-    <mcsim> If we free the physical page and return it to system we need
-      another one for next allocation. But if we keep it, we don't need to find
-      new physical page. 
-    <mcsim> And physical page is allocated only then when page fault
-      occurs. Probably, I'm wrong
-    <antrik> what does "return to system" mean? we are talking about the
-      kernel...
-    <antrik> zalloc/slab are about allocating kernel objects. this doesn't have
-      *anything* to do with paging of userspace processes
-    <antrik> only thing the have in common is that they need to get pages from
-      the physical page allocator. but that's yet another topic
-    <mcsim> Under "return to system" I mean ability to use this page for other
-      needs.
-    <braunr> mcsim: consider kernel memory to be wired
-    <braunr> here, return to system means releasing a page back to the vm
-      system
-    <braunr> the vm_kmem module then unmaps the physical page and free its
-      virtual address in the kernel map
-    <mcsim> ok
-    <braunr> antrik: the problem with new allocators like slqb is that it's
-      very difficult to really know if they're better, even with extensive
-      testing
-    <braunr> antrik: there are papers (like wilson95) about the difficulties in
-      making valuable results in this field
-    <braunr> see
-      http://www.sceen.net/~rbraun/dynamic_storage_allocation_a_survey_and_critical_review.pdf
-    <mcsim> how can be allocated physically continuous object now?
-    <braunr> mcsim: rephrase please
-    <mcsim> what is similar to kmalloc in Linux to gnumach?
-    <braunr> i know memory is reserved for dma in a direct virtual to physical
-      mapping
-    <braunr> so even if the allocation is done similarly to vmalloc()
-    <braunr> the selected region of virtual space maps physical memory, so
-      memory is physically contiguous too
-    <braunr> for other allocation types, a block large enough is allocated, so
-      it's contiguous too
-    <mcsim> I don't clearly understand. If we have fragmentation in physical
-      ram, so there aren't 2 free pages in a row, but there are able apart, we
-      can't to allocate these 2 pages along?
-    <braunr> no
-    <braunr> but every system has this problem
-    <mcsim> But since we have only 12 or 32 MB of memory the problem becomes
-      more significant
-    <braunr> you're confusing virtual and physical memory
-    <braunr> those 32 MiB are virtual
-    <braunr> the physical pages backing them don't have to be contiguous
-    <mcsim> Oh, indeed 
-    <mcsim> So the only problem are limits?
-    <braunr> and performance
-    <braunr> and correctness
-    <braunr> i find the zone allocator badly written
-    <braunr> antrik: mcsim: here is the content of the kernel pmap on NetBSD
-      (which uses a virtual memory system close to the Mach VM)
-    <braunr> antrik: mcsim: http://www.sceen.net/~rbraun/pmap.out
-
-[[pmap.out]]
-
-    <braunr> you can see the kmem_map (which is used for most general kernel
-      allocations) is 128 MiB large
-    <braunr> actually it's not the kernel pmap, it's the kernel_map
-    <antrik> braunr: why is it called pmap.out then? ;-)
-    <braunr> antrik: because the tool is named pmap
-    <braunr> for process map
-    <braunr> it also exists under Linux, although direct access to
-      /proc/xx/maps gives more info
-    <mcsim> braunr: I've said that this is kernel_map. Can I see kernel_map for
-      Linux?
-    <braunr> mcsim: I don't know how to do that
-    <mcsim> s/I've/You've
-    <braunr> but Linux doesn't have submaps, and uses a direct virtual to
-      physical mapping, so it's used differently
-    <antrik> how are things (such as zalloc zones) entered into kernel_map?
-    <braunr> in zone_init() you have
-    <braunr> zone_map = kmem_suballoc(kernel_map, &zone_min, &zone_max,
-      zone_map_size, FALSE);
-    <braunr> so here, kmem_map is named zone_map
-    <braunr> then, in zalloc()
-    <braunr> kmem_alloc_wired(zone_map, &addr, zone->alloc_size)
-    <antrik> so, kmem_alloc just deals out chunks of memory referenced directly
-      by the address, and without knowing anything about the use?
-    <braunr> kmem_alloc() gives virtual pages
-    <braunr> zalloc() carves them into buffers, as in the slab allocator
-    <braunr> the difference is essentially the lack of formal "slab" object
-    <braunr> which makes the zone code look like a mess
-    <antrik> so kmem_suballoc() essentially just takes a bunch of pages from
-      the main kernel_map, and uses these to back another map which then in
-      turn deals out pages just like the main kernel_map?
-    <braunr> no
-    <braunr> kmem_suballoc creates a vm_map_entry object, and sets its start
-      and end address
-    <braunr> and creates a vm_map object, which is then inserted in the new
-      entry
-    <braunr> maybe that's what you meant with "essentially just takes a bunch
-      of pages from the main kernel_map"
-    <braunr> but there really is no allocation at this point
-    <braunr> except the map entry and the new map objects
-    <antrik> well, I'm trying to understand how kmem_alloc() manages things. so
-      it has map_entry structures like the maps of userspace processes? do
-      these also reference actual memory objects?
-    <braunr> kmem_alloc just allocates virtual pages from a vm_map, and backs
-      those with physical pages (unless the user requested pageable memory)
-    <braunr> it's not "like the maps of userspace processes"
-    <braunr> these are actually the same structures
-    <braunr> a vm_map_entry can reference a memory object or a kernel submap
-    <braunr> in netbsd, it can also referernce nothing (for pure wired kernel
-      memory like the vm_page array)
-    <braunr> maybe it's the same in mach, i don't remember exactly
-    <braunr> antrik: this is actually very clear in vm/vm_kern.c
-    <braunr> kmem_alloc() creates a new kernel object for the allocation
-    <braunr> allocates a new entry (or uses a previous existing one if it can
-      be extended) through vm_map_find_entry()
-    <braunr> then calls kmem_alloc_pages() to back it with wired memory
-    <antrik> "creates a new kernel object" -- what kind of kernel object?
-    <braunr> kmem_alloc_wired() does roughly the same thing, except it doesn't
-      need a new kernel object because it knows the new area won't be pageable
-    <braunr> a simple vm_object
-    <braunr> used as a container for anonymous memory in case the pages are
-      swapped out
-    <antrik> vm_object is the same as memory object/pager? or yet something
-      different?
-    <braunr> antrik: almost
-    <braunr> antrik: a memory_object is the user view of a vm_object
-    <braunr> as in the kernel/user interfaces used by external pagers
-    <braunr> vm_object is a more internal name
-    <mcsim> Is fragmentation a big problem in slab allocator?
-    <mcsim> I've tested it on my computer in Linux and for some caches it
-      reached 30-40%
-    <antrik> well, fragmentation is a major problem for any allocator...
-    <antrik> the original slab allocator was design specifically with the goal
-      of reducing fragmentation
-    <antrik> the revised version with the addition of magazines takes a step
-      back on this though
-    <antrik> have you compared it to slub? would be pretty interesting...
-    <mcsim> I have an idea how can it be decreased, but it will hurt by
-      performance...
-    <mcsim> antrik: no I haven't, but there will be might the same, I think
-    <mcsim> if each cache will handle two types of object: with sizes that will
-      fit cache sizes (or I bit smaller) and with sizes which are much smaller
-      than maximal cache size. For first type of object will be used standard
-      slab allocator and for latter type will be used (within page) heap
-      allocator.
-    <mcsim> I think that than fragmentation will be decreased
-    <antrik> not at all. heap allocator has much worse fragmentation. that's
-      why slab allocator was invented
-    <antrik> the problem is that in a long-running program (such an the
-      kernel), objects tend to have vastly varying lifespans
-    <mcsim> but we use heap only for objects of specified sizes
-    <antrik> so often a few old objects will keep a whole page hostage
-    <mcsim> for example for 32 byte cache it could be 20-28 byte objects
-    <antrik> that's particularily visible in programs such as firefox, which
-      will grow the heap during use even though actual needs don't change
-    <antrik> the slab allocator groups objects in a fashion that makes it more
-      likely adjacent objects will be freed at similar times
-    <antrik> well, that's pretty oversimplyfied, but I hope you get the
-      idea... it's about locality
-    <mcsim> I agree, but I speak not about general heap allocation. We have
-      many heaps for objects with different sizes.
-    <mcsim> Could it be better?
-    <antrik> note that this has been a topic of considerable research. you
-      shouldn't seek to improve the actual algorithms -- you would have to read
-      up on the existing research at least before you can contribute anything
-      to the field :-)
-    <antrik> how would that be different from the slab allocator?
-    <mcsim> slab will allocate 32 byte for both 20 and 32 byte requests
-    <mcsim> And if there was request for 20 bytes we get 12 unused
-    <antrik> oh, you mean the implementation of the generic allocator on top of
-      slabs? well, that might not be optimal... but it's not an often used case
-      anyways. mostly the kernel uses constant-sized objects, which get their
-      own caches with custom tailored size
-    <antrik> I don't think the waste here matters at all
-    <mcsim> affirmative. So my idea is useless. 
-    <antrik> does the statistic you refer to show the fragmentation in absolute
-      sizes too?
-    <mcsim> Can you explain what is absolute size?
-    <mcsim> I've counted what were requested (as parameter of kmalloc) and what
-      was really allocated (according to best fit cache size).
-    <antrik> how did you get that information?
-    <mcsim> I simply wrote a hook
-    <antrik> I mean total. i.e. how many KiB or MiB are wasted due to
-      fragmentation alltogether
-    <antrik> ah, interesting. how does it work?
-    <antrik> BTW, did you read the slab papers?
-    <mcsim> Do you mean articles from lwn.net?
-    <antrik> no 
-    <antrik> I mean the papers from the Sun hackers who invented the slab
-      allocator(s)
-    <antrik> Bonwick mostly IIRC
-    <mcsim> Yes
-    <antrik> hm... then you really should know the rationale behind it...
-    <mcsim> There he says about 11% percent of memory waste
-    <antrik> you didn't answer my other questions BTW :-)
-    <mcsim> I've corrupted kernel tree with patch, and tomorrow I'm going to
-      read myself up for exam (I have it on Thursday). But than I'll send you a
-      module which I've used for testing.
-    <antrik> OK
-    <mcsim> I can send you module now, but it will not work without patch.
-    <mcsim> It would be better to rewrite it using debugfs, but when I was
-      writing this test I didn't know about trace_* macros
-
-
-# IRC, freenode, #hurd, 2011-04-15
-
-    <mcsim> There is a hack in zone_gc when it allocates and frees two
-      vm_map_kentry_zone elements to make sure the gc will be able to allocate
-      two in vm_map_delete. Isn't it better to allocate memory for these
-      entries statically?
-    <youpi> mcsim: that's not the point of the hack
-    <youpi> mcsim: the point of the hack is to make sure vm_map_delete will be
-      able to allocate stuff
-    <youpi> allocating them statically will just work once
-    <youpi> it may happen several times that vm_map_delete needs to allocate it
-      while it's empty (and thus zget_space has to get called, leading to a
-      hang)
-    <youpi> funnily enough, the bug is also in macos X
-    <youpi> it's still in my TODO list to manage to find how to submit the
-      issue to them
-    <braunr> really ?
-    <braunr> eh
-    <braunr> is that because of map entry splitting ?
-    <youpi> it's git commit efc3d9c47cd744c316a8521c9a29fa274b507d26
-    <youpi> braunr: iirc something like this, yes
-    <braunr> netbsd has this issue too
-    <youpi> possibly
-    <braunr> i think it's a fundamental problem with the design
-    <braunr> people think of munmap() as something similar to free()
-    <braunr> whereas it's really unmap
-    <braunr> with a BSD-like VM, unmap can easily end up splitting one entry in
-      two
-    <braunr> but your issue is more about harmful recursion right ?
-    <youpi> I don't remember actually
-    <youpi> it's quite some time ago :)
-    <braunr> ok
-    <braunr> i think that's why i have "sources" in my slab allocator, the
-      default source (vm_kern) and a custom one for kernel map entries
-
-
-# IRC, freenode, #hurd, 2011-04-18
-
-    <mcsim> braunr: you've said that once page is completely free, it is
-      returned to the vm.
-    <mcsim> who else, besides zone_gc, can return free pages to the vm?
-    <braunr> mcsim: i also said i was wrong about that
-    <braunr> zone_gc is the only one
-
-
-# IRC, freenode, #hurd, 2011-04-19
-
-    <braunr> antrik: mcsim: i added back a new per-cpu layer as planned
-    <braunr>
-      http://git.sceen.net/rbraun/libbraunr.git/?a=blob;f=mem.c;h=c629b2b9b149f118a30f0129bd8b7526b0302c22;hb=HEAD
-    <braunr> mcsim: btw, in mem_cache_reap(), you can clearly see there are two
-      loops, just as in zone_gc, to reduce contention and avoid deadlocks
-    <braunr> this is really common in memory allocators
-
-
-# IRC, freenode, #hurd, 2011-04-23
-
-    <mcsim> I've looked through some allocators and all of them use different
-      per cpu cache policy. AFAIK gnuhurd doesn't support multiprocessing, but
-      still multiprocessing must be kept in mind. So, what do you think what
-      kind of cpu caches is better? As for me I like variant with only per-cpu
-      caches (like in slqb).
-    <antrik> mcsim: well, have you looked at the allocator braunr wrote
-      himself? :-)
-    <antrik> I'm not sure I suggested that explicitly to you; but probably it
-      makes most sense to use that in gnumach
-
-
-# IRC, freenode, #hurd, 2011-04-24
-
-    <mcsim> antrik: Yes, I have. He uses both global and per cpu caches. But he
-      also suggested to look through slqb, where there are only per cpu
-      caches.\
-    <braunr> i don't remember slqb in detail
-    <braunr> what do you mean by "only per-cpu caches" ?
-    <braunr> a whole slab sytem for each cpu ?
-    <mcsim> I mean that there are no global queues in caches, but there are
-      special queues for each cpu.
-    <mcsim> I've just started investigating slqb's code, but I've read an
-      article on lwn about it. And I've read that it is used for zen kernel.
-    <braunr> zen ?
-    <mcsim> Here is this article http://lwn.net/Articles/311502/
-    <mcsim> Yes, this is linux kernel with some patches which haven't been
-      approved to torvald's tree
-    <mcsim> http://zen-kernel.org/
-    <braunr> i see
-    <braunr> well it looks nice
-    <braunr> but as for slub, the problem i can see is cross-CPU freeing
-    <braunr> and I think nick piggins mentions it
-    <braunr> piggin*
-    <braunr> this means that sometimes, objects are "burst-free" from one cpu
-      cache to another
-    <braunr> which has the same bad effects as in most other allocators, mainly
-      fragmentation
-    <mcsim> There is a special list for freeing object allocated for another
-      CPU
-    <mcsim> And garbage collector frees such object on his own
-    <braunr> so what's your question ?
-    <mcsim> It is described in the end of article.
-    <mcsim> What cpu-cache policy do you think is better to implement?
-    <braunr> at this point, any
-    <braunr> and even if we had a kernel that perfectly supports
-      multiprocessor, I wouldn't care much now
-    <braunr> it's very hard to evaluate such allocators
-    <braunr> slqb looks nice, but if you have the same amount of fragmentation
-      per slab as other allocators do (which is likely), you have tat amount of
-      fragmentation multiplied by the number of processors
-    <braunr> whereas having shared queues limit the problem somehow
-    <braunr> having shared queues mean you have a bit more contention
-    <braunr> so, as is the case most of the time, it's a tradeoff
-    <braunr> by the way, does pigging say why he "doesn't like" slub ? :)
-    <braunr> piggin*
-    <mcsim> http://lwn.net/Articles/311093/
-    <mcsim> here he describes what slqb is better.
-    <braunr> well it doesn't describe why slub is worse
-    <mcsim> but not very particularly 
-    <braunr> except for order-0 allocations
-    <braunr> and that's a form of fragmentation like i mentioned above
-    <braunr> in mach those problems have very different impacts
-    <braunr> the backend memory isn't physical, it's the kernel virtual space
-    <braunr> so the kernel allocator can request chunks of higher than order-0
-      pages
-    <braunr> physical pages are allocated one at a time, then mapped in the
-      kernel space
-    <mcsim> Doesn't order of page depend on buffer size?
-    <braunr> it does
-    <mcsim> And why does gnumach allocates higher than order-0 pages more?
-    <braunr> why more ?
-    <braunr> i didn't say more
-    <mcsim> And why in mach those problems have very different impact?
-    <braunr> ?
-    <braunr> i've just explained why :)
-    <braunr> 09:37 < braunr> physical pages are allocated one at a time, then
-      mapped in the kernel space
-    <braunr> "one at a time" means order-0 pages, even if you allocate higher
-      than order-0 chunks
-    <mcsim> And in Linux they allocated more than one at time because of
-      prefetching page reading?
-    <braunr> do you understand what virtual memory is ?
-    <braunr> linux allocators allocate "physical memory"
-    <braunr> mach kernel allocator allocates "virtual memory"
-    <braunr> so even if you allocate a big chunk of virtual memory, it's backed
-      by order-0 physical pages
-    <mcsim> yes, I understand this
-    <braunr> you don't seem to :/
-    <braunr> the problem of higher than order-0 page allocations is
-      fragmentation
-    <braunr> do you see why ?
-    <mcsim> yes
-    <braunr> so
-    <braunr> fragmentation in the kernel space is less likely to create issues
-      than it does in physical memory
-    <braunr> keep in mind physical memory is almost always full because of the
-      page cache
-    <braunr> and constantly under some pressure
-    <braunr> whereas the kernel space is mostly empty
-    <braunr> so allocating higher then order-0 pages in linux is more dangerous
-      than it is in Mach or BSD
-    <mcsim> ok
-    <braunr> on the other hand, linux focuses pure performance, and not having
-      to map memory means less operations, less tlb misses, quicker allocations
-    <braunr> the Mach VM must map pages "one at a time", which can be expensive
-    <braunr> it should be adapted to handle multiple page sizes (e.g. 2 MiB) so
-      that many allocations can be made with few mappings
-    <braunr> but that's not easy
-    <braunr> as always: tradeoffs
-    <mcsim> There are other benefits of physical allocating. In big DMA
-      transfers can be needed few continuous physical pages. How does mach
-      handles such cases?
-    <braunr> gnumach does that awfully
-    <braunr> it just reserves the whole DMA-able memory and uses special
-      allocation functions on it, IIRC
-    <braunr> but kernels which have a MAch VM like memory sytem such as BSDs
-      have cleaner methods
-    <braunr> NetBSD provides a function to allocate contiguous physical memory
-    <braunr> with many constraints
-    <braunr> FreeBSD uses a binary buddy system like Linux
-    <braunr> the fact that the kernel allocator uses virtual memory doesn't
-      mean the kernel has no mean to allocate contiguous physical memory ...
-
-
-# IRC, freenode, #hurd, 2011-05-02
-
-    <braunr> hm nice, my allocator uses less memory than glibc (squeeze
-      version) on both 32 and 64 bits systems
-    <braunr> the new per-cpu layer is proving effective
-    <neal> braunr: Are you reimplementation malloc?
-    <braunr> no
-    <braunr> it's still the slab allocator for mach, but tested in userspace
-    <braunr> so i wrote malloc wrappers
-    <neal> Oh.
-    <braunr> i try to heavily test most of my code in userspace now
-    <neal> it's easier :-)
-    <neal> I agree
-    <braunr> even the physical memory allocator has been implemented this way
-    <neal> is this your mach version?
-    <braunr> virtual memory allocation will follow
-    <neal> or are you working on gnu mach?
-    <braunr> for now it's my version
-    <braunr> but i intend to spend the summer working on ipc port names
-      management
-
-[[rework_gnumach_IPC_spaces]].
-
-    <braunr> and integrate the result in gnu mach
-    <neal> are you keeping the same user-space API?
-    <neal> Or are you experimenting with something new?
-    <antrik> braunr: to be fair, it's not terribly hard to use less memory than
-      glibc :-)
-    <braunr> yes
-    <braunr> antrik: well ptmalloc3 received some nice improvements
-    <braunr> neal: the goal is to rework some of the internals only
-    <braunr> neal: namely, i simply intend to replace the splay tree with a
-      radix tree
-    <antrik> braunr: the glibc allocator is emphasising performace, unlike some
-      other allocators that trade some performance for much better memory
-      utilisation...
-    <antrik> ptmalloc3?
-    <braunr> that's the allocator used in glibc
-    <braunr> http://www.malloc.de/en/
-    <antrik> OK. haven't seen any recent numbers... the comparision I have in
-      mind is many years old...
-    <braunr> i also made some additions to my avl and red-black trees this week
-      end, which finally make them suitable for almost all generic uses
-    <braunr> the red-black tree could be used in e.g. gnu mach to augment the
-      linked list used in vm maps
-    <braunr> which is what's done in most modern systems
-    <braunr> it could also be used to drop the overloaded (and probably over
-      imbalanced) page cache hash table
-
-[[gnumach_vm_map_red-black_trees]].
-
-
-# IRC, freenode, #hurd, 2011-05-03
-
-    <mcsim> antrik: How should I start porting? Have I just include rbraun's
-      allocator to gnumach and make it compile?
-    <antrik> mcsim: well, basically yes I guess... but you will have to look at
-      the code in question first before we know anything more specific :-)
-    <antrik> I guess braunr might know better how to start, but he doesn't
-      appear to be here :-(
-    <braunr> mcsim: you can't juste put my code into gnu mach and make it run,
-      it really requires a few careful changes
-    <braunr> mcsim: you will have to analyse how the current zone allocator
-      interacts with regard to locking
-    <braunr> if it is used in interrupt handlers
-    <braunr> what kind of locks it should use instead of the pthread stuff
-      available in userspace
-    <braunr> you will have to change the reclamiing policy, so that caches are
-      reaped on demand
-    <braunr> (this basically boils down to calling the new reclaiming function
-      instead of zone_gc())
-    <braunr> you must be careful about types too
-    <braunr> there is work to be done ;)
-    <braunr> (not to mention the obvious about replacing all the calls to the
-      zone allocator, and testing/debugging afterwards)
-
-
-# IRC, freenode, #hurd, 2011-07-14
-
-    <braunr> can you make your patch available ?
-    <mcsim> it is available in gnumach repository at savannah 
-    <mcsim> tree mplaneta/libbraunr/master
-    <braunr> mcsim: i'll test your branch
-    <mcsim> ok. I'll give you a link in a minute
-    <braunr> hm why balloc ?
-    <mcsim> Braun's allocator
-    <braunr> err
-    <braunr>
-      http://git.sceen.net/rbraun/x15mach.git/?a=blob;f=kern/kmem.c;h=37173fa0b48fc9d7e177bf93de531819210159ab;hb=HEAD
-    <braunr> mcsim: this is the interface i had in mind for a kernel version :)
-    <braunr> very similar to the original slab allocator interface actually
-    <braunr> well, you've been working
-    <mcsim> But I have a problem with this patch. When I apply it to gnumach
-      code from debian repository. I have to make a change in file ramdisk.c
-      with sed -i 's/kernel_map/\&kernel_map/' device/ramdisk.c
-    <mcsim> because in git repository there is no such file
-    <braunr> mcsim: how do you configure the kernel before building ?
-    <braunr> mcsim: you should keep in touch more often i think, so that you
-      get feedback from us and don't spend too much time "off course"
-    <mcsim> I didn't configure it. I just run dpkg-buildsource -b.
-    <braunr> oh you build the debian package
-    <braunr> well my version was by configure --enable-kdb --enable-rtl8139
-    <braunr> and it seems stuck in an infinite loop during bootstrap
-    <mcsim> and printf doesn't work. The first function called by c_boot_entry
-      is printf(version).
-    <braunr> mcsim: also, you're invited to get the x15mach version of my
-      files, which are gplv2+ licensed
-    <braunr> be careful of my macros.h file, it can conflict with the
-      macros_help.h file from gnumach iirc
-    <mcsim> There were conflicts with MACRO_BEGIN and MACRO_END. But I solved
-      it
-    <braunr> ok
-    <braunr> it's tricky
-    <braunr> mcsim: try to find where the first use of the allocator is made
-
-
-# IRC, freenode, #hurd, 2011-07-22
-
-    <mcsim> braunr, hello. Kernel with your allocator already compiles and
-      runs. There still some problems, but, certainly, I'm on the final stage
-      already. I hope I'll finish in a few days.
-    <tschwinge> mcsim: Oh, cool!  Have you done some measurements already?
-    <mcsim> Not yet
-    <tschwinge> OK.
-    <tschwinge> But if it able to run a GNU/Hurd system, then that already is
-      something, a big milestone!
-    <braunr> nice
-    <braunr> although you'll probably need to tweak the garbage collecting
-      process
-    <mcsim> tschwinge: thanks
-    <mcsim> braunr: As back-end for allocating memory I use
-      kmem_alloc_wired. But in zalloc was an opportunity to use as back-end
-      kmem_alloc_pageable. Although there was no any zone that used
-      kmem_alloc_pageable. Do I need to implement this functionality?
-    <braunr> mcsim: do *not* use kmem_alloc_pageable()
-    <mcsim> braunr: Ok. This is even better)
-    <braunr> mcsim: in x15, i've taken this even further: there is *no* kernel
-      vm object, which means all kernel memory is wired and unmanaged
-    <braunr> making it fast and safe
-    <braunr> pageable kernel memory was useful back when RAM was really scarce
-    <braunr> 20 years ago
-    <braunr> but it's a source of deadlock
-    <mcsim> Indeed. I'll won't use kmem_alloc_pageable.
-
-
-# IRC, freenode, #hurd, 2011-08-09
-
-    < braunr> mcsim: what's the "bug related to MEM_CF_VERIFY" you refer to in
-      one of your commits ?
-    < braunr> mcsim: don't use spin_lock_t as a member of another structure
-    < mcsim> braunr: I confused with types in *_verify functions, so they
-      didn't work. Than I fixed it in the commit you mentioned.
-    < braunr> in gnumach, most types are actually structure pointers
-    < braunr> use simple_lock_data_t
-    < braunr> mcsim: ok
-    < mcsim> > use simple_lock_data_t
-    < mcsim> braunr: ok
-    < braunr> mcsim: don't make too many changes to the code base, and if
-      you're unsure, don't hesitate to ask
-    < braunr> also, i really insist you rename the allocator, as done in x15
-      for example
-      (http://git.sceen.net/rbraun/x15mach.git/?a=blob;f=vm/kmem.c), instead of
-      a name based on mine :/
-    < mcsim> braunr: Ok. It was just work name. When I finish I'll rename the
-      allocator.
-    < braunr> other than that, it's nice to see progress
-    < braunr> although again, it would be better with some reports along
-    < braunr> i won't be present at the meeting tomorrow unfortunately, but you
-      should use those to report the status of your work
-    < mcsim> braunr: You've said that I have to tweak gc process. Did you mean
-      to call mem_gc() when physical memory ends instead of calling it every x
-      seconds? Or something else?
-    < braunr> there are multiple topics, alhtough only one that really matters
-    < braunr> study how zone_gc was called
-    < braunr> reclaiming memory should happen when there is pressure on the VM
-      subsystem
-    < braunr> but it shouldn't happen too ofte, otherwise there is trashing
-    < braunr> and your caches become mostly useless
-    < braunr> the original slab allocator uses a 15-second period after a
-      reclaim during which reclaiming has no effect
-    < braunr> this allows having a somehow stable working set for this duration
-    < braunr> the linux slab allocator uses 5 seconds, but has a more
-      complicated reclaiming mechanism
-    < braunr> it releases memory gradually, and from reclaimable caches only
-      (dentry for example)
-    < braunr> for x15 i intend to implement the original 15 second interval and
-      then perform full reclaims
-    < mcsim> In zalloc mem_gc is called by vm_pageout_scan, but not often than
-      once a second.
-    < mcsim> In balloc I've changed interval to once in 15 seconds.
-    < braunr> don't use the code as it is
-    < braunr> the version you've based your work on was meant for userspace
-    < braunr> where there isn't memory pressure
-    < braunr> so a timer is used to trigger reclaims at regular intervals
-    < braunr> it's different in a kernel
-    < braunr> mcsim: where did you see vm_pageout_scan call the zone gc once a
-      second ?
-    < mcsim> vm_pageout_scan calls consider_zone_gc and consider_zone_gc checks
-      if second is passed.
-    < braunr> where ?
-    < mcsim> Than zone_gc can be called.
-    < braunr> ah ok, it's in zaclloc.c then
-    < braunr> zalloc.c
-    < braunr> yes this function is fine
-    < mcsim> so old gc didn't consider vm pressure. Or I missed something.
-    < braunr> it did
-    < mcsim> how?
-    < braunr> well, it's called by the pageout daemon
-    < braunr> under memory pressure
-    < braunr> so it's fine
-    < mcsim> so if mem_gc is called by pageout daemon is it fine?
-    < braunr> it must be changed to do something similar to what
-      consider_zone_gc does
-    < mcsim> It does. mem_gc does the same work as consider_zone_gc and
-      zone_gc.
-    < braunr> good
-    < mcsim> so gc process is fine?
-    < braunr> should be
-    < braunr> i see mem.c only includes mem.h, which then includes other
-      headers
-    < braunr> don't do that
-    < braunr> always include all the headers you need where you need them
-    < braunr> if you need avltree.h in both mem.c and mem.h, include it in both
-      files
-    < braunr> and by the way, i recommend you use the red black tree instead of
-      the avl type
-    < braunr> (it's the same interface so it shouldn't take long)
-    < mcsim> As to report. If you won't be present at the meeting, I can tell
-      you what I have to do now.
-    < braunr> sure
-    < braunr> in addition, use GPLv2 as the license, teh BSD one is meant for
-      the userspace version only
-    < braunr> GPLv2+ actually
-    < braunr> hm you don't need list.c
-    < braunr> it would only add dead code
-    < braunr> "Zone for dynamical allocator", don't mix terms
-    < braunr> this comment refers to a vm_map, so call it a map
-    < mcsim> 1. Change constructor for kentry_alloc_cache.
-    < mcsim> 2. Make measurements.
-    < mcsim> +
-    < mcsim> 3. Use simple_lock_data_t
-    < mcsim> 4. Replace license
-    < braunr> kentry_alloc_cache <= what is that ?
-    < braunr> cache for kernel map entries in vm_map ?
-    < braunr> the comment for mem_cpu_pool_get doesn't apply in gnumach, as
-      there is no kernel preemption
-
-[[microkernel/mach/gnumach/preemption]].
-
-    < braunr> "Don't attempt mem GC more frequently than hz/MEM_GC_INTERVAL
-      times a second.
-    < braunr> "
-    < mcsim> sorry. I meant vm_map_kentry_cache
-    < braunr> hm nothing actually about this comment
-    < braunr> mcsim: ok
-    < braunr> yes kernel map entries need special handling
-    < braunr> i don't know how it's done in gnumach though
-    < braunr> static preallocation ?
-    < mcsim> yes
-    < braunr> that's ugly :p
-    < mcsim> but it uses dynamic allocation further even for vm_map kernel
-      entries
-    < braunr> although such bootstrapping issues are generally difficult to
-      solve elegantly
-    < braunr> ah
-    < mcsim> now I use only static allocation, but I'll add dynamic allocation
-      too
-    < braunr> when you have time, mind the coding style (convert everything to
-      gnumach style, which mostly implies using tabs instead of 4-spaces
-      indentation)
-    < braunr> when you'll work on dynamic allocation for the kernel map
-      entries, you may want to review how it's done in x15
-    < braunr> the mem_source type was originally intended for that purpose, but
-      has slightly changed once the allocator was adapted to work in my kernel
-    < mcsim> ok
-    < braunr> vm_map_kentry_zone is the only zone created with ZONE_FIXED
-    < braunr> and it is zcram()'ed immediately after
-    < braunr> so you can consider it a statically allocated zone
-    < braunr> in x15 i use another strategy: there is a special kernel submap
-      named kentry_map which contains only one map entry (statically allocated)
-    < braunr> this map is the backend (mem_source) for the kentry_cache
-    < braunr> the kentry_cache is created with a special flag that tells it
-      memory can't be reclaimed
-    < braunr> when the cache needs to grow, the single map entry is extended to
-      cover the allocated memory
-    < braunr> it's similar to the way pmap_growkernel() works for kernel page
-      table pages
-    < braunr> (and is actually based on that idea)
-    < braunr> it's a compromise between full static and dynamic allocation
-      types
-    < braunr> the advantage is that the allocator code can be used (so there is
-      no need for a special allocator like in netbsd)
-    < braunr> the drawback is that some resources can never be returned to
-      their source (and under peaks, the amount of unfreeable resources could
-      become large, but this is unexpected)
-    < braunr> mcsim: for now you shouldn't waste your time with this
-    < braunr> i see the number of kernel map entries is fixed at 256
-    < braunr> and i've never seen the kernel use more than around 30 entries
-    < mcsim> Do you think that I have to left this problem to the end?
-    < braunr> yes
-
-
-# IRC, freenode, #hurd, 2011-08-11
-
-    < mcsim> braunr: Hello. Can you give me an advice how can I make
-      measurements better?
-    < braunr> mcsim: what kind of measurements
-    < mcsim> braunr: How much is your allocator better than zalloc.
-    < braunr> slightly :p
-    < braunr> that's why i never took the time to put it in gnumach
-    < mcsim> braunr: Just I thought that there are some rules or
-      recommendations of such measurements. Or I can do them any way I want?
-    < braunr> mcsim: i don't know
-    < braunr> mcsim: benchmarking is an art of its own, and i don't even know
-      how to use the bits of profiling code available in gnumach (if it still
-      works)
-    < antrik> mcsim: hm... are you saying you already have a running system
-      with slab allocator?... :-)
-    < braunr> mcsim: the main advantage i can see is the removal of many
-      arbitrary hard limits
-    < mcsim> antrik: yes
-    < antrik> \o/
-    < antrik> nice work!
-    < braunr> :)
-    < braunr> the cpu layer should also help a bit, but it's hard to measure
-    < braunr> i guess it could be seen on the ipc path for very small buffers
-    < mcsim> antrik: Thanks. But I still have to 1. Change constructor for
-      kentry_alloc_cache. and 2. Make measurements.
-    < braunr> and polish the whole thing :p
-    < antrik> mcsim: I'm not sure this can be measured... the performance
-      differente in any real live usage is probably just a few percent at most
-      -- it's hard to construct a benchmark giving enough precision so it's not
-      drowned in noise...
-    < antrik> perhaps it conserves some memory -- but that too would be hard to
-      measure I fear
-    < braunr> yes
-    < braunr> there *should* be better allocation times, less fragmentation,
-      better accounting ... :)
-    < braunr> and no arbitrary limits !
-    < antrik> :-)
-    < braunr> oh, and the self debugging features can be nice too
-    < mcsim> But I need to prove that my work wasn't useless
-    < braunr> well it wasn't, but that's hard to measure
-    < braunr> it's easy to prove though, since there are additional features
-      that weren't present in the zone allocator
-    < mcsim> Ok. If there are some profiling features in gnumach can you give
-      me a link with their description?
-    < braunr> mcsim: sorry, no
-    < braunr> mcsim: you could still write the basic loop test, which counts
-      the number of allocations performed in a fixed time interval
-    < braunr> but as it doesn't match many real life patterns, it won't be very
-      useful
-    < braunr> and i'm afraid that if you consider real life patterns, you'll
-      see how negligeable the improvement can be compared to other operations
-      such as memory copies or I/O (ouch)
-    < mcsim> Do network drivers use this allocator?
-    < mcsim> ok. I'll scrape up some test and than I'll report results.
-
-
-# IRC, freenode, #hurd, 2011-08-26
-
-    < mcsim> hello. Are there any analogs of copy_to_user and copy_from_user in
-      linux for gnumach?
-    < mcsim> Or how can I determine memory map if I know address? I need this
-      for vm_map_copyin
-    < guillem> mcsim: vm_map_lookup_entry?
-    < mcsim> guillem: but I need to transmit map to this function and it will
-      return an entry which contains specified address.
-    < mcsim> And I don't know what map have I transmit.
-    < mcsim> I need to transfer static array from kernel to user. What map
-      contains static data?
-    < antrik> mcsim: Mach doesn't have copy_{from,to}_user -- instead, large
-      chunks of data are transferred as out-of-line data in IPC messages
-      (i.e. using VM magic)
-    < mcsim> antrik: can you give me an example? I just found using
-      vm_map_copyin in host_zone_info.
-    < antrik> no idea what vm_map_copyin is to be honest...
-
-
-# IRC, freenode, #hurd, 2011-08-27
-
-    < braunr> mcsim: the primitives are named copyin/copyout, and they are used
-      for messages with inline data
-    < braunr> or copyinmsg/copyoutmsg
-    < braunr> vm_map_copyin/out should be used for chunks larger than a page
-      (or roughly a page)
-    < braunr> also, when writing to a task space, see which is better suited:
-      vm_map_copyout or vm_map_copy_overwrite
-    < mcsim> braunr: and what will be src_map for vm_map_copyin/out?
-    < braunr> the caller map
-    < braunr> which you can get with current_map() iirc
-    < mcsim> braunr: thank you
-    < braunr> be careful not to leak anything in the transferred buffers
-    < braunr> memset() to 0 if in doubt
-    < mcsim> braunr:ok
-    < braunr> antrik: vm_map_copyin() is roughly vm_read()
-    < antrik> braunr: what is it used for?
-    < braunr> antrik: 01:11 < antrik> mcsim: Mach doesn't have
-      copy_{from,to}_user -- instead, large chunks of data are transferred as
-      out-of-line data in IPC messages (i.e. using VM magic)
-    < braunr> antrik: that "VM magic" is partly implemented using vm_map_copy*
-      functions
-    < antrik> braunr: oh, you mean it doesn't actually copy data, but only page
-      table entries? if so, that's *not* really comparable to
-      copy_{from,to}_user()...
-
-
-# IRC, freenode, #hurd, 2011-08-28
-
-    < braunr> antrik: the equivalent of copy_{from,to}_user are
-      copy{in,out}{,msg}
-    < braunr> antrik: but when the data size is about a page or more, it's
-      better not to copy, of course
-    < antrik> braunr: it's actually not clear at all that it's really better to
-      do VM magic than to copy...
-
-
-# IRC, freenode, #hurd, 2011-08-29
-
-    < braunr> antrik: at least, that used to be the general idea, and with a
-      simpler VM i suspect it's still true
-    < braunr> mcsim: did you progress on your host_zone_info replacement ?
-    < braunr> mcsim: i think you should stick to what the original
-      implementation did
-    < braunr> which is making an inline copy if caller provided enough space,
-      using kmem_alloc_pageable otherwise
-    < braunr> specify ipc_kernel_map if using kmem_alloc_pageable
-    < mcsim> braunr: yes. And it works. But I use kmem_alloc, not pageable. Is
-      it worse?
-    < mcsim> braunr: host_zone_info replacement is pushed to savannah
-      repository. 
-    < braunr> mcsim: i'll have a look
-    < mcsim> braunr: I've pushed one more commit just now, which has attitude
-      to host_zone_info.
-    < braunr> mem_alloc_early_init should be renamed mem_bootstrap
-    < mcsim> ok
-    < braunr> mcsim: i don't understand your call to kmem_free
-    < mcsim> braunr: It shouldn't be there?
-    < braunr> why should it be there ?
-    < braunr> you're freeing what the copy object references
-    < braunr> it's strange that it even works
-    < braunr> also, you shouldn't pass infop directly as the copy object
-    < braunr> i guess you get a warning for that
-    < braunr> do what the original code does: use an intermediate copy object
-      and a cast
-    < mcsim> ok
-    < braunr> another error (without consequence but still, you should mind it)
-    < braunr> simple_lock(&mem_cache_list_lock);
-    < braunr> [...]
-    < braunr> kr = kmem_alloc(ipc_kernel_map, &info, info_size);
-    < braunr> you can't hold simple locks while allocating memory
-    < braunr> read how the original implementation works around this
-    < mcsim> ok
-    < braunr> i guess host_zone_info assumes the zone list doesn't change much
-      while unlocked
-    < braunr> or that's it's rather unimportant since it's for debugging
-    < braunr> a strict snapshot isn't required
-    < braunr> list_for_each_entry(&mem_cache_list, cache, node) max_caches++;
-    < braunr> you should really use two separate lines for readability
-    < braunr> also, instead of counting each time, you could just maintain a
-      global counter
-    < braunr> mcsim: use strncpy instead of strcpy for the cache names
-    < braunr> not to avoid overflow but rather to clear the unused bytes at the
-      end of the buffer
-    < braunr> mcsim: about kmem_alloc vs kmem_alloc_pageable, it's a minor
-      issue
-    < braunr> you're handing off debugging data to a userspace application
-    < braunr> a rather dull reporting tool in most cases, which doesn't require
-      wired down memory
-    < braunr> so in order to better use available memory, pageable memory
-      should be used
-    < braunr> in the future i guess it could become a not-so-minor issue though
-    < mcsim> ok. I'll fix it
-    < braunr> mcsim: have you tried to run the kernel with MC_VERIFY always on
-      ?
-    < braunr> MEM_CF_VERIFY actually
-    < mcsim1> yes.
-    < braunr> oh
-    < braunr> nothing wrong 
-    < braunr> ?
-    < mcsim1> it is always set
-    < braunr> ok
-    < braunr> ah, you set it in macros.h ..
-    < braunr> don't
-    < braunr> put it in mem.c if you want, or better, make it a compile-time
-      option
-    < braunr> macros.h is a tiny macro library, it shouldn't define such
-      unrelated options
-    < mcsim1> ok.
-    < braunr> mcsim1: did you try fault injection to make sure the checking
-      code actually works and how it behaves when an error occurs ?
-    < mcsim1> I think that when I finish I'll merge files cpu.h and macros.h
-      with mem.c
-    < braunr> yes that would simplify things
-    < mcsim1> Yes. When I confused with types mem_buf_fill worked wrong and
-      panic occurred.
-    < braunr> very good
-    < braunr> have you progressed concerning the measurements you wanted to do
-      ?
-    < mcsim1> not much.
-    < braunr> ok
-    < mcsim1> I think they will be ready in a few days.
-    < antrik> what measurements are these?
-    < mcsim1> braunr: What maximal size for static data and stack in kernel?
-    < braunr> what do you mean ?
-    < braunr> kernel stacks are one page if i'm right
-    < braunr> static data (rodata+data+bss) are limited by grub bugs only :)
-    < mcsim1> braunr: probably they are present, because when I created too big
-      array I couldn't boot kernel
-    < braunr> local variable or static ?
-    < mcsim1> static
-    < braunr> how large ?
-    < mcsim1> 4Mb
-    < braunr> hm
-    < braunr> it's not a grub bug then
-    < braunr> i was able to embed as much as 32 MiB in x15 while doing this
-      kind of tests
-    < braunr> I guess it's the gnu mach boot code which only preallocates one
-      page for the initial kernel mapping
-    < braunr> one PTP (page table page) maps 4 MiB
-    < braunr> (x15 does this completely dynamically, unlike mach or even
-      current BSDs)
-    < mcsim1> antrik: First I want to measure time of each cache
-      creation/allocation/deallocation and then compile kernel.
-    < braunr> cache creation is irrelevant
-    < braunr> because of the cpu pools in the new allocator, you should test at
-      least two different allocation patterns
-    < braunr> one with quick allocs/frees
-    < braunr> the other with large numbers of allocs then their matching frees
-    < braunr> (larger being at least 100)
-    < braunr> i'd say the cpu pool layer is the real advantage over the
-      previous zone allocator
-    < braunr> (from a performance perspective)
-    < mcsim1> But there is only one cpu
-    < braunr> it doesn't matter
-    < braunr> it's stil a very effective cache
-    < braunr> in addition to reducing contention
-    < braunr> compare mem_cpu_pool_pop() against mem_cache_alloc_from_slab()
-    < braunr> mcsim1: work is needed to polish the whole thing, but getting it
-      actually working is a nice achievement for someone new on the project
-    < braunr> i hope it helped you learn about memory allocation, virtual
-      memory, gnu mach and the hurd in general :)
-    < antrik> indeed :-)
-
-
-# IRC, freenode, #hurd, 2011-09-06
-
-    [some performance testing]
-    <braunr> i'm not sure such long tests are relevant but let's assume balloc
-      is slower
-    <braunr> some tuning is needed here
-    <braunr> first, we can see that slab allocation occurs more often in balloc
-      than page allocation does in zalloc
-    <braunr> so yes, as slab allocation is slower (have you measured which part
-      actually is slow ? i guess it's the kmem_alloc call)
-    <braunr> the whole process gets a bit slower too
-    <mcsim> I used alloc_size = 4096 for zalloc
-    <braunr> i don't know what that is exactly
-    <braunr> but you can't hold 500 16 bytes buffers in a page so zalloc must
-      have had free pages around for that
-    <mcsim> I use kmem_alloc_wired
-    <braunr> if you have time, measure it, so that we know how much it accounts
-      for
-    <braunr> where are the results for dealloc ?
-    <mcsim> I can't give you result right now because internet works very
-      bad. But for first DEALLOC result are the same, exept some cases when it
-      takes balloc for more than 1000 ticks
-    <braunr> must be the transfer from the cpu layer to the slab layer
-    <mcsim> as to kmem_alloc_wired. I think zalloc uses this function too for
-      allocating objects in zone I test.
-    <braunr> mcsim: yes, but less frequently, which is why it's faster
-    <braunr> mcsim: another very important aspect that should be measured is
-      memory consumption, have you looked into that ?
-    <mcsim> I think that I made too little iterations in test SMALL
-    <mcsim> If I increase constant SMALL_TESTS will it be good enough?
-    <braunr> mcsim: i don't know, try both :)
-    <braunr> if you increase the number of iterations, balloc average time will
-      be lower than zalloc, but this doesn't remove the first long
-      initialization step on the allocated slab
-    <mcsim> SMALL_TESTS to 500, I mean
-    <braunr> i wonder if maintaining the slabs sorted through insertion sort is
-      what makes it slow
-    <mcsim> braunr: where do you sort slabs? I don't see this.
-    <braunr> mcsim: mem_cache_alloc_from_slab and its free counterpart
-    <braunr> mcsim: the mem_source stuff is useless in gnumach, you can remove
-      it and directly call the kmem_alloc/free functions
-    <mcsim> But I have to make special allocator for kernel map entries.
-    <braunr> ah right
-    <mcsim> btw. It turned out that 256 entries are not enough.
-    <braunr> that's weird
-    <braunr> i'll make a patch so that the mem_source code looks more like what
-      i have in x15 then
-    <braunr> about the results, i don't think the slab layer is that slow
-    <braunr> it's the cpu_pool_fill/drain functions that take time
-    <braunr> they preallocate many objects (64 for your objects size if i'm
-      right) at once
-    <braunr> mcsim: look at the first result page: some times, a number around
-      8000 is printed
-    <braunr> the common time (ticks, whatever) for a single object is 120
-    <braunr> 8132/120 is 67, close enough to the 64 value
-    <mcsim> I forgot about SMALL tests here are they:
-      http://paste.debian.net/128533/ (balloc) http://paste.debian.net/128534/
-      (zalloc)
-    <mcsim> braunr: why do you divide 8132 by 120?
-    <braunr> mcsim: to see if it matches my assumption that the ~8000 number
-      matches the cpu_pool_fill call
-    <mcsim> braunr: I've got it
-    <braunr> mcsim: i'd be much interested in the dealloc results if you can
-      paste them too
-    <mcsim> dealloc: http://paste.debian.net/128589/
-      http://paste.debian.net/128590/
-    <braunr> mcsim: thanks
-    <mcsim> second dealloc: http://paste.debian.net/128591/
-      http://paste.debian.net/128592/
-    <braunr> mcsim: so the main conclusion i retain from your tests is that the
-      transfers from the cpu and the slab layers are what makes the new
-      allocator a bit slower
-    <mcsim> OPERATION_SMALL dealloc: http://paste.debian.net/128593/
-      http://paste.debian.net/128594/
-    <braunr> mcsim: what needs to be measured now is global memory usage
-    <mcsim> braunr: data from /proc/vmstat after kernel compilation will be
-      enough?
-    <braunr> mcsim: let me check
-    <braunr> mcsim: no it won't do, you need to measure kernel memory usage
-    <braunr> the best moment to measure it is right after zone_gc is called
-    <mcsim> Are there any facilities in gnumach for memory measurement?
-    <braunr> it's specific to the allocators
-    <braunr> just count the number of used pages
-    <braunr> after garbage collection, there should be no free page, so this
-      should be rather simple
-    <mcsim> ok
-    <mcsim> braunr: When I measure memory usage in balloc, what formula is
-      better cache->nr_slabs * cache->bufs_per_slab * cache->buf_size or
-      cache->nr_slabs * cache->slab_size?
-    <braunr> the latter
-
-
-# IRC, freenode, #hurd, 2011-09-07
-
-    <mcsim> braunr: I've disabled calling of mem_cpu_pool_fill and allocator
-      became faster
-    <braunr> mcsim: sounds nice
-    <braunr> mcsim: i suspect the free path might not be as fast though
-    <mcsim> results for first calling: http://paste.debian.net/128639/ second:
-      http://paste.debian.net/128640/ and with many alloc/free:
-      http://paste.debian.net/128641/
-    <braunr> mcsim: thanks
-    <mcsim> best result are for second call: average time decreased from 159.56
-      to 118.756
-    <mcsim> First call slightly worse, but this is because I've added some
-      profiling code
-    <braunr> i still see some ~8k lines in 128639
-    <braunr> even some around ~12k
-    <mcsim> I think this is because of mem_cache_grow I'm investigating it now
-    <braunr> i guess so too
-    <mcsim> I've measured time for first call in cache and from about 22000
-      mem_cache_grow takes 20000
-    <braunr> how did you change the code so that it doesn't call
-      mem_cpu_pool_fill ?
-    <braunr> is the cpu layer still used ?
-    <mcsim> http://paste.debian.net/128644/
-    <braunr> don't forget the free path
-    <braunr> mcsim: anyway, even with the previous slightly slower behaviour we
-      could observe, the performance hit is negligible
-    <mcsim> Is free path a compilation? (I'm sorry for my english)
-    <braunr> mcsim: mem_cache_free
-    <braunr> mcsim: the last two measurements i'd advise are with big (>4k)
-      object sizes and, really, kernel allocator consumption
-    <mcsim> http://paste.debian.net/128648/ http://paste.debian.net/128646/
-      http://paste.debian.net/128649/ (first, second, small)
-    <braunr> mcsim: these numbers are closer to the zalloc ones, aren't they ?
-    <mcsim> deallocating slighty faster too
-    <braunr> it may not be the case with larger objects, because of the use of
-      a tree
-    <mcsim> yes, they are closer
-    <braunr> but then, i expect some space gains
-    <braunr> the whole thing is about compromise
-    <mcsim> ok. I'll try to measure them today. Anyway I'll post result and you
-      could read them in the morning
-    <braunr> at least, it shows that the zone allocator was actually quite good
-    <braunr> i don't like how the code looks, there are various hacks here and
-      there, it lacks self inspection features, but it's quite good
-    <braunr> and there was little room for true improvement in this area, like
-      i told you :)
-    <braunr> (my allocator, like the current x15 dev branch, focuses on mp
-      machines)
-    <braunr> mcsim: thanks again for these numbers
-    <braunr> i wouldn't have had the courage to make the tests myself before
-      some time eh
-    <mcsim> braunr: hello. Look at the small_4096 results
-      http://paste.debian.net/128692/ (balloc) http://paste.debian.net/128693/
-      (zalloc)
-    <braunr> mcsim: wow, what's that ? :)
-    <braunr> mcsim: you should really really include your test parameters in
-      the report
-    <braunr> like object size, purpose, and other similar details
-    <mcsim> for balloc I specified only object_size = 4096
-    <mcsim> for zalloc object_size = 4096, alloc_size = 4096, memtype = 0;
-    <braunr> the results are weird
-    <braunr> apart from the very strange numbers (e.g. 0 or 4429543648), none
-      is around 3k, which is the value matching a kmem_alloc call
-    <braunr> happy to see balloc behaves quite good for this size too
-    <braunr> s/good/well/
-    <mcsim> Oh
-    <mcsim> here is significant only first 101 lines
-    <mcsim> I'm sorry
-    <braunr> ok
-    <braunr> what does the test do again ? 10 loops of 10 allocs/frees ?
-    <mcsim> yes
-    <braunr> ok, so the only slowdown is at the beginning, when the slabs are
-      created
-    <braunr> the two big numbers (31844 and 19548) are strange
-    <mcsim> on the other hand time of compilation is 
-    <mcsim> balloc               zalloc
-    <mcsim> 38m28.290s  38m58.400s 
-    <mcsim> 38m38.240s  38m42.140s 
-    <mcsim> 38m30.410s  38m52.920s 
-    <braunr> what are you compiling ?
-    <mcsim> gnumach kernel
-    <braunr> in 40 mins ?
-    <mcsim> yes
-    <braunr> you lack hvm i guess
-    <mcsim> is it long?
-    <mcsim> I use real PC
-    <braunr> very
-    <braunr> ok
-    <braunr> so it's normal
-    <mcsim> in vm it was about 2 hours)
-    <braunr> the difference really is negligible
-    <braunr> ok i can explain the big numbers
-    <braunr> the slab size depends on the object size, and for 4k, it is 32k
-    <braunr> you can store 8 4k buffers in a slab (lines 2 to 9)
-    <mcsim> so we need use kmem_alloc_* 8 times?
-    <braunr> on line 10, the ninth object is allocated, which adds another slab
-      to the cache, hence the big number
-    <braunr> no, once for a size of 32k
-    <braunr> and then the free list is initialized, which means accessing those
-      pages, which means tlb misses
-    <braunr> i guess the zone allocator already has free pages available
-    <mcsim> I see
-    <braunr> i think you can stop performance measurements, they show the
-      allocator is slightly slower, but so slightly we don't care about that
-    <braunr> we need numbers on memory usage now (at the page level)
-    <braunr> and this isn't easy
-    <mcsim> For balloc I can get numbers if I summarize nr_slabs*slab_size for
-      each cache, isn't it?
-    <braunr> yes
-    <braunr> you can have a look at the original implementation, function
-      mem_info
-    <mcsim> And for zalloc I have to summarize of cur_size and then add
-      zalloc_wasted_space?
-    <braunr> i don't know :/
-    <braunr> i think the best moment to obtain accurate values is after zone_gc
-      removes the collected pages
-    <braunr> for both allocators, you could fill a stats structure at that
-      moment, and have an rpc copy that structure when a client tool requests
-      it
-    <braunr> concerning your tests, there is another point to have in mind
-    <braunr> the very first loop in your code shows a result of 31844
-    <braunr> although you disabled the call to cpu_pool_fill
-    <braunr> but the reason why it's so long is that the cpu layer still exists
-    <braunr> and if you look carefully, the cpu pools are created as needed on
-      the free path
-    <mcsim> I removed cpu_pool_drain
-    <braunr> but not cpu_pool_push/pop i guess
-    <mcsim> http://paste.debian.net/128698/
-    <braunr> see, you still allocate the cpu pool array on the free path
-    <mcsim> but I don't fill it
-    <braunr> that's not the point
-    <braunr> it uses mem_cache_alloc
-    <braunr> so in a call to free, you can also have an allocation, that can
-      potentially create a new slab
-    <mcsim> I see, so I have to create cpu_pool at the initialization stage?
-    <braunr> no, you can't
-    <braunr> there is a reason why they're allocated on the free path
-    <braunr> but since you don't have the fill/drain functions, i wonder if you
-      should just comment out the whole cpu layer code
-    <braunr> but hmm
-    <braunr> no really, it's not worth the effort
-    <braunr> even with drains/fills, the results are really good enough
-    <braunr> it makes the allocator smp ready
-    <braunr> we should just keep it that way
-    <braunr> mcsim: fyi, the reason why cpu pool arrays are allocated on the
-      free path is to avoid recursion
-    <braunr> because cpu pool arrays are allocated from caches just as almost
-      everything else
-    <mcsim> ok
-    <mcsim> summ of cur_size and then adding zalloc_wasted_space gives 0x4e1954
-    <mcsim> but this value isn't even page aligned
-    <mcsim> For balloc I've got 0x4c6000 0x4aa000 0x48d000
-    <braunr> hm can you report them in decimal, >> 10 so that values are in KiB
-      ?
-    <mcsim> 4888 4776 4660 for balloc
-    <mcsim> 4998 for zalloc
-    <braunr> when ?
-    <braunr> after boot ?
-    <mcsim> boot, compile, zone_gc
-    <mcsim> and then measure
-    <braunr> ?
-    <mcsim> I call garbage collector before measuring
-    <mcsim> and I measure after kernel compilation
-    <braunr> i thought it took you 40 minutes
-    <mcsim> for balloc I got results at night
-    <braunr> oh so you already got them
-    <braunr> i can't beleive the kernel only consumes 5 MiB
-    <mcsim> before gc it takes about 9052 Kib
-    <braunr> can i see the measurement code ?
-    <braunr> oh, and how much ram does your machine have ?
-    <mcsim> 758 mb
-    <mcsim> 768
-    <braunr> that's really weird
-    <braunr> i'd expect the kernel to consume much more space
-    <mcsim> http://paste.debian.net/128703/
-    <mcsim> it's only dynamically allocated data
-    <braunr> yes
-    <braunr> ipc ports, rights, vm map entries, vm objects, and lots of other
-      hanging buffers
-    <braunr> about how much is zalloc_wasted_space ?
-    <braunr> if it's small or constant, i guess you could ignore it
-    <mcsim> about 492
-    <mcsim> KiB
-    <braunr> well it's another good point, mach internal structures don't imply
-      much overhead
-    <braunr> or, the zone allocator is underused
-
-    <tschwinge> mcsim, braunr: The memory allocator project is coming along
-      good, as I get from your IRC messages?
-    <braunr> tschwinge: yes, but as expected, improvements are minor
-    <tschwinge> But at the very least it's now well-known, maintainable code.
-    <braunr> yes, it's readable, easier to understand, provides self inspection
-      and is smp ready
-    <braunr> there also are less hacks, but a few less features (there are no
-      way to avoid sleeping so it's unusable - and unused - in interrupt
-      handlers)
-    <braunr> is* no way
-    <braunr> tschwinge: mcsim did a good job porting and measuring it
-
-
-# IRC, freenode, #hurd, 2011-09-08
-
-    <antrik> braunr: note that the zalloc map used to be limited to 8 MiB or
-      something like that a couple of years ago... so it doesn't seems
-      surprising that the kernel uses "only" 5 MiB :-)
-    <antrik> (yes, we had a *lot* of zalloc panics back then...)
-
-
-# IRC, freenode, #hurd, 2011-09-14
-
-    <mcsim> braunr: hello. I've written a constructor for kernel map entries
-      and it can return resources to their source. Can you have a look at it?
-      http://paste.debian.net/130037/ If all be OK I'll push it tomorrow.
-    <braunr> mcsim: send the patch through mail please, i'll apply it on my
-      copy
-    <braunr> are you sure the cache is reapable ?
-    <mcsim> All slabs, except first I allocate with kmem_alloc_wired.
-    <braunr> how can you be sure ?
-    <mcsim> First slab I allocate during bootstrap and use pmap_steal_memory
-      and further I use only kmem_alloc_wired
-    <braunr> no, you use kmem_free
-    <braunr> in kentry_dealloc_cache()
-    <braunr> which probably creates a recursion
-    <braunr> using the constructor this way isn't a good idea
-    <braunr> constructors are good for preconstructed state (set counters to 0,
-      init lists and locks, that kind of things, not allocating memory)
-    <braunr> i don't think you should try to make this special cache reapable
-    <braunr> mcsim: keep in mind constructors are applied on buffers at *slab*
-      creation, not at object allocation
-    <braunr> so if you allocate a single slab with, say, 50 or 100 objects per
-      slab, kmem_alloc_wired would be called that number of times
-    <mcsim> why kentry_dealloc_cache can create recursion? kentry_dealloc_cache
-      is called only by mem_cache_reap.
-    <braunr> right
-    <braunr> but are you totally sure mem_cache_reap() can't be called by
-      kmem_free() ?
-    <braunr> i think you're right, it probably can't
-
-
-# IRC, freenode, #hurd, 2011-09-25
-
-    <mcsim> braunr: hello. I rewrote constructor for kernel entries and seems
-      that it works fine. I think that this was last milestone. Only moving of
-      memory allocator sources to more appropriate place and merge with main
-      branch left.
-    <braunr> mcsim: it needs renaming and reindenting too
-    <mcsim> for reindenting C-x h Tab in emacs will be enough?
-    <braunr> mcsim: make sure which style must be used first
-    <mcsim> and what should I rename and where better to place allocator? For
-      example, there is no lib directory, like in x15. Should I create it and
-      move list.* and rbtree.* to lib/ or move these files to util/ or
-      something else?
-    <braunr> mcsim: i told you balloc isn't a good name before, use something
-      more meaningful (kmem is already used in gnumach unfortunately if i'm
-      right)
-    <braunr> you can put the support files in kern/
-    <mcsim> what about vm_alloc?
-    <braunr> you should prefix it with vm_
-    <braunr> shouldn't
-    <braunr> it's a top level allocator
-    <braunr> on top of the vm system
-    <braunr> maybe mcache
-    <braunr> hm no
-    <braunr> maybe just km_
-    <mcsim> kern/km_alloc.*?
-    <braunr> no
-    <braunr> just km
-    <mcsim> ok.
-
-
-# IRC, freenode, #hurd, 2011-09-27
-
-    <mcsim> braunr: hello. When I've tried to speed of new allocator and bad
-      I've removed function mem_cpu_pool_fill. But you've said to undo this. I
-      don't understand why this function is necessary. Can you explain it,
-      please?
-    <mcsim> When I've tried to compare speed of new allocator and old*
-    <braunr> i'm not sure i said that
-    <braunr> i said the performance overhead is negligible
-    <braunr> so it's better to leave the cpu pool layer in place, as it almost
-      doesn't hurt
-    <braunr> you can implement the KMEM_CF_NO_CPU_POOL I added in the x15 mach
-      version
-    <braunr> so that cpu pools aren't used by default, but the code is present
-      in case smp is implemented
-    <mcsim> I didn't remove cpu pool layer. I've just removed filling of cpu
-      pool during creation of slab.
-    <braunr> how do you fill the cpu pools then ?
-    <mcsim> If object is freed than it is added to cpu poll
-    <braunr> so you don't fill/drain the pools ?
-    <braunr> you try to get/put an object and if it fails you directly fall
-      back to the slab layer ?
-    <mcsim> I drain them during garbage collection
-    <braunr> oh
-    <mcsim> yes
-    <braunr> you shouldn't touch the cpu layer during gc
-    <braunr> the number of objects should be small enough so that we don't care
-      much
-    <mcsim> ok. I can drain cpu pool at any other time if it is prohibited to
-      in mem_gc.
-    <mcsim> But why do we need to fill cpu poll during slab creation?
-    <mcsim> In this case allocation consist of: get object from slab -> put it
-      to cpu pool -> get it from cpu pool
-    <mcsim> I've just remove last to stages
-    <braunr> hm cpu pools aren't filled at slab creation
-    <braunr> they're filled when they're empty, and drained when they're full
-    <braunr> so that the number of objects they contain is increased/reduced to
-      a value suitable for the next allocations/frees
-    <braunr> the idea is to fall back as little as possible to the slab layer
-      because it requires the acquisition of the cache lock
-    <mcsim> oh. You're right. I'm really sorry. The point is that if cpu pool
-      is empty we don't need to fill it first
-    <braunr> uh, yes we do :)
-    <mcsim> Why cache locking is so undesirable? If we have free objects in
-      slabs locking will not take a lot if time.
-    <braunr> mcsim: it's undesirable on a smp system
-    <mcsim> ok.
-    <braunr> mcsim: and spin locks are normally noops on a up system
-    <braunr> which is the case in gnumach, hence the slightly better
-      performances without the cpu layer
-    <braunr> but i designed this allocator for x15, which only supports mp
-      systems :)
-    <braunr> mcsim: sorry i couldn't look at your code, sick first, busy with
-      server migration now (new server almost ready for xen hurds :))
-    <mcsim> ok.
-    <mcsim> I ended with allocator if didn't miss anything important:)
-    <braunr> i'll have a look soon i hope :)
-
-
-# IRC, freenode, #hurd, 2011-09-27
-
-    <antrik> braunr: would it be realistic/useful to check during GC whether
-      all "used" objects are actually in a CPU pool, and if so, destroy them so
-      the slab can be freed?...
-    <antrik> mcsim: BTW, did you ever do any measurements of memory
-      use/fragmentation?
-    <mcsim> antrik: I couldn't do this for zalloc
-    <antrik> oh... why not?
-    <antrik> (BTW, I would be interested in a comparision between using the CPU
-      layer, and bare slab allocation without CPU layer)
-    <mcsim> Result I've got were strange. It wasn't even aligned to page size.
-    <mcsim> Probably is it better to look into /proc/vmstat?
-    <mcsim> Because I put hooks in the code and probably I missed something
-    <antrik> mcsim: I doubt vmstat would give enough information to make any
-      useful comparision...
-    <braunr> antrik: isn't this draining cpu pools at gc time ?
-    <braunr> antrik: the cpu layer was found to add a slight overhead compared
-      to always falling back to the slab layer
-    <antrik> braunr: my idea is only to drop entries from the CPU cache if they
-      actually prevent slabs from being freed... if other objects in the slab
-      are really in use, there is no point in flushing them from the CPU cache
-    <antrik> braunr: I meant comparing the fragmentation with/without CPU
-      layer. the difference in CPU usage is probably negligable anyways...
-    <antrik> you might remember that I was (and still am) sceptical about CPU
-      layer, as I suspect it worsens the good fragmentation properties of the
-      pure slab allocator -- but it would be nice to actually check this :-)
-    <braunr> antrik: right
-    <braunr> antrik: the more i think about it, the more i consider slqb to be
-      a better solution ...... :>
-    <braunr> an idea for when there's time
-    <braunr> eh
-    <antrik> hehe :-)
-
-
-# IRC, freenode, #hurd, 2011-10-13
-
-    <braunr> mcsim: what's the current state of your gnumach branch ?
-    <mcsim> I've merged it with master in September
-    <braunr> yes i've seen that, but does it build and run fine ?
-    <mcsim> I've tested it on gnumach from debian repository, but for building
-      I had to make additional change in device/ramdisk.c, as I mentioned.
-    <braunr> mcsim: why ?
-    <mcsim> And it runs fine for me.
-    <braunr> mcsim: why did you need to make other changes ?
-    <mcsim> because there is a patch which comes with from-debian-repository
-      kernel and it addes some code, where I have to make changes. Earlier
-      kernel_map was a pointer to structure, but I change that and now
-      kernel_map is structure. So handling to it should be by taking the
-      address (&kernel_map)
-    <braunr> why did you do that ?
-    <braunr> or put it another way: what made you do that type change on
-      kernel_map ?
-    <mcsim> Earlier memory for kernel_map was allocating with zalloc. But now
-      salloc can't allocate memory before it's initialisation
-    <braunr> that's not a good reason
-    <braunr> a simple workaround for your problem is this :
-    <braunr> static struct vm_map kernel_map_store;
-    <braunr> vm_map_t kernel_map = &kernel_map_store;
-    <mcsim> braunr: Ok. I'll correct this.
-
-
-# IRC, freenode, #hurd, 2011-11-01
-
-    <braunr> etenil: but mcsim's work is, for one, useful because the allocator
-      code is much clearer, adds some debugging support, and is smp-ready
-
-
-# IRC, freenode, #hurd, 2011-11-14
-
-    <braunr> i've just realized that replacing the zone allocator removes most
-      (if not all) static limit on allocated objects
-    <braunr> as we have nothing similar to rlimits, this means kernel resources
-      are actually exhaustible
-    <braunr> and i'm not sure every allocation is cleanly handled in case of
-      memory shortage
-    <braunr> youpi: antrik: tschwinge: is this acceptable anyway ?
-    <braunr> (although IMO, it's also a good thing to get rid of those limits
-      that made the kernel panic for no valid reason)
-    <youpi> there are actually not many static limits on allocated objects
-    <youpi> only a few have one
-    <braunr> those defined in kern/mach_param.h
-    <youpi> most of them are not actually enforced
-    <braunr> ah ?
-    <braunr> they are used at zinit() time
-    <braunr> i thought they were
-    <youpi> yes,  but most zones are actually fine with overcoming the max
-    <braunr> ok
-    <youpi> see zone->max_size += (zone->max_size >> 1);
-    <youpi> you need both !EXHAUSTIBLE and FIXED
-    <braunr> ok
-    <pinotree> making having rlimits enforced would be nice...
-    <pinotree> s/making//
-    <braunr> pinotree: the kernel wouldn't handle many standard rlimits anyway
-
-    <braunr> i've just committed my final patch on mcsim's branch, which will
-      serve as the starting point for integration
-    <braunr> which means code in this branch won't change (or only last minute
-      changes)
-    <braunr> you're invited to test it
-    <braunr> there shouldn't be any noticeable difference with the master
-      branch
-    <braunr> a bit less fragmentation
-    <braunr> more memory can be reclaimed by the VM system
-    <braunr> there are debugging features
-    <braunr> it's SMP ready
-    <braunr> and overall cleaner than the zone allocator
-    <braunr> although a bit slower on the free path (because of what's
-      performed to reduce fragmentation)
-    <braunr> but even "slower" here is completely negligible
-
-
-# IRC, freenode, #hurd, 2011-11-15
-
-    <mcsim> I enabled cpu_pool layer and kentry cache exhausted at "apt-get
-      source gnumach && (cd gnumach-* && dpkg-buildpackage)"
-    <mcsim> I mean kernel with your last commit
-    <mcsim> braunr: I'll make patch how I've done it in a few minutes, ok? It
-      will be more specific.
-    <braunr> mcsim: did you just remove the #if NCPUS > 1 directives ?
-    <mcsim> no. I replaced macro NCPUS > 1 with SLAB_LAYER, which equals NCPUS
-      > 1, than I redefined macro SLAB_LAYER
-    <braunr> ah, you want to make the layer optional, even on UP machines
-    <braunr> mcsim: can you give me the commands you used to trigger the
-      problem ?
-    <mcsim> apt-get source gnumach && (cd gnumach-* && dpkg-buildpackage)
-    <braunr> mcsim: how much ram & swap ?
-    <braunr> let's see if it can handle a quite large aptitude upgrade
-    <mcsim> how can I check swap size?
-    <braunr> free
-    <braunr> cat /proc/meminfo
-    <braunr> top
-    <braunr> whatever
-    <mcsim>              total       used       free     shared    buffers
-      cached
-    <mcsim> Mem:        786368     332296     454072          0          0
-      0
-    <mcsim> -/+ buffers/cache:     332296     454072
-    <mcsim> Swap:      1533948          0    1533948
-    <braunr> ok, i got the problem too
-    <mcsim> braunr: do you run hurd in qemu?
-    <braunr> yes
-    <braunr> i guess the cpu layer increases fragmentation a bit
-    <braunr> which means more map entries are needed
-    <braunr> hm, something's not right
-    <braunr> there are only 26 kernel map entries when i get the panic
-    <braunr> i wonder why the cache gets that stressed
-    <braunr> hm, reproducing the kentry exhaustion problem takes quite some
-      time
-    <mcsim> braunr: what do you mean?
-    <braunr> sometimes, dpkg-buildpackage finishes without triggering the
-      problem
-    <mcsim> the problem is in apt-get source gnumach
-    <braunr> i guess the problem happens because of drains/fills, which
-      allocate/free much more object than actually preallocated at boot time
-    <braunr> ah ?
-    <braunr> ok
-    <braunr> i've never had it at that point, only later
-    <braunr> i'm unable to trigger it currently, eh
-    <mcsim> do you use *-dbg kernel?
-    <braunr> yes
-    <braunr> well, i use the compiled kernel, with the slab allocator, built
-      with the in kernel debugger
-    <mcsim> when you run apt-get source gnumach, you run it in clean directory?
-      Or there are already present downloaded archives?
-    <braunr> completely empty
-    <braunr> ah just got it
-    <braunr> ok the limit is reached, as expected
-    <braunr> i'll just bump it
-    <braunr> the cpu layer drains/fills allocate several objects at once (64 if
-      the size is small enough)
-    <braunr> the limit of 256 (actually 252 since the slab descriptor is
-      embedded in its slab) is then easily reached
-    <antrik> mcsim: most direct way to check swap usage is vmstat
-    <braunr> damn, i can't live without slabtop and the amount of
-      active/inactive cache memory any more
-    <braunr> hm, weird, we have active/inactive memory in procfs, but not
-      buffers/cached memory
-    <braunr> we could set buffers to 0 and everything as cached memory, since
-      we're currently unable to communicate the purpose of cached memory
-      (whether it's used by disk servers or file system servers)
-    <braunr> mcsim: looks like there are about 240 kernel map entries (i forgot
-      about the ones used in kernel submaps)
-    <braunr> so yes, addin the cpu layer is what makes the kernel reach the
-      limit more easily
-    <mcsim> braunr: so just increasing limit will solve the problem?
-    <braunr> mcsim: yes
-    <braunr> slab reclaiming looks very stable
-    <braunr> and unfrequent
-    <braunr> (which is surprising)
-    <pinotree> braunr: "unfrequent"?
-    <braunr> pinotree: there isn't much memory pressure
-    <braunr> slab_collect() gets called once a minute on my hurd
-    <braunr> or is it infrequent ?
-    <braunr> :)
-    <pinotree> i have no idea :)
-    <braunr> infrequent, yes
-
-
-# IRC, freenode, #hurd, 2011-11-16
-
-    <braunr> for those who want to play with the slab branch of gnumach, the
-      slabinfo tool is available at http://git.sceen.net/rbraun/slabinfo.git/
-    <braunr> for those merely interested in numbers, here is the output of
-      slabinfo, for a hurd running in kvm with 512 MiB of RAM, an unused swap,
-      and a short usage history (gnumach debian packages built, aptitude
-      upgrade for a dozen of packages, a few git commands)
-    <braunr> http://www.sceen.net/~rbraun/slabinfo.out
-    <antrik> braunr: numbers for a long usage history would be much more
-      interesting :-)
-
-
-## IRC, freenode, #hurd, 2011-11-17
-
-    <braunr> antrik: they'll come :)
-    <etenil> is something going on on darnassus? it's mighty slow
-    <braunr> yes
-    <braunr> i've rebooted it to run a modified kernel (with the slab
-      allocator) and i'm building stuff on it to stress it
-    <braunr> (i don't have any other available machine with that amount of
-      available physical memory)
-    <etenil> ok
-    <antrik> braunr: probably would be actually more interesting to test under
-      memory pressure...
-    <antrik> guess that doesn't make much of a difference for the kernel object
-      allocator though
-    <braunr> antrik: if ram is larger, there can be more objects stored in
-      kernel space, then, by building something large such as eglibc, memory
-      pressure is created, causing caches to be reaped
-    <braunr> our page cache is useless because of vm_object_cached_max
-    <braunr> it's a stupid arbitrary limit masking the inability of the vm to
-      handle pressure correctly 
-    <braunr> if removing it, the kernel freezes soon after ram is filled
-    <braunr> antrik: it may help trigger the "double swap" issue you mentioned
-    <antrik> what may help trigger it?
-    <braunr> not checking this limit
-    <antrik> hm... indeed I wonder whether the freezes I see might have the
-      same cause
-
-
-## IRC, freenode, #hurd, 2011-11-19
-
-    <braunr> http://www.sceen.net/~rbraun/slabinfo.out <= state of the slab
-      allocator after building the debian libc packages and removing all files
-      once done
-    <braunr> it's mostly the same as on any other machine, because of the
-      various arbitrary limits in mach (most importantly, the max number of
-      objects in the page cache)
-    <braunr> fragmentation is still quite low
-    <antrik> braunr: actually fragmentation seems to be lower than on the other
-      run...
-    <braunr> antrik: what makes you think that ?
-    <antrik> the numbers of currently unused objects seem to be in a similar
-      range IIRC, but more of them are reclaimable I think
-    <antrik> maybe I'm misremembering the other numbers
-    <braunr> there had been more reclaims on the other run
-
-
-# IRC, freenode, #hurd, 2011-11-25
-
-    <braunr> mcsim: i've just updated the slab branch, please review my last
-      commit when you have time
-    <mcsim> braunr: Do you mean compilation/tests?
-    <braunr> no, just a quick glance at the code, see if it matches what you
-      intended with your original patch
-    <mcsim> braunr: everything is ok
-    <braunr> good
-    <braunr> i think the branch is ready for integration
-
-
-# IRC, freenode, #hurd, 2011-12-17
-
-    <braunr> in the slab branch, there now is no use for the defines in
-      kern/mach_param.h
-    <braunr> should the file be removed or left empty as a placeholder for
-      future arbitrary limits ?
-    <braunr> (i'd tend ro remove it as a way of indicating we don't want
-      arbitrary limits but there may be a good reason to keep it around .. :))
-    <youpi> I'd just drop it
-    <braunr> ok
-    <braunr> hmm maybe we do want to keep that one :
-    <braunr> #define IMAR_MAX        (1 << 10)       /* Max number of
-      msg-accepted reqs */
-    <antrik> whatever that is...
-    <braunr> it gets returned in ipc_marequest_info
-    <braunr> but the mach_debug interface has never been used on the hurd
-    <braunr> there now is a master-slab branch in the gnumach repo, feel free
-      to test it
-
-
-# IRC, freenode, #hurd, 2011-12-22
-
-    <youpi> braunr: does the new gnumach allocator has profiling features?
-    <youpi> e.g. to easily know where memory leaks reside
-    <braunr> youpi: you mean tracking call traces to allocated blocks ?
-    <youpi> not necessarily traces
-    <youpi> but at least means to know what kind of objects is filling memory
-    <braunr> it's very close to the zone allocator
-    <braunr> but instead of zones, there are caches
-    <braunr> each named after the type they store
-    <braunr> see http://www.sceen.net/~rbraun/slabinfo.out
-    <youpi> ok, so we can know, per-type, how much memory is used
-    <braunr> yes
-    <youpi> good
-    <braunr> if backtraces can easily be forged, it wouldn't be hard to add
-      that feature too
-    <youpi> does it dump such info when memory goes short?
-    <braunr> no but it can
-    <braunr> i've done this during tests
-    <youpi> it'd be good
-    <youpi> because I don't know in advance when a buildd will crash due to
-      that :)
-    <braunr> each time slab_collect() is called for example
-    <youpi> I mean not on collect, but when it's too late
-    <youpi> and thus always enabled
-    <braunr> ok
-    <youpi> (because there's nothing better to do than at least give infos)
-    <braunr> you just have to define "when it's too late", and i can add that
-    <youpi> when there is no memory left
-    <braunr> you mean when the number of free pages strictly reaches 0 ?
-    <youpi> yes
-    <braunr> ok
-    <youpi> i.e. just before crashing the kernel
-    <braunr> i see
-
-
-# IRC, freenode, #hurdfr, 2012-01-02
-
-    <youpi> braunr: le code du slab allocator, il est écrit from scratch ?
-    <youpi> il y a encore du copyright carnegie mellon
-    <youpi> (dans slab_info.h du moins)
-    <youpi> ipc_hash_global_size = 256;
-    <youpi> il faudrait mettre 256 comme constante dans un header
-    <youpi> sinon c'est encore une valeur arbitraire cachée dans du code
-    <youpi> de même pour ipc_marequest_size etc.
-    <braunr> youpi: oui, from scratch
-    <braunr> slab_info.h est à l'origine zone_info.h
-    <braunr> pour les valeurs fixes, elles étaient déjà présentes de cette
-      façon, j'ai pensé qu'il valait mieux laisser comme ça pour faciliter la
-      lecture des diffs
-    <braunr> je ferai des macros à la place
-    <braunr> du coup il faudra peut-être remettre mach_param.h
-    <braunr> ou alors dans les .h ipc
-
-
-# IRC, freenode, #hurd, 2012-01-18
-
-    <braunr> does the slab branch need other reviews/reports before being
-      integrated ?
-
-
-# IRC, freenode, #hurd, 2012-01-30
-
-    <braunr> youpi: do you have some idea about when you want to get the slab
-      branch in master ?
-    <youpi> I was considering as soon as mcsim gets his paper
-    <braunr> right
-
-
-# IRC, freenode, #hurd, 2012-02-22
-
-    <mcsim> Do I understand correct, that real memory page should be
-      necessarily in one of following lists: vm_page_queue_active,
-      vm_page_queue_inactive, vm_page_queue_free?
-    <braunr> cached pages are
-    <braunr> some special pages used only by the kernel aren't
-    <braunr> pages can be both wired and cached (i.e. managed by the page
-      cache), so that they can be passed to external applications and then
-      unwired (as is the case with your host_slab_info() function if you
-      remember)
-    <braunr> use "physical" instead of "real memory"
-    <mcsim> braunr: thank you.
-
-
-# IRC, freenode, #hurd, 2012-04-22
-
-    <braunr> youpi: tschwinge: when the slab code was added, a few new files
-      made into gnumach that come from my git repo and are used in other
-      projects as well
-    <braunr> they're licensed under BSD upstream and GPL in gnumach, and though
-      it initially didn't disturb me, now it does
-    <braunr> i think i should fix this by leaving the original copyright and
-      adding the GPL on top
-    <youpi> sure, submit a patch
-    <braunr> hm i have direct commit acces if im right
-    <youpi> then fix it :)
-    <braunr> do you want to review ?
-    <youpi> I don't think there is any need to
-    <braunr> ok
-
-
-# IRC, freenode, #hurd, 2012-12-08
-
-    <mcsim> braunr: hi. Do I understand correct that merely the same technique
-      is used in linux to determine the slab where, the object to be freed,
-      resides?
-    <braunr> yes but it's faster on linux since it uses a direct mapping of
-      physical memory
-    <braunr> it just has to shift the virtual address to obtain the physical
-      one, whereas x15 has to walk the pages tables
-    <braunr> of course it only works for kmalloc, vmalloc is entirely different
-    <mcsim> btw, is there sense to use some kind of B-tree instead of AVL to
-      decrease number of cache misses? AFAIK, in modern processors size of L1
-      cache line is at least 64 bytes, so in one node we can put at least 4
-      leafs (key + pointer to data) making search faster.
-    <braunr> that would be a b-tree
-    <braunr> and yes, red-black trees were actually developed based on
-      properties observed on b-trees
-    <braunr> but increasing the size of the nodes also increases memory
-      overhead
-    <braunr> and code complexity
-    <braunr> that's why i have a radix trees for cases where there are a large
-      number of entries with keys close to each other :)
-    <braunr> a radix-tree is basically a b-tree using the bits of the key as
-      indexes in the various arrays it walks instead of comparing keys to each
-      other
-    <braunr> the original avl tree used in my slab allocator was intended to
-      reduce the average height of the tree (avl is better for that)
-    <braunr> avl trees are more suited for cases where there are more lookups
-      than inserts/deletions
-    <braunr> they make the tree "flatter" but the maximum complexity of
-      operations that change the tree is 2log2(n), since rebalancing the tree
-      can make the algorithm reach back to the tree root
-    <braunr> red-black trees have slightly bigger heights but insertions are
-      limited to 2 rotations and deletions to 3
-    <mcsim> there should be not much lookups in slab allocators
-    <braunr> which explains why they're more generally found in generic
-      containers
-    <mcsim> or do I misunderstand something?
-    <braunr> well, there is a lookup for each free()
-    <braunr> whereas there are insertions/deletions when a slab becomes
-      non-empty/empty
-    <mcsim> I see
-    <braunr> so it was very efficient for caches of small objects, where slabs
-      have many of them
-    <braunr> also, i wrote the implementation in userspace, without
-      functionality pmap provides (although i could have emulated it
-      afterwards)
-
-
-# IRC, freenode, #hurd, 2013-01-06
-
-    <youpi> braunr: panic: vm_map: kentry memory exhausted
-    <braunr> youpi: ouch
-    <youpi> that's what I usually get
-    <braunr> ok
-    <braunr> the kentry area is a preallocated memory area that is used to back
-      the vm_map_kentry cache
-    <braunr> objects from this cache are used to describe kernel virtual memory
-    <braunr> so in this case, i simply assume the kentry area must be enlarged
-    <braunr> (currently, both virtual and physical memory is preallocated, an
-      improvement could be what is now done in x15, to preallocate virtual
-      memory only
-    <braunr> )
-    <youpi> Mmm, why do we actually have this limit?
-    <braunr> the kentry area must be described by one entry
-    <youpi> ah, sorry, vm/vm_resident.c:       kentry_data =
-      pmap_steal_memory(kentry_data_size);
-    <braunr> a statically allocated one
-    <youpi> I had missed that one
-    <braunr> previously, the zone allocator would do that
-    <braunr> the kentry area is required to avoid recursion when allocating
-      memory
-    <braunr> another solution would be a custom allocator in vm_map, but i
-      wanted to use a common cache for those objects too
-    <braunr> youpi: you could simply try doubling KENTRY_DATA_SIZE
-    <youpi> already doing that
-    <braunr> we might even consider a much larger size until it's reworked
-    <youpi> well, it's rare enough on buildds already
-    <youpi> doubling should be enough
-    <youpi> or else we have leaks
-    <braunr> right
-    <braunr> it may not be leaks though
-    <braunr> it may be poor map entry merging
-    <braunr> i'd expected the kernel map entries to be easier to merge, but it
-      may simply not be the case
-    <braunr> (i mean, when i made my tests, it looked like there were few
-      kernel map entries, but i may have missed corner cases that could cause
-      more of them to be needed)
-
-
-## IRC, freenode, #hurd, 2014-02-11
-
-    <braunr> youpi: what's the issue with kentry_data_size ?
-    <youpi> I don't know
-    <braunr> so back to 64pages from 256 ?
-    <youpi> in debian for now yes
-    <braunr> :/
-    <braunr> from what i recall with x15, grub is indeed allowed to put modules
-      and command lines around as it likes
-    <braunr> restricted to 4G
-    <braunr> iirc, command lines were in the first 1M while modules could be
-      loaded right after the kernel or at the end of memory, depending on the
-      versions
-    <youpi> braunr: possibly VM_KERNEL_MAP_SIZE is then not big enough
-    <braunr> youpi: what's the size of the ramdisk ?
-    <braunr> youpi: or kmem_map too big
-    <braunr> we discussed this earlier with teythoon 
-
-[[user-space_device_drivers]], *Open Issues*, *System Boot*, *IRC, freenode,
-\#hurd, 2011-07-27*, *IRC, freenode, #hurd, 2014-02-10*
-
-    <braunr> or maybe we want to remove kmem_map altogether and directly use
-      kernel_map
-    <youpi> it's 6.2MiB big
-    <braunr> hm
-    <youpi> err no
-    <braunr> looks small
-    <youpi> 70MiB
-    <braunr> ok yes
-    <youpi> (uncompressed)
-    <braunr> well
-    <braunr> kernel_map is supposed to have 64M on i386 ...
-    <braunr> it's 192M large, with kmem_map taking 128M
-    <braunr> so at most 64M, with possible fragmentation
-    <teythoon> i believe the compressed initrd is stored in the ramdisk
-    <youpi> ah, right it's ext2fs which uncompresses it
-    <braunr> uncompresses it where 
-    <braunr> ?
-    <teythoon> libstore does that
-    <youpi> module --nounzip /boot/${gtk}initrd.gz 
-    <youpi> braunr: in userland memory
-    <youpi> it's not grub which uncompresses it for sure
-    <teythoon> braunr: so my ramdisk isn't 64 megs either
-    <braunr> which explains why it sometimes works
-    <teythoon> yes
-    <teythoon> mine is like 15 megs
-    <braunr> kentry_data_size calls pmap_steal_memory, an early allocation
-      function which changes virtual_space_start, which is later used to create
-      the first kernel map entry
-    <braunr> err, pmap_steal_memory is called with kentry_data_size as its
-      argument
-    <braunr> this first kernel map entry is installed inside kernel_map and
-      reduces the amount of available virtual memory there
-    <braunr> so yes, it all points to a layout problem
-    <braunr> i suggest reducing kmem_map down to 64M
-    <youpi> that's enough to get d-i back to boot
-    <youpi> what would be the downside?
-    <youpi> (why did you raise it to 128 actually? :) )
-    <braunr> i merged the map used by generic kalloc allocations into kmem_map
-    <braunr> both were 64M
-    <braunr> i don't see any downside for the moment
-    <braunr> i rarely see more than 50M used by the slab allocator
-    <braunr> and with the recent code i added to collect reclaimable memory on
-      kernel allocation failures, it's unlikely the slab allocator will be
-      starved
-    <youpi> but then we need that patch too
-    <braunr> no
-    <braunr> it would be needed if kmem_map gets filled
-    <braunr> this very rarely happens
-    <youpi> is "very rarely" enough ? :)
-    <braunr> actualy i've never seen it happen
-    <braunr> i added it because i had port leaks with fakeroot
-    <braunr> port rights are a bit special because they're stored in a table in
-      kernel space
-    <braunr> this table is enlarged with kmem_realloc
-    <braunr> when an ipc space gets very large, fragmentation makes it very
-      difficult to successfully resize it
-    <braunr> that should be the only possible issue
-    <braunr> actually, there is another submap that steals memory from
-      kernel_map: device_io_map is 16M large
-    <braunr> so kernel_map gets down to 48M
-    <braunr> if the initial entry (that is, kentry_data_size + the physical
-      page table size) gets a bit large, kernel_map may have very little
-      available room
-    <braunr> the physical page table size obviously varies depending on the
-      amount of physical memory loaded, which may explain why the installer
-      worked on some machines
-    <youpi> well, it works up to 1855M
-    <youpi> at 1856 it doesn't work any more :)
-    <braunr> heh :)
-    <youpi> and that's about the max gnumach can handle anyway
-    <braunr> then reducing kmem_map down to 96M should be enough
-    <youpi> it works indeed
-    <braunr> could you check the amount of available space in kernel_map ?
-    <braunr> the value of kernel_map->size should do
-    <youpi> printing it "multiboot modules" print should be fine I guess?
-
-
-### IRC, freenode, #hurd, 2014-02-12
-
-    <braunr> probably
-    <teythoon> ?
-    <braunr> i expect a bit more than 160M
-    <braunr> (for the value of kernel_map->size)
-    <braunr> teythoon: ?
-    <youpi> well, it's 2110210048
-    <teythoon> what is multiboot modules printing ?
-    <youpi> almost last in gnumach bootup
-    <braunr> humm
-    <braunr> it must account directly mapped physical pages
-    <braunr> considering the kernel has exactly 2G, this means there is 36M
-      available in kernel_map
-    <braunr> youpi: is the ramdisk loaded at that moment ?
-    <youpi> what do you mean by "loaded" ? :)
-    <braunr> created
-    <youpi> where?
-    <braunr> allocated in kernel memory
-    <youpi> the script hasn't started yet
-    <braunr> ok
-    <braunr> its size was 6M+ right ?
-    <braunr> so it leaves around 30M
-    <youpi> something like this yes
-    <braunr> and changing kmem_map from 128M to 96M gave us 32M
-    <braunr> so that's it
-
-
-# IRC, freenode, #hurd, 2013-04-18
-
-    <braunr> oh nice, i've found a big scalability issue with my slab allocator
-    <braunr> it shouldn't affect gnumach much though
-
-
-## IRC, freenode, #hurd, 2013-04-19
-
-    <ArneBab> braunr: is it fixable?
-    <braunr> yes
-    <braunr> well, i'll do it in x15 for a start
-    <braunr> again, i don't think gnumach is much affected
-    <braunr> it's a scalability issue
-    <braunr> when millions of objects are in use
-    <braunr> gnumach rarely has more than a few hundred thousands
-    <braunr> it's also related to heavy multithreading/smp
-    <braunr> and by multithreading, i also mean preemption
-    <braunr> gnumach isn't preemptible and uniprocessor
-    <braunr> if the resulting diff is clean enough, i'll push it to gnumach
-      though :)
-
-
-### IRC, freenode, #hurd, 2013-04-21
-
-    <braunr> ArneBab_: i fixed the scalability problems btw
-
-
-## IRC, freenode, #hurd, 2013-04-20
-
-    <braunr> well, there is also a locking error in the slab allocator,
-      although not a problem for a non preemptible kernel like gnumach
-    <braunr> non preemptible / uniprocessor
diff --git a/open_issues/gnumach_memory_management_2.mdwn b/open_issues/gnumach_memory_management_2.mdwn
deleted file mode 100644
index 64aae2a4..00000000
--- a/open_issues/gnumach_memory_management_2.mdwn
+++ /dev/null
@@ -1,246 +0,0 @@
-[[!meta copyright="Copyright © 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_gnumach]]
-
-IRC, freenode, #hurd, 2011-10-16:
-
-    <youpi> braunr: I realize that kmem_alloc_wired maps the allocated pages in
-      the kernel map
-    <youpi> it's a bit of a waste when my allocation is exactly a page size
-    <youpi> is there a proper page allocation which would simply return its
-      physical address?
-    <youpi> pages returned by vm_page_grab  may get swapped out, right?
-    <youpi> so could it be a matter of calling vm_page_alloc then vm_page_wire
-      (with lock_queues held) ?
-    <youpi> s/alloc/grab/
-    <braunr> vm_page_grab() is only used at boot iirc
-    <braunr> youpi: mapping allocated memory in the kernel map is normal, even
-      if it's only a page
-    <braunr> the allocated area usually gets merged with an existing
-      vm_map_entry
-    <braunr> youpi: also, i'm not sure about what you're trying to do here, so
-      my answers may be out of scope :p
-    <youpi> saving addressing space
-    <youpi> with that scheme we're using twice as much addressing space for
-      kernel buffers
-    <braunr> kernel or user task ?
-    <youpi> kernl
-    <braunr> hm are there so many wired areas ?
-    <youpi> several MiBs, yes
-    <youpi> there are also the zalloc areas
-    <braunr> that's pretty normal
-    <youpi> which I've recently incrased
-    <braunr> hm forget what i've just said about vm_page_grab()
-    <braunr> youpi: is there a particular problem caused by kernel memory
-      exhaustion ?
-    <youpi> I currently can't pass the dh_strip stage of iceweasel due to this
-    <youpi> it can not allocate a stack 
-    <braunr> a kernel thread stack ?
-    <youpi> yes
-    <braunr> that's surprising
-    <youpi> it'd be good to have a kernel memory profile
-    <braunr> vminfo is able to return the kernel map
-    <youpi> well, it's not suprising if the kernel map is full
-    <youpi> but it doesn't tell what allocates which p ieces
-    <braunr> that's what i mean, it's surprising to have a full kernel map
-    <youpi> (that's what profiling is about)
-    <braunr> right
-    <youpi> well, it's not really surprising, considering that the krenel map
-      size is arbitrarily chosen
-    <braunr> youpi: 2 GiB is really high enough
-    <youpi> it's not 2GiB, precisely
-    <youpi> there is much of the 2GiB addr space which is spent on physical
-      memory mapping
-    <youpi> then there is the virtual mapping
-    <braunr> are you sure we're talking about the kernel map, or e.g. the kmem
-      map
-    <youpi> which is currently only 192MiB
-    <youpi> the kmem_map part of kernel_map
-    <braunr> ok, the kmem_map submap then
-    <braunr> netbsd has used 128 MiB for yeas with almost no issue
-    <braunr> mach uses more kernel objects so it's reasonable to have a bigger
-      map
-    <braunr> but that big ..
-    <youpi> I've made the zalloc areas quite big
-    <youpi> err, not only zalloc area
-    <braunr> kernel stacks are allocated directly from the kernel map
-    <youpi> kalloc to 64MiB, zalloc to 64MiB
-    <youpi> ipc map size to 8MiB
-    <braunr> youpi: it could be the lack of kernel map entries
-    <youpi> and the device io map to 16MiB
-    <braunr> do you have the exact error message ?
-    <youpi> no more room for vm_map_find_entry in 71403294
-    <youpi> no more rooom for kmem_alloc_aligned in 71403294
-    <braunr> ah, aligned
-    <youpi> for a stack
-    <youpi> which is 4 pages only
-    <braunr> memory returned by kmem functions always return pages
-    <braunr> hum
-    <braunr> kmem functions always return memory in page units
-    <youpi> and my xen driver is allocating 1MiB memory for the network buffer
-    <braunr> 4 pages for kernel stacks ?
-    <youpi> through kmem_alloc_wire
-    <braunr> that seems a lot
-    <youpi> that's needed for xen page updates
-    <youpi> without having to split the update in several parts
-    <braunr> ok
-    <braunr> but are there any alignment requirements ?
-    <youpi> I guess mach  uses the alignment trick to find "self"
-    <youpi> anyway, an alignment on 4pages shouldn't be a problem
-    <braunr> i think kmem_alloc_aligned() is the generic function used both for
-      requests with and without alignment constraints
-    <youpi> so I was thinking about at least moving my xen net driver to
-      vm_grab_page instead of kmem_alloc
-    <youpi> and along this, maybe others
-    <braunr> but you only get a vm_page, you can't access the memory it
-      describes
-    <youpi> non, a lloc_aligned always aligns
-    <youpi> why?
-    <braunr> because it's not mapped
-    <youpi> there's even vm_grab_page_physical_addr
-    <youpi> it is, in the physical memory map
-    <braunr> ah, you mean using the direct mapped area
-    <youpi> yes
-    <braunr> then yes
-    <braunr> i don't know that part much
-    <youpi> what I'm afraid of is the wiring
-    <braunr> why ?
-    <youpi> because I don't want to see my page swapped out :)
-    <youpi> or whatever might happen if I don't wire it
-    <braunr> oh i'm almost sure you won't
-    <youpi> why?
-    <youpi> why some people need to wire it, and I won't?
-    <braunr> because in most mach vm derived code i've seen, you have to
-      explicitely tell the vm your area is pageable
-    <youpi> ah,  mach does such thing indeed
-    <braunr> wiring can be annoying when you're passing kernel data to external
-      tasks
-    <braunr> you have to make sure the memory isn't wired once passed
-    <braunr> but that's rather a security/resource management problem
-    <youpi> in the net driver case, it's not passed to anything else
-    <youpi> I'm seeing 19MiB kmem_alloc_wired atm
-    <braunr> looks ok to me
-    <braunr> be aware that the vm_resident code was meant for single page
-      allocations
-    <youpi> what does this mean?
-    <braunr> there is no buddy algorithm or anything else decent enough wrt
-      performance
-    <braunr> vm_page_grab_contiguous_pages() can be quite slow
-    <youpi> err, ok, but what is the relation with the question at stake ?
-    <braunr> you need 4 pages of direct mapped memory for stacks
-    <braunr> those pages need to be physically contiguous if you want to avoid
-      the mapping
-    <braunr> allocating physically contiguous pages in mach is slow
-    <braunr> :)
-    <youpi> I didn't mean I wanted to avoid the mapping for stacks
-    <youpi> for anything more than a page, kmem mapping should be fine
-    <youpi> I'm concerned with code which allocates only page per page
-    <youpi> which thus really doesn't need any mapping
-    <braunr> i don't know the mach details but in derived implementations,
-      there is almost no overhead when allocating single pages
-    <braunr> except for the tlb programming
-    <youpi> well, there is: twice as much addressing space
-    <braunr> well
-    <braunr> netbsd doesn't directly map physical memory
-    <braunr> and for others, like freebsd
-    <braunr> the area is just one vm_map_entry
-    <braunr> and on modern mmus, 4 MiBs physical mappings are used in pmap
-    <youpi> again, I don't care about tlb & performance
-    <youpi> just about the addressing space
-    <braunr> hm
-    <braunr> you say "twice"
-    <youpi> which is short when you're trying to link crazy stuff like
-      iceweasel & co
-    <youpi> yes
-    <braunr> ok, the virtual space is doubled
-    <youpi> yes
-    <braunr> but the resources consume to describe them aren't
-    <braunr> even on mach
-    <youpi> since you have both the physical mapping and the kmem mapping
-    <youpi> I don't care much about the resources
-    <youpi> but about addressing space
-    <braunr> well there are a limited numbers of solutions
-    <youpi> the space it takes  and has to be taken from something else, that
-      is,  here physical memory available to Mach
-    <braunr> reduce the physical mapping
-    <braunr> increase the kmem mapping
-    <braunr> or reduce kernel memory consumption
-    <youpi> and instead of taking the space from physical  mapping, we can as
-      well avoid doubling the space consumption when it's trivial lto
-    <youpi> yes, the hird
-    <youpi> +t
-    <youpi> that's what I'm asking from the beginning :)
-    <braunr> 18:21 < youpi> I don't care much about the resources
-    <braunr> actually, you care :)
-    <youpi> yes and no
-    <braunr> i understand what you mean
-    <youpi> not in the sense "it takes a page_t to allocate a page"
-    <braunr> you want more virtual space, and aren't that much concerned about
-      the number of objects used
-    <youpi> yes
-    <braunr> then it makes sense
-    <braunr> but in this case, it could be a good idea to generalize it
-    <braunr> have our own kmalloc/vmalloc interfaces
-    <braunr> maybe a gsoc project :)
-    <youpi> err, don't we have them already?
-    <youpi> I mean, what exactly do you want to generalize?
-    <braunr> mach only ever had vmalloc
-    <youpi> we already have a hell lot of allocators :)
-    <youpi> and it's a pain to distribute the available space to them
-    <braunr> yes
-    <braunr> but what you basically want is to introduce something similar to
-      kmalloc for single pages
-    <youpi> or just patch the few cases that need it into just grabbing a page
-    <youpi> there are probably not so many
-    <braunr> ok
-    <braunr> i've just read vm_page_grab()
-    <braunr> it only removes a page from the free list
-    <braunr> other functions such as vm_page_alloc insert them afterwards
-    <braunr> if a page is in no list, it can't be paged out
-    <braunr> so i think it's probably safe to assume it's naturally wired
-    <braunr> you don't even need a call to vm_page_wire or a flag of some sort
-    <youpi> ok
-    <braunr> although considering the low amount of work done by
-      vm_page_wire(), you could, for clarity
-    <youpi> braunr: I was also wondering about the VM_PAGE_FREE_RESERVED & such
-      constants
-    <youpi> they're like 50 pages
-    <youpi> is this still reasonable  nowadays?
-    <braunr> that's a question i'm still asking myself quite often :)
-    <youpi> also, the BURST_{MAX,MIN} & such in vm_pageout.c are probably out
-      of date?
-    <braunr> i didn't study the pageout code much
-    <youpi> k
-    <braunr> but correct handling of low memory thresholds is a good point to
-      keep in mind
-    <braunr> youpi: i often wonder how linux can sometimes have so few free
-      pages left and still be able to work without any visible failure
-    <youpi> well, as long as you have enough pages to be able to make progress,
-      you're fine
-    <youpi> that' the point of the RESERVED pages in mach I guess
-    <braunr> youpi: yes but, obviously, hard values are *bad*
-    <braunr> linux must adjust it, depending on the number of processors, the
-      number of pdflush threads, probably other things i don't have in mind
-    <braunr> i don't know what should make us adjust that value in mach
-    <youpi> which value?
-    <braunr> the size of the reserved pool
-    <youpi> I don't think it's adjusted
-    <braunr> that's what i'm saying
-    <braunr> i guess there is an #ifndef line for arch specific definitions
-    <youpi> err, you just said linux must adjust it :
-    <youpi> ))
-    <youpi> there is none
-    <braunr> linux adjusts it dynamically
-    <braunr> well ok
-    <braunr> that's another way to say it
-    <braunr> we don't have code to get rid of this macro
-    <braunr> but i don't even know how we, as maintainers, are supposed to
-      guess it
diff --git a/open_issues/gnumach_memory_management_physical_memory.mdwn b/open_issues/gnumach_memory_management_physical_memory.mdwn
deleted file mode 100644
index 58fefe1f..00000000
--- a/open_issues/gnumach_memory_management_physical_memory.mdwn
+++ /dev/null
@@ -1,46 +0,0 @@
-[[!meta copyright="Copyright © 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_gnumach]]
-
-IRC, freenode, #hurd, 2011-10:
-
-    <braunr> antrik: about our physical memory limitations, i told you some
-      time ago that part of it was due to the linux drivers
-    <braunr> and i mentioned the paper concerning the integration of the linux
-      drivers written at the time
-    <braunr> it does indeed tell that mach, which used the common 3G->4G area
-      for the kernel space had to be adapted
-    <braunr> because linux used segmentation so that kernel addresses matched
-      physical addresses
-    <braunr> and it looks like some (many) drivers require that
-    <braunr> our current gnumach actually does this (which i found surprising
-      when i first found it)
-    <braunr> and i believe the easy solution to exceed this limitation is to
-      use a strategy similar to what linux still does on i386
-    <braunr> some highmem support
-    <braunr> we could alter the vm_resident module so that, by default, it
-      still looks for pages in the low 0-800 (or 0-1800 on debian patched
-      kernels) area
-    <braunr> but for everything else than the kernel, e.g. all user processes
-    <braunr> we could use a flag or a specialized function that would first
-      look in the highmem pool for available physical pages to map
-    <braunr> the only thing i'm not yet sure of is about user/kernel transfers
-    <braunr> if virtual addresses and copies are always cleanly done, then it's
-      ok
-    <braunr> and i really hope our linux drivers do so :)
-    <braunr> (i mean ,the glue code ofc)
-
-2011-10-23:
-
-    <youpi> braunr: I believe, like Linus, that highmem support is a nightmare
-    <antrik> braunr: uhm... the drivers want virtual addressses to match
-      physical ones? I guess that means switching address spaces before any
-      driver code is executed?...
diff --git a/open_issues/gnumach_page_cache_policy.mdwn b/open_issues/gnumach_page_cache_policy.mdwn
deleted file mode 100644
index 77e52ddb..00000000
--- a/open_issues/gnumach_page_cache_policy.mdwn
+++ /dev/null
@@ -1,873 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 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_gnumach]]
-
-[[!toc]]
-
-
-# [[page_cache]]
-
-
-# IRC, freenode, #hurd, 2012-04-26
-
-    <braunr> another not-too-long improvement would be changing the page cache
-      policy
-    <youpi> to drop the 4000 objects limit, you mean ?
-    <braunr> yes
-    <youpi> do you still have my patch attempt ?
-    <braunr> no
-    <youpi> let me grab that
-    <braunr> oh i won't start it right away you know
-    <braunr> i'll ask for it when i do
-    <youpi> k
-    <braunr> (otherwise i fell i'll just loose it again eh)
-    <youpi> :)
-    <braunr> but i imagine it's not too hard to achieve
-    <youpi> yes
-    <braunr> i also imagine to set a large threshold of free pages to avoid
-      deadlocks
-    <braunr> which will still be better than the current situation where we
-      have either lots of free pages because tha max limit is reached, or lots
-      of pressure and system freezes :/
-    <youpi> yes
-
-
-## IRC, freenode, #hurd, 2012-06-17
-
-    <braunr> youpi: i don't understand your patch :/
-    <youpi> arf
-    <youpi>  which part don't you understand?
-    <braunr> the global idea :/
-    <youpi> first, drop the limit on number of objects
-    <braunr> you added a new collect call at pageout time
-    <youpi> (i.e. here, hack overflow into 0)
-    <braunr> yes
-    <braunr> obviously
-    <youpi> but then the cache keeps filling up with objects
-    <youpi> which sooner or later become empty
-    <youpi> thus the collect, which is supposed to look for empty objects, and
-      just drop them
-    <braunr> but not at the right time
-    <braunr> objects should be collected as soon as their ref count drops to 0
-    <braunr> err
-    <youpi> now, the code of the collect is just a crude attempt without
-      knowing much about the vm
-    <braunr> when their resident page count drops to 0
-    <youpi> so don't necessarily read it :)
-    <braunr> ok
-    <braunr> i've begin playing with the vm recently
-    <braunr> the limits (arbitrary, and very old obviously) seem far too low
-      for current resources
-    <braunr> (e.g. the threshold on free pages is 50 iirc ...)
-    <youpi> yes
-    <braunr> i'll probably use a different approach
-    <braunr> the one i mentioned (collecting one object at a time - or pushing
-      them on a list for bursts - when they become empty)
-    <braunr> this should relax the kernel allocator more
-    <braunr> (since there will be less empty vm_objects remaining until the
-      next global collecttion)
-
-
-## IRC, freenode, #hurd, 2012-06-30
-
-    <braunr> the threshold values of the page cache seem quite enough actually
-    <youpi> braunr: ah
-    <braunr> youpi: yes, it seems the problems are in ext2, not in the VM
-    <youpi> k
-    <youpi> the page cache limitation still doesn't help :)
-    <braunr> the problem in the VM is the recycling of vm_objects, which aren't
-      freed once empty
-    <braunr> but it only wastes some of the slab memory, it doesn't prevent
-      correct processing
-    <youpi> braunr: thus the limitation, right?
-    <braunr> no
-    <braunr> well
-    <braunr> that's the policy they chose at the time
-    <braunr> for what reason .. i can't tell
-    <youpi> ok, but I mean
-    <youpi> we can't remove the policy because of the non-free of empty objects
-    <braunr> we must remove vm_objects at some point
-    <braunr> but even without it, it makes no sense to disable the limit while
-      ext2 is still unstable
-    <braunr> also, i noticed that the page count in vm_objects never actually
-      drop to 0 ...
-    <youpi> you mean the limit permits to avoid going into the buggy scenarii
-      too often?
-    <braunr> yes
-    <youpi> k
-    <braunr> at least, that's my impression
-    <braunr> my test case is tar xf files.tar.gz, which contains 50000 files of
-      12k random data
-    <braunr> i'll try with other values
-    <braunr> i get crashes, deadlocks, livelocks, and it's not pretty :)
-
-[[libpager_deadlock]].
-
-    <braunr> and always in ext2, mach doesn't seem affected by the issue, other
-      than the obvious
-    <braunr> (well i get the usual "deallocating an invalid port", but as
-      mentioned, it's "most probably a bug", which is the case here :)
-    <youpi> braunr: looks coherent with the hangs I get on the buildds
-    <braunr> youpi: so that's the nasty bug i have to track now
-    <youpi> though I'm also still getting some out of memory from gnumach
-      sometimes
-    <braunr> the good thing is i can reproduce it very quickly
-    <youpi> a dump from the allocator to know which zone took all the room
-      might help
-    <braunr> youpi: yes i promised that too
-    <youpi> although that's probably related with ext2 issues :)
-    <braunr> youpi: can you send me the panic message so i can point the code
-      which must output the allocator state please ?
-    <youpi> next time I get it, sure :)
-    <pinotree> braunr: you could implement a /proc/slabinfo :)
-    <braunr> pinotree: yes but when a panic happens, it's too late
-    <braunr> http://git.sceen.net/rbraun/slabinfo.git/ btw
-    <braunr> although it's not part of procfs
-    <braunr> and the mach_debug interface isn't provided :(
-
-
-## IRC, freenode, #hurd, 2012-07-03
-
-    <braunr> it looks like pagers create a thread per memory object ...
-    <antrik> braunr: oh. so if I open a lot of files, ext2fs will *inevitably*
-      have lots of threads?...
-    <braunr> antrik: i'm not sure
-    <braunr> it may only be required to flush them
-    <braunr> but when there are lots of them, the threads could run slowly,
-      giving the impression there is one per object
-    <braunr> in sync mode i don't see many threads
-    <braunr> and i don't get the bug either for now
-    <braunr> while i can see physical memory actually being used
-    <braunr> (and the bug happens before there is any memory pressure in the
-      kernel)
-    <braunr> so it definitely looks like a corruption in ext2fs
-    <braunr> and i have an idea .... :>
-    <braunr> hm no, i thought an alloca with a big size parameter could erase
-      memory outside the stack, but it's something else
-    <braunr> (although alloca should really be avoided)
-    <braunr> arg, the problem seems to be in diskfs_sync_everything ->
-      ports_bucket_iterate (pager_bucket, sync_one); :/
-    <braunr> :(
-    <braunr> looks like the ext2 problem is triggered by calling pager_sync
-      from diskfs_sync_everything
-    <braunr> and is possibly related to
-      http://lists.gnu.org/archive/html/bug-hurd/2010-03/msg00127.html
-    <braunr> (and for reference, the rest of the discussion
-      http://lists.gnu.org/archive/html/bug-hurd/2010-04/msg00012.html)
-    <braunr> multithreading in libpager is scary :/
-    <antrik> braunr: s/in libpager/ ;-)
-    <braunr> antrik: right
-    <braunr> omg the ugliness :/
-    <braunr> ok i found a bug
-    <braunr> a real one :)
-    <braunr> (but not sure it's the only one since i tried that before)
-    <braunr> 01:38 < braunr> hm no, i thought an alloca with a big size
-      parameter could erase memory outside the stack, but it's something else
-    <braunr> turns out alloca is sometimes used for 64k+ allocations
-    <braunr> which explains the stack corruptions
-    <pinotree> ouch
-    <braunr> as it's used to duplicate the node table before traversing it, it
-      also explains why the cache limit affects the frequency of the bug
-    <braunr> now the fun part, write the patch following GNU protocol .. :)
-
-[[!message-id "1341350006-2499-1-git-send-email-rbraun@sceen.net"]]
-
-    <braunr> if someone feels like it, there are a bunch of alloca calls in the
-      hurd (like around 30 if i'm right)
-    <braunr> most of them look safe, but some could trigger that same problem
-      in other servers
-    <braunr> ok so far, no problem with the upstream ext2fs code :)
-    <braunr> 20 loops of tar xf / rm -rf consuming all free memory as cache :)
-    <braunr> the hurd uses far too much cpu time for no valid reason in many
-      places :/
-    * braunr happy
-    <braunr> my hurd is completely using its ram :)
-    <gnu_srs> Meaning, the bug is solved? Congrats if so :)
-    <braunr> well, ext2fs looks way more stable now
-    <braunr> i haven't had a single issue since the change, so i guess i messed
-      something with my previous test
-    <braunr> and the Mach VM cache implementation looks good enough
-    <braunr> now the only thing left is to detect unused objects and release
-      them
-    <braunr> which is actually the core of my work :)
-    <braunr> but i'm glad i could polish ext2fs
-    <braunr> with luck, this is the issue that was striking during "thread
-      storms" in the past
-    * pinotree hugs braunr
-    <braunr> i'm also very happy to see the slab allocator reacting well upon
-      memory pressure :>
-    <mcsim> braunr: Why alloca corrupted memory diskfs_node_iterate? Was
-      temporary node to big to keep it in stack?
-    <braunr> mcsim: yes
-    <braunr> 17:54 < braunr> turns out alloca is sometimes used for 64k+
-      allocations
-    <braunr> and i wouldn't be surprised if our thread stacks are
-      simplecontiguous 64k mappings of zero-filled memory
-    <braunr> (as Mach only provides bottom-up allocation)
-    <braunr> our thread implementation should leave unmapped areas between
-      thread stacks, to easily catch such overflows
-    <pinotree> braunr: wouldn't also fatfs/inode.c and tmpfs/node.c need the
-      same fix?
-    <braunr> pinotree: possibly
-    <braunr> i haven't looked
-    <braunr> more than 300 loops of tar xf / rm -rf on an archive of 20000
-      files of 12 KiB each, without any issue, still going on :)
-    <youpi> braunr: yay
-
-
-## [[!message-id "20120703121820.GA30902@mail.sceen.net"]], 2012-07-03
-
-
-## IRC, freenode, #hurd, 2012-07-04
-
-    <braunr> mach is so good it caches objects which *no* page in physical
-      memory
-    <braunr> hm i think i have a working and not too dirty vm cache :>
-    <kilobug> braunr: congrats :)
-    <braunr> kilobug: hey :)
-    <braunr> the dangerous side effect is the increased swappiness
-    <braunr> we'll have to monitor that on the buildds
-    <braunr> otherwise the cache is effectively used, and the slab allocator
-      reports reasonable amounts of objects, not increasing once the ram is
-      full
-    <braunr> let's see what happens with 1.8 GiB of RAM now
-    <braunr> damn glibc is really long to build :)
-    <braunr> and i fear my vm cache patch makes non scalable algorithms negate
-      some of its benefits :/
-    <braunr> 72 tasks, 2090 threads
-    <braunr> we need the ability to monitor threads somewhere
-
-
-## IRC, freenode, #hurd, 2012-07-05
-
-    <braunr> hm i get kernel panics when not using the host cache :/
-    <braunr> no virtual memory for stack allocations
-    <braunr> that's scary
-    <antrik> ?
-    <braunr> i guess the lack of host cache makes I/O slow enough to create a
-      big thread storm
-    <braunr> that completely exhausts the kernel space
-    <braunr> my patch challenges scalability :)
-    <antrik> and not having a zalloc zone anymore, instead of getting a nice
-      panic when trying to allocate yet another thread, you get an address
-      space exhaustion on an unrelated event instead. I see ;-)
-    <braunr> thread stacks are not allocated from a zone/cache
-    <braunr> also, the panic concerned aligned memory, but i don't think that
-      matters
-    <braunr> the kernel panic clearly mentions it's about thread stack
-      allocation
-    <antrik> oh, by "stack allocations" you actually mean allocating a stack
-      for a new thread...
-    <braunr> yes
-    <antrik> that's not what I normally understand when reading "stack
-      allocations" :-)
-    <braunr> user stacks are simple zero filled memory objects
-    <braunr> so we usually get a deadlock on them :>
-    <braunr> i wonder if making ports_manage_port_operations_multithread limit
-      the number of threads would be a good thing to do
-    <antrik> braunr: last time slpz did that, it turned out that it causes
-      deadlocks in at least one (very specific) situation
-    <braunr> ok
-    <antrik> I think you were actually active at the time slpz proposed the
-      patch (and it was added to Debian) -- though probably not at the time
-      where youpi tracked it down as the cause of certain lockups, so it was
-      dropped again...
-    <braunr> what seems very weird though is that we're normally using
-      continuations
-
-[[microkernel/mach/gnumach/continuation]].
-
-    <antrik> braunr: you mean in the kernel? how is that relevant to the topic
-      at hand?...
-    <braunr> antrik: continuations have been designed to reduce the number of
-      stacks to one per cpu :/
-    <braunr> but they're not used everywhere
-    <antrik> they are not used *anywhere* in the Hurd...
-    <braunr> antrik: continuations are supposed to be used by kernel code
-    <antrik> braunr: not sure what you are getting at. of course we should use
-      some kind of continuations in the Hurd instead of having an active thread
-      for every single request in flight -- but that's not something that could
-      be done easily...
-    <braunr> antrik: oh no, i don't want to use continuations at all
-    <braunr> i just want to use less threads :)
-    <braunr> my panic definitely looks like a thread storm
-    <braunr> i guess increasing the kmem_map will help for the time bein
-    <braunr> g
-    <braunr> (it's not the whole kernel space that gets filled up actually)
-    <braunr> also, stacks are kept on a local cache until there is memory
-      pressure oO
-    <braunr> their slab cache can fill the backing map before there is any
-      pressure
-    <braunr> and it makes a two level cache, i'll have to remove that
-    <antrik> well, how do you reduce the number of threads? apart from
-      optimising scheduling (so requests are more likely to be completed before
-      new ones are handled), the only way to reduce the number of threads is to
-      avoid having a thread per request
-    <braunr> exactly
-    <antrik> so instead the state of each request being handled has to be
-      explicitly stored...
-    <antrik> i.e. continuations
-    <braunr> hm actually, no
-    <braunr> you use thread migration :)
-    <braunr> i don't want to artificially use the number of kernel threads
-    <braunr> the hurd should be revamped not to use that many threads
-    <braunr> but it looks like a hard task
-    <antrik> well, thread migration would reduce the global number of threads
-      in the system... it wouldn't prevent a server from having thousands of
-      threads
-    <braunr> threads would allready be allocated before getting in the server
-    <antrik> again, the only way not to use a thread for each outstanding
-      request is having some explicit request state management,
-      i.e. continuations
-    <braunr> hm right
-    <braunr> but we can nonetheless reduce the number of threads
-    <braunr> i wonder if the sync threads are created on behalf of the pagers
-      or the kernel
-    <braunr> one good thing is that i can already feel better performance
-      without using the host cache until the panic happens
-    <antrik> the tricky bit about that is that I/O can basically happen at any
-      point during handling a request, by hitting a page fault. so we need to
-      be able to continue with some other request at any point...
-    <braunr> yes
-    <antrik> actually, readahead should help a lot in reducing the number of
-      request and thus threads... still will be quite a lot though
-    <braunr> we should have a bunch of pageout threads handling requests
-      asynchronously
-    <braunr> it depends on the implementation
-    <braunr> consider readahead detects that, in the next 10 pages, 3 are not
-      resident, then 1 is, then 3 aren't, then 1 is again, and the last two
-      aren't
-    <braunr> how is this solved ? :)
-    <braunr> about the stack allocation issue, i actually think it's very
-      simple to solv
-    <braunr> the code is a remnant of the old BSD days, when processes were
-      heavily swapped
-    <braunr> so when a thread is created, its stack isn't allocated
-    <braunr> the allocation happens when the thread is dispatched, and the
-      scheduler finds it's swapped (which is the initial state)
-    <braunr> the stack is allocated, and the operation is assumed to succeed,
-      which is why failure produces a panic
-    <antrik> well, actually, not just readahead... clustered paging in
-      general. the thread storms happen mostly on write not read AIUI
-    <braunr> changing that to allocate at thread creation time will allow a
-      cleaner error handling
-    <braunr> antrik: yes, at writeback
-    <braunr> antrik: so i guess even when some physical pages are already
-      present, we should aim at larger sizes for fewer I/O requests
-    <antrik> not sure that would be worthwhile... probably doesn't happen all
-      that often. and if some of the pages are dirty, we would have to make
-      sure that they are ignored although they were part of the request...
-    <braunr> yes
-    <braunr> so one request per missing area ?
-    <antrik> the opposite might be a good idea though -- if every other page is
-      dirty, it *might* indeed be preferable to do a single request rewriting
-      even the clean ones in between...
-    <braunr> yes
-    <braunr> i personally think one request, then replace only what was
-      missing, is simpler and preferable
-    <antrik> OTOH, rewriting clean pages might considerably increase write time
-      (and wear) on SSDs
-    <braunr> why ?
-    <antrik> I doubt the controller is smart enough to recognies if a page
-      doesn't really need rewriting
-    <antrik> so it will actually allocate and write a new cluster
-    <braunr> no but it won't spread writes on different internal sectors, will
-      it ?
-    <braunr> sectors are usually really big
-    <antrik> "sectors" is not a term used in SSDs :-)
-    <braunr> they'll be erased completely whatever the amount of data at some
-      point if i'm right
-    <braunr> ah
-    <braunr> need to learn more about that
-    <braunr> i thought their internal hardware was much like nand flash
-    <antrik> admittedly I don't remember the correct terminology either...
-    <antrik> they *are* NAND flash
-    <antrik> writing is actually not the problem -- it can happen in small
-      chunks. the problem is erasing, which is only possible in large blocks
-    <braunr> yes
-    <braunr> so having larger requests doesn't seem like a problem to me
-    <braunr> because of that
-    <antrik> thus smart controllers (which pretty much all SSD nowadays have,
-      and apparently even SD cards) do not actually overwrite. instead, writes
-      always happen to clean portions, and erasing only happens when a block is
-      mostly clean
-    <antrik> (after relocating the remaining used parts to other clean areas)
-    <antrik> braunr: the problem is not having larger requests. the problem is
-      rewriting clusters that don't really need rewriting. it means the dist
-      performs unnecessary writing actions.
-    <antrik> it doesn't hurt for magnetic disks, as the head has to pass over
-      the unchanged sectors anyways; and rewriting the unnecessarily doesn't
-      increase wear
-    <antrik> but it's different for SSDs
-    <antrik> each write has a penalty there
-    <braunr> i thought only erases were the real penalty
-    <antrik> well, erase happens in the background with modern controllers; so
-      it has no direct penalty. the write has a direct performance penalty when
-      saturating the bandwith, and always has a direct wear penalty
-    <braunr> can't controllers handle 32k requests ? like everything does ? :/
-    <antrik> sure they can. but that's beside the point...
-    <braunr> if they do, they won't mind the clean data inside such large
-      blocks
-    <antrik> apparently we are talking past each other
-    <braunr> i must be missing something important about SSD
-    <antrik> braunr: the point is, the controller doesn't *know* it's clean
-      data; so it will actually write it just like the really unclean data
-    <braunr> yes
-    <braunr> and it will choose an already clean sector for that (previously
-      erased), so writing larger blocks shouldn't hurt
-    <braunr> there will be a slight increase in bandwidth usage, but that's
-      pretty much all of it
-    <braunr> isn't it ?
-    <antrik> well, writing always happens to clean blocks. but writing more
-      blocks obviously needs more time, and causes more wear...
-    <braunr> aiui, blocks are always far larger than the amount of pages we
-      want to writeback in one request
-    <braunr> the only way to use more than one is crossing a boundary
-    <antrik> no. again, the blocks that can be *written* are actually quite
-      small. IIRC most SSDs use 4k nowadays
-    <braunr> ok
-    <antrik> only erasing operates on much larger blocks
-    <braunr> so writing is a problem too
-    <braunr> i didn't think it would cause wear leveling to happen
-    <antrik> well, I'm not sure whether the wear actually happens on write or
-      on erase... but that doesn't matter, as the number of blocks that need to
-      be erased is equivalent to the number of blocks written...
-    <braunr> sorry, i'm really not sure
-    <braunr> if you erase one sector, then write the first and third block,
-      it's clearly not equivalent
-    <braunr> i mean
-    <braunr> let's consider two kinds of pageout requests
-    <braunr> 1/ a big one including clean pages
-    <braunr> 2/ several ones for dirty pages only
-    <braunr> let's assume they both need an erase when they happen
-    <braunr> what's the actual difference between them ?
-    <braunr> wear will increase only if the controller handle it on writes, if
-      i'm right
-    <braunr> but other than that, it's just bandwidth
-    <antrik> strictly speaking erase is only *necessary* when there are no
-      clean blocks anymore. but modern controllers will try to perform erase of
-      unused blocks in the background, so it doesn't delay actual writes
-    <braunr> i agree on that
-    <antrik> but the point is that for each 16 pages (or so) written, we need
-      to erase one block so we get 16 clean pages to write...
-    <braunr> yes
-    <braunr> which is about the size of a request for the sequential policy
-    <braunr> so it fits
-    <antrik> just to be clear: it doesn't matter at all how the pages
-      "fit". the controller will reallocate them anyways
-    <antrik> what matters is how many pages you write
-    <braunr> ah
-    <braunr> i thought it would just put the whole request in a single sector
-      (or two)
-    <antrik> I'm not sure what you mean by "sector". as I said, it's not a term
-      used in SSD technology
-    <braunr> so do you imply that writes can actually get spread over different
-      sectors ?
-    <braunr> the sector is the unit at the nand flash level, its size is the
-      erase size
-    <antrik> actually, I used the right terminology... the erase unit is the
-      block; the write unit is the page
-    <braunr> sector is a synonym of block
-    <antrik> never seen it. and it's very confusing, as it isn't in any way
-      similar to sectors in magnetic disks...
-    <braunr> http://en.wikipedia.org/wiki/Flash_memory#NAND_flash
-    <braunr> it's actually in the NOR part right before, paragraph "Erasing"
-    <braunr> "Modern NOR flash memory chips are divided into erase segments
-      (often called blocks or sectors)."
-    <antrik> ah. I skipped the NOR part :-)
-    <braunr> i've only heard sector where i worked, but i don't consider french
-      computer engineers to be authorities on the matter :)
-    <antrik> hehe
-    <braunr> let's call them block
-    <braunr> so, thread stacks are allocated out of the kernel map
-    <braunr> this is already a bad thing (which is probably why there is a
-      local cache btw)
-    <antrik> anyways, yes. modern controllers might split a contiguous write
-      request onto several blocks, as well as put writes to completely
-      different logical pages into one block. the association between addresses
-      and actual blocks is completely free
-    <braunr> now i wonder why the kernel map is so slow, as the panic happens
-      at about 3k threads, so about 11M of thread stacks
-    <braunr> antrik: ok
-    <braunr> antrik: well then it makes sense to send only dirty pages
-    <braunr> s/slow/low/
-    <antrik> it's different for raw flash (using MTD subsystem in Linux) -- but
-      I don't think this is something we should consider any time soon :-)
-    <antrik> (also, raw flash is only really usable with specialised
-      filesystems anyways)
-    <braunr> yes
-    <antrik> are the thread stacks really only 4k? I would expect them to be
-      larger in many cases...
-    <braunr> youpi reduced them some time ago, yes
-    <braunr> they're 4k on xen
-    <braunr> uh, 16k
-    <braunr> damn, i'm wondering why i created separate submaps for the slab
-      allocator :/
-    <braunr> probably because that's how it was done by the zone allocator
-      before
-    <braunr> but that's stupid :/
-    <braunr> hm the stack issue is actually more complicated than i thought
-      because of interrupt priority levels
-    <braunr> i increased the kernel map size to avoid the panic instead
-    <braunr> now libc0.3 seems to build fine
-    <braunr> and there seems to be a clear decrease of I/O :)
-
-
-### IRC, freenode, #hurd, 2012-07-06
-
-    <antrik> braunr: there is a submap for the slab allocator? that's strange
-      indeed. I know we talked about this; and I am pretty sure we agreed
-      removing the submap would actually be among the major benefits of a new
-      allocator...
-    <braunr> antrik: a submap is a good idea anyway
-    <braunr> antrik: it avoids fragmenting the kernel space too much
-    <braunr> it also breaks down locking
-    <braunr> but we could consider it
-    <braunr> as a first step, i'll merge the kmem and kalloc submaps (the ones
-      used for the slab caches and the malloc-like allocations respectively)
-    <braunr> then i'll change the allocation of thread stacks to use a slab
-      cache
-    <braunr> and i'll also remove the thread swapping stuff
-    <braunr> it will take some time, but by the end we should be able to
-      allocate tens of thousands of threads, and suffer no panic when the limit
-      is reached
-    <antrik> braunr: I'm not sure "no panic" is really a worthwhile goal in
-      such a situation...
-    <braunr> antrik: uh ?N
-    <braunr> antrik: it only means the system won't allow the creation of
-      threads until there is memory available
-    <braunr> from my pov, the microkernel should never fail up to a point it
-      can't continue its job
-    <antrik> braunr: the system won't be able to recover from such a situation
-      anyways. without actual resource management/priorisation, not having a
-      panic is not really helpful. it only makes it harder to guess what
-      happened I fear...
-    <braunr> i don't see why it couldn't recover :/
-
-
-## IRC, freenode, #hurd, 2012-07-07
-
-    <braunr> grmbl, there are a lot of issues with making the page cache larger
-      :(
-    <braunr> it actually makes the system slower in half of my tests
-    <braunr> we have to test that on real hardware
-    <braunr> unfortunately my current results seem to indicate there is no
-      clear benefit from my patch
-    <braunr> the current limit of 4000 objects creates a good balance between
-      I/O and cpu time
-    <braunr> with the previous limit of 200, I/O is often extreme
-    <braunr> with my patch, either the working set is less than 4k objects, so
-      nothing is gained, or the lack of scalability of various parts of the
-      system add overhead that affect processing speed
-    <braunr> also, our file systems are cached, but our block layer isn't
-    <braunr> which means even when accessing data from the cache, accesses
-      still cause some I/O for metadata
-
-
-## IRC, freenode, #hurd, 2012-07-08
-
-    <braunr> youpi: basically, it works fine, but exposes scalability issues,
-      and increases swapiness
-    <youpi> so it doens't help with stability?
-    <braunr> hum, that was never the goal :)
-    <braunr> the goal was to reduce I/O, and increase performance
-    <youpi> sure
-    <youpi> but does it at least not lower stability too much?
-    <braunr> not too much, no
-    <youpi> k
-    <braunr> most of the issues i found could be reproduced without the patch
-    <youpi> ah
-    <youpi> then fine :)
-    <braunr> random deadlocks on heavy loads
-    <braunr> youpi: but i'm not sure it helps with performance
-    <braunr> youpi: at least not when emulated, and the host cache is used
-    <youpi> that's not very surprising
-    <braunr> it does help a lot when there is no host cache and the working set
-      is greater (or far less) than 4k objects
-    <youpi> ok
-    <braunr> the amount of vm_object and ipc_port is gracefully adjusted
-    <youpi> that'd help us with not having to tell people to use the complex
-      -drive option :)
-
-([[hurd/running/qemu/writeback_caching]].)
-
-    <braunr> so you can easily run a hurd with 128 MiB with decent performance
-      and no leak in ext2fs
-    <braunr> yes
-    <braunr> for example
-    <youpi> braunr: I'd say we should just try it on buildds
-    <braunr> (it's not finished yet, i'd like to work more on reducing
-      swapping)
-    <youpi> (though they're really not busy atm, so the stability change can't
-      really be measured)
-    <braunr> when building the hurd, which takes about 10 minutes in my kvm
-      instances, there is only a 30 seconds difference between using the host
-      cache and not using it
-    <braunr> this is already the case with the current kernel, since the
-      working set is less than 4k objects
-    <braunr> while with the previous limit of 200 objects, it took 50 minutes
-      without host cache, and 15 with it
-    <braunr> so it's a clear benefit for most uses, except my virtual machines
-      :)
-    <youpi> heh
-    <braunr> because there, the amount of ram means a lot of objects can be
-      cached, and i can measure an increase in cpu usage
-    <braunr> slight, but present
-    <braunr> youpi: isn't it a good thing that buildds are resting a bit ? :)
-    <youpi> on one hand, yes
-    <youpi> but on the other hand, that doesn't permit to continue
-      stress-testing the Hurd :)
-    <braunr> we're not in a hurry for this patch
-    <braunr> because using it really means you're tickling the pageout daemon a
-      lot :)
-
-
-## [[metadata_caching]]
-
-
-## IRC, freenode, #hurd, 2012-07-12
-
-    <braunr> i'm only adding a cached pages count you know :)
-    <braunr> (well actually, this is now a vm_stats call that can replace
-      vm_statistics, and uses flavors similar to task_info)
-    <braunr> my goal being to see that yellow bar in htop
-    <braunr> ... :)
-    <pinotree> yellow?
-    <braunr> yes, yellow
-    <braunr> as in http://www.sceen.net/~rbraun/htop.png
-    <pinotree> ah
-
-
-## IRC, freenode, #hurd, 2012-07-13
-
-    <braunr> i always get a "no more room for vm_map_enter" error when building
-      glibc :/
-    <braunr> but the build continues, probably a failed test
-    <braunr> ah yes, i can see the yellow bar :>
-    <antrik> braunr: congrats :-)
-    <braunr> antrik: thanks
-    <braunr> but i think my patch can't make it into the git repo until the
-      swap deadlock is solved (or at least very infrequent ..)
-
-[[libpager_deadlock]].
-
-    <braunr> well, the page cache accounting tells me something is wrong there
-      too lol
-    <braunr> during a build 112M of data was created, of which only 28M made it
-      into the cache
-    <braunr> which may imply something is still holding references on the
-      others objects (shadow objects hold references to their underlying
-      object, which could explain this)
-    <braunr> ok i'm stupid, i just forgot to subtract the cached pages from the
-      used pages .. :>
-    <braunr> (hm, actually i'm tired, i don't think this should be done)
-    <braunr> ahh yes much better
-    <braunr> i simply forgot to convert pages in kilobytes .... :>
-    <braunr> with the fix, the accounting of cached files is perfect :)
-
-
-## IRC, freenode, #hurd, 2012-07-14
-
-    <youpi> braunr: btw, if you want to stress big builds, you might want to
-      try webkit, ppl, rquantlib, rheolef, yade
-    <youpi> they don't pass on bach (1.3GiB), but do on ironforge (1.8GiB)
-    <braunr> youpi: i don't need to, i already know my patch triggers swap
-      deadlocks more often, which was expected
-    <youpi> k
-    <braunr> there are 3 tasks concerning my work : 1/ page cache accounting
-      (i'm sending the patch right now) 2/ removing the fixed limit and 3/
-      hunting the swap deadlock and fixing as much as possible
-    <braunr> 2/ can't get in the repository without 3/ imo
-    <youpi> btw, the increase of PAGE_FREE_* in your 2/ could go already,
-      couldn't it?
-    <braunr> yes
-    <braunr> but we should test with higher thresholds
-    <braunr> well
-    <braunr> it really depends on the usage pattern :/
-
-
-## [[ext2fs_libports_reference_counting_assertion]]
-
-
-## IRC, freenode, #hurd, 2012-07-15
-
-    <braunr> concerning the page cache patch, i've been using for quite some
-      time now, did lots of builds with it, and i actually wonder if it hurts
-      stability as much as i think
-    <braunr> considering i didn't stress the system as much before
-    <braunr> and it really improves performance
-
-    <braunr> cached memobjs:   138606
-    <braunr> cache:             1138M
-    <braunr> i bet ext2fs can have a hard time scanning 138k entries in a
-      linked list, using callback functions on each of them :x
-
-
-
-## IRC, freenode, #hurd, 2012-07-16
-
-    <tschwinge> braunr: Sorry that I didn't have better results to present.
-      :-/
-    <braunr> eh, that was expected :)
-    <braunr> my biggest problem is the hurd itself :/
-    <braunr> for my patch to be useful (and the rest of the intended work), the
-      hurd needs some serious fixing
-    <braunr> not syncing from the pagers
-    <braunr> and scalable algorithms everywhere of course
-
-
-## IRC, freenode, #hurd, 2012-07-23
-
-    <braunr> youpi: FYI, the branches rbraun/page_cache in the gnupach and hurd
-      repos are ready to be merged after review
-    <braunr> gnumach*
-    <youpi> so you fixed the hangs & such?
-    <braunr> they only the cache stats, not the "improved" cache
-    <braunr> no
-    <braunr> it requires much more work for that :)
-    <youpi> braunr: my concern is that the tests on buildds show stability
-      regression
-    <braunr> youpi: tschwinge also reported performance degradation
-    <braunr> and not the minor kind
-    <youpi> uh
-    <tschwinge> :-/
-    <braunr> far less pageins, but twice as many pageouts, and probably high
-      cpu overhead
-    <braunr> building (which is what buildds do) means lots of small files
-    <braunr> so lots of objects
-    <braunr> huge lists, long scans, etc..
-    <braunr> so it definitely requires more work
-    <braunr> the stability issue comes first in mind, and i don't see a way to
-      obtain a usable trace
-    <braunr> do you ?
-    <youpi> nope
-    <braunr> (except making it loop forever instead of calling assert() and
-      attach gdb to a qemu instance)
-    <braunr> youpi: if you think the infinite loop trick is ok, we could
-      proceed with that
-    <youpi> which assert?
-    <braunr> the port refs one
-    <youpi> which one?
-    <braunr> whicih prevented you from using the page cache patch on buildds
-    <youpi> ah, the libports one
-    <youpi> for that one, I'd tend to take the time to perhaps use coccicheck
-      actually
-
-[[code_analysis]].
-
-    <braunr> oh
-    <youpi> it's one of those which is supposed to be statically ananyzable
-    <youpi> s/n/l
-    <braunr> that would be great
-    <tschwinge> :-)
-    <tschwinge> And set precedence.
-
-
-# IRC, freenode, #hurd, 2012-07-26
-
-    <braunr> hm i killed darnassus, probably the page cache patch again
-
-
-# IRC, freenode, #hurd, 2012-09-19
-
-    <youpi> I was wondering about the page cache information structure
-    <youpi> I guess the idea is that if we need to add a field, we'll just
-      define another RPC?
-    <youpi> braunr: ↑
-    <braunr> i've done that already, yes
-    <braunr> youpi: have a look at the rbraun/page_cache gnumach branch
-    <youpi> that's what I was referring to
-    <braunr> ok
-
-
-# IRC, freenode, #hurd, 2013-01-15
-
-    <braunr> hm, no wonder the page cache patch reduced performance so much
-    <braunr> the page cache when building even moderately large packages is
-      about a few dozens MiB (around 50)
-    <braunr> the patch enlarged it to several hundreds :/
-    <ArneBab> braunr: so the big page cache essentially killed memory locality?
-    <braunr> ArneBab: no, it made ext2fs crazy (disk translators - used as
-      pagers - scan their cached pages every 5 seconds to flush the dirty ones)
-    <braunr> you can imagine what happens if scanning and flushing a lot of
-      pages takes more than 5 seconds
-    <ArneBab> ouch… that’s heavy, yes
-    <ArneBab> I already see it pile up in my mindb 
-    <braunr> and it's completely linear, using a lock to protect the whole list
-    <braunr> darnassus is currently showing such a behaviour, because tschwinge
-      is linking huge files (one object with lots of pages)
-    <braunr> 446 MB of swap used, between 200 and 1850 MiB of RAM used, and i
-      can still use vim and build stuff without being too disturbed
-    <braunr> the system does feel laggy, but there has been great stability
-      improvements
-    <braunr> have*
-    <braunr> and even if laggy, it doesn't feel much more than the usual lag of
-      a network (ssh) based session
-
-
-# IRC, freenode, #hurd, 2013-10-08
-
-    <braunr> hmm i have to change what gnumach reports as being cached memory
-
-
-## IRC, freenode, #hurd, 2013-10-09
-
-    <braunr> mhmm, i'm able to copy files as big as 256M while building debian
-      packages, using a gnumach kernel patched for maximum memory usage in the
-      page cache
-    <braunr> just because i used --sync=30 in ext2fs
-    <braunr> a bit of swapping (around 40M), no deadlock yet
-    <braunr> gitweb is a bit slow but that's about it
-    <braunr> that's quite impressive
-    <braunr> i suspect thread storms might not even be the cataclysmic event
-      that we thought it was
-    <braunr> the true problem might simply be parallel fs synces
-
-
-## IRC, freenode, #hurd, 2013-10-10
-
-    <braunr> even with the page cache patch, memory filled, swap used, and lots
-      of cached objects (over 200k), darnassus is impressively resilient
-    <braunr> i really wonder whether we fixed ext2fs deadlock
-
-    <braunr> youpi: fyi, darnassus is currently running a patched gnumach with
-      the vm cache changes, in hope of reproducing the assertion errors we had
-      in the past
-    <braunr> i increased the sync interval of ext2fs to 30s like we discussed a
-      few months back
-    <braunr> and for now, it has been very resilient, failing only because of
-      the lack of kernel map entries after several heavy package builds
-    <gg0> wait the latter wasn't a deadlock it resumed after 1363.06 s
-    <braunr> gg0: thread storms can sometimes (rarely) fade and let the system
-      resume "normally"
-    <braunr> which is why i increased the sync interval to 30s, this leaves
-      time between two intervals for normal operations
-    <braunr> otherwise writebacks are queued one after the other, and never
-      processed fast enough for that queue to become empty again (except
-      rarely)
-    <braunr> youpi: i think we should consider applying at least the sync
-      interval to exodar, since many DDs are just unaware of the potential
-      problems with large IOs
-    <youpi> sure
-
-    <braunr> 222k cached objects (1G of cached memory) and darnassus is still
-      kicking :)
-    <braunr> youpi: those lock fixing patches your colleague sent last year
-      must have helped somewhere
-    <youpi> :)
-
-
-## IRC, freenode, #hurd, 2013-10-13
-
-    <youpi> braunr: how are your tests going with the object cache?
-    <braunr> youpi: not so good
-    <braunr> youpi: it failed after 2 days of straight building without a
-      single error output :/
diff --git a/open_issues/gnumach_panic_thread_dispatch.mdwn b/open_issues/gnumach_panic_thread_dispatch.mdwn
deleted file mode 100644
index db094f2f..00000000
--- a/open_issues/gnumach_panic_thread_dispatch.mdwn
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!meta copyright="Copyright © 2013 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_gnumach]]
-
-
-# IRC, freenode, #hurd, 2013-02-10
-
-    <youpi> panic: thread_dispatch: thread a958c950 has unexpected state 114
-    <youpi> hum ):
-    <braunr> ouch
-    <youpi> during a perl build
-    <braunr> TH_SWAPPED | TH_HALTED | TH_RUN
diff --git a/open_issues/gnumach_rpc_timeouts.mdwn b/open_issues/gnumach_rpc_timeouts.mdwn
deleted file mode 100644
index 68cfcb5a..00000000
--- a/open_issues/gnumach_rpc_timeouts.mdwn
+++ /dev/null
@@ -1,19 +0,0 @@
-[[!meta copyright="Copyright © 2012 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_gnumach]]
-
-
-# IRC, freenode, #hurd, 2012-04-28
-
-    <pinotree> uhm, apparently mach cannot handle timeouts for rpc's of more
-      than (2^(sizeof(mach_msg_timeout_t) * 8) - 1) / HZ
-    <pinotree> it seems that how ticks are calculated in mach, it becomes 0
-    <pinotree> +because of
diff --git a/open_issues/gnumach_tick.mdwn b/open_issues/gnumach_tick.mdwn
deleted file mode 100644
index f29df6de..00000000
--- a/open_issues/gnumach_tick.mdwn
+++ /dev/null
@@ -1,38 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 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_gnumach]]
-
-
-# IRC, freenode, #hurd, 2012-07-05
-
-    <pinotree> braunr: wrt to mach: it seems to me it ticks every 10ms or so,
-      it is true?
-    <braunr> yes
-    <braunr> and it's not preemptible
-
-[[microkernel/mach/gnumach/preemption]].
-
-    <pinotree> braunr: that means a gnumach kernel currently has a maximum
-      uptime of almost 500 days
-    <braunr> pinotree: what do you mean ?
-    <pinotree> there's an int (or uint, i don't remember) variable that keeps
-      the tick count
-    <braunr> yes the tick variable should probably be a 64-bits type
-    <braunr> or a struct
-    <braunr> but the tick count should only be used for computation on "short"
-      delays
-    <braunr> and it should be safe to use it even when it overflows
-    <braunr> it's not the wall clock
-    <pinotree> i found that when investigating why the maximum timeout for a
-      mach_msg is like INT_MAX >> 2 (or 4) or something like that, also due to
-      the tick count
-    <braunr> iirc, in linux, they mostly use the lower 32-bits on 32-bits
-      architecture, updating the 32 upper only when necessary
diff --git a/open_issues/gnumach_tlb_flushing.mdwn b/open_issues/gnumach_tlb_flushing.mdwn
deleted file mode 100644
index 45d0730d..00000000
--- a/open_issues/gnumach_tlb_flushing.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_gnumach]]
-
-IRC, unknown channel, unknown date.
-
-    <tschwinge> gianluca, youpi: Why the value 32 for the TLB flushing decision, by the way?
-    <youpi> completely arbitrary
-    <tschwinge> I thought whether that might perhaps be worth a macro definition with a comment?
-    <verte> what's the typical TLB size these days?
-    <youpi> tschwinge: right
-    <youpi> note that the 32 value would be probably different between native and xen
-    <gianluca> tschwinge: just arbitrary
diff --git a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn
deleted file mode 100644
index 7739f4d1..00000000
--- a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn
+++ /dev/null
@@ -1,202 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012 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_gnumach]]
-
-
-# IRC, freenode, #hurd, 2011-07-20
-
-    <braunr> could we add gnumach forward map entry merging as an open issue ?
-    <braunr> probably hurting anything using bash extensively, like build most
-      build systems
-    <braunr> mcsim: this map entry merging problem might interest you
-    <braunr> tschwinge: see vm/vm_map.c, line ~905
-    <braunr> "See whether we can avoid creating a new entry (and object) by
-      extending one of our neighbors.  [So far, we only attempt to extend from
-      below.]"
-    <braunr> and also vm_object_coalesce
-    <braunr> "NOTE:   Only works at the moment if the second object is NULL -
-      if it's not, which object do we lock first?"
-    <braunr> although map entry merging should be enough
-    <braunr> this seems to be the cause for bash having between 400 and 1000+
-      map entries
-    <braunr> thi makes allocations and faults slow, and forks even more
-    <braunr> but again, this should be checked before attempting anything
-    <braunr> (for example, this comment still exists in freebsd, although they
-      solved the problem, so who knows)
-    <antrik> braunr: what exactly would you want to check?
-    <antrik> braunr: this rather sounds like something you would just have to
-      try...
-    <braunr> antrik: that map merging is actually incomplete
-    <braunr> and that entries can actually be merged
-    <antrik> hm, I see...
-    <braunr> (i.e. they are adjacent and have compatible properties
-    <braunr> )
-    <braunr> antrik: i just want to avoid the "hey, splay trees mak fork slow,
-      let's work on it for a month to see it wasn't the problem"
-    <antrik> so basically you need a dump of a task's map to check whether
-      there are indeed entries that could/should be merged?
-    <antrik> hehe :-)
-    <braunr> well, vminfo should give that easily, i just didn't take the time
-      to check it
-    <jkoenig> braunr, as you pointed out, "vminfo $$" seems to indicate that
-      merging _is_ incomplete.
-    <braunr> this could actually have a noticeable impact on package builds
-    <braunr> hm
-    <braunr> the number of entries for instances of bash running scripts don't
-      exceed 50-55 :/
-    <braunr> the issue seems to affect only certain instances (login shells,
-      and su -)
-    <braunr> jkoenig: i guess dash is just much lighter than bash in many ways
-      :)
-    <jkoenig> braunr, the number seems to increase with usage (100 here for a
-      newly started interactive shell, vs. 150 in an old one)
-    <braunr> yes, merging is far from complete in the vm_map code
-    <braunr> it only handles null objects (private zeroed memory), and only
-      tries to extend a previous entry (this isn't even a true merge)
-    <braunr> this works well for the kernel however, which is why there are so
-      few as 25 entries
-    <braunr> but any request, be it e.g. mmap(), or mprotect(), can easily
-      split entries
-    <braunr> making their number larger
-    <jkoenig> my ext2fs has ~6500 entries, but I guess this is related to
-      mapping blocks from the filesystem, right?
-    <braunr> i think so
-    <braunr> hm not sure actually
-    <braunr> i'd say it's fragmentation due to copy on writes when client have
-      mapped memory from it
-    <braunr> there aren't that many file mappings though :(
-    <braunr> jkoenig: this might just be the same problem as in bash
-    <braunr>  0x1308000[0x3000] (prot=RW, max_prot=RWX, mem_obj=584)
-    <braunr>  0x130b000[0x6000] (prot=RW, max_prot=RWX, mem_obj=585)
-    <braunr>  0x1311000[0x3000] (prot=RX, max_prot=RWX, mem_obj=586)
-    <braunr>  0x1314000[0x1000] (prot=RW, max_prot=RWX, mem_obj=586)
-    <braunr>  0x1315000[0x2000] (prot=RX, max_prot=RWX, mem_obj=587)
-    <braunr> the first two could be merged but not the others
-    <jkoenig> theoritically, those may correspond to memory objects backed by
-      different portions of the disk, right?
-    <braunr> jkoenig: this looks very much like the same issue (many private
-      mappings not merged)
-    <braunr> jkoenig: i'm not sure
-    <braunr> jkoenig: normally there is an offset when the object is valid
-    <braunr> but vminfo may simply not display it if 0
-    * jkoenig goes read about memory object
-    <braunr> ok, vminfo can't actually tell if the object is anonymous or
-      file-backed memory
-    <jkoenig> (I'm perplexed about how the kernel can merge two memory objects
-      if disctinct port names exist in the tasks' name space -- that's what
-      mem_obj is, right?)
-    <braunr> i don't see why
-    <braunr> jkoenig: can you be more specific ?
-    <jkoenig> braunr, if, say, 584 and 585 above are port names which the task
-      expects to be able to access and do stuff with, what will happen to them
-      when the memory objects are merged?
-    <braunr> good question
-    <braunr> but hm
-    <braunr> no it's not really a problem
-    <braunr> memory objects aren't directly handled by the vm system
-    <braunr> vm_object and memory_object are different things
-    <braunr> vm_objects can be split and merged
-    <braunr> and shadow objects form chains ending on a final vm_object
-    <braunr> which references a memory object
-    <braunr> hm
-    <braunr> jkoenig: ok no solution, they can't be merged :)
-    <jkoenig> braunr, I'm confused :-)
-    <braunr> jkoenig: but at least, if two vm_objects are created but reference
-      the same externel memory object, the vm should be able to merge them back
-    <braunr> external*
-    <braunr> are created as a result of a split
-    <braunr> say, you map a memory object, mprotect part of it (=split), then
-      mprotect the reste of it (=merge), it should work
-    <braunr> jkoenig: does that clarify things a bit ?
-    <jkoenig> ok so if I get it right, the entries shown by vmstat are the
-      vm_object, and the mem_obj listed is a send right to the memory object
-      they're referencing ?
-    <braunr> yes
-    <braunr> i'm not sure about the type of the integer showed (port name or
-      simply an index)
-    <braunr> jkoenig: another possibility explaining the high number of entries
-      is how anonymous memory is implemented
-    <braunr> if every vm_allocate request implies the creation of a memory
-      object from the default pager
-    <braunr> the vm has no way to merge them
-    <jkoenig> and a vm_object is not a capability, but just an internal kernel
-      structure used to record the composition of the address space
-    <braunr> jkoenig: not exactly the address space, but close enough
-    <braunr> jkoenig: it's a container used to know what's in physical memory
-      and what isn't
-    <jkoenig> braunr, ok I think I'm starting to get it, thanks.
-    <braunr> glad i could help
-    <braunr> i wonder when vm_map_enter() gets null objects though :/
-    <braunr> "If this port is MEMORY_OBJECT_NULL, then zero-filled memory is
-      allocated instead"
-    <braunr> which means vm_allocate()
-    <jkoenig> braunr, when the task uses vm_allocate(), or maybe vm_map_enter()
-      with MEMORY_OBJECT_NULL, there's an opportunity to extend an existing
-      object though, is that what you referred to earlier ?
-    <braunr> jkoenig: yes, and that's what is done
-    <jkoenig> but how does that play out with the default pager? (I'm thinking
-      aloud, as always feel free to ignore ;-)
-    <braunr> the default pager backs vm_objects providing zero filled memory
-    <braunr> hm, guess it wasn't your question
-    <braunr> well, swap isn't like a file, pages can be placed dynamically,
-      which is why the offset is always 0 for this type of memory
-    <jkoenig> hmm I see, apparently a memory object does not have a size
-    <braunr> are you sure ?
-    <jkoenig> from what I can gather from
-      http://www.gnu.org/software/hurd/gnumach-doc/External-Memory-Management.html,
-      but I looked very quickly
-    <braunr> vm_objects have a size
-    <braunr> and each map entry recors the offset within the object where the
-      mapping begins
-    <braunr> offset and sizes are used by the kernel when querying the memory
-      object pager
-    <braunr> see memory_object_data_request for example
-    <jkoenig> right.
-    <braunr> but the default pager has another interface
-    <braunr> jkoenig: after some simple tests, i haven't seen a simple case
-      where forward merging could be applied :(
-    <braunr> which means it's a lot harder than it first looked
-    <braunr> hm
-    <braunr> actually, there seems to be cases where this can be done
-    <braunr> all of them occurring after a first merge was done
-    <braunr> (which means a mapping request perfectly fits between two map
-      entries)
-
-
-# IRC, freenode, #hurd, 2011-07-21
-
-    <braunr> tschwinge: you may remove the forward map entry merging issue :/
-    <pinotree> what did you discover?
-    <braunr> tschwinge: it's actually much more complicated than i thought, and
-      needs major changes in the vm, and about the way anonymous memory is
-      handled
-    <braunr> from what i could see, part of the problem still exists in freebsd
-    <braunr> for the same reasons (shadow objects being one of them)
-
-[[mach_shadow_objects]].
-
-
-# GCC build time using bash vs. dash
-
-<http://gcc.gnu.org/ml/gcc/2011-07/msg00444.html>
-
-
-# Procedure
-
-  * Analyze.
-
-  * Measure.
-
-  * Fix.
-
-  * Measure again.
-
-  * Have Samuel measure on the buildd.
diff --git a/open_issues/gnumach_vm_map_red-black_trees.mdwn b/open_issues/gnumach_vm_map_red-black_trees.mdwn
deleted file mode 100644
index 53ff66c5..00000000
--- a/open_issues/gnumach_vm_map_red-black_trees.mdwn
+++ /dev/null
@@ -1,346 +0,0 @@
-[[!meta copyright="Copyright © 2012 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_gnumach]]
-
-
-# IRC, freenode, #hurd, 2012-04-23
-
-    <braunr> btw, i'm running a gnumach version using red-black trees for vm
-      map entries
-    <antrik> braunr: sounds fashionable ;-)
-    <youpi> braunr: with some perf improvement?
-    <braunr> looks promising for our ext2fs instances showing several thousands
-      of map entries
-    <braunr> youpi: i'm not using it for lookups yet
-    <braunr> but the tree is there, maintained, used for both regular and copy
-      maps, and it doesn't crash
-    <youpi> good :)
-    <braunr> antrik: isn't it ? :)
-    <braunr> youpi: and the diff stat is like 50/15
-    <antrik> braunr: what's the goal of using the fashionable trees?
-    <braunr> antrik: speeding up lookups in address spaces
-    <antrik> braunr: so the idea is that if we have a heavily fragmented
-      address space, the performance penalty is smaller?
-    <braunr> yes
-    <antrik> OK
-    <antrik> I take it you gave up on attempts to actually decrease
-      fragmentation?...
-    <braunr> it's not as good as reducing fragmentation, which requires
-      implementing a powerful merge, but it's still better
-    <braunr> yes
-    <braunr> it's too messy for my brain :/
-    <antrik> I see
-    <antrik> oh
-    <braunr> it will add some overhead though
-    <youpi> I guess log(n) ?
-    <braunr> but if there is a significant performance gain, it'll be worth it
-    <braunr> yes
-    <braunr> i was more thinking about the memory overhead
-    <antrik> right now it's a linear list?
-    <youpi> I don't think we care nowadays :)
-    <braunr> antrik: yes
-    <antrik> ouch
-    <braunr> antrik: yes ... :>
-    <braunr> the original authors expected vm maps to have like 30 entries
-    <braunr> so they used a list for the maps, and a hash table for the
-      object/offset to physical page lookups
-    <braunr> there is a small lookup cache though, which is a nice optimization
-    <braunr> my code now uses it first, and falls back to the RB tree if the
-      hint didn't help
-    <antrik> braunr: well, don't forget to check whether it actually *is* still
-      an optimisation, when using fashionable trees ;-)
-    <braunr> antrik: i checked that already :)
-    <braunr> i did the same in x15
-    <antrik> I see
-    <braunr> both bsd and linux uses a similar technique
-    <braunr> use*
-    <braunr> (well, bsd actually use what is done in mach :)
-    <antrik> (or perhaps the other way around... ;-) )
-    <braunr> i don't think so, as the bsd vm is really the mach vm
-    <braunr> but we don't care much
-    <antrik> oh, right... that part actually went full circle
-    <braunr> youpi: i have a patch ready for test on machines with significant
-      amounts of map entries (e.g. the buildds ..)
-    <braunr> youpi: i won't have time for tests tonight, are you interested ?
-    <braunr> (i've been running it for 15 minutes without any issue for now)
-    <youpi> I'd say post to the list
-    <braunr> ok
-    <youpi> braunr: your patch uses the rb tree for lookups, right?
-    <youpi> braunr: the buildd using rbtree seems swift
-    <youpi> but maybe it's just a psychologic effect :)
-    <youpi> the chroot ext2fs already has 1392 lines in vminfo
-    <youpi> an rbtree can't hurt  there :)
-    <youpi> braunr: it really seems faster
-    <youpi> the reboot might have helped too
-    <youpi> benchmarks shall say
-    <youpi> for now, I'll just let ironforge use it
-    <antrik> youpi: it's always fast after a reboot ;-)
-    <youpi> sure
-    <youpi> but still
-    <youpi> I mean
-    <youpi> *obviously* the reboot has helped
-    <youpi> but it might not be all
-    <youpi> at least it feels so
-    <youpi> and obviously only benchmarks can say
-    <antrik> the major benefit AIUI is rather that the slowdown happening over
-      time will be less noticable
-
-[[performance/degradation]].
-
-    <youpi> "over time" is actually quite fast
-    <youpi> ext2 fills up very quickly when you build a package
-    <youpi> it went up to 1700 lines very quickly
-    <youpi> and stabilized around there
-    <antrik> yeah, it can be very fast under heavy load
-    <youpi> that's why I say reboot seems not all
-    <youpi> it's already not so fresh
-    <youpi> with 1700 lines in vminfo
-    <antrik> well, I don't know how much of the slowdown I'm experiencing
-      (after doing stuff under memory pressure) is actually related to VM map
-      fragmentation...
-    <antrik> might be all, might be none, might be something in between
-    <youpi> then try his patch
-    <antrik> guess I should play a bit with vminfo...
-    <antrik> well, currently I actually experience pretty little slowdown, as
-      for certain reasons (only indirectly related to the Hurd) I'm not running
-      mutt on this machine, so I don't really have memory pressure...
-
-
-## IRC, freenode, #hurd, 2012-04-24
-
-    <braunr> youpi: yes, it uses bst lookups
-    <braunr> youpi: FYI, the last time i checked, one ext2fs instance had 4k+
-      map entries, and another around 7.5k
-    <braunr> (on ironforge)
-
-
-## IRC, freenode, #hurd, 2012-04-24
-
-    <youpi> braunr: $ sudo vminfo  624 | wc -l
-    <youpi> 22957
-    <youpi> there's no way it can not help :)
-    <braunr> youpi: 23k, that's really huge
-
-
-## IRC, freenode, #hurd, 2012-04-26
-
-    <braunr> youpi: any new numbers wrt the rbtree patch ?
-    <youpi> well, buildd times are not really accurate :)
-    <youpi> but what I can tell is that it managed to build qtwebkit fine
-    <braunr> ok
-    <youpi> so the patch is probably safe :)
-    <braunr> i'll commit it soon then
-    <youpi> I'd say feel free to, yes
-    <braunr> thanks
-
-
-## IRC, freenode, #hurd, 2012-04-27
-
-    <braunr> elmig: don't expect anything grand though, this patch is mostly
-      useful when address spaces get really fragmented, which mainly happens on
-      buildds
-    <braunr> (and it only speeds lookups, which isn't as good as reducing
-      fragmentation; things like fork still have to copy thousands of map
-      entries)
-
-[[glibc/fork]].
-
-
-## IRC, freenode, #hurdfr, 2012-06-02
-
-    <youpi> braunr: oh, un bug de rbtree
-    <youpi> Assertion `diff != 0' failed in file "vm/vm_map.c", line 1002
-    <youpi> c'est dans rbtree_insert()
-    <youpi> vm_map_enter (vm/vm_map.c:1002).
-    <youpi> vm_map (vm/vm_user.c:373).
-    <youpi> syscall_vm_map (kern/ipc_mig.c:657).
-    <youpi> erf j'ai tué mon débuggueur, je ne peux pas inspecter plus
-    <youpi> le peu qui me reste c'est qu'apparemment target_map == 1, size ==
-      0, mask == 0
-    <youpi> anywhere = 1
-    <braunr> youpi: ça signifie sûrement que des adresses overlappent
-    <braunr> je rejetterai un coup d'oeil sur le code demain
-    <braunr> (si ça se trouve c'est un bug rare de la vm, le genre qui fait
-      crasher le noyau)
-    <braunr> (enfin jveux dire, qui faisait crasher le noyau de façon très
-      obscure avant le patch rbtree)
-
-
-### IRC, freenode, #hurd, 2012-07-15
-
-    <bddebian> I get errors in vm_map.c whenever I try to "mount" a CD
-    <bddebian> Hmm, this time it rebooted the machine
-    <bddebian> braunr: The translator set this time and the machine reboots
-      before I can get the full message about vm_map, but here is some of the
-      crap I get:  http://paste.debian.net/179191/
-    <braunr> oh
-    <braunr> nice
-    <braunr> that may be the bug youpi saw with my redblack tree patch
-    <braunr> bddebian: assert(diff != 0); ?
-    <bddebian> Aye
-    <braunr> good
-    <braunr> it means we're trying to insert a vm_map_entry at a region in a
-      map which is already occupied
-    <bddebian> Oh
-    <braunr> and unlike the previous code, the tree actually checks that
-    <braunr> it has to
-    <braunr> so you just simply use the iso9660fs translator and it crashes ?
-    <bddebian> Well it used to on just trying to set the translator.  This time
-      I was able to set the translator but as soon as I cd to the mount point I
-      get all that crap
-    <braunr> that's very good
-    <braunr> more test cases to fix the vm
-
-
-### IRC, freenode, #hurd, 2012-11-01
-
-    <youpi> braunr: Assertion `diff != 0' failed in file "vm/vm_map.c", line
-      1002
-    <youpi> that's in rbtree_insert
-    <braunr> youpi: the problem isn't the tree, it's the map entries
-    <braunr> some must overlap
-    <braunr> if you can inspect that, it would be helpful
-    <youpi> I have a kdb there
-    <youpi> it's within a port_name_to_task system call
-    <braunr> this assertion basically means there already is an item in the
-      tree where the new item is supposed to be inserted
-    <youpi> this port_name_to_task presence in the stack is odd
-    <braunr> it's in vm_map_enter
-    <youpi> there's a vm_map just after that (and the assembly trap code
-      before)
-    <youpi> I know
-    <youpi> I'm wondering about the caller
-    <braunr> do you have a way to inspect the inserted map entry ?
-    <youpi> I'm actually wondering whether I have the right kernel in gdb
-    <braunr> oh
-    <youpi> better
-    <youpi> with the right kernel :)
-    <youpi> 0x80039acf (syscall_vm_map)
-      (target_map=d48b6640,address=d3b63f90,size=0,mask=0,anywhere=1)
-    <youpi> size == 0 seems odd to me
-    <youpi> (same parameters for vm_map)
-    <braunr> right
-    <braunr> my code does assume an entry has a non null size
-    <braunr> (in the entry comparison function)
-    <braunr>        EINVAL (since Linux 2.6.12) length was 0.
-    <braunr> that's a quick glance at mmap(2)
-    <braunr> might help track bugs from userspace (e.g. in exec .. :))
-    <braunr> posix says the saem
-    <braunr> same*
-    <braunr> the gnumach manual isn't that precise
-    <youpi> I don't seem to manage to read the entry
-    <youpi> but I guess size==0 is the problem anyway
-    <mcsim> youpi, braunr: Is there another kernel fault? Was that in my
-      kernel?
-    <braunr> no that's another problem
-    <braunr> which became apparent following the addition of red black trees in
-      the vm_map code
-    <braunr> (but which was probably present long before)
-    <mcsim> braunr: BTW, do you know if there where some specific circumstances
-      that led to memory exhaustion in my code? Or it just aggregated over
-      time?
-    <braunr> mcsim: i don't know
-    <mcsim> s/where/were
-    <mcsim> braunr: ok
-
-
-### IRC, freenode, #hurd, 2012-11-05
-
-    <tschwinge> braunr: I have now also hit the diff != 0 assertion error;
-      sitting in KDB, waiting for your commands.
-    <braunr> tschwinge: can you check the backtrace, have a look at the system
-      call and its parameters like youpi did ?
-    <tschwinge> If I manage to figure out how to do that...  :-)
-    * tschwinge goes read scrollback.
-    <braunr> "trace" i suppose
-    <braunr> if running inside qemu, you can use the integrated gdb server
-    <tschwinge> braunr: No, hardware.  And work intervened.  And mobile phone
-      <-> laptop via bluetooth didn't work.  But now:
-    <tschwinge> Pretty similar to Samuel's:
-    <tschwinge>     Assert([...])
-    <tschwinge>     vm_map_enter(0xc11de6c8, 0xc1785f94, 0, 0, 1)
-    <tschwinge>     vm_map(0xc11de6c8, 0xc1785f94, 0, 0, 1)
-    <tschwinge>     syscall_vm_map(1, 0x1024a88, 0, 0, 1)
-    <tschwinge>     mach_call_call(1, 0x1024a88, 0, 0, 1)
-    <braunr> thanks
-    <braunr> same as youpi observed, the requested size for the mapping is 0
-    <braunr> tschwinge: thanks
-    <tschwinge> braunr: Anything else you'd like to see before I reboot?
-    <braunr> tschwinge: no, that's enough for now, and the other kind of info
-      i'd like are much more difficult to obtain
-    <braunr> if we still have the problem once a small patch to prevent null
-      size is applied, then it'll be worth looking more into it
-    <pinotree> isn't it possible to find out who called with that size?
-    <braunr> not easy, no
-    <braunr> it's also likely that the call that fails isn't the first one
-    <pinotree> ah sure
-    <pinotree> braunr: making mmap reject 0 size length could help? posix says
-      such size should be rejected straight away
-    <braunr> 17:09 < braunr> if we still have the problem once a small patch to
-      prevent null size is applied, then it'll be worth looking more into it
-    <braunr> that's the idea
-    <braunr> making faulty processes choke on it should work fine :)
-    <pinotree> «If len is zero, mmap() shall fail and no mapping shall be
-      established.»
-    <pinotree> braunr: should i cook up such patch for mmap?
-    <braunr> no, the change must be applied in gnumach
-    <pinotree> sure, but that could simply such condition in mmap (ie avoiding
-      to call io_map on a file)
-    <braunr> such calls are erroneous and rare, i don't see the need
-    <pinotree> ok
-    <braunr> i bet it comes from the exec server anyway :p
-    <tschwinge> braunr: Is the mmap with size 0 already a reproducible testcase
-      you can use for the diff != 0 assertion?
-    <tschwinge> Otherwise I'd have a reproducer now.
-    <braunr> tschwinge: i'm not sure but probably yes
-    <tschwinge> braunr: Otherwise, take GDB sources, then: gcc -fsplit-stack
-      gdb/testsuite/gdb.base/morestack.c && ./a.out
-    <tschwinge> I have not looked what exactly this does; I think -fsplit-stack
-      is not really implemented for us (needs something in libgcc we might not
-      have), is on my GCC TODO list already.
-    <braunr> tschwinge: interesting too :)
-
-
-### IRC, freenode, #hurd, 2012-11-19
-
-    <tschwinge> braunr: Hmm, I have now hit the diff != 0 GNU Mach assertion
-      failure during some GCC invocation (GCC testsuite) that does not relate
-      to -fsplit-stack (as the others before always have).
-    <tschwinge> Reproduced:
-      /media/erich/home/thomas/tmp/gcc/hurd/master.build/gcc/xgcc
-      -B/media/erich/home/thomas/tmp/gcc/hurd/master.build/gcc/
-      /home/thomas/tmp/gcc/hurd/master/gcc/testsuite/gcc.dg/torture/pr42878-1.c
-      -fno-diagnostics-show-caret -O2 -flto -fuse-linker-plugin
-      -fno-fat-lto-objects -fcompare-debug -S -o pr42878-1.s
-    <tschwinge> Will check whether it's the same backtrace in GNU Mach.
-    <tschwinge> Yes, same.
-    <braunr> tschwinge: as youpi seems quite busy these days, i'll cook a patch
-      and commit it directly
-    <tschwinge> braunr: Thanks!  I have, by the way, confirmed that the
-      following is enough to trigger the issue: vm_map(mach_task_self(), 0, 0,
-      0, 1, 0, 0, 0, 0, 0, 0);
-    <tschwinge> ... and before the allocator patch, GNU Mach did accept that
-      and return 0 -- though I did not check what effect it actually has.  (And
-      I don't think it has any useful one.)  I'm also reading that as of lately
-      (Linux 2.6.12), mmap (length = 0) is to return EINVAL, which I think is
-      the foremost user of vm_map.
-    <pinotree> tschwinge: posix too says to return EINVAL for length = 0
-    <braunr> yes, we checked that earlier with youpi
-
-[[!message-id "87sj8522zx.fsf@kepler.schwinge.homeip.net"]].
-
-    <braunr> tschwinge: well, actually your patch is what i had in mind
-      (although i'd like one in vm_map_enter to catch wrong kernel requests
-      too)
-    <braunr> tschwinge: i'll work on it tonight, and do some testing to make
-      sure we don't regress critical stuff (exec is another major direct user
-      of vm_map iirc)
-    <tschwinge> braunr: Oh, OK.  :-)
diff --git a/open_issues/gnumach_vm_object_resident_page_count.mdwn b/open_issues/gnumach_vm_object_resident_page_count.mdwn
deleted file mode 100644
index 2ffe5753..00000000
--- a/open_issues/gnumach_vm_object_resident_page_count.mdwn
+++ /dev/null
@@ -1,54 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 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_gnumach]]
-
-
-# IRC, freenode, #hurd, 2012-07-03
-
-    <braunr> omg the ugliness
-    <braunr> the number of pages in physical memory for on object is a short
-      ... which limits the amount to .. 128 MiB
-    * braunr cries
-    <braunr> luckily, this should be easy to solve
-
-`vm/vm_object.h:vm_object:resident_page_count`.
-
-
-## IRC, freenode, #hurd, 2013-06-03
-
-    <elmig> regarding
-      https://www.gnu.org/software/hurd/open_issues/gnumach_vm_object_resident_page_count.html,
-      this is fixed. it's an int. what should happen do this page? /dev/null
-    <elmig> ?
-    <youpi> I guess so
-
-
-## IRC, freenode, #hurd, 2013-06-04
-
-    <elmig>
-      http://darnassus.sceen.net/~hurd-web/open_issues/gnumach_vm_object_resident_page_count/
-    <elmig> this is a int
-    <elmig> how to deal with the page? delete it? archive it?
-    <braunr> ?
-    <elmig> the issue originallu reported was fixed, right?
-    <braunr> i think so, yes
-    <braunr> for now at least
-    <elmig> so this stays on the open_issues on the wiki anyway?
-    <braunr> no, it should go away
-    <elmig> i dont know how to suggest deletion on the wiki
-    <braunr> don't
-    <braunr> i'll do it later
-
-
-## 2013-06-04
-
-resident_page_count it's now an int. 
-The topic it's fixed.
diff --git a/open_issues/hurd_101.mdwn b/open_issues/hurd_101.mdwn
deleted file mode 100644
index e55b0e8e..00000000
--- a/open_issues/hurd_101.mdwn
+++ /dev/null
@@ -1,360 +0,0 @@
-[[!meta copyright="Copyright © 2011, 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]]."]]"""]]
-
-(See Wikipedia page for the meaning of [[!wikipedia "101_(term)"]].)
-
-Not the first time that something like this is proposed...
-
-
-# IRC, freenode, #hurd, 2011-07-25
-
-    [failed GNU/Hurd project]
-    < antrik> gnu_srs1: I wouldn't say he was on track. just one of the many
-      many people who insist on picking a hard task; realizing that indeed it's
-      hard; and going into hiding
-    < antrik> we see that happen every couple of months
-    < cluck> maybe we need a "hurd 101" 
-    < cluck> getting a teacher and setting up a regularly held "class" for hurd
-      noobs
-    < Tekk_> cluck: what would that include?
-    < cluck> explaining core concepts, giving out "homework" (small tasks), etc
-
-[[Anatomy_of_a_Hurd_system]].
-
-    < cluck> that way "the big guys" could focus on the hard stuff and have an
-      army of code monkeys at their disposal to write speced stuff
-    < cluck> (then again this idea would heavily depend on available "teachers"
-      and "students", which, going by gsoc numbers, may not be all that
-      helpful)
-    < Tekk_> cluck: gsoc isn't an accurate indicator
-    < Tekk_> cluck: I'm not allowed to participate in gsoc but I'd join :P
-    < antrik> cluck: we don't need code monkeys... we need hackers
-    < Tekk_`> antrik: code monkeys involve into hackers
-    < Tekk_`> under the right conditions
-    < cluck> antrik: jokes aside some sort of triage system/training ground for
-      newcomers could be helpful
-
-
-# IRC, freenode, #hurd, 2013-01-20
-
-    <zacts> so once I have written my first translators, and really understand
-      that, what kinds of projects would you recommend to an operating
-      systems/hurd newbie.
-    <zacts> I am reading the minix book now as I have it, but I'm waiting on
-      getting the modern operating systems book by the same author.
-    <zacts> I was initially going to start working on minix, but their focus
-      seems to be on embedded, and I want to work on a system that is more
-      general purpose, and I like the philosophy of freedom surrounding the
-      hurd.
-    <zacts> I like how the hurd design allows more freedom for users of the
-      operating system, but I would also like to incorporate ideas from minix
-      on the hurd. mainly, rebootless updates of servers/translators.
-    <neal> then you should study how translators work
-    <neal> how ipc works
-    <neal> and understand exactly what state is stored where
-    <zacts> ok
-
-
-# IRC, freenode, #hurd, 2013-10-12
-
-    <ahungry> Hi all, can anyone expand on
-      https://www.gnu.org/software/hurd/contributing.html - if I proceed with
-      the quick start and have the system running in a virtual image, how do I
-      go from there to being able to start tweaking the source (and recompiling
-      ) in a meaningful way?
-    <ahungry> Would I modify the source, compile within the VM and then what
-      would be the next step to actually test my new changes?
-    <braunr> ahungry: we use debian
-    <braunr> i suggest formatting your changes into patches, importing them
-      into debian packages, rebuilding those packages, and installing them over
-      the upstream ones
-    <ahungry> what about modifications to mach itself?  or say I wanted to try
-      to work on the wifi drives - I would build the translator or module or
-      whatever and just add to the running instance of hurd?
-    <ahungry> s/drives/drivers
-    <braunr> same thing
-    <braunr> although
-    <braunr> during development, it's obviously a bit too expensive to rebuild
-      complete packages each time
-    <braunr> you can use the hurd on top of a gnumach kernel built completely
-      from upstream sources
-    <braunr> you need a few debian patches for the hurd itself
-    <braunr> a lot of them for glibc
-    <braunr> i usually create a temporary local branch with the debian patches
-      i need to make my code run
-    <braunr> and then create the true development branch itself from that one
-    <braunr> drivers are a a dark corner of the hurd
-    <braunr> i wouldn't recommend starting there
-    <braunr> but if you did, yes, you'd write a server to run drivers, and
-      start it
-    <braunr> you'd probably write a translator (which is a special kind of
-      server), yes
-    <ahungry> braunr: thanks for all the info, hittin the sack now but ill have
-      to set up a box and try to contribute 
-
-
-# Documentation
-
-## IRC, freenode, #hurd, 2013-11-04
-
-    <stargater> i think the problem my hurd have not more developers or
-      contubutors is the project idears and management , eg, the most problem
-      is the mach kernel and documatation and the missing subsystem goals
-      (driver, etc)
-    <stargater> no i think you and other have a clue but this is not
-      tranzparent when i read the webpage 
-    <teythoon> well, fwiw I agree, the documentation is lacking
-    <braunr> about what ?
-    <braunr> something that doesn't exist ?
-    <braunr> like smp or a generic device driver framework ?
-    <teythoon> no, high level concepts, design stuff
-    <braunr> what ?
-    <braunr> how come ?
-    <teythoon> not even the gnumach documentation is complete
-    <braunr> for example ?
-    <braunr> see http://www.sceen.net/~rbraun/doc/mach/
-    <braunr> which is my personal collection of docs on mach/hurd
-    <braunr> and it's lacking at least one paper
-    <braunr> well two, since i can't find the original article about the hurd
-      in pdf format
-    <braunr> project ideas are clearly listed in the project ideas page
-    <stargater> braunr: do you think the mach kernel decumatation a compleat?
-      and you think its good documentatition about "how write a drive for mach"
-      and you think a answare is found why dont work smp and why is have no
-      arm, x64 support ?
-    <braunr> stargater:
-      http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/
-    <braunr> the page is even named "project ideas"
-    <braunr> the mach kernel is probably the most documented in the world
-    <braunr> even today
-    <braunr> and if there is no documentation about "how to write drivers for
-      mach", that's because we don't want in kernel drivers any more
-    <braunr> and the state of our driver framework is practically non existent
-    <braunr> it's basically netdde
-    <braunr> partial support for network drivers from linux
-    <braunr> that's all
-    <braunr> we need to improve that
-    <braunr> someone needs to do the job
-    <braunr> noone has for now
-    <braunr> that's all
-    <braunr> why would we document something that doesn't exist ?
-    <braunr> only stupid project managers with no clue about the real world do
-      that
-    <braunr> (or great ones who already know everything there is to know before
-      writing code, but that's rare)
-    <braunr> stargater: the answer about smp, architectures etc.. is the same
-    <stargater> spirit and magic are nice ;-) braunr sorry, that is only my
-      meanig and i will help, so i ask and say what i think. when you say, hurd
-      and mach are good and we on the right way, then its ok for me . i wonder
-      why not more developer help hurd. and i can read and see the project page
-      fro side a first time user/developer
-    <braunr> i didn't say they're good
-    <braunr> they're not, they need to be improved
-    <braunr> clearly
-    <stargater> ok, then sorry
-    <braunr> i wondered about that too, and my conclusion is that people aren't
-      interested that much in system architectures
-    <braunr> and those who are considered the hurd too old to be interesting,
-      and don't learn about it
-    <braunr> consider*
-    <braunr> stargater: why are you interested in the hurd ?
-    <braunr> that's a question everyone intending to work on it should ask
-    <stargater> the spirit of free software and new and other operation system,
-      with focus to make good stuff with less code and working code for ever
-      and everone can it used 
-    <braunr> well, if the focus was really to produce good stuff, the hurd
-      wouldn't be so crappy
-    <braunr> it is now, but it wasn't in the past
-    <stargater> a good point whas more documentation in now and in the future,
-      eg, i like the small project http://wiki.osdev.org/ and i like to see
-      more how understanding mach and hurd 
-    <nalaginrut> I love osdev much, it taught me a lot ;-D
-    <braunr> osdev is a great source for beginners
-    <braunr> teythoon: what else did you find lacking ?
-    <teythoon> braunr: in my opinion the learning curve of Hurd development is
-      quite steep at the beginning
-    <teythoon> yes, documentation exists, but it is distributed all over the
-      internets
-    <braunr> teythoon: hm ok
-    <braunr> yes the learning curve is too hard
-    <braunr> that's an entry barrier
-
-
-# IRC, freenode, #hurd, 2014-02-04
-
-[[!tag open_issue_documentation]]
-
-    <bwright> Does the GNU Mach kernel have concepts of capabilities?
-    <braunr> yes
-    <braunr> see ports, port rights and port names
-    <bwright> Does it follow the take grant approch
-    <bwright> approach*
-    <braunr> probably
-    <bwright> Can for example I take an endpoint that I retype from untyped
-      memory and mint it such that it only has read access and pass that to the
-      cspace of another task over ipc.
-    <bwright> Where that read minted cap enforces it may onnly wait on that ep.
-    <braunr> ep ?
-    <braunr> ah
-    <bwright> Endpoint.
-    <braunr> probably
-    <bwright> Alright cool.
-    <braunr> it's a bit too abstract for me to answer reliably
-    <braunr> ports are message queues
-    <braunr> port rights are capabilities to ports
-    <bwright> Not sure exactly how it would be implemented but essentially you
-      would have a guarded page table with 2 levels, 2^pow slots.
-    <braunr> port names are integers referring to port rights
-    <braunr> we don't care about the implementation of page tables
-    <bwright> Each slot contains a kernel object, which in itself may be more
-      page tabels that store more caps.
-    <braunr> it's not l4 :p
-    <braunr> mach is more of a hybrid
-    <bwright> It isn't a page table for memory.
-    <braunr> it manages virtual memory
-    <bwright> Ah ok.
-    <braunr> whatever, we don't care about the implementation
-    <bwright> So if I want to say port an ethernet driver over.
-    <braunr> whether memory or capabilities, mach manages them
-    <bwright> Can I forward the interrupts through to my new process?
-    <braunr> yes
-    <braunr> it has been implemented for netdde
-    <braunr> these are debian specific patches for the time being though
-    <bwright> Great, and shared memory set ups are all nice and dandy.
-    <braunr> yes, the mach vm takes care of that
-    <bwright> Can I forward page faults?
-    <bwright> Or does mach actually handle the faults?
-    <bwright> (Sorry for so many questions just comparing what I know from my
-      microkernel knowledge to mach and gnu mach)
-    <braunr> mach handles them but translates them to requests to userspace
-      pagers
-    <bwright> (Still have a mach paper to read)
-    <bwright> Alright that sounds sane.
-    <bwright> Does GNU mach have benchmarks on its IPC times?
-    <braunr> no but expect them to suck :)
-    <bwright> Isn't it fixable though?
-    <braunr> mach ipc is known to be extremely heavy in comparison with modern
-      l4-like kernels
-    <braunr> not easily
-    <bwright> Yeah so I know that IPC is an issue but never dug into why it is
-      bad on Mach.
-    <bwright> So what design decision really screwed up IPC speed?
-    <braunr> for one because they're completely async, and also because they
-      were designed for network clusters, meaning data is typed inside messages
-    <bwright> Oh weird
-    <bwright> So how is type marshalled in the message?
-    <braunr> in its own field
-    <braunr> messages have their own header
-    <braunr> and each data field inside has its own header
-    <bwright> Oh ok, so I can see this being heavy.
-    <bwright> So the big advantage is for RPC
-    <bwright> It would make things nice in that case.
-    <bwright> Is it possible to send an IPC without the guff though?
-    <bwright> Or would this break the model mach is trying to achieve?
-    <bwright> I am assuming Mach wanted something where you couldn't tell if a
-      process was local or not.
-    <bwright> So I am assuming then that IPC is costly for system calls from a
-      user process.
-    <bwright> You have some sort of blocking wait on the call to the service
-      that dispatches the syscall.
-    <bwright> I am assuming the current variants of GNU/Hurd run on glibc.
-    <bwright> It would be interesting to possibly replace that with UlibC or do
-      a full port of the FlexSC exceptionless system calls.
-    <bwright> Could get rid of some of the bottlenecks in hurd assuming it is
-      very IPC heavy.
-    <bwright> And that won't break the async model.
-    <bwright> Actually should be simpler if it is already designed for that.
-    <bwright> But would break the "distributed" vibe unless you had the faults
-      to those shared pages hit a page faulter that sent them over the network
-      on write.
-    <bwright> </end probably stupid ideas>
-    <kilobug> bwright: a lot of POSIX compatibility is handled by the glibc,
-      "porting" another libc to the Hurd will be a titanic task
-    <bwright> In theory exceptionless system calls work fine on glibc, it is
-      just harder to get them working.
-    <bwright> has not been done or was not explored in the paper.
-    <bwright> Something about it having a few too many annoying assumptions.
-    <bwright> Would be interesting to run some benchmarks on hurd and figure
-      out where the bottlenecks really are.
-    <bwright> At least for an exercise in writing good benchmarks :P
-    <bwright> I have a paper on the design of hurd I should read actually.
-    <bwright> After I get through this l4 ref man.
-    <braunr> the main bottleneck is scalability
-    <braunr> there are a lot of global locks
-    <braunr> and servers are prone to spawning lots of threads
-    <braunr> because, despite the fact mach provides async ipc, the hurd mostly
-      uses sync ipc
-    <braunr> so the way to handle async notifications is to receive messages
-      and spawn threads as needed
-    <bwright> Lets take a senario
-    <braunr> beyond that, core algorithms such as scanning pages in pagers, are
-      suboptimal
-    <bwright> I want to get a file and send it across the network.
-    <bwright> How many copies of the data occur?
-    <braunr> define send
-    <braunr> ouch :)
-    <braunr> disk drivers are currently in the kernel
-    <bwright> I read a block from disk, I pass this to my file system it passes
-      it to the app and it sends to the lwip or whatever interface then out the
-      ethernet card.
-    <braunr> and "block device drivers" in userspace (storeio) are able to
-      redirect file system servers directly to those in kernel drivers
-    <braunr> so
-    <braunr> kernel -> fs -> client -> pfinet -> netdde (user space network
-      drivers on debian hurd)
-    <bwright> Alright. Hopefully each arrow is not a copy :p
-    <braunr> it is
-    <bwright> My currently multiserver does this same thing with zero copy.
-    <braunr> because buffers are usually small
-    <braunr> yes but zero copy requires some care
-    <bwright> Which is possible.
-    <braunr> and usually, posix clients don't care about that
-    <bwright> Yes it requires a lot of care.
-    <bwright> POSIX ruins this
-    <bwright> Absolutely.
-    <braunr> they assume read/write copy data, or that the kernel is directly
-      able to access data
-    <bwright> But there are some things you can take care with
-    <bwright> And not break posix and still have this work.
-    <braunr> pfinet handles ethernet packets one at a time, and 1500 isn't
-      worth zero copying
-    <bwright> This depends though right?
-    <braunr> i'm not saying it's not possible
-    <braunr> i'm saying most often, there are copies
-    <bwright> So if I have high throughput I can load up lots of packets and
-      the data section can then be sectioned with scatter gather 
-    <braunr> again, the current interface doesn't provide that
-    <bwright> Alright yeah that is what I expected which is fine.
-    <bwright> It will be POSIX compliant which is the main goal.
-    <braunr> not really scatter gather here but rather segment offloading for
-      example
-    <braunr> ah you're working on something like that too :)
-    <bwright> Yeah I am an intern :)
-    <bwright> Have it mostly working, just lots of pain.
-    <bwright> Have you read the netmap paper?
-    <bwright> Really interesting.
-    <braunr> not sure i have
-    <braunr> unless it has another full name
-    <bwright> 14.86 million packets per second out of the ethernet card :p
-    <bwright> SMOKES everything else.
-    <bwright> Implemented in Linux and FreeBSD now.
-    <bwright> Packets are UDP 1 byte MTU I think
-    <bwright> 1 byte data *
-    <bwright> To be correct :p
-    <braunr> right, i see
-    <bwright> Break posix again
-    <bwright> "More Extend"
-    <braunr> i've actually worked on a proprietary implementation of such a
-      thing where i'm currently working
-    <bwright> Bloody useful for high frequency trading etc.
-    <bwright> Final year as an undergraduate this year doing my thesis which
-      should be fun, going to be something OS hopefully.
-    <bwright> Very fun field lots of weird and crazy problems.
diff --git a/open_issues/hurd_build_without_parted.mdwn b/open_issues/hurd_build_without_parted.mdwn
deleted file mode 100644
index 06ecf56d..00000000
--- a/open_issues/hurd_build_without_parted.mdwn
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!meta copyright="Copyright © 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_hurd]]
-
-Seen with `cross-gnu`.
-
-If the *parted* libraries aren't available, we explicitly have to set
-`--without-parted` or the build will fail.
diff --git a/open_issues/hurd_file_name_lookup_retry_FS_RETRY_MAGIC.mdwn b/open_issues/hurd_file_name_lookup_retry_FS_RETRY_MAGIC.mdwn
deleted file mode 100644
index ba2f5865..00000000
--- a/open_issues/hurd_file_name_lookup_retry_FS_RETRY_MAGIC.mdwn
+++ /dev/null
@@ -1,50 +0,0 @@
-[[!meta copyright="Copyright © 2009, 2010, 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]]."]]"""]]
-
-[[!meta title="hurd_file_name_lookup_retry: FS_RETRY_MAGICAL"]]
-
-[[!tag open_issue_glibc open_issue_hurd]]
-
-
-# IRC, freenode, #hurd, 2009-08-25
-
-[[hurd/interface/dir_lookup]].
-
-    <cfhammar> also I fixed (what I think is) a bug in
-      hurd_file_name_lookup_retry when opening FDs with FS_RETRY_MAGICAL
-    <cfhammar> it didn't actually reopen the FD, rather it just (effectively)
-      duped it
-    <scolobb> cfhammar: That's great!  I think I had some problems because of
-      not being able to truly reopen a port to a file.
-    <antrik> cfhammar: what is the difference, and why do you consider it a
-      bug?...
-    <cfhammar> antrik: for one thing you can't change open modes, and it
-      doesn't reset the file cursor
-    <cfhammar> (which I actually needed, though I could have done it manually)
-    <cfhammar> antrik: and also it isn't consistant with linux
-    <cfhammar> you can trigger the bug from the shell: cat /dev/fd/3 3>>
-      /tmp/foo
-    <antrik> cfhammar: I can't say that I understand the test case... but I can
-      at least confirm that it behaves differently on Hurd and on Linux :-)
-
-
-## 2013-02-17
-
-GNU/Linux:
-
-    $ cat /dev/fd/3 3>> /tmp/foo
-    $ ls -l /tmp/foo 
-    -rw-rw-r-- 1 thomas thomas 0 Feb 17 12:01 /tmp/foo
-
-GNU/Hurd:
-
-    $ cat /dev/fd/3 3>> /tmp/foo
-    cat: /dev/fd/3: Bad file descriptor
diff --git a/open_issues/hurd_init.mdwn b/open_issues/hurd_init.mdwn
deleted file mode 100644
index cc06935c..00000000
--- a/open_issues/hurd_init.mdwn
+++ /dev/null
@@ -1,224 +0,0 @@
-[[!meta copyright="Copyright © 2013 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_hurd]]
-
-
-# [[!message-id "20130625154749.17799.36923@thinkbox.jade-hamburg.de"]]
-
-
-## IRC, freenode, #hurd, 2013-07-22
-
-    <teythoon> ok, so back to the drawing board for the next big issue, the
-      potential proc and init merge
-    <teythoon> Roland had some harsh words for that proposal, but noone else
-      raised concerns
-    <youpi> noone else does not mean much
-    <youpi> I guess only Roland actually understands the matter
-    <youpi> so I'd tend to believe him
-    <teythoon> even though, his criticism was so superficial, he could at least
-      be a bit more specific...
-    <braunr> i agree that the argument, being simply based on vague principle,
-      isn't very convincing
-    <teythoon> so, what should I do?
-    <braunr> you can either keep them separate, or fight with roland
-    <teythoon> common braunr, I need a little more guidance in these kind of
-      social issues
-    <teythoon> a statement like this is of little use ;)
-    <braunr> that's the best i can give you
-    <teythoon> :/
-    <braunr> i have one patch "fixing" HZ on the hurd, and i even get to fight
-      about it
-    <teythoon> I understand Roland has been around forever and keeps an eye on
-      stuff
-    <teythoon> but could/would he block a patch for hurd if e.g. youpi would
-      accept it
-    <teythoon> i.e. how much control has he in practice?
-    <teythoon> me fighting with him over a patch is of little value for anyone
-      and I don't care to do so
-    <braunr> not much i suppose now
-    <braunr> but we also have to agree with the change
-    <braunr> with *real* arguments
-    <braunr> (well, if it was up to me, i'd even merge exec with proc so ..)
-    <teythoon> ok, so I whip up a patch to see how it goes in practice and
-      present it so we could talk about the issue with something to look at
-      first
-    <braunr> although maybe not ;p
-    <braunr> you'll hit the same reaction
-    <teythoon> from Roland?
-    <braunr> yes
-    <braunr> and youpi said he tends to trust what roland says
-    <braunr> so let's discuss the pros and cons a bit more
-    <teythoon> yes, but I'd honor his concerns if they were properly
-      presented. just telling me to hack on linux instead even though I think I
-      have demonstrated that I do want to work on Hurd is so childish in my
-      eyes that I do not consider that a valid argument at the moment
-    <teythoon> sure, shoot
-    <braunr> well, functionally, they're unrelated
-    <teythoon> head -n1 init/init.c
-    <teythoon> /* Start and maintain hurd core servers and system run state
-    <youpi> and thus it makes sense to make them separate, even if it does not
-      seem to bring anything useful now
-    <youpi> history has shown that it makes a bed for nice things later
-    <braunr> teythoon: that's not what proc is about
-    <teythoon> braunr: I know
-    <teythoon> braunr: that's what init is about in its own words ;)
-    <youpi> teythoon: also, "simplifying the code" is not necessarily an
-      argument that would be considered
-    <youpi> depending on the simplification
-    <youpi> linux made it all simple by using a monolithic kernel :)
-    <youpi> separating concerns is complex
-    <youpi> but in the end it usually pays off on the Hurd
-    <youpi> personally, I'd be fine with Guillem's solution, and renumbering
-      init's pid in Debian
-    <youpi> there's a pending question from Roland actually: what information
-      is exchanged between init and proc in the end?
-    <youpi> that's actually the point of the discussion: is that information
-      really big or not
-    <teythoon> I'm sorry, you lost me, where did he ask that question?
-    <pinotree> $ git grep proc_getmsgport | egrep '[0-9]' ← /hurd/init as pid 1
-      is hardcoded in few places
-    <youpi> teythoon: he didn't ask it this way, but that's the question I had
-      to be able to answer his
-    <youpi> Date: Mon, 15 Jul 2013 10:36:35 -0700 (PDT)
-    <youpi> > That's not what he said. He said there is a lot of information
-    <youpi> > propagated from init to proc, and thus the separation is
-      questionable.
-    <youpi> Are you talking about bootstrap, or what?
-    <youpi> as I haven't investigated much, I couldn't answer this
-    <youpi> pinotree: right. We could patch these in Debian
-    <teythoon> youpi: so, shall I refresh, test and refine Guillems patch and
-      resend it?
-    <youpi> it's probably an easier way
-    <teythoon> ok, I start by doing that
-
-
-## IRC, freenode, #hurd, 2013-07-25
-
-    <teythoon> pinotree: btw, there are two /sbin/init processes even with my
-      hacked up init/proc variant where /sbin/init gets to be pid 1
-    <pinotree> never seen that
-    <pinotree> what are their parents?
-    <teythoon> pinotree: well, pid 1 is /sbin/init now, pid 13 or something has
-      the parent 1
-    <teythoon> looks like init forks or something
-    <pinotree> i guess your sysvinit is compiled without INITDEBUG?
-    <pinotree> nothing in syslog either?
-    <teythoon> pinotree: it's compiled like the sysvinit shipped with debian
-    <pinotree> teythoon: do you have custom additions in inittab?
-    <teythoon> pinotree: a terminal for my serial console
-    <teythoon> *getty
-    <pinotree> are the getty started correctly for you, btw?
-    <teythoon> pinotree: yes
-    <pinotree> interesting
-    <pinotree> teythoon: back then, they were costantly respawning, with hurd's
-      getty's failing to start when exec'ed by (sysv)init
-    <pinotree> wonder what changed
-    <teythoon> pinotree: cool, magically went away then :)
-
-
-## IRC, freenode, #hurd, 2013-07-29
-
-    <teythoon> youpi: I need some feedback on the not freezing translators
-      issue, more specifically whether I understood you correctly in your mail
-      from wednesday (20130724131552.GG9576@type.bordeaux.inria.fr)
-    <teythoon> oh yeah, and I had some questions yesterday too, about rpctrace
-      and dead-name notifications, specifically why /hurd/init is not receiving
-      any for the root translator and the exec server
-    <braunr> teythoon: more details please
-    <teythoon> ok, so /hurd/init is registering for dead name notifications for
-      essential tasks
-    <teythoon> the rootfs and exec both register as essential tasks at init and
-      init requests successfully dead name notifications for them
-    <teythoon> if you e.g. kill the auth server, /hurd/init will notice and
-      crash the system
-    <teythoon> if you kill exec or the rootfs, /hurd/init does not get notified
-    <teythoon> I verified this with gdb and an subhurd
-    <teythoon> I'm puzzled by this, as the kernel is the one who sends the
-      notifications, right?
-    <braunr> yes
-    <braunr> teythoon: where is the problem ?
-    <teythoon> and it is not that the system is not sending any messages, it
-      is, I see the msgcount increase over time
-    <teythoon> braunr: dunno, as far as I can tell the kernel does not deliver
-      the notification for rootfs and exec
-    <braunr> oh
-    <teythoon> those are the two processes loaded by grub, maybe they are
-      different somehow
-    <braunr> is that affecting your work ?
-    <teythoon> no, not directly, I strayed around at the weekend, trying to
-      think of cool stuff hurd could do
-    <teythoon> youpi: I need some feedback on the not freezing translators
-      issue, more specifically whether I understood you correctly in your mail
-      from wednesday (20130724131552.GG9576@type.bordeaux.inria.fr)
-    <youpi> teythoon: ok, now I'm available for the not-freezing-translators
-      thing :)
-
-
-## IRC, freenode, #hurd, 2013-08-05
-
-    <teythoon> youpi: I'm in the process of producing a unified
-      sysvinit-as-pid1 and please-dont-kill-important-processes patch series
-    <teythoon> youpi: there is one issue with changing /hurd/inits pid, libcs
-      reboot() also assumes that it has the pid 1
-    <youpi> argl
-    <youpi> that's bad, because it's then an ABI, not just an internal thing
-    <teythoon> hardcoding the pid is the worst way of getting a handle of any
-      server :/
-    <teythoon> I've been thinking to make it explicit by binding it to
-      /servers/startup or something
-    <youpi> that would be more hurdish than using a pid, yes
-    <teythoon> yes, and not only does it break the abi, but in a bad way
-      too. if the libc is updated before the hurd, the shutdown sequence is
-      broken in a way that the translators aren't synced :/
-    <teythoon> youpi: as a workaround, we could make reboot() signal both pid 1
-      and 2
-    <youpi> at worse pid 1 shouldn't get harmed by receiving a startup_reboot
-      RPC indeed
-    <teythoon> yes
-
-
-## IRC, freenode, #hurd, 2013-08-16
-
-    <teythoon> grml, the procfs hardcodes the kernels pid :/
-    <teythoon> there's always one more thing to fix...
-    <teythoon> uh, and we made pids.h a private header, so no nice constant for
-      the procfs translator :/
-    <teythoon> server lookup by hardcoding the pid should be banned...
-
-
-## IRC, freenode, #hurd, 2013-09-16
-
-    <teythoon> youpi: I'm thinking about splitting /hurd/init into /hurd/init
-      and /hurd/startup
-    <teythoon> that way, you could also merge the init as pid1 patches
-    <teythoon> that should be doable within the week
-    <youpi> that would probably be better received by Roland than merging init
-      into proc :)
-    <teythoon> yes, I suppose so :D
-    <youpi> perhaps you should start the discussion on the list about it
-      already, with just a sketch of which would do what
-    <teythoon> ok
-    <teythoon> fwiw I like the name startup b/c it speaks the startup protocol
-    <braunr> teythoon: +1 startup
-
-
-## IRC, freenode, #hurd, 2013-09-23
-
-    <teythoon> I've been hacking on init/startup, I've looked into cleaning it
-      up
-
-
-## IRC, freenode, #hurd, 2013-10-07
-
-    <teythoon> braunr: btw, what do you think of my /hurd/startup proposal?
-    <braunr> i haven't read it in detail yet
-    <braunr> it's about separating init right ?
-    <teythoon> yes
diff --git a/open_issues/hurdextras.mdwn b/open_issues/hurdextras.mdwn
deleted file mode 100644
index d4f9d1bc..00000000
--- a/open_issues/hurdextras.mdwn
+++ /dev/null
@@ -1,95 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2012 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]]."]]"""]]
-
-This is about merging some hurdextras stuff into Hurd proper repostitories.
-
-[[!toc levels=2]]
-
-
-# OK
-
-## mboxfs
-
-Tarball-import, plus trivial changes.
-
-  * Ludovic Courtes -- OK
-  * mmenal -- OK
-
-## notice
-
-Tarball-import.
-
-  * Wolfgang Jährling <wolfgang@pro-linux.de> -- OK
-
-## run
-
-Tarball-import.
-
-  * Marcus Brinkmann  <marcus@gnu.org> -- OK
-  * Manuel Menal  <mmenal@hurdfr.org> -- OK
-
-
-# Not Interesting
-
-## procfs
-
-Not interesting anymore, but perhaps import for posterity?  Likewise for Neal's
-tarball(s).
-
-
-# Not OK
-
-Sent email to all *NOK*s on 2012-07-14, asking for assignment.
-
-
-## httpfs
-
-  * Arun V. <arunsark@yahoo.com> -- NOK
-  * Gopika U. K. <gopika78@yahoo.com> -- NOK
-  * mrphython / James A. Morrison  <ja2morri@uwaterloo.ca> -- OK
-
-## ipc_guide
-
-  * Manuel Pavón Valderrama <mpavon@ugr.es> -- NOK
-  * <cp46tan@hotpop.com> -- NOK
-
-## jfs
-
-  * Sajith T S  <sajith@symonds.net> -- NOK
-  * mmenal / Manuel Menal  <mmenal@hurdfr.org> -- OK
-
-## memfs
-
-  * Farid Hajji  <farid.hajji@ob.kamp.net> -- NOK
-  * Ludovic Courtes  <ludo@chbouib.org> -- OK
-  * mmenal -- OK
-
-## pith
-
-[[tschwinge]] has some tarballs, too.
-
-  * John Tobey  <jtobey@john-edwin-tobey.org> -- NOK
-  * Manuel Menal  <mmenal@hurdfr.org> -- OK
-
-## pptop
-
-  * Miles Bader -- OK
-  * Paul Emsley <paule@chem.gla.ac.uk> -- NOK
-  * James Morrison -- OK
-  * Neal Walfield -- OK
-  * Jon Arney <jarney1@cox.net> -- OK
-  * Alfredo Beaumont Sainz  <alfredo.beaumont@gmail.com> -- NOK (but trivial) -- OK
-
-## xmlfs
-
-Tarball-import.
-
-  * Marc de Saint Sauveur <marc@hurdfr.org> -- NOK
-  * mmenal -- OK
diff --git a/open_issues/ifunc.mdwn b/open_issues/ifunc.mdwn
deleted file mode 100644
index c357c99c..00000000
--- a/open_issues/ifunc.mdwn
+++ /dev/null
@@ -1,49 +0,0 @@
-[[!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_binutils open_issue_gcc open_issue_glibc]]
-
-Needs porting / support in [[/binutils]] and [[/glibc]], and then some target
-configure magic for [[/GCC]].
-
-<http://nickclifton.livejournal.com/6612.html> has a short summary about how to
-use it from GCC.
-
-  * binutils
-
-    Already passes the ifunc testsuite bits for GAS, but notably for LD
-    (`ld/testsuite/ld-ifunc/ifunc.exp`), too, but that one contains a bunch of
-    stuff explicitly tailored towards Linux.  For example, we get *OS/ABI: UNIX
-    - Linux*.  (This should be fixed through using [[toolchain/ELFOSABI_GNU]].)
-
-    Most of the executables that the testsuite generates don't actually
-    execute.  (Though, this is partly due to the [[static
-    issue|binutils#static]].)
-
-        $ tmpdir/local_prog 
-        ifunc working correctly
-        $ tmpdir/static_prog 
-        Killed
-        $ tmpdir/dynamic_prog 
-        tmpdir/dynamic_prog: error while loading shared libraries: ./tmpdir/libshared_ifunc.so: ELF file OS ABI invalid
-        $ tmpdir/static_nonifunc_prog 
-        Killed
-        $ tmpdir/test-1
-        tmpdir/test-1: error while loading shared libraries: tmpdir/libshared_ifunc.so: ELF file OS ABI invalid
-
-  * [[glibc]]
-
-      * [[libc_variant_selection]]
-
-  * [[GCC]]
-
-    In `gcc/config.gcc`, set `default_gnu_indirect_function=yes` for us, like
-    done for GNU/Linux.  See thread starting at [[!message-id
-    "CAFULd4YZsAQ6ckFjXtU5-yyv=3tYQwTJOPhU9zmJxFOrnotj8g@mail.gmail.com"]].
diff --git a/open_issues/implementing_hurd_on_top_of_another_system.mdwn b/open_issues/implementing_hurd_on_top_of_another_system.mdwn
deleted file mode 100644
index cf3db0ab..00000000
--- a/open_issues/implementing_hurd_on_top_of_another_system.mdwn
+++ /dev/null
@@ -1,420 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 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_documentation]]
-
-It is possible to run Hurd stuff on top of another system instead of on Mach.
-One obvious variant is [[emulation]] (using [[hurd/running/QEMU]], for
-example), but
-doing that does not really integratable the Hurd guest into the host system.
-There is also a more direct way, more powerful, but it also has certain
-requirements to do it effectively.
-
-See also [[Mach_on_top_of_POSIX]].
-
-
-# IRC, freenode, #hurd, August / September 2010
-
-    <marcusb> silver_hook: the Hurd can also refer to the interfaces of the
-      filesystems etc, and a lot of that is really just server/client APIs that
-      could be implemented on any system that has transferable rights to
-      message capabilities.
-    <marcusb> silver_hook: it's surprising how few systems *have* transferable
-      rights, though!
-    <marcusb> silver_hook: usually it is added as an afterthought
-    <marcusb> and comes with restriction
-    <youpi> marcusb: there's SCM_RIGHTS to transfer fds, which is quite often
-      available
-    <marcusb> youpi: yes, I know this as "fdpassing"
-    <marcusb> youpi: it's described in the Stevens series even
-    [...]
-    <marcusb> ArneBab: well, let me put it this way.  the Linux kernel has no
-      interface to manipulate another tasks's virtual address space, ie you
-      can't map/unmap stuff in another process
-    <marcusb> ArneBab: you would have to use ptrace and load some stub code in
-      that process to make that happen.
-    <marcusb> ArneBab: so for complete transparent manipulation, you need a
-      kernel module
-    <marcusb> that is what the User Mode Linux kernel module does
-    <marcusb> ArneBab: so say you use the User Mode Linux kernel module for
-      that one feature.  Then you can do everything that User Mode Linux can
-      do, which, I assure you, includes running subhurds :)
-    <marcusb> it can be a bit tricky to implement those features, but it is not
-      harder than writing a kernel in the first place
-    <ArneBab> So, if I got an admin to install User Mode Linux and Mach
-      emulation, I’d get the flexibility (and independence from admin
-      decisions) I have in the Hurd?
-    <marcusb> ArneBab: one problem is that you still use Linux.  For those who
-      want to get rid of Linux for political reasons, that would mean complete
-      failure
-    <marcusb> ArneBab: if you have UML kernel module, you can implement Mach in
-      user space
-    <marcusb> ArneBab: in fact, John Tobey did this a couple of years ago, or
-      started it
-
-[[Mach_on_top_of_POSIX]].
-
-    <marcusb> ArneBab: or you can just implement parts of it and relay to Linux
-      for the rest
-    <marcusb> the point is, that if you don't care for kernel improvements, and
-      are sufficiently happy with the translator stuff, it's not hard to bring
-      the Hurd to Linux or BSD
-
-Continue reading about the [[benefits_of_a_native_Hurd_implementation]].
-
-
-# IRC, freenode, #hurd, 2010-12-28
-
-    <antrik> kilobug: there is no real requirement for the Hurd to run on a
-      microkernel... as long as the important mechanisms are provided (most
-      notably external pagers and Mach IPC), the Hurd could run an top of
-      pretty much any kernel...
-    <antrik> whether it makes sense is another question of course :-)
-    <antrik> though I must say that I'm more and more convinced running the
-      Hurd on top of a monolithic kernel would actually be a useful approach
-      for the time being...
-
-
-# IRC, freenode, #hurd, 2011-02-11
-
-    <neal> marcus and I were discussing how to add Mach to Linux
-    <neal> one could write a module to implement Mach IPC
-    <neal> and another to implement Mach VM
-    <neal> the big thing missing with Mach VM is the ability for a tracing
-      process to easily map or unmap an inferior process's memory
-    <antrik> neal: why would a tracing process need to map the inferior's
-      memory?
-    <neal> the simple answer is that is how it is done on Mach
-    <antrik> neal: is it? not sure we are talking about the same thing
-      here. GDB uses vm_read()/vm_write() to access the inferior's memory AFAIK
-    <neal> on linux?
-    <neal> I think it use /proc/pid/mem
-    <antrik> on Hurd
-    <neal> I'm talking about adding Mach to Linux
-    <neal> by adding some functionality to Linux
-    <neal> and then implementing a bunch in user space
-    <antrik> yeah, but I don't understand the point about mapping inferior's
-      memory :-(
-    <antrik> what would be in user space?
-    <neal> there are a number of different cut points
-    <neal> one could imagine just using Linux's device drivers, CPU scheduler,
-      memory management, etc.
-    <neal> another possibility would be something higher where Hurd processes
-      just use some Hurdish servers
-    <antrik> neal: yeah, these are all options I have been considering... too
-      bad I wasn't able to come to FOSDEM -- I'd love to have participated in
-      this discussion :-(
-    <antrik> neal: BTW, were you just discussing this as a hypothetical idea,
-      or something you are seriously considering?
-    <neal> I'm unlikely to work on it, sorry
-    <antrik> didn't really expect that :-)
-    <antrik> would be nice though if you could write up your conclusions...
-
-
-# IRC, freenode, #hurd, 2012-10-12
-
-    <peo-xaci> do hurd system libraries make raw system calls ever
-      (i.e. inlined syscall() / raw assembly)?
-    <braunr> sure
-    <peo-xaci> hmm, so a hurd emulation layer would need to use ptrace if it
-      should be fool proof? :/
-    <braunr> there is no real need for raw assembly, and the very syscalls are
-      all available through macros
-    <braunr> hum what are you trying to say ?
-    <peo-xaci> well, if they are done through syscall, as a function, not a
-      macro, then they can be intercepted with LD_PRELOAD
-    <peo-xaci> so applications that do Hurd (Mach?) syscalls could work on
-      f.e. Linux, if a special libc is injected into the program with
-      LD_PRELOAD
-    <peo-xaci> same thing with making standard Linux-applications go through
-      the Hurd emulation layer
-    <peo-xaci> without recompilation
-    <mel-_> peo-xaci: the second direction is implemented in glibc.
-    <mel-_> for the other direction, I personally see little use for it
-    <braunr> peo-xaci: ok i misunderstood
-    <braunr> peo-xaci: i don't think there is any truely direct syscall usage
-      in the hurd
-    <peo-xaci> hmm, I'm not sure I understand what directions you are referring
-      to mel-_ 
-    <braunr> peo-xaci: what are you trying to achieve ?
-    <peo-xaci> I want to make the Hurd design more accessible by letting Hurd
-      application run on the Linux kernel, preferably without
-      recompilation. This would be done with a daemon that implements Mach and
-      which all syscalls would go to.
-    <peo-xaci> then, I also want so that standard Linux applications can go
-      through that Mach daemon as well, if a special libc is preloaded
-    <braunr> you might want to discuss this with antrik 
-    <peo-xaci> what I'm trying to figure out specifically is if there is some
-      library/interface that glue Hurd with Mach and would be better suited to
-      emulate than Mach? Mach seems to be more of an implementation detail to
-      the hurd and not something an application would directly use.
-    <braunr> yes, the various hurd libraries (libports and libpager mostly)
-    <peo-xaci> From [http://www.gnu.org/software/hurd/hurd/libports.html]:
-      "libports is not (at least, not for now) a generalization / abstraction
-      of Mach ports to the functionality the Hurd needs, that is, it is not
-      meant to provide an interface independently of the underlying
-      microkernel."
-    <peo-xaci> Is this still true?
-    <peo-xaci> Does libpager abstract the rest?
-    <peo-xaci> (and the other hurd libraries)
-    <braunr> there is nothing that really abstracts the hurd from mach
-    <braunr> for example, reference counting often happens here and there
-    <braunr> and core libraries like glibc and libpthread heavily rely on it
-      (through sysdeps specific code though)
-    <braunr> libports and libpager are meant to simplify object manipulation
-      for the former, and pager operations for the latter
-    <peo-xaci> and applications, such as translators, often use Mach interfaces
-      directly?
-    <peo-xaci> correct?
-    <braunr> depends on what often means
-    <braunr> let's say they do
-    <peo-xaci> :/ then it probably is better to emulate Mach after all
-    <braunr> there was a mach on posix port a long time ago
-    <peo-xaci> I thought applications were completely separated from the
-      microkernel in use by the Hurd
-    <braunr> that level of abstraction is pretty new
-    <braunr> genode is the only system i know which does that
-
-[[microkernel/Genode]].
-
-    <braunr> and it's still for "l4 variants"
-    <pinotree> ah, thanks (i forgot that name)
-    <antrik> braunr: Genode also runs on Linux and a few other non-L4
-      environments IIRC
-    <antrik> peo-xaci: I'm not sure binary emulation is really useful. rather,
-      I'd recompile stuff as "regular" Linux executables, only using a special
-      glibc
-    <antrik> where the special glibc could be basically a port of the Hurd
-      glibc communicating with the Mach emulation instead of real Mach; or it
-      could do emulation at a higher level
-    <antrik> a higher level emulation would be more complicated to implement,
-      but more efficient, and allow better integration with the ordinary
-      GNU/Linux environment
-    <antrik> also note that any regular program could be recompiled against the
-      HELL glibc to run in the Hurdish environment...
-    <antrik> (well, glibc + hurd server libraries)
-    <peo-xaci> I'm willing to accept that Hurd-application would need to be
-      recompiled to work on the HELL
-    <peo-xaci> but not Linux-applications :)
-    <antrik> peo-xaci: if you happen to understand German, there is a fairly
-      good overview in my thesis report ;-)
-    <antrik> peo-xaci: there are no "Hurd applications" or "Linux applications"
-    <peo-xaci> well, let me define what I mean by the terms: Hurd applications
-      use Hurd-specific interfaces/syscalls, and Linux applications use
-      Linux-specific interfaces/syscalls
-    <antrik> a few programs use Linux-specific interfaces (and we probably
-      can't run them in HELL just as we can't run them on actual Hurd); but all
-      other programs work in any glibc environment
-    <antrik> (usually in any POSIX environment in fact...)
-    <antrik> peo-xaci: no sane application uses syscalls
-    <peo-xaci> they do under the hood
-    <peo-xaci> I have read about inlined syscalls
-    <antrik> again, there are *some* applications using Linux-specific
-      interfaces (sometimes because they are inherently bound to Linux
-      features, sometimes unnecessarily)
-    <antrik> so far there are no applications using Hurd-specific interfaces
-    <peo-xaci> translators do?
-    <peo-xaci> they are standard executables are they not?
-    <peo-xaci> I would like so that translators also can be run in the HELL
-    <antrik> I wouldn't consider them applications. all existing translators
-      are pretty much components of the Hurd itself
-    <peo-xaci> okay, it's a question about semantics, perhaps I should use
-      another word than "applications" :)
-    <peo-xaci> for me, applications are what have a main-function, or similar
-      single entry point
-    <braunr> hum
-    <braunr> that's not a good enough definition
-    <antrik> anyways, as I said, I think recompiling translators against a
-      Hurdish glibc and ported translator libraries seems the most reasonable
-      approach to me
-    <braunr> let's say applications are userspace processes that make use of
-      services provided by the operating system
-    <braunr> translators being part of the operating system here
-    <antrik> braunr: do you know whether the Mach-on-POSIX was actually
-      functional, or just an abandoned experiment?...
-    <antrik> (I don't remember hearing of it before...)
-    <braunr> incomplete iirc
-    <peo-xaci> braunr: still, when I've explained what I meant, even if I used
-      the wrong term, then my previous statements should come in another light
-    <peo-xaci> antrik / braunr: are you still interested in hearing my
-      thoughts/ideas about HELL?
-    <antrik> oh, there is more to come? ;-)
-    <peo-xaci> yes! I don't think I have made myself completely understood :/
-    <peo-xaci> what I envision is a HELL system that works on as low level as
-      feasible, to make it possible to do almost anything that can be done on
-      the real Hurd (except possibly testing hardware drivers and such very low
-      level stuff).
-    <braunr> sure
-    <peo-xaci> I want it to be more than just allowing programs to access a
-      virtual filesystem à la FUSE. My idea is that all user space system
-      libraries/programs of the Hurd should be inside the HELL as well, and
-      they should not be emulated.
-    <peo-xaci> The system should at the very least be API compatible, so at the
-      very most a recompilation is necessary.
-    <peo-xaci> I also want so that GNU/Linux-programs can access the features
-      of the HELL with little effort on the user. At most perhaps a script that
-      wraps LD_PRELOADing has to be run on the binary. Best would be if it
-      could work also with insane assembly programs using raw system calls, or
-      if glibc happens to have some well hidden syscall being inlined to raw
-      assembly code.
-    <peo-xaci> And I think I have an idea on how an implementation could
-      satisfy these things!
-    <peo-xaci> By modifying the kernel and replace those syscalls that make
-      sense for the Hurd/Mach
-    <peo-xaci> with "the kernel", I meant Linux
-    <braunr> it's possible but tedious and not very useful so better do that
-      later
-    <braunr> mach did something similar at its time
-    <braunr> there was a syscall emulation library
-    <peo-xaci> but isn't it about as much work as emulating the interface on
-      user-level?
-    <braunr> and the kernel cooperated so that unmodified unix binaries
-      performing syscalls would actually jump to functions provided by that
-      library, which generally made an RPC
-    <peo-xaci> instead of a bunch of extern-declerations, one would put the
-      symbols in the syscall table
-    <braunr> define what "those syscalls that make sense for the Hurd/Mach"
-      actually means
-    <peo-xaci> open/close, for example
-    <braunr> otherwise i don't see another better way than what the old mach
-      folks did
-    <braunr> well, with that old, but existing support, your open would perform
-      a syscall
-    <braunr> the kernel would catch it and redirect the caller to its syscall
-      emulation library
-    <braunr> which would call the open RPC instead
-    <peo-xaci> wait, so this "existing support" you're talking about; is this a
-      module for the Linux kernel (or a fork, or something else)?
-    <peo-xaci> where can I find it?
-    <braunr> no
-    <braunr> it was for mach
-    <braunr> in order to run unmodified unix binaries
-    <braunr> the opposite of what you're trying to do
-    <peo-xaci> ah okay
-    <braunr> well
-    <braunr> not really either :)
-    <peo-xaci> does posix/unix define a standard for how a syscall table should
-      look like, to allow binary syscall compatibility?
-    <braunr> absolutely not
-    <peo-xaci> so how could this mach module run any unmodified unix binary? if
-      they expected different sys calls at different offsets?
-    <braunr> posix specifically (and very early) states that it almost forbids
-      itself to deal with anything regarding to ABIs
-    <braunr> depends
-    <braunr> since it was old, there weren't that many unix systems
-    <braunr> and even today, there are techniques like those used by netbsd
-      (and many other actually)
-    <braunr> that are able to inspect the binary and load a syscall emulation
-      environment depending on its exposed ABI
-    <braunr> e.g. file on an executable states which system it's for
-    <peo-xaci> hmm, I'm not sure how a kernel would implement that in
-      practice.. I thought these things were so hard coded and dependent on raw
-      memory reads that it would not be possible
-    <braunr> but i really think it's not worth the time for your project
-    <peo-xaci> to be honest I have virtually no experience of practical kernel
-      programming
-    <braunr> with an LDT on x86 for example
-    <braunr> no, there is really not that much hardcoded
-    <braunr> quite the contrary
-    <braunr> there is a lot of runtime detection today
-    <peo-xaci> well I mean how the syscall table is read
-    <braunr> it's not read
-    <peo-xaci> it's read to find the function pointer to the syscall handler in
-      the kernel?
-    <braunr> no
-    <braunr> that's the really basic approach
-    <braunr> (and in practice it can happen of course)
-    <braunr> what really happens is that, for example, on linux, the user space
-      system call code is loaded as a virtual shared library
-    <braunr> use ldd on an executable to see it
-    <braunr> this virtual object provides code that, depending on what the
-      kernel has detected, will use the appropriate method to perform a system
-      call
-    <peo-xaci> but this user space system calls need to make some kind of cpu
-      interupt to communicate with the kernel, right?
-    <braunr> the glibc itself has no idea how a system call will look like in
-      the end
-    <braunr> yes
-    <peo-xaci> an assembler programmer would be able to get around this glue
-      code?
-    <braunr> that's precisely what is embedded in this virtual library
-    <braunr> it could yes
-    <braunr> i think even when sysenter/sysexit is supported, legacy traps are
-      still implemented to support old binaries
-    <braunr> but then all these different entry points will lead to the same
-      code inside the kernel
-    <peo-xaci> but when the glue code is used, then its API compatible, and
-      then I can understand that the kernel can allow different syscall
-      implementations for different executables
-    <braunr> what glue code ?
-    <peo-xaci> what you talked about above "the user space system call code is
-      loaded as a virtual shared library"
-    <braunr> let's call it vdso
-
-[[vDSO]]
-
-    <peo-xaci> thanks, I looked it up on Wikipedia and understand immediately
-      :P
-    <peo-xaci> so VDSOs are provided by the kernel, not a regular library file,
-      right?
-    <vdox2> What does HELL stand for :) ?
-    <dardevelin> vdox2,  Hurd Emulation Layer for Linux
-    <vdox2> dardevelin: thanks
-    <braunr> peo-xaci: yes
-    <antrik> peo-xaci: I believe your goals are conflicting. a low-level
-      implementation makes it basically impossible to interact between the HELL
-      environment and the GNU/Linux environment in any meaningful way. to allow
-      such interaction, you *have* to have some glue at a higher semantic level
-    <braunr> agreed
-    <antrik> peo-xaci: BTW, if you want regular Linux binaries to get somehow
-      redirected to access HELL facilities, there is already a framework (don't
-      remember the name right now) that allows this kind of system call
-      redirection on Linux
-    <antrik> (it can run both through LD_PRELOAD or as a kernel module -- where
-      obviously only the latter would allow raw system call redirection... but
-      TBH, I don't think that's worthwhile anyways. the rare cases where
-      programs use raw system calls are usually for extremely system-specific
-      stuff anyways...)
-    <antrik> ViewOS is the name
-    <antrik> err... View-OS I mean
-    <antrik> or maybe View OS ? ;-)
-    <antrik> whatever, you'll find it :-)
-
-[[Virtual_Square_View-OS]].
-
-    <antrik> I'm not sure it's really worthwhile to use this either
-      though... the most meaningful interaction is probably at the FS level,
-      and that can be done with FUSE
-    <antrik> OHOH, View-OS probably allows doing more interesting stuff that
-      FUSE, such as modyfing the way the VFS works...
-    <antrik> OTOH
-    <antrik> so it could expose more of the Hurd features, at least in theory
-
-
-## IRC, freenode, #hurd, 2012-10-13
-
-    <peo-xaci> antrik / braunr: thanks for your input! I'm not entirely
-      convinced though. :) I will probably return to this project once I have
-      acquired a lot more knowledge about low level stuff. I want to see for
-      myself whether a low level HELL is not feasible. :P
-    <braunr> peo-xaci: what's the point of a low level hell ?
-    <peo-xaci> more Hurd code can be tested in the hell, if the hell is at a
-      low level
-    <peo-xaci> at a higher level, some Hurd code cannot run, because the
-      interfaces they use would not be accessible from the higher level
-      emulation
-    <antrik> peo-xaci: I never said it's not possible. I actually said it would
-      be easier to do. I just said you can't do it low level *and* have
-      meaningful interaction with the host system
-    <peo-xaci> I don't understand why
-    <braunr> peo-xaci: i really don't see what you want to achieve with low
-      level support
-    <braunr> what would be unavailable with a higher level approach ?
diff --git a/open_issues/inotify_file_notice_changes.mdwn b/open_issues/inotify_file_notice_changes.mdwn
deleted file mode 100644
index 6d644788..00000000
--- a/open_issues/inotify_file_notice_changes.mdwn
+++ /dev/null
@@ -1,47 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-IRC, freenode, #hurd, 2011-03-28
-
-[[!tag open_issue_hurd]]
-
-    <barrucadu> I've been going through the xmlfs code, and plan to have it
-      monitor the backing store (xml file) for changes and update the presented
-      directory hierarchy when something is changed; is there a better way to
-      check a file for changes beyond checking its modification time every few
-      minutes?
-    <tschwinge> barrucadu: In the Hurd spirit, you'd use file_notice_changes
-      (fs.defs).
-    <barrucadu> thanks
-    <youpi> we should manage to work out an inotify interface around it, btw
-    <pochu> like gamin?
-    <pinotree> imho making gamin work should gain all the fam-using
-      applications
-    <pochu> (which, looking at the sources, seems to support hurd already, not
-      sure why it's not built)
-    <pinotree> pochu: the hurd_notify of gamin does not build OOTB
-    <pochu> > /build/buildd/gamin-0.1.10/./libgamin/gam_data.c:476: error:
-      'PTHREAD_MUTEX_RECURSIVE' undeclared (first use in this function)
-    <pinotree> there are few patches in bugzilla to make it compile
-    <pochu> if they work, and you point me to them, I can upload a new gamin
-      with them included
-    <pinotree> #315644, #588337. #605246
-    <pinotree> and iirc there's something else i have locally but not send yet
-    <pochu> please check and submit :)
-    <pinotree> ah no, those three contains all the build issues
-    <pinotree> .. plus relative proposed fixes
-    <pochu> ok, I'll try to get to it soonish
-    <pinotree> and you should know about two of them already ;D
-    <pochu> please remind me if I don't :)
-
----
-
-Apparently fanotify is cosidered inotify's successor, so we might directly go
-supporting that one instead, or both.  --[[tschwinge]], 2011-05-10
diff --git a/open_issues/issue_tracking.mdwn b/open_issues/issue_tracking.mdwn
deleted file mode 100644
index 72bb3b77..00000000
--- a/open_issues/issue_tracking.mdwn
+++ /dev/null
@@ -1,196 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-[[!toc]]
-
-
-# Savannah Trackers, Open Issues, debbugs
-
-There are the Savannah trackers.  Nobody really likes them.
-
-There is a proposal to add/move to <http://debbugs.gnu.org/>.  It can be
-operated by email, Debian people (developers and users) already know how to use
-it.
-
-There are the [[Open_Issues]] pages.  This is basically just free-form text
-enriched by some tags for grouping, editable via the web and through Git
-commit.  [[tschwinge]] added this to the set, and/but mostly is the sole user
-of it, even though casually there are a few other people contributing, and
-surely these pages do show up in web searches.  A more traditional system (like
-the Savannah trackers or the new debbugs) do have their advantages, too, so
-perhaps there's a niche for both these and the [[Open_Issues]].
-
-IRC, freenode, #hurd, 2011-08-31:
-
-    <tschwinge> So.  Savannah trackers vs. Open Issues vs. debbugs.  Any input?
-    <youpi> I like *both* open issues and debbugs
-    <youpi> open issues is good for exposing things that people may encounter
-      in other situations
-    <youpi> while debbugs is useful to actually work on a bug
-    <tschwinge> youpi: The advantage of debbugs being the email interface and
-      the well-known procedure, or something else?
-    <youpi> email interface, which nicely flows into a mailing list
-    <youpi> the savannah bug updates suffer from the additional layout
-    <tschwinge> How does one decide what to put in a debbug and what in an Open
-      Issue page?
-    <youpi> I'd say it's not exclusive at all
-    <youpi> like, a bug on a specific case can start as debbug, and as we
-      discover it's more general and will not be fixed immediately, get an open
-      issue page
-    <youpi> and conversely, when we know some shortcoming, start with an open
-      issue, and if some bugs are submitted which are actually due to it,
-      cross-link
-    <tschwinge> OK.
-    <youpi> (some general short coming I mean, like SIGINFO)
-    <tschwinge> And we would keep the current stuff in the trackers, and let
-      these ``get empty'' gradually (it'll be years...) ;-) or migrate the
-      remaining issues?
-    <tschwinge> What we can do is inhibiting the creation of new issues in the
-      trackers.
-    <youpi> I'd say move
-    <youpi> else they will be forgotten
-    <tschwinge> Hrm.
-    <antrik> actually, I considered creating a track-like plugin for ikiwiki,
-      as both the popularity of trac and the usefulness of open_issues show
-      that something wiki-like is actually more useful than a rigid traditional
-      bugtracker. but I'm not really willing to do the work, which is why I
-      didn't propose it before :-)
-    <antrik> err... trac-like
-    <youpi> yes, the wiki part is really useful to keep a good summary of the
-      issue
-    <tschwinge> antrik: Same for me.  I always hoped that someone would do
-      it...  :-)
-    <antrik> hehe
-    <tschwinge> antrik: But, as you surely know, this email parsing business is
-      just too ugly to do realiable, etc.
-    <antrik> youpi: my point is that adding a few additional bits (like a
-      comfortable tagging functionality, and some mail interface) could turn
-      into a full-blown tracker unifying the advantages of both... but as I
-      said, I'm not really willing to do the work :-)
-    <youpi> additional to open_issue you mean?
-    <youpi> yes, but like you say :)
-    <antrik> tschwinge: hm... seems to work well enough it debbugs
-    <youpi> debbugs just piles things
-    <youpi> and has a few commands
-    <youpi> you'd still need the web interface to edit the wiki part for
-      instance
-    <antrik> of course. that wouldn't change at all
-    <antrik> (except for adding a tagging GUI perhaps)
-    <antrik> (debbugs of course is not the only mail-operable bugtracking
-      system... there are a number of others -- and I heard rumors even
-      bugzilla grew a mail interface now...)
-    <youpi> antrik: a .mdwn diff should however be sent to the bug for
-      information
-    <youpi> atm, what happens sometimes is somebody saying something here on
-      #hurd, tschwinge turning that into an open_issue, and it does not show up
-      on the mailing list
-    <tschwinge> debbugs surely has the advantage that it is available (nearly)
-      right now.
-    <mattl> RT (request tracker) and ikiwiki play quite nicely together.
-    <tschwinge> mattl: You'Re using that at GNU/FSF/somewhere, right?
-    <mattl> you can close tickets from the wiki, and RT has a good command line
-      interface, email interface and web interface.
-    <mattl> tschwinge: yeah, we use RT and ikiwiki.
-    <mattl> RT for all FSF communications, and ikiwiki for internal organising.
-    <mattl> RT is not the easiest thing to set up, but works pretty well once
-      it's running.
-
-IRC, freenode, #hurd, 2011-10-19:
-
-    <antrik> tschwinge: BTW, what happened to the plan of killing help-hurd?
-    <antrik> (and possibly some other lists)
-    <tschwinge> antrik: That plan got stalled, obviously.  ;-)
-    <tschwinge> antrik: Now, I had proposed to use hurd-dev for development,
-      and turn bug-hurd into a debbugs bug reportling list.  That proposal has
-      not heard any supportive/unsupportive votes yet.
-    <tschwinge> hurd-devel.  That's the name.
-    <tschwinge> And turn off hurd-devel-readers.  And turn off help-hurd.
-    <tschwinge> And web-hurd.
-    <tschwinge> Keep l4-hurd.
-    <antrik> yeah, I haven't replied regarding bug-hurd vs. hurd-devel, as I'm
-      not quite sure myself
-    <antrik> on one hand, a dedicated bug list can be convenient; on the other
-      hand, this kind of splits always causes unnecessary overhead IMHO
-    <antrik> also, hurd-devel would obviously be *only* for development, so in
-      this scenario we actually would *need* to keep something like help-hurd
-      as well...
-    <antrik> I think I'd prefer the non-exclusive mode for debbugs... would
-      have to check again how it works exactly though :-)
-    <tschwinge> antrik: I quite liked that exclusive mode for it automatically
-      archives discussions grouped by threads for easy reference.
-    <tschwinge> antrik: And, the very most of bug-hurd emails are ``issues'' of
-      some sort: bug report, patch (that needs to be tracked until it is
-      applied, etc.
-    <antrik> tschwinge: exclusive mode would just mean that people would take
-      most of these discussion elsewhere, and the bug list would only be used
-      when someone explicitly wants something tracked as a bug...
-    <antrik> ideally, the bug tracker should only track things if explicitly
-      CCed. ideally, it should be possible to forward mails that have been
-      posted without CC, so they can be tracked retroactively...
-    <tschwinge> antrik: Why do you think that people would take discussions
-      elsewhere?
-    <antrik> because most people don't consider it useful to put every random
-      question or remark in an issue tracker
-    <antrik> IMHO it should be easy to turn messages into tickets/followups;
-      but it should not happen automatically
-    <tschwinge> What if people wouldn't even notice that their issues is kept
-      in a tracker, too?
-    <draculus> It might send a notification of some sort?
-    <antrik> I once posted to a list with RT in exclusive mode, and quite
-      frankly, I considered it rather strange to get a ticket created for my
-      message :-)
-    <antrik> tschwinge: that would only be useful if you always close tickets
-      for irrelevant or finished discussions, mark duplicates etc. -- and this
-      would have to happen silently, without noise for most other people
-      following the list...
-    <antrik> tschwinge: are you sure you want to do that?... :-)
-    <tschwinge> Yes.
-    <tschwinge> Because that way we don't lose so much stuff as we currently
-      do.
-    <antrik> well, the decision is up to you in that case...
-    <tschwinge> In fact, probably less than manually archiving the content, as
-      I'm doing now, partially.
-    <tschwinge> antrik: Well, I'm just out for getting some comments.
-    <antrik> it would further reduce our bus factor though :-(
-    <tschwinge> That already is low enough that it doesn't matter anymore...
-    <tschwinge> antrik: So, to sum up, you'd use non-exclusive mode, but are
-      not actively opposed to exclusive mode as long as it doesn't too much
-      disturbe any procedures you're currently using?
-    <antrik> well, if it happens mostly in the background, I don't see why
-      anyone should be opposed...
-    <antrik> just make sure people posting to the list don't get a "ticket
-      created" message in response :-)
-    <antrik> it would make it harder though for people to explicitly track
-      issue they are interested in I fear
-    <antrik> when using non-exclusive mode, and people explicitly CC things to
-      the tracker, which sends a notice about a ticket being created, everyone
-      sees that and can act accordingly. if everything happens in the
-      background, few people would even think about it...
-    <antrik> so non-exclusive mode probably needs more effort to keep in order;
-      but it would be more useful too...
-    <tschwinge> Well, but with exclusive mode, people don't lose anything
-      compared to the current state, do they?
-    <antrik> tschwinge: probably not compared to the current state... but
-      possibly compared to a well-used non-exclusive mode :-)
-
-
-# Further Systems
-
-  * ikiwiki
-
-      * <http://ikiwiki.info/tips/integrated_issue_tracking_with_ikiwiki/>
-
-      * <http://ikiwiki.info/todo/Better_bug_tracking_support/>
-
-      * <http://ikiwiki.info/todo/tracking_bugs_with_dependencies/>
-
-      * <http://ikiwiki.info/todo/Updated_bug_tracking_example/>
-
-  * <http://bugseverywhere.org/>
diff --git a/open_issues/keymap_mach_console.mdwn b/open_issues/keymap_mach_console.mdwn
deleted file mode 100644
index 3063dd00..00000000
--- a/open_issues/keymap_mach_console.mdwn
+++ /dev/null
@@ -1,40 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-IRC, freenode, #hurd, 2011-04-26
-
-    <guillem> pavkac: btw are you aware there's already some code to change the
-      keymap for the mach console (I think originally from the hurdfr guys, but
-      I cannot remember exactly from where I got it from :/)
-    <guillem> pavkac: http://www.hadrons.org/~guillem/tmp/hurd-keymap.tgz
-    <pavkac> guillem: No, I didn't know. I'll diff it and try to follow.
-    <guillem> pavkac: it would be nice to maybe integrate it properly into the
-      hurd
-    <guillem> you'll see the code is pretty basic, so extending it would be
-      nice too I guess :)
-    <pavkac> guillem: OK, I'll see to it. Unfortunately I'm quite busy this
-      week. Have a lot of homeworks to school. :/
-    <pavkac> guillem: But, I'll find some time during weekend.
-    <youpi> maybe it'd be simpler to add it to the hurd package and use that
-      from the console-setup package indeed
-    <youpi> but copyright issues should be solved
-    <youpi> unless we simply put this into hurdextras
-    <guillem> ok found this:
-      http://www.mail-archive.com/debian-hurd@lists.debian.org/msg02456.html
-    <guillem> and
-      http://www.mail-archive.com/debian-hurd@lists.debian.org/msg01173.html
-    <guillem> which seems to be the original Mark's code
-    <guillem> AFAIR I contributed the the spanish keymap and some additional
-      key definitions for loadkeys
-    <guillem> and http://lists.debian.org/debian-hurd/2000/10/msg00130.html
-    <pavkac> I've fetched all. :) But I must leave, good night if you're in
-      Europe. :)
-    <guillem> pavkac: the tarball I provided should be the latest, the others
-      are mostly to track the provenance of the source
diff --git a/open_issues/kvm.mdwn b/open_issues/kvm.mdwn
deleted file mode 100644
index 327f97ca..00000000
--- a/open_issues/kvm.mdwn
+++ /dev/null
@@ -1,37 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-Issues when running Hurd under KVM: un-synced filesystems, etc.  No problems
-with Virtualbox.
-
-2010-07-28, #hurd
-
-    <youpi> pochu: you were the one reporting issues with qemu/kvm and hurd, right?
-    <youpi> is your machine somehow smp (like multicore for instance)
-    <youpi> ?
-    <pochu> youpi: yes, it's a Core 2 Duo
-    <pochu> so 2 cores
-    <youpi> ok, you might want to try to bind qemu/kvm
-    <youpi> e.g. install hwloc, and prepend "hwloc-bind 1 --" before the qemu/kvm command line 
-    <pochu> ok, ty
-
-2010-07-31, GNU Mach commit 039176372b4271f370ef38eb2ee5d43923a5b28b.
-
-# KVM-on-KVM (nested KVM)
-
-This seems sluggish like hell. jenkins.debian.net suffers badly from it: it
-takes like an hour to complete the "Loading additional components" step.
-
-It's actually slower than just running qemu-on-KVM.
-
-This doesn't happen with Linux L2 guests.
-
-Date: Tue, 11 Nov 2014
-https://www.mail-archive.com/kvm@vger.kernel.org/msg109570.html
diff --git a/open_issues/largefile.mdwn b/open_issues/largefile.mdwn
deleted file mode 100644
index a6f76a0e..00000000
--- a/open_issues/largefile.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-[[!meta copyright="Copyright © 2012 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_hurd]]
-
-
-# IRC, freenode, #hurd, 2012-04-26
-
-    <pinotree> i kind of understood why (at least in some parts) largefile doesn't seem to work properly
-    <pinotree> libdiskfs/io-seek.c, SEEK_SET case: cred->po->filepointer = offset;
-    <pinotree> offset is off_t, which becomes off64_t when compiled with largefile, but filepointer seems to be... int
-    <pinotree> at least in libdiskfs/diskfs.h, while in libnetfs/netfs.h seems ok (loff_t)
-    <pinotree> diskfs.h is a public header though :/
-    <youpi> well, we can change the soname to mark ABI change
diff --git a/open_issues/latrace.mdwn b/open_issues/latrace.mdwn
deleted file mode 100644
index f5b7521e..00000000
--- a/open_issues/latrace.mdwn
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2013 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]]."]]"""]]
-
-Check whether <http://people.redhat.com/jolsa/latrace/> works.
-
-
-# See Also
-
-  * [[debugging]], [[profiling]]
diff --git a/open_issues/lexical_dot-dot.mdwn b/open_issues/lexical_dot-dot.mdwn
deleted file mode 100644
index 3299dfa0..00000000
--- a/open_issues/lexical_dot-dot.mdwn
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-[[!meta title="Lexical .. Resolution"]]
-
-[[!tag open_issue_glibc open_issue_hurd]]
-
-There is a [[!FF_project 279]][[!tag bounty]] on this task.
-
-
-# Original [[community/GSoC]] Task Description
-
-[[!inline pages=community/gsoc/project_ideas/lexical_dot-dot feeds=no]]
diff --git a/open_issues/libc_variant_selection.mdwn b/open_issues/libc_variant_selection.mdwn
deleted file mode 100644
index 71370a43..00000000
--- a/open_issues/libc_variant_selection.mdwn
+++ /dev/null
@@ -1,57 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 2013 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_porting]]
-
-There is a [[!FF_project 274]][[!tag bounty]] on this task.
-
-There are now specialized variants of Debian's libc package, libc0.3-i686 and
-libc0.3-xen.
-
-
-On Thu, Oct 07, 2010 at 11:22:46AM +0200, Samuel Thibault wrote:
-> Thomas Schwinge, le Thu 07 Oct 2010 10:11:07 +0200, a écrit :
-> > Also, this text says ``will be selected instead when running under Xen''
-> > -- is this meant to be automatically done?
->
-> It's supposed to be, we need to add support for it.
->
-> > If so, then it didn't work.
->
-> Yes, you need to copy it by hand. Same for libc0.3-i686, we just need to
-> steal the cpuid code from the kfreebsd port of glibc.
-
-
-# IRC, freenode, #hurd, 2013-06-30
-
-    <pinotree> other than that, the hwcap system is not working for us yet,
-      right?
-    <youpi> no but we'd like to use e.g. cpuid for that
-    <youpi> like kfreebsd does
-    <pinotree> do they use cpuid for that?
-    <pinotree> i kind of lost myself in glibc's loading internals, trying to
-      find out where the hwcap bits come from
-    <youpi> on linux it comes from the kernel
-    <youpi> on kfreebsd aiui they use cpuid to figure it out from the process
-      itself
-    <pinotree> do you have any pointer to the kfreebsd way? iirc i had a look
-      in their sysdeps, but found nothing related to that
-    <youpi> it's in local-sysdeps.diff aiui
-    <youpi> +dl_platform_kfreebsd_i386_init
-    <youpi> which fills dl_hwcap
-    <youpi> called at _dl_sysdep_start
-    <pinotree> interesting
-
-
----
-
-Having working CPUID code inside [[glibc]] is also a prerequisite for proper
-[[IFUNC]] support.
diff --git a/open_issues/libdiskfs_dot_dot-dot_relevant_for_libnetfs.mdwn b/open_issues/libdiskfs_dot_dot-dot_relevant_for_libnetfs.mdwn
deleted file mode 100644
index 1e4a6acb..00000000
--- a/open_issues/libdiskfs_dot_dot-dot_relevant_for_libnetfs.mdwn
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_hurd]]
-
-IRC, unknown channel, unknown date.
-
-    <tschwinge> By the way: your libdiskfs ., .. fix -- is that relevant for libnetfs as well?  (Didn't look it up so far.)
-    <youpi> it could be a good idea to protect netfs users directly from there yes
-    <tschwinge> But probably the backend (e.g., NFS server) would protect us in the netfs case, right?
-    <youpi> possibly, but we could have locking issues in between like in libdiskfs
-    <youpi> and POSIX says it's invalid anyway
-    <youpi> so we'd probably better just forbid it
diff --git a/open_issues/libfshelp_in_hurdlibs.mdwn b/open_issues/libfshelp_in_hurdlibs.mdwn
deleted file mode 100644
index 0700b061..00000000
--- a/open_issues/libfshelp_in_hurdlibs.mdwn
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2009 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]]."]]"""]]
-
-[[!meta title="libfshelp in HURDLIBS"]]
-
-[[!tag open_issue_hurd]]
-
-[[hurd/libtrivfs]] seems to use [[hurd/libfshelp]], but doesn't have it listed
-in `HURDLIBS`.  Should we change that?  Same for [[hurd/libnetfs]] and
-[[hurd/libdiskfs]]?
diff --git a/open_issues/libgomp_pthread_attr_setstacksize_pthread_stack_min.mdwn b/open_issues/libgomp_pthread_attr_setstacksize_pthread_stack_min.mdwn
deleted file mode 100644
index 817dac76..00000000
--- a/open_issues/libgomp_pthread_attr_setstacksize_pthread_stack_min.mdwn
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_libpthread]]
-
-IRC, unknown channel, unknown date:
-
-    <azeem> neal: libgomp (GNU's implementation of OpenMP) uses PTHREAD_STACK_MIN, which we do not define apparently
-    <neal> azeem: We have fixed sized stacks.
-    <neal> so the pthread_attr_setstacksize will fail once you define PTHREAD_STACK_MIN)
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
diff --git a/open_issues/libnetfs_io_map.mdwn b/open_issues/libnetfs_io_map.mdwn
deleted file mode 100644
index dc6da202..00000000
--- a/open_issues/libnetfs_io_map.mdwn
+++ /dev/null
@@ -1,42 +0,0 @@
-[[!meta copyright="Copyright © 2012 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]]."]]"""]]
-
-[[!meta title="libnetfs: io_map"]]
-
-[[!tag open_issue_hurd]]
-
-This hampers [[hurd/translator/nfs]] usability, for example:
-
-    $ fsysopts ./
-    /hurd/nfs [...]
-    $ cp -a /bin/true ./
-    cp: failed to preserve authorship for `./true': Operation not supported
-    $ ./true
-    $ /lib/ld.so /bin/true
-    $ /lib/ld.so $PWD/true
-    [...]/true: error while loading shared libraries: [...]/true: failed to map segment from shared object: Error 1073741869
-
-IRC, freenode, #hurd, 2012-03-14:
-
-    <civodul> i just realized that ld.so uses mmap unconditionally
-    <civodul> so executables or shared libs can't be used off a netfs-based
-      file system
-    <civodul> that's annoying
-    <tschwinge> civodul: Do you know what it takes to fix libnetfs?  I have no
-      idea.
-    <tschwinge> Never looked at it.
-    <civodul> tschwinge: implementing io_map
-    <civodul> but i think the idea is that io_map typically isn't convenient
-      for network file systems
-    <civodul> which is why it doesn't have it
-    <civodul> the GCS says "thou shall not require mmap" ;-)
-
-<http://lists.gnu.org/archive/html/bug-hurd/2001-10/msg00306.html>.  Analysis
-to be found on [[glibc/mmap]] page.
diff --git a/open_issues/libnetfs_passive_translators.mdwn b/open_issues/libnetfs_passive_translators.mdwn
deleted file mode 100644
index c89d27f7..00000000
--- a/open_issues/libnetfs_passive_translators.mdwn
+++ /dev/null
@@ -1,55 +0,0 @@
-[[!meta copyright="Copyright © 2013 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_hurd]]
-
-
-# IRC, freenode, #hurd, 2013-07-15
-
-    <teythoon> is there a libnetfs based translator that supports passive
-      translators?
-    <youpi> I don't see any at the top of my head, only with active ones such
-      as hostmux
-    <teythoon> I suspected as much since as far as I can tell libnetfs lacks
-      some bits to make that even work
-    <braunr> teythoon: the problem with passive translators is persistence
-    <braunr> well, it's easy to store volatile passive translators in a
-      libnetfs server
-    <braunr> but usually, there is no backing store for them
-    <braunr> ext2fs is the only one actually providing space to store their
-      command line
-    <teythoon> sure, but at least file_get_translator needs to work so that
-      procfs can serve a mounts node
-    <braunr> silly idea but
-    <braunr> don't you want to directly add it to the procfs translator ?
-    <teythoon> no, I think it's useful on its own
-    <braunr> ok
-    <braunr> then you may need to add the required support
-    <teythoon> it even doubles as normal command line tool
-    <teythoon> yes, I almost got it... or so I hope ;)
-    <braunr> ok
-    <teythoon> also, netfs_get_translator exists, so not supporting that feels
-      like a bug to me
-    <teythoon> could also be useful for a potential devfs translator
-    <braunr> yes
-
-    <teythoon> uh, the code duplication in lib*fs is really bad :/
-    <teythoon> the code is mostly similar, though they have diverged and many
-      little things are different so diffing them is very noisy
-    <teythoon> stuff like file names or identifiers
-    <teythoon> and I cannot figure out why my shiny passive translators are not
-      started :/
-    <teythoon> % showtrans tmp/mounts
-    <teythoon> /hurd/mtab.fixed /
-    <teythoon> % wc --bytes tmp/mounts
-    <teythoon> 0 tmp/mounts
-    <teythoon> and no mtab translator around either
-
-[[hurd/translator/mtab/discussion]].
diff --git a/open_issues/libnetfs_vs_libdiskfs.mdwn b/open_issues/libnetfs_vs_libdiskfs.mdwn
deleted file mode 100644
index 2fcfbea5..00000000
--- a/open_issues/libnetfs_vs_libdiskfs.mdwn
+++ /dev/null
@@ -1,118 +0,0 @@
-[[!meta copyright="Copyright © 2013 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_hurd]]
-
-[[!toc]]
-
-
-# Argument Parsing
-
-## IRC, freenode, #hurd, 2013-06-27
-
-    <teythoon> the arg parsing in libdiskfs and libnetfs differ :/
-    <teythoon> afaics libdiskfs gets it right, libnetfs does not
-    <pinotree> what do you mean?
-    <teythoon> wrt to *_std_{runtime,startup}_argp
-    <teythoon> see eg netfs.h
-    <teythoon> libdiskfs/opts-std-runtime.c:const struct argp
-      diskfs_std_runtime_argp =
-    <teythoon> libdiskfs/opts-std-runtime.c-{
-    <teythoon> libdiskfs/opts-std-runtime.c-  std_runtime_options, parse_opt,
-      0, 0, children
-    <teythoon> libdiskfs/opts-std-runtime.c-};
-    <teythoon> but
-    <teythoon> libnetfs/std-runtime-argp.c:const struct argp
-      netfs_std_runtime_argp = { 0 };
-    <pinotree> well there are no common startup/runtime options provided by
-      netfs
-    <pinotree> usually netfs-based translators put netfs_std_startup_argp as
-      child as their options, so if netfs starts providing options they would
-      work
-    <teythoon> ah
-    <pinotree> if you have a test showing issues, we can certainly look it :)
-    <teythoon> ok, m/b I was confused...
-    <pinotree> no worries, feel free to ask anytime
-    <teythoon> I thought about providing --update as common runtime flag, like
-      diskfs does, you think it's the right thing to do?
-    <pinotree> what would it do?
-    <teythoon> or should it be left for each translator to implement?
-    <teythoon> nothing by default I guess
-    <pinotree> options provided in libdiskfs are implemented and handled mostly
-      in libdiskfs itself
-    <pinotree> so imho a new option for libnetfs would be there because its
-      behaviour is implemented mostly within libnetfs itself
-    <teythoon> libdiskfs calls diskfs_reload_global_state
-    <teythoon> libnetfs could do the same, allowing translators to plug in
-      anything they wish
-    <teythoon> but I'll implement it in procfs for the time being
-    <pinotree> ah, its alias is remount
-    <teythoon> yes
-    <teythoon> I need that working for procfs
-    <teythoon> btw, I think I got your mount confusion thing figured out
-    <pinotree> but procfs has nothing to update/flush, all the information are
-      fetched at every rpc
-    <teythoon> yes
-    <teythoon> but we still need to ignore the flag
-    <teythoon> otherwise the set_options rpc fails
-    <teythoon> http://paste.debian.net/12938/
-    <teythoon> whee, remounting proc works :)
-    <braunr> :)
-
-
-# IRC, freenode, #hurd, 2013-07-29
-
-    <teythoon> so, what do you folks think about refactoring libdiskfs and
-      libnetfs to be more alike?
-    <pinotree> what do you mean?
-    <teythoon> ah, I mentioned that in the context of my mtab prototype
-      1374247519-26589-1-git-send-email-4winter@informatik.uni-hamburg.de
-    <teythoon> they are hard to diff against each other b/c they differ in file
-      names and identifier names
-    <teythoon> while working on the mtab stuff I encountered stuff that was
-      implemented in libdiskfs, but never in libnetfs
-    <teythoon> mostly support for binding translators to libnetfs nodes
-    <braunr> teythoon: sure, but looks a little out of scope
-    <teythoon> braunr: I do not mean now, more in general
-    <braunr> ok
-    <tschwinge> teythoon: I wondered about this, too.  I don't know if it's
-      possible to literally merge them (and build the backend-based (libdiskfs)
-      vs. volatile-backend one (libnetfs) based on a pre-processor define or
-      similar), or just structure the source code (files) in a way such that
-      »diff -ru libdiskfs/ libnetfs/« gives meaningful results, figuratively
-      spoken.
-    <teythoon> tschwinge: my thoughts exactly
-
-
-# IRC, freenode, #hurd, 2013-08-28
-
-    <teythoon> braunr: do you think another lib*fs would be frowned uppon? I
-      like the way procfs is structured and that could be refactored and
-      generalized into a library
-    <braunr> i think we need more lib*fs libraries
-    <braunr> and better integration
-    <braunr> that's one of the strengths in linux
-    <braunr> it makes writing file systems very easy
-    <teythoon> cool :)
-    <teythoon> now we only need a snappy name, any suggestions?
-    <braunr> i don't know what you like specificlaly in procfs
-    <braunr> libpseudofs ?
-    <teythoon> well, it's not perfect, but i like the way you just have to
-      implement a function for a node and it magically gains the ability to
-      being read
-    <teythoon> for example
-    <braunr> yes i see
-    <pinotree> lacks a bit of caching though
-    <braunr> no caching for such file systems
-    <teythoon> indeed
-    <braunr> why would you want caching ?
-    <pinotree> you might have files that don't change at all, or rarely do
-    <braunr> the premise is that it's meant for files generated on the fly
-    <braunr> but are they big ?
diff --git a/open_issues/libnfs.mdwn b/open_issues/libnfs.mdwn
deleted file mode 100644
index 8cadefa4..00000000
--- a/open_issues/libnfs.mdwn
+++ /dev/null
@@ -1,28 +0,0 @@
-[[!meta copyright="Copyright © 2012 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_hurd]]
-
-IRC, freenode, #hurd, 2012-01-09:
-
-    <pinotree> https://github.com/sahlberg/libnfs ← maybe it could be used for
-      nfs support, instead of the rpc stuff "removed" in newer glibc versions
-    <antrik> pinotree: sounds like it could do much more than just the RPC
-      stuff -- definitely interesting :-)
-    <pinotree> hm but it seems to be an abstraction over either classic rpc or
-      tirpc
-    <pinotree> (anyway, it is packaged already in debian)
-    <antrik> good licensing too
-    <antrik> I guess I'll modify the GSoC task to "rework the Hurd NFS client
-      to use libnfs" :-)
-    <pinotree> the nfs translator?
-    <antrik> yes
-
-[[hurd/translator/nfs]]
diff --git a/open_issues/libpager_deadlock.mdwn b/open_issues/libpager_deadlock.mdwn
deleted file mode 100644
index 017ecff6..00000000
--- a/open_issues/libpager_deadlock.mdwn
+++ /dev/null
@@ -1,165 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2012 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_hurd]]
-
-Deadlocks in libpager/periodic sync have been found.
-
-
-# [[gnumach_page_cache_policy]]
-
-
-## IRC, freenode, #hurd, 2012-07-12
-
-    <braunr> ah great, a paper about the mach pageout daemon !
-    <mcsim> braunr: Where is paper about the mach pageout daemon?
-    <braunr> ftp://ftp.cs.cmu.edu/project/mach/doc/published/defaultmm.ps
-    <braunr> might give us a clue about the swap deadlock (although i still
-      have a few ideas to check)
-    <braunr>
-      http://www.sceen.net/~rbraun/moving_the_default_memory_manager_out_of_the_mach_kernel.pdf
-    <braunr> we should more seriously consider sergio's advisory pageout branch
-      some day
-    <braunr> i'll try to get in touch with him about that before he completely
-      looses interest
-    <braunr> i'll include it in my "make that page cache as decent as possible"
-      task
-    <braunr> many of his comments match what i've seen
-    <braunr> and we both did a few optimizations the same way
-    <braunr> (like not deactivating pages when they enter the cache)
-
-
-## IRC, freenode, #hurd, 2012-07-13
-
-    <braunr> antrik: i'm able to consistently reproduce the swap deadlocks you
-      regularly had when using apt with my page cache patch
-    <braunr> it happens when lots of dirty pages are write back to their pagers
-    <braunr> so apt, or a big file copy or anything that writes several MiB
-      very quickly is a good candidate
-    <braunr> written*
-    <antrik> braunr: nice...
-    <braunr> antrik: well in a way, yes, as it will allow us to track it more
-      easily
-
-
-## IRC, freenode, #hurd, 2012-07-15
-
-    <braunr> oh btw, i think i can say with confidence that the hurd *doesn't*
-      deadlock
-    <braunr> (at least, concerning swapping)
-    <braunr> lol, one of my hurd systems has been hitting the "swap deadlock"
-      for more than an hour, and suddenly got out of it
-    <braunr> something is really wrong in the pageout daemon, but it's not a
-      deadlock
-    <youpi> a livelock then
-    <braunr> do you get out of livelocks ?
-    <braunr> i mean, it's not even a "lock"
-    <braunr> just a big damn tricky slowdown 
-    <youpi> yes, you can, by giving a few more resources for instance
-    <youpi> depends on the kind of livelock of course
-    <braunr> i think it's that
-    <braunr> the pageout daemon clearly throttles itself, waiting for pagers to
-      complete
-    <braunr> and another dangerous thing is the line in vm_resident, which only
-      wakes on thread to avoid starvation
-    <braunr> hum, during the livelock, the kernel spends much time waiting in
-      db_read_address
-    <braunr> could be a bad stack
-    <braunr> so, the pageout daemon seems to slow itself as much as waiting
-      several seconds between each iteration when under load
-    <braunr> but each iteration possibly removes clean pages
-    <braunr> so at some point, there is enough memory to unblock waiting pagers
-    <braunr> for now i'll try a simple solution, like limiting the pausing
-      delay
-    <braunr> but we'll need more page lists in the future (inactive-clean,
-      inactive-dirty, etc..)
-    <braunr> limiting the amount of dirty pages is the only way to really make
-      it safe actually
-    <braunr> wow, the pageout loop is still running even after many pages were
-      freed, and it unable to free more pages
-    <braunr> i think i have an idea about the livelock
-    <braunr> i think it comes from the periodic syncing
-    <bddebian> Too often?
-    <braunr> that's not the problem
-    <braunr> the problem is that it can happen at the same time with paging
-    <bddebian> Oh
-    <braunr> if paging gets slow, it won't stop the periodic syncing
-    <braunr> which will grab any page it can as soon as some are free
-    <braunr> but then, before it even finishes, another sync may occur
-    <braunr> i have yet to check that it is possible
-    <braunr> and i don't understand why syncing isn't done by the kernel
-    <braunr> the kernel is supposed to handle the paging policy
-    <braunr> and it would make paging really scale
-    <bddebian> It's done on the Hurd side?
-    <braunr> (instead of having external pagers make one request for each
-      object, even if they're clean)
-    <braunr> yes
-    <bddebian> Hmm, interesting
-    <braunr> ofc, with ext2fs --debug, i can't reproduce anything
-    <bddebian> Ugh
-    <braunr> sync are serialized
-    <braunr> grmbl
-    <braunr> there is a big lock taken at sync time though
-    <braunr> uhg
-
-
-## IRC, freenode, #hurd, 2012-07-16
-
-    <braunr> all right so, there *is* a deadlock, and it may be due to the
-      default pager actually
-    <braunr> the vm_page_laundry_count doesn't decrease at some point, even
-      when there are more than enough free pages
-    <braunr> antrik: the thing is, i think the deadlock concerns the default
-      pager
-    <antrik> the deadlock?
-    <braunr> yes
-    <braunr> when swapping
-
-
-## IRC, freenode, #hurd, 2012-07-17
-
-    <braunr> i can't even reproduce the swap deadlock when using upstrea ext2fs
-      :(
-    <braunr> upstream*
-
-
-## IRC, freenode, #hurd, 2012-07-19
-
-    <braunr> the libpager deadlock patch looks wrong to me
-    <braunr> hm no, the libpager patch is ok acually
-
-
-## [[synchronous_ipc]]
-
-### IRC, freenode, #hurd, 2012-07-20
-
-    <braunr> but actually after reviewing more, the debian patch for this
-      particular issue seems correct
-    <antrik> well, it's most probably done by youpi, so I would be shocked if
-      it wasn't correct... ;-)
-    <braunr> he wasn't sure at all about it
-    <antrik> still ;-)
-    <braunr> :)
-    <antrik> well, if you also think it's correct, I guess it's time to push it
-      upstream...
-
-
-## IRC, freenode, #hurd, 2012-07-23
-
-    <braunr> i still can't conclude if we have any pageout deadlock, or if it's
-      simply a side effect of the active and inactive lists getting very very
-      large
-    <braunr> but almost every time this issue happens, it somehow recovers,
-      sometimes hours later
-
-
-# See Also
-
-  * [[ext2fs_deadlock]]
diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn
deleted file mode 100644
index 0294b008..00000000
--- a/open_issues/libpthread.mdwn
+++ /dev/null
@@ -1,2414 +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_libpthread]]
-
-[[!toc]]
-
-
-# cthreads -> pthreads
-
-Get rid of cthreads; switch to pthreads.
-Most of the issues raised on this page has been resolved, a few remain.
-
-
-## IRC, freenode, #hurd, 2012-04-26
-
-    <pinotree> youpi: just to be sure: even if libpthread is compiled inside
-      glibc (with proper symbols forwarding etc), it doesn't change that you
-      cannot use both cthreads and pthreads in the same app, right?
-
-[[Packaging_libpthread]].
-
-    <youpi> it's the same libpthread
-    <youpi> symbol forwarding does not magically resolve that libpthread lacks
-      some libthread features :)
-    <pinotree> i know, i was referring about the clash between actively using
-      both
-    <youpi> there'll still be the issue that only one will be initialized
-    <youpi> and one that provides libc thread safety functions, etc.
-    <pinotree> that's what i wanted to knew, thanks :)
-
-
-## IRC, freenode, #hurd, 2012-07-23
-
-    <bddebian> So I am not sure what to do with the hurd_condition_wait stuff
-    <braunr> i would also like to know what's the real issue with cancellation
-      here
-    <braunr> because my understanding is that libpthread already implements it
-    <braunr> does it look ok to you to make hurd_condition_timedwait return an
-      errno code (like ETIMEDOUT and ECANCELED) ?
-    <youpi> braunr: that's what pthread_* function usually do, yes
-    <braunr> i thought they used their own code
-    <youpi> no
-    <braunr> thanks
-    <braunr> well, first, do you understand what hurd_condition_wait is ?
-    <braunr> it's similar to condition_wait or pthread_cond_wait with a subtle
-      difference
-    <braunr> it differs from the original cthreads version by handling
-      cancellation
-    <braunr> but it also differs from the second by how it handles cancellation
-    <braunr> instead of calling registered cleanup routines and leaving, it
-      returns an error code
-    <braunr> (well simply !0 in this case)
-    <braunr> so there are two ways
-    <braunr> first, change the call to pthread_cond_wait
-    <bddebian> Are you saying we could fix stuff to use pthread_cond_wait()
-      properly?
-    <braunr> it's possible but not easy
-    <braunr> because you'd have to rewrite the cancellation code
-    <braunr> probably writing cleanup routines
-    <braunr> this can be hard and error prone
-    <braunr> and is useless if the code already exists
-    <braunr> so it seems reasonable to keep this hurd extension
-    <braunr> but now, as it *is* a hurd extension noone else uses
-    <antrik> braunr: BTW, when trying to figure out a tricky problem with the
-      auth server, cfhammer digged into the RPC cancellation code quite a bit,
-      and it's really a horrible complex monstrosity... plus the whole concept
-      is actually broken in some regards I think -- though I don't remember the
-      details
-    <braunr> antrik: i had the same kind of thoughts
-    <braunr> antrik: the hurd or pthreads ones ?
-    <antrik> not sure what you mean. I mean the RPC cancellation code -- which
-      is involves thread management too
-    <braunr> ok
-    <antrik> I don't know how it is related to hurd_condition_wait though
-    <braunr> well i found two main entry points there
-    <braunr> hurd_thread_cancel and hurd_condition_wait
-    <braunr> and it didn't look that bad
-    <braunr> whereas in the pthreads code, there are many corner cases
-    <braunr> and even the standard itself looks insane
-    <antrik> well, perhaps the threading part is not that bad...
-    <antrik> it's not where we saw the problems at any rate :-)
-    <braunr> rpc interruption maybe ?
-    <antrik> oh, right... interruption is probably the right term
-    <braunr> yes that thing looks scary
-    <braunr> :))
-    <braunr> the migration thread paper mentions some things about the problems
-      concerning threads controllability
-    <antrik> I believe it's a very strong example for why building around
-      standard Mach features is a bad idea, instead of adapting the primitives
-      to our actual needs...
-    <braunr> i wouldn't be surprised if the "monstrosities" are work arounds
-    <braunr> right
-
-
-## IRC, freenode, #hurd, 2012-07-26
-
-    <bddebian> Uhm, where does /usr/include/hurd/signal.h come from?
-    <pinotree> head -n4 /usr/include/hurd/signal.
-    <pinotree> h
-    <bddebian> Ohh glibc?
-    <bddebian> That makes things a little more difficult :(
-    <braunr> why ?
-    <bddebian> Hurd includes it which brings in cthreads
-    <braunr> ?
-    <braunr> the hurd already brings in cthreads
-    <braunr> i don't see what you mean
-    <bddebian> Not anymore :)
-    <braunr> the system cthreads header ?
-    <braunr> well it's not that difficult to trick the compiler not to include
-      them
-    <bddebian> signal.h includes cthreads.h  I need to stop that
-    <braunr> just define the _CTHREADS_ macro before including anything
-    <braunr> remember that header files are normally enclosed in such macros to
-      avoid multiple inclusions
-    <braunr> this isn't specific to cthreads
-    <pinotree> converting hurd from cthreads to pthreads will make hurd and
-      glibc break source and binary compatibility
-    <bddebian> Of course
-    <braunr> reminds me of the similar issues of the late 90s
-    <bddebian> Ugh, why is he using _pthread_self()?
-    <pinotree> maybe because it accesses to the internals
-    <braunr> "he" ?
-    <bddebian> Thomas in his modified cancel-cond.c
-    <braunr> well, you need the internals to implement it
-    <braunr> hurd_condition_wait is similar to pthread_condition_wait, except
-      that instead of stopping the thread and calling cleanup routines, it
-      returns 1 if cancelled
-    <pinotree> not that i looked at it, but there's really no way to implement
-      it using public api?
-    <bddebian> Even if I am using glibc pthreads?
-    <braunr> unlikely
-    <bddebian> God I had all of this worked out before I dropped off for a
-      couple years.. :(
-    <braunr> this will come back :p
-    <pinotree> that makes you the perfect guy to work on it ;)
-    <bddebian> I can't find a pt-internal.h anywhere.. :(
-    <pinotree> clone the hurd/libpthread.git repo from savannah
-    <bddebian> Of course when I was doing this libpthread was still in hurd
-      sources...
-    <bddebian> So if I am using glibc pthread, why can't I use pthread_self()
-      instead?
-    <pinotree> that won't give you access to the internals
-    <bddebian> OK, dumb question time.  What internals?
-    <pinotree> the libpthread ones
-    <braunr> that's where you will find if your thread has been cancelled or
-      not
-    <bddebian> pinotree: But isn't that assuming that I am using hurd's
-      libpthread?
-    <pinotree> if you aren't inside libpthread, no
-    <braunr> pthread_self is normally not portable
-    <braunr> you can only use it with pthread_equal
-    <braunr> so unless you *know* the internals, you can't use it
-    <braunr> and you won't be able to do much
-    <braunr> so, as it was done with cthreads, hurd_condition_wait should be
-      close to the libpthread implementation
-    <braunr> inside, normally
-    <braunr> now, if it's too long for you (i assume you don't want to build
-      glibc)
-    <braunr> you can just implement it outside, grabbing the internal headers
-      for now
-    <pinotree> another "not that i looked at it" question: isn't there no way
-      to rewrite the code using that custom condwait stuff to use the standard
-      libpthread one?
-    <braunr> and once it works, it'll get integrated
-    <braunr> pinotree: it looks very hard
-    <bddebian> braunr: But the internal headers are assuming hurd libpthread
-      which isn't in the source anymore
-    <braunr> from what i could see while working on select, servers very often
-      call hurd_condition_wait
-    <braunr> and they return EINTR if canceleld
-    <braunr> so if you use the standard pthread_cond_wait function, your thread
-      won't be able to return anything, unless you push the reply in a
-      completely separate callback
-    <braunr> i'm not sure how well mig can cope with that
-    <braunr> i'd say it can't :)
-    <braunr> no really it looks ugly
-    <braunr> it's far better to have this hurd specific function and keep the
-      existing user code as it is
-    <braunr> bddebian: you don't need the implementation, only the headers
-    <braunr> the thread, cond, mutex structures mostly
-    <bddebian> I should turn <pt-internal.h> to "pt-internal.h" and just put it
-      in libshouldbelibc, no?
-    <pinotree> no, that header is not installed
-    <bddebian> Obviously not the "best" way
-    <bddebian> pinotree: ??
-    <braunr> pinotree: what does it change ?
-    <pinotree> braunr: it == ?
-    <braunr> bddebian: you could even copy it entirely in your new
-      cancel-cond.C and mention where it was copied from
-    <braunr> pinotree: it == pt-internal.H not being installed
-    <pinotree> that he cannot include it in libshouldbelibc sources?
-    <pinotree> ah, he wants to copy it?
-    <braunr> yes
-    <braunr> i want him to copy it actually :p
-    <braunr> it may be hard if there are a lot of macro options
-    <pinotree> the __pthread struct changes size and content depending on other
-      internal sysdeps headers
-    <braunr> well he needs to copy those too :p
-    <bddebian> Well even if this works we are going to have to do something
-      more "correct" about hurd_condition_wait.  Maybe even putting it in
-      glibc?
-    <braunr> sure
-    <braunr> but again, don't waste time on this for now
-    <braunr> make it *work*, then it'll get integrated
-    <bddebian> Like it has already?  This "patch" is only about 5 years old
-      now... ;-P
-    <braunr> but is it complete ?
-    <bddebian> Probably not :)
-    <bddebian> Hmm, I wonder how many undefined references I am going to get
-      though.. :(
-    <bddebian> Shit, 5
-    <bddebian> One of which is ___pthread_self.. :(
-    <bddebian> Does that mean I am actually going to have to build hurds
-      libpthreads in libshouldbeinlibc?
-    <bddebian> Seriously, do I really need ___pthread_self, __pthread_self,
-      _pthread_self and pthread_self???
-    <bddebian> I'm still unclear what to do with cancel-cond.c.  It seems to me
-      that if I leave it the way it is currently I am going to have to either
-      re-add libpthreads or still all of the libpthreads code under
-      libshouldbeinlibc.
-    <braunr> then add it in libc
-    <braunr> glib
-    <braunr> glibc
-    <braunr> maybe under the name __hurd_condition_wait
-    <bddebian> Shouldn't I be able to interrupt cancel-cond stuff to use glibc
-      pthreads?
-    <braunr> interrupt ?
-    <bddebian> Meaning interject like they are doing.  I may be missing the
-      point but they are just obfuscating libpthreads thread with some other
-      "namespace"?  (I know my terminology is wrong, sorry).
-    <braunr> they ?
-    <bddebian> Well Thomas in this case but even in the old cthreads code,
-      whoever wrote cancel-cond.c
-    <braunr> but they use internal thread structures ..
-    <bddebian> Understood but at some level they are still just getting to a
-      libpthread thread, no?
-    <braunr> absolutely not ..
-    <braunr> there is *no* pthread stuff in the hurd
-    <braunr> that's the problem :p
-    <bddebian> Bah damnit...
-    <braunr> cthreads are directly implement on top of mach threads
-    <braunr> implemeneted*
-    <braunr> implemented*
-    <bddebian> Sure but hurd_condition_wait wasn't
-    <braunr> of course it is
-    <braunr> it's almost the same as condition_wait
-    <braunr> but returns 1 if a cancelation request was made
-    <bddebian> Grr, maybe I am just confusing myself because I am looking at
-      the modified (pthreads) version instead of the original cthreads version
-      of cancel-cond.c
-    <braunr> well if the modified version is fine, why not directly use that ?
-    <braunr> normally, hurd_condition_wait should sit next to other pthread
-      internal stuff
-    <braunr> it could be renamed __hurd_condition_wait, i'm not sure
-    <braunr> that's irrelevant for your work anyway
-    <bddebian> I am using it but it relies on libpthread and I am trying to use
-      glibc pthreads
-    <braunr> hum
-    <braunr> what's the difference between libpthread and "glibc pthreads" ?
-    <braunr> aren't glibc pthreads the merged libpthread ?
-    <bddebian> quite possibly but then I am missing something obvious.  I'm
-      getting ___pthread_self in libshouldbeinlibc but it is *UND*
-    <braunr> bddebian: with unmodified binaries ?
-    <bddebian> braunr: No I added cancel-cond.c to libshouldbeinlibc
-    <bddebian> And some of the pt-xxx.h headers
-    <braunr> well it's normal then
-    <braunr> i suppose
-    <bddebian> braunr: So how do I get those defined without including
-      pthreads.c from libpthreads? :)
-    <antrik> pinotree: hm... I think we should try to make sure glibc works
-      both whith cthreads hurd and pthreads hurd. I hope that shoudn't be so
-      hard.
-    <antrik> breaking binary compatibility for the Hurd libs is not too
-      terrible I'd say -- as much as I'd like that, we do not exactly have a
-      lot of external stuff depending on them :-)
-    <braunr> bddebian: *sigh*
-    <braunr> bddebian: just add cancel-cond to glibc, near the pthread code :p
-    <bddebian> braunr: Wouldn't I still have the same issue?
-    <braunr> bddebian: what issue ?
-    <antrik> is hurd_condition_wait() the name of the original cthreads-based
-      function?
-    <braunr> antrik: the original is condition_wait
-    <antrik> I'm confused
-    <antrik> is condition_wait() a standard cthreads function, or a
-      Hurd-specific extension?
-    <braunr> antrik: as standard as you can get for something like cthreads
-    <bddebian> braunr: Where hurd_condition_wait is looking for "internals" as
-      you call them.  I.E. there is no __pthread_self() in glibc pthreads :)
-    <braunr> hurd_condition_wait is the hurd-specific addition for cancelation
-    <braunr> bddebian: who cares ?
-    <braunr> bddebian: there is a pthread structure, and conditions, and
-      mutexes
-    <braunr> you need those definitions
-    <braunr> so you either import them in the hurd
-    <antrik> braunr: so hurd_condition_wait() *is* also used in the original
-      cthread-based implementation?
-    <braunr> or you write your code directly where they're available
-    <braunr> antrik: what do you call "original" ?
-    <antrik> not transitioned to pthreads
-    <braunr> ok, let's simply call that cthreads
-    <braunr> yes, it's used by every hurd servers
-    <braunr> virtually
-    <braunr> if not really everyone of them
-    <bddebian> braunr: That is where you are losing me.  If I can just use
-      glibc pthreads structures, why can't I just use them in the new pthreads
-      version of cancel-cond.c which is what I was originally asking.. :)
-    <braunr> you *have* to do that
-    <braunr> but then, you have to build the whole glibc
-    * bddebian shoots himself
-    <braunr> and i was under the impression you wanted to avoid that
-    <antrik> do any standard pthread functions use identical names to any
-      standard cthread functions?
-    <braunr> what you *can't* do is use the standard pthreads interface
-    <braunr> no, not identical
-    <braunr> but very close
-    <braunr> bddebian: there is a difference between using pthreads, which
-      means using the standard posix interface, and using the glibc pthreads
-      structure, which means toying with the internale implementation
-    <braunr> you *cannot* implement hurd_condition_wait with the standard posix
-      interface, you need to use the internal structures
-    <braunr> hurd_condition_wait is actually a shurd specific addition to the
-      threading library
-    <braunr> hurd*
-    <antrik> well, in that case, the new pthread-based variant of
-      hurd_condition_wait() should also use a different name from the
-      cthread-based one
-    <braunr> so it's normal to put it in that threading library, like it was
-      done for cthreads
-    <braunr> 21:35 < braunr> it could be renamed __hurd_condition_wait, i'm not
-      sure
-    <bddebian> Except that I am trying to avoid using that threading library
-    <braunr> what ?
-    <bddebian> If I am understanding you correctly it is an extention to the
-      hurd specific libpthreads?
-    <braunr> to the threading library, whichever it is
-    <braunr> antrik: although, why not keeping the same name ?
-    <antrik> braunr: I don't think having hurd_condition_wait() for the cthread
-      variant and __hurd_condition_wait() would exactly help clarity...
-    <antrik> I was talking about a really new name. something like
-      pthread_hurd_condition_wait() or so
-    <antrik> braunr: to avoid confusion. to avoid accidentally pulling in the
-      wrong one at build and/or runtime.
-    <antrik> to avoid possible namespace conflicts
-    <braunr> ok
-    <braunr> well yes, makes sense
-    <bddebian> braunr: Let me state this as plainly as I hope I can.  If I want
-      to use glibc's pthreads, I have no choice but to add it to glibc?
-    <braunr> and pthread_hurd_condition_wait is a fine name
-    <braunr> bddebian: no
-    <braunr> bddebian: you either add it there
-    <braunr> bddebian: or you copy the headers defining the internal structures
-      somewhere else and implement it there
-    <braunr> but adding it to glibc is better
-    <braunr> it's just longer in the beginning, and now i'm working on it, i'm
-      really not sure
-    <braunr> add it to glibc directly :p
-    <bddebian> That's what I am trying to do but the headers use pthread
-      specific stuff would should be coming from glibc's pthreads
-    <braunr> yes
-    <braunr> well it's not the headers you need
-    <braunr> you need the internal structure definitions
-    <braunr> sometimes they're in c files for opacity
-    <bddebian> So ___pthread_self() should eventually be an obfuscation of
-      glibcs pthread_self(), no?
-    <braunr> i don't know what it is
-    <braunr> read the cthreads variant of hurd_condition_wait, understand it,
-      do the same for pthreads
-    <braunr> it's easy :p
-    <bddebian> For you bastards that have a clue!! ;-P
-    <antrik> I definitely vote for adding it to the hurd pthreads
-      implementation in glibc right away. trying to do it externally only adds
-      unnecessary complications
-    <antrik> and we seem to agree that this new pthread function should be
-      named pthread_hurd_condition_wait(), not just hurd_condition_wait() :-)
-
-
-## IRC, freenode, #hurd, 2012-07-27
-
-    <bddebian> OK this hurd_condition_wait stuff is getting ridiculous the way
-      I am trying to tackle it. :(  I think I need a new tactic.
-    <braunr> bddebian: what do you mean ?
-    <bddebian> braunr: I know I am thick headed but I still don't get why I
-      cannot implement it in libshouldbeinlibc for now but still use glibc
-      pthreads internals
-    <bddebian> I thought I was getting close last night by bringing in all of
-      the hurd pthread headers and .c files but it just keeps getting uglier
-      and uglier
-    <bddebian> youpi: Just to verify.  The /usr/lib/i386-gnu/libpthread.so that
-      ships with Debian now is from glibc, NOT libpthreads from Hurd right?
-      Everything I need should be available in glibc's libpthreads? (Except for
-      hurd_condition_wait obviously).
-    <braunr> 22:35 < antrik> I definitely vote for adding it to the hurd
-      pthreads implementation in glibc right away. trying to do it externally
-      only adds unnecessary complications
-    <youpi> bddebian: yes
-    <youpi> same as antrik
-    <bddebian> fuck
-    <youpi> libpthread *already* provides some odd symbols (cthread
-      compatibility), it can provide others
-    <braunr> bddebian: don't curse :p it will be easier in the long run
-    * bddebian breaks out glibc :(
-    <braunr> but you should tell thomas that too
-    <bddebian> braunr: I know it just adds a level of complexity that I may not
-      be able to deal with
-    <braunr> we wouldn't want him to waste too much time on the external
-      libpthread
-    <braunr> which one ?
-    <bddebian> glibc for one.  hurd_condition_wait() for another which I don't
-      have a great grasp on.  Remember my knowledge/skillsets are limited
-      currently.
-    <braunr> bddebian: tschwinge has good instructions to build glibc
-    <braunr> keep your tree around and it shouldn't be long to hack on it
-    <braunr> for hurd_condition_wait, i can help
-    <bddebian> Oh I was thinking about using Debian glibc for now.  You think I
-      should do it from git?
-    <braunr> no
-    <braunr> debian rules are even more reliable
-    <braunr> (just don't build all the variants)
-    <pinotree> `debian/rules build_libc` builds the plain i386 variant only
-    <bddebian> So put pthread_hurd_cond_wait in it's own .c file or just put it
-      in pt-cond-wait.c ?
-    <braunr> i'd put it in pt-cond-wait.C
-    <bddebian> youpi or braunr: OK, another dumb question.  What (if anything)
-      should I do about hurd/hurd/signal.h.  Should I stop it from including
-      cthreads?
-    <youpi> it's not a dumb question. it should probably stop, yes, but there
-      might be uncovered issues, which we'll have to take care of
-    <bddebian> Well I know antrik suggested trying to keep compatibility but I
-      don't see how you would do that
-    <braunr> compability between what ?
-    <braunr> and source and/or binary ?
-    <youpi> hurd/signal.h implicitly including cthreads.h
-    <braunr> ah
-    <braunr> well yes, it has to change obviously
-    <bddebian> Which will break all the cthreads stuff of course
-    <bddebian> So are we agreeing on pthread_hurd_cond_wait()?
-    <braunr> that's fine
-    <bddebian> Ugh, shit there is stuff in glibc using cthreads??
-    <braunr> like what ?
-    <bddebian> hurdsig, hurdsock, setauth, dtable, ...
-    <youpi> it's just using the compatibility stuff, that pthread does provide
-    <bddebian> but it includes cthreads.h implicitly
-    <bddebian> s/it/they in many cases
-    <youpi> not a problem, we provide the functions
-    <bddebian> Hmm, then what do I do about signal.h?  It includes chtreads.h
-      because it uses extern struct mutex ...
-    <youpi> ah, then keep the include
-    <youpi> the pthread mutexes are compatible with that
-    <youpi> we'll clean that afterwards
-    <bddebian> arf, OK
-    <youpi> that's what I meant by "uncover issues"
-
-
-## IRC, freenode, #hurd, 2012-07-28
-
-    <bddebian> Well crap, glibc built but I have no symbol for
-      pthread_hurd_cond_wait in libpthread.so :(
-    <bddebian> Hmm, I wonder if I have to add pthread_hurd_cond_wait to
-      forward.c and Versions? (Versions obviously eventually)
-    <pinotree> bddebian: most probably not about forward.c, but definitely you
-      have to export public stuff using Versions
-
-
-## IRC, freenode, #hurd, 2012-07-29
-
-    <bddebian> braunr: http://paste.debian.net/181078/
-    <braunr> ugh, inline functions :/
-    <braunr> "Tell hurd_thread_cancel how to unblock us"
-    <braunr> i think you need that one too :p
-    <bddebian> ??
-    <braunr> well, they work in pair
-    <braunr> one cancels, the other notices it
-    <braunr> hurd_thread_cancel is in the hurd though, iirc
-    <braunr> or uh wait
-    <braunr> no it's in glibc, hurd/thread-cancel.c
-    <braunr> otherwise it looks like a correct reuse of the original code, but
-      i need to understand the pthreads internals better to really say anything
-
-
-## IRC, freenode, #hurd, 2012-08-03
-
-    <braunr> pinotree: what do you think of
-      condition_implies/condition_unimplies ?
-    <braunr> the work on pthread will have to replace those
-
-
-## IRC, freenode, #hurd, 2012-08-06
-
-    <braunr> bddebian: so, where is the work being done ?
-    <bddebian> braunr: Right now I would just like to testing getting my glibc
-      with pthread_hurd_cond_wait installed on the clubber subhurd.  It is in
-      /home/bdefreese/glibc-debian2
-    <braunr> we need a git branch
-    <bddebian> braunr: Then I want to rebuild hurd with Thomas's pthread
-      patches against that new libc
-    <bddebian> Aye
-    <braunr> i don't remember, did thomas set a git repository somewhere for
-      that ?
-    <bddebian> He has one but I didn't have much luck with it since he is using
-      an external libpthreads
-    <braunr> i can manage the branches
-    <bddebian> I was actually patching debian/hurd then adding his patches on
-      top of that.  It is in /home/bdefreese/debian-hurd but he has updateds
-      some stuff since then
-    <bddebian> Well we need to agree on a strategy.  libpthreads only exists in
-      debian/glibc
-    <braunr> it would be better to have something upstream than to work on a
-      debian specific branch :/
-    <braunr> tschwinge: do you think it can be done 
-    <braunr> ?
-
-
-## IRC, freenode, #hurd, 2012-08-07
-
-    <tschwinge> braunr: You mean to create on Savannah branches for the
-      libpthread conversion?  Sure -- that's what I have been suggesting to
-      Barry and Thomas D. all the time.
-
-    <bddebian> braunr: OK, so I installed my glibc with
-      pthread_hurd_condition_wait in the subhurd and now I have built Debian
-      Hurd with Thomas D's pthread patches.
-    <braunr> bddebian: i'm not sure we're ready for tests yet :p
-    <bddebian> braunr: Why not? :)
-    <braunr> bddebian: a few important bits are missing
-    <bddebian> braunr: Like?
-    <braunr> like condition_implies
-    <braunr> i'm not sure they have been handled everywhere
-    <braunr> it's still interesting to try, but i bet your system won't finish
-      booting
-    <bddebian> Well I haven't "installed" the built hurd yet
-    <bddebian> I was trying to think of a way to test a little bit first, like
-      maybe ext2fs.static or something
-    <bddebian> Ohh, it actually mounted the partition
-    <bddebian> How would I actually "test" it?
-    <braunr> git clone :p
-    <braunr> building a debian package inside
-    <braunr> removing the whole content after
-    <braunr> that sort of things
-    <bddebian> Hmm, I think I killed clubber :(
-    <bddebian> Yep.. Crap! :(
-    <braunr> ?
-    <braunr> how did you do that ?
-    <bddebian> Mounted a new partition with the pthreads ext2fs.static then did
-      an apt-get source hurd to it..
-    <braunr> what partition, and what mount point ?
-    <bddebian> I added a new 2Gb partition on /dev/hd0s6 and set the translator
-      on /home/bdefreese/part6
-    <braunr> shouldn't kill your hurd
-    <bddebian> Well it might still be up but killed my ssh session at the very
-      least :)
-    <braunr> ouch
-    <bddebian> braunr: Do you have debugging enabled in that custom kernel you
-      installed?  Apparently it is sitting at the debug prompt.
-
-
-## IRC, freenode, #hurd, 2012-08-12
-
-    <braunr> hmm, it seems the hurd notion of cancellation is actually not the
-      pthread one at all
-    <braunr> pthread_cancel merely marks a thread as being cancelled, while
-      hurd_thread_cancel interrupts it
-    <braunr> ok, i have a pthread_hurd_cond_wait_np function in glibc
-
-
-## IRC, freenode, #hurd, 2012-08-13
-
-    <braunr> nice, i got ext2fs work with pthreads
-    <braunr> there are issues with the stack size strongly limiting the number
-      of concurrent threads, but that's easy to fix
-    <braunr> one problem with the hurd side is the condition implications
-    <braunr> i think it should be deal separately, and before doing anything
-      with pthreads
-    <braunr> but that's minor, the most complex part is, again, the term server
-    <braunr> other than that, it was pretty easy to do
-    <braunr> but, i shouldn't speak too soon, who knows what tricky bootstrap
-      issue i'm gonna face ;p
-    <braunr> tschwinge: i'd like to know how i should proceed if i want a
-      symbol in a library overriden by that of a main executable
-    <braunr> e.g. have libpthread define a default stack size, and let
-      executables define their own if they want to change it
-    <braunr> tschwinge: i suppose i should create a weak alias in the library
-      and a normal variable in the executable, right ?
-    <braunr> hm i'm making this too complicated
-    <braunr> don't mind that stupid question
-    <tschwinge> braunr: A simple variable definition would do, too, I think?
-    <tschwinge> braunr: Anyway, I'd first like to know why we can'T reduce the
-      size of libpthread threads from 2 MiB to 64 KiB as libthreads had.  Is
-      that a requirement of the pthread specification?
-    <braunr> tschwinge: it's a requirement yes
-    <braunr> the main reason i see is that hurd threadvars (which are still
-      present) rely on common stack sizes and alignment to work
-    <tschwinge> Mhm, I see.
-    <braunr> so for now, i'm using this approach as a hack only
-    <tschwinge> I'm working on phasing out threadvars, but we're not there yet.
-
-[[glibc/t/tls-threadvar]].
-
-    <tschwinge> Yes, that's fine for the moment.
-    <braunr> tschwinge: a simple definition wouldn't work
-    <braunr> tschwinge: i resorted to a weak symbol, and see how it goes
-    <braunr> tschwinge: i supposed i need to export my symbol as a global one,
-      otherwise making it weak makes no sense, right ?
-    <braunr> suppose*
-    <braunr> tschwinge: also, i'm not actually sure what you meant is a
-      requirement about the stack size, i shouldn't have answered right away
-    <braunr> no there is actually no requirement
-    <braunr> i misunderstood your question
-    <braunr> hm when adding this weak variable, starting a program segfaults :(
-    <braunr> apparently on ___pthread_self, a tls variable
-    <braunr> fighting black magic begins
-    <braunr> arg, i can't manage to use that weak symbol to reduce stack sizes
-      :(
-    <braunr> ah yes, finally
-    <braunr> git clone /path/to/glibc.git on a pthread-powered ext2fs server :>
-    <braunr> tschwinge: seems i have problems using __thread in hurd code
-    <braunr> tschwinge: they produce undefined symbols
-    <braunr> tschwinge: forget that, another mistake on my part
-    <braunr> so, current state: i just need to create another patch, for the
-      code that is included in the debian hurd package but not in the upstream
-      hurd repository (e.g. procfs, netdde), and i should be able to create
-      hurd packages taht completely use pthreads
-
-
-## IRC, freenode, #hurd, 2012-08-14
-
-    <braunr> tschwinge: i have weird bootstrap issues, as expected
-    <braunr> tschwinge: can you point me to important files involved during
-      bootstrap ?
-    <braunr> my ext2fs.static server refuses to start as a rootfs, whereas it
-      seems to work fine otherwise
-    <braunr> hm, it looks like it's related to global signal dispositions
-
-
-## IRC, freenode, #hurd, 2012-08-15
-
-    <braunr> ahah, a subhurd running pthreads-powered hurd servers only
-    <LarstiQ> braunr: \o/
-    <braunr> i can even long on ssh
-    <braunr> log
-    <braunr> pinotree: for reference, i uploaded my debian-specific changes
-      there :
-    <braunr> http://git.sceen.net/rbraun/debian_hurd.git/
-    <braunr> darnassus is now running a pthreads-enabled hurd system :)
-
-
-## IRC, freenode, #hurd, 2012-08-16
-
-    <braunr> my pthreads-enabled hurd systems can quickly die under load
-    <braunr> youpi: with hurd servers using pthreads, i occasionally see thread
-      storms apparently due to a deadlock
-    <braunr> youpi: it makes me think of the problem you sometimes have (and
-      had often with the page cache patch)
-    <braunr> in cthreads, mutex and condition operations are macros, and they
-      check the mutex/condition queue without holding the internal
-      mutex/condition lock
-    <braunr> i'm not sure where this can lead to, but it doesn't seem right
-    <pinotree> isn't that a bit dangerous?
-    <braunr> i believe it is
-    <braunr> i mean
-    <braunr> it looks dangerous
-    <braunr> but it may be perfectly safe
-    <pinotree> could it be?
-    <braunr> aiui, it's an optimization, e.g. "dont take the internal lock if
-      there are no thread to wake"
-    <braunr> but if there is a thread enqueuing itself at the same time, it
-      might not be waken
-    <pinotree> yeah
-    <braunr> pthreads don't have this issue
-    <braunr> and what i see looks like a deadlock
-    <pinotree> anything can happen between the unlocked checking and the
-      following instruction
-    <braunr> so i'm not sure how a situation working around a faulty
-      implementation would result in a deadlock with a correct one
-    <braunr> on the other hand, the error youpi reported
-      (http://lists.gnu.org/archive/html/bug-hurd/2012-07/msg00051.html) seems
-      to indicate something is deeply wrong with libports
-    <pinotree> it could also be the current code does not really "works around"
-      that, but simply implicitly relies on the so-generated behaviour
-    <braunr> luckily not often
-    <braunr> maybe
-    <braunr> i think we have to find and fix these issues before moving to
-      pthreads entirely
-    <braunr> (ofc, using pthreads to trigger those bugs is a good procedure)
-    <pinotree> indeed
-    <braunr> i wonder if tweaking the error checking mode of pthreads to abort
-      on EDEADLK is a good approach to detecting this problem
-    <braunr> let's try !
-    <braunr> youpi: eh, i think i've spotted the libports ref mistake
-    <youpi> ooo!
-    <youpi> .oOo.!!
-    <gnu_srs> Same problem but different patches
-    <braunr> look at libports/bucket-iterate.c
-    <braunr> in the HURD_IHASH_ITERATE loop, pi->refcnt is incremented without
-      a lock
-    <youpi> Mmm, the incrementation itself would probably be compiled into an
-      INC, which is safe in UP
-    <youpi> it's an add currently actually
-    <youpi>    0x00004343 <+163>:   addl   $0x1,0x4(%edi)
-    <braunr>     40c4:       83 47 04 01             addl   $0x1,0x4(%edi)
-    <youpi> that makes it SMP unsafe, but not UP unsafe
-    <braunr> right
-    <braunr> too bad
-    <youpi> that still deserves fixing :)
-    <braunr> the good side is my mind is already wired for smp
-    <youpi> well, it's actually not UP either
-    <youpi> in general
-    <youpi> when the processor is not able to do the add in one instruction
-    <braunr> sure
-    <braunr> youpi: looks like i'm wrong, refcnt is protected by the global
-      libports lock
-    <youpi> braunr: but aren't there pieces of code which manipulate the refcnt
-      while taking another lock than the global libports lock
-    <youpi> it'd not be scalable to use the global libports lock to protect
-      refcnt
-    <braunr> youpi: imo, the scalability issues are present because global
-      locks are taken all the time, indeed
-    <youpi> urgl
-    <braunr> yes ..
-    <braunr> when enabling mutex checks in libpthread, pfinet dies :/
-    <braunr> grmbl, when trying to start "ls" using my deadlock-detection
-      libpthread, the terminal gets unresponsive, and i can't even use ps .. :(
-    <pinotree> braunr: one could say your deadlock detection works too
-      good... :P
-    <braunr> pinotree: no, i made a mistake :p
-    <braunr> it works now :)
-    <braunr> well, works is a bit fast
-    <braunr> i can't attach gdb now :(
-    <braunr> *sigh*
-    <braunr> i guess i'd better revert to a cthreads hurd and debug from there
-    <braunr> eh, with my deadlock-detection changes, recursive mutexes are now
-      failing on _pthread_self(), which for some obscure reason generates this
-    <braunr> => 0x0107223b <+283>:   jmp    0x107223b
-      <__pthread_mutex_timedlock_internal+283>
-    <braunr> *sigh*
-
-
-## IRC, freenode, #hurd, 2012-08-17
-
-    <braunr> aw, the thread storm i see isn't a deadlock
-    <braunr> seems to be mere contention ....
-    <braunr> youpi: what do you think of the way
-      ports_manage_port_operations_multithread determines it needs to spawn a
-      new thread ?
-    <braunr> it grabs a lock protecting the number of threads to determine if
-      it needs a new thread
-    <braunr> then releases it, to retake it right after if a new thread must be
-      created
-    <braunr> aiui, it could lead to a situation where many threads could
-      determine they need to create threads
-    <youpi> braunr: there's no reason to release the spinlock before re-taking
-      it
-    <youpi> that can indeed lead to too much thread creations
-    <braunr> youpi: a harder question
-    <braunr> youpi: what if thread creation fails ? :/
-    <braunr> if i'm right, hurd servers simply never expect thread creation to
-      fail
-    <youpi> indeed
-    <braunr> and as some patterns have threads blocking until another produce
-      an event
-    <braunr> i'm not sure there is any point handling the failure at all :/
-    <youpi> well, at least produce some output
-    <braunr> i added a perror
-    <youpi> so we know that happened
-    <braunr> async messaging is quite evil actually
-    <braunr> the bug i sometimes have with pfinet is usually triggered by
-      fakeroot
-    <braunr> it seems to use select a lot
-    <braunr> and select often destroys ports when it has something to return to
-      the caller
-    <braunr> which creates dead name notifications
-    <braunr> and if done often enough, a lot of them
-    <youpi> uh
-    <braunr> and as pfinet is creating threads to service new messages, already
-      existing threads are starved and can't continue
-    <braunr> which leads to pfinet exhausting its address space with thread
-      stacks (at about 30k threads)
-    <braunr> i initially thought it was a deadlock, but my modified libpthread
-      didn't detect one, and indeed, after i killed fakeroot (the whole
-      dpkg-buildpackage process hierarchy), pfinet just "cooled down"
-    <braunr> with almost all 30k threads simply waiting for requests to
-      service, and the few expected select calls blocking (a few ssh sessions,
-      exim probably, possibly others)
-    <braunr> i wonder why this doesn't happen with cthreads
-    <youpi> there's a 4k guard between stacks, otherwise I don't see anything
-      obvious
-    <braunr> i'll test my pthreads package with the fixed
-      ports_manage_port_operations_multithread
-    <braunr> but even if this "fix" should reduce thread creation, it doesn't
-      prevent the starvation i observed
-    <braunr> evil concurrency :p
-
-    <braunr> youpi: hm i've just spotted an important difference actually
-    <braunr> youpi: glibc sched_yield is __swtch(), cthreads is
-      thread_switch(MACH_PORT_NULL, SWITCH_OPTION_DEPRESS, 10)
-    <braunr> i'll change the glibc implementation, see how it affects the whole
-      system
-
-    <braunr> youpi: do you think bootsting the priority or cancellation
-      requests is an acceptable workaround ?
-    <braunr> boosting
-    <braunr> of*
-    <youpi> workaround for what?
-    <braunr> youpi: the starvation i described earlier
-    <youpi> well, I guess I'm not into the thing enough to understand
-    <youpi> you meant the dead port notifications, right?
-    <braunr> yes
-    <braunr> they are the cancellation triggers
-    <youpi> cancelling whaT?
-    <braunr> a blocking select for example
-    <braunr> ports_do_mach_notify_dead_name -> ports_dead_name ->
-      ports_interrupt_notified_rpcs -> hurd_thread_cancel
-    <braunr> so it's important they are processed quickly, to allow blocking
-      threads to unblock, reply, and be recycled
-    <youpi> you mean the threads in pfinet?
-    <braunr> the issue applies to all servers, but yes
-    <youpi> k
-    <youpi> well, it can not not be useful :)
-    <braunr> whatever the choice, it seems to be there will be a security issue
-      (a denial of service of some kind)
-    <youpi> well, it's not only in that case
-    <youpi> you can always queue a lot of requests to a server
-    <braunr> sure, i'm just focusing on this particular problem
-    <braunr> hm
-    <braunr> max POLICY_TIMESHARE or min POLICY_FIXEDPRI ?
-    <braunr> i'd say POLICY_TIMESHARE just in case
-    <braunr> (and i'm not sure mach handles fixed priority threads first
-      actually :/)
-    <braunr> hm my current hack which consists of calling swtch_pri(0) from a
-      freshly created thread seems to do the job eh
-    <braunr> (it may be what cthreads unintentionally does by acquiring a spin
-      lock from the entry function)
-    <braunr> not a single issue any more with this hack
-    <bddebian> Nice
-    <braunr> bddebian: well it's a hack :p
-    <braunr> and the problem is that, in order to boost a thread's priority,
-      one would need to implement that in libpthread
-    <bddebian> there isn't thread priority in libpthread?
-    <braunr> it's not implemented
-    <bddebian> Interesting
-    <braunr> if you want to do it, be my guest :p
-    <braunr> mach should provide the basic stuff for a partial implementation
-    <braunr> but for now, i'll fall back on the hack, because that's what
-      cthreads "does", and it's "reliable enough"
-
-    <antrik> braunr: I don't think the locking approach in
-      ports_manage_port_operations_multithread() could cause issues. the worst
-      that can happen is that some other thread becomes idle between the check
-      and creating a new thread -- and I can't think of a situation where this
-      could have any impact...
-    <braunr> antrik: hm ?
-    <braunr> the worst case is that many threads will evalute spawn to 1 and
-      create threads, whereas only one of them should have
-    <antrik> braunr: I'm not sure perror() is a good way to handle the
-      situation where thread creation failed. this would usually happen because
-      of resource shortage, right? in that case, it should work in non-debug
-      builds too
-    <braunr> perror isn't specific to debug builds
-    <braunr> i'm building glibc packages with a pthreads-enabled hurd :>
-    <braunr> (which at one point run the test allocating and filling 2 GiB of
-      memory, which passed)
-    <braunr> (with a kernel using a 3/1 split of course, swap usage reached
-      something like 1.6 GiB)
-    <antrik> braunr: BTW, I think the observation that thread storms tend to
-      happen on destroying stuff more than on creating stuff has been made
-      before...
-    <braunr> ok
-    <antrik> braunr: you are right about perror() of course. brain fart -- was
-      thinking about assert_perror()
-    <antrik> (which is misused in some places in existing Hurd code...)
-    <antrik> braunr: I still don't see the issue with the "spawn"
-      locking... the only situation where this code can be executed
-      concurrently is when multiple threads are idle and handling incoming
-      request -- but in that case spawning does *not* happen anyways...
-    <antrik> unless you are talking about something else than what I'm thinking
-      of...
-    <braunr> well imagine you have idle threads, yes
-    <braunr> let's say a lot like a thousand
-    <braunr> and the server gets a thousand requests
-    <braunr> a one more :p
-    <braunr> normally only one thread should be created to handle it
-    <braunr> but here, the worst case is that all threads run internal_demuxer
-      roughly at the same time
-    <braunr> and they all determine they need to spawn a thread
-    <braunr> leading to another thousand
-    <braunr> (that's extreme and very unlikely in practice of course)
-    <antrik> oh, I see... you mean all the idle threads decide that no spawning
-      is necessary; but before they proceed, finally one comes in and decides
-      that it needs to spawn; and when the other ones are scheduled again they
-      all spawn unnecessarily?
-    <braunr> no, spawn is a local variable
-    <braunr> it's rather, all idle threads become busy, and right before
-      servicing their request, they all decide they must spawn a thread
-    <antrik> I don't think that's how it works. changing the status to busy (by
-      decrementing the idle counter) and checking that there are no idle
-      threads is atomic, isn't it?
-    <braunr> no
-    <antrik> oh
-    <antrik> I guess I should actually look at that code (again) before
-      commenting ;-)
-    <braunr> let me check
-    <braunr> no sorry you're right
-    <braunr> so right, you can't lead to that situation
-    <braunr> i don't even understand how i can't see that :/
-    <braunr> let's say it's the heat :p
-    <braunr> 22:08 < braunr> so right, you can't lead to that situation
-    <braunr> it can't lead to that situation
-
-
-## IRC, freenode, #hurd, 2012-08-18
-
-    <braunr> one more attempt at fixing netdde, hope i get it right this time
-    <braunr> some parts assume a ddekit thread is a cthread, because they share
-      the same address
-    <braunr> it's not as easy when using pthread_self :/
-    <braunr> good, i got netdde work with pthreads
-    <braunr> youpi: for reference, there are now glibc, hurd and netdde
-      packages on my repository
-    <braunr> youpi: the debian specific patches can be found at my git
-      repository (http://git.sceen.net/rbraun/debian_hurd.git/ and
-      http://git.sceen.net/rbraun/debian_netdde.git/)
-    <braunr> except a freeze during boot (between exec and init) which happens
-      rarely, and the starvation which still exists to some extent (fakeroot
-      can cause many threads to be created in pfinet and pflocal), the
-      glibc/hurd packages have been working fine for a few days now
-    <braunr> the threading issue in pfinet/pflocal is directly related to
-      select, which the io_select_timeout patches should fix once merged
-    <braunr> well, considerably reduce at least
-    <braunr> and maybe fix completely, i'm not sure
-
-
-## IRC, freenode, #hurd, 2012-08-27
-
-    <pinotree> braunr: wrt a78a95d in your pthread branch of hurd.git,
-      shouldn't that job theorically been done using pthread api (of course
-      after implementing it)?
-    <braunr> pinotree: sure, it could be done through pthreads
-    <braunr> pinotree: i simply restricted myself to moving the hurd to
-      pthreads, not augment libpthread
-    <braunr> (you need to remember that i work on hurd with pthreads because it
-      became a dependency of my work on fixing select :p)
-    <braunr> and even if it wasn't the reason, it is best to do these tasks
-      (replace cthreads and implement pthread scheduling api) separately
-    <pinotree> braunr: hm ok
-    <pinotree> implementing the pthread priority bits could be done
-      independently though
-
-    <braunr> youpi: there are more than 9000 threads for /hurd/streamio kmsg on
-      ironforge oO
-    <youpi> kmsg ?!
-    <youpi> it's only /dev/klog right?
-    <braunr> not sure but it seems so
-    <pinotree> which syslog daemon is running?
-    <youpi> inetutils
-    <youpi> I've restarted the klog translator, to see whether when it grows
-      again
-
-    <braunr> 6 hours and 21 minutes to build glibc on darnassus
-    <braunr> pfinet still runs only 24 threads
-    <braunr> the ext2 instance used for the build runs 2k threads, but that's
-      because of the pageouts
-    <braunr> so indeed, the priority patch helps a lot
-    <braunr> (pfinet used to have several hundreds, sometimes more than a
-      thousand threads after a glibc build, and potentially increasing with
-      each use of fakeroot)
-    <braunr> exec weights 164M eww, we definitely have to fix that leak
-    <braunr> the leaks are probably due to wrong mmap/munmap usage
-
-[[exec_memory_leaks]].
-
-
-### IRC, freenode, #hurd, 2012-08-29
-
-    <braunr> youpi: btw, after my glibc build, there were as little as between
-      20 and 30 threads for pflocal and pfinet
-    <braunr> with the priority patch
-    <braunr> ext2fs still had around 2k because of pageouts, but that's
-      expected
-    <youpi> ok
-    <braunr> overall the results seem very good and allow the switch to
-      pthreads
-    <youpi> yep, so it seems
-    <braunr> youpi: i think my first integration branch will include only a few
-      changes, such as this priority tuning, and the replacement of
-      condition_implies
-    <youpi> sure
-    <braunr> so we can push the move to pthreads after all its small
-      dependencies
-    <youpi> yep, that's the most readable way
-
-
-## IRC, freenode, #hurd, 2012-09-03
-
-    <gnu_srs> braunr: Compiling yodl-3.00.0-7:
-    <gnu_srs> pthreads: real    13m42.460s, user    0m0.000s, sys     0m0.030s
-    <gnu_srs> cthreads: real     9m 6.950s, user    0m0.000s, sys     0m0.020s   
-    <braunr> thanks
-    <braunr> i'm not exactly certain about what causes the problem though
-    <braunr> it could be due to libpthread using doubly-linked lists, but i
-      don't think the overhead would be so heavier because of that alone
-    <braunr> there is so much contention sometimes that it could
-    <braunr> the hurd would have been better off with single threaded servers
-      :/
-    <braunr> we should probably replace spin locks with mutexes everywhere
-    <braunr> on the other hand, i don't have any more starvation problem with
-      the current code
-
-
-### IRC, freenode, #hurd, 2012-09-06
-
-    <gnu_srs> braunr: Yes you are right, the new pthread-based Hurd is _much_
-      slower.
-    <gnu_srs> One annoying example is when compiling, the standard output is
-      written in bursts with _long_ periods of no output in between:-( 
-    <braunr> that's more probably because of the priority boost, not the
-      overhead
-    <braunr> that's one of the big issues with our mach-based model
-    <braunr> we either give high priorities to our servers, or we can suffer
-      from message floods
-    <braunr> that's in fact more a hurd problem than a mach one
-    <gnu_srs> braunr: any immediate ideas how to speed up responsiveness the
-      pthread-hurd. It is annoyingly slow (slow-witted)
-    <braunr> gnu_srs: i already answered that
-    <braunr> it doesn't look that slower on my machines though
-    <gnu_srs> you said you had some ideas, not which. except for mcsims work.
-    <braunr> i have ideas about what makes it slower
-    <braunr> it doesn't mean i have solutions for that
-    <braunr> if i had, don't you think i'd have applied them ? :)
-    <gnu_srs> ok, how to make it more responsive on the console? and printing
-      stdout more regularly, now several pages are stored and then flushed.
-    <braunr> give more details please
-    <gnu_srs> it behaves like a loaded linux desktop, with little memory
-      left...
-    <braunr> details about what you're doing
-    <gnu_srs> apt-get source any big package and: fakeroot debian/rules binary
-      2>&1 | tee ../binary.logg
-    <braunr> isee
-    <braunr> well no, we can't improve responsiveness
-    <braunr> without reintroducing the starvation problem
-    <braunr> they are linked
-    <braunr> and what you're doing involes a few buffers, so the laggy feel is
-      expected
-    <braunr> if we can fix that simply, we'll do so after it is merged upstream
-
-
-### IRC, freenode, #hurd, 2012-09-07
-
-    <braunr> gnu_srs: i really don't feel the sluggishness you described with
-      hurd+pthreads on my machines
-    <braunr> gnu_srs: what's your hardware ?
-    <braunr> and your VM configuration ?
-    <gnu_srs> Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz
-    <gnu_srs> kvm -m 1024 -net nic,model=rtl8139 -net
-      user,hostfwd=tcp::5562-:22 -drive
-      cache=writeback,index=0,media=disk,file=hurd-experimental.img -vnc :6
-      -cdrom isos/netinst_2012-07-15.iso -no-kvm-irqchip
-    <braunr> what is the file system type where your disk image is stored ?
-    <gnu_srs> ext3
-    <braunr> and how much physical memory on the host ?
-    <braunr> (paste meminfo somewhere please)
-    <gnu_srs> 4G, and it's on the limit, 2 kvm instances+gnome,etc
-    <gnu_srs> 80% in use by programs, 14% in cache.
-    <braunr> ok, that's probably the reason then
-    <braunr> the writeback option doesn't help a lot if you don't have much
-      cache
-    <gnu_srs> well the other instance is cthreads based, and not so sluggish.
-    <braunr> we know hurd+pthreads is slower
-    <braunr> i just wondered why i didn't feel it that much
-    <gnu_srs> try to fire up more kvm instances, and do a heavy compile...
-    <braunr> i don't do that :)
-    <braunr> that's why i never had the problem
-    <braunr> most of the time i have like 2-3 GiB of cache
-    <braunr> and of course more on shattrath
-    <braunr> (the host of the sceen.net hurdboxes, which has 16 GiB of ram)
-
-
-### IRC, freenode, #hurd, 2012-09-11
-
-    <gnu_srs> Monitoring the cthreads and the pthreads load under Linux shows:  
-    <gnu_srs> cthread version: load can jump very high, less cpu usage than
-      pthread version
-    <gnu_srs> pthread version: less memory usage, background cpu usage higher
-      than for cthread version
-    <braunr> that's the expected behaviour
-    <braunr> gnu_srs: are you using the lifothreads gnumach kernel ?
-    <gnu_srs> for experimental, yes.
-    <gnu_srs> i.e. pthreads
-    <braunr> i mean, you're measuring on it right now, right ?
-    <gnu_srs> yes, one instance running cthreads, and one pthreads (with lifo
-      gnumach)
-    <braunr> ok
-    <gnu_srs> no swap used in either instance, will try a heavy compile later
-      on.
-    <braunr> what for ?
-    <gnu_srs> E.g. for memory when linking. I have swap available, but no swap
-      is used currently.
-    <braunr> yes but, what do you intend to measure ?
-    <gnu_srs> don't know, just to see if swap is used at all. it seems to be
-      used not very much.
-    <braunr> depends
-    <braunr> be warned that using the swap means there is pageout, which is one
-      of the triggers for global system freeze :p
-    <braunr> anonymous memory pageout
-    <gnu_srs> for linux swap is used constructively, why not on hurd?
-    <braunr> because of hard to squash bugs
-    <gnu_srs> aha, so it is bugs hindering swap usage:-/
-    <braunr> yup :/
-    <gnu_srs> Let's find them thenO:-), piece of cake
-    <braunr> remember my page cache branch in gnumach ? :)
-
-[[gnumach_page_cache_policy]].
-
-    <gnu_srs> not much
-    <braunr> i started it before fixing non blocking select
-    <braunr> anyway, as a side effect, it should solve this stability issue
-      too, but it'll probably take time
-    <gnu_srs> is that branch integrated? I only remember slab and the lifo
-      stuff.
-    <gnu_srs> and mcsims work
-    <braunr> no it's not
-    <braunr> it's unfinished
-    <gnu_srs> k!
-    <braunr> it correctly extends the page cache to all available physical
-      memory, but since the hurd doesn't scale well, it slows the system down
-
-
-## IRC, freenode, #hurd, 2012-09-14
-
-    <braunr> arg
-    <braunr> darnassus seems to eat 100% cpu and make top freeze after some
-      time
-    <braunr> seems like there is an important leak in the pthreads version
-    <braunr> could be the lifothreads patch :/
-    <cjbirk> there's a memory leak?
-    <cjbirk> in pthreads? 
-    <braunr> i don't think so, and it's not a memory leak
-    <braunr> it's a port leak
-    <braunr> probably in the kernel
-
-
-### IRC, freenode, #hurd, 2012-09-17
-
-    <braunr> nice, the port leak is actually caused by the exim4 loop bug
-
-
-### IRC, freenode, #hurd, 2012-09-23
-
-    <braunr> the port leak i observed a few days ago is because of exim4 (the
-      infamous loop eating the cpu we've been seeing regularly)
-
-[[fork_deadlock]]?
-
-    <youpi> oh
-    <braunr> next time it happens, and if i have the occasion, i'll examine the
-      problem
-    <braunr> tip: when you can't use top or ps -e, you can use ps -e -o
-      pid=,args=
-    <youpi> or -M ?
-    <braunr> haven't tested
-
-
-### IRC, freenode, #hurd, 2013-01-26
-
-    <braunr> ah great, one of the recent fixes (probably select-eintr or
-      setitimer) fixed exim4 :)
-
-
-## IRC, freenode, #hurd, 2012-09-23
-
-    <braunr> tschwinge: i committed the last hurd pthread change,
-      http://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=master-pthreads
-    <braunr> tschwinge: please tell me if you consider it ok for merging
-
-
-### IRC, freenode, #hurd, 2012-11-27
-
-    <youpi> braunr: btw, I forgot to forward here, with the glibc patch it does
-      boot fine, I'll push all that and build some almost-official packages for
-      people to try out what will come when eglibc gets the change in unstable
-    <braunr> youpi: great :)
-    <youpi> thanks for managing the final bits of this
-    <youpi> (and thanks for everybody involved)
-    <braunr> sorry again for the non obvious parts
-    <braunr> if you need the debian specific parts refined (e.g. nice commits
-      for procfs & others), i can do that
-    <youpi> I'll do that, no pb
-    <braunr> ok
-    <braunr> after that (well, during also), we should focus more on bug
-      hunting
-
-
-## IRC, freenode, #hurd, 2012-10-26
-
-    <mcsim1> hello. What does following error message means? "unable to adjust
-      libports thread priority: Operation not permitted" It appears when I set
-      translators.
-    <mcsim1> Seems has some attitude to libpthread. Also following appeared
-      when I tried to remove translator: "pthread_create: Resource temporarily
-      unavailable"
-    <mcsim1> Oh, first message appears very often, when I use translator I set.
-    <braunr> mcsim1: it's related to a recent patch i sent
-    <braunr> mcsim1: hurd servers attempt to increase their priority on startup
-      (when a thread is created actually)
-    <braunr> to reduce message floods and thread storms (such sweet names :))
-    <braunr> but if you start them as an unprivileged user, it fails, which is
-      ok, it's just a warning
-    <braunr> the second way is weird
-    <braunr> it normally happens when you're out of available virtual space,
-      not when shutting a translator donw
-    <mcsim1> braunr: you mean this patch: libports: reduce thread starvation on
-      message floods?
-    <braunr> yes
-    <braunr> remember you're running on darnassus
-    <braunr> with a heavily modified hurd/glibc
-    <braunr> you can go back to the cthreads version if you wish
-    <mcsim1> it's better to check translators privileges, before attempting to
-      increase their priority, I think.
-    <braunr> no
-    <mcsim1> it's just a bit annoying
-    <braunr> privileges can be changed during execution
-    <braunr> well remove it
-    <mcsim1> But warning should not appear.
-    <braunr> what could be done is to limit the warning to one occurrence
-    <braunr> mcsim1: i prefer that it appears
-    <mcsim1> ok
-    <braunr> it's always better to be explicit and verbose
-    <braunr> well not always, but very often
-    <braunr> one of the reasons the hurd is so difficult to debug is the lack
-      of a "message server" à la dmesg
-
-[[translator_stdout_stderr]].
-
-
-### IRC, freenode, #hurd, 2012-12-10
-
-    <youpi> braunr: unable to adjust libports thread priority: (ipc/send)
-      invalid destination port
-    <youpi> I'll see what package brought that
-    <youpi> (that was on a buildd)
-    <braunr> wow
-    <youpi> mkvtoolnix_5.9.0-1:
-    <pinotree> shouldn't that code be done in pthreads and then using such
-      pthread api? :p
-    <braunr> pinotree: you've already asked that question :p
-    <pinotree> i know :p
-    <braunr> the semantics of pthreads are larger than what we need, so that
-      will be done "later"
-    <braunr> but this error shouldn't happen
-    <braunr> it looks more like a random mach bug
-    <braunr> youpi: anything else on the console ?
-    <youpi> nope
-    <braunr> i'll add traces to know which step causes the error
-
-
-#### IRC, freenode, #hurd, 2012-12-11
-
-    <youpi> braunr: mktoolnix seems like a reproducer for the libports thread
-      priority issue
-    <youpi> (3 times)
-    <braunr> youpi: thanks
-    <braunr> youpi: where is that tool packaged ?
-    <pinotree> he probably means the mkvtoolnix source
-    <braunr> seems so
-    <braunr> i don't find anything else
-    <youpi> that's it, yes
-
-
-#### IRC, freenode, #hurd, 2013-03-01
-
-    <youpi> braunr: btw, "unable to adjust libports thread priority: (ipc/send)
-      invalid destination port" is actually not a sign of fatality
-    <youpi> bach recovered from it
-    <braunr> youpi: well, it never was a sign of fatality
-    <braunr> but it means that, for some reason, a process looses a right for a
-      very obscure reason :/
-    <braunr> weird sentence, agreed :p
-
-
-#### IRC, freenode, #hurd, 2013-06-14
-
-    <gnu_srs> Hi, when running check for gccgo the following occurs (multiple
-      times) locking up the console
-    <gnu_srs> unable to adjust libports thread priority: (ipc/send) invalid
-      destination port
-    <gnu_srs> (not locking up the console, it was just completely filled with
-      messages))
-    <braunr> gnu_srs: are you running your translator as root ?
-    <braunr> or, do you have a translator running as an unprivileged user ?
-    <braunr> hm, invalid dest port
-    <braunr> that's a bug :p
-    <braunr> but i don't know why
-    <braunr> i'll have to take some time to track it down
-    <braunr> it might be a user ref overflow or something similarly tricky
-    <braunr> gnu_srs: does it happen everytime you run gccgo checks or only
-      after the system has been alive for some time ?
-    <braunr> (some time being at least a few hours, more probably days)
-
-
-#### IRC, freenode, #hurd, 2013-07-05
-
-    <braunr> ok, found the bug about invalid ports when adjusting priorities
-    <braunr> thhe hurd must be plagued with wrong deallocations :(
-    <braunr> i have so many problems when trying to cleanly destroy threads
-
-[[libpthread/t/fix_have_kernel_resources]].
-
-
-#### IRC, freenode, #hurd, 2013-11-25
-
-    <braunr> youpi: btw, my last commit on the hurd repo fixes the urefs
-      overflow we've sometimes seen in the past in the priority adjusting code
-      of libports
-
-
-#### IRC, freenode, #hurd, 2013-11-29
-
-See also [[open_issues/libpthread/t/fix_have_kernel_resources]].
-
-    <braunr> there still are some leak ports making servers spawn threads with
-      non-elevated priorities :/
-    <braunr> leaks*
-    <teythoon> issues with your thread destruction work ?
-    <teythoon> err, wait
-    <teythoon> why does a port leak cause that ?
-    <braunr> because it causes urefs overflows
-    <braunr> and the priority adjustment code does check errors :p
-    <teythoon> ^^
-    <teythoon> ah yes, urefs...
-    <braunr> apparently it only affects the root file system
-    <teythoon> hm
-    <braunr> i'll spend an hour looking for it, and whatever i find, i'll
-      install the upstream debian packages so you can build glibc without too
-      much trouble
-    <teythoon> we need a clean build chroot on darnassus for this situation
-    <braunr> ah yes
-    <braunr> i should have time to set things up this week end
-    <braunr>      1: send (refs: 65534)
-    <braunr> i wonder what the first right is in the root file system
-    <teythoon> hm
-    <braunr> search doesn't help so i'm pretty sure it's a kernel object
-    <braunr> perhaps the host priv port
-    <teythoon> could be the thread port or something ?
-    <braunr> no, not the thread port
-    <teythoon> why would it have so many refs ?
-    <braunr> the task port maybe but it's fine if it overflows
-    <teythoon> also, some urefs are clamped at max, so maybe this is fine ?
-    <braunr> it may be fine yes
-    <braunr> err = get_privileged_ports (&host_priv, NULL);
-    <braunr> iirc, this function should pass copies of the name, not increment
-      the urefs counter
-    <braunr> it may behave differently if built statically
-    <teythoon> o_O y would it ?
-    <braunr> no idea
-    <braunr> something doesn't behave as it should :)
-    <braunr> i'm not asking why, i'm asking where :)
-    <braunr> the proc server is also affected
-    <braunr> so it does look like it has something to do with bootstrap
-    <teythoon> I'm not surprised :/
-
-
-#### IRC, freenode, #hurd, 2013-11-30
-
-    <braunr> so yes, the host_priv port gets a reference when calling
-      get_privileged_ports
-    <braunr> but only in the rootfs and proc servers, probably because others
-      use the code path to fetch it from proc
-    <teythoon> ah
-    <teythoon> well, it shouldn't behave differently
-    <braunr> ?
-    <teythoon> get_privileged_ports
-    <braunr> get_privileged_ports is explictely described to cache references
-    <teythoon> i don't get it
-    <teythoon> you said it behaved differently for proc and the rootfs
-    <teythoon> that's undesireable, isn't it ?
-    <braunr> yes
-    <teythoon> ok
-    <braunr> so it should behave differently than it does
-    <teythoon> yes
-    <teythoon> right
-    <braunr> teythoon: during your work this summer, have you come across the
-      bootstrap port of a task ?
-    <braunr> i wonder what the bootstrap port of the root file system is
-    <braunr> maybe i got the description wrong since references on host or
-      master are deallocated where get_privileged_ports is used ..
-    <teythoon> no, I do not believe i did anything bootstrap port related
-    <braunr> ok
-    <braunr> i don't need that any more fortunately
-    <braunr> i just wonder how someone could write a description so error-prone
-      ..
-    <braunr> and apparently, this problem should affect all servers, but for
-      some reason i didn't see it
-    <braunr> there, problem fixed
-    <teythoon> ?
-    <braunr> last leak eliminated
-    <teythoon> cool :)
-    <teythoon> how ?
-    <braunr> i simply deallocate host_priv in addition to the others when
-      adjusting thread priority
-    <braunr> as simple as that ..
-    <teythoon> uh
-    <teythoon> sure ?
-    <braunr> so many system calls just for reference counting
-    <braunr> yes
-    <teythoon> i did that, and broke the rootfs
-    <braunr> well i'm using one right now
-    <teythoon> ok
-    <braunr> maybe i should let it run a bit :)
-    <teythoon> no, for me it failed on the first write
-    <braunr> teythoon: looks weird
-    <teythoon> so i figured it was wrong to deallocate that port
-    <braunr> i'll reboot it and see if there may be a race
-    <teythoon> thought i didn't get a reference after all or something
-    <teythoon> I believe there is a race in ext2fs
-    <braunr> teythoon: that's not good news for me
-    <teythoon> when doing fsysopts --update / (which remounts /)
-    <teythoon> sometimes, the system hangs
-    <braunr> :/
-    <teythoon> might be a deadlock, or the rootfs dies and noone notices
-    <teythoon> with my protected payload stuff, the system would reboot instead
-      of just hanging
-    <braunr> oh
-    <teythoon> which might point to a segfault in ext2fs
-    <teythoon> maybe the exception message carries a bad payload
-    <braunr> makes sense
-    <braunr> exception handling in ext2fs is messy ..
-    <teythoon> braunr: and, doing sleep 0.1 before remounting / makes the
-      problem less likely to appear
-    <braunr> ugh
-    <teythoon> and system load on my host system seems to affect this
-    <teythoon> but it is hard to tell
-    <teythoon> sometimes, this doesn't show up at all
-    <teythoon> sometimes several times in a row
-    <braunr> the system load might simply indicate very short lived processes
-    <braunr> (or threads)
-    <teythoon> system load on my host
-    <braunr> ah
-    <teythoon> this makes me believe that it is a race somewhere
-    <teythoon> all of this
-    <braunr> well, i can't get anything wrong with my patched rootfs
-    <teythoon> braunr: ok, maybe I messed up
-    <braunr> or maybe you were very unlucky
-    <braunr> and there is a rare race
-    <braunr> but i'll commit anyway
-    <teythoon> no, i never got it to work, always hung at the first write
-    <braunr> it won't be the first or last rare problem we'll have to live with
-    <braunr> hm
-    <braunr> then you probably did something wrong, yes
-    <braunr> that's reassuring
-
-
-### IRC, freenode, #hurd, 2013-03-11
-
-    <braunr> youpi: oh btw, i noticed a problem with the priority adjustement
-      code
-    <braunr> a thread created by a privileged server (e.g. an ext2fs
-      translator) can then spawn a server from a node owned by an unprivileged
-      user
-    <braunr> which inherits the priority
-    <braunr> easy to fix but worth saying to keep in mind
-    <youpi> uh
-    <youpi> indeed
-
-### IRC, freenode, #hurd, 2013-07-01
-
-    <youpi> braunr: it seems as if pfinet is not prioritized enough
-    <youpi> I'm getting network connectivity issues when the system is quite
-      loaded
-    <braunr> loaded with what ?
-    <braunr> it could be ext2fs having a lot more threads than other servers
-    <youpi> building packages
-    <youpi> I'm talking about the buildds
-    <braunr> ok
-    <braunr> ironforge or others ?
-    <youpi> they're having troubles uploading packages while building stuff
-    <youpi> ironforge and others
-    <youpi> that happened already in the past sometimes
-    <youpi> but at the moment it's really pronounced
-    <braunr> i don't think it's a priority issue
-    <braunr> i think it's swapping
-    <youpi> ah, that's not impossible indeed
-    <youpi> but why would it swap?
-    <youpi> there's a lot of available memory
-    <braunr> a big file is enough
-    <braunr> it pushes anonymous memory out
-    <youpi> to fill 900MiB memory ?
-    <braunr> i see 535M of swap on if
-    <braunr> yes
-    <youpi> ironforge is just building libc
-    <braunr> and for some reason, swapping is orders of magnitude slower than
-      anything else
-    <youpi> not linking it yet
-    <braunr> i also see 1G of free memory on it
-    <youpi> that's what I meant with 900MiB
-    <braunr> so at some point, it needed a lot of memory, caused swapping
-    <braunr> and from time to time it's probably swapping back
-    <youpi> well, pfinet had all the time to swap back already
-    <youpi> I don't see why it should be still suffering from it
-    <braunr> swapping is a kernel activity
-    <youpi> ok, but once you're back, you're back
-    <youpi> unless something else pushes you out
-    <braunr> if the kernel is busy waiting for the default pager, nothing makes
-      progress
-    <braunr> (eccept the default pager hopefully)
-    <youpi> sure but pfinet should be back already, since it does work
-    <youpi> so I don't see why it should wait for something
-    <braunr> the kernel is waiting
-    <braunr> and the kernel isn't preemptibl
-    <braunr> e
-    <braunr> although i'm not sure preemption is the problem here
-    <youpi> well
-    <youpi> what I don't understand is what we have changed that could have so
-      much impact
-    <youpi> the only culprit I can see is the priorities we have changed
-      recently
-    <braunr> do you mean it happens a lot more frequently than before ?
-    <youpi> yes
-    <youpi> way
-    <braunr> ok
-    <youpi> ironforge is almost unusable while building glibc
-    <youpi> I've never seen that
-    <braunr> that's weird, i don't have these problems on darnassus
-    <braunr> but i think i reboot it more often
-    <braunr> could be a scalability issue then
-    <braunr> combined with the increased priorities
-    <braunr> if is indeed running full time on the host, whereas swapping
-      issues show the cpu being almost idle
-    <braunr> loadavg is high too so i guess there are many threads
-    <braunr>    0   971     3 -20 -20 1553 305358625 866485906 523M 63M *   S<o
-      ?    13hrs /hurd/ext2fs.static -A /dev/hd0s2
-    <braunr>    0   972     3 -20 -20 1434 125237556 719443981 483M 5.85M * S<o
-      ?    13hrs /hurd/ext2fs.static -A /dev/hd0s3
-    <braunr> around 1k5 each
-    <youpi> that's quite usual
-    <braunr> could be the priorities then
-    <braunr> but i'm afraid that if we lower them, the number of threads will
-      grow out of control
-    <braunr> (good thing is i'm currently working on a way to make libpthread
-      actually remove kernel resources)
-    <youpi> but the priorities should be the same in ext2fs and pfinet,
-      shouldn't they?
-    <braunr> yes but ext2 has a lot more threads than pfinet
-    <braunr> the scheduler only sees threads, we don't have a grouping feature
-    <youpi> right
-    <braunr> we also should remove priority depressing in glibc
-    <braunr> (in sched_yield)
-    <braunr> it affects spin locks
-
-    <braunr> youpi: is it normal to see priorities of 26 ?
-    <youpi> braunr: we have changed the nice factor
-    <braunr> ah, factor
-    <youpi> Mm, I'm however realizing the gnumach kernel running these systems
-      hasn't been upgraded in a while
-    <youpi> it may not even have the needed priority levels
-    <braunr> ar euare you using top right now on if ?
-    <braunr> hm no i don't see it any more
-    <braunr> well yes, could be the priorities ..
-    <youpi> I've rebooted with an upgraded kernel
-    <youpi> no issue so far
-    <youpi> package uploads will tell me on the long run
-    <braunr> i bet it's also a scalability issue
-    <youpi> but why would it appear now only?
-    <braunr> until the cache and other data containers start to get filled,
-      processing is fast enough that we don't see it hapenning
-    <youpi> sure, but I haven't seen that in the past
-    <braunr> oh it's combined with the increased priorities
-    <youpi> even after a week building packages
-    <braunr> what i mean is, increased priorities don't affect much if threads
-      porcess things fast
-    <braunr> things get longer with more data, and then increased prioritis
-      give more time to these threads
-    <braunr> and that's when the problem appears
-    <youpi> but increased priorities give more time to the pfinet threads too,
-      don't they?
-    <braunr> yes
-    <youpi> so what is different ?
-    <braunr> but again, there are a lot more threads elsewhere
-    <braunr> with a lot more data to process
-    <youpi> sure, but that has alwasy been so
-    <braunr> hm
-    <youpi> really, 1k5 threads does not surprise me at all :)
-    <youpi> 10k would
-    <braunr> there aren't all active either
-    <youpi> yes
-    <braunr> but right, i don't know why pfinet would be given less time than
-      other threads ..
-    <braunr> compared to before
-    <youpi> particularly on xen-based buildds
-    <braunr> libpthread is slower than cthreads
-    <youpi> where it doesn't even have to wait for netdde
-    <braunr> threads need more quanta to achieve the same ting
-    <braunr> perhaps processing could usually be completed in one go before,
-      and not any more
-    <braunr> we had a discussion about this with antrik
-
-    <braunr> youpi: concerning the buildd issue, i don't think pfinet is
-      affected actually
-    <braunr> but the applications using the network may be
-    <youpi> why using the network would be a difference ?
-    <braunr> normal applications have a lower priority
-    <braunr> what i mean is, pfinet simply has nothing to do, because normal
-      applications don't have enough cpu time
-    <braunr> (what you said earlier seemed to imply pfinet had issues, i don't
-      think it has)
-    <braunr> it should be easy to test by pinging the machine while under load
-    <braunr> we should also check the priority of the special thread used to
-      handle packets, both in pfinet and netdde
-    <braunr> this one isn't spawned by libports and is likely to have a lower
-      priority as well
-
-    <braunr> youpi: you're right, something very recent slowed things down a
-      lot
-    <braunr> perhaps the new priority factor
-    <braunr> well not the factor but i suppose the priority range has been
-      increased
-
-[[nice_vs_mach_thread_priorities]].
-
-    <youpi> braunr: haven't had any upload issue so far
-    <youpi> over 20 uploads
-    <youpi> while it was usually 1 every 2 before...
-    <youpi> so it was very probably the kernel missing the priorities levels
-    <braunr> ok
-    <braunr> i think i've had the same problem on another virtual machine
-    <braunr> with a custom kernel i built a few weeks ago
-    <braunr> same kind of issue i guess
-    <braunr> it's fine now, and always was on darnassus
-
-
-## IRC, freenode, #hurd, 2012-12-05
-
-    <braunr> tschwinge: i'm currently working on a few easy bugs and i have
-      planned improvements for libpthreads soon
-    <pinotree> wotwot, which ones?
-    <braunr> pinotree: first, fixing pthread_cond_timedwait (and everything
-      timedsomething actually)
-    <braunr> pinotree: then, fixing cancellation
-    <braunr> pinotree: and last but not least, optimizing thread wakeup
-    <braunr> i also want to try replacing spin locks and see if it does what i
-      expect
-    <pinotree> which fixes do you plan applying to cond_timedwait?
-    <braunr> see sysdeps/generic/pt-cond-timedwait.c
-    <braunr> the FIXME comment
-    <pinotree> ah that
-    <braunr> well that's important :)
-    <braunr> did you have something else in mind ?
-    <pinotree> hm, __pthread_timedblock... do you plan fixing directly there? i
-      remember having seem something related to that (but not on conditions),
-      but wasn't able to see further
-    <braunr> it has the same issue
-    <braunr> i don't remember the details, but i wrote a cthreads version that
-      does it right
-    <braunr> in the io_select_timeout branch
-    <braunr> see
-      http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/libthreads/cancel-cond.c?h=rbraun/select_timeout
-      for example
-    * pinotree looks
-    <braunr> what matters is the msg_delivered member used to synchronize
-      sleeper and waker
-    <braunr> the waker code is in
-      http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/libthreads/cprocs.c?h=rbraun/select_timeout
-    <pinotree> never seen cthreads' code before :)
-    <braunr> soon you shouldn't have any more reason to :p
-    <pinotree> ah, so basically the cthread version of the pthread cleanup
-      stack + cancelation (ie the cancel hook) broadcasts the condition
-    <braunr> yes
-    <pinotree> so a similar fix would be needed in all the places using
-      __pthread_timedblock, that is conditions and mutexes
-    <braunr> and that's what's missing in glibc that prevents deploying a
-      pthreads based hurd currently
-    <braunr> no that's unrelated
-    <pinotree> ok
-    <braunr> the problem is how __pthread_block/__pthread_timedblock is
-      synchronized with __pthread_wakeup
-    <braunr> libpthreads does exactly the same thing as cthreads for that,
-      i.e. use messages
-    <braunr> but the message alone isn't enough, since, as explained in the
-      FIXME comment, it can arrive too late
-    <braunr> it's not a problem for __pthread_block because this function can
-      only resume after receiving a message
-    <braunr> but it's a problem for __pthread_timedblock which can resume
-      because of a timeout
-    <braunr> my solution is to add a flag that says whether a message was
-      actually sent, and lock around sending the message, so that the thread
-      resume can accurately tell in which state it is
-    <braunr> and drain the message queue if needed
-    <pinotree> i see, race between the "i stop blocking because of timeout" and
-      "i stop because i got a message" with the actual check for the real cause
-    <braunr> locking around mach_msg may seem overkill but it's not in
-      practice, since there can only be one message at most in the message
-      queue
-    <braunr> and i checked that in practice by limiting the message queue size
-      and check for such errors
-    <braunr> but again, it would be far better with mutexes only, and no spin
-      locks
-    <braunr> i wondered for a long time why the load average was so high on the
-      hurd under even "light" loads
-    <braunr> now i know :)
-
-
-## IRC, freenode, #hurd, 2012-12-27
-
-    <youpi> btw, good news: the installer works with libpthread
-    <youpi> (well, at least boots, I haven't tested the  installation)
-    <braunr> i can do that if the image is available publically
-    <braunr> youpi: the one thing i suspect won't work right is the hurd
-      console :/
-    <braunr> so we might need to not enable it by default
-    <youpi> braunr: you mean the mode setting?
-    <braunr> youpi: i don't know what's wrong with the hurd console, but it
-      seems to deadlock with pthreads
-    <youpi> ah?
-    <youpi> I don't have such issue
-    <braunr> ah ? i need to retest that then
-
-Same issue as [[term_blocking]] perhaps?
-
-
-## IRC, freenode, #hurd, 2013-01-06
-
-    <youpi> it seems fakeroot has become slow as hell
-
-[[pfinet_timers]].
-
-    <braunr> fakeroot is the main source of dead name notifications
-    <braunr> well, a very heavy one
-    <braunr> with pthreads hurd servers, their priority is raised, precisely to
-      give them time to handle those dead name notifications
-    <braunr> which slows everything else down, but strongly reduces the rate at
-      which additional threads are created to handle dn notifications
-    <braunr> so this is expected
-    <youpi> ok :/
-    <braunr> which is why i mentioned a rewrite of io_select into a completely
-      synchronous io_poll
-    <braunr> so that the client themselves remove their requests, instead of
-      the servers doing it asynchronously when notified
-    <youpi> by "slows everything else down", you mean, if the servers do take
-      cpu time?
-    <braunr> but considering the amount of messaging it requires, it will be
-      slow on moderate to large fd sets with frequent calls (non blocking or
-      low timeout)
-    <braunr> yes
-    <youpi> well here the problem is not really it gets slowed down
-    <youpi> but that e.g. for gtk+2.0 build, it took 5h cpu time
-    <youpi> (and counting)
-    <braunr> ah, the hurd with pthreads is noticeably slower too
-    <braunr> i'm not sure why, but i suspect the amount of internal function
-      calls could account for some of the overhead
-    <youpi> I mean the fakeroot process
-    <youpi> not the server process
-    <braunr> hum
-    <braunr> that's not normal :)
-    <youpi> that's what I meant
-    <braunr> well, i should try to build gtk+20 some day
-    <braunr> i've been building glibc today and it's going fine for now
-    <youpi> it's the install stage which poses problem
-    <youpi> I've noticed it with the hurd package too
-    <braunr> the hurd is easier to build
-    <braunr> that's a good test case
-    <braunr> there are many times when fakeroot just doesn't use cpu, and it
-      doesn't look like a select timeout issue (it still behaved that way with
-      my fixed branch)
-    <youpi> in general, pfinet is taking really a lot of cpu time
-    <youpi> that's surprising
-    <braunr> why ?
-    <braunr> fakeroot uses it a lot
-    <youpi> I know
-    <youpi> but still
-    <youpi> 40% cpu time is not normal
-    <youpi> I don't see why it would need so much cpu time
-    <braunr> 17:57 < braunr> but considering the amount of messaging it
-      requires, it will be slow on moderate to large fd sets with frequent
-      calls (non blocking or low timeout)
-    <youpi> by "it", what did you mean?
-    <youpi> I thought you meant the synchronous select implementation
-    <braunr> something irrelevant here
-    <braunr> yes
-    <braunr> what matters here is the second part of my sentence, which is what
-      i think happens now
-    <youpi> you mean it's the IPC overhead which is taking so much time?
-    <braunr> i mean, it doesn't matter if io_select synchronously removes
-      requests, or does it by destroying ports and relying on notifications,
-      there are lots of messages in this case anyway
-    <braunr> yes
-    <youpi> why "a lot" ?
-    <youpi> more than one per select call?
-    <braunr> yes
-    <youpi> why ?
-    <braunr> one per fd
-    <braunr> then one to wait
-    <youpi> there are two in faked
-    <braunr> hum :)
-    <braunr> i remember the timeout is low
-    <braunr> but i don't remember its value
-    <youpi> the timeout is NULL in faked
-    <braunr> the client then
-    <youpi> the client doesn't use select
-    <braunr> i must be confused
-    <braunr> i thought it did through the fakeroot library
-    <braunr> but yes, i see the same behaviour, 30 times more cpu for pfinet
-      than faked-tcp
-    <braunr> or let's say between 10 to 30
-    <braunr> and during my tests, these were the moments the kernel would
-      create lots of threads in servers and fail because of lack of memory,
-      either kernel memory, or virtual in the client space (filled with thread
-      stacks)
-    <braunr> it could be due to threads spinning too much
-    <braunr> (inside pfinet)
-    <youpi> attaching a gdb shows it mostly inside __pthread_block
-    <youpi> uh, how awful pfinet's select is
-    <youpi> a big global lock
-    <youpi> whenever something happens all threads get woken up
-    <pinotree> BKL!
-    * pinotree runs
-    <braunr> we have many big hurd locks :p
-    <youpi> it's rather a big translator lock
-    <braunr> more than a global lock it seems, a global condvar too, isn't it ?
-    <youpi> sure
-    <braunr> we have a similar problem with the hurd-specific cancellation
-      code, it's in my todo list with io_select
-    <youpi> ah, no, the condvar is not global
-
-
-## IRC, freenode, #hurd, 2013-01-14
-
-    <braunr> *sigh* thread cancellable is totally broken :(
-    <braunr> cancellation*
-    <braunr> it looks like playing with thread cancellability can make some
-      functions completely restart
-    <braunr> (e.g. one call to printf to write twice its output)
-
-[[git_duplicated_content]], [[git-core-2]].
-
-    * braunr is cooking a patch to fix pthread cancellation in
-        pthread_cond_{,timed}wait, smells good
-    <braunr> youpi: ever heard of something that would make libc functions
-      "restart" ?
-    <youpi> you mean as a feature, or as a bug ?
-    <braunr> when changing the pthread cancellation state of a thread, i
-      sometimes see printf print its output twice
-    <youpi> or perhaps after a signal dispatch?
-    <braunr> i'll post my test code
-    <youpi> that could be a duplicate write
-    <youpi> due to restarting after signal
-    <braunr> http://www.sceen.net/~rbraun/pthreads_test_cancel.c
-    #include <stdio.h>
-    #include <stdarg.h>
-    #include <stdlib.h>
-    #include <pthread.h>
-    #include <unistd.h>
-    
-    static pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
-    static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
-    static int predicate;
-    static int ready;
-    static int cancelled;
-    
-    static void
-    uncancellable_printf(const char *format, ...)
-    {
-        int oldstate;
-        va_list ap;
-    
-        va_start(ap, format);
-        pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &oldstate);
-        vprintf(format, ap);
-        pthread_setcancelstate(oldstate, &oldstate);
-        va_end(ap);
-    }
-    
-    static void *
-    run(void *arg)
-    {
-        uncancellable_printf("thread: setting ready\n");
-        ready = 1;
-        uncancellable_printf("thread: spin until cancellation is sent\n");
-    
-        while (!cancelled)
-            sched_yield();
-    
-        uncancellable_printf("thread: locking mutex\n");
-        pthread_mutex_lock(&mutex);
-        uncancellable_printf("thread: waiting for predicate\n");
-    
-        while (!predicate)
-            pthread_cond_wait(&cond, &mutex);
-    
-        uncancellable_printf("thread: unlocking mutex\n");
-        pthread_mutex_unlock(&mutex);
-        uncancellable_printf("thread: exit\n");
-        return NULL;
-    }
-    
-    int
-    main(int argc, char *argv[])
-    {
-        pthread_t thread;
-    
-        uncancellable_printf("main: create thread\n");
-        pthread_create(&thread, NULL, run, NULL);
-        uncancellable_printf("main: spin until thread is ready\n");
-    
-        while (!ready)
-            sched_yield();
-    
-        uncancellable_printf("main: sending cancellation\n");
-        pthread_cancel(thread);
-        uncancellable_printf("main: setting cancelled\n");
-        cancelled = 1;
-        uncancellable_printf("main: joining thread\n");
-        pthread_join(thread, NULL);
-        uncancellable_printf("main: exit\n");
-        return EXIT_SUCCESS;
-    }
-    <braunr> youpi: i'd see two calls to write, the second because of a signal,
-      as normal, as long as the second call resumes, but not restarts after
-      finishing :/
-    <braunr> or restarts because nothing was done (or everything was entirely
-      rolled back)
-    <youpi> well, with an RPC you may not be sure whether it's finished or not
-    <braunr> ah
-    <youpi> we don't really have rollback
-    <braunr> i don't really see the difference with a syscall there
-    <youpi> the kernel controls the interruption in the case of the syscall
-    <braunr> except that write is normally atomic if i'm right
-    <youpi> it can't happen on the way back to userland
-    <braunr> but that could be exactly the same with RPCs
-    <youpi> while perhaps it can happen on the mach_msg back to userland
-    <braunr> back to userland ok, back to the application, no
-    <braunr> anyway, that's a side issue
-    <braunr> i'm fixing a few bugs in libpthread
-    <braunr> and noticed that
-    <braunr> (i should soon have patches to fix - at least partially - thread
-      cancellation and timed blocking)
-    <braunr> i was just wondering how cancellation how handled in glibc wrt
-      libpthread
-    <youpi> I don't know
-    <braunr> (because the non standard hurd cancellation has nothing to do with
-      pthread cancellation)à
-    <braunr> ok
-    <braunr> s/how h/is h/
-
-
-### IRC, freenode, #hurd, 2013-01-15
-
-    <tschwinge> braunr: Re »one call to printf to write twice its output«:
-      sounds familiar:
-      http://www.gnu.org/software/hurd/open_issues/git_duplicated_content.html
-      and http://www.gnu.org/software/hurd/open_issues/git-core-2.html
-    <braunr> tschwinge: what i find strange with the duplicated operations i've
-      seen is that i merely use pthreads and printf, nothing else
-    <braunr> no setitimer, no alarm, no select
-    <braunr> so i wonder how cancellation/syscall restart is actually handled
-      in our glibc
-    <braunr> but i agree with you on the analysis
-
-
-### IRC, freenode, #hurd, 2013-01-16
-
-    <braunr> neal: do you (by any chance) remember if there could possibly be
-      spurious wakeups in your libpthread implementation ?
-    <neal> braunr: There probably are.
-    <neal> but I don't recall
-
-    <braunr> i think the duplicated content issue is due to the libmach/glibc
-      mach_msg wrapper
-    <braunr> which restarts a message send if interrupted
-    <tschwinge> Hrm, depending on which point it has been interrupted you mean?
-    <braunr> yes
-    <braunr> not sure yet and i could be wrong
-    <braunr> but i suspect that if interrupted after send and during receive,
-      the restart might be wrongfully done
-    <braunr> i'm currently reworking the timed* pthreads functions, doing the
-      same kind of changes i did last summer when working on select (since
-      implement the timeout at the server side requires pthread_cond_timedwait)
-    <braunr> and i limit the message queue size of the port used to wake up
-      threads to 1
-    <braunr> and it seems i have the same kind of problems, i.e. blocking
-      because of a second, unexpected send
-    <braunr> i'll try using __mach_msg_trap directly and see how it goes
-    <tschwinge> Hrm, mach/msg.c:__mach_msg does look correct to me, but yeah,
-      won't hurd to confirm this by looking what direct usage of
-      __mach_msg_trap is doing.
-    <braunr> tschwinge: can i ask if you still have a cthreads based hurd
-      around ?
-    <braunr> tschwinge: and if so, to send me libthreads.so.0.3 ... :)
-    <tschwinge> braunr: darnassus:~tschwinge/libthreads.so.0.3
-    <braunr> call   19c0 <mach_msg@plt>
-    <braunr> so, cthreads were also using the glibc wrapper
-    <braunr> and i never had a single MACH_SEND_INTERRUPTED
-    <braunr> or a busy queue :/
-    <braunr> (IOW, no duplicated messages, and the wrapper indeed looks
-      correct, so it's something else)
-    <tschwinge> (Assuming Mach is doing the correct thing re interruptions, of
-      course...)
-    <braunr> mach doesn't implement it
-    <braunr> it's explicitely meant to be done in userspace
-    <braunr> mach merely reports the error
-    <braunr> i checked the osfmach code of libmach, it's almost exactly the
-      same as ours
-    <tschwinge> Yeah, I meant Mach returns the interurption code but anyway
-      completed the RPC.
-    <braunr> ok
-    <braunr> i don't expect mach wouldn't do it right
-    <braunr> the only difference in osf libmach is that, when retrying,
-      MACH_SEND_INTERRUPT|MACH_RCV_INTERRUPT are both masked (for both the
-      send/send+receive and receive cases)
-    <tschwinge> Hrm.
-    <braunr> but they say it's for performance, i.e. mach won't take the slow
-      path because of unexpected bits in the options
-    <braunr> we probably should do the same anyway
-
-
-### IRC, freenode, #hurd, 2013-01-17
-
-    <braunr> tschwinge: i think our duplicated RPCs come from
-      hurd/intr-msg.c:148 (err == MACH_SEND_INTERRUPTED but !(option &
-      MACH_SEND_MSG))
-    <braunr> a thread is interrupted by a signal meant for a different thread
-    <braunr> hum no, still not that ..
-    <braunr> or maybe .. :)
-    <tschwinge> Hrm.  Why would it matter for for the current thread for which
-      reason (different thread) mach_msg_trap returns *_INTERRUPTED?
-    <braunr> mach_msg wouldn't return it, as explained in the comment
-    <braunr> the signal thread would, to indicate the send was completed but
-      the receive must be retried
-    <braunr> however, when retrying, the original user_options are used again,
-      which contain MACH_SEND_MSG
-    <braunr> i'll test with a modified version that masks it
-    <braunr> tschwinge: hm no, doesn't fix anything :(
-
-
-### IRC, freenode, #hurd, 2013-01-18
-
-    <braunr> the duplicated rpc calls is one i find very very frustrating :/
-    <youpi> you mean the dup writes we've seen lately?
-    <braunr> yes
-    <youpi> k
-
-
-### IRC, freenode, #hurd, 2013-01-19
-
-    <braunr> all right, i think the duplicated message sends are due to thread
-      creation
-    <braunr> the duplicated message seems to be sent by the newly created
-      thread
-    <braunr> arg no, misread
-
-
-### IRC, freenode, #hurd, 2013-01-20
-
-    <braunr> tschwinge: youpi: about the diplucated messages issue, it seems to
-      be caused by two threads (with pthreads) doing an rpc concurrently
-    <braunr> duplicated*
-
-
-### IRC, freenode, #hurd, 2013-01-21
-
-    <braunr> ah, found something interesting
-    <braunr> tschwinge: there seems to be a race on our file descriptors
-    <braunr> the content written by one thread seems to be retained somewhere
-      and another thread writing data to the file descriptor will resend what
-      the first already did
-    <braunr> it could be a FILE race instead of fd one though
-    <braunr> yes, it's not at the fd level, it's above
-    <braunr> so good news, seems like the low level message/signalling code
-      isn't faulty here
-    <braunr> all right, simple explanation: our IO_lockfile functions are
-      no-ops
-    <pinotree> braunr: i found that out days ago, and samuel said they were
-      okay
-
-[[glibc]], `flockfile`/`ftrylockfile`/`funlockfile`.
-
-
-## IRC, freenode, #hurd, 2013-01-15
-
-    <braunr> hmm, looks like subhurds have been broken by the pthreads patch :/
-    <braunr> arg, we really do have broken subhurds :((
-    <braunr> time for an immersion in the early hurd bootstrapping stuff
-    <tschwinge> Hrm.  Narrowed down to cthreads -> pthread you say.
-    <braunr> i think so
-    <braunr> but i think the problem is only exposed
-    <braunr> it was already present before
-    <braunr> even for the main hurd, i sometimes have systems blocking on exec
-    <braunr> there must be a race there that showed far less frequently with
-      cthreads
-    <braunr> youpi: we broke subhurds :/
-    <youpi> ?
-    <braunr> i can't start one
-    <braunr> exec seems to die and prevent the root file system from
-      progressing
-    <braunr> there must be a race, exposed by the switch to pthreads
-    <braunr> arg, looks like exec doesn't even reach main :(
-    <braunr> now, i'm wondering if it could be the tls support that stops exec
-    <braunr> although i wonder why exec would start correctly on a main hurd,
-      and not on a subhurd :(
-    <braunr> i even wonder how much progress ld.so.1 is able to make, and don't
-      have much idea on how to debug that
-
-
-### IRC, freenode, #hurd, 2013-01-22
-
-    <braunr> hm, subhurds seem to be broken because of select
-    <braunr> damn select !
-    <braunr> hm i see, we can't boot a subhurd that still uses libthreads from
-      a main hurd that doesn't
-    <braunr> the linker can't find it and doesn't start exec
-    <braunr> pinotree: do you understand what the fmh function does in
-      sysdeps/mach/hurd/dl-sysdep.c ?
-    <braunr> i think we broke subhurds by fixing vm_map with size 0
-    <pinotree> braunr: no idea, but i remember thomas talking about this code
-
-[[vm_map_kernel_bug]]
-
-    <braunr> it checks for KERN_INVALID_ADDRESS and KERN_NO_SPACE
-    <braunr> and calls assert_perror(err); to make sure it's one of them
-    <braunr> but now, KERN_INVALID_ARGUMENT can be returned
-    <braunr> ok i understand what it does
-    <braunr> and youpi has changed the code, so he does too
-    <braunr> (now i'm wondering why he didn't think of it when we fixed vm_map
-      size with 0 but his head must already be filled with other things so ..)
-    <braunr> anyway, once this is dealt with, we get subhurds back :)
-    <braunr> yes, with a slight change, my subhurd starts again \o/
-    <braunr> youpi: i found the bug that prevents subhurds from booting
-    <braunr> it's caused by our fixing of vm_map with size 0
-    <braunr> when ld.so.1 starts exec, the code in
-      sysdeps/mach/hurd/dl-sysdep.c fails because it doesn't expect the new
-      error code we introduced
-    <braunr> (the fmh functions)
-    <youpi> ah :)
-    <youpi> good :)
-    <braunr> adding KERN_INVALID_ARGUMENT to the list should do the job, but if
-      i understand the code correctly, checking if fmhs isn't 0 before calling
-      vm_map should do the work too
-    <braunr> s/do the work/work/
-    <braunr> i'm not sure which is the preferred way
-    <youpi> otherwise I believe fmh could be just fixed to avoid calling vm_map
-      in the !fmhs case
-    <braunr> yes that's what i currently do
-    <braunr> at the start of the loop, just after computing it
-    <braunr> seems to work so far
-
-
-## IRC, freenode, #hurd, 2013-01-22
-
-    <braunr> i have almost completed fixing both cancellation and timeout
-      handling, but there are still a few bugs remaining
-    <braunr> fyi, the related discussion was
-      https://lists.gnu.org/archive/html/bug-hurd/2012-08/msg00057.html
-
-
-## IRC, freenode, #hurd, 2014-01-01
-
-    <youpi> braunr: I have an issue with  tls_thread_leak
-    <youpi> int main(void) {
-    <youpi> pthread_create(&t, NULL, foo, NULL);
-    <youpi> pthread_exit(0);
-    <youpi> }
-    <youpi> this fails at least with the libpthread without your libpthread
-      thread termination patch
-    <youpi> because for the main thread, tcb->self doesn't contain thread_self
-    <youpi> where is tcb->self supposed to be initialized for the main thread?
-    <youpi> there's also the case of fork()ing from main(), then calling
-      pthread_exit()
-    <youpi> (calling pthread_exit() from the child)
-    <youpi> the child would inherit the tcb->self value from the parent, and
-      thus pthread_exit() would try to kill the father
-    <youpi> can't we still do tcb->self = self, even if we don't keep a
-      reference over the name?
-    <youpi> (the pthread_exit() issue above should be fixed by your thread
-      termination patch actually)
-    <youpi> Mmm, it seems the thread_t port that the child inherits actually
-      properly references the thread of the child, and not the thread of the
-      father?
-    <youpi> “For the name we use for our own thread port, we will insert the
-      thread port for the child main user thread after we create it.” Oh, good
-      :)
-    <youpi> and, “Skip the name we use for any of our own thread ports.”, good
-      too :)
-    <braunr> youpi: reading
-    <braunr> youpi: if we do tcb->self = self, we have to keep the reference
-    <braunr> this is strange though, i had tests that did exactlt what you're
-      talking about, and they didn't fail
-    <youpi> why?
-    <braunr> if you don't keep the reference, it means you deallocate self
-    <youpi> with the thread termination patch, tcb->self is not used for
-      destruction
-    <braunr> hum
-    <braunr> no it isn't
-    <braunr> but it must be deallocated at some point if it's not temporary
-    <braunr> normally, libpthread should set it for the main thread too, i
-      don't understand
-    <youpi> I don't see which code is supposed to do it
-    <youpi> sure it needs to be deallocated at some point
-    <youpi> but does tcb->self has to wear the reference?
-    <braunr> init_routine should do it
-    <braunr> it calls __pthread_create_internal
-    <braunr> which allocates the tcb
-    <braunr> i think at some point, __pthread_setup should be called for it too
-    <youpi> but what makes pthread->kernel_thread contain the port for the
-      thread?
-    <braunr> but i have to check that
-    <braunr> __pthread_thread_alloc does that
-    <braunr> so normally it should work
-    <braunr> is your libpthread up to date as well ?
-    <youpi> no, as I said it doesn't contain the thread destruction patch
-    <braunr> ah
-    <braunr> that may explain
-    <youpi> but the tcb->self uninitialized issue happens on darnassus too
-    <youpi> it just doesn't happen to crash because it's not used
-    <braunr> that's weird :/
-    <youpi> see ~youpi/test.c there for instance
-    <braunr> humpf
-    <braunr> i don't see why :/
-    <braunr> i'll debug that later
-    <braunr> youpi: did you find the problem ?
-    <youpi> no
-    <youpi> I'm working on fixing the libpthread hell in the glibc debian
-      package :)
-    <youpi> i.e. replace a dozen patches with a git snapshot
-    <braunr> ah you reverted commit
-    <braunr> +a
-    <braunr> i imagine it's hairy :)
-    <youpi> not too much actually
-    <braunr> wow :)
-    <youpi> with the latest commits, things have converged
-    <youpi> it's now about small build details
-    <youpi> I just take time to make sure I'm getting the same source code in
-      the end :)
-    <braunr> :)
-    <braunr> i hope i can determine what's going wrong tonight
-    <braunr> youpi: avec mach_print, je vois bien self setté par la libpthread
-      ..
-    <youpi> mais à autre chose que 0 ?
-    <braunr> oui
-    <braunr> bizarrement, l'autre thread n'as pas la même valeur
-    <braunr> tu es bien sûr que c'est self que tu affiches avec l'assembleur ?
-    <braunr> oops, english
-    <youpi> see test2
-    <youpi> so I'm positive
-    <braunr> well, there obviously is a bug
-    <braunr> but are you certain your assembly code displays the thread port
-      name ?
-    <youpi> I'm certain it displays tcb->self
-    <braunr> oh wait, hexadecimal, ok
-    <youpi> and the value happens to be what mach_thread_self returns
-    <braunr> ah right
-    <youpi> ah, right, names are usually decimals :)
-    <braunr> hm
-    <braunr> what's the problem with test2 ?
-    <youpi> none
-    <braunr> ok
-    <youpi> I was just checking what happens on fork from another thread
-    <braunr> ok i do have 0x68 now
-    <braunr> so the self field gets erased somehow
-    <braunr> 15:34 < youpi> this fails at least with the libpthread without
-      your libpthread thread termination patch
-    <braunr> how does it fail ?
-    <youpi> ../libpthread/sysdeps/mach/pt-thread-halt.c:44:
-      __pthread_thread_halt: Unexpected error: (ipc/send) invalid destination
-      port.
-    <braunr> hm
-    <braunr> i don't have that problem on darnassus
-    <youpi> with the new libc?
-    <braunr> the pthread destruction patch actually doesn't use the tcb->self
-      name if i'm right
-    <braunr> yes
-    <braunr> what is tcb->self used for ?
-    <youpi> it used to be used by pt-thread-halt
-    <youpi> but is darnassus using your thread destruction patch?
-    <youpi> as I said, since your thread destruction pathc doesn't use
-      tcb->self, it doesn't have the issue
-    <braunr> the patched libpthread merely uses the sysdeps kernel_thread
-      member
-    <braunr> ok
-    <youpi> it's the old libpthread against the new libc which has issues
-    <braunr> yes it is
-    <braunr> so for me, the only thing to do is make sure tcb->self remains
-      valid
-    <braunr> we could simply add a third user ref but i don't like the idea
-    <youpi> well, as you said the issue is rather that tcb->self gets
-      overwritten
-    <youpi> there is no reason why it should
-    <braunr> the value is still valid when init_routine exits, so it must be in
-      libc
-    <youpi> or perhaps for some reason tls gets initialized twice
-    <braunr> maybe
-    <youpi> and thus what libpthread's init writes to is not what's used later
-    <braunr> i've add a print in pthread_create, to see if self actually got
-      overwritten
-    <braunr> and it doesn't
-    <braunr> there is a disrepancy between the tcb member in libpthread and
-      what libc uses for tls
-    <braunr> added*
-    <braunr> (the print is at the very start of pthread_create, and displays
-      the thread name of the caller only)
-    <youpi> well, yes, for the main thread libpthread shouldn't be allocating a
-      new tcb
-    <youpi> and just use the existing one
-    <braunr> ?
-    <youpi> the main thread's tcb is initialized before the threading library
-      iirc
-    <braunr> hmm
-    <braunr> it would make sense if we actually had non-threaded programs :)
-    <youpi> at any rate, the address of the tcb allocated by libpthread is not
-      put into registers
-    <braunr> how does it get there for the other threads ?
-    <youpi> __pthread_setup does it
-    <braunr> so
-    <braunr> looks like dl_main is called after init_routine
-    <braunr> and it then calls init_tls
-    <braunr> init_tls returns the tcb for the main thread, and that's what
-      overrides the libpthread one
-    <youpi> yes, _hurd_tls_init is called very early, before init_routine
-    <youpi> __pthread_create_internal could fetch the tcb pointer from gs:0
-      when it's the main thread
-    <braunr> so there is something i didn't get right
-    <braunr> i thought _hurd_tls_init was called as part of dl_main
-    <youpi> well, it's not a bug of yours, it has always been bug :)
-    <braunr> which is called *after* init_routine
-    <braunr> and that explains why the libpthread tcb isn't the one installed
-      in the thread register
-    <braunr> i can actually check that quite easily
-    <youpi> where do you see dl_main called after init_routine?
-    <braunr> well no i got that wrong somehow
-    <braunr> or i'm unable to find it again
-    <braunr> let's see
-    <braunr> init_routine is called by init which is called by _dl_init_first
-    <braunr> which i can only find in the macro RTLD_START_SPECIAL_INIT
-    <braunr> with print traces, i see dl_main called before init_routine
-    <braunr> so yes, libpthread should reuse it
-    <braunr> the tcb isn't overriden, it's just never installed
-    <braunr> i'm not sure how to achieve that cleanly
-    <youpi> well, it is installed, by _hurd_tls_init
-    <youpi> it's the linker which creates the main thread's tcb
-    <youpi> and calls _hurd_tls_init to install it
-    <youpi> before the thread library enters into action
-    <braunr> agreed
-
-
-### IRC, freenode, #hurd, 2014-01-14
-
-    <braunr> btw, are you planning to do something with regard to the main
-      thread tcb initialization issue ?
-    <youpi> well, I thought you were working on it
-    <braunr> ok
-    <braunr> i wasn't sure
-
-
-### IRC, freenode, #hurd, 2014-01-19
-
-    <braunr> i have some fixup code for the main thread tcb
-    <braunr> but it sometimes crashes on tcb deallocation
-    <braunr> is there anything particular that you would know about the tcb of
-      the main thread ?
-    <braunr> (that could help explaining this)
-    <youpi> Mmmm, I don't think there is anything particular
-    <braunr> doesn't look like the first tcb can be reused safely
-    <braunr> i think we should instead update the thread register to point to
-      the pthread tcb
-    <youpi> what do you mean by "the first tcb" exactly?
-
-
-## IRC, freenode, #hurd, 2014-01-03
-
-    <gg0> braunr: hurd from your repo can't boot. restored debian one
-    <braunr> gg0: it does boot
-    <braunr> gg0: but you need everything (gnumach and glibc) in order to make
-      it work
-    <braunr> i think youpi did take care of compatibility with older kernels
-    <teythoon> braunr: so do we need a rebuilt libc for the latest hurd from
-      git ?
-    <braunr> teythoon: no, the hurd isn't the problem
-    <teythoon> ok
-    <teythoon> good
-    <braunr> the problem is the libports_stability patch
-    <teythoon> what about it ?
-    <braunr> the hurd can't work correctly without it since the switch to
-      pthreads
-    <braunr> because of subtle bugs concerning resource recycling
-    <teythoon> ok
-    <braunr> these have been fixed recently by youpi and me (youpi fixed them
-      exactly as i did, which made my life very easy when merging :))
-    <braunr> there is also the problem of the stack sizes, which means the hurd
-      servers could use 2M stacks with an older glibc
-    <braunr> or perhaps it chokes on an error when attempting to set the stack
-      size because it was unsupported
-    <braunr> i don't know
-    <braunr> that may be what gg0 suffered from
-    <gg0> yes, both gnumach and eglibc were from debian. seems i didn't
-      manually upgrade eglibc from yours
-    <gg0> i'll reinstall them now. let's screw it up once again
-    <braunr> :)
-    <braunr> bbl
-    <gg0> ok it boots
-    <gg0> # apt-get install
-      {hurd,hurd-dev,hurd-libs0.3}=1:0.5.git20131101-1+rbraun.7
-      {libc0.3,libc0.3-dev,libc0.3-dbg,libc-dev-bin}=2.17-97+hurd.0+rbraun.1+threadterm.1
-    <gg0> there must a simpler way
-    <gg0> besides apt-pinning
-    <gg0> making it a real "experimental" release might help with -t option for
-      instance
-    <gg0> btw locales still segfaults
-    <gg0> rpctrace from teythoon gets stuck at
-      http://paste.debian.net/plain/74072/
-    <gg0> ("rpctrace locale-gen", last 300 lines)
diff --git a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn b/open_issues/libpthread/t/fix_have_kernel_resources.mdwn
deleted file mode 100644
index 02b6ab05..00000000
--- a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn
+++ /dev/null
@@ -1,1301 +0,0 @@
-[[!meta copyright="Copyright © 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_libpthread]]
-
-`t/fix_have_kernel_resources`
-
-Address problem mentioned in [[/libpthread]], *Threads' Death*.
-
-
-# IRC, freenode, #hurd, 2012-08-30
-
-    <braunr> tschwinge: this issue needs more cooperation with the kernel
-    <braunr> tschwinge: i.e. the ability to tell the kernel where the stack is,
-      so it's unmapped when the thread dies
-    <braunr> which requiring another thread to perform this deallocation
-
-
-## IRC, freenode, #hurd, 2013-05-09
-
-    <bddebian> braunr: Speaking of which, didn't you say you had another "easy"
-      task?
-    <braunr> bddebian: make a system call that both terminates a thread and
-      releases memory
-    <braunr> (the memory released being the thread stack)
-    <braunr> this way, a thread can completely terminates itself without the
-      assistance of a managing thread or deferring work
-    <bddebian> braunr: That's "easy" ? :)
-    <braunr> bddebian: since it's just a thread_terminate+vm_deallocate, it is
-    <braunr> something like thread_terminate_self
-    <bddebian> But a syscall not an RPC right?
-    <braunr> in hurd terminology, we don't make the distinction
-    <braunr> the only real syscalls are mach_msg (obviously) and some to get
-      well known port rights
-    <braunr> e.g. mach_task_self
-    <braunr> everything else should be an RPC but could be a system call for
-      performance
-    <braunr> since mach was designed to support clusters, it was necessary that
-      anything not strictly machine-local was an RPC
-    <braunr> and it also helps emulation a lot
-    <braunr> so keep doing RPCs :p
-
-
-## IRC, freenode, #hurd, 2013-05-10
-
-    <braunr> i'm not sure it should only apply to self though
-    <braunr> youpi: can we get a quick opinion on this please ?
-    <braunr> i've suggested bddebian to work on a new RPC that both terminates
-      a thread and releases its stack to help fix libpthread
-    <braunr> and initially, i thought of it as operating only on the calling
-      thread
-    <braunr> do you see any reason to make it work on any thread ?
-    <braunr> (e.g. a real thread_terminate + vm_deallocate)
-    <braunr> (or any reason not to)
-    <youpi> thread stack deallocation is always a burden indeed
-    <youpi> I'd tend to think it'd be useful, but perhaps ask the list
-
-
-## IRC, freenode, #hurd, 2013-06-26
-
-    <braunr> looks like there is a port right leak in libpthread
-    <braunr> grmbl, the port leak seems to come from mach_port_destroy being
-      buggy :/
-    <braunr> hum, apparently we're not the only ones to suffer from port leaks
-      wrt mach_port_destroy
-    <braunr> ew, libpthread is leaking
-    <pinotree> memory or ports?
-    <braunr> both
-    <pinotree> sounds great ;)
-    <braunr> as it is, libpthread doesn't destroy threads
-    <braunr> it queues them so they're recycled late
-    <braunr> r
-    <braunr> but there is confusion between the thread structure itself and its
-      internal resources
-    <braunr> i.e. there is pthread_alloc which allocates a thread structure,
-      and pthread_create which allocates everything else
-    <braunr> but on pthread_exit, nothing is destroyed
-    <braunr> when a thread structure is reused, its internal resources are
-      replaced by new instances
-    <pinotree> oh
-    <braunr> it's ok for joinable threads but most of our threads are detached
-    <braunr> pinotree: as expected, it's bigger than expected :p
-    <braunr> so i won't be able to write a quick fix
-    <braunr> the true way to fix this is make it possible for threads to free
-      their own resources
-    <braunr> let's do that :p
-    <braunr> ok, got the new thread termination function, i'll build eglibc
-      package providing it, then experiment with libpthread
-    <pinotree> braunr: iirc there's also a tschwinge patch in the debian eglibc
-      about that
-    <braunr> ah
-    <pinotree> libpthread_fix.diff
-    <braunr> i see
-    <braunr> thanks for the notice
-    <braunr> bddebian:
-      http://www.sceen.net/~rbraun/0001-thread_terminate_deallocate.patch
-    <braunr> bddebian: this is what it looks like
-    <braunr> see, short and easy
-    <bddebian> Aye but didn't youpi say not to bother with it??
-    <braunr> he did ?
-    <braunr> i don't remember
-    <bddebian> I thought that was the implication.  Or maybe that was the one I
-      already did!?
-    <braunr> i'd be interested in reading that
-    <braunr> anyway, there still are problems in libpthread, and this call is
-      one building block to fix some of them
-    <braunr> some important ones
-    <braunr> (big leaks)
-
-
-## IRC, freenode, #hurd, 2013-06-29
-
-    <braunr> damn, i fix leaks in libpthread, only to find out leaks somewhere
-      else :(
-    <braunr> bddebian: ok, actually it was a bit more complicated than what i
-      showed you
-    <braunr> because in addition to the stack, the call must also release the
-      send right in the caller's ipc space
-    <braunr> (it can't be released before since there would be no mean to
-      reference the thread to destroy)
-    <braunr> or perhaps it should strictly be reserved to self termination
-    <braunr> hmm
-    <braunr> yes it would probably be simpler
-    <braunr> but it should be a decent compromise
-    <braunr> i'm close to having a libpthread that doesn't leak anything
-    <braunr> and that properly destroys threads and their resources
-
-
-## IRC, freenode, #hurd, 2013-06-30
-
-    <braunr> bddebian: ok, it was even more tricky, because the kernel would
-      save the return value on the user stack (which is released by the call
-      and then invalid) before checking for asynchronous software traps (ASTs,
-      a kind of software interrupts in mach), and terminating the calling
-      thread is done by a deferred AST ... :)
-    <braunr> hmm, making threads able to terminate themselves makes rpctrace a
-      bit useless :/
-    <braunr> well, more restricted
-
-    <braunr> ok so, tough question :
-    <braunr> i have a small test program that creates a thread, and inspect its
-      state before any thread dies
-    <braunr> i can see msg_report_wait requests when using ps
-    <braunr> (one per thread)
-    <braunr> one of these requests create a new receive right, apparently for
-      the second thread in the test program
-    <braunr> each time i use ps, i can see the sequence numbers of two receive
-      rights increase
-    <braunr> i guess these rights are related to proc and signal handling per
-      thread
-    <braunr> but i can't find what create them
-    <braunr> does anyone know ?
-    <braunr> tschwing_: ^ :)
-
-    <braunr> again, too many things wrong elsewhere to cleanly destroy threads
-      ..
-    <braunr> something is deeply wrong with controlling terminals ..
-
-
-## IRC, freenode, #hurd, 2013-07-01
-
-    <braunr> youpi: if you happen to notice what receive right is created for
-      each thread (beyond the obvious port used for blocking and waking up),
-      please let me know
-    <braunr> it's the only port leak i have with thread destruction
-    <braunr> and i think it's related to the proc server since i see the
-      sequence number increase every time i use ps
-
-    <braunr> pinotree: my change doesn't fix all the pthread leaks but it's a
-      lot better
-    <braunr> bddebian: i've spent almost the whole week end trying to find the
-      last port leak without success
-    <braunr> there is some weird bug related to the controlling tty that hits
-      me every time i try to change something
-    <braunr> it's the same bug that prevents ttys from being correctly closed
-      when using ssh or screen
-    <braunr> well maybe not the same, but it's close
-    <braunr> some stale receive right kept around for no apparent reason
-    <braunr> and i can't find its source
-
-
-## IRC, freenode, #hurd, 2013-07-02
-
-    <braunr> and btw, i don't think i can make my libpthread patch work
-    <braunr> i'll just aim at avoiding leaks, but destroying threads and their
-      related resources depends on other changes i don't clearly see
-
-
-## IRC, freenode, #hurd, 2013-07-03
-
-    <braunr> grmbl, i don't want to give up thread destruction ..
-
-
-## IRC, freenode, #hurd, 2013-07-15
-
-    <braunr> btw, my work on thread destruction is currently stalled
-    <braunr> i don't have much free time right now
-
-
-## IRC, freenode, #hurd, 2013-09-13
-
-    <braunr> i think i know why my thread_terminate_deallocate patches leak one
-      receive port :>
-    <braunr> but now i'm not sure of the proper solution
-    <braunr> every time a thread is created and destroyed, a receive right is
-      leaked
-    <braunr> i guess it's simply the reply port ..
-    <braunr> grmbl
-    <braunr> i guess i have to make it a simpleroutine ...
-    <braunr> hm too bad, it's not the reply port :(
-    <braunr> it's also leaking some memory
-    <braunr> it doesn't seem related to my changes though
-    <braunr> stacks, rights, and threads are correctly destroyed
-    <braunr> some obscure state is left behind
-    <braunr> i wonder how exception ports are dealt with
-    <braunr> vminfo seems to confirm memory is leaking in the heap
-    <braunr> humpf
-    <braunr> oh silly me
-    <braunr> i don't detach threads
-    <teythoon> well, detach them ;)
-    <braunr> hm worse :p
-    <braunr> now i get additional dead names
-    <braunr> but it's a step forward
-
-
-## IRC, freenode, #hurd, 2013-09-16
-
-    <braunr> that thread port leak is so strange
-    <braunr> the leaked port seems to be created when the new thread starts
-      running
-    <braunr> so it looks like a port the kernel would implicitely create
-    <braunr> hm could it be a thread-specific reply port ?
-    <youpi> ah, yes, there is one of those
-    <braunr> how come mach/mig-reply.c in glibc isn't thread-safe ?
-    <youpi> it is overriden by sysdeps/mach/hurd/img-reply.c I guess
-    <youpi> which uses a threadvar for the mig reply port
-    <braunr> oh
-    <youpi> talking of which, there is also last_value in
-      sysdeps/mach/strerror_l.c
-    <youpi> strerror_thread_freeres is supposed to get called, but who knows
-    <braunr> it does look to be that port
-    <youpi> iirc that's the issue which prevents from letting us make threads
-      exit on idleness?
-    <braunr> one of them
-    <youpi> ok
-    <braunr> maybe the only one, yes
-    <braunr> i see memory leaks but they could be related/normal
-    <braunr> (i.e. not actual leaks)
-    <braunr> on the other hand, i also can't boot a hurd with my patch
-    <braunr> but i consider removing such leaks a priority
-    <braunr> does anyone know the semantic difference between
-      __mig_put_reply_port and __mig_dealloc_reply_port ?
-    <braunr> i guess __mig_dealloc_reply_port is actually a destruction
-      operation, right ?
-    <youpi> AIUI, dealloc is used when one wants the port not to be reused at
-      all
-    <youpi> because it has been used as a reference for something, and can
-      still be currently in use
-    <youpi> while put_reply would be when we're really done with it, and won't
-      use it again, and can thus be used as such
-    <youpi> or at least something like that
-    <braunr> heh
-    <braunr> __mig_dealloc_reply_port calls __mach_port_mod_refs, which is a
-      RPC, and creates a new reply port when destroying the current one
-    <youpi> bah
-    <youpi> that's fine, it's a deref of the old port, which is not in the
-      reply_port variable any more
-    <braunr> it's fine, but still a leak
-    <youpi> well, dealloc does not completely deallocs, yes
-    <braunr> that's not really the problem here
-    <braunr> i've introduced a case that wasn't considered at the time, namely
-      that a thread can destroy itself
-    <youpi> we probably need another function to be called from the thread exit
-    <braunr> i'll simply try with mach_port_destroy
-    <braunr> mach_port_destroy seems to be a RPC too ...
-    <braunr> grmbl
-    <youpi> isn't there a trap version somehow ?
-    <braunr> not in libc
-    <youpi> erf
-    <braunr> at least i know what's wrong now :)
-    <braunr> there still is a small memory leak i have to investigate
-    <braunr> but outside the stack
-    <braunr> the stack, the thread name and the thread are correctly destroyed
-    <braunr> slabinfo confirms only one port leak and nothing else is leaked
-    <braunr> ok so the port leak was indeed the thread-specific reply port,
-      taken care of
-    <braunr> there are also memory leaks too
-
-
-## IRC, freenode, #hurd, 2013-09-17
-
-    <braunr> teythoon: on my side, i'm getting to know our threading
-      implementation better
-    <braunr> closing to clean thread destruction
-    <braunr> x15 ipc will hide reply ports ;p
-    <braunr> memory leaks solved \o/
-    <braunr> now, have to fix memory release when joining
-    <braunr> proper reference counting on detach/join/exit, let's see how it
-      goes ..
-    <braunr> seems to work fine
-
-
-## IRC, freenode, #hurd, 2013-09-18
-
-    <braunr> ok i'll soon have gnumach and libc packages including proper
-      thread destruction :>
-    <teythoon> braunr: why did you have to touch gnumach?
-    <braunr> to add a call allowing threads to release ports and memory
-    <braunr> i.e. their last self reference, their reply port and their stack
-    <braunr> let me public my current patches
-    <teythoon> braunr: thread_commit_suicide ?
-    <braunr> hehe
-    <braunr> initially thread_terminate_self but
-    <braunr> it can be used by other threads too
-    <braunr> to i named it thread_terminate_release
-    <braunr> http://darnassus.sceen.net/~rbraun/0001-pthread_thread_halt.patch
-    <braunr>
-      http://darnassus.sceen.net/~rbraun/0001-thread_terminate_release.patch
-    <braunr> the pthread patch needs to be polished because it changes the
-      semantics of pthread_thread_halt
-    <braunr> but other than that, it should be complete
-    <pinotree> pthread_thread_halt_reallyhalt
-    <braunr> ok let's try these libc packages
-    <braunr> old static ext2fs for the root, but other than that, it boots
-    <braunr> let's try iceweasel
-    <braunr> (i'll need to build a hurd package against this new libc, removing
-      the libports_stability patch which prevents thread destruction in servers
-      on the way)
-    <teythoon> prevents thread destruction o_O
-    <braunr> yes
-    <braunr> in libports only ;p
-    <teythoon> oh, *only* in libports, I assumed for a moment that it affected
-      almost every component of the Hurd...
-    <teythoon> *phew(
-    <braunr> ... :)
-    <braunr> that's why, after a burst of messages, say because of aptitude
-      (select), you may see a few hundred threads still hanging around
-    <braunr> also why unused servers remain running even after several minutes,
-      where the normal timeout is 2mins
-    <teythoon> I wondered about that, some servers (symlink comes to mind) seem
-      to go away if unused (or that's how I read the code)
-    <braunr> symlinks are usually not servers, since most of them actually
-      exist in file systems, and are implemented through an optimization
-    <teythoon> yes I know that
-    <teythoon> trans/symlink.c reads:
-    <teythoon>       /* The timeout here is 10 minutes */
-    <teythoon>       err = mach_msg_server_timeout (fsys_server, 0, control,
-    <teythoon> 				     MACH_RCV_TIMEOUT, 1000 * 60 * 10);
-    <teythoon>       if (err == MACH_RCV_TIMED_OUT)
-    <teythoon> 	exit (0);
-    <braunr> ok
-    <teythoon> hm, /hurd/symlink doesn't feel at all like a symlink... but
-      works like one
-    <braunr> well, starting iceweasel makes X on my host freeze oO
-    <braunr> bbl
-    <teythoon> /hurd/symlink translators do go away after being unused for 10
-      minutes... this is funny if they are set up by hand instead of being
-      started from a passive translator record
-    <teythoon> magically vanishing symlinks ;)
-
-
-## IRC, freenode, #hurd, 2013-09-19
-
-    <braunr> hum, i can't rebuild a hurd package :(
-    <teythoon> braunr: with your thread destruction patches in libc?
-    <braunr> yes but it's unrelated
-    <braunr> In file included from ../../libdiskfs/boot-start.c:38:0:
-    <braunr> ./fsys_reply_U.h:173:15: error: conflicting types for
-      ‘fsys_get_children’
-    <braunr> i didn't see a new libc debian release
-    <teythoon> hm, David reported that as well
-    <teythoon>
-      id:CAEvUa7=QzOiS41G5Vq8k4AiaN10jAPm+CL_205OHJnL0xpJXbw@mail.gmail.com
-    <teythoon> uh oh
-    <teythoon> it seems I didn't add a _reply suffix to the reply routines :/
-    <teythoon> there's quite a bit of fallout from my patches, I kinda feel bad
-      :(
-    <braunr> teythoon: what i'm wondering is what youpi did too, since he got
-      hurd binary packages
-    <teythoon> braunr: well neither he nor I noticed that b/c for us the
-      declarations were just missing
-    <braunr> from libc you mean ?
-    <braunr> or hum gnumach-common ?
-    <teythoon> not sure actually
-    <braunr> no it's not a gnumach thing
-    <braunr> hurd-dev then
-    <teythoon> the build system should have cought these, or mig...
-    <braunr> also, i see you changed fsys_reply.defs, but nothing about
-      fsys_request.defs
-    <teythoon> I have no fsys_requests.defs
-    <braunr> looks like there was no fsys_request.defs in the first place
-      ... *sigh*
-    <braunr> do you know an application that often creates and destroys threads
-      ?
-    <teythoon> no, sorry
-    <pinotree> maybe some test suite
-    <braunr> ah right
-    <braunr> sysbench maybe
-    <braunr> also, i've been hit by a lot more network deadlocks than usual
-      lately
-    <braunr> fixing netdde has gained some priority in my todo list
-
-
-## IRC, freenode, #hurd, 2013-09-20
-
-    <braunr> oh, git is multithreaded
-    <braunr> great
-    <braunr> so i've actually tested my libpthread patch quite a lot
-
-
-## IRC, freenode, #hurd, 2013-09-25
-
-    <braunr> on a side note, i was able to build gnumach/libc/hurd packages
-      with thread destruction
-    <teythoon> nice :)
-    <braunr> they boot and work mostly fine, although they add their own issues
-    <braunr> e.g. the comm field of the root ext2fs is empty
-    <braunr> ps crashes when trying to display threads
-    <braunr> but thread destruction actually works, i.e. servers (those that
-      are configured that away at least) go away after some time, and even
-      heavily used servers such as ext2fs dynamically scale over time :)
-
-
-## IRC, freenode, #hurd, 2013-10-10
-
-    <braunr> concerning threads, i think i figured out the last bugs i had with
-      thread destruction
-    <braunr> it should be well on its way to be merged by the end of the year
-
-
-## IRC, freenode, #hurd, 2013-10-11
-
-    <gg0> braunr: is your thread destruction patch ready for testing?
-    <braunr> gg0: there are packages at my repository, yes
-    <braunr> but i still have hurd fixes to do before i polish it
-    <braunr> in particular, posix says returning from main() stops the entire
-      process and all other threads
-    <braunr> i didn't check that during the switch to pthreads, and ext2fs (and
-      maybe others) actually return from main but expect other threads to live
-      on
-    <braunr> this creates problems when the main thread is actually destroyed,
-      but not the process
-    <teythoon> braunr: tmpfs does something like that, but calls pthread_exit
-      at the end of main
-    <braunr> same effect
-    <braunr> this was fine with cthreads, but must be changed with pthreads
-    <braunr> and libpthread must be fixed to enforce it
-    <braunr> (or libc)
-
-    <braunr> diskfs_startup_diskfs should probably be changed to reuse the main
-      thread instead of returning
-
-
-## IRC, freenode, #hurd, 2013-10-19
-
-    <zacts> I know what threads are, but what is 'thread destruction'?
-    <braunr> the hurd currently never destroys individual threads
-    <braunr> they're destroyed when tasks are destroyed
-    <braunr> if the number of threads in a task peaks at a high number, say
-      thousands of them, they'll remain until the task is terminated
-    <braunr> such tasks are usually file systems, normally never restarted (and
-      in the case of the root file system, not restartable)
-    <braunr> this results in a form of leak
-    <braunr> another effect of this leak is that servers which should go away
-      because of inactivity still remain
-    <braunr> since thread destruction doesn't actually work, the debian package
-      uses a patch to prevent worker threads from timeouting
-    <braunr> and to finish with, since thread destruction actually doesn't
-      work, normal (unpatched) applications that destroy threads are certainly
-      failing bad
-    <braunr> i just need to polish a few things, wait for youpi to finish his
-      work on TLS to resolve conflicts, and that will be all
-
-
-## IRC, freenode, #hurd, 2013-10-30
-
-    <braunr> FYI, the packages on my repository enable actual thread
-      destruction, and i've altered the libports_stability.patch
-    <braunr> it nows only sets the global timeout to 0
-    <braunr> now*
-    <braunr> we actually can't let translator "die" on global timeout because
-      of a race issue
-    <braunr> tested for about two weeks now and no major problem sighted
-    <braunr> top reports processes running for 100% of their time when
-      terminating threads, but i expect it's simply mach/proc aggregating their
-      run time to the task
-    <braunr> 100% of cpu time
-
-
-## IRC, freenode, #hurd, 2013-11-08
-
-    <braunr> teythoon: darnassus is currently running a modified glibc with
-      thread destruction, yes
-    <teythoon> braunr: did that require any fixups in Hurd that I'd have missed
-      ?
-    <braunr> no
-    <braunr> well
-    <teythoon> b/c the resulting hurd package would not boot
-    <braunr> actually yes
-    <braunr> one
-    <braunr> i'll push the patch somewhere
-    <teythoon> iirc the mach-defpager spewed some error and /hurd/init failed
-      to bootstrap the system
-    <braunr> teythoon:
-      http://darnassus.sceen.net/~rbraun/0001-Prevent-diskfs-translators-from-destroying-main-thre.patch
-    <braunr> make sure you have the proper gnumach packages too :p
-    <teythoon> well, that could very well account for my trouble ;)
-    <teythoon> uh
-    <teythoon> well
-    <braunr> gnumach implements thread destruction, glibc uses it, hurd makes
-      sure it doesn't exit from main
-
-
-## IRC, freenode, #hurd, 2013-11-12
-
-    <braunr> ok so, calling pthread_exit() from main isn't the same as
-      returning from main()
-    <braunr> unlike what some man pages seem to say
-    <braunr> so loosing task info when destroying the main thread is actually a
-      proc bug
-    <braunr> ugh
-    <teythoon> ^^
-    <braunr> or a glibc one
-    <teythoon> the proc server, your favorite Hurd component...
-    <braunr> :)
-    <braunr> hm :/
-    <braunr> looks like command line arguments are stored on the stack of the
-      main thread
-    <braunr> and proc merely receives the addresses of those in the target task
-    <neal> why not just keep the main thread around?
-    <neal> it represents a minor resource leak, true
-    <braunr> yes
-    <braunr> that's the hack i suggested
-    <neal> but it is relatively small
-    <braunr> well no
-    <braunr> my hack was about diskfs translators
-    <braunr> it should be generalized in libpthread
-    <braunr> seems reasonable
-    <braunr> let's do it >)
-
-
-## IRC, freenode, #hurd, 2013-11-13
-
-    <youpi> braunr: there is a thread destruction issue in the experimental
-      ocaml build, worth looking at, probably
-    <braunr> what do you mean ?
-    <youpi> ... testing 'testfork.ml': ocamlcocamlrun:
-      ../libpthread/sysdeps/mach/pt-thread-halt.c:51: __pthread_thread_halt:
-      Unexpected error: (ipc/send) invalid destination port.
-    <youpi> during the experimental ocaml build
-    <braunr> well yes
-    <braunr> thread recycling is buggy
-    <braunr> i had the choice to fix it, or implement true destruction
-    <braunr> i'm tweaking my patch so it leaves the main thread stack untouched
-      on destruction
-    <braunr> and it should be ready
-    <braunr> for review at least
-
-
-## IRC, OFTC, #debian-hurd, 2013-11-13
-
-    <gg0> ironforge out of memory during ruby1.9.1 rebuild. during test which
-      creates 10000 threads
-    <gg0> ironforge out of memory during ruby1.9.1 rebuild, test which creates
-      10000 threads
-    <gg0> i guess ironforge kernel has been rebuilt against -95, correct?
-    <youpi> err, what kernel?
-    <gg0> 23:37 < youpi> hurd needs a rebuild to be able to work with the newer
-      eglibc
-    <gg0> i mean hurd
-    <youpi> yes, libc0.3 breaks the old packages anyway
-    <gg0> wrt ENOMEM, was it expected?
-    <gg0> wrt disk problems, aren't there on alioth only?
-    <youpi> well 10,000 threads is a lot, especially on 32bit machine with 2M
-      default stack  size
-    <youpi> that makes 2GiB stacks
-    <youpi> can't fit in a 2/2 split model, which gnumach uses
-    <gg0> well, though active thread should die right away, just after set x to
-      false, if i read it correctly
-    <youpi> perhaps the stacks are not correctly reused
-    <youpi> that's probably worth digging in libpthread
-    <youpi> by putting printfs, etc.
-    <youpi> it seems stacks are never reused indeed, damn
-    <youpi> I just wrote a small test that creates threads which just print
-      their stack address
-    <youpi> that takes just a few minutes to do
-    <gg0> i see. about reusage i guess you mean base address is kindof always
-      incremented
-    * gg0 likes being wrong
-    <youpi> that's it, yes
-    <youpi> gg0: take care, by keeping being wrong all the time, sometimes you
-      get right ;)
-    <youpi> and you are definitely right here :)
-    <youpi> Mmm, but the stack is really deallocated
-    <youpi> and the numbers wrap around
-    <youpi> I wonder how that is :)
-    <youpi> ok, creating 20 000 threads does work
-    <youpi> perhaps ruby does odd things which makes it not work
-
-
-### IRC, OFTC, #debian-hurd, 2013-11-14
-
-    <gg0>  UID   PID  PPID TH  MSGI  MSGO    SZ   RSS SC STAT     TIME COMMAND
-    <gg0> 1012 16446 15473 720  987   509 1.89G 23.6M  1 Hu    0:00.15
-      /home/gg0-guest/ruby/ruby1.9.git/ruby1.9.1
-      -I/home/gg0-guest/ruby/ruby1.9.git/lib -W0 bootstraptest.tmp.rb
-    <gg0> 720 threads, stuck
-    <youpi> 2G SZ is very big :)
-    <gg0> 00:42 < youpi> perhaps ruby does odd things which makes it not work
-    <gg0> is that enough to file a ruby bug? as ruby suggests itself btw
-    <youpi> no, they will probably not be able to investigate
-    <youpi> but you can already check out how they create threads
-    <youpi> and try to reproduce the same with a small C program
-    <gg0> ehm on ruby2.0 with *context _enabled_ i can not reproduce it
-
-See [[/open_issues/glibc]] for `*context` functions.
-
-
-## IRC, freenode, #hurd, 2013-11-14
-
-    <braunr> nice, i got glibc packages with thread destruction
-    <braunr> building hurd packages against it now
-    <braunr> everything seems fine
-    <braunr> hurd packages ready, let's see
-
-    <gg0> ruby1.9.1 FTBFS due to a couple of tests
-      https://buildd.debian.org/status/fetch.php?pkg=ruby1.9.1&arch=hurd-i386&ver=1.9.3.448-1&stamp=1384265526
-    <gg0> second one creates 10000 threads and machine got ENOMEM
-    <braunr> bootstraptest.tmp.rb: [BUG] [BUG] pthread_cond_init: Cannot
-      allocate memory (ENOMEM) ew
-    <gg0> few hours ago trying to reproduce it:
-    <gg0> 01:20 < gg0>  UID   PID  PPID TH  MSGI  MSGO    SZ   RSS SC STAT
-      TIME COMMAND
-    <gg0> 01:20 < gg0> 1012 16446 15473 720  987   509 1.89G 23.6M  1 Hu
-      0:00.15 /home/gg0-guest/ruby/ruby1.9.git/ruby1.9.1
-      -I/home/gg0-guest/ruby/ruby1.9.git/lib -W0 bootstraptest.tmp.rb
-    <braunr> yes that's expected
-    <braunr> our stacks are 2M
-    <braunr> 10k threads means right over 2G of stacks
-    <braunr> userspace is restricted to 2G
-    <gg0> but if i read correctly test in question, thread should just set x to
-      false then die
-    <braunr> so ?
-    <gg0> and ENOMEM popped upk when there were thread count was at 720
-    <braunr> hum
-    <braunr> 10k threads would actually be 20G
-    <braunr> 1k threads is 2G
-    <braunr> 720 is about 1.5G
-    <braunr> the rest is probably the ruby runtime
-    <gg0> youpi tried to create 10000 thread, no problem. he guessed something
-      wrong on ruby side
-    <gg0> indeed on ruby2.0 such test succeeds
-    <braunr> you can't create 10k threads unless you change the stack size
-    <braunr> hurd servers use a stack size of 64k by default which allows them
-      to go up to 30k iirc
-    <braunr> but normal applications use the default 2M
-    <gg0> i guess you mean 10000 threads active at the same time. test in
-      question should make them die after simply setting x to false, i guess
-      youpi's test did so as well
-    <braunr> no
-    <braunr> it's about stacks
-    <braunr> hm
-    <braunr> yes at the same time but
-    <braunr> thread recycling is known to be buggy
-    <braunr> which is what i'm currently fixing btw
-    <neal> what's the bug?
-    <braunr> neal: there are several subtle issues
-    <braunr> for example, joining a thread that is also calling pthread_exit
-      can fail badly
-    <neal> hmm
-    <neal> good that you are on it then :)
-    <braunr> or detaching
-    <braunr> i don't remember the details
-    <braunr> but i remember such problems
-    <braunr> apparently, keeping the stack of the main thread isn't enough
-    <braunr> :(
-    <braunr> for now, i'll keep the entire thread
-
-
-## IRC, freenode, #hurd, 2013-11-15
-
-    <gg0> i wasn't doing anything, just some single test runs. but yes, also
-      that one which creates hundreds of threads
-    <gg0> it would like creating 10000 but goes out of memory after ~720
-    <gg0> btw same tests succeed on ruby2.0, so they should be fixed by
-      backporting some changes
-    <braunr> actually it looks more like a deadlock ..
-    <gg0> deadlock that says ENOMEM?
-    <braunr> ?
-    <braunr> ENOMEM is returned because the test task has no more virtual
-      memory
-    <braunr> this doesn't mean the rest of the system should fail
-    <gg0> ok i thought you were talking about such test
-    <braunr> no it's something else
-    <braunr> a deadlock in a critical server
-    <braunr> the root file system maybe
-    <gg0> braunr: htop and ps hang. just run the test once again
-    <gg0> now you should still be able to login
-    <braunr> htop/ps hanging means one process is unable to reply to queries
-      sent to the message port/thread
-    <braunr> procfs does that to report on what a process is waiting
-    <braunr> it usually mean there is a bug around signals, since the message
-      thread is also in charge of delivering signals
-    <braunr> use ps -eM
-    <braunr> and kill -KILL
-    <braunr> hum
-    <braunr> root       954 S<o   0:00.05 /hurd/crash --dump-core
-    <braunr> dumping cores is known not to work most of the time
-    <braunr> exodar shouldn't be configured like that
-    <braunr> so yes, the crash server is hanging
-    <braunr> gg0: i've set it to crash --kill and killed the hanging crash
-      instances blocking top/ps
-    <gg0> nice
-
-    <braunr> my thread destruction patch and tls are indeed conflicting a bit
-    <braunr> i suspect the tcb is used after being freed
-    <braunr> i think i'll simply recycle the tcb, along with the pthread
-      structs
-    <braunr> ok i think it's fine now
-    <braunr> there was also a small bug in the tls code, keeping a reference on
-      the thread port
-    <braunr> mach reference counting is so counter intuitive :/
-    <braunr> well, error-prone
-
-    <braunr> argh, more bugs in libc :(
-    <teythoon> :/
-    <teythoon> but don't worry, there is always one more bug ;)
-    <braunr> this one might explain crashes that are long to trigger
-    <braunr> _hurd_self_sigstate() is implemented like this :
-      _hurd_thread_sigstate (__mach_thread_self ());
-    <braunr> it leaks a reference on the current thread each time it's called
-    <teythoon> >,<
-    <braunr> but glibc maintains such references, so if the maximum value is
-      reached, and references are dropped, the value can reach 0
-    <teythoon> ouch
-    <braunr> at which point any call on a thread will result in an invalid send
-      right
-    <braunr> and probably an assertion
-    <teythoon> well it's a good thing then that you found it :)
-    <braunr> i think it's always been there
-    <braunr> but it's more apparent since jknoenig's patch on signal
-      dispositions
-    <braunr> the maximum number of user references in mach is 64k
-    <braunr> this right leak isn't easy
-    <braunr> tls is very tricky heh :)
-    <braunr> for the main thread, tls initialization happens after the thread
-      creation, obviously
-    <braunr> but for other threads, it's initialized before starting them
-    <braunr> the leak was probably an overlook caused by that complexity
-    <braunr> teythoon: actually that leak i mentioned in _hurd_self_sigstate
-      has only been recently added in Convert sigstate to TLS
-    <braunr> so it's merely tls integration polishing
-    <braunr> youpi: i'm currently reviewing changes related to tls and i think
-      there is a bug in _hurd_self_sigstate
-    <braunr> calls to mach_thread_self() should be paired with
-      mach_port_deallocate to avoid urefs overflows
-    <braunr> and right leaks
-    <braunr> _hurd_critical_section_lock is probably affected too
-    <braunr> hm
-    <braunr> mhmm
-    <braunr> in glibc, hurd/hurd/signal.h, _hurd_critical_section_lock
-    <braunr> why is the sigstate unlocked after the call to
-      _hurd_thread_sigstate
-    <braunr> _hurd_thread_sigstate doesn't seem to lock it ..
-    <braunr> unless __spin_lock_init does it
-    <braunr> yes, leak solved :)
-
-
-## IRC, freenode, #hurd, 2013-11-16
-
-    <braunr> argh, _hurd_critical_section_lock is called before the send right
-      on the main thread is fetched in libpthread :/
-    <teythoon> is that bad ?
-    <braunr> the sigstate is supposed to be initialized after pthreads
-    <braunr> _hurd_critical_section_lock will create it if it sees there is
-      none
-    <braunr> creating the sigstate is currently what makes the send right leak
-    <teythoon> ok
-    <teythoon> it's bad then
-    <braunr> it may be due to my patch
-    <braunr> _hurd_critical_section_lock is called during pthreads
-      initializatio
-    <braunr> n
-    <braunr> before the sigstate for the main thread is created, but after the
-      pthread init routine is called
-    <braunr> it does indeed look like the code wasn't written with thread being
-      destroyed some day in mind :/
-    <teythoon> braunr: btw, if you ever feel like benchmarking, sysbench has a
-      benchmark for threads contending for a lock
-    <braunr> yes i've used it before
-    <teythoon> was it useful for this purpose ?
-    <braunr> no :)
-    <teythoon> :/
-    <braunr> we already know libpthread isn't optimized
-    <braunr> and felt it when we switched from cthreads
-    <braunr> humpf
-    <braunr> simply calling malloc implies a call to
-      _hurd_critical_section_lock
-    <braunr> on the other hand, unlike what some glibc comments say, this does
-      work
-
-
-## IRC, freenode, #hurd, 2013-11-17
-
-    <braunr> looks like i've fixed all leak issues with thread destruction and
-      tls :)
-    <braunr> let's see if ext2fs.static works fine too
-    <youpi> braunr: \o/
-    <youpi> sorry about introducing the tls ones :)
-    <braunr> no worries, it was expected
-    <braunr> and tls was really needed :)
-    <braunr> i mean, i expected to have some problems when rebasing on tls :p
-    <teythoon> braunr: this is good news, how is your rootfs translator holding
-      up?
-    <braunr> building hurd packages right now
-    <braunr> for now, only test applications and a few really multithreaded
-      ones (e.g. iceweasel) have been tested
-    <braunr> well, the system boots :)
-    <teythoon> awesome :)
-    <braunr> stressing the file system with git while watching youtube videos
-      with gnash doesn't make the system crash
-    <teythoon> you can actually watch yt videos on your Hurd box ?
-    <braunr> yes
-    <braunr> for a while now
-    <teythoon> o_O
-    <braunr> can't you ?
-    <teythoon> I never even dared to try
-    <braunr> hehe
-    <braunr> teythoon: looks stable enough to install on darnassus
-
-
-## IRC, freenode, #hurd, 2013-11-18
-
-    <teythoon> braunr: wrt to your thread destruction patchset, I thought you
-      also had to fix the proc server ?
-    <braunr> teythoon: no
-    <braunr> the problem was in glibc
-    <braunr> i may have to fix proc/procfs though, because cpu time gets wrong
-      with the patch
-    <braunr> currently, it's the addition of the cpu time of all threads
-    <braunr> mach provides aggregate times including destroyed threads though
-    <teythoon> ah, I see
-    <braunr> one side effect is that you'll see processes sometimes taking 100%
-      of cpu time although the cpu is unused
-    <braunr> or the cpu time of a process gets reduced :)
-    <braunr> i guess the 100% cpu is how top sees a negative increment
-    <teythoon> ^^
-    <braunr> gg0: do my threadterm packages help with ruby1.9 ?
-    <braunr> i mean, can you test with them some time ? :)
-
-
-## IRC, freenode, #hurd, 2013-11-21
-
-    <braunr> youpi: ping about my question regarding error handling in the
-      proposed thread_terminate_release call
-    <youpi> I agree with what Neal said
-    <braunr> he didn't say anything about error handling
-    <braunr> see
-      http://lists.gnu.org/archive/html/bug-hurd/2013-11/msg00181.html
-    <braunr> i think i should make the call fail on first error
-    <braunr> it shouldn't happen, so it would merely serve to catch bugs
-    <braunr> it's not easily recoverable (if it's recoverable at all)
-    <youpi> uh, I thought he had
-    <youpi> I must have dreamt
-
-    <braunr> i think i'll go ahead with thread destruction integration
-
-
-## IRC, freenode, #hurd, 2013-11-25
-
-    <braunr> i've pushed the thread destruction patches for gnumach upstream
-    <braunr> and made a branch in glibc for that too
-    <teythoon> awesome :)
-    <braunr> youpi: i don't remember how glibc changes should be managed
-    <braunr> once those are applied, i'll commit in libpthread
-    <youpi> braunr: usually we create a topgit branch, and then we add the
-      patch from that to the debian repository
-
-
-## IRC, freenode, #hurd, 2013-11-29
-
-    <braunr> youpi: i still have a leak somewhere with the thread destruction
-      patches
-    <braunr> maybe on the host priv port in bootstrap servers (root fs and proc
-      server)
-    <braunr> it prevents priority adjusting in libports and can easily bring
-      down a system because servers can start trashing a lot sooner, as it was
-      the case during the pthread migration
-
-See discussion about that on [[/open_issues/libpthread]].
-
-    <braunr> so i'll hunt it down before merging
-
-
-## IRC, freenode, #hurd, 2013-12-19
-
-    <braunr> darnassus still has the libports priority adjustement leaks
-    <braunr> i'll apply a few more patches to my hurd packages
-
-    <braunr> humpf, proc seems to have a problem getting the host priv port :/
-    <teythoon> thats bad
-    <teythoon> what did you do ?
-    <braunr> i fixed all the leaks in libports when adjusting priorities
-    <braunr> the last one being releasing the host priv right
-    <braunr> and i get errors at boot time from the proc server
-    <teythoon> remember when i had this problem ?
-    <braunr> proc doesn't get the host priv port the normal way since the
-      normal way is to get it from proc iirc
-    <teythoon> ah, thought you fixed that
-    <braunr> so i guess the alternate way doesn't add a reference
-    <braunr> well the leak is fixed
-    <braunr> the problem you had was due to the leak which made the host priv
-      port reach its max uref value
-    <braunr> now it's just the proc server
-    <braunr> the system works fine though
-    <teythoon> for real ?
-    <teythoon> the proc server needs the host priv port for getting the new
-      tasks
-    <braunr> well yes
-    <teythoon> how can it work w/o it ?
-    <braunr> i don't know ..
-    <braunr> i guess the problem is internal to glibc
-    <braunr> i mean, get_priv_ports fails, but that doesn't mean the host priv
-      port is lost
-    <teythoon> could be
-    <teythoon> are you running a patched rootfs translator too ?
-    <braunr> yes
-    <teythoon> ok
-    <teythoon> b/c i remember having trouble with that
-    <braunr> right, the glibc call would make proc call __proc_getprivports
-    <braunr> hum
-    <braunr> teythoon: do you remember how proc gets its host priv port ?
-    <teythoon> from init
-    <teythoon> i think
-    <braunr> startup_procinit ?
-    <teythoon> possibly
-    <braunr> right
-    <braunr> so it's probably not the host priv port
-    <braunr> i mean, the error is about another invalid send right
-    <braunr> hm nope, it is on host_priv :/
-    <braunr> hm ok i see, looks like a bug from a debian patch
-    <braunr> or rather, a bug fix not yet imported into the debian package
-    <braunr> teythoon: you actually fixed it in
-      2c9422595f41635e2f4f7ef1afb7eece9001feae
-    <braunr> great :)
-    <teythoon> ah, that one
-    <braunr> i was looking at the upstream code and couldn't understand what
-      was going wrong
-    <braunr> :)
-    <braunr> much better
-    <braunr> except ps -eT doesn't work any more ..
-    <braunr> interestingly, with the thread destruction patch, ps -eT sometimes
-      work, and sometimes doesn't
-    <braunr> the behaviour doesn't seem to change without a reboot
-    <braunr> and of course, as soon as i say it, i'm proven wrong by the next
-      test :)
-
-
-## IRC, freenode, #hurd, 2013-12-26
-
-    <braunr> __pthread_sigstate_init doesn't seem to be converted to TLS in the
-      upstream repository master branch
-
-    <braunr> ah dammit, the global signal dispositions patch touches both glibc
-      and libpthread @#!
-    <braunr> what a mess
-
-    <braunr> youpi: do you have some time to quickly review the
-      rbraun/thread_destruction branch in libpthread ?
-    <braunr> there might be conflict with some glibc patches
-    <braunr> or do you prefer it on the mailing list ?
-    <braunr> (i used a branch because it's not based on master)
-    <youpi> rather mail the list, yes
-    <braunr> ok
-    <youpi> it'd also be useful to write the rationale
-    <youpi> probably to be left as comment in the source code
-    <braunr> yes, that branch was for personal storage :)
-    <youpi> so the reader knows how things are recycled or not
-    <braunr> hm
-    <braunr> that should already be the case
-    <youpi> ok
-    <braunr> the two structures that are still recycled are the pthread struct
-      and tls
-    <braunr> it's quite obvious from pthread_alloc
-    <braunr> and well commented there
-    <braunr> for tls, it's explained in pthread_exit
-
-    <braunr> there, thread destruction finally merged in
-    <braunr> and now, we can remove the ugly hacks that were done for
-      threadvars
-    <braunr> :)
-    <braunr> change stacks at will and support all sorts of weird languages and
-      runtimes
-    <teythoon> braunr: cool :)
-
-
-## IRC, freenode, #hurd, 2013-12-31
-
-    <youpi1> braunr: I've added sigstate_locking, sigstate_thread_reference and
-      tls_thread_leak to the debian glibc 2.18 package
-    <youpi1> I believe that's complete?
-    <youpi1> is mach_msg_uspace_options ready for being added? Does it bring
-      much speedup?
-    <youpi1> AIUI, thread_terminate_release is  the union of the branches
-      mentioned above?
-    <youpi1> (I'm cleaning up branches in the glibc repo)
-    <braunr> youpi1: mach_msg_uspace_options can be left over, it only affects
-      selects and not noticeably
-    <braunr> yes, those three branches are the only ones needed for thread
-      destruction
-    <youpi1> ok
-    <youpi> does the hurd changes depend on these changes ?
-    <braunr> no
-    <youpi> good :)
-    <braunr> only on tls for one of them
-    <braunr> (it's about the default stack size of 64k for hurd servers)
-    <youpi> and we have had this in debian for a long time already :)
-    <braunr> yes
-    <youpi> (how big were they before?)
-    <youpi> (where they a couple MiB, and thus exploding to GiBs on thousands
-      of threads?)
-    <braunr> 64k
-    <braunr> pthread stacks are 2M by default
-    <braunr> yes
-
-
-## IRC, freenode, #hurd, 2014-01-14
-
-    <youpi> braunr: it seems your time change in libps made ps produce odd re
-    <youpi> results
-    <youpi>     samy 10987     5 -514358:-18:-42.17 /hurd/firmlink tmp
-    <braunr> youpi: wow :)
-    <braunr> that change is supposed to run on a system where threads actually
-      get destroyed
-    <braunr> but i don't see what could trigger this side effect
-    <youpi>     root  8629   664 56 years make -j 3
-    <youpi> :)
-    <braunr> heh
-    <braunr> youpi: does the hurd package on darnassus include that patch ?
-    <youpi> yes
-    <braunr> i don't reproduce the problem :/
-    <youpi> err
-    <braunr> what command are you using ?
-    <youpi> ps -feM on darnassus
-    <youpi>     root 29642   473 7 months /usr/sbin/sshd -R
-    <braunr> hmmmm
-    <braunr> i don't see it with a make -j
-    <youpi> well, it's not systematic
-    <youpi> it's like once over two launches
-    <braunr> hhhhmmmmm
-    <youpi> it'd look like some random numbers get added
-    <braunr> strangely, the gcc processes started by a recursive make aren't
-      children of make ..
-    <braunr> ps -eF hurd seems to report the correct values
-    <braunr> even ps -eM
-    <braunr> oO
-    <braunr> ps -ef too
-    <braunr> the problem seems to be with ps -efM
-    <youpi> too bad I'm always using that :)
-    <braunr> another way to see it is that it makes us spot the issue ;p
-
-
-### IRC, freenode, #hurd, 2014-01-15
-
-    <braunr> ok i have an idea of what goes wrong in libps
-
-    <braunr> youpi: for some reason, ps -efM lacks the PSTAT_TASK_BASIC flag
-    <braunr> my patch is wrong since it doesn't try to determine whether the
-      stats apply to a task or a thread, but that is easy to fix
-    <braunr> ps -efM should nonetheless provide basic task info, obviously
-    <braunr> in addition, the problems i've observed with ps -T (occasional
-      segfaults) seem to have existed before thread destruction
-    <braunr> they're just strongly exposed now that the thread list can be
-      shrunk
-
-    <braunr> libps is quite complicated
-    <braunr> even hairy, i'd say ..
-
-
-### IRC, freenode, #hurd, 2014-01-16
-
-    <braunr> youpi: i think i have a proper fix for libps
-    <braunr> i'll commit it soon
-    <youpi> ok
-    <braunr> basically, getting system times simply set the PSTAT_THREAD_BASIC
-      flag
-    <braunr> whereas getting the run time of the terminated threads requires
-      PSTAT_TASK_BASIC
-    <braunr> i assumed it was always set in the function i changed when dealing
-      with a task and not a thread
-    <braunr> and well, that was a wrong assumtion, -M can remove it if not
-      strictly needed by the format
-    <braunr> the default format asks for suspend_count, which forces the
-      retrieval of task basic info, os it works with -eM
-    <braunr> but -f doesn't :)
-    <youpi> so extremely bad lucky combination of flags :)
-    <braunr> indeed
-    <braunr> i added a pstat_times using the last (!) available flag bit
-    <braunr> looks clean to me
-    <braunr> i hope there is no abi issue
-    <braunr> (at least everything works with the unmodified ps-hurd executable
-      and a new libps.so)
-
-    <braunr> hm, small bug in the thread destruction patch :/
-
-
-### IRC, freenode, #hurd, 2014-01-17
-
-    <braunr> good, i have proper fixes for tls in the main thread and thread
-      termination :)
-    <teythoon> awesome :)
-    <teythoon> i've been wondering, what does it take to get the thread
-      destruction stuff into the debian package ?
-    <braunr> i still have to build test packages, look for (unlikely, heh)
-      regressions and work some integration details with samuel
-    <braunr> hum the main thread tls fixup i guess
-    <braunr> youpi was waiting for me to fix that
-    <braunr> gnumach already provides the RPC
-    <braunr> so it will be in glibc soon
-    <braunr> i just have to get those last bits right
-    <braunr> teythoon: i'm quite slow at integrating stuff
-    <teythoon> and samuel then builds packages ?
-    <teythoon> i mean, is our libc package build linked to the other libc
-      packages ?
-    <braunr> libpthread is applied as a patch to glibc
-    <braunr> and loaded as a plugin
-
-
-## IRC, freenode, #hurd, 2014-01-17
-
-    <braunr> uhm, did we break fakeroot-tcp ?
-    <teythoon> we did ?
-    <youpi> fakeroot-tcp just works fine on buildds
-    <braunr> with fakeroot-tcp, i get
-    <braunr> make[4]: Entering directory
-      `/home/rbraun/devel/debian/packages/hurd/hurd-0.5.git20140113/libdde-linux26/contrib/include'
-    <braunr> rm -f .general.d
-    <braunr> make[4]: *** [cleanall] Killed
-    <braunr> when cleaning the package before building ..
-
-
-### IRC, freenode, #hurd, 2014-01-18
-
-    <braunr> damn, fakeroot-tcp won't work on darnassus ..
-    <braunr> uh, looks like my tls/thread destruction "fixes" do cause
-      regressions :(
-    <braunr> fakeroot works fine with debian glibc
-    <teythoon> which one ?
-    <teythoon> which fakeroot i mean
-    <braunr> -tcp
-    <braunr> yes, it fails as soon as i use the patched glibc :/
-    <braunr> at least it's easy to reproduce
-
-
-### IRC, freenode, #hurd, 2014-01-20
-
-    <braunr> great, 3rd libc version installed on darnassus, let's see if i can
-      build hurd packages against that
-
-
-### IRC, freenode, #hurd, 2014-01-21
-
-    <braunr> damn, fakeroot-tcp still crashes with my latest changes ....
-
-    <braunr> darnassus looks in good shape
-    <braunr> youpi: ^
-    <braunr> youpi: if you have other tests, feel free to do them now
-    <braunr> i feel confident about committing the changes, if you're ok with
-      it
-    <youpi> which changes ?
-    <youpi> I'm a bit lost in what you were talking about :)
-    <braunr> you can find them in 2 patches in /var/tmp on darnassus
-    <braunr> one is about fixing thread destruction
-    <braunr> i'm pretty certain about this one so i'll commit it directly
-    <braunr> the other is fixing the tcb of the main thread
-
-[[open_issues/libpthread]].
-
-    <braunr> where i simply do tcb->self = thread->kernel_thread :)
-    <braunr> with a comment explaining why i don't do something else like
-      deallocating the unused tcb
-    <youpi> braunr: ok, that looks good
-    <teythoon> braunr: awesome :)
-    <braunr> youpi: ok
-
-
-### IRC, freenode, #hurd, 2014-01-22
-
-    <braunr> there, libpthread should be fine now
-
-
-## IRC, freenode, #hurd, 2014-02-06
-
-    <braunr> youpi: in case you're planning to upgrade glibc (or not), the
-      thread destruction changes are complete
-    <braunr> youpi: darnassus has been running them for some weeks with no
-      visible regression
-    <youpi> braunr: ok, good
-    <youpi> including it in glibc was on my todo list indeed
-    <youpi> and Adam  indeed plan for a 2.18 upload
-    <braunr> good :)
-    <youpi> braunr: this is up to 7c6dc6e28b2fc4b67934223f41cf080ffe58b230,
-      right? (Wed Jan 22, Fix up the main thread TCB)
-    <braunr> yes
-    <braunr> oh, i just saw 2.17-98~0 glibc packages on debian-ports :)
-    <youpi> yes, it's just to fix the dhcp crash
-    <braunr> ah yes, it's not 2.18
-    <youpi> 2.18 is available in experimental
-
-    <youpi> braunr: just to make sure: did you have
-      983b18a6ff16f5687a9ece63a50d1831dec88609 in libc on darnassus?
-    <youpi> (which drops the stack size  hack)
-    <braunr> youpi: let me check
-    <braunr> youpi: ah no, i don't, you're right
-    <youpi> well, I was just wondering, nothing make me think that was the case
-      :)
-    <youpi> what was the issue that it was raising btw?
-    <braunr> threadvards
-    <youpi> ok, b ut in which case?
-    <youpi> (to make sure I test that before committing)
-    <braunr> now that we switched to tls, i would assume the transition path to
-      be 1/ hurd stops defining that symbol, 2/ libpthread can stop using it
-    <braunr> the goal was to reduce the stack size of hurd server threads
-    <youpi> well, that's not my question :) I'm wondering in which precise case
-      that was breaking things
-    <braunr> youpi: i don't know, it shouldn't break
-    <youpi> ok
-    <braunr> youpi: just in case, don't forget that last one line patch i
-      committed last night, fakeroot can't work right without it
-    <braunr> (i made a minor change while reviewing before comitting, and
-      obviously got it wrong :p)
-    <youpi> ok
-
-    <youpi> braunr: I've upgraded libpthread in debian's eglibc btw
-
-    <braunr>
-      /home/rbraun/devel/debian/packages/eglibc/eglibc-2.17/build-tree/hurd-i386-libc/libc.so.phdr:
-      *** executable stack signaled
-    <braunr> from build-tree/hurd-i386-libc/elf/check-execstack.out
-    <braunr> i thought glibc didn't use those
-    <braunr> anyway it doesn't look to be the regression i'm having
-    <braunr> does this ring a bell :
-    <braunr> Encountered regressions that don't match expected failures
-      (debian/testsuite-checking/expected-results-i486-gnu-libc):
-    <braunr> test-stpcpy_chk.out, Error 1
-    <braunr> TEST test-stpcpy_chk.out: __stpcpy_chk    normal_stpcpy
-      simple_stpcpy_chk
-    <youpi> nope
-    <youpi> after what are you getting this regression?
-    <braunr> building glibc 2.17-97 with thread destruction patches, including
-      the one removing the stack size hack
-    <braunr> during tests
-    <braunr> there also are "progressions", but i'm not sure what these are
-    <youpi> some progressions are just luck, other seem to happen on some
-      platforms only
-    <youpi> I'm not sure you want to test 2.17
-    <youpi> a lot has changed between 2.17's libpthread and 2.18's libpthread
-      (which is now equal to cvs's libpthread
-    <youpi> )
-    <youpi> s/cvs/git/
-    <braunr> yes
-    <braunr> i usually build with nocheck
-
-
-## IRC, freenode, #hurd, 2014-02-07
-
-    <braunr> youpi: on a vm with hurd 1:0.5.git20140203-1, upgrading to a
-      patched glibc 2.17-97 that includes the patch which reverts the stack
-      size hack, the system reboots and works fine
-    <youpi> ok. I don't remember what problem I was seeing
-    <braunr> that version of the hurd no longer defines the symbol
-    <braunr> but even then, there shouldn't have been any problem
-    <braunr> hm, or does it
-    <braunr> yes, it does
-    <braunr> youpi: the hurd package patch mentions
-    <braunr> Revert this for now, will have to wait for dropping the use of
-    <braunr> __pthread_stack_default_size from eglibc's
-      libpthread_hurd_cond_wait.diff
-    <braunr> i wonder how it got there
-    <youpi> IIRC I was wondering too
-    <braunr> i've installed my c library on darnassus and it works fine there
-      too
-    <braunr> with older (january) hurd packages
-    <braunr> looks good to me
-
-
-## IRC, freenode, #hurd, 2014-02-10
-
-    <teythoon> braunr: btw, do the new libc packages contain your thread
-      destruction work ?
-    <braunr> teythoon: the -98 ones on experimental ?
-    <braunr> i don't think they do
-    <braunr> the -18 ones should do
diff --git a/open_issues/libpthread_1fcd93fd3c733eb19bcad8d03e65f13ec4b0e998..master-viengoos-on-bare-metal.mdwn b/open_issues/libpthread_1fcd93fd3c733eb19bcad8d03e65f13ec4b0e998..master-viengoos-on-bare-metal.mdwn
deleted file mode 100644
index 4396cf59..00000000
--- a/open_issues/libpthread_1fcd93fd3c733eb19bcad8d03e65f13ec4b0e998..master-viengoos-on-bare-metal.mdwn
+++ /dev/null
@@ -1,849 +0,0 @@
-[[!meta copyright="Copyright � 2012 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_libpthread]]
-
-Things found in a `git diff
-1fcd93fd3c733eb19bcad8d03e65f13ec4b0e998..master-viengoos-on-bare-metal` that
-are not specific to L4 or Viengoos, and may be worth having on master, too.
-
-
-# `__pthread_alloc` init with `malloc` or `calloc`
-
-    diff --git a/pthread/pt-alloc.c b/pthread/pt-alloc.c
-    index 6af2da9..c63801f 100644
-    --- a/pthread/pt-alloc.c
-    +++ b/pthread/pt-alloc.c
-    @@ -123,7 +123,7 @@ __pthread_alloc (struct __pthread **pthread)
-         }
-     
-       /* Allocate a new thread structure.  */
-    -  new = malloc (sizeof (struct __pthread));
-    +  new = calloc (sizeof (struct __pthread), 1);
-       if (new == NULL)
-         return ENOMEM;
-     
-
-
-# `atomic.h`
-
-Later on master, commit 608a12659f15d57abf42a972c1e56c6a24cfe244: `Rename
-bits/atomic.h to bits/pt-atomic.h`.
-
-    diff --git a/pthread/pt-create.c b/pthread/pt-create.c
-    index 8f62b78..504cacc 100644
-    --- a/pthread/pt-create.c
-    +++ b/pthread/pt-create.c
-    @@ -22,7 +22,7 @@
-     #include <pthread.h>
-     #include <signal.h>
-     
-    -#include <bits/atomic.h>
-    +#include <atomic.h>
-     
-     #include <pt-internal.h>
-     
-    @@ -33,7 +33,7 @@
-     /* The total number of pthreads currently active.  This is defined
-        here since it would be really stupid to have a threads-using
-        program that doesn't call `pthread_create'.  */
-    -__atomic_t __pthread_total;
-    +atomic_fast32_t __pthread_total;
-     
-     
-     /* The entry-point for new threads.  */
-    @@ -163,7 +163,7 @@ __pthread_create_internal (struct __pthread **thread,
-          the number of threads from within the new thread isn't an option
-          since this thread might return and call `pthread_exit' before the
-          new thread runs.  */
-    -  __atomic_inc (&__pthread_total);
-    +  atomic_increment (&__pthread_total);
-     
-       /* Store a pointer to this thread in the thread ID lookup table.  We
-          could use __thread_setid, however, we only lock for reading as no
-    @@ -190,7 +190,7 @@ __pthread_create_internal (struct __pthread **thread,
-     
-      failed_starting:
-       __pthread_setid (pthread->thread, NULL);
-    -  __atomic_dec (&__pthread_total);
-    +  atomic_decrement (&__pthread_total);
-      failed_sigstate:
-       __pthread_sigstate_destroy (pthread);
-      failed_setup:
-    diff --git a/pthread/pt-exit.c b/pthread/pt-exit.c
-    index 5fe0ba8..68c56d7 100644
-    --- a/pthread/pt-exit.c
-    +++ b/pthread/pt-exit.c
-    @@ -24,7 +24,7 @@
-     
-     #include <pt-internal.h>
-     
-    -#include <bits/atomic.h>
-    +#include <atomic.h>
-     
-     
-     /* Terminate the current thread and make STATUS available to any
-    @@ -57,7 +57,7 @@ pthread_exit (void *status)
-     
-       /* Decrease the number of threads.  We use an atomic operation to
-          make sure that only the last thread calls `exit'.  */
-    -  if (__atomic_dec_and_test (&__pthread_total))
-    +  if (atomic_decrement_and_test (&__pthread_total))
-         /* We are the last thread.  */
-         exit (0);
-     
-    diff --git a/pthread/pt-internal.h b/pthread/pt-internal.h
-    index cb441d0..986ec6b 100644
-    --- a/pthread/pt-internal.h
-    +++ b/pthread/pt-internal.h
-    @@ -26,13 +26,15 @@
-     #include <signal.h>
-     #include <assert.h>
-     
-    -#include <bits/atomic.h>
-    +#include <atomic.h>
-    [...]
-    @@ -136,7 +144,7 @@ __pthread_dequeue (struct __pthread *thread)
-            )
-     
-     /* The total number of threads currently active.  */
-    -extern __atomic_t __pthread_total;
-    +extern atomic_fast32_t __pthread_total;
-     
-     /* The total number of thread IDs currently in use, or on the list of
-        available thread IDs.  */
-    diff --git a/sysdeps/ia32/bits/atomic.h b/sysdeps/ia32/bits/atomic.h
-    deleted file mode 100644
-    index 0dfc1f6..0000000
-    --- a/sysdeps/ia32/bits/atomic.h
-    +++ /dev/null
-    @@ -1,66 +0,0 @@
-    -/* Atomic operations.  i386 version.
-    -   Copyright (C) 2000 Free Software Foundation, Inc.
-    -   This file is part of the GNU C Library.
-    -
-    -   The GNU C Library is free software; you can redistribute it and/or
-    -   modify it under the terms of the GNU Library General Public License as
-    -   published by the Free Software Foundation; either version 2 of the
-    -   License, or (at your option) any later version.
-    -
-    -   The GNU C Library is distributed in the hope that it will be useful,
-    -   but WITHOUT ANY WARRANTY; without even the implied warranty of
-    -   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-    -   Library General Public License for more details.
-    -
-    -   You should have received a copy of the GNU Library General Public
-    -   License along with the GNU C Library; see the file COPYING.LIB.  If not,
-    -   write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
-    -   Boston, MA 02111-1307, USA.  */
-    -
-    -#ifndef _BITS_ATOMIC_H
-    -#define _BITS_ATOMIC_H	1
-    -
-    -typedef __volatile int __atomic_t;
-    -
-    -static inline void
-    -__atomic_inc (__atomic_t *__var)
-    -{
-    -  __asm__ __volatile ("lock; incl %0" : "=m" (*__var) : "m" (*__var));
-    -}
-    -
-    -static inline void
-    -__atomic_dec (__atomic_t *__var)
-    -{
-    -  __asm__ __volatile ("lock; decl %0" : "=m" (*__var) : "m" (*__var));
-    -}
-    -
-    -static inline int
-    -__atomic_dec_and_test (__atomic_t *__var)
-    -{
-    -  unsigned char __ret;
-    -
-    -  __asm__ __volatile ("lock; decl %0; sete %1"
-    -		      : "=m" (*__var), "=qm" (__ret) : "m" (*__var));
-    -  return __ret != 0;
-    -}
-    -
-    -/* We assume that an __atomicptr_t is only used for pointers to
-    -   word-aligned objects, and use the lowest bit for a simple lock.  */
-    -typedef __volatile int * __atomicptr_t;
-    -
-    -/* Actually we don't implement that yet, and assume that we run on
-    -   something that has the i486 instruction set.  */
-    -static inline int
-    -__atomicptr_compare_and_swap (__atomicptr_t *__ptr, void *__oldval,
-    -			      void * __newval)
-    -{
-    -  char __ret;
-    -  int __dummy;
-    -
-    -  __asm__ __volatile ("lock; cmpxchgl %3, %1; sete %0"
-    -		      : "=q" (__ret), "=m" (*__ptr), "=a" (__dummy)
-    -		      : "r" (__newval), "m" (*__ptr), "a" (__oldval));
-    -  return __ret;
-    -}
-    -
-    -#endif
-
-
-# Memory Barries
-
-    diff --git a/sysdeps/generic/bits/memory.h b/sysdeps/generic/bits/memory.h
-    new file mode 100644
-    index 0000000..7b88a7e
-    --- /dev/null
-    +++ b/sysdeps/generic/bits/memory.h
-    @@ -0,0 +1,36 @@
-    +/* Memory barrier operations.  Generic version.
-    +   Copyright (C) 2008 Free Software Foundation, Inc.
-    +   This file is part of the GNU Hurd.
-    +
-    +   The GNU Hurd is free software; you can redistribute it and/or
-    +   modify it under the terms of the GNU General Public License as
-    +   published by the Free Software Foundation; either version 3 of the
-    +   License, or (at your option) any later version.
-    +
-    +   The GNU Hurd is distributed in the hope that it will be useful, but
-    +   WITHOUT ANY WARRANTY; without even the implied warranty of
-    +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-    +   General Public License for more details.
-    +
-    +   You should have received a copy of the GNU General Public License
-    +   along with this program.  If not, see
-    +   <http://www.gnu.org/licenses/>.  */
-    +
-    +#ifndef _BITS_MEMORY_H
-    +#define _BITS_MEMORY_H	1
-    +
-    +/* Prevent read and write reordering across this function.  */
-    +static inline void
-    +__memory_barrier (void)
-    +{
-    +  /* Any lock'ed instruction will do.  */
-    +  __sync_synchronize ();
-    +}
-    +
-    +/* Prevent read reordering across this function.  */
-    +#define __memory_read_barrier __memory_barrier
-    +
-    +/* Prevent write reordering across this function.  */
-    +#define __memory_write_barrier __memory_barrier
-    +
-    +#endif
-
-
-# Spin Locks
-
-    diff --git a/sysdeps/generic/bits/spin-lock-inline.h b/sysdeps/generic/bits/spin-lock-inline.h
-    new file mode 100644
-    index 0000000..6c3e06e
-    --- /dev/null
-    +++ b/sysdeps/generic/bits/spin-lock-inline.h
-    @@ -0,0 +1,99 @@
-    +/* Machine-specific definitions for spin locks.  Generic version.
-    +   Copyright (C) 2000, 2005, 2008 Free Software Foundation, Inc.
-    +   This file is part of the GNU C Library.
-    +
-    +   The GNU C Library is free software; you can redistribute it and/or
-    +   modify it under the terms of the GNU Library General Public License as
-    +   published by the Free Software Foundation; either version 2 of the
-    +   License, or (at your option) any later version.
-    +
-    +   The GNU C Library is distributed in the hope that it will be useful,
-    +   but WITHOUT ANY WARRANTY; without even the implied warranty of
-    +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-    +   Library General Public License for more details.
-    +
-    +   You should have received a copy of the GNU Library General Public
-    +   License along with the GNU C Library; see the file COPYING.LIB.  If not,
-    +   write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
-    +   Boston, MA 02111-1307, USA.  */
-    +
-    +/*
-    + * Never include this file directly; use <pthread.h> or <cthreads.h> instead.
-    + */
-    +
-    +#ifndef _BITS_SPIN_LOCK_INLINE_H
-    +#define _BITS_SPIN_LOCK_INLINE_H	1
-    +
-    +#include <features.h>
-    +#include <bits/spin-lock.h>
-    +
-    +__BEGIN_DECLS
-    +
-    +#if defined __USE_EXTERN_INLINES || defined _FORCE_INLINES
-    +
-    +# if !defined (__EBUSY) || !defined (__EINVAL)
-    +#  include <errno.h>
-    +#  ifndef __EBUSY
-    +#   define __EBUSY EBUSY
-    +#  endif
-    +#  ifndef __EINVAL
-    +#   define __EINVAL EINVAL
-    +#  endif
-    +# endif
-    +
-    +# ifndef __PT_SPIN_INLINE
-    +#  define __PT_SPIN_INLINE __extern_inline
-    +# endif
-    +
-    +__PT_SPIN_INLINE int __pthread_spin_destroy (__pthread_spinlock_t *__lock);
-    +
-    +__PT_SPIN_INLINE int
-    +__pthread_spin_destroy (__pthread_spinlock_t *__lock)
-    +{
-    +  return 0;
-    +}
-    +
-    +__PT_SPIN_INLINE int __pthread_spin_init (__pthread_spinlock_t *__lock,
-    +					  int __pshared);
-    +
-    +__PT_SPIN_INLINE int
-    +__pthread_spin_init (__pthread_spinlock_t *__lock, int __pshared)
-    +{
-    +  *__lock = __SPIN_LOCK_INITIALIZER;
-    +  return 0;
-    +}
-    +
-    +__PT_SPIN_INLINE int __pthread_spin_trylock (__pthread_spinlock_t *__lock);
-    +
-    +__PT_SPIN_INLINE int
-    +__pthread_spin_trylock (__pthread_spinlock_t *__lock)
-    +{
-    +  int __locked = __sync_val_compare_and_swap (__lock, 0, 1);
-    +  return __locked ? __EBUSY : 0;
-    +}
-    +
-    +__extern_inline int __pthread_spin_lock (__pthread_spinlock_t *__lock);
-    +extern int _pthread_spin_lock (__pthread_spinlock_t *__lock);
-    +
-    +__extern_inline int
-    +__pthread_spin_lock (__pthread_spinlock_t *__lock)
-    +{
-    +  if (__pthread_spin_trylock (__lock))
-    +    return _pthread_spin_lock (__lock);
-    +  return 0;
-    +}
-    +
-    +__PT_SPIN_INLINE int __pthread_spin_unlock (__pthread_spinlock_t *__lock);
-    +
-    +__PT_SPIN_INLINE int
-    +__pthread_spin_unlock (__pthread_spinlock_t *__lock)
-    +{
-    +  int __locked = __sync_val_compare_and_swap (__lock, 1, 0);
-    +  return __locked ? 0 : __EINVAL;
-    +}
-    +
-    +#endif /* Use extern inlines or force inlines.  */
-    +
-    +__END_DECLS
-    +
-    +#endif /* bits/spin-lock.h */
-    diff --git a/sysdeps/l4/bits/pthread-np.h b/sysdeps/generic/bits/spin-lock.h
-    similarity index 67%
-    rename from sysdeps/l4/bits/pthread-np.h
-    rename to sysdeps/generic/bits/spin-lock.h
-    index 6a02bdc..c2ba332 100644
-    --- a/sysdeps/l4/bits/pthread-np.h
-    +++ b/sysdeps/generic/bits/spin-lock.h
-    @@ -1,5 +1,5 @@
-    -/* Non-portable functions. L4 version.
-    -   Copyright (C) 2003, 2007 Free Software Foundation, Inc.
-    +/* Machine-specific definitions for spin locks.  Generic version.
-    +   Copyright (C) 2000, 2005, 2008 Free Software Foundation, Inc.
-        This file is part of the GNU C Library.
-     
-        The GNU C Library is free software; you can redistribute it and/or
-    @@ -21,15 +21,19 @@
-      * Never include this file directly; use <pthread.h> or <cthreads.h> instead.
-      */
-     
-    -#ifndef _BITS_PTHREAD_NP_H
-    -#define _BITS_PTHREAD_NP_H	1
-    +#ifndef _BITS_SPIN_LOCK_H
-    +#define _BITS_SPIN_LOCK_H	1
-     
-    -#include <l4.h>
-    +#include <features.h>
-     
-    -/* Add the thread TID to the internal kernel thread pool.  */
-    -extern int pthread_pool_add_np (l4_thread_id_t tid);
-    +__BEGIN_DECLS
-     
-    -/* Get the first thread from the pool.  */
-    -extern l4_thread_id_t pthread_pool_get_np (void);
-    +/* The type of a spin lock object.  */
-    +typedef __volatile int __pthread_spinlock_t;
-     
-    -#endif /* bits/pthread-np.h */
-    +/* Initializer for a spin lock object.  */
-    +# define __SPIN_LOCK_INITIALIZER ((__pthread_spinlock_t) 0)
-    +
-    +__END_DECLS
-    +
-    +#endif /* bits/spin-lock.h */
-
-
-# Signal Stuff
-
-    diff --git a/pthread/pt-internal.h b/pthread/pt-internal.h
-    index cb441d0..986ec6b 100644
-    --- a/pthread/pt-internal.h
-    +++ b/pthread/pt-internal.h
-    @@ -26,13 +26,15 @@
-    [...]
-     #include <pt-sysdep.h>
-     #include <pt-machdep.h>
-     
-    +#include <sig-internal.h>
-    +
-     /* Thread state.  */
-     enum pthread_state
-     {
-    @@ -54,6 +56,10 @@ enum pthread_state
-     # define PTHREAD_SYSDEP_MEMBERS
-     #endif
-     
-    +#ifndef PTHREAD_SIGNAL_MEMBERS
-    +# define PTHREAD_SIGNAL_MEMBERS
-    +#endif
-    +
-     /* This structure describes a POSIX thread.  */
-     struct __pthread
-     {
-    @@ -89,6 +95,8 @@ struct __pthread
-     
-       PTHREAD_SYSDEP_MEMBERS
-     
-    +  PTHREAD_SIGNAL_MEMBERS
-    +
-       struct __pthread *next, **prevp;
-     };
-     
-    diff --git a/signal/kill.c b/signal/kill.c
-    index 27c9c32..c281640 100644
-    --- a/signal/kill.c
-    +++ b/signal/kill.c
-    @@ -20,6 +20,8 @@
-     
-     #include "sig-internal.h"
-     
-    +#include <string.h>
-    +
-     int
-     kill (pid_t pid, int signo)
-     {
-    @@ -65,6 +67,12 @@ kill (pid_t pid, int signo)
-          current thread has blocked the signal, the correct thing to do is
-          to iterate over all the other threads and find on that hasn't
-          blocked it.  */
-    +
-    +  extern int __pthread_num_threads;
-    +  if (__pthread_num_threads == 0)
-    +    panic ("signal %d received before pthread library is able to handle it",
-    +	   signo);
-    +
-       return pthread_kill (pthread_self (), signo);
-     }
-     
-    diff --git a/signal/pt-kill-siginfo-np.c b/signal/pt-kill-siginfo-np.c
-    index 9bdf6cc..35642c3 100644
-    --- a/signal/pt-kill-siginfo-np.c
-    +++ b/signal/pt-kill-siginfo-np.c
-    @@ -75,7 +75,8 @@ pthread_kill_siginfo_np (pthread_t tid, siginfo_t si)
-     	  || (ss->stack.ss_flags & SS_DISABLE)
-     	  || (ss->stack.ss_flags & SS_ONSTACK)))
-         /* We are sending a signal to ourself and we don't use an
-    -       alternate stack.  */
-    +       alternate stack.  (Recall: SA_ONSTACK means use the alt
-    +       stack.)  */
-         signal_dispatch (ss, &si);
-       else
-         signal_dispatch_lowlevel (ss, tid, si);
-    diff --git a/signal/signal-dispatch.c b/signal/signal-dispatch.c
-    index 40440b7..6fafcc1 100644
-    --- a/signal/signal-dispatch.c
-    +++ b/signal/signal-dispatch.c
-    @@ -20,6 +20,8 @@
-     
-     #include "sig-internal.h"
-     
-    +#include <viengoos/math.h>
-    +
-     /* This is the signal handler entry point.  A thread is forced into
-        this state when it receives a signal.  We need to save the thread's
-        state and then invoke the high-level signal dispatcher.  SS->LOCK
-    @@ -107,7 +109,7 @@ signal_dispatch (struct signal_state *ss, siginfo_t *si)
-           sigset_t pending = ~ss->blocked & ss->pending;
-           if (! pending)
-     	pending = ~ss->blocked & process_pending;
-    -      signo = l4_lsb64 (pending);
-    +      signo = vg_lsb64 (pending);
-         }
-       while (signo);
-     
-    diff --git a/signal/sigwaiter.c b/signal/sigwaiter.c
-    index 8d041ac..adc05ca 100644
-    --- a/signal/sigwaiter.c
-    +++ b/signal/sigwaiter.c
-    @@ -20,7 +20,7 @@
-     
-     #include "sig-internal.h"
-     
-    -#include <hurd/futex.h>
-    +#include <viengoos/futex.h>
-     
-     struct sigwaiter *sigwaiters;
-     
-    diff --git a/signal/sigwaitinfo.c b/signal/sigwaitinfo.c
-    index 1b47079..dea3ef4 100644
-    --- a/signal/sigwaitinfo.c
-    +++ b/signal/sigwaitinfo.c
-    @@ -43,7 +43,7 @@ sigwaitinfo (const sigset_t *restrict set, siginfo_t *restrict info)
-     
-           assert (extant);
-     
-    -      int signo = l4_msb64 (extant);
-    +      int signo = vg_msb64 (extant);
-     
-           if (info)
-     	{
-
-
-# `ALWAYS_TRACK_MUTEX_OWNER`
-
-    diff --git a/sysdeps/generic/pt-mutex-timedlock.c b/sysdeps/generic/pt-mutex-timedlock.c
-    index ee43219..265a453 100644
-    --- a/sysdeps/generic/pt-mutex-timedlock.c
-    +++ b/sysdeps/generic/pt-mutex-timedlock.c
-    @@ -36,7 +36,6 @@ __pthread_mutex_timedlock_internal (struct __pthread_mutex *mutex,
-       if (__pthread_spin_trylock (&mutex->__held) == 0)
-         /* Successfully acquired the lock.  */
-         {
-    -#ifdef ALWAYS_TRACK_MUTEX_OWNER
-     #ifndef NDEBUG
-           self = _pthread_self ();
-           if (self)
-    @@ -48,7 +47,6 @@ __pthread_mutex_timedlock_internal (struct __pthread_mutex *mutex,
-     	  mutex->owner = _pthread_self ();
-     	}
-     #endif
-    -#endif
-     
-           if (mutex->attr)
-     	switch (mutex->attr->mutex_type)
-    @@ -75,16 +73,14 @@ __pthread_mutex_timedlock_internal (struct __pthread_mutex *mutex,
-       self = _pthread_self ();
-       assert (self);
-     
-    -  if (! mutex->attr || mutex->attr->mutex_type == PTHREAD_MUTEX_NORMAL)
-    -    {
-    -#if defined(ALWAYS_TRACK_MUTEX_OWNER)
-    -      assert (mutex->owner != self);
-    -#endif
-    -    }
-    -  else
-    +  if (mutex->attr)
-         {
-           switch (mutex->attr->mutex_type)
-     	{
-    +	case PTHREAD_MUTEX_NORMAL:
-    +	  assert (mutex->owner != self);
-    +	  break;
-    +
-     	case PTHREAD_MUTEX_ERRORCHECK:
-     	  if (mutex->owner == self)
-     	    {
-    @@ -106,10 +102,9 @@ __pthread_mutex_timedlock_internal (struct __pthread_mutex *mutex,
-     	  LOSE;
-     	}
-         }
-    +  else
-    +    assert (mutex->owner != self);
-     
-    -#if !defined(ALWAYS_TRACK_MUTEX_OWNER)
-    -  if (mutex->attr && mutex->attr->mutex_type != PTHREAD_MUTEX_NORMAL)
-    -#endif
-         assert (mutex->owner);
-     
-       if (abstime && (abstime->tv_nsec < 0 || abstime->tv_nsec >= 1000000000))
-    @@ -146,12 +141,9 @@ __pthread_mutex_timedlock_internal (struct __pthread_mutex *mutex,
-       else
-         __pthread_block (self);
-     
-    -#if !defined(ALWAYS_TRACK_MUTEX_OWNER)
-    -  if (mutex->attr && mutex->attr->mutex_type != PTHREAD_MUTEX_NORMAL)
-    -#endif
-    -    {
-    +#ifndef NDEBUG
-           assert (mutex->owner == self);
-    -    }
-    +#endif
-     
-       if (mutex->attr)
-         switch (mutex->attr->mutex_type)
-    diff --git a/sysdeps/generic/pt-mutex-transfer-np.c b/sysdeps/generic/pt-mutex-transfer-np.c
-    index 7796ac4..bcb809d 100644
-    --- a/sysdeps/generic/pt-mutex-transfer-np.c
-    +++ b/sysdeps/generic/pt-mutex-transfer-np.c
-    @@ -45,12 +45,7 @@ __pthread_mutex_transfer_np (struct __pthread_mutex *mutex, pthread_t tid)
-         }
-     
-     #ifndef NDEBUG
-    -# if !defined(ALWAYS_TRACK_MUTEX_OWNER)
-    -  if (mutex->attr && mutex->attr->mutex_type != PTHREAD_MUTEX_NORMAL)
-    -# endif
-    -    {
-           mutex->owner = thread;
-    -    }
-     #endif
-     
-       return 0;
-    diff --git a/sysdeps/generic/pt-mutex-unlock.c b/sysdeps/generic/pt-mutex-unlock.c
-    index 7645fd4..f299750 100644
-    --- a/sysdeps/generic/pt-mutex-unlock.c
-    +++ b/sysdeps/generic/pt-mutex-unlock.c
-    @@ -33,16 +33,19 @@ __pthread_mutex_unlock (pthread_mutex_t *mutex)
-     
-       if (! mutex->attr || mutex->attr->mutex_type == PTHREAD_MUTEX_NORMAL)
-         {
-    -#if defined(ALWAYS_TRACK_MUTEX_OWNER)
-     # ifndef NDEBUG
-           if (_pthread_self ())
-     	{
-     	  assert (mutex->owner);
-    -	  assert (mutex->owner == _pthread_self ());
-    +	  assertx (mutex->owner == _pthread_self (),
-    +		   "%p("VG_THREAD_ID_FMT") != %p("VG_THREAD_ID_FMT")",
-    +		   mutex->owner,
-    +		   ((struct __pthread *) mutex->owner)->threadid,
-    +		   _pthread_self (),
-    +		   _pthread_self ()->threadid);
-     	  mutex->owner = NULL;
-     	}
-     # endif
-    -#endif
-         }
-       else
-         switch (mutex->attr->mutex_type)
-    @@ -81,12 +84,7 @@ __pthread_mutex_unlock (pthread_mutex_t *mutex)
-       __pthread_dequeue (wakeup);
-     
-     #ifndef NDEBUG
-    -# if !defined (ALWAYS_TRACK_MUTEX_OWNER)
-    -  if (mutex->attr && mutex->attr->mutex_type != PTHREAD_MUTEX_NORMAL)
-    -# endif
-    -    {
-           mutex->owner = wakeup;
-    -    }
-     #endif
-     
-       /* We do not unlock MUTEX->held: we are transferring the ownership
-
-
-# `t/fix_have_kernel_resources`
-
-See topic branch of that name.
-
-    diff --git a/sysdeps/mach/hurd/pt-sysdep.h b/sysdeps/mach/hurd/pt-sysdep.h
-    index f14a136..83bad96 100644
-    --- a/sysdeps/mach/hurd/pt-sysdep.h
-    +++ b/sysdeps/mach/hurd/pt-sysdep.h
-    @@ -1,5 +1,5 @@
-     /* Internal defenitions for pthreads library.
-    -   Copyright (C) 2000, 2002, 2008 Free Software Foundation, Inc.
-    +   Copyright (C) 2000, 2002 Free Software Foundation, Inc.
-        This file is part of the GNU C Library.
-     
-        The GNU C Library is free software; you can redistribute it and/or
-    @@ -32,8 +32,7 @@
-     
-     #define PTHREAD_SYSDEP_MEMBERS \
-       thread_t kernel_thread;      \
-    -  mach_msg_header_t wakeupmsg; \
-    -  int have_kernel_resources;
-    +  mach_msg_header_t wakeupmsg;
-     
-     #define _HURD_THREADVAR_THREAD _HURD_THREADVAR_DYNAMIC_USER
-     
-    diff --git a/sysdeps/mach/pt-thread-alloc.c b/sysdeps/mach/pt-thread-alloc.c
-    index 3d7c046..1acba98 100644
-    --- a/sysdeps/mach/pt-thread-alloc.c
-    +++ b/sysdeps/mach/pt-thread-alloc.c
-    @@ -1,5 +1,5 @@
-     /* Start thread.  Mach version.
-    -   Copyright (C) 2000, 2002, 2005, 2008 Free Software Foundation, Inc.
-    +   Copyright (C) 2000, 2002, 2005 Free Software Foundation, Inc.
-        This file is part of the GNU C Library.
-     
-        The GNU C Library is free software; you can redistribute it and/or
-    @@ -63,9 +63,6 @@ create_wakeupmsg (struct __pthread *thread)
-     int
-     __pthread_thread_alloc (struct __pthread *thread)
-     {
-    -  if (thread->have_kernel_resources)
-    -    return 0;
-    -
-       error_t err;
-     
-       err = create_wakeupmsg (thread);
-    @@ -100,7 +97,5 @@ __pthread_thread_alloc (struct __pthread *thread)
-     	return EAGAIN;
-         }
-     
-    -  thread->have_kernel_resources = 1;
-    -
-       return 0;
-     }
-
-
-# Miscellaneous
-
-    diff --git a/Makefile b/Makefile
-    index 04dfb26..a4c0c52 100644
-    --- a/Makefile
-    +++ b/Makefile
-    @@ -71,7 +71,6 @@ SRCS := pt-attr.c pt-attr-destroy.c pt-attr-getdetachstate.c		    \
-     	pt-mutex-init.c pt-mutex-destroy.c				    \
-     	pt-mutex-lock.c pt-mutex-trylock.c pt-mutex-timedlock.c		    \
-     	pt-mutex-unlock.c						    \
-    -	pt-mutex-transfer-np.c						    \
-     	pt-mutex-getprioceiling.c pt-mutex-setprioceiling.c		    \
-     									    \
-     	pt-rwlock-attr.c						    \
-    @@ -100,7 +99,6 @@ SRCS := pt-attr.c pt-attr-destroy.c pt-attr-getdetachstate.c		    \
-     	pt-thread-dealloc.c						    \
-     	pt-thread-start.c						    \
-     	pt-thread-halt.c						    \
-    -	pt-startup.c							    \
-     									    \
-     	pt-getconcurrency.c pt-setconcurrency.c				    \
-     									    \
-    @@ -143,7 +141,6 @@ sysdeps_headers =				\
-     	      semaphore.h			\
-     						\
-                   bits/pthread.h			\
-    -              bits/pthread-np.h			\
-                   bits/mutex.h			\
-                   bits/condition.h			\
-                   bits/condition-attr.h		\
-    diff --git a/Makefile.am b/Makefile.am
-    index e59c946..e73d8d6 100644
-    --- a/Makefile.am
-    +++ b/Makefile.am
-    @@ -20,17 +20,18 @@
-     if ARCH_IA32
-       arch=ia32
-     endif
-    +if ARCH_X86_64
-    +  arch=x86_64
-    +endif
-     if ARCH_POWERPC
-       arch=powerpc
-     endif
-     
-     # The source files are scattered over several directories.  Add 
-     # all these directories to the vpath.
-    -SYSDEP_PATH = $(srcdir)/sysdeps/l4/hurd/${arch}	\
-    -	 $(srcdir)/sysdeps/l4/${arch}		\
-    +SYSDEP_PATH = $(srcdir)/sysdeps/viengoos/${arch} \
-     	 $(srcdir)/sysdeps/${arch}		\
-    -	 $(srcdir)/sysdeps/l4/hurd		\
-    -	 $(srcdir)/sysdeps/l4			\
-    +	 $(srcdir)/sysdeps/viengoos		\
-     	 $(srcdir)/sysdeps/hurd			\
-     	 $(srcdir)/sysdeps/generic		\
-     	 $(srcdir)/sysdeps/posix		\
-    @@ -68,7 +69,6 @@ libpthread_a_SOURCES = pt-attr.c pt-attr-destroy.c pt-attr-getdetachstate.c \
-     	pt-alloc.c							    \
-     	pt-create.c							    \
-     	pt-getattr.c							    \
-    -	pt-pool-np.c							    \
-     	pt-equal.c							    \
-     	pt-dealloc.c							    \
-     	pt-detach.c							    \
-    diff --git a/headers.m4 b/headers.m4
-    index 5a58b9b..7c73cf2 100644
-    --- a/headers.m4
-    +++ b/headers.m4
-    @@ -14,10 +14,9 @@ AC_CONFIG_LINKS([
-       sysroot/include/pthread.h:libpthread/include/pthread.h
-       sysroot/include/pthread/pthread.h:libpthread/include/pthread/pthread.h
-       sysroot/include/pthread/pthreadtypes.h:libpthread/include/pthread/pthreadtypes.h
-    -  sysroot/include/bits/memory.h:libpthread/sysdeps/${arch}/bits/memory.h
-    -  sysroot/include/bits/spin-lock.h:libpthread/sysdeps/${arch}/bits/spin-lock.h
-    -  sysroot/include/bits/spin-lock-inline.h:libpthread/sysdeps/${arch}/bits/spin-lock-inline.h
-    -  sysroot/include/bits/pthreadtypes.h:libpthread/sysdeps/generic/bits/pthreadtypes.h
-    +  sysroot/include/bits/memory.h:libpthread/sysdeps/generic/bits/memory.h
-    +  sysroot/include/bits/spin-lock.h:libpthread/sysdeps/generic/bits/spin-lock.h
-    +  sysroot/include/bits/spin-lock-inline.h:libpthread/sysdeps/generic/bits/spin-lock-inline.h
-       sysroot/include/bits/barrier-attr.h:libpthread/sysdeps/generic/bits/barrier-attr.h
-       sysroot/include/bits/barrier.h:libpthread/sysdeps/generic/bits/barrier.h
-       sysroot/include/bits/cancelation.h:libpthread/sysdeps/generic/bits/cancelation.h
-    @@ -30,9 +29,8 @@ AC_CONFIG_LINKS([
-       sysroot/include/bits/rwlock-attr.h:libpthread/sysdeps/generic/bits/rwlock-attr.h
-       sysroot/include/bits/rwlock.h:libpthread/sysdeps/generic/bits/rwlock.h
-       sysroot/include/bits/thread-attr.h:libpthread/sysdeps/generic/bits/thread-attr.h
-    -  sysroot/include/bits/thread-barrier.h:libpthread/sysdeps/generic/bits/thread-barrier.h
-       sysroot/include/bits/thread-specific.h:libpthread/sysdeps/generic/bits/thread-specific.h
-    -  sysroot/include/bits/pthread-np.h:libpthread/sysdeps/l4/hurd/bits/pthread-np.h
-    +  sysroot/include/bits/pthread-np.h:libpthread/sysdeps/viengoos/bits/pthread-np.h
-       sysroot/include/semaphore.h:libpthread/include/semaphore.h
-       sysroot/include/bits/semaphore.h:libpthread/sysdeps/generic/bits/semaphore.h
-       sysroot/include/signal.h:libpthread/signal/signal.h
-    @@ -41,5 +39,5 @@ AC_CONFIG_LINKS([
-     AC_CONFIG_COMMANDS_POST([
-       mkdir -p sysroot/lib libpthread &&
-       ln -sf ../../libpthread/libpthread.a sysroot/lib/ &&
-    -  touch libpthread/libpthread.a
-    +  echo '/* This file intentionally left blank.  */' >libpthread/libpthread.a
-     ])
-    diff --git a/sysdeps/hurd/pt-setspecific.c b/sysdeps/hurd/pt-setspecific.c
-    index 89ca4d7..d2d1157 100644
-    --- a/sysdeps/hurd/pt-setspecific.c
-    +++ b/sysdeps/hurd/pt-setspecific.c
-    @@ -1,5 +1,5 @@
-     /* pthread_setspecific.  Generic version.
-    -   Copyright (C) 2002 Free Software Foundation, Inc.
-    +   Copyright (C) 2002, 2008 Free Software Foundation, Inc.
-        This file is part of the GNU C Library.
-     
-        The GNU C Library is free software; you can redistribute it and/or
-    @@ -30,7 +30,8 @@ pthread_setspecific (pthread_key_t key, const void *value)
-     
-       if (! self->thread_specifics)
-         {
-    -      err = hurd_ihash_create (&self->thread_specifics, HURD_IHASH_NO_LOCP);
-    +      err = hurd_ihash_create (&self->thread_specifics, false,
-    +			       HURD_IHASH_NO_LOCP);
-           if (err)
-     	return ENOMEM;
-         }
-    diff --git a/sysdeps/mach/pt-thread-halt.c b/sysdeps/mach/pt-thread-halt.c
-    index 973cde1..9f86024 100644
-    --- a/sysdeps/mach/pt-thread-halt.c
-    +++ b/sysdeps/mach/pt-thread-halt.c
-    @@ -30,8 +30,14 @@
-        being halted, thus the last action should be halting the thread
-        itself.  */
-     void
-    -__pthread_thread_halt (struct __pthread *thread)
-    +__pthread_thread_halt (struct __pthread *thread, int need_dealloc)
-     {
-    -  error_t err = __thread_terminate (thread->kernel_thread);
-    +  error_t err;
-    +  thread_t tid = thread->kernel_thread;
-    +
-    +  if (need_dealloc)
-    +    __pthread_dealloc (thread);
-    +
-    +  err = __thread_terminate (tid);
-       assert_perror (err);
-     }
diff --git a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn
deleted file mode 100644
index 9f732fbe..00000000
--- a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn
+++ /dev/null
@@ -1,120 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 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]]."]]"""]]
-
-[[!meta title="libpthread: CLOCK_MONOTONIC"]]
-
-[[!tag open_issue_glibc open_issue_libpthread]]
-
-[[!message-id "201204220058.37328.toscano.pino@tiscali.it"]]
-
-
-# IRC, freenode, #hurd, 2012-04-22
-
-    <pinotree> youpi: what i thought would be creating a
-      glib/hurd/hurdtime.{c,h}, adding _hurd_gettimeofday and
-      _hurd_clock_{gettime,settime,getres} to it and making the current .c in
-      sysdeps call those
-    <youpi> yep
-    <youpi> that's unfortunate, but that's what nptl actually does
-    <pinotree> this way we could add inside hurdtime.c the mapped time stuff
-      too
-
-[[Mapped-time_interface|microkernel/mach/gnumach/interface/device/time]].
-
-    <pinotree> most probably a noobish question, but why does rt link to
-      pthread?
-    <youpi> no idea :)
-    <youpi> possibly due to aio implementation
-    <youpi> ./sysdeps/pthread/aio_cancel.c
-    <youpi> probably due to that
-    <youpi> (and others)
-
-
-## IRC, freenode, #hurd, 2012-04-23
-
-    <youpi> pinotree: about librt vs libpthread, don't worry too much for now
-    <youpi> libpthread can lib against the already-installed librt
-    <youpi> it does work
-    <pinotree> youpi: wouldn't that cause a dependency loop?
-    <youpi> pinotree: what dependency loop?
-    <pinotree> youpi: librt wouldd link to pthread, no?
-    <youpi> and ?
-    <youpi> I don't think it's an issue that .so link with each other
-    <pinotree> it isn't?
-    <youpi> well, try
-    * pinotree never did that
-    <youpi> but I don't think it will pose problem
-    <youpi> well, perhaps initialization order
-    <youpi> anyway, I now have packages built, I'll test that
-    <youpi> pinotree: ok, it seems it doesn't work indeed :)
-    <youpi> early in initialization
-    <youpi> pinotree: the initialization bug might actually not be due to librt
-      at all
-    <youpi> pinotree: yes, things work even with -lrt
-    <pinotree> wow
-
-
-## IRC, OFTC, #debian-hurd, 2012-06-04
-
-    <youpi> pinotree: -lrt in libpthread is what is breaking glib2.0
-    <youpi> during ./configure it makes clock_gettime linked in, while at
-      library link it doesn't
-    <youpi> probably for obscure reasons
-    <youpi> I'll have to disable it in debian
-
-
-### IRC, OFTC, #debian-hurd, 2012-06-05
-
-    <pinotree> youpi: i saw your message about the linking issues with
-      pthread/rt; do you want me to provide a patch to switch clock_gettime →
-      gettimeofday in libpthread?
-    <youpi> you mean switch it back as it was previously?
-    <pinotree> kind of, yes
-    <youpi> I have reverted the change in libc for now
-    <pinotree> ok
-
-
-## IRC, freenode, #hurd, 2012-07-22
-
-    <tschwinge> pinotree, youpi: I once saw you discussing issue with librt
-      usage is libpthread -- is it this issue?  http://sourceware.org/PR14304
-    <youpi> tschwinge: (librt): no
-    <youpi> it's the converse
-    <pinotree> tschwinge: kind of
-    <youpi> unexpectedly loading libpthread is almost never a problem
-    <youpi> it's unexpectedly loading librt which was a problem for glib
-    <youpi> tschwinge: basically what happened with glib is that at configure
-      time, it could find clock_gettime without any -lrt, because of pulling
-      -lpthread, but at link time that wouldn't happen
-
-
-## IRC, freenode, #hurd, 2012-07-23
-
-    <braunr> pinotree: oh, i see you changed __pthread_timedblock to use
-      clock_gettime
-    <braunr> i wonder if i should do the same in libthreads
-    <pinotree> yeah, i realized later it was a bad move
-    <braunr> ok
-    <braunr> i'll stick to gettimeofday for now
-    <pinotree> it'll be safe when implementing some private
-      __hurd_clock_get{time,res} in libc proper, making librt just forward to
-      it and adapting the gettimeofday to use it
-
-
-## IRC, freenode, #hurd, 2012-10-22
-
-    <pinotree> youpi: apparently somebody in glibc land is indirectly solving
-      our "libpthread needs lirt which pulls libphtread" circular issue by
-      moving the clock_* functions to libc proper
-    <youpi> I've seen that yes :)
-
-[[!sourceware_PR 14304]], [[!sourceware_PR 14743]], [[!message-id
-"CAH6eHdQRyTgkXE7k+UVpaObNTOZf7QF_fNoU-bqbMhfzXxXUDg@mail.gmail.com"]], commit
-6e6249d0b461b952d0f544792372663feb6d792a (2012-10-24).
diff --git a/open_issues/libpthread_addon.mdwn b/open_issues/libpthread_addon.mdwn
deleted file mode 100644
index 3a10cbde..00000000
--- a/open_issues/libpthread_addon.mdwn
+++ /dev/null
@@ -1,135 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 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]]."]]"""]]
-
-[[!meta title="libpthread as glibc addon"]]
-
-[[!tag open_issue_glibc open_issue_libpthread]]
-
-This page lists all the notes, issues, etc, only about compiling libpthread
-as addon for glibc, *not* for general libpthread issues.
-
-# Building
-
-To build libpthread as glibc addon, copy libpthread inside the glibc tree,
-and then tell glibc's configure to use it:
-
-    $ cp /path/to/libpthread libpthread
-    $ ./configure [...] --enable-add-ons=[...],libpthread
-
-Currently, it is build like that in Debian since eglibc 2.13-31.
-
-# Issues and notes
-
-### `bits/` headers not used
-
-Recompiling glibc (e.g. on a Debian system) and running the
-`check-local-headers` test, `check-local-headers.out` shows:
-
-    *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/pthread.h
-    *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/thread-attr.h
-    *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/mutex-attr.h
-    *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/mutex.h
-    *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/condition-attr.h
-    *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/condition.h
-    *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/rwlock-attr.h
-    *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/rwlock.h
-    *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/barrier-attr.h
-    *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/barrier.h
-    *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/thread-specific.h
-    *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/once.h
-    *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/cancelation.h
-    *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/pthread-np.h
-
-This happens because these headers are in the `bits/` subdirectory in
-`sysdeps/generic` -- a `generic` sysdep is used only for the top-level
-`sysdeps` directory in glibc.
-
-### Use of hurd's libihash
-
-libpthread makes use of the ihash hurd library, as also glibc's
-`check-local-headers` test shows:
-
-    *** $(common-objpfx)libpthread/pt-alloc.o: uses /usr/include/hurd/ihash.h
-
-Possible alternatives: [[hurd/libihash]].
-
-### Executable stack
-
-Running glibc's `check-execstack` test gives in `check-execstack.out`:
-
-    $BUILDDIR/libpthread/libpthread.so.phdr: *** executable stack signaled
-
-### Extra PLT references
-
-Running glibc's `check-localplt` test gives in `check-localplt.out`:
-
-    Extra PLT reference: libpthread.so: pthread_detach
-    Extra PLT reference: libpthread.so: pthread_mutex_lock
-    Extra PLT reference: libpthread.so: pthread_mutexattr_settype
-    Extra PLT reference: libpthread.so: pthread_rwlock_rdlock
-    Extra PLT reference: libpthread.so: _pthread_spin_lock
-    Extra PLT reference: libpthread.so: pthread_attr_setstacksize
-    Extra PLT reference: libpthread.so: pthread_attr_getstacksize
-    Extra PLT reference: libpthread.so: pthread_attr_getstackaddr
-    Extra PLT reference: libpthread.so: pthread_attr_setstackaddr
-    Extra PLT reference: libpthread.so: pthread_exit
-    Extra PLT reference: libpthread.so: pthread_getspecific
-    Extra PLT reference: libpthread.so: __mutex_lock_solid
-    Extra PLT reference: libpthread.so: pthread_mutex_unlock
-    Extra PLT reference: libpthread.so: pthread_setcanceltype
-    Extra PLT reference: libpthread.so: pthread_key_create
-    Extra PLT reference: libpthread.so: pthread_cond_wait
-    Extra PLT reference: libpthread.so: pthread_rwlock_wrlock
-    Extra PLT reference: libpthread.so: pthread_once
-    Extra PLT reference: libpthread.so: pthread_cond_broadcast
-    Extra PLT reference: libpthread.so: pthread_setspecific
-    Extra PLT reference: libpthread.so: __pthread_get_cleanup_stack
-    Extra PLT reference: libpthread.so: pthread_rwlock_unlock
-    Extra PLT reference: libpthread.so: pthread_create
-    Extra PLT reference: libpthread.so: pthread_mutex_init
-    Extra PLT reference: libpthread.so: pthread_mutexattr_init
-    Extra PLT reference: libpthread.so: __mutex_unlock_solid
-    Extra PLT reference: libpthread.so: pthread_mutexattr_destroy
-    Extra PLT reference: libpthread.so: pthread_setcancelstate
-
-### `bits/posix_opt.h`
-
-`bits/posix_opt.h` is the glibc header defining the various
-supported/unsupported `_POSIX_*` defines (e.g. `_POSIX_THREADS`, etc).
-
-Currently, glibc's `sysdeps/mach/hurd/bits/posix_opt.h` is patched in Debian
-to add all the defines advertizing thread-related support.
-An idea to avoid this would be to follow what is done in NPTL, and do the
-following:
-
-   - in glibc: leave `sysdeps/mach/hurd/bits/posix_opt.h` with *no*
-thread-related macros at all.
-
-   - in libpthread: provide `sysdeps/mach/hurd/bits/posix_opt.h` which would
-be a copy of glibc's `sysdeps/mach/hurd/bits/posix_opt.h` with also the thread
-macros.
-
-This approach would have the drawback that changes in the glibc header must be
-mirrored also in the libpthread version, but with the advantage that defines
-according to supported features in libpthread can be added in libpthread's own
-version (and glibc would pick it automatically).
-
-### Tests
-
-The (few) existing tests are not built (thus neither run) just like other tests
-in glibc.
-
-### `gai_misc.h`
-
-A pthread version of `gai_misc.h` must be provided by libpthread (just like
-NPTL provides one), either in `sysdeps/mach/hurd` or `sysdeps/pthread`
-(better).
-
-Currently, it is provided in glibc itself in Debian.
diff --git a/open_issues/libpthread_assertion_thread_prevp.mdwn b/open_issues/libpthread_assertion_thread_prevp.mdwn
deleted file mode 100644
index f93f07d6..00000000
--- a/open_issues/libpthread_assertion_thread_prevp.mdwn
+++ /dev/null
@@ -1,109 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2013 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]]."]]"""]]
-
-[[!meta title="libpthread: __pthread_enqueue: Assertion `thread->prevp == 0'
-failed"]]
-
-[[!tag open_issue_libpthread]]
-
-
-# IRC, OFTC, #debian-hurd, 2011-10-21
-
-    [Python testsuite]
-    <pinotree> [169/340/1] test_logging
-    <pinotree> python:
-      /home/pino/sources/hurd/hurd-20110519/./libpthread/pthread/pt-internal.h:109:
-      __pthread_enqueue: Assertion `thread->prevp == 0' failed.
-    <pinotree> sigh
-
-
-## IRC, freenode, #hurd, 2011-10-21
-
-    <pinotree> am i missing anything, or in libpthread the __pthread_threads
-      list does not ever has elements removed from it?
-    <pinotree> ... thus potentially causing
-      "./libpthread/pthread/pt-internal.h:109: __pthread_enqueue: Assertion
-      `thread->prevp == 0' failed." because threads can be appended on
-      __pthread_dealloc() to the __pthread_free_threads list as well?
-    <pinotree> maybe reusing the same next+prevp pointers in the __pthread
-      struct for more than one list at the same time isn't a good idea...
-
-
-## IRC, freenode, #hurd, 2011-10-23
-
-    <youpi> pinotree: I don't understand the relation between thread->prevp !=
-      0 and the __pthread_threads list
-    <youpi> the list never has elements removed indeed, since libpthread never
-      frees __pthread structures apparently
-    <pinotree> youpi: ye sorry, that relation is indeed nonsense
-    <youpi> in which condition did you get prevp != 0
-    <pinotree> i wa trying to find some explaination for the "thread->prevp ==
-      0" assertion in the _queue function
-    <youpi> ?
-    <pinotree> *was
-    <youpi> it's not obvious to me how libpthread makes sure the various
-      cond/mutex/rwlock make sure that it's not queued several times
-    <pinotree> yeah
-    <pinotree> apparently prevp/next are used for lists of held
-      waitcond/mutex/rwlock and free threads
-
-
-# IRC, freenode, #hurd, 2013-03-20
-
-    <braunr> aw
-    <braunr> i hit the ext2fs.static: ./pthread/pt-internal.h:122:
-      __pthread_enqueue: Assertion `thread->prevp == 0' failed.
-    <braunr> assertion
-    <braunr> looks like there is a deadlock on assert
-    <braunr> which might explain why i never saw progress when i tested that in
-      the past
-
-
-## IRC, freenode, #hurd, 2013-04-21
-
-    <braunr> damn, there still bugs in libpthread
-    <braunr> (about prevp not being null when it should i mean)
-    <pinotree> braunr: found another trigger for that?
-    <braunr> no
-    <braunr> it's so random i wonder if it's not a completely unrelated
-      corruption
-    <braunr> pinotree: also, i'm having more of these issues with my custom
-      hurd packages that let threads exit after some time from managing ports
-    <braunr> (i removed the libports_stability patch)
-    <braunr> i once had this : http://www.sceen.net/~rbraun/darnassus_crash.png
-
-[The assertion failure.]
-
-
-## IRC, freenode, #hurd, 2013-04-23
-
-    <braunr> removing the libports_stability patch exposed bugs in libpthread,
-      triggering assertions when queueing/dequeue threads from a queue (but i
-      don't know which one / in which function)
-
-
-## IRC, freenode, #hurd, 2013-06-25
-
-    <pinotree> braunr:
-      https://buildd.debian.org/status/fetch.php?pkg=libmemcached&ver=1.0.17-2&arch=hurd-i386&stamp=1372165732
-    <pinotree> make: ./pthread/pt-internal.h:122: __pthread_enqueue: Assertion
-      `thread->prevp == 0' failed. \o/
-    <pinotree> (it should rather be /o\, but better pretend not)
-    <braunr> pinotree: yes, we regularly see it
-    <braunr> pinotree: how long has the machine been running at this point ?
-    <pinotree> dunno, you should ask samuel about that
-    <pinotree> does it happen after N hours/days?
-    <braunr> a few days of moderate to high activity yes
-    <pinotree> ah ok
-    <braunr> and i actually see this error much more often when i disable the
-      libports stability patch in the hurd debian package
-    <braunr> so i guess something is wrong with thread recycling
-    <braunr> but i wanted to completely rewrite that part with the new kernel
-      call i asked bddebian to work on :)
diff --git a/open_issues/libpthread_cancellation_points.mdwn b/open_issues/libpthread_cancellation_points.mdwn
deleted file mode 100644
index 48f1acf5..00000000
--- a/open_issues/libpthread_cancellation_points.mdwn
+++ /dev/null
@@ -1,139 +0,0 @@
-[[!meta copyright="Copyright © 2013 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]]."]]"""]]
-
-[[!meta title="cancellation points are not cancelling threads"]]
-
-[[!tag open_issue_libpthread]]
-
-    #include <pthread.h>
-    #include <stdio.h>
-    #include <sys/select.h>
-    #include <unistd.h>
-    
-    void *f (void*foo)
-    {
-        char buf[128];
-	//pthread_setcanceltype (PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
-	while (1) {
-	    read (0, buf, sizeof(buf));
-	}
-    }
-    int main (void) {
-        pthread_t t;
-	pthread_create (&t, NULL, f, NULL);
-	sleep (1);
-	pthread_cancel (t);
-	pthread_join (t, NULL);
-	exit(0);
-    }
-
-read() is not behaving as a cancellation point, only setting the cancel
-type to asynchronous permits this testcase to terminate. We do have the
-pthread_setcanceltype glibc/libpthread hook in the forward structure, but we are
-not using it: the LIBC_CANCEL_ASYNC macros are void, and we're not using them in
-the mig msg call either.
-
-
-# Provenance
-
-## IRC, OFTC, #debian-hurd, 2013-04-15
-
-    <paravoid> so, let me say a few things about the bug in the first place
-    <paravoid> the package builds and runs a test suite
-    <paravoid> the second test in the test suite blocks forever
-    <paravoid> a blocked pthread_join is what I see
-    <paravoid> I'm unsure why
-    <paravoid> have you seen anything like it before?
-    <youpi> whenever the thread doesn't actually terminate, sure
-    <youpi> what is the thread usually blocked on when you cancel it?
-    <paravoid> this is a hurd-specific issue
-    <paravoid> works on all other arches
-    <youpi> could be just that all other archs have more relaxed behavior
-    <youpi> thus the question of what exactly is supposed to be happening
-    <youpi> apparently it is inside a select?
-    <youpi> it seems select is not cancellable here
-    <pinotree> wasn't the patch you sent?
-    <youpi> no, my patch was about signals
-    <youpi> not cancellation
-    <pinotree> k
-    <youpi> (even if that could be related, of course)
-    <paravoid> how did you see that?
-    <paravoid> what's the equivalent of strace?
-    <youpi> thread 3 is inside _hurd_select
-    <paravoid> thread 1 is blocked on join
-    <paravoid> but the code is
-    <paravoid>     if(gdmaps->reload_thread_spawned) {
-    <paravoid>         pthread_cancel(gdmaps->reload_tid);
-    <paravoid>         pthread_join(gdmaps->reload_tid, NULL);
-    <paravoid>     }
-    <paravoid> so cancel should have killed the thread
-    <youpi> cancelling a thread is a complex matter
-    <youpi> there are cancellation points
-    <youpi> e.g. a thread performing while(1); can't be cancelled
-    <paravoid> thread 3 is just a libev event loop
-    <youpi> yes, "just" calling poll, the most complex system call of unix :)
-    <youpi> paravoid: anyway, don't look for a bug in your program, it's most
-      likely a bug in glibc, thanks for the report
-    <paravoid> I think it all boils down to a problem cancelling a thread in
-      poll()
-    <youpi> yes
-    <youpi> paravoid: ok, actually with the latest libc it does work
-    <paravoid> oh?
-    <youpi> where latest = not uploaded yet :/
-    <paravoid> did you test this on exodar?
-    <youpi> pinotree: that's the libpthread_cancellation.diff I guess
-    <paravoid> because I commented out the join :)
-    <youpi> paravoid:  in the root, yes
-    <youpi> well, I tried my own program
-    <paravoid> oh, okay
-    <youpi> which is indeed hanging inside select (or just read) in the chroot
-    <youpi> but not in the root
-    <pinotree> ah, richard's patch
-    <paravoid> url?
-    <youpi> I've installed the build-dep in the root, if you want to try
-    <paravoid> strange that root is newer than the chroot :)
-    <youpi> paravoid: it's the usual eglibc debian source
-    <paravoid> tried in root, still fails
-    <youpi> could you keep the process running?
-    <paravoid> done
-    <youpi> Mmm, but the thread running gdmaps_reload_thread never set the
-      cancel type to async?
-    <youpi> that said I guess read and select are supposed to be cancellation
-      points
-    <youpi> thus cancel_deferred should be working, but they are not
-    <youpi> it seems it's cancellation points which have just not been
-      implemented
-    <youpi> (they happen to be one of the most obscure things in posix)
-
-
-## IRC, freenode, #hurd, 2013-04-15
-
-    <youpi> but yes, there is still an issue, with PTHREAD_CANCEL_DEFERRED
-    <youpi> how calls like read() or select() are supposed to test
-      cancellation?
-    <pinotree> iirc there are the LIBC_CANCEL_* macros in glibc
-    <pinotree> eg sysdeps/unix/sysv/linux/pread.c
-    <youpi> yes
-    <youpi> but in our libpthredaD?
-    <pinotree> could it be we lack the libpthread → glibc bridge of
-      cancellation stuff?
-    <youpi> we do have pthread_setcancelstate/type forwards
-    <youpi> but it seems the default LIBC_CANCEL_ASYNC is void
-    <pinotree> i mean, so when you cancel a thread, you can get that cancel
-      status in libc proper, just like it seems done with LIBC_CANCEL_* macros
-      and nptl
-    <youpi> as I said, the bridge is there
-    <youpi> we're just not using it in glibc
-    <youpi> I'm writing an open_issues page
-
-
-### IRC, freenode, #hurd, 2013-04-16
-
-    <braunr> youpi: yes, we said some time ago that it was lacking
diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn
deleted file mode 100644
index a825fdff..00000000
--- a/open_issues/libpthread_dlopen.mdwn
+++ /dev/null
@@ -1,244 +0,0 @@
-[[!meta copyright="Copyright © 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_libpthread]]
-
-[[!toc]]
-
-# [[FAQ entry|faq/libpthread_dlopen]]
-
-# IRC, freenode, #hurd, 2010-01-24
-
-    <pinotree> youpi: hm, thought about the pthread/stubs issue w/ dlopen'ed
-      libraries
-    <pinotree> currently looks like libstdc++ on hurd links to pthread-stubs,
-      we're the only one with such configuration
-    <pinotree> i was looking at the gcc 4.4 patch hurd-pthread.diff, could it
-      be it does not set THREADLIBS in the configure.ac switch case?
-    <youpi> that's expected
-    <youpi> on linux the libc provides hooks itself, on hurd-i386 it's
-      pthread-stubs
-    <pinotree> why not explicitly link to pthread though?
-    <youpi> because there is no strict need to, for applications that don't
-      need libpthread
-    <youpi> the dlopen case is a tricky case that pthread-stubs had not thought
-      about
-    <pinotree> hm
-    <pinotree> what if the pthread stubs would be moved in our glibc?
-    <youpi> that's what we should do yes
-    <youpi> (ideally)
-    <youpi> but for this we need to build libpthread along glibc, to get it
-      really working
-
-[[Packaging_libpthread]].
-
-    <youpi> and that's the tricky part (Makefile & such) which hasn't been done
-      yet
-    <pinotree> why both (stubs + actual libpthread)?
-    <youpi> because you need the stubs to be able to call the actual libpthread
-    <youpi> as soon libpthread gets dlopened for instance
-    <youpi> +as
-    <pinotree> i see
-    <youpi> (remember that nptl does this if you want to see how)
-    <youpi> (it's the libc files in nptl/)
-    <youpi> (and forward.c)
-    <guillem> also if libpthreads gets integrated with glibc don't we need to
-      switch the hurd from cthreads then? Which has been the blocker all this
-      time AFAIR?
-    <youpi> we don't _need_ to
-    <guillem> ok
-
-
-# IRC, OFTC, #debian-hurd, 2011-07-21
-
-    <youpi> there's one known issue with pthreads
-    <youpi> you can't dlopen() it
-
-... if the main application is not already linked against it.
-
-    <youpi> which also means you can't dlopen() a module which depends on it if
-      the main application hasn't used -lpthread already
-    <youpi> (so as to get libpthread initialized early, not at the dlopen()
-      call)
-    <lucas> I get this while building simgrid:
-    <lucas> cd /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console &&
-      /usr/bin/cmake -E create_symlink
-      /home/lucas/simgrid-3.6.1/obj-i486-gnu/lib/libsimgrid.so
-      /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console/simgrid.so
-    <lucas> cd /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console &&
-      lua /home/lucas/simgrid-3.6.1/examples/gras/console/ping_generator.lua
-    <lucas> lua:
-      /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libpthread/sysdeps/generic/pt-mutex-timedlock.c:68:
-      __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed.
-    <lucas> Aborted (core dumped)
-    <youpi> that's it, yes
-    <youpi> (or at least it has the same symptoms)
-    <lucas> it would need fixing in lua, not in SG, then, right?
-    <youpi> yes
-    <lucas> ok, thanks
-
-The fix thus being: link the main application with -lpthread.
-
-IRC, freenode, #hurd, 2011-08-17
-
-    < youpi> i.e. openjade apparently dlopen()s modules which use pthreads, but
-      openjade itself is not liked against libpthread
-    < youpi> which means unexpectedly  loading pthreads on the fly, which is
-      not implemented
-    < youpi> (and hard to implement of course)
-    < youpi> gnu_srs: so simply tell openjade people to link it with -lpthread
-    < gnu_srs> Shuoldn't missing linking with pthread create an error when
-      building openjade then?
-    < youpi> no
-    < youpi> because it's just a module which needs pthread
-    < youpi> and that module _is_ linked with -lpthread
-    < youpi> and dlopen() loads libpthreads too due to that
-    < youpi> but that's unexpected, for the libpthread initialization stuff
-    < youpi> (and too late to fix initlaization)
-    < gnu_srs> How come that other OSes build opensp w/o problems?
-    < youpi> because there are stubs in the libc
-    < gnu_srs> Sorry for the delay: What hinders stubs to be present also in
-      the Hurd libc parts too, to cope with this problem?
-    < youpi> doing it
-    < youpi> which is hard because you need libpthread bits inside the libc
-    < youpi> making it simpler would need building libpthread at the same time
-      as libc
-
-[[packaging_libpthread]]
-
-
-# IRC, freenode, #hurd, 2013-09-03
-
-    <gnu_srs> iceweasel: ./pthread/../sysdeps/generic/pt-mutex-timedlock.c:70:
-      __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed.
-    <pinotree> LD_PRELOAD libpthread
-    <gnu_srs> why
-    <pinotree> missing link to pthread?
-    <pinotree> and yes, it's known already, just nobody worked on solving it
-
-
-# IRC, freenode, #hurd, 2014-01-28
-
-    <gnu_srs> braunr: Is this fixed by your recent patches? test_dbi:
-      ./pthread/../sysdeps/generic/pt-mutex-timedlock.c:70: 
-    <gnu_srs> __pthread_mutex_timedlock_internal: Assertion `__pthread_threads'
-      failed.
-    <youpi> faq/libpthread_dlopen.mdwn:
-      ./pthread/../sysdeps/generic/pt-mutex-timedlock.c:70:
-      __pthread_mutex_time
-    <gnu_srs> youpi: tks. A workaround seems to be available:
-      LD_PRELOAD=/lib/i386-gnu/libpthread.so.0.3
-    <gnu_srs> Is that possible on a buildd?
-    <youpi> it would be simpler to just make the package explicitly link
-      libpthread
-    <gnu_srs> Package is libdbi-drivers, providing libdbd-sqlite3 needed by
-      gnucash
-
-
-# IRC, freenode, #hurd, 2014-02-17
-
-    <braunr> hm ok, looks like iceweasel errors all have something to do with
-      the libc dns resolver
-    <braunr> http://darnassus.sceen.net/~rbraun/iceweasel_crash
-    <braunr> apparently, it's simply because the memory chunk isn't page
-      aligned ..
-    <braunr> looks like not preloading libpthread tirggers lots of tricky
-      issues
-    <braunr> anyway, apparently, the malloc/free calls in libresolv don't use
-      locks if libpthread isn't preloaded, which explains why the program state
-      looked impossible to reach and why crashes look random
-    <congzhang> debian linux does not have the pthread load problem.
-    <braunr> congzhang: it had it
-    <braunr> maybe not debian but i've found one such report for opensuse
-
-    <braunr> ok the bug is simple
-    <braunr> for some reason, our glibc still uses a global _res state for dns
-      resolution instead of per thread ones
-    <braunr> uh, apparently, it's libpthread's job to define a __res_state
-      function for that :(
-
-## IRC, freenode, #hurd, 2014-02-18
-
-    <braunr> usually when i say it, it crashes soon after, so let's try it :
-    <braunr> i've been running iceweasel 27 fine for like 10 minutes with a
-      patched libpthread
-    <braunr> still no crash ;p
-    <braunr> with luck this extremely lightweight patch will fix all
-      multithreaded applications doing concurrent name resolution .... :)
-    <teythoon> nice :)
-    <braunr> let's try gnash ....
-    <braunr> uh, segfault on termination
-    <braunr> gnash works :)
-    <teythoon> sweet :)
-    <braunr> i'm very surprised we could live so long with that resolv bug
-
-
-## IRC, freenode, #hurd, 2014-02-19
-
-    <braunr> youpi: the eglibc bug is about libresolv
-    <braunr> it uses a global resolver state even in multithreaded applications
-    <youpi> libresolv is a horrible part of glibc :)
-    <braunr> which is obviously bad
-    <braunr> yes .. :)
-    <braunr> here is the patch :
-      http://darnassus.sceen.net/~rbraun/0001-libpthread-per-thread-resolver-states.patch
-    <braunr> it's very short, it basically allocates a resolver state per
-      thread in the pthread struct, and sets the TLS variable __resp when the
-      thread starts
-    <braunr> should we make that hurd-specific ?
-    <braunr> or enclose that assignment with #ifdef ENABLE_TLS ?
-    <youpi> well, ENABLE_TLS is now always 1, iirc :)
-    <braunr> for the hurd, yes
-    <youpi> I'm surprised linux never had the issue
-    <youpi> no, not for the hurd
-    <braunr> ah
-    <youpi> I *had* to implement TLS for hurd because it was always 1 for
-      everybody :)
-    <braunr> ok
-    <braunr> so all those ifdefs could be removed and libpthread can assume tls
-      is enabled
-    <braunr> in which case my patch looks fine
-    <youpi> ah, thats a libpthread patch, not glibc patch
-    <braunr> yes
-    <braunr> nptl obviously did that from the start . :)
-    <braunr> linuxthreads had the problem a looong time ago
-    <youpi> ok
-    <braunr> i'm surprised we overlooked it for so long
-    <braunr> but anyway, that's a good fix
-    <youpi> indeed
-    <youpi> it seems all good to me
-    <braunr> well, __resp is a __thread variable
-    <braunr> i could add #ifdef ENABLE_TLS, but then what of the case where TLS
-      isn't enabled, and do we actually care ?
-    <braunr> #error maybe ?
-    <braunr> or #warning ?
-    <youpi> I don't think we care about the non-TLS case any more
-    <braunr> ok
-    <braunr> topgit branch i suppose ?
-    <youpi> well, not, hurd libpthread repo :)
-    <braunr> oh right ... :)
-
-
-# libthreads vs. libpthread
-
-The same symptom appears in an odd case, for instance:
-
-    buildd@hurd:~$ ldd /usr/bin/openjade
-            libthreads.so.0.3 => /lib/libthreads.so.0.3 (0x0103d000)
-            libosp.so.5 => /usr/lib/libosp.so.5 (0x01044000)
-            libpthread.so.0.3 => /lib/libpthread.so.0.3 (0x01221000)
-            libnsl.so.1 => /lib/i386-gnu/libnsl.so.1 (0x01232000)
-    [...]
-
-openjade links against *both* libthreads and libpthread. The result is that libc
-early-initializes libthreads only, and thus libpthread is not early-initialized,
-and later on raises assertions. The solution is to just get rid of libthreads,
-to have only one threading library.
diff --git a/open_issues/libpthread_glibc_nptl_testsuite.mdwn b/open_issues/libpthread_glibc_nptl_testsuite.mdwn
deleted file mode 100644
index 87204c9c..00000000
--- a/open_issues/libpthread_glibc_nptl_testsuite.mdwn
+++ /dev/null
@@ -1,26 +0,0 @@
-[[!meta copyright="Copyright © 2012 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_libpthread]]
-
-For fun and profit we should run [[glibc]]'s [[NPTL]] testsuite against
-[[libpthread]].
-
-Also, there are sometimes issues fixed in NPTL that libpthread should also be
-checked against.  Totally incomplete list:
-
-  * `pthread_cancel` when single-threaded, glibc
-    439bf404b8fa125cf950dc1aa37838702c5353ea, [[!sourceware_PR 13613]],
-    [[!message-id "20120509202437.268a72b9@spoyarek"]].
-  * `__libc_stack_end`, glibc 9c6ea9facbba4d430807bd21fa82892d713b1ecd,
-    18b5e737de22462ab6b3fc89f26c9ad480ebb843, [[!sourceware_PR 12416]],
-    [[!message-id "20120419120021.4780e8c8@spoyarek"]], [[!message-id
-    "20120615005913.4f517e02@spoyarek"]], [[!message-id
-    "4FE378DE.8050906@mentor.com"]].
diff --git a/open_issues/libpthread_set_stack_size.mdwn b/open_issues/libpthread_set_stack_size.mdwn
deleted file mode 100644
index 21c2f18e..00000000
--- a/open_issues/libpthread_set_stack_size.mdwn
+++ /dev/null
@@ -1,114 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012, 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_libpthread]]
-
-IRC, freenode, #hurd, 2011-10-21:
-
-    <pinotree> maybe i'm missing something... what's the reason for not
-      allowing setting a different stack size in libpthread?
-
-2011-10-23:
-
-    <youpi> pinotree: the threadvars implementations
-    <youpi> which needs to find the variables according to sp value
-    <youpi> of course, since we now have TLS, threadvards can go away
-    <youpi> it's simply on the so-long TODO list
-
-[[glibc/t/tls-threadvar]].
-
-2012-12-28:
-
-Hurd commit 3a3fcc811e6b50b21124a5c5a128652e788a3b67 `libports: remove the
-threadvars stack size hack`.
-
-IRC, freenode, #hurd, 2014-01-09:
-
-    <teythoon> braunr: i'm afraid it might be your patch 3a3fcc81 that breaks
-      proc
-    <teythoon> w/ the current debian libc that is
-    <teythoon> braunr: i reverted that patch and now it boots again
-    <gnu_srs> is alternate stack and arbitrary stack sizes supported by now, or
-      upcoming?
-    <braunr> gnu_srs: supported
-    <braunr> well
-    <braunr> considering what teythoon just said, maybe not
-    <gg0> need to remove __pthread_stack_default_size from
-      libpthread_hurd_cond_wait patch too i guess
-    <braunr> teythoon: i don't understand why this change has any negative
-      effect :/
-    <braunr> or
-    <braunr> hm no ..
-    <braunr> there may be a bug in the latest glibc, where changing the stack
-      is allowed on the ground that threadvars have been replaced with tls, but
-      the libpthread stack handling code does it wrong
-    <braunr> see 714413a7694ff534855e9e5904899695eac6c9bb in libpthread
-    <braunr> which the thread destruction patches already did before it was
-      fixed in libpthread
-    <braunr> and may explain why my packages work
-
-
-IRC, freenode, #hurd, 2014-01-14:
-
-    <youpi> teythoon: Mmm, I tried to update to the latest hurd commits, but
-      init dies early at boot
-    <youpi> exec init proc auth, and then init crashes
-    <youpi> downgrading libports to previous makes the issue go away
-    <braunr> youpi: previous ?
-    <youpi> previous debian package
-    <braunr> which patch makes it fail ?
-    <youpi> I'm bisecting
-    <braunr> i remember teythoon saying he had failures with the patch that
-      removes the threadvars stack size hack
-    <youpi> I'll try that already, ok
-    <youpi> yes, boots fine without this change
-    <braunr> ok
-    <youpi> perhaps some missing patches in the current 2.17-97 glibc
-    <braunr> or libpthread reacting badly to new stack sizes
-    <braunr> is 714413a7694ff534855e9e5904899695eac6c9bb included in your glibc
-      ?
-    <braunr> (714413a7694ff534855e9e5904899695eac6c9bb from libpthread)
-    <braunr> or maybe that's not the problem
-    <braunr> anyway, it's normally fixed with the thread destruction patch
-    <braunr> i did test it and checked the stack size were correct
-    <braunr> sizes*
-    <youpi> yes, debian's glibc has it
-    <youpi> ok
-    <youpi> so that can wait
-    <braunr> is 959f7365fccd1c89be9938c2655eba9122171e6a (Drop threadvars
-      entirely) also in your glibc ?
-    <youpi> yes
-    <braunr> that's weird :/
-    <braunr> the only thing i can think of is __pthread_stack_alloc miserably
-      failing with 2M stacks and "many" threads for some odd reason ..
-    <braunr> anyway, see you tomorrow
-    <gg0> hurd-i386/libpthread_hurd_cond_wait.diff keeps using
-      __pthread_stack_default_size. isn't it the problem?
-    * youpi wonders what that change is doing there
-    <youpi> and it's there from the start of that patch...
-    <braunr> +  if (&__pthread_stack_default_size != NULL)
-    <braunr> checks if the symbol is actually resolved
-    <braunr> that's what allows regular applications to work
-    <braunr> it should be the same for hurd servers
-
-
-# sigaltstack
-
-Likewise, `sigaltstack` is not usable at the moment.
-
-IRC, freenode, #hurd, 2014-02-25:
-
-    <gnu_srs> braunr: are the split/alternate stack etc problems solved by now
-      so gccgo can work properly?
-    <braunr> i don't know
-    <braunr> i suspect it wouldn't require much work now that tls is well
-      supported
-    <youpi> alternate stack is supposed to be working
diff --git a/open_issues/libpthread_timeout_dequeue.mdwn b/open_issues/libpthread_timeout_dequeue.mdwn
deleted file mode 100644
index 5ebb2e11..00000000
--- a/open_issues/libpthread_timeout_dequeue.mdwn
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!meta copyright="Copyright © 2012 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_libpthread]]
-
-
-# IRC, freenode, #hurd, 2012-08-17
-
-    <braunr> pthread_cond_timedwait and pthread_mutex_timedlock *can* produce
-      segfaults in our implementation
-    <braunr> if a timeout happens, but before the thread dequeues itself,
-      another tries to wake it, it will be dequeued twice
-    <braunr> this is the issue i spent a week on when working on fixing select
-
-[[select]]
diff --git a/open_issues/libpthread_weak_symbols.mdwn b/open_issues/libpthread_weak_symbols.mdwn
deleted file mode 100644
index 6f135979..00000000
--- a/open_issues/libpthread_weak_symbols.mdwn
+++ /dev/null
@@ -1,50 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_libpthread]]
-
-IRC, unknown channel, unknown date.
-
-    <youpi> btw, the issue with pthread_cancel is tricky
-    <youpi> I'm afraid there might be no fix
-    <youpi> clean fix, I mean
-    <pinotree> oh, hm
-    <pinotree> where it the problem located, actually?
-    <youpi> it's a lot more than just one place
-    <youpi> in some c++ header there is a weak reference to pthread_cancel
-    <youpi> libpthreadstubs0 provides a weak definition of pthread_cancel, which can suit well
-    <youpi> problem comes when also linking with a library which pulls libpthread
-    <youpi> oops no libpthreadstubs0 doesn't provide a weak definition of pthread_cancel
-    <youpi> it couldn't implement it anyway
-    <youpi> and the problem here is that the linker seems to be looking for pthread_cancel in the libpthreadstubs0 library, not libpthread
-    <youpi> and can't find it
-    <youpi> I don't know how this translate to english, but we're “walking on eggs
-    <youpi> ” on this issue
-    <pinotree> i see
-    <youpi> i.e. we already know we're not respecting the ELF standard
-    <youpi> we need a feature that is not in the standard to make pthread symbols working
-    <youpi> the solution would be to integrate libpthread into the glibc
-    <pinotree> you mean in the sources, but still providing separate libc.so and libpthread.so?
-    <youpi> yes
-    <pinotree> would that be difficult/tricky?
-    <youpi> because that permits to put pthread_* functions forwarding directly in the glibc, as is done on linux
-    <youpi> problem is upstream, you know...
-    <youpi> if we put libpthread there, it'll be difficult for us to maintain it
-    <pinotree> ah, the friendly ulrich mate?
-    <youpi> we already have difficults to get almost trivial patches commited
-    <youpi> and the "yes I'll handle it someday" Roland mate
-    <youpi> Roland is supposed to be the GNU part maintainer, but he doesn't have a box running at the moment
-    <youpi> what we could do is to do it in Debian for the moment
-    <pinotree> yeah
-    <pinotree> iirc eglibc is maintained within git, isn't it?
-    <pinotree> maybe you could do a hurd branch, putting all the hurd patches and the pthread sources, and then releasing from that
-    <youpi> we're already moving to something like that, yes
-    <youpi> at least for all the other glibc patches we have
-    <youpi> maybe we'll just do that on sourceware actually
diff --git a/open_issues/librpci.mdwn b/open_issues/librpci.mdwn
deleted file mode 100644
index a3af16b1..00000000
--- a/open_issues/librpci.mdwn
+++ /dev/null
@@ -1,31 +0,0 @@
-[[!meta copyright="Copyright © 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_gnumach open_issue_hurd]]
-
-2004 to 2007, Anand Babu has been working some on this project.  It is still in
-rather early stages.  It's meant to become an extension/complement to
-[[hurd/debugging/rpctrace]].
-
-  * <https://savannah.nongnu.org/projects/rpci>
-
-    > A C language library for interposing ports of a Hurd task running on top
-    > of GNU Mach micro-kernel. Using this library, it would be possible to
-    > implement a trace/replay system, RPC debugger, sandbox, etc.
-
-    On top of that, a debugger was planned:
-
-    > A RPC level debugger with useful command set to analyze/manipulate a task
-    > at run time. For example, the user will be able to set RPC break points,
-    > manipulate port rights and data, trace and replay a task.
-
-If there is interest, the existing source code could be moved from the CVS
-repository into the [[source_repositories/incubator]] ([[tschwinge]] already
-locally converted it to Git.)
diff --git a/open_issues/libstore_parted.mdwn b/open_issues/libstore_parted.mdwn
deleted file mode 100644
index 852c8fa8..00000000
--- a/open_issues/libstore_parted.mdwn
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-[[!meta redir=hurd/libstore/part]]
diff --git a/open_issues/libtool.mdwn b/open_issues/libtool.mdwn
deleted file mode 100644
index 7b2e0fe0..00000000
--- a/open_issues/libtool.mdwn
+++ /dev/null
@@ -1,19 +0,0 @@
-[[!meta copyright="Copyright © 2012 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_porting]]
-
-# [[GCC]]: `libtool: finish`: `ldconfig` is not run for the Hurd.
-
-This probably comes from libtool's `libltdl/m4/libtool.m4` (or similar):
-`finish_cmds`.
-
-There are a few other differences between `gnu` and `linux* | k*bsd*-gnu |
-kopensolaris*-gnu`.
diff --git a/open_issues/linux_as_the_kernel.mdwn b/open_issues/linux_as_the_kernel.mdwn
deleted file mode 100644
index 2656b1a3..00000000
--- a/open_issues/linux_as_the_kernel.mdwn
+++ /dev/null
@@ -1,268 +0,0 @@
-[[!meta copyright="Copyright © 2012, 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]]."]]"""]]
-
-Instead of attempting a [[history/port_to_another_microkernel]], or writing an
-own one, an implementation of a Hurd system could use another existing
-operating system/kernel, like [[UNIX]], for example, the Linux kernel.  This is
-not a [[microkernel]], but that is not an inherent hindrance; depending on what
-the goals are.
-
-There has been an attempt for building a [[Mach_on_top_of_POSIX]].
-
-
-# IRC, freenode, #hurd, 2012-02-08
-
-Richard's X-15 Mach re-implementation:
-
-    <braunr> and in case you didn't notice, it's stalled
-    <braunr> actually i don't intend to work on it for the time being
-    <braunr> i'd rather do as neal suggested: take linux, strip it, and give it
-      a mach interface
-    <braunr> (if your goal really is to get something usable for real world
-      tasks)
-    <antrik> braunr: why would you want to strip down Linux? I think one of the
-      major benefits of building a Linux-Frankenmach would be the ability to
-      use standard Linux functionality alongside Hurd...
-    <braunr> we could have a linux x86_64 based mach replacement in "little"
-      time, with a compatible i386 interface for the hurd
-    <braunr> antrik: well, many of the vfs and network subsystems would be hard
-      to use
-    <antrik> BTW, one of the talks at FOSDEM was about the possibility of using
-      different kernels for Genode, and pariticularily focused on the
-      possibilities with using Linux... unfortunately, I wasn't able to follow
-      the whole talk; but they mentioned similar possibilities to what I'm
-      envisioning here :-)
-
-
-## IRC, freenode, #hurd, 2012-03-28
-
-    <mel__> is there currently any work going on with respect to
-      Mach-alternatives?
-    <antrik> mel__: no
-    <antrik> we have other priorities to take care of :-)
-    <braunr> antrik: i still intend to try giving linux a "mach personality" :)
-    <braunr> antrik: but i don't have much time for development currently :(
-    <mel__> antrik: which means that the hope is that Mach can be turned into
-      something really well working (i.e. secure/scalable/etc.)?
-    <antrik> mel__: yes, that's the venue we are pursuing
-    <antrik> (and IMHO the right one... though the Linux layer mentioned by
-      braunr is also one of my favourite projects, that we should pursue *in
-      parallel* to the existing Mach-based implementation)
-    <mel__> what is this Linux Layer exactly?
-    <mel__> a Linux instance running on top of Mach in parallel to Hurd
-      serverS?
-    <braunr> mel__: not exactly
-    <braunr> mel__: it would involve adding a mach layer on top of linux
-      actually
-    <braunr> mel__: so that linux can be used as a mach kernel
-    <mel__> Ah!
-    <mel__> Running Hurd on top of Linux
-    <mel__> :-D
-    <mel__> Funny
-    <braunr> ironic, yes
-    <braunr> but very pragmatic
-    <mel__> and THEN
-    <antrik> yeah. I most like the name: Hurd Emulation Layer on
-      Linux... i.e. HELL :-)
-    <mel__> we use a device driver framework something so that we can use Linux
-      device drivers in Hurd!
-    <mel__> on top of Linux....
-    <braunr> yes
-    <braunr> i guess a transition phase would include using in kernel drivers
-      directly for a while
-    <mel__> and somebody is working on that?
-    <antrik> mel__: well, for using Linux drivers we are persuing DDE, which
-      allows us doing that with Mach as well
-    <braunr> then grabbing them out of the kernel and into dde
-    <braunr> not yet
-    <antrik> (in fact we have been using Linux drivers since forever... they
-      just haven't been updated for ages)
-    <mel__> I would _guess_ that it is not that hard.
-    <braunr> it's not
-    <mel__> Basically one would need to implement the message passing interface
-      thing in linux I guess.
-    <braunr> and many exported kernel objects like tasks, threads, etc..
-    <braunr> and implement all the RPCs normally implemented by the kernel
-    <braunr> but it's doable
-    <antrik> mel__: the IPC aspect is one part, but probably the less tricky
-      one. the external pager interface is really the crucial element
-    <mel__> uh
-    <mel__> yeah
-    <mel__> hooking into linux virtual memory stuff
-    <mel__> sounds delicate
-    <braunr> it's true that some interactions between the linux VM and file
-      systems (the linux equivalent of our pagers) is synchronous
-    <braunr> but i don't think it would be that hard considering the amount of
-      facilities available in linux
-    <braunr> it's just work, takes time, needs debugging, reviewing, testing,
-      etc..
-    <lcc> hurd on top of linux. how would that work?
-    <braunr> 15:30 < braunr> antrik: i still intend to try giving linux a "mach
-      personality" :)
-    <braunr> lcc: 7 system calls and a few hundreds of RPCs on top, the
-      internal magic of course, and voila ..
-    <antrik> of course porting Mach still requires work
-    <mel__> that would then be GNU/Hurd/Linux
-    <mel__> :-)
-    <antrik> hehe
-    <braunr> eh
-    <antrik> braunr: BTW, are you more thinking of a userspace solution on top
-      of standard Linux mechanisms, or additions to Linux itself?...
-    <antrik> (we probably talked about it already, but I don't remember all the
-      details...)
-    <braunr> antrik: adding to linux
-    <antrik> do you think a pure userspace solution would be realistic at all?
-      (at the expense of some performance of course)
-    <mel__> it's probably comparable to the qemu vs. qemu/kvm thing
-    <antrik> yeah, I guess that pretty much sums it up...
-    <braunr> antrik: i don't know :/
-    <antrik> OK
-    <lcc> how challenging is it to port mach?
-    <antrik> lcc: it requires good low-level knowledge of the platform in
-      question. having that, I guess it shouldn't be too hard to add the
-      necessary code in Mach...
-    <antrik> TBH I'm not sure how much knowledge of Mach internals is required
-    <braunr> the pmap module is the main thing to port
-    <antrik> braunr: well, sartakov seemed to have most trouble with the
-      scheduler when he attempted the ARM port...
-    <braunr> that's strange
-    <antrik> at least there was quite a long thread where he asked about how
-      task switching works in Mach
-    <braunr> ok
-    <braunr> that would be interesting
-    <braunr> i thought intereacting with the hardclock was enough
-
-
-## IRC, freenode, #hurd, 2012-04-05
-
-    <braunr> antrik: don't you think HELL is worth a try for the GSoC btw ?
-    <antrik> braunr: definitely. I haven't managed to rework the project ideas
-      list at all this year... but it's something I wanted there for a long
-      time
-
-    <youngrw> just out of curiousity, what is HELL ?
-    <antrik> Hurd Emulation Layer on Linux
-    <braunr> youngrw: it can be described in several ways
-    <braunr> youngrw: basically, it's a mach interface on top of linux
-    <youngrw> implementing I suppose both the IPC mechanism and memory
-      management interface?
-    <mel__> youngrw: basically that. more generally: implement everything in
-      order to let Hurd run on that layer.
-    <antrik> well, it's slightly more complicated in my view... it's basically
-      anything that allows running a Hurdish environment on top of
-      GNU/Linux. it might be simply an implementation/emulation of Mach
-      mechanisms; but it also *might* work on a slightly higher level...
-    <youngrw> antrik: how might HELL operate at the slighty higher level like
-      you describe?
-    <antrik> let's call it low-level HELL and high-level HELL ;-)
-    <antrik> (a more descriptive name would be hurdenv... but HELL is so much
-      more catchy :-) )
-    <antrik> so, high-level HELL... basically, the idea would be not to emulate
-      the kernel facilities and run all the real Hurd servers; but instead to
-      use special servers implementing the Hurd interfaces, but on top of
-      standard Linux facilities
-    <antrik> hurdish programs could run in such an environment, as long as they
-      aren't too low-level
-    <antrik> I wonder whether generic RPC interfaces could be implemented with
-      some side channel tunneled though the ordinary Linux FS interfaces...
-    <antrik> so translators would be loaded as FUSE modules for example, but
-      could still present generic interfaces
-    <youngrw> That's actually pretty different from what I was expecting
-    <antrik> what were you expecting?
-    <youngrw> maybe something where the entire kernel interface is emulated by
-      a running user process, like a kind of virtual machine
-    <youngrw> I hope that makes sense--I may be using my words incorrectly.
-    <antrik> youngrw: that would be in the low-level HELL category
-    <youngrw> antrik: right; I had the misconception that the level was defined
-      by how it made use of the underlying linux system
-    <youngrw> and that different HELL designs would always implement the mach
-      interface
-
-
-## IRC, freenode, #hurd, 2012-04-06
-
-    <braunr> antrik: i think we have diverging ideas about how to use linux for
-      the hurd
-    <braunr> antrik: what you seem to want are really emulation componants,
-      like e.g. ext2fs and pfinet actually using the linux implementation
-    <braunr> (correct me if i'm mistaken)
-    <braunr> whereas my project is to make linux behave as a mach clone
-    <antrik> braunr: as I said, I consider both variants -- either a high-level
-      HELL or a low-level HELL
-    <braunr> ok
-    <antrik> (or perhaps a mix of both)
-    <braunr> a mix would be best imho
-    <antrik> yeah, probably
-    <braunr> so we have the real hurd, the real mach interface, and a set of
-      native translators (e.g. ext2fs) along some emulating their functionality
-      using linux code (e.g. a hypothetical ext4fs)
-    <antrik> I don't think we would have emulation servers for individual Linux
-      filesystems. rather, a generic server interfacing with the Linux VFS
-      tree...
-    <braunr> ok
-
-    <antrik> braunr: BTW, I think I mentioned a couple of years ago that the
-      most realistic route towards a modern Mach in my opinion would be taking
-      a modern BSD (or Linux), and redo what the original Mach developers did
-      -- i.e. add the Mach-specific features, and drop the unnecessary UNIX
-      stuff
-    <braunr> antrik: :)
-    <braunr> we had discussions about it some time ago yes
-    <antrik> later I realised that it's better *not* to drop the UNIX
-      interfaces, but rather to keep them in parallel :-)
-    <braunr> antrik: for what purpose ?
-    <braunr> (i can imagine a few, but i'd like to know your idea)
-    <antrik> for the purpose of HELL :-)
-    <braunr> well hell would be the implementation, but what do you keep these
-      unix interfaces for ?
-    <antrik> i.e. people being able to play around with a Hurd environment
-      while staying with their existing system
-    <braunr> yes, i see
-    <braunr> i was considering doing that for development, yes
-    <braunr> uml first, and then i realized i wouldn't need it :)
-    <braunr> then i remembed netbsd and its syscall emulation layer
-    <antrik> also we might leverage some "foreign" userspace infrastructure
-      that way, such as udev
-    <antrik> (in the case of Linux that is... not sure whether NetBSD has
-      something similar at all ;-) )
-    <braunr> i'll have to check, it's been a long time since i've really used
-      it
-    <braunr> they must use a pure devfs instance now
-
-
-# IRC, freenode, #hurd, 2014-02-23
-
-    <desrt> so crazy idea: would it be possible to have mach as a linux kernel
-      module?
-    <desrt> ie: some new binfmt type thing that could load mach binaries and
-      implement the required kernel ABI for them
-    <desrt> and then run the entire hurd under that....
-    <braunr> desrt: that's an idea, yes
-    <braunr> and not a new one
-    * desrt did a bit of googling but didn't find any information about it
-    <braunr> desrt: but why are you thinking of it ?
-    <braunr> we talked about it here, informally
-    <desrt> braunr: mostly because running hurd in a VM sucks
-    <desrt> if we had mach-via-linux, we'd have:
-    <desrt>  - no vm overhead
-    <desrt>  - no device virtualisation
-    <desrt>  - 64bit (physical at least) memory support
-    <desrt>  - SMP
-    <desrt>  - access to the linux drivers, natively
-    <desrt> and maybe some other nice things
-    <braunr> yes we talkbed about all this
-    <braunr> but i still consider that to be an incomplete solution
-    <desrt> i don't consider it to be running "the hurd" as your OS... but it
-      would be a nice solution for development and virtualisation
-    <braunr> we probably don't want to use drivers natively, since we want them
-      to run in their own address space, with their own namespace context
-    <braunr> it would, certainly
-    <braunr> but it would require a lot of effort anyway
-    <desrt> right
diff --git a/open_issues/linux_vmsig.mdwn b/open_issues/linux_vmsig.mdwn
deleted file mode 100644
index 182fb6f9..00000000
--- a/open_issues/linux_vmsig.mdwn
+++ /dev/null
@@ -1,44 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2013 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]]."]]"""]]
-
-[[!meta title="Linux: vmsig"]]
-
-[[!tag open_issue_gnumach open_issue_hurd]]
-
-  * *cooperating with the VM when memory pressure increases*
-
-  * *notify user applications of virtual memory events via real-time signals*
-
-<http://www.cs.umass.edu/~emery/pubs/bookmarking-collector/>, and discussion at
-<http://lambda-the-ultimate.org/node/2391> and
-<http://marc.info/?t=113269321800003&r=1&w=2>.
-
-Found this via <http://lambda-the-ultimate.org/node/4094#comment-62100>, which
-was linked from [LWN](http://lwn.net/Articles/409416/).
-
-From a quick glance, this sounds to [[me|tschwinge]] quite a bit like
-mechanisms also found in (originating in?) Mach's
-[[microkernel/mach/external_pager_mechanism]].  May be worth having a look at
-it.
-
-
-# IRC, freenode, #hurd, 2013-03-06
-
-    <braunr> tschwinge: from a quick look, this isn't similar to the external
-      pager mechanism
-    <braunr> it's an additional tool to help userspace application manage
-      internal caches
-    <braunr> it's similar to what is done to reclaim memory from the slab
-      allocator for example
-    <braunr> and it would indeed be a very good thing to have so that e.g. the
-      hurd can build a distributed but completely dynamic dentry-like cache
-    <braunr> i'm actually glad to see someone else thought of using real time
-      signals for this
-    <braunr> i didn't do any research on that subject yet
diff --git a/open_issues/lisp_cross-compile.mdwn b/open_issues/lisp_cross-compile.mdwn
deleted file mode 100644
index c9100aec..00000000
--- a/open_issues/lisp_cross-compile.mdwn
+++ /dev/null
@@ -1,11 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-flaviocruz-soc2008-lisp-branch: lisp stuff can't be cross-compiled.
diff --git a/open_issues/llvm.mdwn b/open_issues/llvm.mdwn
deleted file mode 100644
index 4da58579..00000000
--- a/open_issues/llvm.mdwn
+++ /dev/null
@@ -1,398 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012, 2013 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_llvm]]
-
-Here's what's to be done for maintaining [[/LLVM]].
-
-Apart from the target-specific configuration machinery, there shouldn't be any
-major differences within LLVM between the GNU/Hurd and GNU/Linux ports, for
-example.  Especially all the compiler magic is all the same.
-
-[[!toc levels=2]]
-
-
-# [[General information|/llvm]]
-
-
-## Rebuild of the Debian archive with clang
-
-From [[!message-id "20120305195308.GA1904@zouish.org"]]:
-<http://sylvestre.ledru.info/blog/sylvestre/2012/02/29/rebuild_of_the_debian_archive_with_clang>,
-<http://clang.debian.net/>.
-
-
-# [[Sources|source_repositories/llvm]]
-
-
-# Configuration
-
-<!--
-
-For all of llvm, clang, compiler-rt, test-suite:
-
-git checkout reviewed
-git log --reverse --topo-order --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..upstream/master
--i
-/^commit |^merge:|^---$|hurd|gnu|linux|nacl|nptl|glibc|[^e]gs:|/proc
-
--->
-
-Last reviewed up to the [[Git mirror's sources|source_repositories/llvm]]: llvm
-6f7becfe23f38e8c28e9422d883263974058aeed (2013-03-24), clang
-495cfa46300979642acde8d93a1f21c9291dac98 (2013-03-23), compiler-rt
-a06fe9183fbffb78798a444da9bc3040fdd444aa (2013-03-23), test-suite
-5a05572d268568fb15b48f374f9fc9f882adecd2 (2013-03-23).
-
-  * <http://anonscm.debian.org/viewvc/pkg-llvm/llvm/trunk/debian/patches/>.
-
-  * [low] Some more `PATH_MAX`/`MAXPATHLEN` things.
-
-  * `gs:` usage
-
-      * `lib/Target/X86/`, `test/CodeGen/X86/`, `test/MC/X86/`.
-
-      * `tools/clang/`
-
-            tools/clang/docs/LanguageExtensions.rst:          movl    %gs:(%eax), %eax
-            tools/clang/test/Sema/asm.c:  asm volatile ("movb %%gs:%P2,%b0" : "=q"(b) : "0"(0), "i"(5L));
-
-      * `compiler-rt` and `test-suite` not yet examined.
-
-  * [low] Linuxisms
-
-      * In some CMake files (`CMakeLists.txt`, for example).
-
-      * `test/`, `unittests`, `tools/clang/test/`, `tools/clang/unittests/` not
-        yet examined.
-
-          * In clang's `test/Driver/` a lot of testing can be generalized from
-            *Linux* to *GNU environment*, adding GNU/Hurd testing, too.
-
-      * LLVM commit 98fbe27ac8f0766ea94b89b8c03418131b72bea4 `Support for
-        HiPE-compatible code emission`
-
-        Only relevant for `CallingConv::HiPE`.
-
-            +  assert(ST->isTargetLinux() &&
-            +         "HiPE prologue is only supported on Linux operating systems.");
-
-      * `compiler-rt` and `test-suite` not yet examined.
-
-  * `/proc` usage
-
-      * `compiler-rt` and `test-suite` not yet examined.
-
-  * `libc++` (not currently using)
-
-    Some Hurd-porting work is said to have been done as Google Summer of Code
-    2012 Debian project,
-    <http://wiki.debian.org/SummerOfCode2012/StudentApplications/AndrejBelym>.
-
-  * [[sanitizers|_san]]
-
-    A lot of Linux-specific things.
-
-  * IRC, OFTC, #debian-hurd, 2013-09-05:
-
-        <gg0> how can this fix it on {kf,hurd}-i386?
-          http://anonscm.debian.org/viewvc/pkg-llvm/llvm-toolchain/branches/3.3/debian/patches/libstdc%2B%2B-header-i386.diff?view=markup&sortby=date&pathrev=830
-        <pinotree> what makes you think it does?
-        <pinotree> it fixes #714890, which has nothing to do with hurd or
-          kfreebsd
-        <gg0> i simple wouldn't add a patch that fixes it on one i386 arch
-          only, being aware there are others
-        <pinotree> meet sylvestre
-
-  * IRC, freenode, #hurd, 2013-09-05:
-
-        <pinotree> tschwinge: iirc you were working on llvm/clang, weren't you?
-        <tschwinge> pinotree: That's right.  I have patches to
-          follow-up/rework.  Stalled at the moment, as you probably already
-          guessed...  %-)
-        <pinotree> tschwinge: <Sylvestre> by the way, pinotree if you have time
-          for hurd stuff, I would be glad to have your help to port
-          llvm-toolchain-3.3 to hurd. I am having some issues with threading
-          aspects https://paste.debian.net/35466/
-        <pinotree> he's the debian packager of llvm
-        <tschwinge> That paste is for LLDB -- which I'd not assume to be in a
-          shape usable for Hurd.
-        <tschwinge> (I didn't look at it at all.)
-        <pinotree> tschwinge: if you look at the latest llvm-toolchain-3.3
-          debian source, there's a lldb-hurd.diff patch, which starts some
-          include header dance
-
-
-# Build
-
-Here's a log of a LLVM build run; this is from our [[Git repository's
-sources|source_repositories/llvm]], llvm
-dc218fb6ae3241f4b66e9bf2c9d6352efecc0a14 (2013-03-24), clang
-744290b5ecd48bddb4a6cf96d68cdc4a57e24e36 (2013-03-24), compiler-rt
-a06fe9183fbffb78798a444da9bc3040fdd444aa (2013-03-23), test-suite
-1821ab0ef1c73430705356fdfde3769460092382 (2013-03-24), run on
-kepler.SCHWINGE and coulomb.SCHWINGE.
-
-    $ export LC_ALL=C
-    $ (cd ../Horace_Silver/ && ln -sfn ../../../clang/tschwinge/Hank_Mobley tools/clang)
-    $ (cd ../Horace_Silver/ && ln -sfn ../../../compiler-rt/tschwinge/Doug_Watkins projects/compiler-rt)
-    $ (cd ../Horace_Silver/ && ln -sfn ../../../test-suite/tschwinge/Art_Blakey projects/test-suite)
-    $ ../Horace_Silver/configure --prefix="$PWD".install --enable-optimized SHELL=/bin/dash CC=gcc-4.7 CXX=g++-4.7 2>&1 | tee log_build
-    $ make VERBOSE=1 2>&1 | tee log_build_
-
-Different hosts may default to different shells and compiler versions; thus
-harmonized.
-
-Passing `--enable-debug-symbols`, the GNU/Hurd build on coulomb.SCHWINGE
-terminates with a SIGBUS
-when linking `Release+Debug+Asserts/bin/clang` (which is bigger than 500 MiB
-for the corresponding GNU/Linux build).  Using `--enable-debug-symbols
---enable-shared`, the GNU/Hurd build hang after `make[1]: Leaving directory
-[...]/tools/llvm-shlib`, after (successfully) linking
-`Release+Debug+Asserts/lib/libLLVM-3.3svn.so` (which is bigger than 250 MiB for
-the corresponding GNU/Linux build).  Also there is a separate
-`--enable-debug-runtime`.
-
-This takes up around 3.2 GiB, and needs roughly 1.5 h on kepler.SCHWINGE and
-5.25 h on coulomb.SCHWINGE.
-
-Configuring without `--enable-optimized` even crashes mighty darnassus,
-probably because of too-big files when linking.  Configuring with
-`--enable-optimized --enable-expensive-checks --disable-threads
---enable-debug-symbols --enable-debug-runtime` is fine.
-
-<!--
-
-    $ (make VERBOSE=1 && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make VERBOSE=1 install && touch .go-test) 2>&1 | tee log_install && test -f .go-test && { make -k VERBOSE=1 LIT_ARGS='-v --threads=1' check-all 2>&1 | tee log_test_check-all; make -k -C projects/test-suite/ 2>&1 | tee log_test_test-suite; }
-
-    $ (PATH=$HOME/tmp/source/autoconf/AUTOCONF-2.60.build.install/bin:$HOME/tmp/source/automake/automake-1.9.6.build.install/bin:$HOME/tmp/source/libtool/release-1-5-22.build.install/bin:$PATH; ./AutoRegen.sh)
-
--->
-
-
-## Analysis
-
-    $ toolchain/logs/process llvm build
-
-        -checking for mmap of files... yes
-        +checking for mmap of files... no
-         checking if /dev/zero is needed for mmap... no
-        +configure: WARNING: mmap() of files required but not found
-
-   Due to [[mmap_write-only]].
-
-        +In file included from [...]/lib/Support/Process.cpp:85:0:
-        +[...]/lib/Support/Unix/Process.inc: In function 'unsigned int getColumns(int)':
-        +[...]/lib/Support/Unix/Process.inc:227:21: warning: enumeral and non-enumeral type in conditional expression [enabled by default]
-
-           225    // Try to determine the width of the terminal.
-           226    struct winsize ws;
-           227    if (ioctl(FileID, TIOCGWINSZ, &ws) == 0)
-
-        include/llvm/Config/*
-        Makefile.config
-
-TODO
-
-
-# Install
-
-    $ make VERBOSE=1 install 2>&1 | tee log_install
-
-This takes up around 400 MiB, and needs roughly 1 min on kepler.SCHWINGE and 12
-min on coulomb.SCHWINGE.
-
-
-## Analysis
-
-    $ toolchain/logs/process llvm install
-
-TODO
-
-
-# Testsuite
-
-    $ make -k VERBOSE=1 LIT_ARGS='-v --threads=1' check-all 2>&1 | tee log_test_check-all
-    $ make -k -C projects/test-suite/ 2>&1 | tee log_test_test-suite
-
-`LIT_ARGS=-v` is default for `VERBOSE=1`, but we want only one worker thread,
-for stable order and usable test output log.
-
-This needs roughly 10 min (`check-all`) + 150 min (test-suite) = 160 min on
-kepler.SCHWINGE and 45 min (`check-all`) + 165 min (test-suite) = 210 min on
-coulomb.SCHWINGE.
-
-
-## Analysis
-
-    $ toolchain/logs/process llvm test
-
-  * `LLVM :: CodeGen/X86/mult-alt-generic-i686.ll`
-
-    This one, as well as a really large set of test from the test-suite fail on
-    coulomb.SCHWINGE no matter whether a GNU/Hurd or GNU/Linux system is booted
-    -- so all these are specific to the Athlon XP processor, hopefully.
-
-  * `Clang :: Index/crash-recovery-modules.m`
-
-    Also fails on GNU/Linux.  Tested `--enable-optimized
-    --enable-expensive-checks --disable-threads --enable-debug-symbols
-    --enable-debug-runtime`.  [[!LLVM_bug 11974]].
-
-  * `Clang :: Misc/dev-fd-fs.c`
-
-        $ cat < [...]/test/Misc/dev-fd-fs.c | Release+Debug+Asserts+Checks/bin/clang -x c /dev/fd/0 -E
-        clang: error: no such file or directory: '/dev/fd/0'
-        clang: error: no input files
-
-    Compare to:
-
-        $ cat < [...]/test/Misc/dev-fd-fs.c | gcc -x c /dev/fd/0 -E
-        gcc: error: /dev/fd/0: (ipc/mig) bad request message ID
-        gcc: warning: '-x c' after last input file has no effect
-        gcc: fatal error: no input files
-        compilation terminated.
-
-    These work:
-
-        $ Release+Debug+Asserts+Checks/bin/clang -x c /dev/fd/0 -E < [...]/test/Misc/dev-fd-fs.c
-        [...]
-        int x;
-        $ gcc -x c /dev/fd/0 -E < [...]/test/Misc/dev-fd-fs.c
-        [...]
-        int x;
-
-        #include <stdio.h>
-        #include <unistd.h>
-        
-        int main(int argc, char *argv[])
-        {   
-          while (argc > 0)
-            {
-              int err;
-              char *f = argv[argc -1];
-        
-              err = access(f, F_OK);
-              if (err < 0)
-                printf("%s: %m\n", f);
-        
-              argc--;
-            }
-        
-          return 0;
-        }
-
-        $ ./a.out /dev/fd/0 < /dev/null
-        $ cat < /dev/null | ./a.out /dev/fd/0
-        /dev/fd/0: (ipc/mig) bad request message ID
-
-    `file_check_access` fails with `MIG_BAD_ID`, meaning this RPC is not
-    implemented.
-
-    The difference is that the former directly refers to the `/dev/null`
-    instance, whereas the latter goes through an intermediate pflocal instance.
-
-    Similarly:
-
-        $ stat /dev/fd/0 < /dev/null
-          File: `/dev/fd/0'
-          Size: 0               Blocks: 0          IO Block: 1048576 character special file
-        Device: 17h/23d Inode: 342820      Links: 1     Device type: 0,0
-        Access: (0666/crw-rw-rw-)  Uid: (    0/    root)   Gid: (    0/    root)
-        Access: 2012-11-27 16:03:19.000000000 +0100
-        Modify: 2012-11-27 16:03:19.000000000 +0100
-        Change: 2012-11-27 16:03:19.000000000 +0100
-         Birth: -
-        $ cat < /dev/null | stat /dev/fd/0
-          File: `/dev/fd/0'
-          Size: 0               Blocks: 0          IO Block: 65536  fifo
-        Device: 9h/9d   Inode: 0           Links: 0
-        Access: (0000/p---------)  Uid: (    0/    root)   Gid: (    0/    root)
-        Access: 1970-01-01 01:00:00.000000000 +0100
-        Modify: 1970-01-01 01:00:00.000000000 +0100
-        Change: 1970-01-01 01:00:00.000000000 +0100
-         Birth: -
-
-    `io_stat_request` fills in these values.    
-
-  * `Clang :: Tooling/clang-check-builtin-headers.cpp`
-
-    Fails: `fatal error: 'stddef.h' file not found`; succeeds when ran
-    manually.
-
-  * With `--enable-optimized --enable-expensive-checks --disable-threads
-    --enable-debug-symbols --enable-debug-runtime`, there are a few new FAILs
-    for both GNU/Linux and GNU/Hurd:
-
-      * `Clang :: Tooling/auto-detect-from-source-parent-of-cwd.cpp`
-
-      * `Clang :: Tooling/auto-detect-from-source-parent.cpp`
-
-      * `Clang :: Tooling/clang-check-autodetect-dir.cpp`
-
-    For all three, the `clang-check` invocation fails.  [[!LLVM_bug 15194]].
-
-  * Several tests are not considered on GNU/Hurd.
-
-        -PASS: Clang-Unit :: ASTMatchers/[...]/tschwinge/Horace_Silver.build/tools/clang/unittests/ASTMatchers/Release+Asserts/ASTMatchersTests/HasNameDeathTest.DiesOnEmptyName
-        -PASS: Clang-Unit :: ASTMatchers/[...]/tschwinge/Horace_Silver.build/tools/clang/unittests/ASTMatchers/Release+Asserts/ASTMatchersTests/HasNameDeathTest.DiesOnEmptyPattern
-        -PASS: Clang-Unit :: ASTMatchers/[...]/tschwinge/Horace_Silver.build/tools/clang/unittests/ASTMatchers/Release+Asserts/ASTMatchersTests/IsDerivedFromDeathTest.DiesOnEmptyBaseName
-        -PASS: LLVM-Unit :: ADT/[...]/tschwinge/Horace_Silver.build/unittests/ADT/Release+Asserts/ADTTests/APFloatTest.SemanticsDeath
-        -PASS: LLVM-Unit :: ADT/[...]/tschwinge/Horace_Silver.build/unittests/ADT/Release+Asserts/ADTTests/APFloatTest.StringDecimalDeath
-        -PASS: LLVM-Unit :: ADT/[...]/tschwinge/Horace_Silver.build/unittests/ADT/Release+Asserts/ADTTests/APFloatTest.StringDecimalExponentDeath
-        -PASS: LLVM-Unit :: ADT/[...]/tschwinge/Horace_Silver.build/unittests/ADT/Release+Asserts/ADTTests/APFloatTest.StringDecimalSignificandDeath
-        -PASS: LLVM-Unit :: ADT/[...]/tschwinge/Horace_Silver.build/unittests/ADT/Release+Asserts/ADTTests/APFloatTest.StringHexadecimalDeath
-        -PASS: LLVM-Unit :: ADT/[...]/tschwinge/Horace_Silver.build/unittests/ADT/Release+Asserts/ADTTests/APFloatTest.StringHexadecimalExponentDeath
-        -PASS: LLVM-Unit :: ADT/[...]/tschwinge/Horace_Silver.build/unittests/ADT/Release+Asserts/ADTTests/APFloatTest.StringHexadecimalSignificandDeath
-        -PASS: LLVM-Unit :: ADT/[...]/tschwinge/Horace_Silver.build/unittests/ADT/Release+Asserts/ADTTests/APIntTest.StringDeath
-        -PASS: LLVM-Unit :: Support/[...]/tschwinge/Horace_Silver.build/unittests/Support/Release+Asserts/SupportTests/LeakDetector.Death1
-        -PASS: LLVM-Unit :: Support/[...]/tschwinge/Horace_Silver.build/unittests/Support/Release+Asserts/SupportTests/ValueHandle.AssertingVH_Asserts
-
-        GTEST_HAS_DEATH_TEST utils/unittest/googletest/include/gtest/internal/gtest-port.h
-
-        -PASS: LLVM-Unit :: ADT/[...]/tschwinge/Horace_Silver.build/unittests/ADT/Release+Asserts/ADTTests/PackedVectorTest.SignedValues
-        -PASS: LLVM-Unit :: ADT/[...]/tschwinge/Horace_Silver.build/unittests/ADT/Release+Asserts/ADTTests/PackedVectorTest.UnsignedValues
-
-        EXPECT_DEBUG_DEATH utils/unittest/googletest/include/gtest/gtest-death-test.h
-
-  * Differences in test-suite, that are not evidently floating-point issues,
-    GNU/Linux vs. GNU/Hurd on coulomb.SCHWINGE:
-
-         gcc-4.6 -I/media/erich/home/thomas/tmp/llvm/tschwinge/Horace_Silver.build/projects/test-suite/SingleSource/UnitTests -I/media/erich/home/thomas/tmp/llvm/test-suite/tschwinge/Art_Blakey/SingleSource/UnitTests -I/home/thomas/tmp/llvm/tschwinge/Horace_Silver.build/projects/test-suite/../../../Horace_Silver/projects/test-suite/include -I../../include -I/home/thomas/tmp/llvm/tschwinge/Horace_Silver.build/include -I/home/thomas/tmp/llvm/tschwinge/Horace_Silver/include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -DNDEBUG  -O3  /media/erich/home/thomas/tmp/llvm/test-suite/tschwinge/Art_Blakey/SingleSource/UnitTests/2007-04-25-weak.c -lm -o Output/2007-04-25-weak.native  -lstdc++ 
-        +/media/erich/home/thomas/tmp/llvm/test-suite/tschwinge/Art_Blakey/SingleSource/UnitTests/2007-04-25-weak.c:3:1: warning: 'weak_import' attribute directive ignored [-Wattributes]
-        +/tmp/ccWGwKvo.o: In function `main':
-        +2007-04-25-weak.c:(.text.startup+0x7): undefined reference to `test_weak'
-        +collect2: ld returned 1 exit status
-        +make[2]: [Output/2007-04-25-weak.native] Error 1 (ignored)
-
-    On GNU/Linux, the clamav tests are compiled with `-DC_LINUX`.
-
-        +/media/erich/home/thomas/tmp/llvm/test-suite/tschwinge/Art_Blakey/MultiSource/Applications/lambda-0.1.3/lambda.cc:63:12: error: use of undeclared identifier 'MAXPATHLEN'
-        +                char buf[MAXPATHLEN+1];
-
-    ..., with follow-up failures.
-
-    `projects/test-suite/MultiSource/Applications/obsequi` is not at all
-    considered for GNU/Hurd.
-
-        +/media/erich/home/thomas/tmp/llvm/test-suite/tschwinge/Art_Blakey/MultiSource/Benchmarks/Olden/voronoi/newvor.c:178:25: warning: implicit declaration of function 'memalign' is invalid in C99 [-Wimplicit-function-declaration]
-        +    char* base = (char*)memalign(align_size, alloc_size);
-        +                        ^
-        +1 warning generated.
-
-        +/media/erich/home/thomas/tmp/llvm/test-suite/tschwinge/Art_Blakey/MultiSource/Benchmarks/Prolangs-C/archie-client/get_vdir.c:213:20: error: use of undeclared identifier 'MAXPATHLEN'
-        +                    char        l_name[MAX_DIR_LINESIZE];
-        +                                       ^
-        +/media/erich/home/thomas/tmp/llvm/test-suite/tschwinge/Art_Blakey/MultiSource/Benchmarks/Prolangs-C/archie-client/pprot.h:39:37: note: expanded from macro 'MAX_DIR_LINESIZE'
-        +#define        MAX_DIR_LINESIZE 160+MAXPATHLEN /* Max linesize in directory */
-        +                                    ^
-
-    ..., and several more.
diff --git a/open_issues/locking_issues.mdwn b/open_issues/locking_issues.mdwn
deleted file mode 100644
index 7086107b..00000000
--- a/open_issues/locking_issues.mdwn
+++ /dev/null
@@ -1,48 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012, 2013 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_hurd]]
-
-There are locking issues in the Hurd's libraries.
-
-[[!toc]]
-
-
-# Original [[community/GSoC]] Task Description
-
-[[!inline pages=community/gsoc/project_ideas/libdiskfs_locking feeds=no]]
-
-
-# ext2fs Deadlock
-
-[[ext2fs_deadlock]].
-
-
-# Formal Verification
-
-Methods of [[formal_verification]] should be applied to get an understanding of
-the behavior of the locking logic.  There are tools for formal
-verification/[[code_analysis]] that can likely help here.
-
-There is a [[!FF_project 278]][[!tag bounty]] on this task.
-
-
-# IRC, OFTC, #debian-hurd, 2012-12-15
-
-    <Steap> youpi: can you think of a locking error recently fixed in the
-      translators ? I'd like to try a Coccinelle script on a real-world example
-    <youpi> 0b6286a3c5eb86e3cca72d0840fc009855e4fba5 for instance
-    <youpi> or a60414ee7fdabb2bdfb17fe82b9a09f811bd2de0
-    <youpi> or b8082aab5049f753abd720a5ef6a113e2acef911
-    <Steap> thx, I think I might have caught a few double unlocks, I'll send
-      patches/bug reports this week-end
-
-[[!message-id "1355701890-29227-1-git-send-email-tipecaml@gmail.com"]].
diff --git a/open_issues/low_memory.mdwn b/open_issues/low_memory.mdwn
deleted file mode 100644
index 22470c65..00000000
--- a/open_issues/low_memory.mdwn
+++ /dev/null
@@ -1,113 +0,0 @@
-[[!meta copyright="Copyright © 2012 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_gnumach open_issue_glibc open_issue_hurd]]
-
-Issues relating to system behavior under memory pressure.
-
-[[!toc]]
-
-
-# [[gnumach_page_cache_policy]]
-
-
-# IRC, freenode, #hurd, 2012-07-08
-
-    <braunr> am i mistaken or is the default pager simply not vm privileged ?
-    <braunr> (which would explain the hangs when memory is very low)
-    <youpi> no idea
-    <youpi> but that's very possible
-    <youpi> we start it by hand from the init scripts
-    <braunr> actually, i see no way provided by mach to set that
-    <braunr> i'd assume it would set the property when a thread would register
-      itself as the default pager, but it doesn't
-    <braunr> i'll check at runtime and see if fixing helps
-    <youpi> thread_wire(host, thread, 1) ?
-    <youpi> ./hurd/mach-defpager/wiring.c:	kr =
-      thread_wire(priv_host_port,
-    <braunr> no
-    <braunr> look in cprocs.c
-    <braunr> iir
-    <braunr> iirc
-    <braunr> iiuc, it sets a 1:1 kernel/user mapping
-    <youpi> ??
-    <youpi> thread_wire, not cthread_wire
-    <braunr> ah
-    <braunr> right, i'm getting tired
-    <braunr> youpi: do you understand the comment in default_pager_thread() ?
-    <youpi> well, I'm not sure to know what external vs internal is
-    <braunr> i'm almost sure the default pager is blocked because of a relation
-      with an unprivlege thread
-    <braunr> +d
-    <braunr> when hangs happen, the pageout daemon is still running, waiting
-      for an event so he can continue
-    <braunr> it*
-
-    <braunr> all right, our pageout stuff completely sucks
-    <braunr> when you think the system is hanged, it's actually not
-    <pinotree> and what's happening instead?
-    <braunr> instead, it seems it's in a very complex resursive state which
-      ends in the slab allocator not being able to allocate kernel map entries
-    <braunr> recursive*
-    <braunr> the pageout daemon, unable to continue, progressively slows
-    <braunr> in hope the default pager is able to service the pageout requests,
-      but it's not
-    <braunr> probably the most complicated deadlock i've seen :)
-    <braunr> luckily !
-    <braunr> i've been playing with some tunables involved in waking up the
-      pageout daemon
-    <braunr> and got good results so far
-    <braunr> (although it's clearly not a proper solution)
-    <braunr> one thing the kernel lacks is a way to separate clean from dirty
-      pages
-    <braunr> this stupid kernel doesn't try to free clean pages first .. :)
-    <braunr> hm
-    <braunr> now i can see the system recover, but some applications are still
-      stuck :(
-    <braunr> (but don't worry, my tests are rather aggressive)
-    <braunr> what i mean by aggressive is several builds and various dd of a
-      few hundred MiB in parallel, on various file systems
-    <braunr> so far the file systems have been very resilient
-    <braunr> ok, let's try running the hurd with 64 MiB of RAM
-    <braunr> after some initial swapping, it runs smoothly :)
-    <braunr> uh ?
-    <braunr> ah no, i'm still doing my parallel builds
-    <braunr> although less
-    <braunr> gcc: internal compiler error: Resource lost (program as)
-    <braunr> arg
-    <braunr> lol
-    <braunr> the file system crashed under the compiler
-    <pinotree> too much memory required during linking? or ram+swap should have
-      been enough?
-    <braunr> there is a lot of swap, i doubt it
-    <braunr> the hurd is such a dumb and impressive system at the same time
-    <braunr> pinotree: what does this tell you ?
-    <braunr> git: hurdsig.c:948: post_signal: Unexpected error: (os/kern)
-      failure.
-    <pinotree> something samuel spots often during the builds of haskell
-      packages
-
-Probably also the *sigpost* case mentioned in [[!message-id
-"87bol6aixd.fsf@schwinge.name"]].
-
-    <braunr> actually i should be asking jkoenig
-    <braunr> it seems the lack of memory has a strong impact on signal delivery
-    <braunr> which is bad
-    <antrik> braunr: I have a vague recollection of slpz also saying something
-      about missing dirty page tracking a while back... I might be confusing
-      stuff though
-    <braunr> pinotree: yes it happens often during links
-    <braunr> which makes sense
-    <pinotree> braunr: "happens often" == "hurdsig.c:948: post_signal: ..."?
-    <braunr> yes
-    <pinotree> if you can reproduce it often, what about debugging it? :P
-    <braunr> i mean, the few times i got it, it was often during a link :p
-    <braunr> i'd rather debug the pageout deadlock :(
-    <braunr> but it's hard
diff --git a/open_issues/lsof.mdwn b/open_issues/lsof.mdwn
deleted file mode 100644
index 2651932d..00000000
--- a/open_issues/lsof.mdwn
+++ /dev/null
@@ -1,51 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2013 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]]."]]"""]]
-
-We don't have a `lsof` tool.  Perhaps we could cook something with having a
-look at which ports are open at the moment (as [[`portinfo`|hurd/portinfo]]
-does, for example)?
-
-
-# IRC, freenode, #hurd, 2013-10-16
-
-    <teythoon> braunr: there's something I've been working on, it's not yet
-      finished but usable
-    <teythoon> http://paste.debian.net/58266/
-    <teythoon> it graphs port usage
-    <teythoon> it's a bit heavy on the dependency-side though...
-    <braunr> but
-    <braunr> is it able to link rights from different ipc spaces ?
-    <teythoon> no
-    <teythoon> what do you mean exactly?
-    <braunr> know that send right 123 in task 1 refers to receive right 321 in
-      task 2
-    <braunr> basically, lsof
-    <braunr> i'm not sure it's possible right now, and that's what we'd really
-      need
-    <teythoon> does the kernel hand out this information?
-    <braunr> ^
-    <teythoon> right, I'm not sure it's possible either
-    <braunr> but a graph maker in less than 300 is cute :)
-    <braunr> 300 lines*
-    <teythoon> well, it leverages pymatplotlib or something, it needs half of
-      the pythonverse ;)
-    <braunr> lsof and pmap and two tools we really lack on the hurd
-    <teythoon> what does portinfo --translate=PID do?
-    <braunr> i guess it asks proc so that ports that refer to task actually
-      give useful info
-    <braunr> hml
-    <braunr> no
-    <braunr> doesn't make sense to give a pid in this case
-    <braunr> teythoon: looks like it does what we talked about
-    <teythoon> :)
-    <braunr> teythoon: the output looks a bit weird anyway, i think we need to
-      look at the code to be sure
-    <teythoon> braunr: this is what aptitude update looks like:
-      https://teythoon.cryptobitch.de/portmonitor/aptitude_portmonitor.svg
diff --git a/open_issues/ltrace.mdwn b/open_issues/ltrace.mdwn
deleted file mode 100644
index 615d2d86..00000000
--- a/open_issues/ltrace.mdwn
+++ /dev/null
@@ -1,27 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2013 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]]
-
-<http://www.ltrace.org/>
-
-
-# IRC, unknown channel, unknown date.
-
-    <youpi> it'd be good to have ltrace eventually
-    <youpi> rpctrace has too many issues to be usable
-    <youpi> (and a lot of them are hard to fix iirc)
-    <youpi> ltrace traces library calls
-    <youpi> in principle it should just work at the dynamic linker stage, so should be portable
-
-
-# See Also
-
-  * [[debugging]], [[profiling]]
diff --git a/open_issues/m4_vs_stack.mdwn b/open_issues/m4_vs_stack.mdwn
deleted file mode 100644
index c92cfb00..00000000
--- a/open_issues/m4_vs_stack.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-[[!meta copyright="Copyright © 2009 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_porting]]
-
-    m4 (1.4.13-1+hurd.2) unreleased; urgency=low
-    
-      * Drop stack overflow (checks/stackovf) check, test-c-stack and
-        test-c-stack2 checks, and /dev/null/ (test-open and test-fopen) checks.
-    
-     -- Samuel Thibault <samuel.thibault@ens-lyon.org>  Tue, 18 Aug 2009 20:54:30 +0000
-    
-    <youpi> that was a quick fix  (as not having m4 makes autoconf uninstallable, which is quite a problem)
-    <youpi> there's probably something wrong in the stack management of the Hurd, I haven't investigated
diff --git a/open_issues/mach-defpager_debugging.mdwn b/open_issues/mach-defpager_debugging.mdwn
deleted file mode 100644
index 33e717d9..00000000
--- a/open_issues/mach-defpager_debugging.mdwn
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012 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_gdb]]
-
-IRC, freenode, #hurd, 2011-11-10:
-
-    <mcsim> hello. Is there any way to debug mach-defpager? When I set
-      breakpoint to any function in it, pager never breaks.
-
-IRC, freenode, #hurd, 2011-11-11:
-
-    <mcsim> hello. I've read that hde tried to debug defpager and wrote some
-      patches for debugging defpager,  but I couldn't find them. Does anybody
-      know are these patches in public?
diff --git a/open_issues/mach-defpager_malloc_hook.mdwn b/open_issues/mach-defpager_malloc_hook.mdwn
deleted file mode 100644
index 2bbff75a..00000000
--- a/open_issues/mach-defpager_malloc_hook.mdwn
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!meta copyright="Copyright © 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]]
-
-*malloc hooks* are used in `[hurd]/mach-defpager/kalloc.c`.  But their use is
-deprecated (glibc 7d17596c198f11fa85cbcf9587443f262e63b616).
diff --git a/open_issues/mach-defpager_swap.mdwn b/open_issues/mach-defpager_swap.mdwn
deleted file mode 100644
index 6e4dc088..00000000
--- a/open_issues/mach-defpager_swap.mdwn
+++ /dev/null
@@ -1,41 +0,0 @@
-[[!meta copyright="Copyright © 2012 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_gnumach]]
-
-[[!toc]]
-
-
-# IRC, OFTC, #debian-hurd, 2012-06-16
-
-    <lifeng> I allocated a 5GB partition as swap, but hurd only found 1GB
-    <youpi> use 2GiB swaps only, >2Gib are not supported
-    <youpi> (and apparently it just truncates the size, to be investigated)
-
-## IRC, freenode, #hurd, 2013-10-25
-
-    <C-Keen> mkswap truncated the swap partiton to 2GB
-    <teythoon> :/
-    <teythoon> have you checked with 'free' ?
-    <teythoon> I have a 4gb swap partition on one of my boxes
-    <C-Keen> how did you create it?
-    <C-Keen> 2gig swap alright
-    <C-Keen> according to free
-
-
-# Swap Files
-
-## IRC, freenode, #hurd, 2013-10-25
-
-    <braunr> C-Keen: swapfiles are not to work very badly on the hurd
-    <braunr> swapfiles cause recursion and reservation problems on every system
-      but on the hurd, we just never took the time to fix the swap code
-
-Same issues as we generally would have with `hurd-defpager`?
diff --git a/open_issues/mach-defpager_vs_defpager.mdwn b/open_issues/mach-defpager_vs_defpager.mdwn
deleted file mode 100644
index f03bc67f..00000000
--- a/open_issues/mach-defpager_vs_defpager.mdwn
+++ /dev/null
@@ -1,33 +0,0 @@
-[[!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_gnumach open_issue_hurd]]
-
-IRC, freenode, #hurd, end of May/beginning of June 2010
-
-    <cfhammar> whats the difference between mach-defpager and defpager?
-    <cfhammar> i'm guessing defpager is a hurdish version that uses libstore
-      but was never finished or something
-    <cfhammar> found an interesting thread about it:
-      http://mirror.libre.fm/hurd/list/msg01232.html
-    <slpz> antrik: an interesting thread, indeed :-)
-    <pochu> slpz: btw is mach-defpager linked statically but not called
-      mach-defpager.static on purpose?
-    <slpz> antrik: also, I can confirm that mach-defpager needs a complete
-      rewrite ;-)
-    <slpz> pochu: I think the original defpager was launched by serverboot
-    <slpz> pochu: that could be the reason to have it static, like ext2fs
-    <slpz> and since there's no need to execute it again during the normal
-      operation of the system, they probably decided to not create a
-      dynamically linked version
-    <slpz> (but I'm just guessing)
-    <slpz> of perhaps they wanted to prevent mach-defpager from the need of
-      reading libraries, since it's used when memory is really scarce (guessing
-      again)
diff --git a/open_issues/mach_federations.mdwn b/open_issues/mach_federations.mdwn
deleted file mode 100644
index 50c939c3..00000000
--- a/open_issues/mach_federations.mdwn
+++ /dev/null
@@ -1,66 +0,0 @@
-[[!meta copyright="Copyright © 2012 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_documentation]]
-
-
-# IRC, freenode, #hurd, 2012-08-18
-
-    <braunr> well replacing parts of it is possible on the hurd, but for core
-      servers it's limited
-    <braunr> minix has features for that
-    <braunr> this was interesting too:
-      http://static.usenix.org/event/osdi08/tech/full_papers/david/david_html/
-    <braunr> lcc: you'll always have some kind of dependency problems which are
-      hard to solve
-    <savask> braunr: One my friend asked me if it's possible to run different
-      parts of Hurd on different computers and make a cluster therefore. So, is
-      it, at least theoretically?
-    <braunr> savask: no
-    <savask> Okay, then I guessed a right answer.
-    <youpi> well, theorically it's possible, but it's not implemented
-    <braunr> well it's possible everywhere :p
-    <braunr> there are projects for that on linux
-    <braunr> but it requires serious changes in both the protocols and servers
-    <braunr> and it depends on the features you want (i assume here you want
-      e.g. process checkpointing so they can be migrated to other machines to
-      transparently balance loads)
-    <lcc> is it even theoretically possible to have a system in which core
-      servers can be modified while the system is running? hm... I will look
-      more into it. just curious.
-    <savask> lcc: Linux can be updated on the fly, without rebooting.
-    <braunr> lcc: to some degree, it is
-    <braunr> savask: the whole kernel is rebooted actually
-    <braunr> well not rebooted, but restarted
-    <braunr> there is a project that provides kernel updates through binary
-      patches
-    <braunr> ksplice
-    <savask> braunr: But it will look like everything continued running.
-    <braunr> as long as the new code expects the same data structures and other
-      implications, yes
-    <braunr> "Ksplice can handle many security updates but not changes to data
-      structures"
-    <braunr> obviously
-    <braunr> so it's good for small changes
-    <braunr> and ksplice is very specific, it's intended for security updates,
-      ad the primary users are telecommunication providers who don't want
-      downtime
-    <antrik> braunr: well, protocols and servers on Mach-based systems should
-      be ready for federations... although some Hurd protocols are not clean
-      for federations with heterogenous architectures, at least on homogenous
-      clusters it should actually work with only some extra bootstrapping code,
-      if the support existed in our Mach variant...
-    <braunr> antrik: why do you want the support in the kernel ?
-    <antrik> braunr: I didn't say I *want* federation support in the
-      kernel... in fact I agree with Shapiro that it's probably a bad idea. I
-      just said that it *should* actually work with the system design as it is
-      now :-)
-    <antrik> braunr: yes, I said that it wouldn't work on heterogenous
-      federations. if all machines use the same architecture it should work.
diff --git a/open_issues/mach_migrating_threads.mdwn b/open_issues/mach_migrating_threads.mdwn
deleted file mode 100644
index 16547838..00000000
--- a/open_issues/mach_migrating_threads.mdwn
+++ /dev/null
@@ -1,118 +0,0 @@
-[[!meta copyright="Copyright © 2011, 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_gnumach]]
-
-<http://www.brynosaurus.com/pub/os/thread-migrate.pdf>
-
-  * [[microkernel/mach/memory_object/discussion]]
-
-  * [[resource_management_problems]]
-
-
-# IRC, freenode, #hurd, 2013-08-13
-
-In context of [[resource_management_problems]].
-
-    <braunr> and thread migration itself is something very confusing
-    <braunr> it's better to think of it as scheduling context inheritance
-    <teythoon> braunr: I read the paper I mentioned and then I wanted to find
-      the sources they modified
-    <teythoon> I failed
-    <teythoon> I hate scientific paper about software that fail to provide the
-      source code
-    <teythoon> that's not science imho b/c it's not reproducible
-    <braunr> i have some osf source code here
-    <braunr> i'll send it if you want
-    <teythoon> ah interesting
-    <braunr> but really, when you dive into it, thread migration is merely
-      scheduling context inheritance with kernel upcalls
-    <braunr> it's good
-    <teythoon> I searched for osf mach but google didn't turned up anything
-    <braunr> but it has nothing to do with resource accounting
-    <braunr> (well, it may hepl better account for cpu time actually)
-    <braunr> help*
-    <braunr> but that's all
-    <teythoon> why is that all? wouldn't that be transitive and could also be
-      used for i/o accounting?
-    <teythoon> also I tried to find alternative mach implementations
-    <teythoon> I wasn't terribly successful, and some sites are gone or
-      unmaintained for years :/
-    <braunr> we don't need that for io accountin
-    <braunr> g
-    <braunr> thread migration is a kernel property
-    <braunr> on mach with userspace drivers, io isn't
-    <braunr> mach should only control cpu and memory
-    <braunr> and you though you can account physical memory, you can't transfer
-      virtual memory accounting from one task to another
-    <teythoon> yes, but once all of those resources can be accounted to the
-      thread initiating whatever it needs doing, shouldn't that be much easier?
-    <braunr> teythoon: it's not required for that
-    <braunr> teythoon: keep in mind userspace sees activations
-    <braunr> in a thread migration enabled kernel, activations are what we
-      usually call threads, and threads are scheduling contexts
-    <teythoon> braunr: ok, so TM is not required for accounting, but surely
-      it's a good thing to have, no?
-    <braunr> teythoon: it's required for cpu accounting only
-    <braunr> which is very important :)
-    <braunr> if you look carefully, you'll see hurd servers are what use most
-      cpu
-    <braunr> there is now easy way to know which application actually uses the
-      server
-    <braunr> i personally tend to think more and more that servers *should*
-      impersonate clients
-    <braunr> TM (or rather, scheduling context inheritance) is one step
-    <braunr> it's not enough exactly because it doesn't help with resource
-      accounting
-    <braunr> teythoon:
-      ftp://ftp.mklinux.org/pub/mklinux-pre-R1/SRPMS/sources/osfmk.tar.gz
-
-
-# IRC, freenode, #hurd, 2013-09-02
-
-[[!taglink open_issue_documentation]]: move information to
-[[microkernel/mach/history]].
-
-    <teythoon> braunr: btw, I just noticed lot's of #ifdef MIGRATING_THREADS in
-      gnumach, so there was some work being done in that direction?
-    <braunr> gnumach is a fork of mach4
-    <braunr> at a stage whre migration was being worked on, yes
-    <teythoon> from what I've gathered, gnumach is the only surviving mach4
-      fork, right?
-    <braunr> yes
-    <braunr> well
-    <braunr> the macos x version is probably one too
-    <braunr> i don't know
-    <teythoon> oh? I read that it was based on mach3
-    <braunr> it is
-    <braunr> i can't tell how much of mach3 versus mach4 it has, and if it's
-      relevant at all
-    <teythoon> and the osfmach, was that also based on mach4?
-    <braunr> yes
-    <teythoon> ok, fair enough
-    <braunr> that's why i think macos x is based on it too
-    <braunr> i initially downloaded osfmach sources to see an example of how
-      thread migration was used from userspace
-    <braunr> and they do have a special threading library for that
-
-
-# IRC, freenode, #hurd, 2014-02-18
-
-    <teythoon> has anyone here ever tried to enable the thread migration bits
-      in gnumach to see where things break and how far that effort has been
-      taken ?
-    <braunr> without proper userspace support, i don't see how this could work
-    <teythoon> but is the kernel part finished or close to being finished ?
-    <braunr> no idea
-    <braunr> i don't think it is
-    <braunr> i didn't see much code related to that feature, and practically
-      none that looked like what the paper described
-    <braunr> some structures, but not used
diff --git a/open_issues/mach_on_top_of_posix.mdwn b/open_issues/mach_on_top_of_posix.mdwn
deleted file mode 100644
index a3e47685..00000000
--- a/open_issues/mach_on_top_of_posix.mdwn
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012 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]]."]]"""]]
-
-[[!meta title="Mach on Top of POSIX"]]
-
-[[!tag open_issue_gnumach]]
-
-At the beginning of the 2000s, there was a *Mach on Top of POSIX* port started
-by John Edwin Tobey.  Status unknown.  Ask [[tschwinge]] for the source code.
-
-See also [[implementing_hurd_on_top_of_another_system]].
diff --git a/open_issues/mach_shadow_objects.mdwn b/open_issues/mach_shadow_objects.mdwn
deleted file mode 100644
index 0669041a..00000000
--- a/open_issues/mach_shadow_objects.mdwn
+++ /dev/null
@@ -1,24 +0,0 @@
-[[!meta copyright="Copyright © 2012 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_gnumach]]
-
-See also [[gnumach_vm_map_entry_forward_merging]].
-
-
-# IRC, freenode, #hurd, 2012-11-16
-
-    <mcsim> hi. do I understand correct that following is true: vm_object_t a;
-      a->shadow->copy == a;?
-    <braunr> mcsim: not completely sure, but i'd say no
-    <braunr> but mach terminology isn't always firm, so possible
-    <braunr> mcsim: apparently you're right, although be careful that it may
-      not be the case *all* the time
-    <braunr> there may be inconsistent states
diff --git a/open_issues/mach_tasks_memory_usage.mdwn b/open_issues/mach_tasks_memory_usage.mdwn
deleted file mode 100644
index 7a7a77ce..00000000
--- a/open_issues/mach_tasks_memory_usage.mdwn
+++ /dev/null
@@ -1,175 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2013 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_documentation open_issue_gnumach]]
-
-
-# IRC, freenode, #hurd, 2011-01-06
-
-    <antrik> hm, odd... vmstat tells me that ~500 MiB of RAM are in use; but
-      the sum of all RSS is <300 MiB... what's the rest?
-    <braunr> kernel memory ?
-    <braunr> the zone allocator maybe
-    <braunr> or the page cache simply
-    <antrik> braunr: which page cache? AIUI, caches are implemented by the
-      individual filesystem servers -- in which case any memory used by them
-      should show up in RSS
-    <antrik> also, gnumach is listed among other tasks, so I'd assume the
-      kernel memery also to be accounted for
-    <braunr> antrik: no, the kernel maintains a page cache, very similar to
-      what is done in Linux, and almost the same as in FreeBSD
-    <braunr> the file system servers are just backing stores
-    <braunr> the RSS for the gnumach tasks only includes kernel memory
-    <braunr> I don't think the page cache is accounted for
-    <braunr> because it's not really kernel memory, it's a cache of user space
-      memory
-    <antrik> apparently my understanding of Mach paging is still (or again?)
-      rather incomplete :-(
-    <antrik> BTW, is there any way to find out how much anonymous memory a
-      process is using? the "virtual" includes discardable mappings, and is
-      thus not very helpful...
-    <antrik> (that applies to Linux as well though)
-    <braunr> can you provide an example of the output of vmstat please ?
-    <braunr> I don't have a Hurd VM near me
-    <antrik> olaf@alien:~$ vmstat
-    <antrik> pagesize:          4K
-    <antrik> size:            501M
-    <antrik> free:           6.39M
-    <antrik> active:          155M
-    <antrik> inactive:        310M
-    <antrik> wired:          29.4M
-    <antrik> zero filled:    15.3G
-    <antrik> reactivated:     708M
-    <antrik> pageins:        3.43G
-    <antrik> pageouts:       1.55G
-    <antrik> page faults: 26844574
-    <antrik> cow faults:   3736174
-    <antrik> memobj hit ratio: 92%
-    <antrik> swap size:       733M
-    <antrik> swap free:       432M
-    <antrik> interesting... closing a single screen window temporarily raises
-      the "free" value by almost 10 MB
-    <antrik> I guess bash is rather hungry nowadays ;-)
-    <braunr> antrik: I guess the only way is using pmap or looking into
-      /proc/<pid>/maps
-    <braunr> but it won't give you the amount of physical memory used by
-      anonymous mappings
-    <antrik> nah, I don't even want that... just like to know how much memory
-      (RAM+swap) a process is really using
-    <braunr> antrik: then the RSS field is what you want
-    <antrik> OTOH, anonymous doesn't include program code or other actively
-      used mappings... so not very useful either
-    <antrik> nah, RSS doesn't count anything that is in swap
-    <braunr> well
-    <braunr> don't you have a SWAP column ?
-    <braunr> hm
-    <braunr> i guess not
-    <braunr> antrik: why do you say it doesn't include other actively used
-      mappings ?
-    <braunr> antrik: and the inclusion of program code also depends on the
-      implementation of the ELF handler
-    <braunr> I don't know how the hurd does that, but some ELF loaders use
-      anonymous memory for the execution view
-    <antrik> well, if a program maps a data file, and regularily accesses parts
-      of the file, they won't occupy physical RAM all the time (and show up in
-      RSS), but they are not anonymous mappings. similar to program code
-    <braunr> then this anonymous memory is shared by all processes using that
-      code
-    <antrik> oh, interesting
-    <antrik> is it really a completely distinct mapping, rather than just COW?
-    <braunr> the first is
-    <braunr> others are COW
-    <antrik> so if a program loads 200 MB of libraries, they are all read in on
-      startup, and occupy RAM or swap subsequently, even if most of the code is
-      never actually run?...
-    <kilobug> library code should be backed by the library file on disk, not be
-      swap
-    <braunr> depends on the implementation
-    <braunr> I guess most use the file system backend
-    <braunr> but in the Hurd, ext2fs.static and ld.so.1 use anonymous memory
-    <braunr> (that's the case for another reason, still, I don't think the
-      report in top/ps clearly indicates that fact)
-    <kilobug> braunr: yeah for bootstrapping issues, makes sense
-    <braunr> it may also depends on the pic/pie options used when building
-      libraries
-
-
-# IRC, freenode, #hurd, 2011-07-24
-
-    < braunr> the panic is probably due to memory shortage
-    < braunr> so as antrik suggested, use more swap
-    < antrik> gg0: you could run "vmstat 1" in another terminal to watch memory
-      usage
-    < antrik> that way we will know for sure whether it's related
-    < braunr> antrik: it's trickier than that
-    < braunr> it depends if the zones used are pageable
-    < antrik> braunr: well, if it's a zone map exhaustion, then the swap size
-      won't change anything?...
-    < braunr> antrik: in this case no, but if the zone is pageable and the
-      pager (backing anonymous memory) refuses to create memory because it
-      estimates it's full (all swap space is reserved), it will fail to
-    < braunr> too
-    < braunr> but i don't think there are much pageable zones in the kernel
-    < antrik> yes, but in that case we can see the exhaustion in vmstat :-)
-    < braunr> many*
-    < braunr> i'm not sure
-    < braunr> reserved swap space doesn't mean it's used
-    < braunr> that's one of the major changes in freebsd 4 or 5 i was
-      mentioning
-    < antrik> if it's reserved, it wouldn't show up as "free", would it?...
-    < braunr> (btw, it's also what makes anonymous memory merging so hard)
-    < braunr> yes it would
-    < braunr> well, it could, i'm not sure
-    < braunr> anonymous memory is considered as a file
-    < braunr> one big file filled with zeroes, which is the swap partition
-    < braunr> when you allocate pageable anonymous memory, a part of this
-      "file" is reserved
-    < braunr> but i don't know if the reported number if the reserved
-      (allocated) space, or used (actually containing data)
-    < braunr> is*
-    < braunr> i also suspect wired allocations can fail because of a full swap
-      (because the kernel is unable to make free pages)
-    < braunr> in this case vmstat will show it
-    < antrik> what does it matter whether there is data there or not? if it's
-      reserved, it's not free. if it behaves differently, I'd consider that a
-      serious bug
-    < braunr> maybe the original developers intended to monitor its actual
-      usage
-    < braunr> antrik: i've just checked how the free count gets updated, and it
-      looks like it is on both seqnos_memory_object_data_initialize and
-      seqnos_memory_object_data_write
-    < braunr> antrik: so i guess reserved memory is accounted for
-
-
-# IRC, freenode, #hurd, 2013-01-12
-
-    <tschwinge> darnassus linking clang: 600 MiB swap in use and 22 MiB RAM
-      free, of 2 GiB.  But ps shows a RSS of just 100 MiB, huh?
-    <tschwinge> Getting "better": near the end of the link, nearly 1 GiB swap
-      in use, and 200 KiB (!) RAM free.
-    <sobhan> can hurd have more than 1GB of ram ?
-    <tschwinge> And then it completed; 75 MiB swap in use, and 1.2 GiB RAM
-      free.
-    <braunr> tschwinge: unless i'm mistaken, mach uses the legacy "swapping"
-      bsd mechanism 
-    <braunr> tschwinge: i.e. when it swaps a process, it swaps all of it
-    <braunr> tschwinge: the rest is probably one big anonymous vm object
-      containing the process space
-    <braunr> cached objects aren't currently well accounted
-    <braunr> (well, since youpi got my page cache patches in, they are, but
-      procfs isn't yet modified to report them)
-    <braunr> tschwinge: right, i'm currently looking at the machine and it
-      doesn't add up, i suppoe there are some big files still in the cache
-    <braunr> ah, git packed objects :p
-    <braunr> and a few llvm .a/.so/executable files too
-    <braunr> and since they're probably targets, they're built last, which
-      explains why they're retained in the cache for a while
-
-[[microkernel/mach/message/msgh_id]] (why on *that* page?).
diff --git a/open_issues/mach_vm_pageout.mdwn b/open_issues/mach_vm_pageout.mdwn
deleted file mode 100644
index dac7fe28..00000000
--- a/open_issues/mach_vm_pageout.mdwn
+++ /dev/null
@@ -1,19 +0,0 @@
-[[!meta copyright="Copyright © 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_gnumach]]
-
-IRC, freenode, #hurd, 2011-09-09
-
-    <slpz> It's amazing how broken some parts of Mach's VM are
-    <slpz> currently, it doesn't even keep track of the number of external
-      pages in the lists
-    <slpz> and vm_pageout_scan produces a hang if want_pages == FALSE (which
-      never is, because vm_page_external_count is always 0)
diff --git a/open_issues/magic_translator_machtype.mdwn b/open_issues/magic_translator_machtype.mdwn
deleted file mode 100644
index 3ae16cf0..00000000
--- a/open_issues/magic_translator_machtype.mdwn
+++ /dev/null
@@ -1,28 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2010, 2013 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]]."]]"""]]
-
-[[!meta title="/hurd/magic machtype"]]
-
-[[!tag open_issue_hurd open_issue_glibc]]
-
-    tschwinge@clubber:~ $ settrans -ca machtype /hurd/magic machtype
-    tschwinge@clubber:~ $ l mach<TAB>Connection to clubber.bddebian.com closed.
-    thomas@dirichlet:~ $ ssh clubber
-    Warning: Permanently added '[clubber.bddebian.com]:2251' (RSA) to the list of known hosts.
-    Last login: Tue Dec 30 08:52:58 2008 from dslb-084-057-196-016.pools.arcor-ip.net
-    tschwinge@clubber:~ $ cat machtype
-    Segmentation fault
-    tschwinge@clubber:~ $ l machtype
-    Segmentation fault
-    tschwinge@clubber:~ $ l mach<TAB>Connection to clubber.bddebian.com closed.
-
-Justus: This is most likely just the shell not handling SIGLOST, see
-[[!GNU_Savannah_bug 19479]].
diff --git a/open_issues/managed_runtime_initiative.mdwn b/open_issues/managed_runtime_initiative.mdwn
deleted file mode 100644
index 7a880beb..00000000
--- a/open_issues/managed_runtime_initiative.mdwn
+++ /dev/null
@@ -1,72 +0,0 @@
-[[!meta copyright="Copyright © 2013 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_gnumach]]
-
-
-# IRC, freenode, #hurd, 2013-04-02
-
-    <psockali> hi again, maybe someone has some metrics 
-    <psockali> is mprotect / munprotect faster in hurd then in linux ?
-    <pinotree> ?
-    <psockali> can i protected a memory page against write access in hurd 
-    <psockali> and if so, is it a fast operation ?
-    <youpi> you can, I never measured, but it's probably the same cost as in
-      linux
-    <youpi> I don't see why it would be different, as it boils down to the same
-      x86 trick
-    <psockali> but i suppose it is part of the mach kernel doing the protection
-      and not part of the unix layer ?
-    <youpi> it is
-    <youpi> the unix layer doesn't have mm control
-    <youpi> it has to ask the kernel
-    <braunr> it's slower on mach, as it's less optimized because of historical
-      reasons
-    <braunr> but that's about it
-    <youpi> less optimized, how so?
-    <braunr> well, more entry fragmentation
-    <youpi> in the end you mark the page table and flush the tlb
-    <braunr> yes
-    <braunr> the high level virtual memory layer is a bit slower
-    <youpi> but fragmentation doesn't come into play it you just have one
-      memory object, does it?
-    <braunr> it does, as it's about memory areas, not objects
-    <braunr> the object is merely a backing store
-    <braunr> protection, inheritance, copy on write are all area (vm_map_entry)
-      attributes
-    <braunr> also, some operations affect all the address spaces where a
-      physical page is mapped
-    <braunr> although i think linux does the same thing as mach/bsd now
-    <youpi> but mprotect/munprotect doesn't, does it?
-    <braunr> no
-    <braunr> or perhaps by side effect, in some situations, i'm not sure
-    <braunr> i think it depends if the memory is shared between processes, but
-      i don't remember the details and can't think of a proper example right
-      now
-    <braunr> but anyway, "slower" here is negligible unless address spaces are
-      really huge and filled with lots of map entries
-    <braunr> psockali: why do you ask ?
-    <psockali> can i post a link here ?
-    <braunr> about what ?
-    <psockali> it's regarding azul / managed runtime initiative 
-    <psockali> a GC for java
-    <braunr> why not
-    <braunr> although i don't see the point for now :)
-    <psockali> they have a custom MM management module for their GC as linux
-      kernel modul
-    <psockali> and i was wondering if mach would be any faster then linux in
-      that aspect
-    <psockali>
-      http://stackoverflow.com/questions/3358545/whats-actually-in-the-managed-runtime-initiatives-kernel-patches-and-jvm
-    <braunr> psockali: generally speaking, mach is slower than linux because of
-      its age and the fact it didn't receive as much attention and
-      microoptimization as linux did
-    <braunr> psockali: about this article, there is no reason mach would be
-      faster
diff --git a/open_issues/memory_object_model_vs_block-level_cache.mdwn b/open_issues/memory_object_model_vs_block-level_cache.mdwn
deleted file mode 100644
index 22db9b86..00000000
--- a/open_issues/memory_object_model_vs_block-level_cache.mdwn
+++ /dev/null
@@ -1,514 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 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_documentation open_issue_hurd open_issue_gnumach]]
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2012-02-14
-
-    <slpz> Open question: what do you think about dropping the memory object
-      model and implementing a simple block-level cache?
-
-[[microkernel/mach/memory_object]].
-
-    <kilobug> slpz: AFAIK the memory object has more purpose than just cache,
-      it's allow used for passing chunk of data between processes, handling
-      swap (which similar to cache, but still slightly different), ...
-    <slpz> kilobug: user processes usually make their way to data with POSIX
-      operations, so memory objects are only needed for mmap'ed files
-    <slpz> kilobug: and swap can be replaced for an in-kernel system or even
-      could still use the memory object
-    <braunr> slpz: memory objects are used for the page cache
-    <kilobug> slpz: translators (especially diskfs based) make heavy use of
-      memory objects, and if "user processes" use POSIX semantics, Hurd process
-      (translators, pagers, ...) shouldn't be bound to POSIX
-    <slpz> braunr: and page cache could be moved to a lower level, near to the
-      devices
-    <braunr> not likely
-    <braunr> well, it could, but then you'd still have the file system overhead
-    <slpz> kilobug: but the use of memory objects it's not compulsory, you can
-      easily write a fs translator without implementing memory objects at all
-      (except to mmap)
-    <braunr> a unified buffer/VM cache as all modern systems have is probably
-      the most efficient approach
-    <slpz> braunr: I agree. I want to look at *BSD/Linux vfs systems to seem
-      how much cache policy depends on the filesystem
-    <slpz> braunr: Are you aware of any good papers on this matter?
-    <braunr> netbsd UVM, the linux virtual memory system
-    <braunr> both a bit old bit still relevant
-    <slpz> braunr: Thanks.
-    <slpz> the problem in our case is that having FS and cache information at
-      different contexts (kernel vs. translator), I find hard to coordinate
-      them.
-    <slpz> that's why I though about a block-level cache that GNU Mach could
-      manage by itself
-    <slpz> I wonder how QNX deals with this
-    <braunr> the point of having a simple page cache is explicitely about not
-      caring if those pages are blocks or files or whatever
-    <braunr> the kernel (at least, mach) normally has all the accounting
-      information it needs to implement its cache policy
-    <braunr> file system translators shouldn't cache much
-    <braunr> the pager interface could be refined, but it looks ok to me as it
-      is
-    <slpz> Mach has the accounting info, but it's not able to purge the cache
-      without coordination with translators
-    <braunr> which is normal
-    <slpz> And this is a big problem when memory pressure increases, as it
-      doesn't know for sure when memory is going to be freed
-    <braunr> Mach flushes its cache when it decides to, and sends back dirty
-      pages if needed by the pager
-    <braunr> that's the case with every paging implementation
-    <braunr> the main difference is security with untrusted pagers
-    <braunr> but that's another issue
-    <slpz> but in a monolithic implementation, the kernel is able for force a
-      chunk of cache memory to be freed without hoping for other process to do
-      the job
-    <braunr> that's not true
-    <braunr> they're not process, they're threads, but the timing issue is the
-      same
-    <braunr> see pdflush on linux
-    <slpz> no, it isn't.
-    <braunr> when memory is scarce, threads that request memory can either wait
-      or immediately fail, and if they wait, they're usually woken by one of
-      the vm threads once flushing is done
-    <slpz> a kernel thread can access all the information in the kernel, and
-      synchronization is pretty easy.
-    <braunr> on mach, synchronization is done with messages, that's even easier
-      than shared kernel locks
-    <slpz> with processes in different spaces, resource coordination becomes
-      really difficult
-    <braunr> and what kind of info would an external pager need when simply
-      asked to take back its dirty pages
-    <braunr> what resources ?
-    <slpz> just take a look at the thread storm problem when GNU Mach needs to
-      clean a bunch of pages
-    <braunr> Mach is big enough to correctly account memory
-    <braunr> there can be thread storms on monolithic systems
-    <braunr> that's a Mach issue, not a microkernel issue
-    <braunr> that's why linux limits the number of pdflush thread instances
-    <slpz> Mach can account memory, but can't assure when be freed by any
-      means, in a lesser degree than a monolithic system
-    <braunr> again i disagree
-    <braunr> no system can guarantee when memory will be freed with paging
-    <slpz> a block level cache can, for most situations
-    <braunr> slpz: why ?
-    <braunr> slpz: or how i mean ?
-    <slpz> braunr: with a block-level page cache, GNU Mach should be able to
-      flush dirty pages directly to the underlaying device without all the
-      complexity and resource cost involved in a m_o_data_return message. It
-      can also throttle the rate at which pages are being cleaned, and do all
-      this while blocking new page allocations to deal with memory exhaustion
-      cases.
-    <slpz> braunr: in the current state, when cleaning dirty pages, GNU Mach
-      sends a bunch on m_o_data_return to the corresponding pagers, hoping they
-      will do their job as soon and as fast as possible.
-    <slpz> memory is not really freed, but transformed from page cache to
-      anonymous memory pertaining to the corresponding translator
-    <slpz> and GNU Mach never knows for sure when this memory is released, if
-      it ever is.
-    <slpz> not being able to flush dirty pages synchronously is a big problem
-      when you need to throttle memory usage
-    <slpz> and needing allocating more memory when you're trying to free (which
-      is the case for the m_o_data_return mechanism) makes the problem even
-      worse
-    <braunr> your idea of a block level cache means in kernel block drivers
-    <braunr> that's not the direction we're taking
-    <braunr> i agree flushing should be a synchronous process, which was one of
-      the proposed improvements in the thread migration papers
-    <braunr> (they didn't achieve it but thought about it for future works, so
-      that the thread at the origin of the fault would handle it itself)
-    <braunr> but it should be possible to have kernel threads similar to
-      pdflush and throttle flush requests too
-    <braunr> again, i really think it's a mach bug, and having a buffer cache
-      would be stepping backward
-    <braunr> the real design issue is allocating memory while trying to free
-      it, yes
-    <slpz> braunr: thread migration doesn't apply to asynchronous IPC, and the
-      entire paging mechanism is implemented this way
-    <slpz> in fact, trying to do a synchronous m_o_data_return will trigger a
-      deadlock for sure
-    <slpz> to achieve synchronous flushing with translators, the entire paging
-      model must be redesigned
-    <slpz> It's true that I'm not very confident of the viability of user space
-      drivers
-    <slpz> at least, not for every device
-    <slpz> I know this is against the current ideas for most ukernel designs,
-      but if we want to achieve real work functionality, I think some
-      sacrifices must be done. Or at least a reasonable compromise.
-    <braunr> slpz: thread migration for paging requests implies synchronous
-      RPC, we don't care much about the IPC layer there
-    <braunr> and it requires large changes of the VM code in addition, yes
-    <braunr> let's not talk about this, we don't have thread migration anyway
-      :p
-    <braunr> except the allocation-on-free-path issue, i really don't see how
-      the current pager interface or the page cache creates problems wrt
-      flushing ..
-    <braunr> monolithic systems also have that problem, with lower impacts
-      though, but still
-    <slpz> braunr: because as it doesn't know when memory is really freed, 1)
-      it just blindly sends a bunch of m_o_data_return to the pagers, usually
-      overloading them (causing thread storms), and 2) it can't properly
-      throttle new page requests to deal with resource exhaustion
-    <braunr> it does know when memory is really freed
-    <braunr> and yes, it blindly sends a bunch of requests, they can and should
-      be trottled
-    <slpz> but dirty pages freed become indistinguishable from common anonymous
-      chunks released, so it doesn't really know if page flushes are really
-      working or not (i.e. doesn't know how fast a device is processing write
-      requests)
-    <braunr> memory is freed when the pager deallocates it
-    <braunr> the speed of the operation is irrelevant
-    <braunr> no system can rely on disk speed to guarantee correct page flushes
-    <braunr> disk or anything else
-    <slpz> requests can't be throttled if Mach doesn't know when they are being
-      processed
-    <braunr> it can easily know it
-    <braunr> they are processed as soon as the request is sent from the kernel
-    <braunr> and processing is done when the pager acknowledges the end of the
-      flush
-    <braunr> memory backing the flushed pages should be released before
-      acknowleding that to avoid starting new requests too soon
-    <slpz> AFAIK pagers doesn't acknowledge the end of the flush
-    <braunr> well that's where the interface should be refined
-    <slpz> Mach just sends the m_o_data_return and continues on its own
-    <braunr> that's why flushing should be synrhconous
-    <braunr> are you sure about that however ?
-    <slpz> so the entire paging system needs a new design... :)
-    <slpz> pretty sure
-    <braunr> not a new design ..
-    <braunr> there is m_o_supply_completed, i don't see how difficult it would
-      be to add m_o_data_return_completed
-    <braunr> it's not a small change, but not a difficult one either
-    <braunr> i'm more worried about the allocation problem
-    <braunr> the default pager should probably be wired in memory
-    <braunr> maybe others
-    <slpz> let's suppose a case in which Mach needs to free memory due to an
-      increase in its pressure. vm_pageout_daemon starts running, clean pages
-      are freed easily, but for each dirty one a m_o_data_return in sent. 1)
-      when should this daemon stop sending m_o_data_return and start waiting
-      for m_o_data_return_completed? 2) what happens if the translator needs to
-      read new blocks to fulfill a write request (pretty common in ext2fs)?
-    <braunr> it should stop after an arbitrary limit is reached
-    <braunr> a reasonable one
-    <braunr> linux limits the number of pdflush threads for that reason as i
-      mentioned (to 8 iirc)
-    <braunr> the problem of reading blocks while flushing is what i'm worried
-      about too, hence the need to wire that code
-    <braunr> well, i'm nto sure it's needed
-    <braunr> again, a reasonable about of free memory should be reserved for
-      that at all times
-    <slpz> but the work for pdflush seems to be a lot easier, as it only deals
-      directly with block devices (if I understood it correctly, I just started
-      looking at it).
-    <braunr> i don't know how other systems compute that, but this is how they
-      seem to do as well
-    <braunr> no, i don't think so
-    <slpz> well, I'll try to invest a few days understanding how pdflush work,
-      to see if some ideas can be borrowed for Hurd
-    <braunr> iirc, freebsd has thresholds in percent for each part of its cache
-      (active, inactive, free, dirty)
-    <slpz> but I still think simple solutions work better, and using the memory
-      object for page cache is tremendously complex.
-    <braunr> the amount of free cache pages is generally sufficient to
-      guarantee much memory can be released at once if needed, without flushing
-      anything
-    <braunr> yes but that's the whole point of the Mach VM
-    <braunr> and its greatest advance ..
-    <slpz> what, memory objects?
-    <braunr> yes
-    <braunr> using physical memory as a cache for anything, not just block
-      buffers
-    <slpz> memory objects work great as a way to provide a shared image of
-      objects between processes, but as page cache they are an overkill (IMHO).
-    <slpz> or, at least, in the way we're using them
-    <braunr> probably
-    <braunr> http://lwn.net/Articles/326552/
-    <braunr> this can help udnerstand the problems we may have without better
-      knowledge of the underlying devices, yes
-    <braunr> (e.g. not being able to send multiple requests to pagers that
-      don't share the same disk)
-    <braunr> slpz: actually i'm not sure it's that overkill
-    <braunr> the linux vm uses struct vm_file to represent memory objects iirc
-    <braunr> there are many links between that structure and some vfs related
-      subsystems
-    <braunr> when a system very actively uses the page cache, the kernel has to
-      maintain a lot of objects to accurately describe the cache content
-    <braunr> you could consider this overkill at first too
-    <braunr> the mach way of doing it just implies some ipc messages instead of
-      function calls, it's not that overkill for me
-    <braunr> the main problems are recursion (allocation while freeing,
-      handling page faults in order to handle flushes, that sort of things)
-    <braunr> struct file and struct address_space actually
-    <braunr> slpz: see struct address_space, it contains a set of function
-      pointers that can help understanding the linux pager interface
-    <braunr> they probably sufferred from similar caveats and worked around
-      them, adjusting that interface on the way
-    <slpz> but their strategy makes them able to treat the relationship between
-      the page cache and the block devices in a really simple way, almost as a
-      traditional storage cache.
-    <slpz> meanwhile on Mach+pager scenario, the relationship between a block
-      in a file and its underlying storage becomes really blurry
-    <slpz> this is a huge advantage when flusing out data, specially when
-      resources are scarce
-    <slpz> I think the idea of using abstract objects for page cache, loses a
-      bit the point that we just want to avoid accessing constantly to a slow
-      device
-    <slpz> and breaking the tight relationship between the device and its
-      cache, makes things a lot harder
-    <slpz> this also manifest itself when flushing clean pages, as things like
-      having an static maximum for cached memory objects
-    <slpz> we shouldn't care about the number of objects, we just need to
-      control the number of pages
-    <slpz> but as we need the pager to flush pages, we need to keep alive a lot
-      of control ports to them
-    <mcsim> slpz: When mo_data_return is called, once the memory manager no
-      longer needs supplied data, it should be deallocated using
-      vm_deallocate. So this way pagers acknowledges the end of flush.
-
-
-# IRC, freenode, #hurd, 2013-08-26
-
-    < Spyro> Ok, so
-    < Spyro> idiot question:  in a nutshell, what is a memory object?
-    < Spyro> and how is swapping/paging handled?
-    < braunr> Spyro: a memory object is how the virtual memory system views a
-      file
-    < braunr> so it's a sequence of bytes with a length
-    < braunr> "swapping" is just a special case of paging that applies to
-      anonymous objects
-    < braunr> (which are named so because they're not associated with a file
-      and have no name)
-    < Spyro> Who creates a memory object, and when?
-    < braunr> pagers create memory objects when needed, e.g. when you open a
-      file
-    < Spyro> and this applies both to mmap opens as well as regular I/O opens
-      as in for read() and write()?
-    < braunr> basically, all file systems capable of handling mmap requests
-      and/or caching in physical memory are pagers
-    < braunr> yes
-    < braunr> read/write will go through the page cache when possible
-    < Spyro> and who owns the page cache?
-    < Spyro> also, who decides what pages ot evict to swap/file if physical
-      memory gets tight?
-    < braunr> the kernel
-    < braunr> that's one of the things that make mach a hybrid
-    < Spyro> so the kernel owns the page cage?
-    < Spyro> ...fml
-    < Spyro> cache!
-    < braunr> yes
-
-
-## IRC, freenode, #hurd, 2013-08-27
-
-    < Spyro> so braunr:  So, who creates the memory object, and how does it get
-      populated?
-    < Spyro> and how does a process accessing a file get hooked up to the
-      memory object?
-    < braunr> Spyro: i told you, pagers create memory objects
-    < braunr> memory objects are how the VM system views files, so they're
-      populated from the content of files
-    < braunr> either true files or virtual files such as in /proc
-    < braunr> Spyro: processes don't directly access memory objects unless
-      memory mapping them with vm_map()
-    < braunr> pagers (basically = file systems) do
-    <Spyro> ok, so how is a pager/fs involved in handling a fault?
-
-
-## IRC, freenode, #hurd, 2013-08-28
-
-    <braunr> Spyro: each object is linked to a pager
-    <braunr> Spyro: when a fault occurs, the kernel looks up the VM map (kernel
-      or a user one), and the address in this map, then the map entry, checks
-      access and lots of other details
-    <Spyro> ok, so it's pager -> object -> vmem
-    <Spyro> ?
-    <braunr> Spyro: then finds the object mapped at that address (similar to
-      how a file is mapped with mmap)
-    <braunr> from the object, it finds the pager
-    <Spyro> ok
-    <braunr> and asks the pager about the data at the appropriate offset
-    <Spyro> so how does a user process do normal file I/O?  is faulting just a
-      special case of it?
-    <braunr> it's completely separate
-    <Spyro> eww
-    <braunr> normal I/O is done with message passing
-    <braunr> the hurd io interface
-    <Spyro> ok
-    <Spyro> so who talks to who on a file I/O?
-    <braunr> a client (e.g. cat) talks to a file system server (e.g. ext2fs)
-    <Spyro> ok so
-    <Spyro> it's client to the pager for regular file I/O?
-    <braunr> Spyro: i don't understand the question
-    <braunr> Spyro: it's client to server, the server might not be a pager
-    <Spyro> ok
-    <Spyro> just trying to figure out the difference between paging/faulting
-      and regular I/O
-    <braunr> regular I/O is just message passing
-    <braunr> page fault handling is dealt with by pagers
-    <Spyro> and I have a hunch that the fs/pager is involved somehow in both,
-      because the server is the source of the data
-    <Spyro> I'm getting a headache
-    <braunr> nalaginrut: a server like ext2fs is both a file server and a pager
-    <Spyro> oh!
-    <Spyro> oh btw, does a file server make use of memory objects for caching?
-    <braunr> Spyro: yes
-    <Spyro> or rather, can it?
-    <Spyro> does it have to?
-    <braunr> memory objects are for caching, and thus for page faults
-    <braunr> Spyro: for caching, it's a requirement
-    <braunr> for I/O, it's not
-    <braunr> you could have I/O without memory objects
-    <Spyro> ok
-    <Spyro> so how does the pager/fileserver use memory objects for caching?
-    <Spyro> does it just map and write to them?
-    <braunr> basically yes but there is a complete protocol with the kernel for
-      that
-    <braunr>
-      http://www.gnu.org/software/hurd/gnumach-doc/External-Memory-Management.html#External-Memory-Management
-    <Spyro> heh, lucky guess
-    <Spyro> ty
-    <Spyro> I am in way over my head here btw
-    <Spyro> zero experience with micro kernels in practice
-    <braunr> it's not trivial
-    <braunr> that's not a microkernel thing at all
-    <braunr> that's how it works in monolithic kernels too
-    <braunr> i recommend netbsd uvm thesis
-    <braunr> there are nice pictures describing the vm system
-    <Spyro> derrr...preacious?
-    <Spyro> wow
-    <braunr> just ignore the anonymous memory handling part which is specific
-      to uvm
-    <Spyro> @_@
-    <braunr> the rest is common to practically all VM systems out there
-    <Spyro> I know about the linux page cache
-    <braunr> well it's almost the same
-    <Spyro> with memory objects being the same thing as files in a page cache?
-    <braunr> memory objects are linux "address spaces"
-    <braunr> and address spaces are how the linux mm views a file, yes
-    <Spyro> derp
-    <Spyro> ...
-    <Spyro> um...
-    <braunr> struvt vm_page == struct page
-    * Spyro first must learn what an address_space is
-    <braunr> struct vm_map == struct mm_struct
-    <braunr> struct vm_map_entry == struct vm_area_struct
-    * Spyro isn't a linux kernel vm expert either
-    <braunr> struct vm_object == struct address_space
-    <braunr> roughly
-    <braunr> details vary a lot
-    <Spyro> and what's an address_space ?
-    <braunr> 11:41 < braunr> and address spaces are how the linux mm views a
-      file, yes
-    <Spyro> ok
-    <braunr> see include/linux/fs.h
-    <braunr> struct address_space_operations is the pager interface
-    * Spyro should look at the linux kernel sources perhaps, unless you have an
-        easier reference
-    <Spyro> embarrassingly, RVR hired me as an editor for the linux-mm wiki
-    <Spyro> I should know this stuff
-    <braunr> see
-      http://darnassus.sceen.net/~rbraun/design_and_implementation_of_the_uvm_virtual_memory_system.pdf
-    <braunr> page 42
-    <braunr> page 66 for another nice view
-    <braunr> i wouldn't recommend using linux source as refernece
-    <braunr> it's very complicated, filled with a lot of code dealing with
-      details
-    <Spyro> lmao
-    <braunr> and linux guys have a habit of choosing crappy names
-    <Spyro> I was only going to 
-    <Spyro> stoppit
-    <braunr> except for "linux" and "git"
-    <Spyro> ...make me laugh any more and I'll need rib surgery
-    <braunr> laugh ?
-    <Spyro> complicated and crappy
-    <braunr> seriously, "address space" for a file is very very confusing
-    <Spyro> oh I agree with that
-    <braunr> yes, names are crappy
-    <braunr> and the code is very complicated
-    <braunr> it took me half an hour to find where readahead is done once
-    <braunr> and i'm still not sure it was the right code
-    <Spyro> so in linkern, there is an address_space for each cached file?
-    <braunr> takes me 30 seconds in netbsd ..
-    <braunr> yes
-    <Spyro> eww
-    <Spyro> yeah, BAD name
-    <Spyro> but thanks for the explanation
-    <Spyro> now I finally know what an address space is
-    <braunr> many linux core developers admit they don't care much about names
-    <Spyro> so, in hurd, a memory object is to hurd, what an address_space is
-      to linux?
-    <braunr> yes
-    <braunr> notto hurd
-    <Spyro> ok
-    <braunr> to mach
-    <Spyro> you know what I mean
-    <Spyro> :P
-    <Spyro> easier than for linux I can tell you that much
-    <braunr> and the bsd vm system is a stripped version of the mach vm
-    <Spyro> ok
-    <braunr> that's why i think it's important to note it
-    <Spyro> good, I learned something abou tthe linux vm...from the mach guys
-    <Spyro> this is funny
-    <braunr> linux did too
-    <braunr> there is a paper about linux page eviction that directly borrows
-      the mach algorithm and improves it
-    <braunr> mach is the historic motivation behind mmap on posix
-    <Spyro> oh nice!
-    <Spyro> but yes, linux picked a shitty name
-    <braunr> is all that clearer to you ?
-    <Spyro> I think that address_space connection was a magic bolt of
-      understanding
-    <braunr> and do you see how I/O and paging are mostly unrelated ?
-    <Spyro> almost
-    <Spyro> but how does a file I/O take advantage of caching by a memory
-      object?
-    <Spyro> does the file server just nudge the core for a hint?
-    <braunr> the file system copies from the memory object
-    * Spyro noddles
-    <Spyro> I think I understand a bit better now
-    <braunr> it's message passing
-    <Spyro> but I havfe too much to digest already
-    <braunr> memory copying
-    <braunr> if the memory is already there, good, if not, the kernel will ask
-      the file system to bring the data
-    <braunr> if message passing uses zero copy, data retrieval can be deferred
-      until the client actually accesses it
-    <Spyro> which is a fancy way of saying demand paging? :P
-    <braunr> it's always demand paging
-    <braunr> what i mean is that the file system won't fetch data as soon as it
-      copies memory
-    <braunr> but when this data is actually needed by the client
-    <Spyro> uh...
-    <Spyro> whta's a precious page?
-    <braunr> let me check quickly
-    <braunr> If precious is FALSE, the kernel treats the data as a temporary
-      and may throw it away if it hasn't been changed. If the precious value is
-      TRUE, the kernel treats its copy as a data repository and promises to
-      return it to the manager
-    <braunr> basically, it's used when you want the kernel to keep cached data
-      in memory
-    <braunr> the cache becomes a lossless container for such pages
-    <braunr> the kernel may flush them, but not evict them
-    <Spyro> what's the difference?
-    <braunr> imagine a ramfs
-    <Spyro> point made
-    <braunr> ok
-    <Spyro> would be pretty hard to flush something that doesn't have a backing
-      store
-    <braunr> that was quick :)
-    <braunr> well
-    <braunr> the normal backing store for anonymous memory is the default pager
-    <braunr> aka swap
-    <Spyro> eww
-    <braunr> but if you want your data *either* in swap or in memory and never
-      in both
-    <braunr> it may be useful
diff --git a/open_issues/metadata_caching.mdwn b/open_issues/metadata_caching.mdwn
deleted file mode 100644
index f7f4cb53..00000000
--- a/open_issues/metadata_caching.mdwn
+++ /dev/null
@@ -1,31 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012 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_gnumach open_issue_hurd]]
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2012-07-08
-
-    <braunr> youpi: there is still quite a lot of I/O even for cached objects
-    <braunr> youpi: i strongly suspect these are for the metadata
-    <braunr> i.e. we don't have a "buffer cache", only a file cache
-    <braunr> (gnu is really not unix lol)
-    <youpi> doesn't ext2fs cache these?
-    <youpi> (as long as the corresponding object is cached
-    <youpi> )
-    <braunr> i didn't look too much, but if it does, it does a bad job
-    <braunr> i would guess it does, but possibly only writethrough
-    <youpi> iirc it does writeback
-    <youpi> there's a sorta "node needs written" flag somewhere iirc
-    <braunr> but that's for the files, not the metadata
-    <youpi> I mean the metadata of the node
-    <braunr> then i have no idea what happens
diff --git a/open_issues/mig_error_reply.mdwn b/open_issues/mig_error_reply.mdwn
deleted file mode 100644
index 21a5b217..00000000
--- a/open_issues/mig_error_reply.mdwn
+++ /dev/null
@@ -1,68 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_mig]]
-
-\#hurd, freenode, 2010-05-19
-
-    <cfhammar> ugh, mig server stubs generated from *_reply.defs don't call the server functions when the reply is an error, since the message size is too small...
-    <cfhammar> term seems to get around it by turning of type checking
-    <cfhammar> s/of/off
-    <cfhammar> but streamio doesn't
-    <cfhammar> luckily the only other program that makes use of a *_reply.defs is crash, and crash_reply.defs' routines only return an error code so it isn't affected
-    <slpz> cfhammar: could you point me to a stub with that problem?
-    <cfhammar> slpz: trans/device_replyServer.c:_Xdevice_open_reply (in build dir)
-    <slpz> cfhammar: So, if I understand it correctly, the problem is that GNU Mach generated stub doesn't properly set the size of the message if there's an error in the function, thus the type checking in user generated stub discards the reply
-    <cfhammar> slpz: the size is correct, error messages contain just a return value
-    <cfhammar> slpz: it is the type checking that is at fault imho
-    <slpz> cfhammar: even when a server wants to return an error, the size of the message should be the same as the reply structure previously defined
-    <slpz> cfhammar: on the other hand, I can't understand why streamio is using device_open_request (async RPC) instead of device_open (sync RPC)...
-    <cfhammar> slpz: the server does not always know the proper size, e.g. when it doesn't understand the message
-    <slpz> cfhammar: what do you mean by "doesn't understand the message"?
-    <cfhammar> slpz: if it doesn't implement that interface or is the wrong type, etc.
-    <cfhammar> slpz: in that case the mig stub needs to send out a generic error reply
-    <cfhammar> slpz: i don't know why streamio uses it either
-    <slpz> cfhammar: OK, now I see your point. If the server answers with a generic error code (as MIG_*), device_open_reply will not be called, and device_open_request doesn't get an error.
-    <slpz> cfhammar: good catch :-)
-    <cfhammar> slpz: all errors are handled the same way, MIG_* is just an example of why it does so
-    <slpz> cfhammar: on an unrealted note, I think we should get rid of all asynchronous messages sent from the user to the kernel, since they aren't asynchronous except for sending the reply to a different port (the process is really done by the thread calling mach_msg)
-    <cfhammar> slpz: i'm not not all that familiar with the low-level parts of message passing so i can't really comment
-    <slpz> cfhammar: in that point I disagree. If the server function can understand the message (so there isn't a MIG_* error), it can send a reply message with the proper size
-    <cfhammar> slpz: it could, but what is the advantage if we still need to handle generic errors?
-    <cfhammar> slpz: "sending the reply to a different port", different from what?
-    <slpz> cfhammar: to differentiate between message marshalling errors and errors generated by the called function
-    <slpz> cfhammar: in a synchronous RPC, the same call to mach_msg will send the request and receive the reply by providing a mig generated reply port
-    <slpz> cfhammar: but in an asynchronous, the reply is received by a port previously generated by the function requesting the message
-    <cfhammar> slpz: ah, that's a clever optimization
-    <slpz> cfhammar: if the "asynchronous" message is sent to the kernel, the thread calling for mach_msg will execute the server's function, but the reply will be sent to one of these previously generated ports
-    <slpz> cfhammar: actually you have a synchronous operation replying to a different port. That doesn't make much sense to me :-)
-    <antrik> slpz: note that most kernel functions can be implemented by userspace servers, in which case they could be really async...
-    <cfhammar> slpz: not sure how differentiating mig errors from server errors is useful...
-    <slpz> antrik: define "most kernel functions" ;-)
-    <cfhammar> slpz: if nothing else kernel rpcs can be proxied, e.g. rpctrace
-    <slpz> cfhammar: well, think of device_open_request. If the result is not a mig error, you can still device_open_reply an expect it to properly process the return code from the message
-    <cfhammar> slpz: it should be able to handle all kinds of errors anyway, the result should be the same as with syncronous rpcs
-    <slpz> cfhammar: yes, you're right. User generated stub should be able to fill the reply with the error code and call to the reply function.
-    <slpz> cfhammar: Then someone needs to introduce some changes in MiG's magic...
-    <cfhammar> slpz: yes, a flag to generate reply side of an interface would be ideal
-    <cfhammar> slpz: then we could toss out *_reply.defs altogether
-    <slpz> cfhammar: well, that's a different change from what I was thinking
-    <cfhammar> slpz: how would you change it?
-    <slpz> cfhammar: just generating stubs which, in case of error, will properly call to the reply function with the error code in its arguments
-    <cfhammar> slpz: ah yes, i considered that as well, but i don't think mig can actually distinguish the error code from any other int argument
-    <cfhammar> slpz: i should double check it though
-    <slpz> cfhammar: I tag can be used to point to argument of this nature
-    <slpz> cfhammar: s/I/A/
-    <cfhammar> slpz: oh, it already is tagged with retcode, intresting
-    <slpz> cfhammar: OMG, I'm thinking like MiG! ;-P
-    <cfhammar> slpz: is that a good or bad ;
-    <cfhammar> slpz: ;-)
-    <slpz> cfhammar: I don't know, but it's somewhat scary ;-)
-    <cfhammar> slpz: apparently retcode is only there for comatibility, mig just ignores it...
diff --git a/open_issues/mig_portable_rpc_declarations.mdwn b/open_issues/mig_portable_rpc_declarations.mdwn
deleted file mode 100644
index f5f18880..00000000
--- a/open_issues/mig_portable_rpc_declarations.mdwn
+++ /dev/null
@@ -1,291 +0,0 @@
-[[!meta copyright="Copyright © 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_mig]]
-
-[[!toc]]
-
-
-# 32-Bit vs. 64-Bit Interfaces
-
-## IRC, freenode, #hurd, 2011-10-16
-
-    <braunr> i guess it wouldn't be too hard to have a special mach kernel for
-      64 bits processors, but 32 bits userland only
-    <youpi> well, it means tinkering with mig
-    <braunr> like old sparc systems :p
-    <youpi> to build the 32bit interface, not the 64bit one
-    <braunr> ah yes
-    <braunr> hm
-    <braunr> i'm not sure
-    <braunr> mig would assume a 32 bits kernel, like now
-    <youpi> and you'll have all kinds of discrepancies in vm_size_t & such
-    <braunr> yes
-    <braunr> the 64 bits type should be completely internal
-    <braunr> types*
-    <braunr> but it would be far less work than changing all the userspace bits
-      for 64 bit (ofc we'll do that some day but in the meanwhile ..)
-    <youpi> yes
-    <youpi> and it'd boost userland addrespace to 4GiB
-    <braunr> yes
-    <youpi> leaving time for a 64bit userland :)
-
-
-## IRC, freenode, #hurd, 2011-11-14
-
-    <braunr> also, what's the best way to deal with types such as
-    <braunr> type cache_info_t = struct[23] of integer_t;
-    <braunr> whereas cache_info_t contains longs, which are obviously not
-      integer-wide on 64-bits processors
-    <braunr> ?
-    <youpi> you mean, to port mach to 64bit?
-    <braunr> no, to make the RPC declaration portable
-    <braunr> just in case :)
-    <youpi> refine integer_t into something more precise
-    <youpi> such as size_t, off_t, etc.
-    <braunr> i can't use a single line then
-    <braunr> struct cache_info contains ints, vm_size_t, longs
-    <braunr> should i just use the maximum size it can get ?
-    <braunr> or declare two sizes depending on the word size ?
-    <youpi> well, I'd say three
-    <braunr> youpi: three ?
-    <youpi> the ints, the vm_size_ts, and the longs
-    <braunr> youpi: i don't get it
-    <braunr> youpi: how would i write it in mig language ?
-    <youpi> I don't know the mig language
-    <braunr> me neither :)
-    <youpi> but I'd say don't lie
-    <braunr> i just see struct[23] of smething
-    <braunr> the original zone_info struct includes both integer_t and
-      vm_size_t, and declares it as
-    <braunr> type zone_info_t = struct[9] of integer_t;
-    <braunr> in its mig defs file
-    <braunr> i don't have a good example to reuse
-    <youpi> which is lying
-    <braunr> yes
-    <braunr> which is why i was wondering if mach architects themselves
-      actually solved that problem :)
-    <braunr> "There is no way to specify the fields of  a
-    <braunr> C  structure  to  MIG. The size and type-desc are just used to
-      give the size of
-    <braunr> the structure.
-    <braunr> "
-    <braunr> well, this sucks :/
-    <braunr> well, i'll do what the rest of the code seems to do, and let it
-      rot until a viable solution is available
-    <antrik> braunr: we discussed the problem of expressing structs with MIG in
-      the libburn thread
-    <antrik> (which I still need to follow up on... [sigh])
-
-
-## IRC, freenode, #hurd, 2012-12-12
-
-In context of [[microkernel/mach/gnumach/memory_management]].
-
-    <tschwinge> Or with a 64-bit one?  ;-P
-    <braunr> tschwinge: i think we all had that idea in mind :)
-    <pinotree> tschwinge: patches welcome :P
-    <youpi> tschwinge: sure, please help us settle down with the mig stuff
-    <youpi> what was blocking me was just deciding how to do it
-    <braunr> hum, what's blocking x86_64, except time to work on it ?
-    <youpi> deciding the mig types & such things
-    <youpi> i.e. the RPC ABI
-    <braunr> ok
-    <braunr> easy answer: keep it the same
-    <youpi> sorry, let me rephrase
-    <youpi> decide what ABI is supposed to be on a 64bit system, so as to know
-      which way to rewrite the types of the kernel MIG part to support 64/32
-      conversion
-    <braunr> can't this be done in two steps ?
-    <youpi> well, it'd mean revamping the whole kernel twice
-    <youpi> as the types at stake are referenced in the whole RPC code
-    <braunr> the first step i imagine would simply imply having an x86_64
-      kernel for 32-bits userspace, without any type change (unless restricting
-      to 32-bits when a type is automatically enlarged on 64-bits)
-    <youpi> it's not so simple
-    <youpi> the RPC code is tricky
-    <youpi> and there are alignments things that RPC code uses
-    <youpi> which become different when build with a 64bit compiler
-    <pinotree> there are also things like int[N] for io_stat_struct and so on
-    <braunr> i see
-    <youpi> making the code wrong for 32
-    <youpi> thus having to change the types
-    <youpi> pinotree: yes
-    <pinotree> (doesn't mig support structs, or it is too clumsy to be used in
-      practice?)
-    <braunr> pinotree: what's the problem with that (i explcitely said changing
-      int to e.g. int32_t)
-    <youpi> that won't fly for some of the calls
-    <youpi> e.g. getting a thread state
-    <braunr> pinotree: no it doesn't support struct
-    <pinotree> braunr: that some types in struct stat are long, for instance
-    <braunr> pinotree: same thing with longs
-    <braunr> youpi: why wouldn't it ?
-    <youpi> that wouldn't work on a 64bit system
-    <youpi> so we can't make it int32_t in the interface definition
-    <braunr> i understand the alignment issues and that the mig code adjusts
-      the generated code, but not the content of what is transfered
-    <braunr> well of course
-    <braunr> i'm talking about the first step here
-    <braunr> which targets a 32-bits userspace only
-    <youpi> ok, so we agree
-    <youpi> the second step would have to revamp the whole RPC code again
-    <braunr> i imagine the first to be less costly
-    <braunr> well, actually no
-    <braunr> you're right, the mig stuff would be easy on the application side,
-      but more complicated on the kernel side, since it would really mean
-      dealing with 64-bits values there
-    <braunr> (unless we keep a 3/1 split instead of giving the full 4g to
-      applications)
-
-See also [[microkernel/mach/gnumach/memory_management]].
-
-    <youpi> (I don't see what that changes)
-    <braunr> if the kernel still runs with 32-bits addresses, everything it
-      recevies from or sends through mig can be stored with the user side
-      32-bits types
-    <youpi> err, ok, but what's the point of the 64bit kernel then ? :)
-    <braunr> and it simply uses 64-bits addresses to deal with physical memory
-    <youpi> ok
-    <youpi> that could even be a 3.5/0.5 split then
-    <braunr> but the memory model forces us to run either at the low 2g or the
-      highest ones
-    <youpi> but linux has 3/1, so we don't need that
-    <braunr> otherwise we need an mcmodel=medium
-    <braunr> we could do with mcmodel=medium though, for a time
-    <braunr> hm actually no, it would require mcmodel=large
-    <braunr> hum, that's stupid, we can make the kernel run at -2g, and use 3g
-      up to the sign extension hole for the kernel map
-
-
-## IRC, freenode, #hurd, 2013-12-03
-
-    <azeem> I believe the main issue is redoing the RPCs in 64bit, i.e. the
-      Mach/Hurd interface
-    <braunr> mach has always been 64-bits capable
-    <braunr> the problem is both mach and the hurd
-    <braunr> it's at the system interface (the .defs of the RPCs)
-    <braunr> azeem: ah, actually that's why you also say
-    <braunr> but i consider it to be a hurd problem
-    <braunr> the hurd itself is defined as being a set of interfaces and
-      servers implementing them, i wouldn't exclude the interfaces
-    <braunr> that's what*
-
-
-# Structured Data
-
-## IRC, freenode, #hurd, 2013-06-25
-
-    <teythoon> is there a nice way to get structured data through mig that I
-      haven't found yet?
-    <teythoon> say an array of string triples
-    <braunr> no
-    <teythoon> :/
-    <braunr> but you shouldn't need that
-    <teythoon> my use case is getting info about fs translators from init to
-      procfs
-
-[[hurd/translator/mtab]], [[hurd/translator/mtab/discussion]].
-
-    <teythoon> should I go for an iterator like interface instead?
-    <braunr> depends
-    <braunr> how many do you need ?
-    <braunr> you could go for a variable sized array too
-    <braunr> have a look at what already exists
-    <teythoon> records, maybe 10-15, depends on many fs translators are running
-    <braunr> a variable sized array is ok if the size isn't too big (and when i
-      say too big, i mean hundreds of MiB)
-    <braunr> an iterator is ok too if there aren't too many items
-    <braunr> you may want to combine both (i think that's what proc does)
-    <braunr> be aware that the maximum size of a message is limited to 512 MiB
-    <teythoon> yeah I saw the array[] of stuff stuff, but array[] of string_t
-      does not work, I guess b/c string_t is also an array
-    <teythoon> how would I send an array of variable length strings?
-    <braunr> i'm not sure you can
-    <braunr> or maybe out of line
-    <teythoon> somehow I expected mig to serialize arbitrary data structures,
-      maybe it's to old for that?
-    <teythoon> yeah, I read about uot of line, but that seems overkill
-    <braunr> it is old yes
-    <braunr> and not very user friendly in the end
-    <braunr> let me check
-    <teythoon> we could stuff json into mig...
-    <braunr> see proc_getallpids for example
-    <braunr> we could get rid of low level serialization altogether :p
-    <teythoon> hah, exactly what  I was looking at
-    <braunr> (which is what i'll do in x15)
-    <braunr> type pidarray_t = array[] of pid_t;
-    <teythoon> but that is trivial b/c its array[] of pid_t
-    <braunr> and always have the server writing guide near you
-    <teythoon> yes
-    <braunr> well, make one big string and an array of lengths :p
-    <teythoon> thought about that and said to myself, there must be a better
-      way that I haven't found yet
-    <braunr> or one big string filled with real null-terminated c strings that
-      you keep parsing until you ate all input bytes
-    <braunr> i'm almost certain there isn't
-    <braunr> type string_t = c_string[1024]; /* XXX */
-    <teythoon> yes
-    <braunr> even that isn't really variable sized
-    <teythoon> you think anyone would object to me putting a json encoder in
-      /hurd/init? it is probably better than me at serializing stuff...
-    <braunr> try with mig anyway
-    <braunr> the less dependencies we have for core stuff, the simpler it is
-    <braunr> but i agree, mig is painful
-    <teythoon> would it be too hacky if I abused the argz functions? they do
-      exactly what I'd need
-
-
-## IRC, freenode, #hurd, 2013-06-26
-
-    <teythoon> there is https://code.google.com/p/protobuf-c/ and it has a rpc
-      mechanism and I believe one could plug arbitrary transports easily
-    <braunr> please don't think about it
-    <braunr> we really don't want to add another layer of serialization
-    <braunr> it's better to completely redesign mach ipc anyway
-    <braunr> and there is a project for that :p
-    <teythoon> ive seen x15
-    <teythoon> just food for thought
-    <braunr> i've studied google protocol buffers
-    <braunr> and fyi, no, it wouldn't be easy to plug arbitrary transports on
-      top of mach
-    <braunr> there is a lot of knowledge about mach ports in mig
-
-[[hurd/translator/mtab]], [[hurd/translator/mtab/discussion]].
-
-    <teythoon> but again I face the challenge of serializing a arbitrary sized
-      list of arbitrary sized strings
-    <braunr> yes
-    <teythoon> list of ports is easier ;) but I think its worthwile
-    <teythoon> so what about abusing argz* for this? you think it's too bad a
-      hack?
-    <braunr> no since it's in glibc
-    <teythoon> awesome :)
-    <braunr> but i don't remember the details well and i'm not sure the way you
-      use it is safe
-    <teythoon> yeah, I might have got the details wrong, I hadn't had the
-      chance to test it ;)
-
-    <braunr> about this dynamic size problem
-    <braunr> a "simple" varying size array should do
-    <braunr> you can easily put all your strings in there
-    <teythoon> seperated by 0?
-    <braunr> yes
-    <teythoon> that's exactly what the argz stuff does
-    <braunr> you'll get the size of the array anyway, and consume it until
-      there is no byte left
-    <braunr> good
-    <braunr> but be careful with this too
-    <braunr> since translators can be run by users, they somtimes can't be
-      trusted
-    <braunr> and even a translator running as root may behave badly
-    <braunr> so careful with parsing
-    <teythoon> noted
diff --git a/open_issues/mig_strings.mdwn b/open_issues/mig_strings.mdwn
deleted file mode 100644
index 3693fcc2..00000000
--- a/open_issues/mig_strings.mdwn
+++ /dev/null
@@ -1,38 +0,0 @@
-[[!meta copyright="Copyright © 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_mig]]
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2014-02-21
-
-    <teythoon> grml... migs support for variable-length c strings is broken :(
-    <braunr> completely ..
-    <teythoon> no one told me :p
-    <braunr> noone dares
-    <teythoon> to tell me ?
-    <braunr> or anyone else ;p
-    <teythoon> ^^
-    <teythoon> root@debian:~# pkill mtab
-    <teythoon> task /hurd/procfs(19) �O�  deallocating an invalid port 1049744,
-      most probably a bug.
-    <braunr> :)
-    <teythoon> it's still an improvement >,<
-    <teythoon> uh the joys...
-    <teythoon> gnu machs mig_strncpy behaves differently from glibcs
-    <teythoon> the mach version always 0-terminates the target string, the libc
-      variant does not
-    <teythoon> which one should i "fix" ?
-    <braunr> strncpy should behave like strncpy
-    <teythoon> not according to the documentation in gnumach...
-    <braunr> people who know it expect it not to always null terminate
-    <braunr> you can either fix mig_strncpy, or call it mig_strlcpy
diff --git a/open_issues/mig_stub_functions.mdwn b/open_issues/mig_stub_functions.mdwn
deleted file mode 100644
index 474a7675..00000000
--- a/open_issues/mig_stub_functions.mdwn
+++ /dev/null
@@ -1,53 +0,0 @@
-[[!meta copyright="Copyright © 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_mig]]
-
-[[!toc]]
-
-
-# RPC Stubs Implemented by Hand
-
-## IRC, freenode, #hurd, 2013-07-28
-
-    <teythoon> why is libfshelp/start-translator-long.c doing the fsys_startup
-      rpcs by hand instead of using the mig generated stubs?
-
-
-## IRC, freenode, #hurd, 2013-07-29
-
-    <teythoon> btw, anyone knows why libfshelp/start-translator-long.c
-      implements the fsys_startup rpc by hand?
-    <braunr> teythoon: no idea
-    <teythoon> maybe b/c of the need to specify a timeout? can one do that with
-      the mig stubs?
-    <braunr> yes
-    <braunr> select used to be implemented that way
-
-
-# Generate the Request and Reply Routines from the Synchronous Routines
-
-## IRC, freenode, #hurd, 2013-09-19
-
-    <teythoon> btw, is there any reason why mig couldn't generate the request
-      and reply routines from the synchronous routines?
-    <braunr> i guess it could
-
-
-# Compiler Optimization
-
-## IRC, freenode, #hurd, 2013-12-02
-
-    <teythoon> braunr: inlining the mach generated x_server_procedure functions
-      shaved 5 minutes off my hurd package build :)
-    <teythoon> i guess fakeroot-tcp benefits most from this... I'm going to try
-      this w/o fakeroot and on real hardware shortly
-    <braunr> teythoon: nice
-    <teythoon> :)
diff --git a/open_issues/mission_statement.mdwn b/open_issues/mission_statement.mdwn
deleted file mode 100644
index a1c8f235..00000000
--- a/open_issues/mission_statement.mdwn
+++ /dev/null
@@ -1,708 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012, 2013 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_documentation]]
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2011-10-12
-
-    <ArneBab> we have a mission statement: http://hurd.gnu.org
-    <Gorodish> yes
-    <Gorodish> but it's quite wishy washy
-    <Gorodish> considering all the elegant capability Hurd potentially has to
-      offer
-    <antrik> Gorodish: it's true that the mission statement is very
-      abstract... but then, it's hard to put anything more specific into 35
-      words
-    <Gorodish> not with some practice
-    <Gorodish> I notice programers tend to speak and write in terms of what
-      something does
-    <Gorodish> not what it is
-    <Gorodish> the "What is Hurd" is a good example
-    <Gorodish> there's a lot of interesting information there
-    <Gorodish> but the way it's ordered is odd
-    <antrik> a mission statement is not primarily a PR instrument; but rather a
-      guide that allows separating things that benefit the common goal from
-      things that don't...
-    <antrik> I agree that some actual marketing material in addition would be
-      nice :-)
-    <Gorodish> yes
-    <Gorodish> the modesty of Developers that work on FOSS projects never
-      ceases to amaze me
-    <Gorodish> I agree that the informational, factual, results oriented
-      documentation is the primary objective of documenting
-
-
-# IRC, freenode, #hurd, 2011-11-25
-
-    <antrik> heh, nice: http://telepathy.freedesktop.org/wiki/Rationale
-    <antrik> most of this could be read as a rationale for the Hurd just as
-      well ;-)
-
-
-# IRC, freenode, #hurd, 2012-04-06
-
-    <braunr> LibreMan: the real feature of the hurd is its extensibility
-
-[[/Extensibility]], [[/advantages]].
-
-    <braunr> LibreMan: (though it could be improved even further)
-    <LibreMan> braunr: yeah, I keep reading that ... but that sounds too
-      abstract, I can not imagine what useful could that provide to the actual
-      users
-    <braunr> LibreMan: say fuse, but improved
-    <braunr> LibreMan: do you see how useful fuse is ?
-    <braunr> if so, you shouldn't have trouble imagining the gap between linux
-      without fuse and linux with fuse is about the same as linux with fuse and
-      the hurd
-    <braunr> and yes, it's abstract
-    <braunr> translators are not only about file systems
-    <LibreMan> braunr: well, its main advantage is that it's running in
-      user-space and therefore doesn't need root priviledges to mount whatever
-      fs you want?
-    <braunr> no
-    <braunr> you don't need to change the kernel, or implement weird tricks to
-      get what you want working
-    <LibreMan> braunr: okay, but there is fuse for Linux ... so the
-      difference/advantages need to be between Linux WITH fuse and Hurd
-    <braunr> that's what i'm saying
-    <LibreMan> the issue I have is that I do not see why anyone would have any
-      incentive to switch to Hurd
-    <braunr> there isn't much, which is why we stick with unix instead of,
-      e.g. plan9 or other advanced systems
-    <pinotree> try to use fuse on a server where there is no fuse installed
-    <LibreMan> if I want fuse-like functionallity I just install FUSE, no need
-      for Hurd ... so the reson to use it is not there
-    <braunr> LibreMan: read what i wrote
-    <braunr> using the hurd compared to using linux with fuse is about the same
-      as using linux with fuse compared to using linux without fuse
-    <LibreMan> braunr: ah, sorry ... I see
-    <braunr> it's a step further
-    <braunr> in theory, developers can add/remove the components they want,
-      making system development faster and more reliable
-    <braunr> where with unix, you need stuff like user mode linux or a virtual
-      machine
-    <LibreMan> braunr: but in practice it was the opposite so far :)
-    <braunr> not really
-    <braunr> it's a lack of manpower
-    <braunr> not a problem of partice versus theory
-    <braunr> practice*
-    <LibreMan> braunr: what do you think are the reasons why Hurd developement
-      is so slow if it should be faster in theory?
-
-[[faq/how_many_developers]].
-
-    <braunr> 17:30 < braunr> it's a lack of manpower
-    <braunr> pay someone to do the job
-    <braunr> :p
-    <LibreMan> braunr: then why does Linux get the manpower but Hurd doesn't?
-    <braunr> $$
-    <LibreMan> braunr: ??
-    <braunr> linux developers are paid
-    <LibreMan> because companies are using it :)
-    <braunr> yes
-    <LibreMan> why are they not using Hurd then?
-    <braunr> because it wasn't reliable enough
-    <LibreMan> Linux wasn't either at some point
-    <braunr> sure
-    <braunr> but when it became, the switch towards its use began
-    <braunr> now that they have something free and already working, there is no
-      point switching again
-    <LibreMan> paid devs join only AFTER volunteers got it to the stage that it
-      was useful to companies
-    <braunr> well linux was easier to develop at the beginning (and is still
-      today because of several kernel hacking features)
-    <braunr> it followed the traditional unix model, nothing was really new
-      about it
-    <LibreMan> braunr: exactly! that's why I think that Hurd needs to have very
-      compelling technical advantages to overcome that barrier
-    <braunr> few people/companies really care about such technical advantages
-    <braunr> they don't care if there are ugly tricks to overcome some problems
-    <LibreMan> you mean about such that Hurd can provide, right?
-    <braunr> it's not elegant, but most of the time they're not even aware of
-      it
-    <braunr> yes
-    <LibreMan> that's eaxctly my point ... most people do not care if it's
-      "elegant" from a programmers POV, they care whether it WORKS
-    <braunr> well yes
-    <braunr> what's your point ?
-    <LibreMan> all I see about Hurd is how "elegant" it is ... but that doesn't
-      matter if it doesn't provide any practical advantages
-    <braunr> you want us to expose a killer feature amazing enough to make the
-      world use our code ?
-    <LibreMan> well, I want Hurd to succeed and try to identify the resons it
-      doesn't
-    <braunr> it does, but not to the point of making people use it
-    <braunr> unix *is* good enough
-    <braunr> same reason plan9 "failed" really
-    <LibreMan> define your idea of Hurd succeeding then, I thought it was to
-      make it useful to the point that people use it :)
-    <braunr> there are many other attempts to make better system architectures
-    <braunr> it is
-    <braunr> people are still using windows you know, and i really don't see
-      why, but it does the work for them
-    <LibreMan> <braunr> you want us to expose a killer feature amazing enough
-      to make the world use our code ? --- YES ;)
-    <braunr> other people can think about the same between unix and the hurd
-    <braunr> LibreMan: well too bad, there is none, because, again, unix isn't
-      that bad
-    <braunr> it doesn't prevent us from making a better system that is usable
-    <LibreMan> to explain my take on this - there are two kind of people, those
-      who care about philosophy behind software (and its consequences, FSF
-      etc.) and those who don't
-    <LibreMan> it's the job of those who do care to make the sw so good that
-      those who do not care switch to it = victory :)
-    <LibreMan> as I said the reasons I want Hurd to succeed are more
-      "political" than technical ... I do not know how many Hurd devs agree
-      with that kind of sentiment but I'd rather want a GNU project to be in
-      the forefront than that of a  "benevolent dictator" that doesnt' really
-      care about user freedom
-    <LibreMan> from thechnical POV I agree that Linux isn't that bad ... it's
-      quite good, it's the "behind the scenes" stuff I do not like about it
-    <LibreMan> I'm kind of confused right now ... what exactly is to point of
-      Hurd then? I thought it was to make it good enough or better than Linux
-      so users start using it (privatly or corporate)
-    <LibreMan> is this just a research project that isn't intended to be used
-      by "general population"?
-    <braunr> LibreMan: it's an operating system project
-    <braunr> some people try to make it as good as it can be, but it's not easy
-    <braunr> it's not a pet or research only system
-    <LibreMan> braunr: I see what it is ... I'm struggling to see what is the
-      point of it being an "OS project", what's its intended purpose
-    <braunr> but it doesn't suit all the needs for a general OS yet
-    <braunr> LibreMan: a general purpose OS like most free unices
-    <LibreMan> what are the motivations behind making it as good as it can be
-    <braunr> for us developers ?
-    <LibreMan> yes
-    <braunr> for me, the architecture
-    <LibreMan> whe you say that linux is goos enough then what's the point?
-    <braunr> we can do better
-    <LibreMan> for you it's just a hobby that doesn't have any real goal except
-      challenging yourself to do it?
-    <braunr> because of lack of time, you could say that
-    <LibreMan> so you want Hurd to challenge Linux one day, right?
-    <braunr> challenging isn't the point
-    <braunr> i'd like to be able to use it for my needs
-    <LibreMan> well, that wasn't the right choise of word but to be better than
-      Linux
-    <braunr> again, you miss the point
-    <braunr> i don't care much about hurd vs linux
-    <LibreMan> your own needs, so you do not want others to use it?
-    <braunr> i care about the hurd and what i do
-    <braunr> others would think the same
-    <braunr> they would want it to work for their needs
-    <LibreMan> I'm asking about you, do YOU want others to use it? is that one
-      of your goals?
-    <braunr> not really
-    <braunr> i let them do what they want
-    <LibreMan> ah I see, so it is kind of a hobby project for you - you're
-      doing to for yourself and your own needs
-    <LibreMan> and don't care if anyone else uses it or not
-    <braunr> yes, i don't care much about the politics around such projects tb
-    <braunr> tbh
-    <LibreMan> is this kind of sentiment prevalent is the Hurd dev community?
-    <braunr> i don't work on software to break any benevolent dictator or
-      anyone in particular
-    <braunr> i don't know
-    <braunr> i'd say so, yes
-    <braunr> but not sure
-    <braunr> i'm not saying they don't care about freedom, don't get me wrong
-    <braunr> i'd say we sure prefer free software over open source
-    <braunr> but i don't think people work on the hurd specifically for these
-      reasons, rather than the technical ones
-    <LibreMan> interesting ... from the presentation of the project by
-      outsiders I got the impression that it is significantly about freedom,
-      GNU - that those are the main drivers
-    <braunr> if it really was so, we would have grabbed a bsd variant,
-      relicenced it with GPLv3, and call it FreeGNU or NetGNU
-    <LibreMan> and that's how I approached the project ... maybe I was wrong,
-      I'm kind of disappointed if that's so :) I care about those things a
-      great deal, in fact that's the only reason I care about Hurd really
-
-    <lcc> the hurd is designed to offer more freedom, in various ways, to the
-      user. freedom from the admin.
-    <lcc> right?
-    <braunr> lcc: that's embedded in the term "extensibility", yes
-    <braunr> lcc: but there are technical solutions for that on other systems
-      as well now
-
-    <antrik> as for the Hurd, people who said they are interested in it only
-      because of freedom aspects *never* contributed anything significant
-    <antrik> *all* serious contributors are motivated at least equally by the
-      technical merits; often more
-    <antrik> (though the fact that it's a GNU project is what has brought many
-      developers here in the first place...)
-    <LibreMan> antrik: I would phrase it the other way - why do people who have
-      contributed significantly not care about freedom that much? or ... how do
-      you know they don't?
-    <antrik> most of us *do* care about freedem. but it's not our primary
-      motivation. the freedom aspects are just not strong enough to motivate
-      anyone alone
-    <antrik> as braunr already pointed out, if the sole purpose was creating a
-      GNU kernel, there would be *much* more promising venues for that
-    <LibreMan> I do not think so ... if you someone where to just take BSD and
-      rebrand it as AWSOMEnewGNUkernel it wouldn't be looked upon too favorably
-    <LibreMan> there is an honor aspect to it, to have something developed by
-      the community that stands by it
-    <LibreMan> so I do not think it would work
-    <antrik> BSD has forked countless times, and several of these forks became
-      very popular. I don't see why a GNU one shouldn't do well enough
-    <antrik> bat that's beside the point. writing a new boring monolithic
-      UNIX-like kernel from scratch is not that hard
-    <antrik> (as Linus has proven, amonst others...)
-    <antrik> if the sole purpose would be having a GNU kernel, I'd be strongly
-      advocating writing a new monolithic kernel from scratch
-    <LibreMan> antrik: ah, snap! not that hard you say? with all the features
-      Linux has? sure, it's not hard to make a kernel that barely boots but
-      that's not the point, is it? :)
-    <antrik> (yes, even now, with the Hurd being almost usable, I still think
-      it would be easier to get a new monolithic kernel to production quality)
-    <LibreMan> antrik: and here is was braunr who was pitching extensibility
-      and faster developement of Hurd as its advantage - and here you come
-      saying that it would be easier to write monolithic kernel from scratch
-    <LibreMan> get your story striaght guys ;)
-    <antrik> the Hurd makes it easier to develop new features. it's not easier
-      to get it production-ready in the first place
-    <LibreMan> antrik: what's the difference of developing a feature that makes
-      it "production ready" and another one that make it "production ready" for
-      a different use?
-    <antrik> features don't make a system production ready
-    <LibreMan> what makes  a system production ready?
-    <LibreMan> what do you consider a "production"?
-    <antrik> supporting enough use cases that a non-trivial number of users
-      have their needs covered; and being stable enough that it's not annoying
-      to use
-    <LibreMan> either it is easier to develop or it isn't ... either it is
-      modular from it's core or it isn't
-    <antrik> well, not only stable enough, but also performant, secure etc.
-    <antrik> wrong
-    <LibreMan> are you saying that the fruits of its modularity will show only
-      after enough modules have been written?
-    <antrik> a modular system with strong isolation is inherently more
-      complicated to get right
-    <LibreMan> that sure is a weird argument to make ...
-    <LibreMan> right ... but when you get it right, the further development is
-      much easier?
-    <antrik> depends. making fundamental changes to how the system works will
-      always be tricky. but adding new stuff that doesn't require fundamental
-      changes, building on the existing foundations, is way easier
-    <antrik> we believe that once we have the fundamentals mostly right, most
-      things people will be adding will fall into the latter catogory
-    <antrik> category
-    <LibreMan> o what's missing to Hurd before it "got it right" and the fast
-      pace development kicks in?
-    <antrik> but so far most of the work is in the former category, meaning
-      progress is slow
-    <LibreMan> because from readin the site it seems the core is pretty much
-      done ... what it needs are all the translators, drivers, user-space tools
-      to make use of that core - is that impression wrong?
-    <antrik> you are missing the point. there is no unified "development pace"
-      measurement. it is easier to add certain things right now. but to get the
-      system production ready, it still requires considerable work on the hard
-      parts
-    <antrik> well, it's not as simple ;-)
-    <LibreMan> are you sure the work on "the hard parts" is ever going to be
-      done? :)
-    <antrik> the core is working, but it is still missing some features, and
-      it's missing lots of performance optimisation and bug fixing
-    <LibreMan> it seems more hard parts pop up every time you think it is
-      almost production ready
-    <antrik> also, we know today that the core could work much better in some
-      regards if we make some major changes. not a priority right now, but
-      something that will have to be addressed in the long run to seriously
-      compete with other systems
-    <antrik> well, no software is ever done :-)
-    <antrik> but I hope we will get to a point where the hard parts work well
-      enough for most people
-    <LibreMan> in fact I remember the design of Hurd was specifically chose by
-      RMS because he thought it would be easier to implement modular system -
-      that was 20 yeras ago? :)
-    <antrik> yes, and he admitted later that he was totally wrong on that :-)
-    <LibreMan> yeah, that was one unlucky choice for GNU ...
-    <antrik> who knows. it's hard to estimate what would have happened it GNU
-      chose a different route back then
-    <LibreMan> so ... Hurd is a hobby project for you too?
-    <LibreMan> or ... what do you hope to achieve by working on Hurd?
-    <LibreMan> I'm really interested in the motivations of people behind Hurd
-      as I'm kind of surprised it's not that much freedom and GNU ...
-    <antrik> it's a hobby project for everyone -- nobody gets paid for working
-      on it
-    <antrik> in the long run, I hope the Hurd to be a good platform for my
-      higher-level ideas. I have a vision of a desktop environment working
-      quite differently from what exists today; and I believe the extensible
-      architecture of the Hurd makes it easier to implement these ideas
-    <LibreMan> that's not what I meant as you may have guessed from my line of
-      reasoning so far
-    <LibreMan> yeah, that's my definition of a hobby project :) not whether one
-      gets payed to do it or not but whether one does it to satisfy their own
-      curiosity
-    <antrik> well, curiosity is clearly too narrow
-    <LibreMan> as far as I'm concerned I'd have a more "political" goal of
-      influencing the wider world to move toward more freedom
-    <antrik> but hackers never work on volunteer projects except to scratch
-      their own itch, or to work on something they are genuinely interested
-      in. nobody hacks free software just to save the world
-    <LibreMan> I find some technical aspects very interesting and fun but if
-      they wouldn't further the goal of more freedom they'd be without purpose
-      to me
-    <antrik> just think of the GNU high priority projects list -- it has zery
-      effect
-    <antrik> zero
-    <LibreMan> yeah ... and I think that is a real shame
-    <LibreMan> I keep thinking that it's because most hackers do not realize
-      the importance of freedom and the consequences of not having it
-    <antrik> it's a shame that some people at the FSF seem to believe they can
-      tell hackers what to work on :-P
-    <LibreMan> I do not think anybody at FSF actually believes that
-    <LibreMan> they believe as I do that we can persuade hackers to work on
-      things after they themselves recognise the significance of it
-    <antrik> no. there are many many hackers who genuinely believe in
-      supporting software freedom (both in the Hurd and in other GNU projects)
-      -- but there are none who would work on projects they are not personally
-      interested in because of that
-    <LibreMan> well, how does one become "personally interested" in a project?
-      surely it's not something you;re born with ... after recognising a
-      significance of some project some may become personally interested in it
-      - and that's the point ;)
-    <antrik> well, if I you mean nobody realises that software freedom is so
-      important they should work on it instead of doing things they actually
-      enjoy... they yes, I guess you are right :-P
-    <antrik> significance is subjective. just because something may be
-      important to the general public, doesn't mean I personally care about it
-    <LibreMan> you keep projecting your own concerns into it
-    <LibreMan> just because you're not interested in something doesn't mean
-      someone else isn't
-    <LibreMan> you approach it from the POV that omebody is telling YOU what
-      you should do ...
-    <LibreMan> that is not the case
-    <antrik> LibreMan: well, but there are obviously things no hackers care
-      about -- or otherwise there would be no need for the high priority
-      projects list... it's a list of things that would be important for
-      software freedom, but nobody is interested in working on. and having a
-      list of them won't change that fact
-    <LibreMan> antrik: why do you feel entitled to speak for all hackers? the
-      projects are high priority exactly because there isn;t enough people
-      working on them, if they were they wouldn't be high priority :)
-    <LibreMan> so maybe you have cause and effect mixed up ...
-    <LibreMan> there is no need to list office suite as hight priority because
-      there is LibreOffice, if there wasn't I'm sure it would be right there on
-      the priority list
-    <antrik> LibreMan: err... how is that different from what I said?
-    <antrik> these projects are there because there are not enough people
-      working on them -- i.e. hackers are not interested in them
-    <LibreMan> you said it in a way the implied that hackers are not interested
-      in working on projects that are required for providing freedom - but
-      mostly there are, it's just a few project where aren't - and those are
-      listed as high priority to bring attention to them
-    <LibreMan> well, maybe after seeing them on a high priority list some
-      hackes become interested in them - that is the point :)
-    <antrik> yes, that's what I implied. the fact that there are projects
-      hackers aren't working on, although they would be important for software
-      freedom, proves that this is not sufficient motivation for volunteers
-    <antrik> if software freedom alone would motivate hackers, there would be
-      enough people working on important projects
-    <LibreMan> who ever claimed that freedom alone motivated hackers? :)
-    <antrik> but there aren't. we have the list, and people are *still* not
-      working on these projects -- q.e.d.
-    <LibreMan> I do not get what you're trying to prove
-    <antrik> the track record so far clearly shows that hackers do *not* become
-      interested in working on these projects just because they are on the list
-    <antrik> err... you pretty much claimed that Hurd hackers should be
-      motivated by freedom alone
-    <antrik> and expressed great disappointment that we aren't
-    <braunr> LibreMan: you expected the hurd developers to share the common
-      goal of freedom mainly, and now you're saying you don't think hackers
-      would work for freedom alone ?
-    <LibreMan>  freedom mainly ==  freedom alone?
-    <braunr> antrik: would you see an objection to using netbsd as a code base
-      for a mach clone ?
-    <braunr> LibreMan: you said share the common goal of freedom
-    <LibreMan> you're twisting my word to suit your own line of reasoning
-    <braunr> implying we all agree this is the priority
-    <LibreMan> being a priority doesn't mean it is there "alone", does it?
-    <braunr> it means it's the only one
-    <LibreMan> in another words, do you reject the possibility of enjoying
-      working on a project and doing it for freedom? because it seems you
-      somehow do not allow for that possibility
-    <braunr> if we agree on it, we can't have multiple priorities per people
-    <braunr> yes, that's what we're saying
-    <braunr> freedom isn't a goal
-    <braunr> it's a constraint
-    <braunr> the project *has* to be free
-    <LibreMan> so if you;re doing something to achieve freedom you can not BY
-      DEFINITION enjoy it? :D
-    <braunr> LibreMan: more or less, yes
-    <braunr> i enjoy the technical aspect, i advocate freedom
-    <LibreMan> then I've just disproven you :) I do things for freedom and
-      enjoy them
-    <braunr> no, not for freedom
-    <LibreMan> yes, for freedom
-    <braunr> i'm telling you it's not what motivates me to write code
-    <LibreMan> if I did not believe in freedom I wouldn't do them
-    <LibreMan> and I'm not talking about you
-    <braunr> i believe in freedom, my job consists of developing mostly
-      proprietary software
-    <braunr> how can you disprove me if you're not talking about me on this ?
-    <LibreMan> you said it's not possible IN PRINCIPLE, well antrik did and you
-      agreed - if you did not follow his line of argument then do not try to
-      continue where he left off ;)
-    <braunr> what project have you worked on ?
-    <LibreMan> my personal ones, nothing big
-    <braunr> so you're not a hacker, you're excluded from the group considered
-    <LibreMan> I'll tell you when it cathes on :)
-    <braunr> (bam)
-    <LibreMan> so now you decide who is and is not a hacker, well ... :)
-    <braunr> :)
-    <LibreMan> but ok, let's not talk about me I concede that I'm a lousy one
-      if any :)
-    <LibreMan> what about RMS, do you consider him a hacker?
-    <braunr> i think he became a hacker for other reasons than freedom
-    <LibreMan> would you say he is not motivated by freedom (if that can be
-      even concieved of)? :)
-    <braunr> and sees freedom as necessary too
-    <braunr> i can't say, i don't know him
-    <antrik> braunr: nope. in fact we discussed this in the past. someone even
-      worked on GSoC project bringing Hurd/Mach features to NetBSD -- but AFAIK
-      nothing came out of it
-    <braunr> antrik: ok
-    <LibreMan> well, he is pretty vocal with plenty of writings ... on the
-      other hand you seemed to know me well enough to proclaim me a non-hacker
-    <braunr> i don't know why he worked on emacs and gcc rather than the hurd
-      :p
-    <braunr> but something other than freedom must have motivated such choices
-    <antrik> I'm uncertain though whether NetBSD is a more useful base than
-      Linux. it would offer advantages on the licensing front, but it would not
-      offer the advantage that people could just run it on their existing
-      systems...
-    <LibreMan> gcc seems pretty significant for Linux lol
-    <braunr> antrik: true
-    <LibreMan> or GNU
-    <braunr> antrik: there are already system call stubs, and the VM is very,
-      very similar
-    <braunr> LibreMan: the hurd was too, at the time
-    <LibreMan> he can not work on everything
-    <braunr> so he ahd to choose, and based his choice on something else than
-      freedom (since all these projects are free)
-    <braunr> i guess he enjoyed emacs more
-    <antrik> LibreMan: RMS is not much of a practicing hacker anymore
-      nowadays...
-    <antrik> braunr: yeah, that's another advantage of using NetBSD as a
-      base... it might be easier to do
-    <braunr> LibreMan: what was your original question again ?
-    <braunr> i've been somewhat ironic since that trademark stuff, i'm serious
-      again now
-    <antrik> LibreMan: again, freedom is a factor for many of us; but not the
-      primary motivation
-    <antrik> (as braunr put, being free software is mandatory for us; but that
-      doesn't mean the main reason for working on the Hurd is some indirect
-      benefit for the free software movement...)
-    <LibreMan> braunr: the original goal was to understand the strong points of
-      Hurd to I can help communicate them to other hackers who might be
-      interested in Hurd
-    <LibreMan> because I wanted it to succeed to advance freedom more
-    <antrik> LibreMan: well, practice what you preach ;-)
-    <LibreMan> but now that I've founf that not even devs themselves are that
-      much interested in freedom I do not have that desire anymore
-    <antrik> you will hardly motivate other hackers to work on something you do
-      not even work on yourself...
-    <LibreMan> and focus my attention somewhere else
-    <antrik> [sigh]
-    <braunr> well, you can now state that the hurd has an elegant architecture
-      allowing many ugly hacks to disappear, and that it doesn't yet handle
-      sata drives or usb keys or advandced multicast routing or ...
-    <antrik> LibreMan: how about you listen to what we are saying?
-    <LibreMan> antrik: so I should work on everything in the world that
-      advances freedom or shut up?
-    <antrik> LibreMan: we *are* interested in freedom. we would work on nothing
-      else than a free software system. it's just not the primary motivation
-      for working on the Hurd
-    <antrik> if you primary motivation is advancing free software, the Hurd is
-      probably indeed not the right project to work on. other projects are more
-      important for that
-    <antrik> and that's got nothing to do with our priorities
-    <antrik> it's simply a matter of what areas free software is most lacking
-      in. the kernel is not one of them.
-    <braunr> antrik: my primary concern with netbsd are drivers
-    <LibreMan> I naively assumed that people working on a GNU project will
-      share GNU vlaues, instead I find that some of them poke fun at its high
-      priority projects
-    <braunr> i poke fun at you
-    <braunr> because you think trademark has any real value on the free
-      software community
-    <LibreMan> braunr: I see, congratulations ... I hope you enjoy it
-    <antrik> if there were no suitable free software kernels around, many
-      people might work on the Hurd mostly to advance free software. but as it
-      stands, having a GNU kernel is secondary
-    <braunr> yes, freedom is a primary goal when there are no free alternatives
-    <antrik> LibreMan: you are accusing us of not sharing GNU values, which is
-      quite outrageous I must say
-    <braunr> LibreMan: actually no, i'd prefer converstation with someone who
-      understands what i'm saying
-    <braunr> even if he contradicts me, like antrik often does
-    <braunr> (but he's usually right)
-    <braunr> LibreMan: you just don't want to accept some (many) of us are here
-      more for technical reasons than ethical ones
-    <LibreMan> antrik: well, some of your reasoning and tone would seem to
-      suggest so ...
-    <braunr> i didn't see antrik being particularly aggressive, but personally,
-      i react badly to stupidity
-    <LibreMan> braunr: WHAT? I've never said anything about what you should or
-      should not do or believe
-    <braunr> you clearly expected something when you first arrived
-    <LibreMan> I said I personally expected more enhusiastic people concerning
-      GNU and freedom but that was my personal expectaion and my personal
-      disappointment
-    <antrik> what makes you think we are not enthusiastic about GNU and
-      software freedom?
-    <braunr> more enthusiastic is vague, you expected us to be some sort of
-      freedom fighters
-    <antrik> just for the record, I'm part of the German core team of the FSFE
-    <braunr> i even stated early that we're mostly part of the free software
-      rather than open source movement, and you still find our point of view
-      disappointing
-    <antrik> still, it's not my major motivation for working on the Hurd
-    <antrik> I don't see any contradiction in that
-    <LibreMan> I don;t know maybe I misunderstand you, I do not mean any
-      disrespect
-    <braunr> me neither
-    <LibreMan> maybe "hackers" truly do think differently than I expected them
-      to in general and it's not specific to Hurd
-    <braunr> well the very word hacker describe someone interested by "hacking"
-      down something to get to understand it
-    <braunr> it's strongly technical
-    <LibreMan> antrik: why are you a core team member of th FSFE? what do you
-      do there and why? is that not motivated by the desire for more freedom?
-    <braunr> and we're lucky, many of them aren't deeply concerned with money
-      and secrecy, and prefer being open about their work
-    <braunr> you still don't get it ...
-    <antrik> LibreMan: of course it is
-    <antrik> and hacking free software in general also is (partly) motivated by
-      that
-    <antrik> but hacking on the Hurd specifically not so much
-    <braunr> 20:23 < antrik> LibreMan: we *are* interested in freedom. we would
-      work on nothing else than a free software system. it's just not the
-      primary motivation for working on the Hurd
-    <braunr> he already answered your question there
-    <antrik> (as I already said, it *is* in fact part of the motivation in my
-      case... just not the major part)
-    <LibreMan> antrik: but if it ever achieved wide success and you would be
-      asy on a "board" to decide future direction would you choose for exacmple
-      to prevent TiVO-ization over wider adpotion?
-    <braunr> we already answered that too
-    <antrik> LibreMan: that's actually not even for us to decide, as long as we
-      are an official GNU project
-    <antrik> but of course we are a GNU project because we *do* believe in
-      software freedom, and obviously wouldn't accept Tivoisation
-    <braunr> (and our discussion about using netbsd as a code base is a
-      relevant example of license concerns)
-    <LibreMan> I'm really trying to get to the core of "not motivated by
-      freedom" but being "interested in freedom" ... I really do not get that,
-      if you are interested in freedom wouldn't you want a project you work on
-      being used to advance it as much as possible and therefore be also
-      motivated to do it the best while enjoying it to achieve the goal of more
-      freedom since you value it that much?
-    <braunr> LibreMan: except for the GPLv2 vs GPLv3 debate, i don't see where
-      there can be a conflict between freedom and technical interest
-    <LibreMan> braunr: the issues around freedom are mainly not technical
-      ... GPLv2 and GPLv3 is also not about technical interests
-    <braunr> that's my problem with you, i fail to see where the problem you
-      think of is
-    <LibreMan> it tends to be about the possibility to extract money and impose
-      your will on the users which turns out to be highly profitable and
-      politicaly desirable in some instances
-    <LibreMan> of course it's technically the best to open-source but how are
-      you going to sell a product like that? that is the main question
-      troubling most corporations
-    <LibreMan> ok, I'm not going to bore you any more ;) I found out what I
-      needed to know ... now I'm going to try to forget about Hurd and focus on
-      something else where my help can be more effective  at achieving what I
-      want ;) good luck with your endavours
-    <antrik> LibreMan: of course we hope for the Hurd to advance the cause of
-      freedom, just like any free software we would work on... still, it's not
-      the primary reason why we work on the Hurd, instead of the myriads of
-      other free software projects out there
-
-
-# IRC, freenode, #hurd, 2012-04-09
-
-    <antono> what is the most impressive thing about hurd you wold like to
-      promote?
-    <antono> killing feature
-    <antono> i've created some simple hurd screencasts here
-      http://shelr.tv/records/search?utf8=%E2%9C%93&q=hurd
-    <antono> but probably i could share something more interesting :)
-    <antrik> antono: if we had such an obvious killer feature, we wouldn't have
-      to struggle ;-)
-    <antrik> the problem is that the advantages of the Hurd architecture are
-      too abstract for the vast majority of people to take them seriously
-    <antrik> IMHO the most interesting part of the Hurd is the fully
-      decentralised (and thus infinitely extensible) VFS mechanism
-    <antrik> but even that is very abstract...
-    <antono> antrik: cand i do somenthing relly fundamental with hurd
-      translator?
-    <antono> for example i hate old school unix FHS
-    <antono> I would like to have only /Users/me and /System/GNU 
-    <antono> and i would like to only see it, but behinde the scenes it should
-      be Debian with FHS layout
-    <antono> is it possible?
-    <antrik> antono: of course. not sure translators offer much advantage over
-      FUSE in this case though... it doesn't really change the functionality of
-      the VFS; only rearranges the tree a bit
-    <antrik> (might even be doable with standard Linux features)
-
-
-# IRC, freenode, #hurd, 2012-07-25
-
-    <braunr> because it has design problems, because it has implementation
-      problems, lots of problems, and far too few people to keep up with other
-      systems that are already dominating
-    <braunr> also, considering other research projects get much more funding
-      than we do, they probably have a better chance at being adopted
-    <rah> you consider the Hurd to be a research project?
-    <braunr> and as they're more recent, they sometimes overcome some of the
-      issues we have
-    <braunr> yes and no
-    <braunr> yes because it was, at the time of its creation, and it hasn't
-      changed much, and there aren't many (any?) other systems with such a
-      design
-    <braunr> and no because the hurd is actually working, and being released as
-      part of something like debian
-    <braunr> which clearly shows it's able to do the stuff it was intended for
-    <braunr> i consider it a technically very interesting project for
-      developers who want to know more about microkernel based extensible
-      systems
-    <antrik> rah: I don't expect the Hurd to achieve world domination, because
-      most people consider Linux "good enough" and will stick with it
-    <antrik> I for my part think though we could do better than Linux (in
-      certain regards I consider important), which is why I still consider it
-      interesting and worthwhile
-    <nowhere_man> I think that in some respect the OS scene may evolve a bit
-      like the PL one, where everyone progressively adopts ideas from Lisp but
-      doesn't want to do Lisp: everyone slowly shifts towards what µ-kernels
-      OSes have done from the start, but they don't want µ-kernels...
-    <braunr> nowhere_man: that's my opinion too
-    <braunr> and this is why i think something like the hurd still has valuable
-      purpose
-    <nowhere_man> braunr: in honesty, I still ponder the fact that it's my
-      coping mechanism to accept being a Lisp and Hurd fan ;-)
-    <braunr> nowhere_man: it can be used that way too
-    <braunr> functional programming is getting more and more attention
-    <braunr> so it's fine if you're a lisp fan really
-
-
-# IRC, freenode, #hurd, 2013-02-04
-
-    <civodul> BTW, it's weird that the mission statement linked from
-      hurd.gnu.org is in weblog/ and written in the first person
-    <braunr> yes
-    <braunr> very :)
diff --git a/open_issues/mmap_crash_etc.mdwn b/open_issues/mmap_crash_etc.mdwn
deleted file mode 100644
index 4946a5a0..00000000
--- a/open_issues/mmap_crash_etc.mdwn
+++ /dev/null
@@ -1,95 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-Several issues here:
-
-  * [[!tag open_issue_glibc open_issue_gnumach]] Even invalid `mmap` shoudn't
-    crash the process.
-
-  * [[!tag open_issue_documentation]] The memory layout example should be
-    documented.
-
-  * [[!tag open_issue_gnumach]] New `vm_map` allocation strategy may be
-    desirable; see also [[placement_of_virtual_memory_regions]].
-
-  * [[!tag open_issue_glibc]] *task X deallocating an invalid port Y, most
-    probably a bug*.
-
-IRC, freenode, #hurd, 2011-08-11
-
-    < zyg> oh, mmap sigsegvs, strange.
-    < braunr> hwo do you see that ?
-    < zyg> braunr: I'll try to paste a minimal case
-    < braunr> zyg: make sure you have a sane memory setup
-    < braunr> 512 RAM / 1G swap seems good
-    < braunr> have more swap than RAM
-    < zyg> I have those. Still it shouldn't sigsegv.
-    < braunr> gnumach is picky about that
-    < braunr> and yes, the hurd shouldn't have bugs
-    < zyg> braunr: ready to crash? #include <stdio.h> #include <sys/mman.h> int
-      main (int argc, char **argv) { mmap(0x10000, 0x8000, PROT_READ, MAP_ANON
-      | MAP_FIXED, -1, 0); return 0; }
-    < braunr> a fixed mapping at such an address is likely to fail, yes
-    < braunr> but a crash, hm
-    < zyg> why should it fail?
-    < braunr> because the hurd doesn't have a common text data bss heap stack
-      layout
-    < braunr> e.g. there are mappings below text, as show by vminfo :
-    < braunr> $ vminfo $$
-    < braunr>          0[0x1000] (prot=0)
-    < braunr>     0x1000[0x21000] (prot=RX, max_prot=RWX, mem_obj=105)
-    < braunr>    0x22000[0x1000] (prot=R, max_prot=RWX, mem_obj=105)
-    < braunr>    0x23000[0x1000] (prot=RW, max_prot=RWX, mem_obj=105)
-    < braunr>    0x24000[0x1000] (prot=0, max_prot=RWX)
-    < braunr>    0x25000[0xfff000] (prot=RWX, mem_obj=106)
-    < braunr>  0x1024000[0x1000] (prot=RWX, mem_obj=107)
-    < braunr>  0x1025000[0x1000] (prot=RW, max_prot=RWX, mem_obj=108)
-    < braunr>  0x1026000[0x1000] (prot=RW, max_prot=RWX, mem_obj=108,
-      offs=0x1000)
-    < braunr>  0x1027000[0x1000] (prot=RW, max_prot=RWX, mem_obj=109)
-    < braunr>  0x1028000[0x2000] (prot=RW, max_prot=RWX, mem_obj=110,
-      offs=0x1000)
-    < braunr>  0x102a000[0x1000] (prot=RW, max_prot=RWX, mem_obj=111)
-    < braunr> (sorry for the long paste)
-    < zyg> oh.. my mmap falls into an occupied range?
-    < braunr> seems so
-    < zyg> thanks, that was really useful.
-    < braunr> MAP_FIXED isn't portable, this is clearly stated in most man
-      pages
-    < zyg> yes, implementation specific it says
-    < braunr> well the behaviour isn't specific, it's well defined, but the
-      memory layout isn't
-    < braunr> i personally think vm_map() should be slightly changed to include
-      a new flag for top-down allocations
-    < braunr> so that our stack and libraries are at high addresses, below the
-      kernel
-    < braunr> zyg: what kind of error do you get ? i don't get sigsegv
-    < zyg> I get both sigsegv and sigill depending on addr
-    < braunr> ok
-    < braunr> i get sigill with your example
-    < braunr> the error is the same (wrong memory access) but the behaviour
-      changes because of the special memory configuration
-    < zyg> yes.. I guess the usecase is too uncommon. Else mmap would have an
-      guard
-    < braunr> some accesses cause invalid page faults (which are sent as
-      segmentation faults) while other cause general protection faults (which
-      are sent as illegal instructions)
-    < braunr> (this is quite weird since the GP fault is likely because the
-      access targets something out of the data or code segment eh)
-    < zyg> braunr: that's very os-specific. Do you mean hurd behaves that way?
-    < braunr> gnumach
-    < braunr> on i386
-    < braunr> the segmant configuration isn't completely flat
-    < braunr> segment*
-    < braunr> hm nice
-    < braunr> your small program triggers the "task X deallocating an invalid
-      port Y, most probably a bug." message
-    < zyg> where do you see that?
-    < braunr> on the mach console
diff --git a/open_issues/mmap_write-only.mdwn b/open_issues/mmap_write-only.mdwn
deleted file mode 100644
index b64e8641..00000000
--- a/open_issues/mmap_write-only.mdwn
+++ /dev/null
@@ -1,57 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012 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_llvm]]
-
-
-# IRC, freenode, #hurd, 2011-12-14
-
-    <pinotree> hm, interesting mmap bug
-    <youpi> ?
-    <pinotree> youpi: http://paste.debian.net/149252/
-    #include <sys/types.h>
-    #include <sys/mman.h>
-    #include <fcntl.h>
-    #include <stdio.h>
-    #include <errno.h>
-    #include <stdlib.h>
-    #include <string.h>
-    #include <unistd.h>
-    
-    void die(int x, const char *s)
-    {
-      perror(s);
-      exit(x);
-    }
-    
-    static const char s_file[] = "foo-mmaptest";
-    
-    int main()
-    {
-      int fd;
-      void *p;
-    
-      fd = creat(s_file, 0777);
-      if (fd < 0) die(1, "creat");
-      errno = 0;
-      p = mmap(NULL, 1, PROT_READ, MAP_SHARED, fd, 0);
-      printf("> %p vs %p, %d (%s)\n", p, MAP_FAILED, errno, strerror(errno));
-      unlink(s_file);
-      return (p != MAP_FAILED);
-    }
-    <pinotree> on linux it returns 0 and fails with EACCESS (as it seems it
-      should, by reading the mmap posix docs), on hurd it returns 1 and the
-      mmap succeeds
-    <pinotree> (taken from llvm's configure)
-    <youpi> why should it? file size extension ?
-    <pinotree> creat creates a o_wronly file, while the mmap specifies only
-      read protection
-    <youpi> oh, craet is always wo
-    <youpi> I didn't know that
diff --git a/open_issues/mondriaan_memory_protection.mdwn b/open_issues/mondriaan_memory_protection.mdwn
deleted file mode 100644
index 2c7b9ba1..00000000
--- a/open_issues/mondriaan_memory_protection.mdwn
+++ /dev/null
@@ -1,85 +0,0 @@
-[[!meta copyright="Copyright © 2013 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]]."]]"""]]
-
-<http://scale.eecs.berkeley.edu/mondriaan/>.
-
-
-# IRC, freenode, #hurd, 2013-07-02
-
-    <xscript> in any case, what I wanted to check is if current hurd support
-      PIE
-    <xscript`> I just saw samuel posted some fixes to have PIE working in hurd
-    <xscript`> are those included in the official image?
-    <youpi> sure
-    <youpi> it's just a trivial fixup in some address calculation code
-    <xscript> youpi: nice
-    <xscript> and does anyone know how complex would it be to implement some
-      hackish support to have non-overlapping virtual addresses for
-      applications supporting PIE?
-    <braunr> not too difficult
-    <xscript> really? I didn't expect such an answer XD
-    <xscript> I'd like to have something similar to a SASOS
-    <xscript> (single address space os)
-    <braunr> ?
-    <braunr> you mean an sasos on top of mach ?
-    <xscript> yes, but only for a few apps I want to evaluate
-    <braunr> i see
-    <xscript> the optimal would be to have all of hurd's servers on that mode
-    <braunr> you'l probably need to implement a small allocator but other than
-      that it shouldn't be too hard, yes
-    <braunr> uh ??
-    <xscript> but running on 32 bits can be a problem here
-    <braunr> and not hurdish at all
-    <xscript> what's not hurdish?
-    <braunr> we do want address space separation
-    <xscript> well, you can have multiple address spaces (page tables), but
-      without overlapping addresses between them
-    <xscript> that's exactly what I'm looking for
-    <braunr> sorry i don't see what you mean
-    <braunr> if you run several servers in the same address space, they can
-      corrupt each other
-    <braunr> we don't want that
-    <braunr> it's that simple
-    <xscript> yes, sorry, I didn't explain myself
-    <xscript> I want a separate address space on each server
-    <xscript> but I want all memory allocations to be on addresses unique to
-      the whole OS
-    <braunr> that still doesn't make sense
-    <xscript> well, it will still be secure
-    <xscript> but I know it does not make sense per se
-    <xscript> I want to do some experiments with a simulator
-    <braunr> why do you want them non overlapping if they're separate ?
-    <xscript> well, in my simulator I wouldn't need to change the page tables,
-      protection is provided through other means
-    <braunr> segmentation ?
-    <xscript> that's one possibility
-    <xscript> (small address spaces)
-    <braunr> what do you have in mind ?
-    <braunr> it wouldn't be on top of mach anyway then
-    <braunr> mach implements paging
-    <xscript> what I'm simulating is something of the likes of Mondriaan
-      (http://www.cs.utexas.edu/~witchel/pubs/mmp-asplos2002.pdf)
-    <xscript> paging is ok for me
-    <braunr> 19:06 < xscript> well, in my simulator I wouldn't need to change
-      the page tables, protection is provided through other means
-    <braunr> it didn't sound so
-    <xscript> I meant switching page tables (cr3, etc)
-    <braunr> mach does that
-    <xscript> I know, I know, I can just ignore that part for the moment
-    <braunr> ok
-    <xscript> for now, I'd like to morph hurd into a SASOS using one page table
-      per process
-    <xscript> I just wanted to know how hard that would be, without starting
-      with a full dive into the code
-    <xscript> there are other options (OSes, microkernels), but none of them
-      provides as many readily-available applications as hurd
-    <xscript> I suppose MINIX would also be easy to modify, but there's less
-      apps there, and I also would like to tamper with MIG
-    <xscript> I just wonder how hard it would be to modify MIG
diff --git a/open_issues/multiprocessing.mdwn b/open_issues/multiprocessing.mdwn
deleted file mode 100644
index eaaa2289..00000000
--- a/open_issues/multiprocessing.mdwn
+++ /dev/null
@@ -1,77 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 2013 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_documentation open_issue_hurd]]
-
-We would expect that fine-grained, compartmentalized systems, that is,
-microkernel-based multi-server systems in particular, would be ideal candidates
-for applying multiprocessing.  That is, however, only true from a first and
-inexperienced point of view: there are many difficulties.
-
-
-# IRC, freenode, #hurd, August / September 2010
-
-    <marcusb> silver_hook: because multi-server systems depend on inter-process
-      communication, and inter-process communication is many times more
-      expensive across cpus
-    <marcusb> silver_hook: so you either force interrelated work on the same
-      cpu, or suffer heavy penalties.  and in a typical fine-grained object
-      system, all objects are interconnected!
-    <marcusb> silver_hook: resources in today's systems, even in a single node
-      with one cpu, but more so in a network, are very non-uniform.  scheduling
-      these resources efficiently is a huge problem.  restricting the resource
-      distribution policies in the way microkernel systems tend to do is posing
-      serious research challenges
-
-
-# IRC, freenode, #hurd, 2011-07-26
-
-    < braunr> 12:03 < CTKArcher> and does the hurd take more advantages in a
-      multicore architecture than linux ?
-    < braunr> CTKArcher: short answer: no
-    < CTKArcher> it's easier to imagine one server pro core than the linux
-      kernel divided to be executed on multiple cores
-    < braunr> CTKArcher: this approach is less efficient
-    < braunr> CTKArcher: threads carry state, both explicit and implicit (like
-      cache data)
-    < braunr> CTKArcher: switching to another core means resetting and
-      refetching this state
-    < braunr> it's expensive and there is no gain obtained by doing this
-    < braunr> thread migration (having a thread from a client also run in
-      servers when making synchronous RPC, even handling its own page faults)
-      was implemented in mach4 and is imo a very good thing we should have
-    < braunr> CTKArcher: and concerning linux, it's actually very scalable
-    < braunr> it's already like if all client threads run in servers (the
-      kernel is the servers there)
-    < braunr> rcu is used a lot
-    < braunr> thread migration already takes into account smt, cores, and numa
-    < braunr> it's hard to do something better
-    < braunr> (here, thread migration means being dispatched on another cpu)
-
-
-# debian-hurd list
-
-On Thu, Jan 02, 2003 at 05:40:00PM -0800, Thomas Bushnell, BSG wrote:
-> Georg Lehner writes:
->
-> > - One promise of the microkernel architecture is better performance on
-> >   multiprocessor systems, or multicomputer systems. What is the status
-> >   of Gnu Mach with respect to these.
->
-> This may or may not be true.  The Hurd is built around a microkernel
-> architecture because of its conceptual elegance and flexibility.
-> Other touted advantages may be more illusory than real, at least, they
-> aren't something *we* are proclaiming is our motivation.
-
-
----
-
-See also: [[multithreading]].
diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn
deleted file mode 100644
index a66202c8..00000000
--- a/open_issues/multithreading.mdwn
+++ /dev/null
@@ -1,601 +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_hurd]]
-
-Hurd servers / VFS libraries are multithreaded.  They can even be said to be
-"hyperthreaded".
-
-
-# Implementation
-
-  * well-known threading libraries
-
-      * [[hurd/libthreads]]
-
-      * [[hurd/libpthread]]
-
-## IRC, freenode, #hurd, 2011-04-20
-
-    <braunr> so basically, a thread should consume only a few kernel resources
-    <braunr> in GNU Mach, it doesn't even consume a kernel stack because only
-      continuations are used
-
-[[microkernel/mach/gnumach/continuation]].
-
-    <braunr> and in userspace, it consumes 2 MiB of virtual memory, a few table
-      entries, and almost no CPU time
-    <svante_> What does "hyperthreaded" mean: Do you have a reference?
-    <braunr> in this context, it just means there are a lot of threads
-    <braunr> even back in the 90s, the expected number of threads could scale
-      up to the thousand
-    <braunr> today, it isn't much impressive any more
-    <braunr> but at the time, most systems didn't have LWPs yet
-    <braunr> and a process was very expensive
-    <svante_> Looks like I have some catching up to do: What is "continuations"
-      and LWP? Maybe I also need a reference to an overview on multi-threading.
-    <ArneBab> Lightweight process?
-      http://en.wikipedia.org/wiki/Light-weight_process
-    <braunr> LWPs are another names for kernel threads usually
-    <braunr> most current kernels support kernel preemption though
-
-[[microkernel/mach/gnumach/preemption]].
-
-    <braunr> which means their state is saved based on scheduler decisions
-    <braunr> unlike continuations where the thread voluntarily saves its state
-    <braunr> if you only have continuations, you can't have kernel preemption,
-      but you end up with one kernel stack per processor
-    <braunr> while the other model allows kernel preemption and requires one
-      kernel stack per thread
-    <svante_> I know resources are limited, but it looks like kernel preemption
-      would be nice to have. Is that too much for a GSoC student?
-    <braunr> it would require a lot of changes in obscure and sensitive parts
-      of the kernel
-    <braunr> and no, kernel preemption is something we don't actually need
-    <braunr> even current debian linux kernels are built without kernel
-      preemption
-    <braunr> and considering mach has hard limitations on its physical memory
-      management, increasing the amount of memory used for kernel stacks would
-      imply less available memory for the rest of the system
-    <svante_> Are these hard limits in mach difficult to change?
-    <braunr> yes
-    <braunr> consider mach difficult to change
-    <braunr> that's actually one of the goals of my stalled project
-    <braunr> which I hope to resume by the end of the year :/
-    <svante_> Reading Wikipedia it looks like LWP are "kernel treads" and other
-      threads are "user threads" at least in IBM/AIX. LWP in Linux is a thread
-      sharing resources and in SunOS they are "user threads". Which is closest
-      for Hurd?
-    <braunr> i told you
-    <braunr> 14:09 < braunr> LWPs are another names for kernel threads usually
-    <svante_> Similar to to the IBM definition then? Sorry for not remembering
-      what I've  been reading.
-
-
-# Design
-
-## Application Programs
-
-### [[glibc/signal/signal_thread]]
-
-## Hurd Servers
-
-See [[hurd/libports]]: roughly using one thread per
-incoming request.  This is not the best approach: it doesn't really make sense
-to scale the number of worker threads with the number of incoming requests, but
-instead they should be scaled according to the backends' characteristics.
-
-The [[hurd/Critique]] should have some more on this.
-
-[*Event-based Concurrency
-Control*](http://soft.vub.ac.be/~tvcutsem/talks/presentations/T37_nobackground.pdf),
-Tom Van Cutsem, 2009.
-
-
-### IRC, freenode, #hurd, 2012-07-08
-
-    <youpi> braunr: about limiting number of threads, IIRC the problem is that
-      for some threads, completing their work means triggering some action in
-      the server itself, and waiting for it (with, unfortunately, some lock
-      held), which never terminates when we can't create new threads any more
-    <braunr> youpi: the number of threads should be limited, but not globally
-      by libports
-    <braunr> pagers should throttle their writeback requests
-    <youpi> right
-
-
-### IRC, freenode, #hurd, 2012-07-16
-
-    <braunr> hm interesting
-    <braunr> when many threads are creating to handle requests, they
-      automatically create a pool of worker threads by staying around for some
-      time
-    <braunr> this time is given in the libport call
-    <braunr> but the thread always remain
-    <braunr> they must be used in turn each time a new requet comes in
-    <braunr> ah no :(, they're maintained by the periodic sync :(
-    <braunr> hm, still not that, so weird
-    <antrik> braunr: yes, that's a known problem: unused threads should go away
-      after some time, but that doesn't actually happen
-    <antrik> don't remember though whether it's broken for some reason, or
-      simply not implemented at all...
-    <antrik> (this was already a known issue when thread throttling was
-      discussed around 2005...)
-    <braunr> antrik: ok
-    <braunr> hm threads actually do finish ..
-    <braunr> libthreads retain them in a pool for faster allocations
-    <braunr> hm, it's worse than i thought
-    <braunr> i think the hurd does its job well
-    <braunr> the cthreads code never reaps threads
-    <braunr> when threads are finished, they just wait until assigned a new
-      invocation
-
-    <braunr> i don't understand ports_manage_port_operations_multithread :/
-    <braunr> i think i get it
-    <braunr> why do people write things in such a complicated way ..
-    <braunr> such code is error prone and confuses anyone
-
-    <braunr> i wonder how well nested functions interact with threads when
-      sharing variables :/
-    <braunr> the simple idea of nested functions hurts my head
-    <braunr> do you see my point ? :) variables on the stack automatically
-      shared between threads, without the need to explicitely pass them by
-      address
-    <antrik> braunr: I don't understand. why would variables on the stack be
-      shared between threads?...
-    <braunr> antrik: one function declares two variables, two nested functions,
-      and use these in separate threads
-    <braunr> are the local variables still "local"
-    <braunr> ?
-    <antrik> braunr: I would think so? why wouldn't they? threads have separate
-      stacks, right?...
-    <antrik> I must admit though that I have no idea how accessing local
-      variables from the parent function works at all...
-    <braunr> me neither
-
-    <braunr> why don't demuxers get a generic void * like every callback does
-      :((
-    <antrik> ?
-    <braunr> antrik: they get pointers to the input and output messages only
-    <antrik> why is this a problem?
-    <braunr> ports_manage_port_operations_multithread can be called multiple
-      times in the same process
-    <braunr> each call must have its own context
-    <braunr> currently this is done by using nested functions
-    <braunr> also, why demuxers return booleans while mach_msg_server_timeout
-      happily ignores them :(
-    <braunr> callbacks shouldn't return anything anyway
-    <braunr> but then you have a totally meaningless "return 1" in the middle
-      of the code
-    <braunr> i'd advise not using a single nested function
-    <antrik> I don't understand the remark about nested function
-    <braunr> they're just horrible extensions
-    <braunr> the compiler completely hides what happens behind the scenes, and
-      nasty bugs could come out of that
-    <braunr> i'll try to rewrite ports_manage_port_operations_multithread
-      without them and see if it changes anything
-    <braunr> but it's not easy
-    <braunr> also, it makes debugging harder :p
-    <braunr> i suspect gdb hangs are due to that, since threads directly start
-      on a nested function
-    <braunr> and if i'm right, they are created on the stack
-    <braunr> (which is also horrible for security concerns, but that's another
-      story)
-    <braunr> (at least the trampolines)
-    <antrik> I seriously doubt it will change anything... but feel free to
-      prove me wrong :-)
-    <braunr> well, i can see really weird things, but it may have nothing to do
-      with the fact functions are nested
-    <braunr> (i still strongly believe those shouldn't be used at all)
-
-
-### IRC, freenode, #hurd, 2012-08-31
-
-    <braunr> and the hurd is all but scalable
-    <gnu_srs> I thought scalability was built-in already, at least for hurd??
-    <braunr> built in ?
-    <gnu_srs> designed in
-    <braunr> i guess you think that because you read "aggressively
-      multithreaded" ?
-    <braunr> well, a system that is unable to control the amount of threads it
-      creates for no valid reason and uses global lock about everywhere isn't
-      really scalable
-    <braunr> it's not smp nor memory scalable
-    <gnu_srs> most modern OSes have multi-cpu support.
-    <braunr> that doesn't mean they scale
-    <braunr> bsd sucks in this area
-    <braunr> it got better in recent years but they're way behind linux
-    <braunr> linux has this magic thing called rcu
-    <braunr> and i want that in my system, from the beginning
-    <braunr> and no, the hurd was never designed to scale
-    <braunr> that's obvious
-    <braunr> a very common mistake of the early 90s
-
-
-### IRC, freenode, #hurd, 2012-09-06
-
-    <braunr> mel-: the problem with such a true client/server architecture is
-      that the scheduling context of clients is not transferred to servers
-    <braunr> mel-: and the hurd creates threads on demand, so if it's too slow
-      to process requests, more threads are spawned
-    <braunr> to prevent hurd servers from creating too many threads, they are
-      given a higher priority
-    <braunr> and it causes increased latency for normal user applications
-    <braunr> a better way, which is what modern synchronous microkernel based
-      systems do
-    <braunr> is to transfer the scheduling context of the client to the server
-    <braunr> the server thread behaves like the client thread from the
-      scheduler perspective
-    <gnu_srs> how can creating more threads ease the slowness, is that a design
-      decision??
-    <mel-> what would be needed to implement this?
-    <braunr> mel-: thread migration
-    <braunr> gnu_srs: is that what i wrote ?
-    <mel-> does mach support it?
-    <braunr> mel-: some versions do yes
-    <braunr> mel-: not ours
-    <gnu_srs> 21:49:03) braunr: mel-: and the hurd creates threads on demand,
-      so if it's too slow to process requests, more threads are spawned
-    <braunr> of course it's a design decision
-    <braunr> it doesn't "ease the slowness"
-    <braunr> it makes servers able to use multiple processors to handle
-      requests
-    <braunr> but it's a wrong design decision as the number of threads is
-      completely unchecked
-    <gnu_srs> what's the idea of creating more theads then, multiple cpus is
-      not supported?
-    <braunr> it's a very old decision taken at a time when systems and machines
-      were very different
-    <braunr> mach used to support multiple processors
-    <braunr> it was expected gnumach would do so too
-    <braunr> mel-: but getting thread migration would also require us to adjust
-      our threading library and our servers
-    <braunr> it's not an easy task at all
-    <braunr> and it doesn't fix everything
-    <braunr> thread migration on mach is an optimization
-    <mel-> interesting
-    <braunr> async ipc remains available, which means notifications, which are
-      async by nature, will create messages floods anyway
-
-
-### IRC, freenode, #hurd, 2013-02-23
-
-    <braunr> hmm let's try something
-    <braunr> iirc, we cannot limit the max number of threads in libports
-    <braunr> but did someone try limiting the number of threads used by
-      libpager ?
-    <braunr> (the only source of system stability problems i currently have are
-      the unthrottled writeback requests)
-    <youpi> braunr: perhaps we can limit the amount of requests batched by the
-      ext2fs sync?
-    <braunr> youpi: that's another approach, yes
-    <youpi> (I'm not sure to understand what threads libpager create)
-    <braunr> youpi: one for each writeback request
-    <youpi> ew
-    <braunr> but it makes its own call to
-      ports_manage_port_operations_multithread
-    <braunr> i'll write a new ports_manage_port_operations_multithread_n
-      function that takes a mx threads parameter
-    <braunr> and see if it helps
-    <braunr> i thought replacing spin locks with mutexes would help, but it's
-      not enough, the true problem is simply far too much contention
-    <braunr> youpi: i still think we should increase the page dirty timeout to
-      30 seconds
-    <youpi> wouldn't that actually increase the amount of request done in one
-      go?
-    <braunr> it would
-    <braunr> but other systems (including linux) do that
-    <youpi> but they group requests
-    <braunr> what linux does is scan pages every 5 seconds, and writeback those
-      who have been dirty for more than 30 secs
-    <braunr> hum yes but that's just a performance issue
-    <braunr> i mean, a separate one
-    <braunr> a great source of fs performance degradation is due to this
-      regular scan happenning at the same time regular I/O calls are made
-    <braunr> e.G. aptitude update
-    <braunr> so, as a first step, until the sync scan is truley optimized, we
-      could increase that interval
-    <youpi> I'm afraid of the resulting stability regression
-    <youpi> having 6 times as much writebacks to do
-    <braunr> i see
-    <braunr> my current patch seems to work fine for now
-    <braunr> i'll stress it some more
-    <braunr> (it limits the number of paging threads to 10 currently)
-    <braunr> but iirc, you fixed a deadlock with a debian patch there
-    <braunr> i think the case was a pager thread sending a request to the
-      kernel, and waiting for the kernel to call another RPC that would unblock
-      the pager thread
-    <braunr> ah yes it was merged upstream
-    <braunr> which means a thread calling memory_object_lock_request with sync
-      == 1 must wait for a memory_object_lock_completed
-    <braunr> so it can deadlock, whatever the number of threads
-    <braunr> i'll try creating two separate pools with a limited number of
-      threads then
-    <braunr> we probably have the same deadlock issue in
-      pager_change_attributes btw
-    <braunr> hm no, i can still bring a hurd down easily with a large i/o
-      request :(
-    <braunr> and now it just recovered after 20 seconds without any visible cpu
-      or i/o usage ..
-    <braunr> i'm giving up on this libpager issue
-    <braunr> it simply requires a redesign
-
-
-### IRC, freenode, #hurd, 2013-02-28
-
-    <smindinvern> so what causes the stability issues?  or is that not really
-      known yet?
-    <braunr> the basic idea is that the kernel handles the page cache
-    <braunr> and writebacks aren't correctly throttled
-    <braunr> so a huge number of threads (several hundreds, sometimes
-      thousands) are created
-    <braunr> when this pathological state is reached, it's very hard to recover
-      because of the various sources of (low) I/O in the system
-    <braunr> a simple line sent to syslog increases the load average
-    <braunr> the solution requires reworking the libpager library, and probably
-      the libdiskfs one too, perhaps others, certainly also the pagers
-    <braunr> maybe the kernel too, i'm not sure
-    <braunr> i'd say so because it manages a big part of the paging policy
-
-
-### IRC, freenode, #hurd, 2013-03-02
-
-    <braunr> i think i have a simple-enough solution for the writeback
-      instability
-
-[[hurd/libpager]].
-
-
-### IRC, freenode, #hurd, 2013-03-29
-
-    <braunr> some day i'd like to add a system call that threads can use to
-      terminate themselves, passing their stack as a parameter for deallocation
-    <braunr> then, we should review the timeouts used with libports management
-    <braunr> having servers go away when unneeded is a valuable and visible
-      feature of modularity
-
-[[open_issues/libpthread/t/fix_have_kernel_resources]].
-
-
-### IRC, freenode, #hurd, 2013-04-03
-
-    <braunr> youpi: i also run without the libports_stability patch
-    <braunr> and i'd like it to be removed unless you still have a good reason
-      to keep it around
-    <youpi> well, the reason I know is mentioned in the patch
-    <youpi> i.e. the box becomes unresponsive when all these threads wake up at
-      the same time
-    <youpi> maybe we could just introduce some randomness in the sleep time
-    <braunr> youpi: i didn't experience the problem
-    <youpi> well, I did :)
-    <braunr> or if i did, it was very short
-    <youpi> for the libports stability, I'd really say take a random value
-      between timeout/2 and timeout
-    <youpi> and that should just nicely fix the issue
-    <braunr> ok
-
-
-### IRC, freenode, #hurd, 2013-11-30
-
-"Thread storms".
-
-    <braunr> if you copy a large file for example, it is loaded in memory, each
-      page is touched and becomes dirty, and when the file system requests them
-      to be flushed, the kernel sends one message for each page
-    <braunr> the file system spawns a thread as soon as a message arrives and
-      there is no idle thread left
-    <braunr> if the amount of message is large and arrives very quickly, a lot
-      of threads are created
-    <braunr> and they compete for cpu time
-    <Gerhard> How do you plan to work around that?
-    <braunr> first i have to merge in some work about pagein clustering
-    <braunr> then i intend to implement a specific thread pool for paging
-      messages
-    <braunr> with a fixed size
-    <Gerhard> something compareable for a kernel scheduler?
-    <braunr> no
-    <braunr> the problem in the hurd is that it spawns threads as soon as it
-      needs
-    <braunr> the thread does both the receiving and the processing
-    <Gerhard> But you want to queue such threads?
-    <braunr> what i want is to separate those tasks for paging
-    <braunr> and manage action queues internally
-    <braunr> in the past, it was attempted to limit the amount ot threads in
-      servers, but since receiving is bound with processing, and some actions
-      in libpager depend on messages not yet received, file systems would
-      sometimes freeze
-    <Gerhard> that's entirely the task of the hurd? One cannot solve that in
-      the microkernel itself?
-    <braunr> it could, but it would involve redesigning the paging interface
-    <braunr> and the less there is in the microkernel, the better
-
-
-#### IRC, freenode, #hurd, 2013-12-03
-
-    <braunr> i think our greatest problem currently is our file system and our
-      paging library
-    <braunr> if someone can spend some time getting to know the details and
-      fixing the major problems they have, we would have a much more stable
-      system
-    <TimKack> braunr: The paging library because it cannot predict or keep
-      statistics on pages to evict or not?
-    <TimKack> braunr: I.e. in short - is it a stability problem or a
-      performance problem (or both :) )
-    <braunr> it's a scalability problem
-    <braunr> the sclability problem makes paging so slow that paging requests
-      stack up until the system becomes almost completely unresponsive
-    <TimKack> ah
-    <TimKack> So one should chase defpager code then 
-    <braunr> no
-    <braunr> defpager is for anonymous memory
-    <TimKack> vmm?
-    <TimKack> Ah ok ofc
-    <braunr> our swap has problems of its own, but we don't suffer from it as
-      much as from ext2fs
-    <TimKack> From what I have picked up from the mailing lists is the ext2fs
-      just because no one really have put lots of love in it? While paging is
-      because it is hard?
-    <TimKack> (and I am not at that level of wizardry!)
-    <braunr> no
-    <braunr> just because it was done at a time when memory was a lot smaller,
-      and developers didn't anticipate the huge growth of data that came during
-      the 90s and after
-    <braunr> that's what scalability is about
-    <braunr> properly dealing with any kind of quantity
-    <teythoon> braunr: are we talking about libpager ?
-    <braunr> yes
-    <braunr> and ext2fs
-    <teythoon> yeah, i got that one :p
-    <braunr> :)
-    <braunr> the linear scans are in ext2fs
-    <braunr> the main drawback of libpager is that it doesn't restrict the
-      amount of concurrent paging requests
-    <braunr> i think we talked about that recently
-    <teythoon> i don't remember
-    <braunr> maybe with someone else then
-    <teythoon> that doesn't sound too hard to add, is it ?
-    <teythoon> what are the requirements ?
-    <teythoon> and more importantly, will it make the system faster ?
-    <braunr> it's not too hard
-    <braunr> well
-    <braunr> it's not that easy to do reliably because of the async nature of
-      the paging requests
-    <braunr> teythoon: the problem with paging on top of mach is that paging
-      requests are asynchronous
-    <teythoon> ok
-    <braunr> libpager uses the bare thread pool from libports to deal with
-      that, i.e. a thread is spawned as soon as a message arrives and all
-      threads are busy
-    <braunr> if a lot of messages arrive in a burst, a lot of threads are
-      created
-    <braunr> libports implies a lot of contention (which should hopefully be
-      lowered with your payload patch)
-
-[[community/gsoc/project_ideas/object_lookups]].
-
-    <braunr> that contention is part of the scalability problem
-    <braunr> a simple solution is to use a more controlled thread pool that
-      merely queues requests until user threads can process them
-    <braunr> i'll try to make it clearer : we can't simply limit the amout of
-      threads in libports, because some paging requests require the reception
-      of future paging requests in order to complete an operation
-    <teythoon> why would that help with the async nature of paging requests ?
-    <braunr> it wouldn't
-    <teythoon> right
-    <braunr> thaht's a solution to the scalability problem, not to reliability
-    <teythoon> well, that kind of queue could also be useful for the other hurd
-      servers, no ?
-    <braunr> i don't think so
-    <teythoon> why not ?
-    <braunr> teythoon: why would it ?
-    <braunr> the only other major async messages in the hurd are the no sender
-      and dead name notification
-    <braunr> notifications*
-    <teythoon> we could cap the number of threads
-    <braunr> two problems with that solution
-    <teythoon> does not solve the dos issue, but makes it less interruptive,
-      no?
-    <braunr> 1/ it would dynamically scale
-    <braunr> and 2/ it would prevent the reception of messages that allow
-      operations to complete
-    <teythoon> why would it block the reception ?
-    <teythoon> it won't be processed, but accepting it should be possilbe 
-    <braunr> because all worker threads would be blocked, waiting for a future
-      message to arrive to complete, and no thread would be available to
-      receive that message
-    <braunr> accepting, yes
-    <braunr> that's why i was suggesting a separate pool just for that
-    <braunr> 15:35 < braunr> a simple solution is to use a more controlled
-      thread pool that merely queues requests until user threads can process
-      them
-    <braunr> "user threads" is a poor choice
-    <braunr> i used that to mirror what happens in current kernels, where
-      threads are blocked until the system tells them they can continue
-    <teythoon> hm
-    <braunr> but user threads don't handle their own page faults on mach
-    <teythoon> so how would the threads be blocked exactly, mach_msg ?
-      phread_locks ?
-    <braunr> probably a pthread_hurd_cond_wait_np yes
-    <braunr> that's not really the problem
-    <teythoon> why not ? that's the point where we could yield the thread and
-      steal some work from our queue
-    <braunr> this solution (a specific thread pool of a limited number of
-      threads to receive messages) has the advantage that it solves one part of
-      the scalability issue
-    <braunr> if you do that, you loose the current state, and you have to use
-      something like continuations instead
-    <teythoon> indeed ;)
-    <braunr> this is about the same as making threads uninterruptible when
-      waiting for IO in unix
-    <braunr> it makes things simpler
-    <braunr> less error prone
-    <braunr> but then, the problem has just been moved
-    <braunr> instead of a large number of threads, we might have a large number
-      of queued requests
-    <braunr> actually, it's not completely asynchronous
-    <braunr> the pageout code in mach uses some heuristics to slow down
-    <braunr> it's ugly, and is the reason why the system can get extremely slow
-      when swap is used
-    <braunr> solving that probably requires a new paging interface with the
-      kernel
-    <teythoon> ok, we will postpone this
-    <teythoon> I'll have to look at libpager for the protected payload series
-      anyways
-    <braunr> 15:38 < braunr> 1/ it would dynamically scale
-    <braunr> + not
-    <teythoon> why not ?
-    <braunr> 15:37 < teythoon> we could cap the number of threads
-    <braunr> to what value ?
-    <teythoon> we could adjust the number of threads and the queue size based
-      on some magic unicorn function
-    <braunr> :)
-    <braunr> this one deserves a smiley too
-    <teythoon> ^^
-
-
-### IRC, freenode, #hurd, 2014-03-02
-
-    <youpi> braunr: what is the status of the thread storm issue? do you have
-      pending code changes for this?
-    <youpi> I was wondering whether to make ext2fs use adaptative locks,
-      i.e. spin a bit and then block
-    <youpi> I don't remember whether anybody already did something like that
-    <braunr> youpi: no i don't
-    <braunr> youpi: i attempted switch from spin locks to mutexes once but it
-      doesn't solve the problem
-    <braunr> switching*
-    <gg0> found another storm maker:
-    <gg0> $ dpkg-reconfigure gnome-accessibility-themes
-    <gg0> aka update-icon-caches /usr/share/icons/HighContrast
-    <youpi> braunr: ok
-
-
-## Alternative approaches:
-
-  * <http://www.concurrencykit.org/>
-
-  * Continuation-passing style
-
-      * [[microkernel/Mach]] internally [[uses
-        continuations|microkernel/mach/gnumach/continuation]], too.
-
-  * [[Erlang-style_parallelism]]
-
-      * [[!wikipedia Actor_model]]; also see overlap with
-        {{$capability#wikipedia_object-capability_model}}.
-
-  * [libtcr - Threaded Coroutine Library](http://oss.linbit.com/libtcr/)
-
-  * <http://monkey.org/~provos/libevent/>
-
----
-
-See also: [[multiprocessing]].
diff --git a/open_issues/multithreading/erlang-style_parallelism.mdwn b/open_issues/multithreading/erlang-style_parallelism.mdwn
deleted file mode 100644
index 4c3651e3..00000000
--- a/open_issues/multithreading/erlang-style_parallelism.mdwn
+++ /dev/null
@@ -1,204 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2013 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_hurd]]
-
-IRC, #hurd, 2010-10-05
-
-    <sdschulze> antrik: Erlang-style parallelism might actually be interesting
-      for Hurd translators.
-    <sdschulze> There are certain similarities between Erlang's message boxes
-      and Mach ports.
-    <sdschulze> The problem is that all languages that implement the Erlang
-      actor model are VM-based.
-    <antrik> sdschulze: I guess that's because most systems don't offer this
-      kind of message passing functionality out of the box... perhaps on Hurd
-      it would be possible to implement an Erlang-like language natively?
-    <sdschulze> That would be quite attractive -- having the same API for
-      in-process parallelism and IPC.
-    <sdschulze> But I don't see why Erlang needs a VM...  It could also be
-      implemented in a library.
-    [...]
-    <sdschulze> BTW, Scala doesn't require a VM by design.  Its Erlang
-      implementation is a binary-compatible abstraction to Java.
-    [...]
-    <sdschulze> My point was that Erlang employs some ideas that might be
-      usable in the Hurd libraries.
-    <sdschulze> concerning multithreading stuff
-    <sdschulze> Unfortunately, it will not contribute to readability if done in
-      C.
-    <antrik> perhaps it's worth a look :-)
-    <sdschulze> Actually, a Mach port is pretty close to an Erlang actor.
-    <sdschulze> Currently, your I/O callbacks have to block when they're
-      waiting for something.
-    <sdschulze> What they should do is save the Mach port and respond as soon
-      as they can.
-    <sdschulze> So there should be a return status for "call me later, when I
-      tell you to" in the callbacks.
-    <sdschulze> Then the translator associates the Mach port with the summary
-      of the request in some data structure.
-    <sdschulze> As soon as the data is there, it tells the callback function to
-      appear again and fulfills the request.
-    <sdschulze> That's -- very roughly -- my idea.
-    <sdschulze> Actually, this eliminates the need for multithreading
-      completely.
-    <antrik> sdschulze: not sure whether you are talking about RPC level or
-      libc level here...
-    <sdschulze> It should be transparent to libc.
-    <sdschulze> If the client does a read() that cannot be answered immediatly,
-      it blocks.
-    <sdschulze> The difference is that there is no corresponding blocking
-      thread in the translator.
-    <antrik> ah, so you are talking about the server side only
-    <sdschulze> yes
-    <antrik> you mean the callback functions provided by the translator
-      implementation should return ASAP, and then the dispatcher would call
-      them again somehow
-    <sdschulze> allowing the server to be single-threaded, if desired
-    <sdschulze> exactly
-    <sdschulze> like: call_again (mach_port);
-    <antrik> but if the functions give up control, how does the dispatcher know
-      when they are ready to be activated again? or does it just poll?
-    <sdschulze> The translator knows this.
-    <sdschulze> hm...
-    <antrik> well, we are talking about the internal design of the translator,
-      right?
-    <antrik> I'm not saying it's impossible... but it's a bit tricky
-    <antrik> essentially, the callbacks would have to tell the dispatcher,
-      "call me again when there is an incoming message on this port"
-    <sdschulze> Say we have a filesystem translator.
-    <antrik> (or rather, it probably should actually call a *different*
-      callback when this happens)
-    <sdschulze> The client does a "read(...)".
-    <sdschulze> => A callback is called in the translator.
-    <antrik> let's call it disfs_S_io_read() ;-)
-    <antrik> err... diskfs
-    <sdschulze> The callback returns: SPECIAL_CALL_ME_LATER.
-    <sdschulze> yes, exactly that :)
-    <sdschulze> But before, it saves the position to be read in its internal
-      data structure.
-    <sdschulze> (a sorted tree, whatever)
-    <sdschulze> The main loop steps through the data structure, doing a read()
-      on the underlying translator (might be the disk partition).
-    <sdschulze> "Ah, gotcha, this is what the client with Mach port number 1234
-      wanted!  Call his callback again!"
-    <sdschulze> Then we're back in diskfs_S_io_read() and supply the data.
-    <antrik> so you want to move part of the handling into the main loop? while
-      I'm not fundamentally opposed to that, I'm not sure whether the
-      dispatcher/callback approach used by MIG makes much sense at all in this
-      case...
-    <antrik> my point is that this probably can be generalised. blocking
-      operations (I/O or other) usually wait for a reply message on a port --
-      in this case the port for the underlying store
-    <antrik> so the main loop would just need to wait for a reply message on
-      the port, without really knowing what it means
-    <sdschulze> on what port?
-    <antrik> so disfs_S_io_read() would send a request message to the store;
-      then it would return to the dispatcher, informing it to call
-      diskfs_S_io_read_finish() or something like that when there is a message
-      on the reply port
-    <antrik> main loop would add the reply port to the listening port bucket
-    <antrik> and as soon as the store provides the reply message, the
-      dispatcher would then call diskfs_S_io_read_finish() with the reply
-      message
-    <sdschulze> yes
-    <antrik> this might actually be doable without changes to MIG, and with
-      fairly small changes to libports... though libdiskfs etc. would probably
-      need major rewrites
-    <sdschulze> What made me think about it is that Mach port communication
-      doesn't block per se.
-    <antrik> all this is however ignoring the problem I mentioned yesterdays:
-      we need to handle page faults as well...
-    <sdschulze> It's MIG and POSIX that block.
-    <sdschulze> What about page faults?
-    <antrik> when the translator has some data mapped, instead of doing
-      explicit I/O, blocking can occur on normal memory access
-    <sdschulze> antrik: Well, I've only been talking about the server side so
-      far.
-    <antrik> sdschulze: this *is* the server side
-    <antrik> sdschulze: a filesystem translator can map the underlying store
-      for example
-    <antrik> (in fact that's what the ext2 translator does... which is why we
-      had this 2G partition limit)
-    <sdschulze> antrik: Ah, OK, so in other words, there are requests that it
-      can answer immediatly and others that it can't?
-    <antrik> that's not the issue. the issue is the the ext2 translator doesn't
-      issue explicit blocking io_read() operations on the underlying
-      store. instead, it just copies some of it's own address space from or to
-      the client; and if the page is not in physical memory, blocking occurs
-      during the copy
-    <antrik> so essentially we would need a way to return control to the
-      dispatcher when a page fault occurs
-    <sdschulze> antrik: Ah, so MIG will find the translator unresponsive?  (and
-      then do what?)
-    <antrik> sdschulze: again, this is not really a MIG thing. the main loop is
-      *not* in MIG -- it's provided by the tranlator, usually through libports
-    <sdschulze> OK, but as Mach IPC is asynchronous, a temporarily unresponsive
-      translator won't cause any severe harm?
-    <sdschulze> antrik: "Easy" solution: use a defined number of worker
-      threads.
-    <antrik> sdschulze: well, for most translators it doesn't do any harm if
-      they block. but if we want to accept that, there is no point in doing
-      this continuation stuff at all -- we could just use a single-threaded
-      implementation :-)
-
-[[continuation]].
-
-    <sdschulze> Hard solution: do use explicit I/O and invent a
-      read_no_pagefault() call.
-    <antrik> not sure what you mean exactly. what I would consider is something
-      like an exception handler around the copy code
-    <antrik> so if an exception occurs during the copy, control is returned to
-      the dispatcher; and once the pager informs us that the memory is
-      available, the copy is restarted. but this is not exacly simple...
-    <sdschulze> antrik: Ah, right.  If the read() blocks, you haven't gained
-      anything over blocking callbacks.
-    * sdschulze adopted an ML coding style for his C coding...
-    <sdschulze> antrik: Regarding it on the Mach level, all you want to do is
-      some communication on some ports.
-    <sdschulze> antrik: Only Unix's blocking I/O makes you want to use threads.
-    <sdschulze> Unless you have a multicore CPU, there's no good reason why you
-      would *ever* want multithreading.
-    <sdschulze> (except poor software design)
-    <sdschulze> antrik: Is there a reason why not to use io_read?
-    <antrik> sdschulze: I totally agree about multithreading...
-    <antrik> as for not using io_read(): some things are easier and/or more
-      efficient with mapping
-    <antrik> the Mach VM is really the most central part of Mach, and it's
-      greatest innovation...
-    <sdschulze> antrik: If you used explicit I/O, it would at least shift the
-      problem somewhere else...
-    <antrik> sure... but that's a workaround, not a solution
-    <sdschulze> I'm not sure how to deal with page faults then -- I know too
-      little about the Hurd's internal design.
-    <sdschulze> Non-blocking io_read only works if we address the client side,
-      too, BTW.
-    <sdschulze> which would be quite ugly in C IMHO
-    <sdschulze> announce_read (what, to, read, when_ready_callback);
-    <antrik> sdschulze: POSIX knows non-blocking I/O
-    <antrik> never checked how it works though
-    <sdschulze> Yes, but I doubt it does what we want.
-    <antrik> anyways, it's not too hard to do non-blocking io_read(). the
-      problem is that then you have to use MIG stubs directly, not the libc
-      function
-    <sdschulze> And you somehow need to get the answer.
-    <sdschulze> resp. get to know when it's ready
-    <antrik> the Hurd actually comes with a io_request.defs and io_reply.defs
-      by default. you just need to use them.
-    <sdschulze> oh, ok
-    <antrik> (instead of the usual io.defs, which does a blocking send/receive
-      in one step)
-    <sdschulze> I'd be interested how this works in Linux...
-    <antrik> what exactly?
-    <sdschulze> simultaneous requests on one FS
-    <antrik> ah, you mean the internal threading model of Linux? no idea
-    <sdschulze> if it uses threading at all
-    <antrik> youpi probably knows... and some others might as well
-    <sdschulze> Callbacks are still ugly...
diff --git a/open_issues/neals_hurd-misc_papers.mdwn b/open_issues/neals_hurd-misc_papers.mdwn
deleted file mode 100644
index 7f4e1e3b..00000000
--- a/open_issues/neals_hurd-misc_papers.mdwn
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_documentation]]
-
-<http://walfield.org/pub/people/neal/papers/hurd-misc/>
-
-    <tschwinge> neal: We could put that into the wiki some day, I think.
-    <neal> sure
diff --git a/open_issues/netstat.mdwn b/open_issues/netstat.mdwn
deleted file mode 100644
index b575ea7f..00000000
--- a/open_issues/netstat.mdwn
+++ /dev/null
@@ -1,34 +0,0 @@
-[[!meta copyright="Copyright © 2012 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 open_issue_porting]]
-
-
-# IRC, freenode, #hurd, 2012-12-06
-
-    <braunr> we need a netstat command
-    <pinotree> wouldn't that require rpcs and notifications in pfinet to get
-      info on the known sockets?
-    <braunr> depends on the interface
-    <braunr> netstat currently uses /proc/net/* so that's out of the question
-    <braunr> but a bsd netstat using ioctls could do the job
-    <braunr> i'm not sure if it's done that way
-    <braunr> i don't see why it would require notifications though
-    <pinotree> if add such rpcs to pfinet, you could show the sockets in procfs
-    <braunr> yes
-    <braunr> that's the clean way :p
-    <braunr> but why notifications ?
-    <pinotree> to get changes on data of sockets (status change, i/o activity,
-      etc)
-    <pinotree> (possibly i'm forgetting some already there features to know
-      that)
-    <braunr> the socket state is centralized in pfinet
-    <braunr> netstat polls it
-    <braunr> (or asks it once)
diff --git a/open_issues/network_file_system_by_just_forwarding_rpcs.mdwn b/open_issues/network_file_system_by_just_forwarding_rpcs.mdwn
deleted file mode 100644
index de1d63a3..00000000
--- a/open_issues/network_file_system_by_just_forwarding_rpcs.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_hurd]]
-
-IRC, #hurd, August / September 2010
-
-    <jkoenig> btw, it should be possible to implement a network "filesystem" by
-      just forwarding RPCs over the network, right?
-    <jkoenig> (of course auth would be an additional concern)
-    <jkoenig> that would open all kinds of possibilities, possibly.
-    <LarstiQ> jkoenig: plan9?
-    <jkoenig> I don't know much about plan9 yet. I seem to remember some mach
-      extension for network transparency being mentionned somewhere..
diff --git a/open_issues/nfs_trailing_slash.mdwn b/open_issues/nfs_trailing_slash.mdwn
deleted file mode 100644
index 90f138e3..00000000
--- a/open_issues/nfs_trailing_slash.mdwn
+++ /dev/null
@@ -1,36 +0,0 @@
-[[!meta copyright="Copyright © 2012 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]]
-
-
-# IRC, freenode, #hurd, 2012-05-27
-
-    <gg0> ok, on nfs "mkdir dir0" succeeds, "mkdir dir0/" fails. RPC struct is bad
-
-
-## IRC, freenode, #hurd, 2012-05-27
-
-    <gg0>  150->dir_mkdir ("foo1/" 493) = 0x40000048 (RPC struct is bad) 
-    <gg0> task2876->mach_port_deallocate (pn{ 18}) = 0 
-    <gg0> mkdir:  136->io_write_request ("mkdir: " -1) = 0 7
-    <gg0> cannot create directory `/nfsroot/foo1/' 136->io_write_request
-      ("cannot create directory `/nfsroot/foo1/'" -1) = 0 40
-    <gg0> : RPC struct is bad 136->io_write_request (": RPC struct is bad" -1)
-      = 0 19
-    <gg0>  136->io_write_request ("
-    <gg0> " -1) = 0 1
-    <tschwinge> gg0: Yes, I think we knew about this before.  Nobody felt like
-      working on it yet.  Might be a nfs, libnetfs, glibc issue.
-    <tschwinge> gg0: If you want to work on it, please ask here or on bug-hurd
-      if you need some guidance.
-    <gg0> yeah found this thread
-      http://lists.gnu.org/archive/html/bug-hurd/2008-04/msg00069.html I don't
-      think I'll work on it
diff --git a/open_issues/nice_changes_priority_of_parent_shell.mdwn b/open_issues/nice_changes_priority_of_parent_shell.mdwn
deleted file mode 100644
index a8a08f90..00000000
--- a/open_issues/nice_changes_priority_of_parent_shell.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_gnumach open_issue_glibc]]
-
-  * [[!debbug 44039]]
-
-  * Also see [[nice_vs_mach_thread_priorities]].
diff --git a/open_issues/nice_vs_mach_thread_priorities.mdwn b/open_issues/nice_vs_mach_thread_priorities.mdwn
deleted file mode 100644
index 1f4c6ab8..00000000
--- a/open_issues/nice_vs_mach_thread_priorities.mdwn
+++ /dev/null
@@ -1,429 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2012, 2013 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_gnumach open_issue_glibc]]
-
-This issue has been known for some time, due to coreutils' testsuite choking
-when testing *nice*: [[!debbug 190581]].
-
-There has been older discussion about this, too, but this is not yet captured
-here.
-
-
-# IRC, freenode, #hurd, 2010-08
-
-    <pochu> I'm reading Mach and POSIX documentation to understand the priorities/nice problems
-    <pochu> antrik said it would be better to reimplement everything instead of
-      fixing the current Mach interfaces, though I'm not sure about that yet
-    <youpi> uh, so he changed his mind?
-    <pochu> it seems POSIX doesn't say nice values should be -20..20, but
-      0..(2*NZERO - 1)
-    <youpi> he said we could just change the max priority value and be done
-      with it :)
-    <pochu> so we can probably define NZERO to 16 to match the Mach range of
-      0..31
-    <youpi> s/said/had said previously/
-    <antrik> youpi: POSIX is actually fucked up regarding the definition of
-      nice values
-    <antrik> or at least the version I checked was
-    <pochu> antrik: why? this says the range is [0,{NZERO}*2-1], so we can just
-      set NZERO to 16 AFAICS:
-      http://www.opengroup.org/onlinepubs/9699919799/functions/getpriority.html
-    <antrik> it talkes about NZERO and all; making it *look* like this could be
-      defined arbitrarily... but in other places, it's clear that the standard
-      40 level range is always assumed
-    <antrik> anyways, I totally see no point in deviating from other systems in
-      this regard. it can only cause problems, and gives us no benefits
-    <cfhammar> it says NZERO should be at least 20 iirc 
-    <youpi> agreed
-    <antrik> I don't remember the details; it's been a while since I looked at
-      this
-    <antrik> youpi: changing the number of levels is only part of the
-      issue. I'm not sure why I didn't mention it initially when we discussed
-      this
-    <antrik> youpi: I already concluded years ago that it's not possible to
-      implement nice levels correctly with the current Mach interfaces in a
-      sane fashion
-    <antrik> (it's probably possible, but only with a stupid hack like setting
-      all the thread priorities one by one)
-    <antrik> youpi: also, last time we discussed this, I checked how the nice
-      stuff works currently on Hurd; and concluded that it's so utterly broken,
-      that there is no point in trying to preserve *any* compatibility. I think
-      we can safely throw away any handling that is alread there, and do it
-      over from scratch in the most straightforward fashion
-    <pochu> antrik: I've thought about setting NZERO to 16 and doing exactly
-      what you've just said to be a hack (setting all the thread priorities one
-      by one)
-    <pochu> but there seems to be consensus that that's undesirable...
-    <pochu> indeed, POSIX says NZERO should be at least 20
-    <antrik> pochu: BTW, I forgot to say: I'm not sure you appreciate the
-      complexity of setting the thread max priorities individually
-    <pochu> antrik: I don't. would it be too complex? I imagined it would be a
-      simple loop :)
-    <antrik> pochu: in order to prevent race conditions, you have to stop all
-      other threads before obtaining the list of threads, and continue them
-      after setting the priority for each
-    <antrik> I don't even know whether it can be done without interfering with
-      other thread handling... in which case it gets really really ugly
-    <pochu> antrik: btw I'm looking at [gnumach]/kern/thread.[ch], removing the
-      priority stuff as appropriate, and will change the tasks code later
-    <antrik> it seems to me that using a more suitable kernel interface will
-      not only be more elegant, but quite possibly actually easier to
-      implement...
-    <pochu> antrik: apparently it's not that hard to change the priority for
-      all threads in a task, see task_priority() in gnumach/kern/task.c
-    <pochu> it looks like the nice test failures are mostly because of the not
-      1:1 mapping between nice values and Mach priorities
-    <marcusb> "Set priority of task; used only for newly created threads."
-    <marcusb> there is a reason I didn't fix nice 8 years ago
-    <marcusb> ah there is a change_threads option
-    <pochu> marcusb: I'm not sure that comment is correct. that syscall is used
-      by setpriority()
-    <marcusb> yeah
-    <marcusb> I didn't read further, where it explains the change_threads
-      options
-    <marcusb> I was shooting before asking questions :)
-    <marcusb> pochu: although there are some bad interactions if max_priorities
-      are set per thread
-    <antrik> pochu: maybe we are talking past each other. my point was not that
-      it's hard to do in the kernel. I was just saying that it would be painful
-      to do from userspace with the current kernel interface
-    <pochu> antrik: you could still use that interface in user space, couldn't
-      you? or maybe I'm misunderstanding...
-    <pochu> cfhammar, antrik: current patch:
-      http://emilio.pozuelo.org/~deb/gnumach.patch, main issue is probably what
-      to do with high-priority threads. are there cases where there should be a
-      thread with a high priority but the task's priority shouldn't be high?
-      e.g. what to do with kernel_thread() in [gnumach]/kern/thread.c
-    <pochu> i.e. if tasks have a max_priority, then threads shouldn't have a
-      higher priority, but then either we raise the task's max_priority if we
-      need a high-prio thread, or we treat them specially (e.g. new field in
-      struct thread), or maybe it's a non-issue because in such cases, all the
-      task is high-prio?
-    <pochu> also I wonder whether I can kill the processor set's
-      max_priority. It seems totally unused (I've checked gnumach, hurd and
-      glibc)
-    <pochu> (that would simplify the priority handling)
-    <cfhammar> pochu: btw what does your patch do? i can't remember what was
-      decided
-    <pochu> cfhammar: it moves the max_priority from the thread to the task, so
-      raising/lowering it has effect on all of its threads
-    <pochu> it also increases the number of run queues (and thus that of
-      priority levels) from 32 to 40 so we can have a 1:1 mapping with nice
-      values
-    <pochu> cfhammar: btw don't do a full review yet, just a quick look would
-      be fine for now
-    <neal> why not do priorities from 0 to 159
-    <neal> then both ranges can be scaled
-    <neal> without loss of precision
-    <pochu> neal: there would be from Mach to nice priorities, e.g. a task with
-      a priority of 2 another with 3 would have the same niceness, though their
-      priority isn't really the same
-    <neal> pochu: sure
-    <neal> pochu: but any posix priority would map to a current mach priority
-      and back
-    <neal> sorry, that's not true
-    <neal> a posix priority would map to a new mach priority and bach
-    <neal> and a current mach priority would map to a new mach priority and
-      back
-    <neal> which is I think more desirable than changing to 40 priority levels
-    <pochu> neal> and a current mach priority would map to a new mach priority
-      and back <- why should we care about this?
-    <neal> to be compatible with existing mach code
-    <neal> why gratutiously break existing interfaces?
-    <pochu> they would break anyway, wouldn't them? i.e. if you do
-      task_set_priority(..., 20), you can't know if the caller is assuming old
-      or new priorities (to leave it as 20 or as 100)
-    <neal> you add a new interface
-    <neal> you should avoid changing the semantics of existing interfaces as
-      much as possible
-    <pochu> ok, and deprecate the old ones I guess
-    <neal> following that rule, priorities only break if someone does
-      task_set_priority_new(..., X) and task_get_priority ()
-    <neal> there are other users of Mach
-    <neal> I'd add a configure check for the new interface
-    <neal> alternatively, you can check at run time
-    <pochu> well if you _set_priority_new(), you should _get_priority_new() :)
-    <neal> it's not always possible
-    <pochu> other users of GNU Mach?
-    <neal> you are assuming you have complete control of all the code
-    <neal> this is usually not the case
-    <neal> no, other users of Mach
-    <neal> even apple didn't gratuitously break Mach
-    <neal> in fact, it may make sense to see how apple handles this problem
-    <pochu> hmm, I hadn't thought about that
-    <pochu> the other thing I don't understand is: "I'd add a configure check
-      for the new interface". a configure check where? in Mach's configure?
-      that doesn't make sense to me
-    <neal> any users of the interface
-    <pochu> ok so in clients, e.g. glibc & hurd
-    <neal> yes.
-    <antrik> neal: I'm not sure we are winning anything by keeping
-      compatibility with other users of Mach...
-    <antrik> neal: we *know* that to make Hurd work really well, we have to do
-      major changes sooner or later. we can just as well start now IMHO
-    <antrik> keeping compatibility just seems like extra effort without any
-      benefit for us
-    <guillem> just OOC have all other Mach forks, preserved full compatibility?
-    <neal> guillem: Darwin is pretty compatible, as I understand it
-    <antrik> pochu: the fundamental approach of changing the task_priority
-      interface to serve as a max priority, and to drop the notion of max
-      priorities from threads, looks fine
-    <antrik> pochu: I'm not sure about the thread priority handling
-    <antrik> I don't know how thread priorities are supposed to work in chreads
-      and/or pthread
-    <antrik> I can only *guess* that they assume a two-stage scheduling
-      process, where the kernel first decides what process to run; and only
-      later which thread in a process...
-    <antrik> if that's indeed the case, I don't think it's even possible to
-      implement with the current Mach scheduler
-    <antrik> I guess we could work with relative thread priorities if we really
-      want: always have the highest-priority thread run with the task's max
-      priority, and lower the priorities of the other threads accordingly
-    <antrik> however, before engaging into this, I think you should better
-      check whether any of the code in Hurd or glibc actually uses thread
-      priorities at all. my guess is that it doesn't
-    <antrik> I think we could get away with stubbing out thread priority
-      handling alltogether for now, and just use the task priority for all
-      threads
-    <antrik> I agree BTW that it would be useful to check how Darwin handles
-      this
-    <pochu> btw do you know where to download the OS X kernel source? I found
-      something called xnu, but I?m not sure that's it
-    <antrik> pochu: yeah, that's it
-    <antrik> Darwin is the UNIX core of OS X, and Xnu is the actual kernel...
-    <pochu> hmm, so they have both a task.priority and a task.max_priority
-    <neal> pochu: thoughts?
-    <pochu> neal: they have a priority and a max_priority in the task and in
-      the threads, new threads inherit it from its parent task
-    <pochu> then they have a task_priority(task, priority, max_priority) that
-      can change a task's priorities, and it also changes it for all its
-      threads
-    <neal> how does the global run queue work?
-    <pochu> and they have 128 run queues, no idea if there's a special reason
-      for that number
-    <pochu> neal: sorry, what do you mean?
-    <neal> I don't understand the point of the max_priority parameter
-    <pochu> neal: and I don't understand the point of the (base) priority ;)
-    <pochu> the max_priority is just that, the maximum priority of a thread,
-      which can be lowered, but can't exceed the max one
-    <pochu> the (base) priority, I don't understand what it does, though I
-      haven't looked too hard. maybe it's the one a thread starts at, and must
-      be <= max_priority
-    <antrik> pochu: it's clearly documented in the manual, as well as in the
-      code your initial patch changes...
-    <antrik> or do you mean the meaning is different in Darwin?...
-    <pochu> I was speaking of Darwin, though maybe it's the same as you say
-    <antrik> I would assume it's the same. I don't think there would be any
-      point in having the base vs. max priority distinction at all, except to
-      stay in line with standard Mach...
-    <antrik> at least I can't see a point in the base priority semantics for
-      use in POSIX systems...
-    <pochu> right, it would make sense to always have priority == max_priority
-      ...
-    <pochu> neal: so max_priority is that maximum priority, and priority is the
-      one used to calculate the scheduled priority, and can be raised and
-      lowered by the user without giving special permissions as long as he
-      doesn't raise it above max_priority
-    <pochu> well this would allow a user to lower a process' priority, and
-      raise it again later, though that may not be allowed by POSIX, so then we
-      would want to have max_priority == priority (or get rid of one of them if
-      possible and backwards compatible)
-    <antrik> pochu: right, that's what I think too
-    <antrik> BTW, did I bring up handling of thread priorities? I know that I
-      meant to, but I don't remember whether I actually did...
-    <pochu> antrik: you told me it'd be ok to just get rid of them for now
-    <pochu> so I'm more thinking of fixing max_priority and (base) priority and
-      leaving thread's scheduling priority as it currently is
-    <pochu> s/so/though/
-    <antrik> pochu: well, my fear is that keeping the thread priority handling
-      as ist while changing task priority handling would complicate the
-      changes, while giving us no real benefit...
-    <antrik> though looking at what Darwin did there should give you an idea
-      what it involves exactly...
-    <pochu> antrik: what would you propose, keeping sched_priority ==
-      max_priority ?
-    <pochu> s/keeping/making/
-    <antrik> yes, if that means what I think it does ;-)
-    <antrik> and keeping the priority of all threads equal to the task priority
-      for now
-    <antrik> of course this only makes sense if changing it like this is
-      actually simpler than extending the current handling...
-    <antrik> again, I can't judge this without actually knowing the code in
-      question. looking at Darwin should give you an idea...
-    <pochu> I think leaving it as is, making it work with the task's
-      max_priority changes would be easier
-    <antrik> perhaps I'm totally overestimating the amount of changes required
-      to do what Darwin does
-    <antrik> OTOH, carrying around dead code isn't exactly helping the
-      maintainability and efficiency of gnumach...
-    <antrik> so I'm a bit ambivalent on this
-    <antrik> should we go for minimal changes here, or use this occasion to
-      simplify things?...
-    <antrik> I guess it would be good to bring this up on the ML
-    <cfhammar> in the context of gsoc i'd say minimal changes
-    <pochu> there's also neal's point on keeping backwards compatibility as
-      much as possible
-    <neal> my point was not backwards compatibility at all costs
-    <antrik> I'm still not convinced this is a valid point :-)
-    <neal> but to not gratutiously break things
-    <antrik> neal: well, I never suggested breaking things just because we
-      can... I only suggested breaking things to make the code and interface
-      simpler :-)
-    <antrik> I do not insist on it though
-    <neal> at that time, we did not know how Mac did it
-    <antrik> I only think it would be good to get into a habit that Mach
-      interfaces are not sacred...
-    <neal> and, I also had a proposal, which I think is not difficult to
-      implement given the existing patch
-    <antrik> but as I said, I do not feel strongly about this. if people feel
-      more confident about a minimal change, I'm fine with that :-)
-    <antrik> neal: err... IIRC your proposal was only about the number of nice
-      levels? we are discussing the interface change necessary to implement
-      POSIX semantics properly
-    <antrik> or am I misremembering?
-    <pochu> antrik: he argues that with that number of nice levels, we could
-      keep backwards compatibility for the 0..31 levels, and for 0..39 for
-      POSIX compatibility
-    <antrik> pochu: yes, I remember that part
-    <neal> antrik : My suggestion was: raise the number of nice levels to 160
-      and introduce a new interface which uses those.  Adjust the old interface
-      to space by 160/32
-    <antrik> neal: I think I said it before: the problem is not *only* in the
-      number of priority levels. the semantics are also wrong. which is why
-      Darwin added a max_priority for tasks
-    <neal> what do you mean the semantics are wrong?
-    <neal> I apologize if you already explained this.
-    <antrik> hm... I explained it at some point, but I guess you were not
-      present at that conversation
-    <neal> I got disconnected recently so I likely don't have it in backlog.
-    <antrik> in POSIX, any process can lower its priority; while only
-      privileged processes can raise it
-    <antrik> Mach distinguishes between "current" and "max" priority for
-      threads: "max" behaves like POSIX; while "current" can be raised or
-      lowered at will, as long as it stays below "max"
-    <antrik> for tasks, there is only a "current" priority
-    <antrik> (which applies to newly created threads, and optionally can be set
-      for all current threads while changing the task priority)
-    <antrik> glibc currently uses the existing task priorities, which leads to
-      *completely* broken semantics
-    <antrik> instead, we need something like a max task priority -- which is
-      exactly what Darwin added
-    <neal> yes
-    <antrik> (the "current" task priority is useless for POSIX semantics as far
-      as I can tell; and regarding thread priorities, I doubt we actually use
-      them at all?...)
-    <cfhammar> where does a new thread get its initial max_priority from?
-    <antrik> cfhammar: from the creator thread IIRC
-    <pochu> yes
-
-
-## IRC, freenode, #hurd, 2010-08-12
-
-    <pochu> my plan is to change the number of priority levels and the
-      threads/tasks priority handling, then add new RPCs to play with them and
-      make the old ones stay compatible, then make glibc use the new RPCs
-
-
-# IRC, freenode, #hurd, 2012-12-29
-
-    <braunr> and, for a reason that i can't understand, there are less
-      priorities than nice levels, despite the fact mach was designed to run
-      unix systems on top of it ..
-    <youpi> btw, didn't we have a plan to increase that number?
-    <braunr> i have no idea
-    <braunr> but we should :)
-    <youpi> I remember some discussion about it on the list
-
-
-## IRC, freenode, #hurd, 2012-12-31
-
-    <youpi> braunr: btw, we *do* have fixed the nice granularity
-    <youpi> +#define MACH_PRIORITY_TO_NICE(prio) ((prio) - 20)
-    <youpi> in the debian package at least
-    <youpi> ah, no
-    <youpi> it's not applied yet
-    <youpi> so I have the patch under hand, just not applied :)
-    <braunr> but that's a simple shift
-    <braunr> the real problem is that there aren't as many mach priorities as
-      there are nice levels
-    <youpi> that's not really a problem
-    <youpi> we can raise that in the kernel
-    <youpi> the problem is the change from shifted to unshifted
-    <youpi> that brings odd nice values during the upgrade
-    <braunr> ok
-    <braunr> i hope the scheduler code isn't allergic to more priorities :)
-
-
-## IRC, freenode, #hurd, 2013-01-02
-
-    <braunr> pochu: i see you were working on nice levels and scheduling code
-      some time ago
-    <braunr> pochu: anything new since then ?
-    <pochu> braunr: nope
-    <braunr> pochu: were you preparing it for the gsoc ?
-    <pochu> braunr: can't remember right now, either that or to fix a ftbfs in
-      debian
-    <youpi> iirc it's coreutils which wants proper nice levels
-
-
-# IRC, OFTC, #debian-hurd, 2013-03-04
-
-    <Steap> Is it not possible to set the priority of a process to 1 ?
-    <Steap> these macros:
-    <Steap> #define MACH_PRIORITY_TO_NICE(prio) (2 * ((prio) - 12))
-    <Steap> #define NICE_TO_MACH_PRIORITY(nice) (12 + ((nice) / 2))
-    <Steap> are used in the setpriority() implementation of Hurd
-    <Steap> so setting a process' priority to 1 is just like setting it to 0
-    <youpi> Steap: that has already been discussed to drop the *2
-    <youpi> the issue is mach not supporting enough sched levels
-    <youpi> can be fixed, of course
-    <youpi> just nobody did yet
-
-GNU Mach commit 6a234201081156e6d5742e7eeabb68418b518fad (and commit
-6fe36b76f7983ec9a2e8a70420e431d54252442e).
-
-
-## IRC, OFTC, #debian-hurd, 2013-03-07
-
-    <braunr> youpi: btw, why did you increase the number of priorites to 50 ?
-    <youpi> for the nice levels
-    <braunr> and probably something more, there are only 40 nice levels
-    <youpi> yes, the current computation leaves some margin
-    <youpi> so I preferred to keep a margin too
-    <braunr> ok
-    <youpi> e.g. for the idle thread, etc.
-    <braunr> or interrupt threads
-    <youpi> yep
-    <braunr> i see the point, thanks
-    <tschwinge> Is the number of 40 specified by POSIX (or whatever) or is that
-      a Linuxism?
-    <braunr> good question
-    <braunr> posix is weird when it comes to such old unixisms
-    <braunr> there is a NZERO value, but i don't remember how it's specified
-    <youpi> it's at least 20
-    <tschwinge> (I don't object to the change; just wondered.  And if practice,
-      you probably wouldn't really need more than a handful.  But if that
-      change (plus some follow-up in glibc (?) improves something while not
-      adding a lot of overhead, then that's entirely fine, of course.)
-    <braunr> "A maximum nice value of 2*{NZERO}-1 and a minimum nice value of 0
-      shall be imposed by the system"
-    <braunr> NZERO being 20 by default
-    <youpi> and 20 is the minimum for NZERO too
-    <braunr> hm, not the default, the minimul
-    <braunr> minimum
-    <braunr> yes that's it
-    <braunr> ok so it's actually well specified
-    <tschwinge> Aha, I see (just read it, too).  So before that change we
-      simply couldn't satisfy the POSIX requirement of (minimum) NZERO = 20,
-      and allowing for step-1 increments.  Alright.
-    <youpi> yep
-    <youpi> thus failing in coreutils testsuite
diff --git a/open_issues/nightly_builds.mdwn b/open_issues/nightly_builds.mdwn
deleted file mode 100644
index f6d2c311..00000000
--- a/open_issues/nightly_builds.mdwn
+++ /dev/null
@@ -1,53 +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]]."]]"""]]
-
-We'd like to have nightly builds for the whole [[toolchain]], and then do some
-automatic [[unit_testing]] on them.
-
-Resources:
-
-  * [[hurd/running/Nix]]
-
-  * [[toolchain/cross-gnu]]
-
-      * [[Debian_Cross_Toolchain]]
-
-  * As reported in the [[news/2010-05-31]] news, there's Hydra doing nightly
-    builds / Nix packages.
-
-  * <http://hudson-ci.org/>, <http://jenkins-ci.org/>
-
-      * [[!message-id "201308251648.38010.holger@layer-acht.org"]]
-
-  * <http://buildbot.net/>
-
-    IRC, freenode, #hurd, 2013-11-15:
-
-        <teythoon> today I discovered buildbot, and both the master as well as
-          the build slave works just fine out of the box on Hurd :)
-        <teythoon> I'd love to set one up on darnassus
-        <braunr> ah nice
-        <braunr> we use buildbot at work too
-        <teythoon> even better, so you already know it
-        <braunr> sure we can
-        <braunr> no i don't
-        <braunr> i just know we use it :)
-        <teythoon> k
-        <braunr> but that would be a good occasion to learn
-        <braunr> i'm a bit busy right now, have to go soon
-        <braunr> we'll see the details later
-        <teythoon> yes :)
-
-    [[Nightly_Builds_deb_Packages]].
-
-  * [LAVA (Linaro Automated Validation
-    Architecture)](http://lava.readthedocs.org/)
-
diff --git a/open_issues/nightly_builds_deb_packages.mdwn b/open_issues/nightly_builds_deb_packages.mdwn
deleted file mode 100644
index cef16734..00000000
--- a/open_issues/nightly_builds_deb_packages.mdwn
+++ /dev/null
@@ -1,747 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 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]]."]]"""]]
-
-I'd be quite helpful to have nightly builds in form of Debian `.deb`
-packages.
-
-  * <http://noone.org/talks/vcs-buildd/> (german)
-
-  * Need to have an automation to get from Hurd upstream Git branches to
-    a branch usable in Debian.
-
-    IRC, freenode, #hurd, 2013-12-18:
-
-        <teythoon> http://darnassus.sceen.net/~teythoon/hurd-ci/ has hurd and
-          mig and gnumach packages built directly from the upstream git
-          repository
-
-
----
-
-There is infrastructure available to test whole OS installations.
-
-  * <http://www.os-autoinst.org/>
-
----
-
-[[Debian_Cross_Toolchain]] for cross-building?
-
----
-
-See also [[nightly_builds]].
-
-
-# Debian Jenkins Instance
-
-## IRC, OFTC, #debian-hurd, 2014-02-24
-
-    <pere> hi.  can hurd be installed using d-i?  If so, what about scripting
-      the installation on <URL:
-      http://jenkins.debian.net/view/g-i-installation/ >?
-    <gnu_srs> pere: d-i works for Hurd, yes, with full graphical interface I
-      dunno. Maybe you can ask about scripting in #hurd, more people are
-      present there?
-    <pere> gnu_srs: the scripts in questions are for jenkins.  quite easy to
-      write (d-i preseed scripts and qemu boot rules).
-
-## IRC, OFTC, #debian-hurd, 2014-02-25
-
-    <pere> getting a automated test in jenkins running could show the status.
-      what is needed to boot the hurd d-i image with a preseed file using qemu?
-    <pere> git://git.debian.org/git/users/holger/jenkins.debian.net.git is the
-      repo with the jenkins build rules.
-    <pere> youpi: is it possible to start the hurd d-i installer with a preseed
-      file from the qemu command line?  --append need --kernel, which I suspect
-      do not make sense with hurd?
-    <pere> can the d-i hurd installer take a preseed file at all?  my initial
-      try failed. :(
-    <teythoon> i don't know
-    <teythoon> there has been talk here the other day about using qemus
-      multiboot capabilities to directly boot the hurd
-
-[[hurd/running/qemu#multiboot]].
-
-For d-i purposes, you'll additionally need:
-
-    $ wget http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/current/initrd.gz
-
-..., and to the `--initrd` option prepend `'initrd.gz $(ramdisk-create)',`
-before the `ext2fs.static`, and refer the latter to `gunzip:device:rd0` instead
-of `device:hd0s1`.
-
-    <pere> I tried adding an url= option to grub when booting the installer,
-      but it seem to be ignored.
-    <pere> perhaps the preseed udeb is missing, or the network support was
-      enabled after preseed looked for the file?
-    <teythoon> uh, i don't know about that stuff, youpi creates the d-i images
-    <pere> ok.  seem to me that the d-i images do not support preseeding at the
-      moment.
-    <teythoon> youpi: ^ did you succeed? if so, can you share how?
-    <pere> teythoon: nope, I concluded it didn't work, and left it to other to
-      fix. :)
-    <youpi> pere, teythoon: IIRC preseeding can be put on the gnumach kernel
-      command line
-    <youpi> but I'm wondering why you can't simply modify the disk image into
-      doing what you want
-    <youpi> or you mean reinstalling the image each time?
-    <pere> youpi: the point is testing the installer, and that can only be done
-      by using the installer. :)
-    <youpi> ok
-    <pere> I would like to see something like <URL:
-      http://jenkins.debian.net/view/g-i-installation/job/g-i-installation_debian_sid_daily_lxde/lastBuild/
-      > for hurd.
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-26
-
-    * gg0 setting up jenkins, almost time to give up
-    <pere> gg0: why do you set up jenkins?
-    <gg0> because i want to fail at doing all things, not just something ;)
-    <gg0> oops seems my setup just sent emails to jenkins+debian-qa
-      holger@layer-acht.org :/
-    <pere> #debian-qa will understand. :)
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-28
-
-    <pere> gg0: are you able to feed the installer one of the preseed files at
-      <URL: http://jenkins.debian.net/d-i-preseed-cfgs/ >?
-    <gg0> though jenking translates double quotes, need to escape the world
-    <pere> debian_sid_daily_lxde_preseed.cfg seem like a good candiate. :)
-    <gg0> pere: i'm working on that, stuck at working around that mandatory
-      double quote
-    <gg0> *initrd double quote
-    <gg0> ok got a g-i-installation_debian_sid_daily_hurd_lxde able to boot
-    <gg0> let's provide a preseed
-    <gg0> shouldn't there be some info/debug consoles from tty 2 to 4?
-    <youpi> there should be
-    <gg0> maybe i can't send alt+NUM from vlc
-    <youpi> ah, yes
-    <youpi> you need to use the menu for that
-    <youpi> press f8
-    <gg0> great
-    <gg0> (found out C+A+{1,2,3} give interesting monitor,serial,parallel
-      consoles btw)
-    <gg0> not much options on menu
-    <gg0> just clipboard management, quit, full screen, send ctrl-alt-del, send
-      F8
-    * gg0 takes "great" back
-    <gg0> i guess it depends on vnc implementation
-    <gg0> don't ask me how i found out one can switch console with
-      ... left/right arrow keys
-    <youpi> without alt pressed?
-    <gg0> without alt pressed
-    <youpi> I've already seen that with qemu, when focusing into/out from the
-      qemu window by using alt
-    <youpi> somehow the alt state gets stuck
-    <gg0> so you mean if i close viewer then reattach it, it doesn't happen
-      anymore? let's see
-    <gg0> you're right
-    <gg0> though yes alt+left/right switches consoles
-    <youpi> the last is expected :)
-    <gg0> it says kbd-udeb doesn't exist so it falls back to
-      hurd-debian-ports-udeb
-    <youpi> that's not a problem
-    <gg0> no partman-auto?
-    <youpi> it should be working
-    <gg0> i meant if it was installed but yes it gets it along with others
-
-
-## IRC, OFTC, #debian-hurd, 2014-03-01
-
-    <gg0> partman-auto would need to be patched to be able to discover
-      available disks
-    <gg0> worked around by forcing /dev/hd1, jenkins creates disk with index=1
-    <gg0> stuck at installation-report installed. seems it can't manage to
-      umount(then remount) /cdrom gracefully
-    <gg0> or better it gets stuck at apt-cdrom ident
-    <gg0> something like https://bugs.debian.org/598457
-
-
-## IRC, OFTC, #debian-hurd, 2014-03-02
-
-    <gg0> youpi: any chance to have monthly/weekly (daily would be too much i
-      guess) isos/images? can i help somehow?
-    <youpi> I am wondering why having that
-    <youpi> since we have up-to-date mirrors
-    <gg0> i'd say to install with latest installer/gnumach/hurd/eglibc 
-    <youpi> so that means also rebuilding the d-i image
-    <gg0> and in general to not have to manually produce them
-    <pere> youpi: the point is to automatically test the current images using
-      jenkins.debian.net, I believe.  for that to work, current images need to
-      exist. :)
-    <gg0> not only. i think saving youpi's time is also important
-    <youpi> gg0: it doesn't really take me much time to generate images
-    <youpi> it's about a few command lines to start, and then work on something
-      else :)
-    <gg0> well though it still requires manual intervention which is not
-      scheduled and also error prone btw
-    <youpi> gg0: I guess the most important help you could provide would be to
-      actually track when the autobuild breaks :)
-    <gg0> what pros keeping it manual? i don't think disk space saving
-    <youpi> it's not really a question of manual, but the frequency
-    <youpi> I prefer to test manually before uploading something on my
-      somehow-official directory on people, anyway
-    <youpi> but that doesn't mean we can't have weekly builds somewhere else
-      indeed
-    <youpi> it's just that for tests it's good to have several images backlog,
-      but then it takes disk
-    <gg0> well we could keeping "official" ones + say 6 monthly and say 4
-      weekly
-    * gg0 randomizes retention
-    <gg0> -ing
-    <teythoon> gg0: check out my hurdtest program
-    <teythoon> it updates qemu images automatically, and runs a test suite,
-      creates snapshots
-    <gg0> youpi: you'd just take actually care of official ones
-    <teythoon> and it can zero-fill the disk images to compact them for
-      publication
-    <youpi> gg0: and have a cron for the others
-    <youpi> on mirror.ftp-master
-    <gg0> nice, we already have a disk image generator then
-    <teythoon> i shall clean it up and merge stuff that i have changed locally
-    <teythoon> i covered it in my early blog posts
-    <teythoon> i use it extensively to test the packages from hurd-ci
-    <gg0> great. so usually at this point /me can't do anything so good work!
-      lol
-    <youpi> crontabs are in place, scheduled on monday mornings
-    <youpi> I have already completed a run, can be seen in weekly-0
-    <gg0> great!
-    <gg0> assuming it will work forever without maintenance, how many minutes
-      you'll save per month? :)
-    <youpi> I don't think that'll save me time per month
-    <youpi> since it's just an additional thing
-    <gg0> youpi: so weekly-0 will always be the latest weekly (same about
-      monthly) ?
-    <youpi> yes
-    <gg0> how about adding -YYYYMMDD after -1 CD/DVD/NETINST number?
-    <youpi> that'd mean more scripting
-    <gg0> just to distinguish them
-    <youpi> we already have timestamps from the server
-    <gg0> unfortunately i can't script myself, i can suggest though :)
-    <gg0> or scripts are available somewhere?
-    <gg0> so current/ should be a link to weekly-0?
-    <youpi> on mirror.ftp-master.debian.org, but I guess you don't have access
-      to it
-    <youpi> no
-    <youpi> definitely no
-    <youpi> the point of current/ is to have something tested
-    <gg0> ok
-    <youpi> while weekly/monthly are most probably to get broken
-    <youpi> so let's not point people at that
-    <gg0> same story about diskimage? how do you generate them?
-    <gg0> how about teythoon's way?
-    <youpi> I do it by hand at the moment, but scripts would be welcome indeed
-    <youpi> http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.txt
-    <gg0> ok now stuck at grub install
-
-
-## IRC, OFTC, #debian-hurd, 2014-03-03
-
-    <gg0> i probably should force /dev/hd0 as i did for /dev/hd0s1 as root
-      device
-    <gg0> if it's possible
-    <youpi> what do you mean by forcing /dev/hd0s1 as root device ?
-    <youpi> you shouldn't have to do that
-    <youpi> my fear is that these additional images will mostly just bring
-      additionnal reports
-    <gg0> i had to specify it in preseed
-    <youpi> which won't really decrease the amount of work
-    <gg0> as partman-auto/disk
-    <gg0> it can recognize available disks
-    <gg0> that's also because it can't list root partitions on rescue mode
-    <youpi> well, all I can say without having (again) to spend time on it, is
-      that you're not supposed to have to do that
-    <youpi> why are you using rescue mode?
-    <youpi> if it can't list root partitions, then of course partman can't work
-    <gg0> well, rescue mode should work
-    <youpi> if you delve into non-tested parts of d-i, you'll surely encounter
-      bugs
-    <youpi> well, less "should" than plain "d-i"
-    <youpi> in that I've never really tested it
-    <youpi> so don't be surprised that some bugs remain
-    <gg0> no problem
-    <youpi> but again, we don't really need  more bug reports
-    <youpi> but rather bug fixing
-    <youpi> we already have enough to fix, no need to delve into advanced
-      things
-    <gg0> sure, i'm just trying to make it work with all its limitations
-    <gg0> it autopartition the disk well, it can't just make one choose among
-      disks because it can't probe and list them
-    <youpi> then fix the probe & list
-    <gg0> i'd like doing it, i'm better at working around for now though :)
-    <gg0> one blocker is mount/umount stuff
-
-[[glibc#mount]].
-
-    <youpi> well, you'll have to get into fixing bugs for real someday
-    <youpi> otherwise this is just adding to TODO lists
-    <youpi> what mount/umount stuff?
-    <gg0> (took a quick look at partconf)
-    <gg0> non-existent mount.h for instance
-    <gg0> do we have replacements?
-    <youpi> not that I know of
-    <gg0> 21:53 < teythoon> gnu_srs1: i put a small hacks entry in the list
-      about moving the mount/umount functionality from our utilities to the
-      libc
-    <youpi> ok
-    <gg0> another thing i'd really like to see would be a physical shutdown,
-      halt-hurd which actually poweroffs the system
-    <gg0> how to switch to sysvinit by default? next sysvinit upload?
-    <youpi> physical shutdown means implementing APM or ACPI
-    <gg0> have to teach jenkins it can shut it down :/
-    <youpi> I'm extremely far from having the will for this
-    <youpi> switching to sysvinit by default is a matter of saying that we want
-      to do it
-    <youpi> I already asked for this on the list without answer IIRC 
-    <gg0> i can't find anything
-    <youpi> anyway, just propose on the list
-    <gg0> d-i grub-installer/bootdev string /dev/hd0 - here it is
-    <gg0> next run should not need any interaction, though it needs 20 mins to
-      understand it has to destroy it and run won't be successful :/
-    <gg0> due to missing acpi/apm
-    <gg0> first graphical automated install http://postimg.org/image/vgagj06q7/
-    <gg0> it seems 720x400
-    <gg0> though jenkins passes video=vesa:ywrap,mtrr vga=788
-    <gg0> by reconnecting it switched to 800x600
-      http://postimg.org/image/h32qjykrx/
-    <gg0> but seems stuck now and i can't even switch from graphical to
-      consoles
-    <gg0> unusually stuck at scanning cdrom
-    <gg0> i'll check text install to see if it gets stuck there too
-    <gg0> text install switches from 720x400 to 640x400
-    <gg0> i confirm it gets stuck on scanning cdrom, i guess because of this
-      one https://bugs.debian.org/728153 which already broke load-install-cd i
-      already had to workaround
-    <pere> gg0: are you in contact with h01ger to update jenkins.debian.net
-      with your cool installation code?
-    <gg0> pere: still trying to have something working
-    <gg0> plus with new weekly cd, apt-cdrom bug makes install getting stuck at
-      first Scanning cdrom:
-    <gg0> 03:44 < gg0> i confirm it gets stuck on scanning cdrom, i guess
-      because of this one https://bugs.debian.org/728153 which already broke
-      load-install-cd i already had to workaround
-    <youpi> do we really need the CD-1 image in weekly builds?
-    <gg0> just netinst?
-    <youpi> yes
-    <gg0> well, i don't know debian installer well. what's the difference
-      between CD and NETINST besides that CD has more packages user doesn't
-      need to download?
-    <gg0> has CD anything not in NETINST which is worth to continously test?
-      (talking about jenkins)
-    <youpi> that's only it, yes
-    <gg0> btw new ACPI on hurd consists of serial console to file + looping
-      grep "In tight loop: hit ctl-alt-del to reboot" && kill qemu
-    <gg0> anything better?
-    <gg0> filed http://bugs.debian.org/740673
-    <gg0> without a patch just to express my great laziness :p
-    <youpi> well, I'm afraid nobody in the debian-boot team will attempt
-      anything at this
-    <youpi> is it reproducible on linux?
-    <gg0> nope
-    <gg0> my guess is that's due to udev, need a deeper check btw
-    <gg0> i mean non-udev cases like hurd maybe are not handled well
-    <youpi> maybe try on kfreebsd then?
-    <gg0> just guessing
-    * gg0 trying on kfreebsd
-
-
-## IRC, OFTC, #debian-hurd, 2014-03-04
-
-    <gg0> hurd install started getting stuck running os-prober, final grub
-      install phase
-    <gg0> youpi: yes i confirm it affects kfreebsd too
-    <youpi> then please say so in the bug
-    <youpi> otherwise most probably but me in the debian-boot team will care
-    <youpi> +nobody
-    <gg0> that might get more attention from d-boot team?
-    <gg0> ok
-    <youpi> also Cc debian-bsd@
-    <youpi> they will care
-    <youpi> and tell about the hint as being the non-udev case
-    <youpi> too much information or ideas is never a bad thing :)
-    <gg0> done
-    <gg0> (now i know notfound does remove found versions instead of adding
-      notfound versions)
-    <gg0> crazy things. to unblock os-prober i had to settrans -fg
-      /target/media/./cdrom0
-    <gg0> it was mounting /dev/hd0s1 ...
-    <gg0> i suspect apt-cdrom is to blame again
-    <gg0> ok now jenkins just managed to start the installed system
-    <gg0> and it's configured to make vncdo testing it
-    <gg0> i'd need a graphical-working cd with old-apt to continue
-    <gg0> let's try to install old apt on weekly-0
-    <gg0> "cdrom drive contains a cd which cannot be used for installation"
-    <gg0> i think a sort of non-authenticated anymore
-    <gg0> ehm.. http://paste.debian.net/plain/85224/
-    <pere> gg0: nice. :)
-    <gg0> with apt 0.9.15.1 which should be good
-    <gg0> pere: it did mount /dev/hd0s1 under /media/cdrom0
-    <gg0> 0.9.15.5, correctly i think, asks to insert it cdrom. but finally
-      both mount /dev/hd0s1 instead of /dev/hd2
-    <gg0> -it
-    <gg0> cause they both can't detect where cdrom is i guess
-
-
-## IRC, freenode, #hurd, 2014-03-04
-
-    <gg0> we could talk about apt-cdrom https://bugs.debian.org/740673
-    <gg0> how should system recognize cdrom device?
-    <gg0> there's no /dev/cdrom link to actual cdrom device
-    <gg0>  /dev/cd[01] are scsi devices if i'm not wrong
-
-
-## IRC, OFTC, #debian-hurd, 2014-03-05
-
-    <gg0> installer gets stuck running os-prober, seems because
-      /target/proc/mounts gets unreadable, sometimes Resource lost sometimes it
-      gets stuck reading it
-
-[[hurd/translator/mtab/discussion#chroot]].
-
-    <gg0> youpi: could you publish script to rebuild CDs you scheduled? with
-      last official CD (20140212) mtab on /target dies and that seems getting
-      os-prober stuck. last (and only) weekly has recent apt-cdrom so it gets
-      stuck wrongly asking to change cdrom
-    <youpi> see the readme file
-    <youpi> err, you say it's the 0212 build which fails?
-    <youpi> I had tested that before uploading
-    <youpi> so the issue comes form the installed packages, not from the CD
-      udebs
-    <youpi> did you test with no network mirror?
-    <gg0> no i didn't. should it find all packages it needs from cd?
-    <youpi> sure, that's what netinst and dvd-1 are, as opposed to netboot
-    <gg0> lxde desktop probably not
-    <youpi> indeed
-    <youpi> though with the dvd in principle it should
-    <youpi> (if all deps were avaijlable at image build time)
-    <youpi> gg0: btw if you haven't noticed, there's a daily too
-    <gg0> youpi: till apt-cdrom is not fixed, they all will be broken, stuck at
-      "Scanning cdrom"
-    <youpi> gg0: did you try to bisect which git change produces the apt-cdrom
-      bug?
-    <gg0> youpi: all in bug in question
-    <gg0> youpi: https://bugs.debian.org/740673
-    <youpi> is there the precise git commit id in the bug log?
-    <gg0>
-      http://anonscm.debian.org/gitweb/?p=apt/apt.git;a=commitdiff;h=62dcbf84c4aee8cb01e40c594d4c7f3a23b64836
-    <youpi> well, don't tell that to just me, but the bug report...
-    <gg0> bug report says "See <bug>" where bug is
-      https://bugs.debian.org/728153
-    <youpi> gg0: bug report doesn't say it was *tested* that it is that changes
-      which broke things
-    <gg0> i don't think we could get it reverted just because it breaks hurd
-      (+kfreebsd to check) debian installer
-    <youpi> of course, but that's at least where developers can have a look at
-    <gg0> well ok i could have been more clear
-    <youpi> it's *WAY* better than having no idea where to have a look at
-    <youpi> gg0: btw, that's why the README file advises not to use a network
-      mirror, to avoid such kind of issues
-    <youpi> you can't expect sid not to be not-broken :)
-    <gg0> one gets Resource lost even when install is just started, no packages
-      from any mirror
-    <gg0> https://bugs.debian.org/740673#19
-
-    * gg0 installing without mirrors, without desktop, without lxde
-    <gg0> same problem
-    <gg0> so problem has nothing to do with installing from mirrors
-    <youpi> what's odd is that I don't get this issue at all with the 20140212
-      upload at least
-    <youpi> kvm -cdrom debian-7.0-hurd-i386-NETINST-1.iso -drive
-      file=blip,cache=unsafe -m 1G
-    <youpi> no more, no less
-    <gg0> it must depend on preseed and/or kernel append options
-    <youpi> possibly
-    <gg0> oh wait here qemu multiboot
-    <youpi> that shouldn't have any impact
-    <gg0> 5€ on qemu multiboot as the culprit
-    <gg0> you should also see it sometimes double-mounts /dev/hd0s1 under
-      /target and /target/./media/cdrom(!)
-    <gg0> but that's due to new apt it in-targets (= installs under /target)
-
-    <gg0> any luck reproducing mtab issue?
-    <youpi> still not
-
-[[hurd/translator/mtab/discussion#chroot]].
-
-
-## IRC, OFTC, #debian-hurd, 2014-03-06
-
-    <youpi>  http://paste.debian.net/85535/
-    <youpi> no issue
-    <youpi> (no network mirror)
-    <gg0> full install till grub-installer?
-    <youpi> yes
-    <youpi> and reboot
-    <gg0> -append 'auto=true mirror/suite=sid console=com0 priority=critical
-      locale=en_US keymap=us
-      url=http://10.0.2.1//d-i-preseed-cfgs/debian_sid_daily_hurd_lxde_preseed.cfg
-      video=vesa:ywrap,mtrr vga=788 -- quiet'
-    <gg0> i should provide preseed too
-    <youpi> well, of course
-    <youpi> always provide as much information as possible
-    <youpi> so there's also your preseed file
-    <gg0> not much different from
-      http://jenkins.debian.net/d-i-preseed-cfgs/debian_sid_daily_lxde_preseed.cfg
-    <gg0> but you need to force a couple of things + ugly workaround for broken
-      apt-cdrom ident
-    <youpi> well, I didn't even know that jenkins had that pressed file
-    <youpi> well, here apt-cdrom is not needed
-    <youpi> +hacks
-    <youpi> since that's the old image we're checking
-    <gg0> well ok, given you take everything from cd only, yes
-    <gg0> here no mirror, no desktop, no lxde
-      http://paste.debian.net/plain/85538/
-    <gg0> i'm trying this one too
-    <gg0> main difference seems to be i usually use CD-1, not NETINST
-    <gg0> had to add -net nic,vlan=0 -net
-      user,vlan=0,host=10.0.2.1,dhcpstart=10.0.2.2,dns=10.0.2.254
-    <gg0> here target mtab is already crashed
-    <gg0> because some package already tried to read /target/proc/mounts
-    <gg0> youpi: reproduced there?
-    <gg0> .o(well, maybe he's been sleeping for ~50 mins)
-    <youpi> nope, I'm working on upgrading servers
-    <youpi> I'm sorry, but your testcase is not really easy to reproduce :)
-    <gg0> do you have apache on your host? just put preseed in the root, vm
-      will take it
-    <gg0> full command line is what you pasted + -net nic,vlan=0 -net
-      user,vlan=0,host=10.0.2.1,dhcpstart=10.0.2.2,dns=10.0.2.254
-    <gg0> what else? when it starts debstrapping, open a console and check
-      procfs and mtab processes
-    <gg0> err, what you paster + -append i pasted + -net nic,vlan=0 -net
-      user,vlan=0,host=10.0.2.1,dhcpstart=10.0.2.2,dns=10.0.2.254
-    <gg0> *pasted
-    <gg0> which is http://paste.debian.net/plain/85554/
-    <gg0> surely keyboard layout doesn't help, here at least
-    * gg0 tries to reproduce without preseed
-    <gg0> i can't reproduce it
-    <gg0> it doesn't crash
-    * gg0 enabling all options but preseed
-    <gg0> need to wait 31% of Installing base system to have the second procfs
-    <gg0> ok got Resource lost even without preseed
-    <gg0> youpi: you can reproduce it by adding -append console=com0 to what
-      you pasted. that breaks grub-installer, it gets stuck at 66%, while runs
-      os-prober
-    <youpi> ah
-    <gg0> how can that affect /target/proc/mounts?
-    <youpi> no idea
-    <gg0> couldn't daily be here? http://d-i.debian.org/daily-images/
-    <youpi> if I knew how to push files there, sure
-    <gg0> asking on #debian-boot would be a starting point i guess
-    <youpi> probably
-    <gg0> me asking on behalf of youpi would not a good one i think, given
-      whatever will the answer i can't do anything
-    <gg0> +be
-    <youpi> you can still trasmit me
-    <youpi> never understimate the little time you can save other people by
-      doing some bits of work
-    <gg0> well, i would not even have to repaste lines here given you joined
-      there too
-    <gg0> never understimate what "help with laziness" means :)
-    <youpi> not necessarily repasting, but at least highlighting me
-    <youpi> so I know where to read in the #d-b logs
-    <gg0> there are no isos there, i'm missing something
-    <youpi> there are no daily isos
-    <youpi> only weekly isos
-    <gg0> so seems i have to reask initial question with this url
-      http://cdimage.debian.org/cdimage/weekly-builds/
-    <gg0> oh wait they are from testing, that's why no hurd ones
-    <gg0> i guess they could be here though
-      http://cdimage.debian.org/cdimage/daily-builds/sid_d-i/current/
-    * gg0 asking on #debian-cd
-    * gg0 would ignore non-DD gg0 asking whatever
-    <youpi> people don't really ask themselves who is a DD and who is not
-    <youpi> as long as you provide information in your question, it'll get
-      answered
-    <gg0> teythoon: interested in reproducing mtab-dying-under-chroot?
-    <gg0> oh just realized it's not only under a chroot, chroot is on another
-      disk. might that make the difference?
-    <gg0> i didn't try to reproduce it by creating a chroot on a different
-      disk, which is what installer does
-    * gg0 wonders if it would have been better filing a bug against
-        cdimage.debian.org
-    <gg0> if no one fixes console=com0 thing, i have to think about a new acpi
-    <gg0> ok managed to workaround apt bug in installer, i can graphically
-      install last weekly
-    <gg0> no console=com0 means no vm shutdown though
-    <pere> gg0: wow.  impressed!
-    <gg0> patching CI to make CI workaround bugs CI spots is not so good
-    <gg0> any idea about another shutdown trick without console=com0 till
-      teythoon or youpi fix it?
-    <pere> nope
-    <gg0> current one: vm writes serial console to file and host loops grepping
-      "In tight loop: hit ctl-alt-del to reboot"
-    <gg0> -watchdog might be an alternative
-    <gg0> if there are watchdog agents that can run on hurd
-    <gg0> "watchdog" for instance doesn't build on hurd
-    <pere> it need kernel support
-    * gg0 testing -add-fd
-
-
-## IRC, freenode, #hurd, 2014-03-07
-
-    <gg0> teythoon: just mounted an additional fs, it's mounted but not present
-      in proc/mounts
-    <braunr> gg0: how did you mount it ?
-    <gg0> i was under /root, sid-chroot is the mountpoint. i did mount /dev/hd3
-      sid-chroot (relative path)
-    <braunr> does fsysopts confirm a new translator is running on sid-chroot ?
-    <gg0> i shut down vm, working on another one by mounting the same disk
-      which hosts a debchroot
-    <gg0> i'm trying to reproduce the mtab-dying-on-chroot issue i get with
-      debian installer
-    <gg0> at the end, os-prober gets stuck by reading /target/proc/mounts
-      (target is the installed system)
-    <gg0> to be precise it gets stuck at second access. at first it gives
-      Resource lost
-    <gg0> didn't manage to reproduce so far
-    <gg0> environment is pretty the same: booting with qemu multiboot
-      http://darnassus.sceen.net/~hurd-web/hurd/running/qemu/#multiboot
-    <gg0> so root on initrd + chroot on real disk 
-    <gg0> what's weird is that issue vanishes by removing console=com0 from
-      -append options
-
-
-### IRC, freenode, #hurd, 2014-03-08
-
-    <gg0> os-prober doesn't get stuck anymore and grub can install
-    <gg0> my guess is that without console=com0 /target/proc/mounts is just
-      accessed once
-
-
-## IRC, OFTC, #debian-hurd, 2014-03-08
-
-    <gg0> youpi: from #debian-cd http://paste.debian.net/plainh/559f669b
-    <gg0> any quick way to recreate initrd?
-    <teythoon> gg0: i'm working on that
-    <gg0> teythoon: that what?
-    <teythoon> gg0: there is genext2fs, i have some patches that allows one to
-      create nodes with passive translator records
-    <gg0> recreating initrd?
-    <teythoon> yes
-    <teythoon> in the meantime, you can mount the existing initrd and modify it
-    <gg0> well i'm following this one to rebuild whole cd then take an updated
-      initrd to test with your repo
-    <gg0> http://people.debian.org/~sthibault/hurd-i386/installer/README-d-i
-    <gg0> probably too much work to get that
-    <gg0> copying current /hurd to new initrd would be enough?
-    <youpi> just copy the precise translator you need
-    <youpi> also, no need to rebuild the whole cd just to replace the initrd
-    <youpi> simply copy the content of an existing is
-    <youpi> iso
-    <youpi> replace the initrd.gz there
-    <youpi> and then use grub-mkrescue to rebuild the ios
-    <youpi> development would be horrible if you had to rebuild everything from
-      zero everytime
-    <youpi> first thing to do when developping is first take the time to find
-      ways to work efficiently
-    <youpi> unfortunately I had to apply some patches
-    <youpi> first in d-i because isc-dhcp doens't work -> use the debian-ports
-      version
-    <youpi> then in d-i to automatically enable the debian-ports mirror
-    <youpi> and last in the debian-cd to include debian-ports-archive-keyring
-
-    <gg0> anything missing here?
-      http://people.debian.org/~sthibault/hurd-i386/installer/README-d-i
-    <gg0> mini.iso doesn't like any mirror
-    <gg0> "mirror does not support the specified release"
-    <gg0> something wrong/missing in my rebuilt
-    <gg0> youpi: anything wrong in http://paste.debian.net/plain/86258 ?
-    <gg0> i have/had problems with name resolution
-    <youpi> gg0: the patch makes sense for -bsd too, Cc them too
-    <gg0> i was wondering how many hunks in your patches are upstreamable
-    <youpi> normally it's zero
-    <gg0>
-      http://people.debian.org/~sthibault/hurd-i386/installer/patch-debootstrap
-    <gg0> why "release" instead on "main" by default? sid is never released
-    <youpi> only because my mirror directory is hacked one
-    <youpi> that merges debian.org, debian-ports.org, and my repo
-    <youpi> and I don't rebuild Release files, just Packages files
-    <gg0> i keep getting gpgv: BAD signature from "Debian Archive Automatic
-      Signing Key (7.0/Wheezy) <ftpmaster@debian.org>
-    <gg0> just before creating debootstrap chroot
-    <gg0> i applied hunk #2 only, installed modified debootstrap and put debs
-      under localdebs/
-    <gg0> trying a different mirror
-    <youpi> I don't know what issue you are encountering
-    <youpi> but again, it's way simpler and faster to just patch existing
-      images, rather than rebuilding them from zero
-    <gg0> ok just read i'd need a local mirror to build isos
-    <gg0> better using netinst and proxy cache
-
-
-## IRC, freenode, #hurd, 2014-03-09
-
-    <gg0> teythoon: shouldn't there be a patch which shows pid instead of task?
-    <gg0> 20:43 < teythoon> task /hurd/procfs(19) <EF><BF><BD>O<EF><BF><BD>
-      deallocating an invalid port 1049744, most probably a bug.
-    <teythoon> there is
-    <teythoon> i placed the functionality in proc first, but the wiki suggested
-      to put it in the exec server instead
-    <teythoon> i did that, it has the advantage, that the argv vector is easily
-      accessible
-    <teythoon> so i can also include the program name
-    <teythoon> but there are two programs, that are not started using the exec
-      server
-    <teythoon> the root filesystem and the exec server itself
-    <teythoon> so for these two processes, the approach does not work
-    <gg0> i see. so here we got two which could come from
-      ext2fs.static(initrd), exec(initrd) and ext2fs(chroot)
-      http://postimg.org/image/e3qyafd0b/ right?
-    <gg0> i also noticed that once mtab dies, by killing its procfs parent,
-      they both restart, but /target/proc is not in /proc/mounts anymore
-    <youpi> teythoon: for those we could use the first word of the module
-      command line
-    <gg0> restart doesn't means that by accessing /target/proc/mounts again it
-      works btw, it'll give Resource lost again
-    <teythoon> youpi: indeed
-    <teythoon> gg0: no, the ext2fs for /target will be started by the exec
-      server
-    <gg0> ok two invalid ports one from ext2fs.static and one exec then
-    <teythoon> gg0: what makes you attribute one to the exec server ?
-    <teythoon> i'm pretty sure that there is a bug in libfshelp, it's easily
-      triggered by killing an translator like procfs
-    <teythoon> i must have introduced it with the translator list work i've
-      done for the mtab translator
-    <gg0> teythoon: a totally wrong task-is-a-process reasoning probably
-    <gg0> just mounted another procfs which seems to work
-    <gg0> http://postimg.org/image/q6w9xzo2j/
-      http://postimg.org/image/cr998jfkr/
-    <teythoon> gg0: the mtab translators in your screenshots are oldish, what's
-      the point exactly ?
-    <teythoon> gg0: also, all tasks are processes. task is a mach concept,
-      whereas process is a posix concept implemented by hurds proc server. it
-      creates a process object for every mach task.
-    <gg0> my guess was that given we got two messages with different taskid:
-    <gg0> 16:01 < gg0> ok two invalid ports one from ext2fs.static and one exec
-      then
-    <gg0> screenshot is this one http://postimg.org/image/e3qyafd0b/
-    <gg0> btw what do you mean by oldish. except first one 01:18 < gg0>
-      http://postimg.org/image/oca8ormaj/ the only with current debian
-      packages, remaining are done with your latest packages
-    <gg0> in all cases i boot using qemu multiboot
-    <gg0> root@hurd01:~# cat /proc/version 
-    <gg0> Linux version 2.6.1 (GNU 0.5 GNU-Mach 1.4-486-dbg/Hurd-0.5
-      i686-AT386)
-    <gg0> it wouldn't be bad customizing version somehow, last commit id for
-      instance
-    <gg0> or build date
-    <gg0> user01@jessie01 ~$ cat /proc/version 
-    <gg0> Linux version 3.11-2-686-pae (debian-kernel@lists.debian.org) (gcc
-      version 4.8.2 (Debian 4.8.2-7) ) #1 SMP Debian 3.11.10-1 (2013-12-04)
-    <gg0> user01@jessie01 ~$ uname -v
-    <gg0> #1 SMP Debian 3.11.10-1 (2013-12-04)
-
-
-## IRC, OFTC, #debian-hurd, 2014-03-10
-
-    <gg0> tschwinge: i just meant Debian Jenkins provides (hopefully for hurd
-      too) continuos testing of debian installer, it doesn't produce .debs
diff --git a/open_issues/notmuch_n_gmane.mdwn b/open_issues/notmuch_n_gmane.mdwn
deleted file mode 100644
index 664c9876..00000000
--- a/open_issues/notmuch_n_gmane.mdwn
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-[[!meta title="Notmuch'n'Gmane"]]
-
-[[!taglink open_issue_documentation]]; [[ikiwiki]] issue.
-
-In `\[[!message-id
-"AANLkTinY1Cd4_qO_9euYJN8zev4hdr7_ANpjNG+yGRMn@mail.gmail.com"]]`, underscores
-are replaced with spaces in the rendered output: [[!message-id
-"AANLkTinY1Cd4_qO_9euYJN8zev4hdr7_ANpjNG+yGRMn@mail.gmail.com"]].
diff --git a/open_issues/nptl.mdwn b/open_issues/nptl.mdwn
deleted file mode 100644
index be0270df..00000000
--- a/open_issues/nptl.mdwn
+++ /dev/null
@@ -1,116 +0,0 @@
-[[!meta copyright="Copyright © 2010, 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_libpthread open_issue_glibc]]
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2010-07-31
-
-    <tschwinge> Other question: how difficult is a NPTL port?  Futexes and some
-      kernel interfaces for scheduling stuff etc. -- what else?
-    <youpi> actually NPTL doesn't _require_ futexes
-    <youpi> it just requires low-level locks
-    <youpi> Mmm, it seems to be so only in principle
-    <youpi> I can see futex names here and there in the generic code
-    <youpi> looks like Drepper isn't disciplined enough in that area either
-    <tschwinge> (well, why would he...)
-    <youpi> I'm not sure we really want to port NPTL
-    <tschwinge> OK.
-    <youpi> Drepper will keep finding things to add
-    <youpi> while the interface between glibc and libpthread isn't increasing
-      _so_ much
-    <tschwinge> ... and even less so the interfavce that actual applications
-      are using.
-    <tschwinge> We'd need to evaluate which benefits NPTL would bring.
-
-
-# IRC, freenode, #hurd, 2013-08-05
-
-    <gnu_srs> Hi, looks like kfreebsd are now using an NPTL-based pthread
-      library: FBTL, http://lists.debian.org/debian-bsd/2013/07/msg00060.html
-    <gnu_srs> Anything of interest for porting to Hurd? See also
-      http://lists.debian.org/debian-hurd/2013/08/msg00000.html
-    <azeem> Petr could've been more verbose in his announcements
-    <pinotree> and there's
-      http://www.gnu.org/software/hurd/open_issues/nptl.html in our wiki
-    <azeem> well, it seems to work fine for kFreeBSD:
-      http://lists.debian.org/debian-bsd/2013/07/msg00134.html
-    <azeem> and http://lists.debian.org/debian-bsd/2013/07/msg00138.html
-
-
-# IRC, freenode, #hurd, 2013-12-26
-
-    <nalaginrut> hm? has NPTL already supported for Hurd?
-    <braunr> probably won't ever be
-    <nalaginrut> so no plan for it?
-    <braunr> what for ?
-    <nalaginrut> no one interested in it, or no necessary adding it?
-    <braunr> why would you want nptl ?
-    <braunr> ntpl was created to overcome the defficiencies of linuxthreads
-    <braunr> we have our own libpthread
-    <braunr> (with its own defficiencies)
-    <braunr> supporting nptl would probably force us to implement something a
-      la clone
-    <nalaginrut> well, just inertia, now that Linux/kFreebsd has it
-    <braunr> are you sure kfreebsd has it ?
-    * teythoon thought we have clone
-    <nalaginrut> http://www.gnu.org/software/hurd/open_issues/nptl.html
-    <nalaginrut> seems someone mentioned it
-    <braunr> it's a "nptl-like implementation"
-    <nalaginrut> yes, I don't think it should be the same with Linux one, but
-      something like it
-    <braunr> but what for ?
-    <braunr> as mentioned in the link you just gave, "<tschwinge> We'd need to
-      evaluate which benefits NPTL would bring."
-    <nalaginrut> well, it's the note of 2010, I don't know if it's relative now
-    <braunr> relevant*
-    <nalaginrut> ah thanks
-    <braunr> but that still doesn't answer anything
-    <braunr> why are *you* talking about nptl ?
-    <nalaginrut> just saw pthread, then recall nptl, dunno
-    <nalaginrut> just asking
-    <braunr> :)
-    <nalaginrut> but you mentioned that Hurd has its own thread implementation,
-      is it similar or better than Linux NPTL?
-    <nalaginrut> or there's no benchmark yet?
-    <braunr> it's inferior in performance
-    <braunr> almost everything in the hurd is inferior performance-wise because
-      of the lack of optimizations
-    <braunr> currently we care more about correctness
-    <nalaginrut> speak the NPTL, I ever argued with a friend since I saw
-      drepper mentioned NPTL should be m:n, then I thought it is...But finally
-      I was failed, he didn't implement it yet...
-    <braunr> what ?
-    <braunr> nptl was always 1:1
-    <nalaginrut> but in nptl-design draft, I thought it's m:n
-    <nalaginrut> anyway, it's draft
-    <nalaginrut> and seems being a draft for long time
-    <braunr> never read anything like that
-    <nalaginrut> I think it's my misread
-    <nalaginrut> I have to go, see you guys tomorrow
-    <braunr> The consensus among the kernel developers was that an M-on-N
-      implementation
-    <braunr> would not fit into the Linux kernel concept. The necessary
-      infrastructure which would
-    <braunr> have to be added comes with a cost which is too high.
-
-
----
-
-# Resources
-
-  * <http://www.akkadia.org/drepper/nptl-design.pdf>
-
-  * <http://nptltracetool.sourceforge.net/>
-
-  * <http://posixtest.sourceforge.net/>
diff --git a/open_issues/o_exec.mdwn b/open_issues/o_exec.mdwn
deleted file mode 100644
index 3f77a0f2..00000000
--- a/open_issues/o_exec.mdwn
+++ /dev/null
@@ -1,54 +0,0 @@
-[[!meta copyright="Copyright © 2012 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]]."]]"""]]
-
-[[!meta title="O_EXEC"]]
-
-[[!tag open_issue_glibc open_issue_hurd]]
-
-
-# IRC, freenode, #hurd, 2012-04-24
-
-    <pinotree> interesting, glibc on every OS except hurd (so including linux
-      too) does not define O_EXEC
-    <pinotree> can somebody please help me understand a POSIX behaviour?
-    <pinotree> it's about fexecve:
-      http://pubs.opengroup.org/onlinepubs/9699919799/functions/fexecve.html
-    <pinotree> basically, it seems to me (reading the "errors" and "application
-      usage" sections) that O_EXEC for open() the fd is not mandatory, and if
-      not used fexecve will check for file permission at call time?
-    <pinotree> because currently libdiskfs and libnetfs require the fd to be
-      open with O_EXEC
-    <braunr> "Since execute permission is checked by fexecve(), the file
-      description fd need not have been opened with the O_EXEC flag"
-    <braunr> this one makes it clear checking for O_EXEC is wrong
-    <braunr> it looks like O_EXEC is only needed when you want to have files
-      for which only the execution permission is set
-    <braunr> but not the read one
-    <braunr> (i don't understand the "and write" part though)
-    <braunr> "exec will fail if the mode of the file associated with fd does
-      not grant execute permission to the calling process at the time fexecve()
-      is called."
-    <braunr> this one strengthens the impression you have, that fexecve indeed
-      checks file permissions at the time it's called
-    <braunr> pinotree: hope it helps
-    <pinotree> so it implies the following:
-    <pinotree> O_RDONLY → exec works if the file is readable
-    <braunr> exec works if the file is readable and/or executable (although
-      without read permissions you can't check it)
-    <braunr> (well, fexecve)
-    <pinotree> O_EXEC → exec requires that the permission of the file at
-      fexecve() time have +x
-    <braunr> i'd say ye so far
-    <braunr> yes
-    <pinotree> so we need to fix lib{disk,net}fs then
-    <braunr> seems so
-    <pinotree> enlighting, merci braunr 
-    <braunr> de rien
-    <pinotree> :)
diff --git a/open_issues/ogi.mdwn b/open_issues/ogi.mdwn
deleted file mode 100644
index c58d2ee1..00000000
--- a/open_issues/ogi.mdwn
+++ /dev/null
@@ -1,54 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2013 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]]."]]"""]]
-
-Go through Ognyan Kulev's (ogi) pages, and archive / hunt down what's still
-interesting.
-
-  * <http://debian.fmi.uni-sofia.bg/~ogi/hurd/links/>
-
-  * <http://debian.fmi.uni-sofia.bg/~ogi/hurd/ext3fs/>
-
-      * SVN ext2fs (ext2fs / large stores doc)
-
-        done
-
-      * ext3fs et al.
-
-        checking copyright situation, also for thesis / w.r.t. university
-        project
-
-        IRC, freenode, #hurd, 2013-02-15:
-
-            <tschwinge> ogi: The question was rather (IIRC) whether your
-              university has the copyright of this project, given it was done
-              on their time.
-            <ogi> tschwinge: no problems with my university
-
-
-# IRC, freenode, #hurd, 2013-02-15
-
-    <ogi> braunr: i want to update my ext3fs server to ext4 actually
-    <braunr> you have an ext3 server ?
-    <ogi> braunr: this was my M.Sc. thesis and the 2G patch was a side effect
-    <ogi> braunr: but it easily crashes under stress, so not usable
-    <braunr> it does ?
-    <ogi> braunr: it's not available for download ATM
-    <braunr> are you sure it's not a thread storm issue caused by the
-      unthrottled mach writebacks ?
-    <ogi> braunr: i don't know, haven't looked at it since 2004
-    <braunr> oh :)
-    <braunr> ok
-    <ogi> i have all ext3fs stuff archived, just haven't put it on
-      http://fire.tower.3.bg/ yet
-    <tschwinge> ogi: If the copyright situation is clear, we can put it into
-      upstream Git repositories, no matter how dirty it is.
-    <tschwinge> "dirty" in the sense of that it needs cleanup, has bugs, etc.
-    <ogi> so at some point i want to audit libdiskfs and then continue with
-      ext4fs: https://savannah.gnu.org/patch/?1839
diff --git a/open_issues/open_posix_test_suite.mdwn b/open_issues/open_posix_test_suite.mdwn
deleted file mode 100644
index 5afa6538..00000000
--- a/open_issues/open_posix_test_suite.mdwn
+++ /dev/null
@@ -1,2725 +0,0 @@
-[[!meta copyright="Copyright © 2009, 2012 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]]."]]"""]]
-
-[[!meta title="Open POSIX Test Suite"]]
-
-
-# 2009-07-27
-
-Here's a log of a [Open POSIX Test Suite](http://posixtest.sourceforge.net/)
-run (get sources, `make`, inspect `logfile`); this is from 2009-07-27 HEAD
-sources on a 2009-07-27 Debian GNU/Hurd system.
-
-The `logfile` has been post-processed with:
-
-    $ sed ↩
-        -e '/build: PASS$/d' ↩
-        -e '/link: PASS$/d' ↩
-        -e '/link: SKIP$/d' ↩
-        -e '/execution: PASS$/d'
-
-The tests that failed as *INTERRUPTED* were hanging and have manually been
-interrupted using `kill [PID]`.
-
-    conformance/definitions/signal_h/16-1: build: FAILED: Compiler output: 
-    conformance/definitions/signal_h/16-1.c:14: error: ‘SA_SIGINFO’ undeclared here (not in a function)
-    conformance/definitions/signal_h/16-1.c:15: error: ‘SA_NOCLDWAIT’ undeclared here (not in a function)
-    conformance/definitions/signal_h/26-1: build: FAILED: Compiler output: 
-    conformance/definitions/signal_h/26-1.c:9: error: expected ‘)’ before ‘int’
-    conformance/definitions/signal_h/26-1.c: In function ‘dummyfcn’:
-    conformance/definitions/signal_h/26-1.c:13: error: ‘pthread_kill_test’ undeclared (first use in this function)
-    conformance/definitions/signal_h/26-1.c:13: error: (Each undeclared identifier is reported only once
-    conformance/definitions/signal_h/26-1.c:13: error: for each function it appears in.)
-    conformance/definitions/signal_h/26-1.c:13: error: expected ‘;’ before ‘dummyvar’
-    conformance/definitions/signal_h/26-1.c:14: error: ‘dummyvar’ undeclared (first use in this function)
-    conformance/definitions/signal_h/26-1.c:14: error: ‘pthread_kill’ undeclared (first use in this function)
-    conformance/interfaces/aio_cancel/3-1: build: FAILED: Compiler output: 
-    conformance/interfaces/aio_cancel/3-1.c: In function ‘main’:
-    conformance/interfaces/aio_cancel/3-1.c:96: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/aio_cancel/3-1.c:96: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/aio_cancel/3-1.c:96: error: for each function it appears in.)
-    conformance/interfaces/aio_cancel/3-1.c:97: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/aio_fsync/1-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/aio_fsync/1-1.c: In function ‘main’:
-    conformance/interfaces/aio_fsync/1-1.c:19: error: implicit declaration of function ‘exit’
-    conformance/interfaces/aio_fsync/1-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/aio_fsync/10-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/aio_fsync/10-1.c: In function ‘main’:
-    conformance/interfaces/aio_fsync/10-1.c:33: error: implicit declaration of function ‘exit’
-    conformance/interfaces/aio_fsync/10-1.c:33: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/aio_fsync/11-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/aio_fsync/11-1.c: In function ‘main’:
-    conformance/interfaces/aio_fsync/11-1.c:19: error: implicit declaration of function ‘exit’
-    conformance/interfaces/aio_fsync/11-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/aio_fsync/13-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/aio_fsync/13-1.c: In function ‘main’:
-    conformance/interfaces/aio_fsync/13-1.c:19: error: implicit declaration of function ‘exit’
-    conformance/interfaces/aio_fsync/13-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/aio_fsync/6-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/aio_fsync/6-1.c: In function ‘main’:
-    conformance/interfaces/aio_fsync/6-1.c:19: error: implicit declaration of function ‘exit’
-    conformance/interfaces/aio_fsync/6-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/aio_fsync/7-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/aio_fsync/7-1.c: In function ‘main’:
-    conformance/interfaces/aio_fsync/7-1.c:19: error: implicit declaration of function ‘exit’
-    conformance/interfaces/aio_fsync/7-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/aio_read/12-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/aio_read/12-1.c: In function ‘main’:
-    conformance/interfaces/aio_read/12-1.c:34: error: implicit declaration of function ‘exit’
-    conformance/interfaces/aio_read/12-1.c:34: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/aio_read/13-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/aio_read/13-1.c: In function ‘main’:
-    conformance/interfaces/aio_read/13-1.c:33: error: implicit declaration of function ‘exit’
-    conformance/interfaces/aio_read/13-1.c:33: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/aio_read/14-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/aio_read/14-1.c: In function ‘main’:
-    conformance/interfaces/aio_read/14-1.c:34: error: implicit declaration of function ‘exit’
-    conformance/interfaces/aio_read/14-1.c:34: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/aio_read/15-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/aio_read/15-1.c: In function ‘main’:
-    conformance/interfaces/aio_read/15-1.c:30: error: implicit declaration of function ‘exit’
-    conformance/interfaces/aio_read/15-1.c:30: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/aio_read/6-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/aio_read/6-1.c: In function ‘main’:
-    conformance/interfaces/aio_read/6-1.c:30: error: implicit declaration of function ‘exit’
-    conformance/interfaces/aio_read/6-1.c:30: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/aio_suspend/1-1: build: FAILED: Compiler output: 
-    conformance/interfaces/aio_suspend/1-1.c: In function ‘main’:
-    conformance/interfaces/aio_suspend/1-1.c:120: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/aio_suspend/1-1.c:120: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/aio_suspend/1-1.c:120: error: for each function it appears in.)
-    conformance/interfaces/aio_suspend/1-1.c:126: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/aio_suspend/2-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/aio_suspend/2-1.c: In function ‘main’:
-    conformance/interfaces/aio_suspend/2-1.c:31: error: implicit declaration of function ‘exit’
-    conformance/interfaces/aio_suspend/2-1.c:31: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/aio_suspend/6-1: build: FAILED: Compiler output: 
-    conformance/interfaces/aio_suspend/6-1.c: In function ‘main’:
-    conformance/interfaces/aio_suspend/6-1.c:116: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/aio_suspend/6-1.c:116: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/aio_suspend/6-1.c:116: error: for each function it appears in.)
-    conformance/interfaces/aio_suspend/6-1.c:122: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/aio_suspend/7-1: build: FAILED: Compiler output: 
-    conformance/interfaces/aio_suspend/7-1.c: In function ‘main’:
-    conformance/interfaces/aio_suspend/7-1.c:118: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/aio_suspend/7-1.c:118: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/aio_suspend/7-1.c:118: error: for each function it appears in.)
-    conformance/interfaces/aio_suspend/7-1.c:124: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/aio_suspend/8-1: build: FAILED: Compiler output: 
-    conformance/interfaces/aio_suspend/8-1.c: In function ‘main’:
-    conformance/interfaces/aio_suspend/8-1.c:121: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/aio_suspend/8-1.c:121: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/aio_suspend/8-1.c:121: error: for each function it appears in.)
-    conformance/interfaces/aio_suspend/8-1.c:127: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/aio_write/10-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/aio_write/10-1.c: In function ‘main’:
-    conformance/interfaces/aio_write/10-1.c:32: error: implicit declaration of function ‘exit’
-    conformance/interfaces/aio_write/10-1.c:32: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/aio_write/11-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/aio_write/11-1.c: In function ‘main’:
-    conformance/interfaces/aio_write/11-1.c:32: error: implicit declaration of function ‘exit’
-    conformance/interfaces/aio_write/11-1.c:32: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/aio_write/12-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/aio_write/12-1.c: In function ‘main’:
-    conformance/interfaces/aio_write/12-1.c:31: error: implicit declaration of function ‘exit’
-    conformance/interfaces/aio_write/12-1.c:31: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/aio_write/13-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/aio_write/13-1.c: In function ‘main’:
-    conformance/interfaces/aio_write/13-1.c:30: error: implicit declaration of function ‘exit’
-    conformance/interfaces/aio_write/13-1.c:30: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/aio_write/4-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/aio_write/4-1.c: In function ‘main’:
-    conformance/interfaces/aio_write/4-1.c:30: error: implicit declaration of function ‘exit’
-    conformance/interfaces/aio_write/4-1.c:30: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/fork/2-1: build: FAILED: Compiler output: 
-    conformance/interfaces/fork/2-1.c: In function ‘main’:
-    conformance/interfaces/fork/2-1.c:240: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/fork/2-1.c:240: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/fork/2-1.c:240: error: for each function it appears in.)
-    conformance/interfaces/fork/2-1.c:241: error: ‘SA_NOCLDWAIT’ undeclared (first use in this function)
-    conformance/interfaces/lio_listio/1-1: build: FAILED: Compiler output: 
-    conformance/interfaces/lio_listio/1-1.c: In function ‘main’:
-    conformance/interfaces/lio_listio/1-1.c:110: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/lio_listio/1-1.c:110: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/lio_listio/1-1.c:110: error: for each function it appears in.)
-    conformance/interfaces/lio_listio/1-1.c:122: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/lio_listio/10-1: build: FAILED: Compiler output: 
-    conformance/interfaces/lio_listio/10-1.c: In function ‘main’:
-    conformance/interfaces/lio_listio/10-1.c:107: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/lio_listio/10-1.c:107: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/lio_listio/10-1.c:107: error: for each function it appears in.)
-    conformance/interfaces/lio_listio/10-1.c:119: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/lio_listio/11-1: build: FAILED: Compiler output: 
-    conformance/interfaces/lio_listio/11-1.c: In function ‘main’:
-    conformance/interfaces/lio_listio/11-1.c:111: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/lio_listio/11-1.c:111: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/lio_listio/11-1.c:111: error: for each function it appears in.)
-    conformance/interfaces/lio_listio/11-1.c:123: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/lio_listio/14-1: build: FAILED: Compiler output: 
-    conformance/interfaces/lio_listio/14-1.c: In function ‘main’:
-    conformance/interfaces/lio_listio/14-1.c:111: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/lio_listio/14-1.c:111: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/lio_listio/14-1.c:111: error: for each function it appears in.)
-    conformance/interfaces/lio_listio/14-1.c:123: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/lio_listio/15-1: build: FAILED: Compiler output: 
-    conformance/interfaces/lio_listio/15-1.c: In function ‘main’:
-    conformance/interfaces/lio_listio/15-1.c:111: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/lio_listio/15-1.c:111: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/lio_listio/15-1.c:111: error: for each function it appears in.)
-    conformance/interfaces/lio_listio/15-1.c:123: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/lio_listio/16-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/lio_listio/16-1.c: In function ‘main’:
-    conformance/interfaces/lio_listio/16-1.c:32: error: implicit declaration of function ‘exit’
-    conformance/interfaces/lio_listio/16-1.c:32: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/lio_listio/17-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/lio_listio/17-1.c: In function ‘main’:
-    conformance/interfaces/lio_listio/17-1.c:19: error: implicit declaration of function ‘exit’
-    conformance/interfaces/lio_listio/17-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/lio_listio/19-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/lio_listio/19-1.c: In function ‘main’:
-    conformance/interfaces/lio_listio/19-1.c:19: error: implicit declaration of function ‘exit’
-    conformance/interfaces/lio_listio/19-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/lio_listio/2-1: build: FAILED: Compiler output: 
-    conformance/interfaces/lio_listio/2-1.c: In function ‘main’:
-    conformance/interfaces/lio_listio/2-1.c:106: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/lio_listio/2-1.c:106: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/lio_listio/2-1.c:106: error: for each function it appears in.)
-    conformance/interfaces/lio_listio/2-1.c:118: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/lio_listio/20-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/lio_listio/20-1.c: In function ‘main’:
-    conformance/interfaces/lio_listio/20-1.c:19: error: implicit declaration of function ‘exit’
-    conformance/interfaces/lio_listio/20-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/lio_listio/21-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/lio_listio/21-1.c: In function ‘main’:
-    conformance/interfaces/lio_listio/21-1.c:19: error: implicit declaration of function ‘exit’
-    conformance/interfaces/lio_listio/21-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/lio_listio/22-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/lio_listio/22-1.c: In function ‘main’:
-    conformance/interfaces/lio_listio/22-1.c:19: error: implicit declaration of function ‘exit’
-    conformance/interfaces/lio_listio/22-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/lio_listio/23-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/lio_listio/23-1.c: In function ‘main’:
-    conformance/interfaces/lio_listio/23-1.c:19: error: implicit declaration of function ‘exit’
-    conformance/interfaces/lio_listio/23-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/lio_listio/24-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/lio_listio/24-1.c: In function ‘main’:
-    conformance/interfaces/lio_listio/24-1.c:19: error: implicit declaration of function ‘exit’
-    conformance/interfaces/lio_listio/24-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/lio_listio/25-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/lio_listio/25-1.c: In function ‘main’:
-    conformance/interfaces/lio_listio/25-1.c:19: error: implicit declaration of function ‘exit’
-    conformance/interfaces/lio_listio/25-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’
-    conformance/interfaces/lio_listio/3-1: build: FAILED: Compiler output: 
-    conformance/interfaces/lio_listio/3-1.c: In function ‘main’:
-    conformance/interfaces/lio_listio/3-1.c:107: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/lio_listio/3-1.c:107: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/lio_listio/3-1.c:107: error: for each function it appears in.)
-    conformance/interfaces/lio_listio/3-1.c:119: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/lio_listio/4-1: build: FAILED: Compiler output: 
-    conformance/interfaces/lio_listio/4-1.c: In function ‘main’:
-    conformance/interfaces/lio_listio/4-1.c:114: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/lio_listio/4-1.c:114: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/lio_listio/4-1.c:114: error: for each function it appears in.)
-    conformance/interfaces/lio_listio/4-1.c:126: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/lio_listio/7-1: build: FAILED: Compiler output: 
-    conformance/interfaces/lio_listio/7-1.c: In function ‘main’:
-    conformance/interfaces/lio_listio/7-1.c:113: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/lio_listio/7-1.c:113: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/lio_listio/7-1.c:113: error: for each function it appears in.)
-    conformance/interfaces/lio_listio/7-1.c:125: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/mq_open/27-1: build: FAILED: Compiler output: 
-    conformance/interfaces/mq_open/27-1.c: In function ‘main’:
-    conformance/interfaces/mq_open/27-1.c:27: error: ‘PATH_MAX’ undeclared (first use in this function)
-    conformance/interfaces/mq_open/27-1.c:27: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/mq_open/27-1.c:27: error: for each function it appears in.)
-    cc1: warnings being treated as errors
-    conformance/interfaces/mq_open/27-1.c:27: error: unused variable ‘qname’
-    conformance/interfaces/mq_send/13-1: build: FAILED: Compiler output: 
-    conformance/interfaces/mq_send/13-1.c:30: error: ‘MQ_PRIO_MAX’ undeclared here (not in a function)
-    conformance/interfaces/mq_send/4-1: build: FAILED: Compiler output: 
-    conformance/interfaces/mq_send/4-1.c: In function ‘main’:
-    conformance/interfaces/mq_send/4-1.c:41: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function)
-    conformance/interfaces/mq_send/4-1.c:41: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/mq_send/4-1.c:41: error: for each function it appears in.)
-    conformance/interfaces/mq_send/4-2: build: FAILED: Compiler output: 
-    conformance/interfaces/mq_send/4-2.c: In function ‘main’:
-    conformance/interfaces/mq_send/4-2.c:41: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function)
-    conformance/interfaces/mq_send/4-2.c:41: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/mq_send/4-2.c:41: error: for each function it appears in.)
-    conformance/interfaces/mq_send/4-3: build: FAILED: Compiler output: 
-    conformance/interfaces/mq_send/4-3.c: In function ‘main’:
-    conformance/interfaces/mq_send/4-3.c:51: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function)
-    conformance/interfaces/mq_send/4-3.c:51: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/mq_send/4-3.c:51: error: for each function it appears in.)
-    conformance/interfaces/mq_send/7-1: build: FAILED: Compiler output: 
-    conformance/interfaces/mq_send/7-1.c: In function ‘main’:
-    conformance/interfaces/mq_send/7-1.c:60: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function)
-    conformance/interfaces/mq_send/7-1.c:60: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/mq_send/7-1.c:60: error: for each function it appears in.)
-    conformance/interfaces/mq_timedsend/13-1: build: FAILED: Compiler output: 
-    conformance/interfaces/mq_timedsend/13-1.c:31: error: ‘MQ_PRIO_MAX’ undeclared here (not in a function)
-    conformance/interfaces/mq_timedsend/4-1: build: FAILED: Compiler output: 
-    conformance/interfaces/mq_timedsend/4-1.c: In function ‘main’:
-    conformance/interfaces/mq_timedsend/4-1.c:45: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function)
-    conformance/interfaces/mq_timedsend/4-1.c:45: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/mq_timedsend/4-1.c:45: error: for each function it appears in.)
-    conformance/interfaces/mq_timedsend/4-2: build: FAILED: Compiler output: 
-    conformance/interfaces/mq_timedsend/4-2.c: In function ‘main’:
-    conformance/interfaces/mq_timedsend/4-2.c:45: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function)
-    conformance/interfaces/mq_timedsend/4-2.c:45: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/mq_timedsend/4-2.c:45: error: for each function it appears in.)
-    conformance/interfaces/mq_timedsend/4-3: build: FAILED: Compiler output: 
-    conformance/interfaces/mq_timedsend/4-3.c: In function ‘main’:
-    conformance/interfaces/mq_timedsend/4-3.c:55: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function)
-    conformance/interfaces/mq_timedsend/4-3.c:55: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/mq_timedsend/4-3.c:55: error: for each function it appears in.)
-    conformance/interfaces/pthread_attr_getstack/1-1: build: FAILED: Compiler output: 
-    conformance/interfaces/pthread_attr_getstack/1-1.c: In function ‘main’:
-    conformance/interfaces/pthread_attr_getstack/1-1.c:54: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function)
-    conformance/interfaces/pthread_attr_getstack/1-1.c:54: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/pthread_attr_getstack/1-1.c:54: error: for each function it appears in.)
-    conformance/interfaces/pthread_attr_getstacksize/1-1: build: FAILED: Compiler output: 
-    conformance/interfaces/pthread_attr_getstacksize/1-1.c: In function ‘main’:
-    conformance/interfaces/pthread_attr_getstacksize/1-1.c:53: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function)
-    conformance/interfaces/pthread_attr_getstacksize/1-1.c:53: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/pthread_attr_getstacksize/1-1.c:53: error: for each function it appears in.)
-    conformance/interfaces/pthread_attr_setstack/1-1: build: FAILED: Compiler output: 
-    conformance/interfaces/pthread_attr_setstack/1-1.c: In function ‘main’:
-    conformance/interfaces/pthread_attr_setstack/1-1.c:63: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function)
-    conformance/interfaces/pthread_attr_setstack/1-1.c:63: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/pthread_attr_setstack/1-1.c:63: error: for each function it appears in.)
-    conformance/interfaces/pthread_attr_setstack/2-1: build: FAILED: Compiler output: 
-    conformance/interfaces/pthread_attr_setstack/2-1.c: In function ‘main’:
-    conformance/interfaces/pthread_attr_setstack/2-1.c:90: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function)
-    conformance/interfaces/pthread_attr_setstack/2-1.c:90: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/pthread_attr_setstack/2-1.c:90: error: for each function it appears in.)
-    conformance/interfaces/pthread_attr_setstack/4-1: build: FAILED: Compiler output: 
-    conformance/interfaces/pthread_attr_setstack/4-1.c: In function ‘main’:
-    conformance/interfaces/pthread_attr_setstack/4-1.c:73: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function)
-    conformance/interfaces/pthread_attr_setstack/4-1.c:73: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/pthread_attr_setstack/4-1.c:73: error: for each function it appears in.)
-    conformance/interfaces/pthread_attr_setstack/6-1: build: FAILED: Compiler output: 
-    conformance/interfaces/pthread_attr_setstack/6-1.c: In function ‘main’:
-    conformance/interfaces/pthread_attr_setstack/6-1.c:59: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function)
-    conformance/interfaces/pthread_attr_setstack/6-1.c:59: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/pthread_attr_setstack/6-1.c:59: error: for each function it appears in.)
-    conformance/interfaces/pthread_attr_setstack/7-1: build: FAILED: Compiler output: 
-    conformance/interfaces/pthread_attr_setstack/7-1.c: In function ‘main’:
-    conformance/interfaces/pthread_attr_setstack/7-1.c:60: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function)
-    conformance/interfaces/pthread_attr_setstack/7-1.c:60: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/pthread_attr_setstack/7-1.c:60: error: for each function it appears in.)
-    conformance/interfaces/pthread_attr_setstacksize/1-1: build: FAILED: Compiler output: 
-    conformance/interfaces/pthread_attr_setstacksize/1-1.c: In function ‘main’:
-    conformance/interfaces/pthread_attr_setstacksize/1-1.c:41: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function)
-    conformance/interfaces/pthread_attr_setstacksize/1-1.c:41: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/pthread_attr_setstacksize/1-1.c:41: error: for each function it appears in.)
-    conformance/interfaces/pthread_attr_setstacksize/2-1: build: FAILED: Compiler output: 
-    conformance/interfaces/pthread_attr_setstacksize/2-1.c: In function ‘main’:
-    conformance/interfaces/pthread_attr_setstacksize/2-1.c:79: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function)
-    conformance/interfaces/pthread_attr_setstacksize/2-1.c:79: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/pthread_attr_setstacksize/2-1.c:79: error: for each function it appears in.)
-    conformance/interfaces/pthread_attr_setstacksize/4-1: build: FAILED: Compiler output: 
-    conformance/interfaces/pthread_attr_setstacksize/4-1.c: In function ‘main’:
-    conformance/interfaces/pthread_attr_setstacksize/4-1.c:50: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function)
-    conformance/interfaces/pthread_attr_setstacksize/4-1.c:50: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/pthread_attr_setstacksize/4-1.c:50: error: for each function it appears in.)
-    conformance/interfaces/pthread_key_create/speculative/5-1: build: FAILED: Compiler output: 
-    conformance/interfaces/pthread_key_create/speculative/5-1.c:37: error: ‘PTHREAD_KEYS_MAX’ undeclared here (not in a function)
-    conformance/interfaces/pthread_once/3-1: build: FAILED: Compiler output: 
-    conformance/interfaces/pthread_once/3-1.c: In function ‘main’:
-    conformance/interfaces/pthread_once/3-1.c:71: error: expected expression before ‘{’ token
-    conformance/interfaces/pthread_once/6-1: build: FAILED: Compiler output: 
-    conformance/interfaces/pthread_once/6-1.c: In function ‘test’:
-    conformance/interfaces/pthread_once/6-1.c:199: error: expected expression before ‘{’ token
-    conformance/interfaces/sched_yield/1-1: build: FAILED: Compiler output: 
-    cc1: warnings being treated as errors
-    conformance/interfaces/sched_yield/1-1.c: In function ‘set_process_affinity’:
-    conformance/interfaces/sched_yield/1-1.c:87: error: implicit declaration of function ‘__CPU_ZERO_S’
-    conformance/interfaces/sched_yield/1-1.c:89: error: implicit declaration of function ‘__CPU_SET_S’
-    conformance/interfaces/sched_yield/1-1.c: In function ‘set_thread_affinity’:
-    conformance/interfaces/sched_yield/1-1.c:119: error: implicit declaration of function ‘pthread_setaffinity_np’
-    conformance/interfaces/sched_yield/1-1.c: In function ‘runner’:
-    conformance/interfaces/sched_yield/1-1.c:136: error: format ‘%ld’ expects type ‘long int’, but argument 3 has type ‘pthread_t’
-    conformance/interfaces/sched_yield/1-1.c: In function ‘busy_thread’:
-    conformance/interfaces/sched_yield/1-1.c:159: error: format ‘%ld’ expects type ‘long int’, but argument 3 has type ‘pthread_t’
-    conformance/interfaces/sem_init/6-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sem_init/6-1.c: In function ‘main’:
-    conformance/interfaces/sem_init/6-1.c:29: error: ‘SEM_VALUE_MAX’ undeclared (first use in this function)
-    conformance/interfaces/sem_init/6-1.c:29: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sem_init/6-1.c:29: error: for each function it appears in.)
-    conformance/interfaces/sem_open/5-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sem_open/5-1.c: In function ‘main’:
-    conformance/interfaces/sem_open/5-1.c:32: error: ‘SEM_VALUE_MAX’ undeclared (first use in this function)
-    conformance/interfaces/sem_open/5-1.c:32: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sem_open/5-1.c:32: error: for each function it appears in.)
-    conformance/interfaces/sigaction/10-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/10-1.c: In function ‘main’:
-    conformance/interfaces/sigaction/10-1.c:41: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/10-1.c:41: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/10-1.c:41: error: for each function it appears in.)
-    conformance/interfaces/sigaction/11-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/11-1.c: In function ‘main’:
-    conformance/interfaces/sigaction/11-1.c:50: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/11-1.c:50: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/11-1.c:50: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-1.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-1.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-1.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-1.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-10: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-10.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-10.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-10.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-10.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-11: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-11.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-11.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-11.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-11.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-12: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-12.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-12.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-12.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-12.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-13: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-13.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-13.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-13.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-13.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-14: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-14.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-14.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-14.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-14.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-15: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-15.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-15.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-15.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-15.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-16: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-16.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-16.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-16.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-16.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-17: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-17.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-17.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-17.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-17.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-18: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-18.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-18.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-18.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-18.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-19: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-19.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-19.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-19.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-19.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-2: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-2.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-2.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-2.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-2.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-20: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-20.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-20.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-20.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-20.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-21: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-21.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-21.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-21.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-21.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-22: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-22.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-22.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-22.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-22.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-23: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-23.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-23.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-23.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-23.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-24: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-24.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-24.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-24.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-24.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-25: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-25.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-25.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-25.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-25.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-26: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-26.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-26.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-26.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-26.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-3: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-3.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-3.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-3.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-3.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-4: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-4.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-4.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-4.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-4.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-5: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-5.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-5.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-5.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-5.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-6: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-6.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-6.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-6.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-6.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-7: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-7.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-7.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-7.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-7.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-8: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-8.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-8.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-8.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-8.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/19-9: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/19-9.c: In function ‘main’:
-    conformance/interfaces/sigaction/19-9.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/19-9.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/19-9.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/21-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/21-1.c: In function ‘main’:
-    conformance/interfaces/sigaction/21-1.c:36: error: ‘SA_NOCLDWAIT’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/21-1.c:36: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/21-1.c:36: error: for each function it appears in.)
-    conformance/interfaces/sigaction/29-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/29-1.c: In function ‘handler’:
-    conformance/interfaces/sigaction/29-1.c:95: error: ‘SIGRTMAX’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/29-1.c:95: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/29-1.c:95: error: for each function it appears in.)
-    conformance/interfaces/sigaction/29-1.c: In function ‘main’:
-    conformance/interfaces/sigaction/29-1.c:133: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/29-1.c:145: error: ‘SIGRTMAX’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/30-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/30-1.c: In function ‘main’:
-    conformance/interfaces/sigaction/30-1.c:117: error: ‘SIGRTMAX’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/30-1.c:117: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/30-1.c:117: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-1.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-1.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-1.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-1.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-10: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-10.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-10.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-10.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-10.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-11: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-11.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-11.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-11.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-11.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-12: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-12.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-12.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-12.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-12.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-13: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-13.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-13.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-13.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-13.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-14: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-14.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-14.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-14.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-14.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-15: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-15.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-15.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-15.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-15.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-16: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-16.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-16.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-16.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-16.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-17: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-17.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-17.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-17.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-17.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-18: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-18.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-18.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-18.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-18.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-19: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-19.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-19.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-19.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-19.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-2: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-2.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-2.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-2.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-2.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-20: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-20.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-20.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-20.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-20.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-21: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-21.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-21.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-21.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-21.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-22: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-22.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-22.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-22.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-22.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-23: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-23.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-23.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-23.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-23.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-24: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-24.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-24.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-24.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-24.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-25: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-25.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-25.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-25.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-25.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-26: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-26.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-26.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-26.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-26.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-3: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-3.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-3.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-3.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-3.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-4: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-4.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-4.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-4.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-4.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-5: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-5.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-5.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-5.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-5.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-6: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-6.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-6.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-6.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-6.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-7: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-7.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-7.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-7.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-7.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-8: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-8.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-8.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-8.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-8.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/6-9: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/6-9.c: In function ‘main’:
-    conformance/interfaces/sigaction/6-9.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/6-9.c:34: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/6-9.c:34: error: for each function it appears in.)
-    conformance/interfaces/sigaction/9-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigaction/9-1.c: In function ‘main’:
-    conformance/interfaces/sigaction/9-1.c:49: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigaction/9-1.c:49: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigaction/9-1.c:49: error: for each function it appears in.)
-    conformance/interfaces/sigqueue/1-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigqueue/1-1.c: In function ‘myhandler’:
-    conformance/interfaces/sigqueue/1-1.c:33: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/sigqueue/1-1.c:33: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigqueue/1-1.c:33: error: for each function it appears in.)
-    conformance/interfaces/sigqueue/1-1.c: In function ‘main’:
-    conformance/interfaces/sigqueue/1-1.c:46: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigqueue/1-1.c:49: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/sigqueue/4-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigqueue/4-1.c: In function ‘main’:
-    conformance/interfaces/sigqueue/4-1.c:45: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigqueue/4-1.c:45: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigqueue/4-1.c:45: error: for each function it appears in.)
-    conformance/interfaces/sigqueue/4-1.c:48: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/sigqueue/5-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigqueue/5-1.c: In function ‘main’:
-    conformance/interfaces/sigqueue/5-1.c:48: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/sigqueue/5-1.c:48: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigqueue/5-1.c:48: error: for each function it appears in.)
-    conformance/interfaces/sigqueue/6-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigqueue/6-1.c: In function ‘main’:
-    conformance/interfaces/sigqueue/6-1.c:55: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigqueue/6-1.c:55: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigqueue/6-1.c:55: error: for each function it appears in.)
-    conformance/interfaces/sigqueue/6-1.c:58: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/sigqueue/7-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigqueue/7-1.c: In function ‘main’:
-    conformance/interfaces/sigqueue/7-1.c:52: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigqueue/7-1.c:52: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigqueue/7-1.c:52: error: for each function it appears in.)
-    conformance/interfaces/sigqueue/7-1.c:58: error: ‘SIGRTMAX’ undeclared (first use in this function)
-    conformance/interfaces/sigqueue/7-1.c:58: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/sigqueue/8-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigqueue/8-1.c: In function ‘main’:
-    conformance/interfaces/sigqueue/8-1.c:46: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigqueue/8-1.c:46: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigqueue/8-1.c:46: error: for each function it appears in.)
-    conformance/interfaces/sigqueue/8-1.c:49: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/sigqueue/9-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigqueue/9-1.c: In function ‘main’:
-    conformance/interfaces/sigqueue/9-1.c:46: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigqueue/9-1.c:46: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigqueue/9-1.c:46: error: for each function it appears in.)
-    conformance/interfaces/sigqueue/9-1.c:49: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/sigwait/2-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigwait/2-1.c: In function ‘main’:
-    conformance/interfaces/sigwait/2-1.c:45: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/sigwait/2-1.c:45: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigwait/2-1.c:45: error: for each function it appears in.)
-    conformance/interfaces/sigwait/7-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigwait/7-1.c: In function ‘main’:
-    conformance/interfaces/sigwait/7-1.c:114: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/sigwait/7-1.c:114: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigwait/7-1.c:114: error: for each function it appears in.)
-    conformance/interfaces/sigwait/7-1.c:114: error: ‘SIGRTMAX’ undeclared (first use in this function)
-    conformance/interfaces/sigwaitinfo/2-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigwaitinfo/2-1.c: In function ‘main’:
-    conformance/interfaces/sigwaitinfo/2-1.c:44: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigwaitinfo/2-1.c:44: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigwaitinfo/2-1.c:44: error: for each function it appears in.)
-    conformance/interfaces/sigwaitinfo/2-1.c:49: error: ‘SIGRTMAX’ undeclared (first use in this function)
-    conformance/interfaces/sigwaitinfo/2-1.c:49: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/sigwaitinfo/5-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigwaitinfo/5-1.c: In function ‘main’:
-    conformance/interfaces/sigwaitinfo/5-1.c:41: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigwaitinfo/5-1.c:41: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigwaitinfo/5-1.c:41: error: for each function it appears in.)
-    conformance/interfaces/sigwaitinfo/6-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigwaitinfo/6-1.c: In function ‘main’:
-    conformance/interfaces/sigwaitinfo/6-1.c:41: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigwaitinfo/6-1.c:41: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigwaitinfo/6-1.c:41: error: for each function it appears in.)
-    conformance/interfaces/sigwaitinfo/7-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigwaitinfo/7-1.c: In function ‘main’:
-    conformance/interfaces/sigwaitinfo/7-1.c:48: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigwaitinfo/7-1.c:48: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigwaitinfo/7-1.c:48: error: for each function it appears in.)
-    conformance/interfaces/sigwaitinfo/7-1.c:51: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/interfaces/sigwaitinfo/8-1: build: FAILED: Compiler output: 
-    conformance/interfaces/sigwaitinfo/8-1.c: In function ‘main’:
-    conformance/interfaces/sigwaitinfo/8-1.c:47: error: ‘SA_SIGINFO’ undeclared (first use in this function)
-    conformance/interfaces/sigwaitinfo/8-1.c:47: error: (Each undeclared identifier is reported only once
-    conformance/interfaces/sigwaitinfo/8-1.c:47: error: for each function it appears in.)
-    conformance/interfaces/sigwaitinfo/8-1.c:50: error: ‘SIGRTMIN’ undeclared (first use in this function)
-    conformance/definitions/mqueue_h/1-1: execution: UNTESTED: Output: 
-    Not Implemented!
-    conformance/definitions/mqueue_h/10-1: execution: UNTESTED: Output: 
-    Test not implemented!
-    conformance/definitions/mqueue_h/11-1: execution: UNTESTED: Output: 
-    Test not implemented!
-    conformance/definitions/mqueue_h/2-1: execution: UNTESTED: Output: 
-    Test not implemented!
-    conformance/definitions/mqueue_h/3-1: execution: UNTESTED: Output: 
-    Test not implemented!
-    conformance/definitions/mqueue_h/4-1: execution: UNTESTED: Output: 
-    Test not implemented!
-    conformance/definitions/mqueue_h/5-1: execution: UNTESTED: Output: 
-    Test not implemented!
-    conformance/definitions/mqueue_h/6-1: execution: UNTESTED: Output: 
-    Test not implemented!
-    conformance/definitions/mqueue_h/7-1: execution: UNTESTED: Output: 
-    Test not implemented!
-    conformance/definitions/mqueue_h/8-1: execution: UNTESTED: Output: 
-    Test not implemented!
-    conformance/definitions/mqueue_h/9-1: execution: UNTESTED: Output: 
-    Test not implemented!
-    conformance/interfaces/aio_cancel/1-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_cancel/10-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_cancel/2-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_cancel/2-2: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_cancel/4-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_cancel/5-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_cancel/6-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_cancel/7-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_cancel/8-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_cancel/9-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_error/1-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_error/2-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_error/3-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_fsync/12-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_fsync/14-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_fsync/2-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_fsync/3-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_fsync/4-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_fsync/4-2: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_fsync/5-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_fsync/8-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_fsync/8-2: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_fsync/8-3: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_fsync/8-4: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_fsync/9-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_read/1-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_read/10-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_read/11-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_read/11-2: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_read/2-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_read/3-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_read/3-2: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_read/4-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_read/5-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_read/7-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_read/8-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_read/9-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_return/1-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_return/2-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_return/3-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_return/3-2: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_return/4-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_suspend/3-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_suspend/4-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_suspend/5-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_suspend/9-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_write/1-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_write/1-2: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_write/2-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_write/3-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_write/5-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_write/6-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_write/7-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_write/8-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_write/8-2: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_write/9-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/aio_write/9-2: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/clock_getcpuclockid/1-1: execution: UNSUPPORTED: Output: 
-    _POSIX_CPUTIME unsupported
-    conformance/interfaces/clock_getcpuclockid/2-1: execution: UNSUPPORTED: Output: 
-    _POSIX_CPUTIME unsupported
-    conformance/interfaces/clock_getres/3-1: execution: FAILED: Output: 
-    clock_getres() failed
-    Test FAILED
-    conformance/interfaces/clock_getres/7-1: execution: UNSUPPORTED: Output: 
-    _POSIX_CPUTIME not supported
-    conformance/interfaces/clock_getres/8-1: execution: UNSUPPORTED: Output: 
-    _POSIX_THREAD_CPUTIME not supported
-    conformance/interfaces/clock_gettime/3-1: execution: UNSUPPORTED: Output: 
-    CLOCK_MONOTONIC unsupported
-    conformance/interfaces/clock_gettime/4-1: execution: UNSUPPORTED: Output: 
-    _POSIX_CPUTIME unsupported
-    conformance/interfaces/clock_nanosleep/10-1: execution: FAILED: Output: 
-    In handler
-    errno != EINTR
-    Test FAILED
-    conformance/interfaces/clock_nanosleep/9-1: execution: FAILED: Output: 
-    In handler
-    clock_nanosleep() did not return EINTR
-    Child did not exit normally.
-    Test FAILED
-    conformance/interfaces/clock_settime/1-1: execution: UNTESTED: Output: 
-    Run this test as ROOT, not as a Regular User
-    conformance/interfaces/clock_settime/19-1: execution: UNTESTED: Output: 
-    Run this test as ROOT, not as a Regular User
-    conformance/interfaces/clock_settime/4-1: execution: UNTESTED: Output: 
-    Run this test as ROOT, not as a Regular User
-    conformance/interfaces/clock_settime/4-2: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/clock_settime/5-1: execution: UNTESTED: Output: 
-    Run this test as ROOT, not as a Regular User
-    conformance/interfaces/clock_settime/5-2: execution: UNTESTED: Output: 
-    Run this test as ROOT, not as a Regular User
-    conformance/interfaces/clock_settime/7-1: execution: UNTESTED: Output: 
-    Run this test as ROOT, not as a Regular User
-    conformance/interfaces/clock_settime/7-2: execution: UNTESTED: Output: 
-    Run this test as ROOT, not as a Regular User
-    conformance/interfaces/clock_settime/8-1: execution: UNTESTED: Output: 
-    Run this test as ROOT, not as a Regular User
-    conformance/interfaces/clock_settime/speculative/4-3: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/clock_settime/speculative/4-4: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/fork/1-1: execution: UNRESOLVED: Output: 
-    [02:46:23]Test conformance/interfaces/fork/1-1.c unresolved: got 1073741869 (Operation not supported) on line 115 (Failed to open the semaphore)
-    [02:46:23]Test conformance/interfaces/fork/1-1.c unresolved: got 1073741869 (Operation not supported) on line 115 (Failed to open the semaphore)
-    conformance/interfaces/fork/11-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/fork/12-1: execution: FAILED: Output: 
-    [09:57:13]SIGUSR1 and SIGUSR2 are pending, we can fork
-    [09:57:13]SIGUSR1 and SIGUSR2 are blocked in child
-    [09:57:13]Test conformance/interfaces/fork/12-1.c FAILED: The new process was created with SIGUSR1 pending
-    [09:57:13]SIGUSR1 and SIGUSR2 are pending, we can fork
-    [09:57:13]Test conformance/interfaces/fork/12-1.c FAILED: Child exited abnormally
-    conformance/interfaces/fork/13-1: execution: UNRESOLVED: Output: 
-    [09:57:14]Test conformance/interfaces/fork/13-1.c unresolved: got 1073741902 (Function not implemented) on line 117 (Failed to set interval timer for ITIMER_VIRTUAL)
-    conformance/interfaces/fork/14-1: execution: UNRESOLVED: Output: 
-    [09:57:14]Test conformance/interfaces/fork/14-1.c unresolved: got 1073741869 (Operation not supported) on line 100 (Failed to create the named semaphore)
-    conformance/interfaces/fork/17-1: execution: UNRESOLVED: Output: 
-    [09:57:15]Test conformance/interfaces/fork/17-1.c unresolved: got 1073741902 (Function not implemented) on line 103 (Failed to get max priority value)
-    conformance/interfaces/fork/17-2: execution: UNRESOLVED: Output: 
-    [09:57:15]Test conformance/interfaces/fork/17-2.c unresolved: got 1073741902 (Function not implemented) on line 103 (Failed to get max priority value)
-    conformance/interfaces/fork/18-1: execution: UNRESOLVED: Output: 
-    [09:57:16]Test conformance/interfaces/fork/18-1.c unresolved: got 1073741902 (Function not implemented) on line 128 (Failed to create a timer)
-    conformance/interfaces/fork/19-1: execution: UNRESOLVED: Output: 
-    [09:57:16]Test conformance/interfaces/fork/19-1.c unresolved: got 1073741902 (Function not implemented) on line 114 (Failed to create the message queue descriptor)
-    conformance/interfaces/fork/21-1: execution: UNRESOLVED: Output: 
-    [09:57:17]Test conformance/interfaces/fork/21-1.c unresolved: got 1073741869 (Operation not supported) on line 128 (Failed to open the semaphore)
-    conformance/interfaces/fork/22-1: execution: UNTESTED: Output: 
-    [09:57:17]File conformance/interfaces/fork/22-1.c cannot test: The testcase needs CPUTIME or THREAD_CPUTIME support
-    conformance/interfaces/fork/8-1: execution: FAILED: Output: 
-    [09:57:20]Test conformance/interfaces/fork/8-1.c FAILED: The process is created with non-zero tms_cutime or tms_cstime
-    conformance/interfaces/fsync/7-1: execution: FAILED: Output: 
-    fsync/7-1.c Test Fail: Expect EINVAL, get: (ipc/mig) bad request message ID
-    conformance/interfaces/lio_listio/12-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/lio_listio/13-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/lio_listio/18-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/lio_listio/5-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/lio_listio/6-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/lio_listio/8-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/lio_listio/9-1: execution: UNSUPPORTED: Output: 
-    conformance/interfaces/mlock/10-1: execution: UNRESOLVED: Output: 
-    You don't have permission to lock your address space.
-    Try to rerun this test as root.
-    conformance/interfaces/mlock/5-1: execution: UNRESOLVED: Output: 
-    You don't have permission to lock your address space.
-    Try to rerun this test as root.
-    conformance/interfaces/mlock/8-1: execution: UNRESOLVED: Output: 
-    You don't have permission to lock your address space.
-    Try to rerun this test as root.
-    conformance/interfaces/mlockall/13-1: execution: FAILED: Output: 
-    Unexpected error: Function not implemented
-    conformance/interfaces/mlockall/13-2: execution: FAILED: Output: 
-    Unexpected error: Function not implemented
-    conformance/interfaces/mlockall/3-6: execution: UNRESOLVED: Output: 
-    An error occurs when calling mlockall(): Function not implemented
-    conformance/interfaces/mlockall/3-7: execution: UNRESOLVED: Output: 
-    An error occurs when calling mlockall(): Function not implemented
-    conformance/interfaces/mlockall/8-1: execution: UNRESOLVED: Output: 
-    Unexpected error: Function not implemented
-    conformance/interfaces/mlockall/speculative/15-1: execution: UNRESOLVED: Output: 
-    Unexpected error: Function not implemented
-    conformance/interfaces/mmap/11-4: execution: FAILED: Output: 
-    pa: 0x28000
-    pa_2: 0x29000
-    Test Fail: mmap/11-4.c Modification of the partial page at the end of an object is written out
-    conformance/interfaces/mmap/11-5: execution: FAILED: Output: 
-    Test Fail: mmap/11-5.c Modification of the partial page at the end of an object is written out
-    conformance/interfaces/mmap/13-1: execution: FAILED: Output: 
-    Time before write(): 1248767904
-    Time before mmap(): 1248767905
-    Time before munmap(): 1248767906
-    atime1: 1248767904, atime2: 1248767904, atime3: 1248767904
-    Test Fail mmap/13-1.c st_atime did not update properly
-    conformance/interfaces/mmap/14-1: execution: FAILED: Output: 
-    Time before write(): 1248767907
-    Time before mmap(): 1248767908
-    Time before write reference: 1248767909
-    Time before msync(): 1248767910
-    ctime1: 1248767909, ctime2: 1248767909
-    mtime1: 1248767909, mtime2: 1248767909
-    Test Fail mmap/14-1.c st_ctime and st_mtime were not updated properly
-    conformance/interfaces/mmap/18-1: execution: UNRESOLVED: Output: 
-    mmap/18-1.c Error at mlockall(): Function not implemented
-    conformance/interfaces/mmap/21-1: execution: FAILED: Output: 
-    Test FAIL
-
-Kernel panic [[!tag open_issue_gnumach]] (at conformance/interfaces/mmap/24-1):
-
-    Assertion `(object == VM_OBJECT_NULL) || (object->ref_count > 0) || ((object->paging_in_progress != 0) && internal)' failed in file "../gnumach-1-branch-Xen-branch/vm/vm_object.c", line 2087
-    Kernel Breakpoint trap, eip 0x20020a77
-    Stopped at  0x20020a76: int     $3
-    db> trace
-    0x20020a76(2006abc1,20067354,2006708c,827,2e4e5514)
-    0x20020ace(20067354,2006708c,827,2001c900,2e3b54f4)
-    0x20035ef2(2e4e5514,1000,0,200194c0,2e3b54f4)
-    0x2003929f(2e3b4d64,2fc6ff9c,400,0,1)
-    0x200577ea(1,15ff998,400,0,1)
-    0x20006838(1,15ff998,400,0,1)
-    >>>>> user space <<<<<
-
-    $ addr2line -i -f -e /boot/gnumach-xen 0x20020a76 0x20020ace 0x20035ef2 0x2003929f 0x200577ea 0x20006838
-    Debugger
-    /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/debug.c:105
-    Assert
-    ??:0
-    vm_object_enter
-    /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/vm/vm_object.c:2109
-    vm_map
-    /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/vm/vm_user.c:326
-    syscall_vm_map
-    /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/ipc_mig.c:657
-    mach_call_call
-    /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/i386/i386/locore.S:1083
-
-Disable the panic-causing test (conformance/interfaces/mmap/24-1) and restart:
-
-    [...]
-    conformance/interfaces/mmap/24-2: execution: INTERRUPTED: Output: 
-    conformance/interfaces/mmap/27-1: execution: UNTESTED: Output: 
-    Test Untested: MAP_FIXED defined
-    conformance/interfaces/mmap/28-1: execution: FAILED: Output: 
-    Test Fail: mmap/28-1.c Got no error at mmap()
-    conformance/interfaces/mmap/31-1: execution: FAILED: Output: 
-    Test FAIL: expect EOVERFLOW but get other error: Cannot allocate memory
-    off: fffff000, len: fffff000
-    conformance/interfaces/mmap/6-4: execution: FAILED: Output: 
-    Test Fail: Did not get EACCES as expected
-    conformance/interfaces/mmap/6-6: execution: FAILED: Output: 
-    Test Fail: Did not get EACCES as expected
-    conformance/interfaces/mmap/7-1: execution: UNRESOLVED: Output: 
-    mmap/7-1.c Error at msync(): Error in unknown error system: FFFFFFFF
-    conformance/interfaces/mmap/7-2: execution: UNRESOLVED: Output: 
-    mmap/7-2.c Error at msync(): Error in unknown error system: FFFFFFFF
-    conformance/interfaces/mq_close/1-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_close/2-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_close 2-1: mq_open: Function not implemented
-    unexpected error: mq_close 2-1: read: EOF
-    conformance/interfaces/mq_close/3-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_close 3-1: mq_open: Function not implemented
-    conformance/interfaces/mq_close/3-2: execution: FAILED: Output: 
-    errno != EBADF on invalid descriptor
-    Test FAILED
-    conformance/interfaces/mq_close/3-3: execution: FAILED: Output: 
-    errno != EBADF on invalid descriptor
-    Test FAILED
-    conformance/interfaces/mq_close/4-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_close 4-1: mq_open: Function not implemented
-    conformance/interfaces/mq_close/5-1: execution: UNTESTED: Output: 
-    Functionality of using mqdes after mq_close() and before
-    mq_open() will not be tested as POSIX says this is undefined.
-    conformance/interfaces/mq_getattr/2-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_getattr 2-1: mq_open(): Function not implemented
-    conformance/interfaces/mq_getattr/2-2: execution: UNRESOLVED: Output: 
-    unexpected error: mq_getattr 2-2: mq_open(): Function not implemented
-    conformance/interfaces/mq_getattr/3-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_getattr 3-1: mq_open(): Function not implemented
-    conformance/interfaces/mq_getattr/4-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_getattr 4-1: mq_open(): Function not implemented
-    conformance/interfaces/mq_getattr/speculative/7-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_getattr 7-1: mq_open(): Function not implemented
-    conformance/interfaces/mq_notify/1-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_notify 1-1: mq_open: Function not implemented
-    conformance/interfaces/mq_notify/2-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_notify 2-1: mq_open: Function not implemented
-    conformance/interfaces/mq_notify/3-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_notify 3-1: mq_open: Function not implemented
-    conformance/interfaces/mq_notify/4-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_notify 4-1: mq_open: Function not implemented
-    conformance/interfaces/mq_notify/5-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_notify 5-1: mq_open: Function not implemented
-    conformance/interfaces/mq_notify/8-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_notify 8-1: mq_open(): Function not implemented
-    conformance/interfaces/mq_notify/9-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_notify 9-1: mq_open: Function not implemented
-    conformance/interfaces/mq_open/1-1: execution: FAILED: Output: 
-    mq_open() did not return success: Function not implemented
-    Test FAILED
-    conformance/interfaces/mq_open/10-1: execution: UNTESTED: Output: 
-    Will not test the user ID and group ID of a created
-    message queue as we would need multiple users and
-    groups on the system to test.
-    Will not test the file permissions as testing would
-    be implementation defined.
-    conformance/interfaces/mq_open/11-1: execution: FAILED: Output: 
-    mq_open() did not return success: Function not implemented
-    Test FAILED
-    conformance/interfaces/mq_open/12-1: execution: FAILED: Output: 
-    mq_open() did not return success: Function not implemented
-    Test FAILED
-    conformance/interfaces/mq_open/13-1: execution: FAILED: Output: 
-    mq_open() did not return success: Function not implemented
-    Test FAILED
-    conformance/interfaces/mq_open/14-1: execution: UNTESTED: Output: 
-    Will not test calling process privileges on name
-    as POSIX does not define when this error occurs.
-    conformance/interfaces/mq_open/15-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    Test UNRESOLVED
-    conformance/interfaces/mq_open/16-1: execution: FAILED: Output: 
-    Test FAILED - mq_open() never succeeded
-    conformance/interfaces/mq_open/17-1: execution: UNTESTED: Output: 
-    Will not test setting O_EXCL without O_CREAT because
-    results are undefined.
-    conformance/interfaces/mq_open/18-1: execution: FAILED: Output: 
-    mq_open() did not return success w/O_NONBLOCK set: Function not implemented
-    Test FAILED
-    conformance/interfaces/mq_open/19-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    Test UNRESOLVED
-    conformance/interfaces/mq_open/2-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    Test UNRESOLVED
-    conformance/interfaces/mq_open/20-1: execution: FAILED: Output: 
-    mq_open() did not return success: Function not implemented
-    Test FAILED
-    conformance/interfaces/mq_open/22-1: execution: UNTESTED: Output: 
-    Will not test returning EACCESS when privileges are denied
-    as POSIX does not define when this error occurs.
-    conformance/interfaces/mq_open/23-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    Test UNRESOLVED
-    conformance/interfaces/mq_open/24-1: execution: UNTESTED: Output: 
-    Will not test mq_open() being interrupted as it is
-    not possible to predictably interrupt an mq_open().
-    conformance/interfaces/mq_open/25-1: execution: UNTESTED: Output: 
-    Will not test mq_open() failing with EINVAL if mq_open()
-    is not supported for the name parameter as
-    unsupported names are implementation defined.
-    conformance/interfaces/mq_open/25-2: execution: FAILED: Output: 
-    errno != EINVAL for mq_maxmsg 0
-    errno != EINVAL for mq_maxmsg -1
-    errno != EINVAL for mq_maxmsg -2147483648
-    errno != EINVAL for mq_msgsize 0
-    errno != EINVAL for mq_msgsize -1
-    errno != EINVAL for mq_msgsize -2147483648
-    Test FAILED
-    conformance/interfaces/mq_open/27-2: execution: FAILED: Output: 
-    errno != ENAMETOOLONG
-    Test FAILED
-    conformance/interfaces/mq_open/28-1: execution: UNTESTED: Output: 
-    Will not test returning with ENFILE if the system has
-    too many message queues as this is beyond this
-    test's domain.
-    conformance/interfaces/mq_open/29-1: execution: FAILED: Output: 
-    errno != ENOENT
-    Test FAILED
-    conformance/interfaces/mq_open/30-1: execution: UNTESTED: Output: 
-    Will not test mq_open() failing with ENOSPC when there
-    is not enough space to create the message queue
-    as system space cannot be controlled from this test.
-    conformance/interfaces/mq_open/4-1: execution: UNTESTED: Output: 
-    Will not test that {OPEN_MAX} file and message queues can
-    be opened as we cannot determine at run-time if a given
-    implementation is implemented with a file descriptor.
-    conformance/interfaces/mq_open/7-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    Test UNRESOLVED
-    conformance/interfaces/mq_open/7-2: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    Test UNRESOLVED
-    conformance/interfaces/mq_open/7-3: execution: FAILED: Output: 
-    mq_open() for read-only queue did not return success: Function not implemented
-    Test FAILED
-    conformance/interfaces/mq_open/8-1: execution: UNRESOLVED: Output: 
-    mq_open() for write-only queue did not return success: Function not implemented
-    Test UNRESOLVED
-    conformance/interfaces/mq_open/8-2: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    Test UNRESOLVED
-    conformance/interfaces/mq_open/9-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success on read-write queue: Function not implemented
-    Test UNRESOLVED
-    conformance/interfaces/mq_open/9-2: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    Test UNRESOLVED
-    conformance/interfaces/mq_open/speculative/26-1: execution: FAILED: Output: 
-    mq_open() failed before expected
-    errno != EMFILE on > _POSIX_OPEN_MAX  or _POSIX_MQ_OPEN_MAX queues
-    Test FAILED
-    conformance/interfaces/mq_receive/1-1: execution: FAILED: Output: 
-    unexpected error: mq_receive 1-1: mq_open: Function not implemented
-    unexpected error: mq_receive 1-1: mq_send: Function not implemented
-    unexpected error: mq_receive 1-1: mq_send: Function not implemented
-    unexpected error: mq_receive 1-1: mq_receive: Function not implemented
-    unexpected error: mq_receive 1-1: mq_receive: Function not implemented
-    unexpected error: mq_receive 1-1: mq_close: Function not implemented
-    unexpected error: mq_receive 1-1: mq_unlink: Function not implemented
-    FAIL: mq_receive didn't receive the highest priority message
-    FAIL: receive priority 134520252 != send priority 2 
-    FAIL: mq_receive didn't receive the correct message
-    FAIL: receive priority 134520252 != send priority 1 
-    Test FAILED
-    conformance/interfaces/mq_receive/10-1: execution: FAILED: Output: 
-    unexpected error: mq_receive 10-1: mq_open: Function not implemented
-    unexpected error: mq_receive 10-1: mq_close: Function not implemented
-    unexpected error: mq_receive 10-1: mq_unlink: Function not implemented
-    errno != EAGAIN 
-    Test FAILED
-    conformance/interfaces/mq_receive/11-1: execution: FAILED: Output: 
-    unexpected error: mq_receive 11-1: mq_open(): Function not implemented
-    unexpected error: mq_receive 11-1: mq_close(): Function not implemented
-    unexpected error: mq_receive 11-1: mq_unlink(): Function not implemented
-    errno != EBADF 
-    Test FAILED
-    conformance/interfaces/mq_receive/11-2: execution: FAILED: Output: 
-    unexpected error: mq_receive 11-2: mq_open(): Function not implemented
-    unexpected error: mq_receive 11-2: mq_close: Function not implemented
-    unexpected error: mq_receive 11-2: mq_unlink(): Function not implemented
-    errno != EBADF 
-    Test FAILED
-    conformance/interfaces/mq_receive/12-1: execution: FAILED: Output: 
-    unexpected error: mq_receive 12-1: mq_open: Function not implemented
-    unexpected error: mq_receive 12-1: mq_send: Function not implemented
-    unexpected error: mq_receive 12-1: mq_close: Function not implemented
-    unexpected error: mq_receive 12-1: mq_unlink: Function not implemented
-    errno != EMSGSIZE 
-    Test FAILED
-    conformance/interfaces/mq_receive/13-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_receive 13-1: mq_open: Function not implemented
-    mq_close() did not return success: Function not implemented
-    mq_unlink() did not return success: Function not implemented
-    Test UNRESOLVED
-    conformance/interfaces/mq_receive/2-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_receive 2-1: mq_open: Function not implemented
-    unexpected error: mq_receive 2-1: mq_send: Function not implemented
-    unexpected error: mq_receive 2-1: mq_close: Function not implemented
-    unexpected error: mq_receive 2-1: mq_unlink: Function not implemented
-    Test UNRESOLVED
-    conformance/interfaces/mq_receive/5-1: execution: FAILED: Output: 
-    unexpected error: mq_receive 5-1: mq_open: Function not implemented
-    unexpected error: mq_receive 5-1: mq_send: Function not implemented
-    unexpected error: mq_receive 5-1: mq_receive: Function not implemented
-    unexpected error: mq_receive 5-1: mq_close: Function not implemented
-    unexpected error: mq_receive 5-1: mq_unlink: Function not implemented
-    Test FAILED
-    conformance/interfaces/mq_receive/7-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_receive 7-1: mq_open: Function not implemented
-    unexpected error: mq_receive 7-1: mq_close: Function not implemented
-    unexpected error: mq_receive 7-1: mq_unlink: Function not implemented
-    Test UNRESOLVED
-    conformance/interfaces/mq_receive/8-1: execution: FAILED: Output: 
-    unexpected error: mq_receive 8-1: mq_open: Function not implemented
-    unexpected error: mq_receive 8-1: mq_send: Function not implemented
-    unexpected error: mq_receive 8-1: mq_send: Function not implemented
-    unexpected error: mq_receive 8-1: mq_close: Function not implemented
-    unexpected error: mq_receive 8-1: mq_unlink: Function not implemented
-    FAIL: mq_receive didn't return the selected message size correctly 
-    FAIL: mq_receive didn't return the selected message size correctly 
-    Test FAILED
-    conformance/interfaces/mq_send/1-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_send/10-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_send/11-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_send/11-2: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_send/12-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_send/14-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_send/2-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_send/3-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_send/3-2: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_send/5-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_send/5-2: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_send/6-1: execution: UNTESTED: Output: 
-    Priority Scheduling needed to make a reliable test case
-    for this instance.  Will not be tested.
-    conformance/interfaces/mq_send/8-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_send/9-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_setattr/1-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_setattr/1-2: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_setattr/2-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_setattr/5-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_setattr 5-1: mq_open(): Function not implemented
-    conformance/interfaces/mq_timedreceive/1-1: execution: FAILED: Output: 
-    unexpected error: mq_timedreceive 1-1: mq_open: Function not implemented
-    unexpected error: mq_timedreceive 1-1: mq_send: Function not implemented
-    unexpected error: mq_timedreceive 1-1: mq_send: Function not implemented
-    unexpected error: mq_timedreceive 1-1: mq_timedreceive: Function not implemented
-    unexpected error: mq_timedreceive 1-1: mq_timedreceive: Function not implemented
-    unexpected error: mq_timedreceive 1-1: mq_close: Function not implemented
-    unexpected error: mq_timedreceive 1-1: mq_unlink: Function not implemented
-    FAIL: mq_timedreceive didn't receive the highest priority message
-    FAIL: receive priority 134520424 != send priority 2 
-    FAIL: mq_timedreceive didn't receive the correct message
-    FAIL: receive priority 134520424 != send priority 1 
-    Test FAILED
-    conformance/interfaces/mq_timedreceive/10-1: execution: FAILED: Output: 
-    unexpected error: mq_timedreceive 10-1: mq_open: Function not implemented
-    unexpected error: mq_timedreceive 10-1: mq_send: Function not implemented
-    FAIL: mq_receive fails unexpectly 
-    : Function not implemented
-    unexpected error: mq_timedreceive 10-1: mq_close: Function not implemented
-    unexpected error: mq_timedreceive 10-1: mq_unlink: Function not implemented
-    Test FAILED
-    conformance/interfaces/mq_timedreceive/10-2: execution: FAILED: Output: 
-    unexpected error: mq_timedreceive 10-1: mq_open: Function not implemented
-    unexpected error: mq_timedreceive 10-1: mq_send: Function not implemented
-    Unexpected error at mq_timedreceive: Function not implemented
-    unexpected error: mq_timedreceive 10-1: mq_close: Function not implemented
-    unexpected error: mq_timedreceive 10-1: mq_unlink: Function not implemented
-    Test FAILED
-    conformance/interfaces/mq_timedreceive/11-1: execution: FAILED: Output: 
-    unexpected error: mq_timedreceive 11-1: mq_open: Function not implemented
-    unexpected error: mq_timedreceive 11-1: mq_send: Function not implemented
-    unexpected error: mq_timedreceive 11-1: mq_send: Function not implemented
-    unexpected error: mq_timedreceive 11-1: mq_close: Function not implemented
-    unexpected error: mq_timedreceive 11-1: mq_unlink: Function not implemented
-    FAIL: mq_timedreceive didn't return the selected message size correctly 
-    FAIL: mq_timedreceive didn't return the selected message size correctly 
-    Test FAILED
-    conformance/interfaces/mq_timedreceive/13-1: execution: FAILED: Output: 
-    unexpected error: mq_timedreceive 13-1: mq_open: Function not implemented
-    unexpected error: mq_timedreceive 13-1: mq_close: Function not implemented
-    unexpected error: mq_timedreceive 13-1: mq_unlink: Function not implemented
-    errno != EAGAIN 
-    Test FAILED
-    conformance/interfaces/mq_timedreceive/14-1: execution: FAILED: Output: 
-    unexpected error: mq_timedreceive 14-1: mq_open(): Function not implemented
-    unexpected error: mq_timedreceive 14-1: mq_close(): Function not implemented
-    unexpected error: mq_timedreceive 14-1: mq_unlink(): Function not implemented
-    errno != EBADF 
-    Test FAILED
-    conformance/interfaces/mq_timedreceive/15-1: execution: FAILED: Output: 
-    unexpected error: mq_timedreceive 15-1: mq_open: Function not implemented
-    unexpected error: mq_timedreceive 15-1: mq_send: Function not implemented
-    unexpected error: mq_timedreceive 15-1: mq_close: Function not implemented
-    unexpected error: mq_timedreceive 15-1: mq_unlink: Function not implemented
-    errno != EMSGSIZE 
-    Test FAILED
-    conformance/interfaces/mq_timedreceive/17-1: execution: FAILED: Output: 
-    unexpected error: mq_timedreceive 17-1: mq_open: Function not implemented
-    unexpected error: mq_timedreceive 17-1: mq_close: Function not implemented
-    unexpected error: mq_timedreceive 17-1: mq_unlink: Function not implemented
-    errno != EINVAL 
-    Test FAILED
-    conformance/interfaces/mq_timedreceive/17-2: execution: FAILED: Output: 
-    unexpected error: mq_timedreceive 17-2: mq_open: Function not implemented
-    unexpected error: mq_timedreceive 17-2: mq_close: Function not implemented
-    unexpected error: mq_timedreceive 17-2: mq_unlink: Function not implemented
-    errno != EINVAL 
-    Test FAILED
-    conformance/interfaces/mq_timedreceive/17-3: execution: FAILED: Output: 
-    unexpected error: mq_timedreceive 17-3: mq_open: Function not implemented
-    unexpected error: mq_timedreceive 17-3: mq_close: Function not implemented
-    unexpected error: mq_timedreceive 17-3: mq_unlink: Function not implemented
-    errno != EINVAL 
-    Test FAILED
-    conformance/interfaces/mq_timedreceive/18-1: execution: FAILED: Output: 
-    unexpected error: mq_timedreceive 18-1: mq_open: Function not implemented
-    unexpected error: mq_timedreceive 18-1: mq_close: Function not implemented
-    unexpected error: mq_timedreceive 18-1: mq_unlink: Function not implemented
-    errno != ETIMEDOUT 
-    Test FAILED
-    conformance/interfaces/mq_timedreceive/18-2: execution: FAILED: Output: 
-    unexpected error: mq_timedreceive 18-2: mq_open: Function not implemented
-    unexpected error: mq_timedreceive 18-2: mq_close: Function not implemented
-    unexpected error: mq_timedreceive 18-2: mq_unlink: Function not implemented
-    errno != ETIMEDOUT
-    Test FAILED
-    conformance/interfaces/mq_timedreceive/2-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_timedreceive 2-1: mq_open: Function not implemented
-    unexpected error: mq_timedreceive 2-1: mq_send: Function not implemented
-    unexpected error: mq_timedreceive 2-1: mq_close: Function not implemented
-    unexpected error: mq_timedreceive 2-1: mq_unlink: Function not implemented
-    Test UNRESOLVED
-    conformance/interfaces/mq_timedreceive/5-1: execution: FAILED: Output: 
-    unexpected error: mq_timedreceive 5-1: mq_open: Function not implemented
-    unexpected error: mq_timedreceive 5-1: mq_send: Function not implemented
-    unexpected error: mq_timedreceive 5-1: mq_timedreceive: Function not implemented
-    unexpected error: mq_timedreceive 5-1: mq_close: Function not implemented
-    unexpected error: mq_timedreceive 5-1: mq_unlink: Function not implemented
-    mq_timedreceive didn't block on waiting 
-    Test FAILED
-    conformance/interfaces/mq_timedreceive/5-2: execution: FAILED: Output: 
-    unexpected error: mq_timedreceive 5-2: mq_open: Function not implemented
-    unexpected error: mq_timedreceive 5-2: mq_close: Function not implemented
-    unexpected error: mq_timedreceive 5-2: mq_unlink: Function not implemented
-    FAIL: mq_timedreceive didn't block until timout expires
-    Test FAILED
-    conformance/interfaces/mq_timedreceive/5-3: execution: UNRESOLVED: Output: 
-    unexpected error: mq_timedreceive 5-3: mq_open: Function not implemented
-    mq_close() did not return success: Function not implemented
-    mq_unlink() did not return success: Function not implemented
-    Test UNRESOLVED
-    conformance/interfaces/mq_timedreceive/7-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_timedreceive 7-1: mq_open: Function not implemented
-    unexpected error: mq_timedreceive 7-1: mq_close: Function not implemented
-    unexpected error: mq_timedreceive 7-1: mq_unlink: Function not implemented
-    Test UNRESOLVED
-    conformance/interfaces/mq_timedreceive/8-1: execution: FAILED: Output: 
-    unexpected error: mq_timedreceive 8-1: mq_open: Function not implemented
-    unexpected error: mq_timedreceive 8-1: mq_close: Function not implemented
-    unexpected error: mq_timedreceive 8-1: mq_unlink: Function not implemented
-    Using CLOCK_REALTIME
-    FAIL: mq_timedreceive didn't block until timout expires
-    Test FAILED
-    conformance/interfaces/mq_timedreceive/speculative/10-2: execution: UNRESOLVED: Output: 
-    unexpected error: mq_timedreceive 10-2: mq_open: Function not implemented
-    unexpected error: mq_timedreceive 10-2: mq_send: Function not implemented
-    unexpected error: mq_timedreceive 10-2: mq_close: Function not implemented
-    unexpected error: mq_timedreceive 10-2: mq_unlink: Function not implemented
-    mq_timedreceive() did fail on invalid abs_time
-    Test UNRESOLVED
-    conformance/interfaces/mq_timedsend/1-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_timedsend/10-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_timedsend/11-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_timedsend/11-2: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_timedsend/12-1: execution: INTERRUPTED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_timedsend/14-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_timedsend/15-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    Test UNRESOLVED
-    conformance/interfaces/mq_timedsend/16-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_timedsend/17-1: execution: UNTESTED: Output: 
-    Will not test timeout resolution.
-    conformance/interfaces/mq_timedsend/18-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    Test UNRESOLVED
-    conformance/interfaces/mq_timedsend/19-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    Test UNRESOLVED
-    conformance/interfaces/mq_timedsend/2-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_timedsend/20-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    Test UNRESOLVED
-    conformance/interfaces/mq_timedsend/3-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_timedsend/3-2: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_timedsend/5-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_timedsend/5-2: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_timedsend/5-3: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_timedsend/6-1: execution: UNTESTED: Output: 
-    Priority Scheduling needed to make a reliable test case
-    for this instance.  Will not be tested.
-    conformance/interfaces/mq_timedsend/7-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_timedsend/8-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_timedsend/9-1: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    conformance/interfaces/mq_timedsend/speculative/18-2: execution: UNRESOLVED: Output: 
-    mq_open() did not return success: Function not implemented
-    Test UNRESOLVED
-    conformance/interfaces/mq_unlink/1-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_unlink 1-1: mq_open: Function not implemented
-    conformance/interfaces/mq_unlink/2-1: execution: UNRESOLVED: Output: 
-    unexpected error: mq_unlink 2-1: mq_open: Function not implemented
-    unexpected error: mq_unlink 2-1: read: EOF 
-    conformance/interfaces/mq_unlink/2-2: execution: UNRESOLVED: Output: 
-    unexpected error: mq_unlink 2-2: mq_open: Function not implemented
-    unexpected error: mq_unlink 2-2: read: EOF
-    conformance/interfaces/mq_unlink/2-3: execution: UNTESTED: Output: 
-    Difficult to detect whether mq_unlink will block until all the reference have been closed
-    for this instance.  Will not be tested.
-    conformance/interfaces/mq_unlink/7-1: execution: FAILED: Output: 
-    Test FAILED
-    conformance/interfaces/mq_unlink/speculative/7-2: execution: FAILED: Output: 
-    Test FAILED, error is Function not implemented
-    conformance/interfaces/munlock/10-1: execution: UNRESOLVED: Output: 
-    Unexpected error: Operation not permitted
-    conformance/interfaces/munlock/11-1: execution: UNRESOLVED: Output: 
-    Unexpected error: Operation not permitted
-    conformance/interfaces/munlock/7-1: execution: UNRESOLVED: Output: 
-    You don't have permission to lock your address space.
-    Try to rerun this test as root.
-    conformance/interfaces/munmap/3-1: execution: FAILED: Output: 
-    Test FAILED: munmap/3-1.c munmap returns: No such file or directory
-    conformance/interfaces/munmap/4-1: execution: UNRESOLVED: Output: 
-    munmap/4-1.c Error at msync(): Error in unknown error system: FFFFFFFF
-    conformance/interfaces/munmap/8-1: execution: FAILED: Output: 
-    Test FAILED: Expect EINVAL but get: (os/kern) successful
-    conformance/interfaces/munmap/9-1: execution: FAILED: Output: 
-    Test Fail: Expect EINVAL while get No such file or directory
-    conformance/interfaces/nanosleep/10000-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/nanosleep/5-1: execution: FAILED: Output: 
-    nanosleep() did not return -1 on failure
-    conformance/interfaces/nanosleep/5-2: execution: FAILED: Output: 
-    In handler
-    Child did not exit normally.
-    Test FAILED
-    conformance/interfaces/nanosleep/6-1: execution: UNRESOLVED: Output: 
-    sleep -1
-    nanosleep() did not return -1 on failure
-    conformance/interfaces/nanosleep/7-1: execution: FAILED: Output: 
-    In handler
-    nanosleep did not return -1
-    Child did not exit normally.
-    Test FAILED
-    conformance/interfaces/nanosleep/7-2: execution: FAILED: Output: 
-    In handler
-    nanosleep() was not interrupted
-    Child did not exit normally.
-    Test FAILED
-    conformance/interfaces/pthread_atfork/1-1: execution: UNRESOLVED: Output: 
-    Error in pthread_atfork
-    conformance/interfaces/pthread_atfork/1-2: execution: UNRESOLVED: Output: 
-    [11:58:02]Test conformance/interfaces/pthread_atfork/1-2.c unresolved: got 1073741902 (Function not implemented) on line 216 (Failed to register the atfork handlers)
-    conformance/interfaces/pthread_atfork/2-1: execution: FAILED: Output: 
-    Test FAILED: Expected return value success, instead received 1073741902
-    conformance/interfaces/pthread_atfork/2-2: execution: UNRESOLVED: Output: 
-    [11:58:03]Test conformance/interfaces/pthread_atfork/2-2.c unresolved: got 1073741902 (Function not implemented) on line 244 (Failed to register the atfork handlers(N,N,N))
-    conformance/interfaces/pthread_atfork/3-2: execution: UNRESOLVED: Output: 
-    [11:58:03]Test conformance/interfaces/pthread_atfork/3-2.c unresolved: got 1073741902 (Function not implemented) on line 213 (Failed to register the atfork handlers)
-    conformance/interfaces/pthread_atfork/3-3: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_atfork/4-1: execution: UNRESOLVED: Output: 
-    [12:10:53]Test conformance/interfaces/pthread_atfork/4-1.c unresolved: got 1073741902 (Function not implemented) on line 244 (Failed to register the atfork handlers)
-    conformance/interfaces/pthread_attr_getschedparam/1-1: execution: UNRESOLVED: Output: 
-    unexpected error: pthread_attr_getschedparam 1-1: pthread_attr_setschedpolicy
-    conformance/interfaces/pthread_attr_getschedpolicy/2-1: execution: UNRESOLVED: Output: 
-    unexpected error: pthread_attr_getschedpolicy 1-1: pthread_attr_setschedpolicy
-    conformance/interfaces/pthread_attr_setinheritsched/2-1: execution: UNRESOLVED: Output: 
-    unexpected error: pthread_attr_setinheritsched 2-1: pthread_attr_setschedpolicy: (os/kern) successful
-    conformance/interfaces/pthread_attr_setinheritsched/2-2: execution: UNRESOLVED: Output: 
-    unexpected error: pthread_attr_setinheritsched 2-2: pthread_attr_setschedpolicyconformance/interfaces/pthread_attr_setinheritsched/2-3: execution: UNRESOLVED: Output: 
-    unexpected error: scheduler 4-1: pthread_setschedparam
-    conformance/interfaces/pthread_attr_setinheritsched/2-4: execution: UNRESOLVED: Output: 
-    unexpected error: scheduler 4-2: pthread_setschedparam
-    conformance/interfaces/pthread_attr_setschedparam/1-1: execution: FAILED: Output: 
-    unexpected error: pthread_attr_setschedparam 1-1: pthread_attr_setschedpolicy
-    conformance/interfaces/pthread_attr_setschedparam/1-2: execution: FAILED: Output: 
-    unexpected error: pthread_attr_setschedparam 1-2: pthread_attr_setschedpolicy
-    conformance/interfaces/pthread_attr_setschedparam/1-3: execution: UNRESOLVED: Output: 
-    unexpected error: scheduler 3-1: pthread_attr_setschedpolicy
-    conformance/interfaces/pthread_attr_setschedparam/1-4: execution: UNRESOLVED: Output: 
-    unexpected error: scheduler 3-2: pthread_attr_setschedpolicy
-    conformance/interfaces/pthread_attr_setschedparam/speculative/3-1: execution: FAILED: Output: 
-    unexpected error: pthread_attr_setschedparam 3-1: pthread_attr_setschedpolicy
-    conformance/interfaces/pthread_attr_setschedparam/speculative/3-2: execution: FAILED: Output: 
-    unexpected error: pthread_attr_setschedpaarm 3-2: pthread_attr_setschedpolicyconformance/interfaces/pthread_attr_setschedpolicy/1-1: execution: FAILED: Output: 
-    Error on pthread_attr_setschedpolicy()	 rc=1073741942
-    conformance/interfaces/pthread_attr_setschedpolicy/speculative/5-1: execution: UNRESOLVED: Output: 
-    unexpected error: pthread_attr_setschedpolicy 5-1: pthread_attr_setinheritsched
-    conformance/interfaces/pthread_attr_setscope/5-1: execution: UNTESTED: Output: 
-    Untested for now, cannot find a unsupported inheritsched value
-    conformance/interfaces/pthread_barrierattr_getpshared/2-1: execution: UNRESOLVED: Output: 
-    Error at pthread_barrierattr_setpshared()
-    conformance/interfaces/pthread_barrierattr_setpshared/1-1: execution: FAILED: Output: 
-    Test FAILED: Error at pthread_barrierattr_setpshared()
-    conformance/interfaces/pthread_cancel/3-1: execution: UNRESOLVED: Output: 
-    unexpected error: pthread_cancel 3-1: pthread_setschedparam
-    conformance/interfaces/pthread_cancel/5-2: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_cond_broadcast/1-2: execution: UNRESOLVED: Output: 
-    [12:42:33]Test starting
-    [12:42:33]System abilities:
-    [12:42:33] TPS : -1
-    [12:42:33] CS  : 200112
-    [12:42:33] MON : -1
-    [12:42:33] MF  : 200112
-    [12:42:33]Process-shared attributes won't be tested
-    [12:42:33]Alternative clock won't be tested
-    [12:42:33]Test conformance/interfaces/pthread_cond_broadcast/1-2.c unresolved: got 1073741846 (Invalid argument) on line 393 ([parent] Failed to set thread stack size)
-    conformance/interfaces/pthread_cond_broadcast/2-3: execution: UNRESOLVED: Output: 
-    [12:42:36]Test starting
-    [12:42:36]System abilities:
-    [12:42:36] TPS : -1
-    [12:42:36] CS  : 200112
-    [12:42:36] MON : -1
-    [12:42:36] MF  : 200112
-    [12:42:36]Process-shared attributes won't be tested
-    [12:42:36]Alternative clock won't be tested
-    [12:42:36]Test conformance/interfaces/pthread_cond_broadcast/2-3.c unresolved: got 1073741846 (Invalid argument) on line 384 ([parent] Failed to set thread stack size)
-    conformance/interfaces/pthread_cond_broadcast/4-2: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_cond_destroy/2-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_cond_init/1-2: execution: UNTESTED: Output: 
-    File conformance/interfaces/pthread_cond_init/1-2.c cannot test: This test requires unsupported features
-    conformance/interfaces/pthread_cond_init/1-3: execution: UNTESTED: Output: 
-    File conformance/interfaces/pthread_cond_init/1-3.c cannot test: This test requires unsupported features
-    conformance/interfaces/pthread_cond_init/2-2: execution: UNTESTED: Output: 
-    File conformance/interfaces/pthread_cond_init/2-2.c cannot test: This test requires unsupported features
-    conformance/interfaces/pthread_cond_init/4-1: execution: UNRESOLVED: Output: 
-    Test conformance/interfaces/pthread_cond_init/4-1.c unresolved: got 1073741942 (Not supported) on line 145 (Cond attribute PSHARED failed)
-    conformance/interfaces/pthread_cond_init/4-2: execution: INTERRUPTED: Output: 
-    Test conformance/interfaces/pthread_cond_init/4-2.c unresolved: got 1073741942 (Not supported) on line 171 (Cond attribute PSHARED failed)
-    conformance/interfaces/pthread_cond_signal/1-2: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_cond_signal/4-2: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_cond_timedwait/4-3: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_cond_wait/4-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_condattr_getpshared/1-2: execution: UNRESOLVED: Output: 
-    Error in pthread_condattr_setpshared(), error: 1073741942
-    conformance/interfaces/pthread_condattr_setclock/1-2: execution: UNSUPPORTED: Output: 
-    UNSUPPORTED: CLOCK_MONOTONIC is unsupported
-    conformance/interfaces/pthread_condattr_setclock/1-3: execution: UNSUPPORTED: Output: 
-    _POSIX_CPUTIME unsupported
-    conformance/interfaces/pthread_condattr_setpshared/1-2: execution: FAILED: Output: 
-    Test FAILED: Could not set pshared to PTHREAD_PROCESS_SHARED, error: 1073741942
-    conformance/interfaces/pthread_create/1-4: execution: UNTESTED: Output: 
-    [13:44:56]System abilities:
-    [13:44:56] TSA: -1
-    [13:44:56] TSS: -1
-    [13:44:56] TPS: -1
-    [13:44:56] pagesize: 4096
-    [13:44:56] min stack size: -1
-    [13:44:56]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size
-    conformance/interfaces/pthread_create/1-5: execution: UNTESTED: Output: 
-    [13:44:56]System abilities:
-    [13:44:56] TSA: -1
-    [13:44:56] TSS: -1
-    [13:44:56] TPS: -1
-    [13:44:56] pagesize: 4096
-    [13:44:56] min stack size: -1
-    [13:44:56]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size
-    conformance/interfaces/pthread_create/1-6: execution: UNTESTED: Output: 
-    [13:44:57]System abilities:
-    [13:44:57] TSA: -1
-    [13:44:57] TSS: -1
-    [13:44:57] TPS: -1
-    [13:44:57] pagesize: 4096
-    [13:44:57] min stack size: -1
-    [13:44:57]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size
-    conformance/interfaces/pthread_create/11-1: execution: UNSUPPORTED: Output: 
-    _POSIX_THREAD_CPUTIME not supported
-    conformance/interfaces/pthread_create/14-1: execution: UNTESTED: Output: 
-    [13:45:08]System abilities:
-    [13:45:08] TSA: -1
-    [13:45:08] TSS: -1
-    [13:45:08] TPS: -1
-    [13:45:08] pagesize: 4096
-    [13:45:08] min stack size: -1
-    [13:45:08]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size
-    conformance/interfaces/pthread_create/15-1: execution: UNTESTED: Output: 
-    [13:45:09]System abilities:
-    [13:45:09] TSA: -1
-    [13:45:09] TSS: -1
-    [13:45:09] TPS: -1
-    [13:45:09] pagesize: 4096
-    [13:45:09] min stack size: -1
-    [13:45:09]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size
-    conformance/interfaces/pthread_create/3-2: execution: UNTESTED: Output: 
-    [13:45:11]Growing down stack started upon 0x19fffa0 and we are currently down to 0x19fff60
-    [13:45:11]Test starting
-     Stack tests will be executed.
-     Sched tests won't be executed.
-    [13:45:11]System abilities:
-    [13:45:11] TSA: -1
-    [13:45:11] TSS: -1
-    [13:45:11] TPS: -1
-    [13:45:11] pagesize: 4096
-    [13:45:11] min stack size: -1
-    [13:45:11]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size
-    conformance/interfaces/pthread_create/8-2: execution: UNTESTED: Output: 
-    [13:45:13]System abilities:
-    [13:45:13] TSA: -1
-    [13:45:13] TSS: -1
-    [13:45:13] TPS: -1
-    [13:45:13] pagesize: 4096
-    [13:45:13] min stack size: -1
-    [13:45:13]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size
-    conformance/interfaces/pthread_detach/1-2: execution: UNTESTED: Output: 
-    [13:45:13]System abilities:
-    [13:45:13] TSA: -1
-    [13:45:13] TSS: -1
-    [13:45:13] TPS: -1
-    [13:45:13] pagesize: 4096
-    [13:45:13] min stack size: -1
-    [13:45:13]File conformance/interfaces/pthread_detach/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size
-    conformance/interfaces/pthread_detach/2-2: execution: UNTESTED: Output: 
-    [13:45:14]System abilities:
-    [13:45:14] TSA: -1
-    [13:45:14] TSS: -1
-    [13:45:14] TPS: -1
-    [13:45:14] pagesize: 4096
-    [13:45:14] min stack size: -1
-    [13:45:14]File conformance/interfaces/pthread_detach/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size
-    conformance/interfaces/pthread_detach/4-3: execution: UNTESTED: Output: 
-    [13:45:15]System abilities:
-    [13:45:16] TSA: -1
-    [13:45:16] TSS: -1
-    [13:45:16] TPS: -1
-    [13:45:16] pagesize: 4096
-    [13:45:16] min stack size: -1
-    [13:45:16]File conformance/interfaces/pthread_detach/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size
-    conformance/interfaces/pthread_equal/2-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_exit/1-2: execution: UNTESTED: Output: 
-    [15:01:43]System abilities:
-    [15:01:43] TSA: -1
-    [15:01:43] TSS: -1
-    [15:01:43] TPS: -1
-    [15:01:43] pagesize: 4096
-    [15:01:43] min stack size: -1
-    [15:01:43]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size
-    conformance/interfaces/pthread_exit/2-2: execution: UNTESTED: Output: 
-    [15:01:44]System abilities:
-    [15:01:44] TSA: -1
-    [15:01:44] TSS: -1
-    [15:01:44] TPS: -1
-    [15:01:44] pagesize: 4096
-    [15:01:44] min stack size: -1
-    [15:01:44]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size
-    conformance/interfaces/pthread_exit/3-2: execution: UNTESTED: Output: 
-    [15:01:45]System abilities:
-    [15:01:45] TSA: -1
-    [15:01:45] TSS: -1
-    [15:01:45] TPS: -1
-    [15:01:45] pagesize: 4096
-    [15:01:45] min stack size: -1
-    [15:01:45]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size
-    conformance/interfaces/pthread_exit/4-1: execution: UNTESTED: Output: 
-    [15:01:45]System abilities:
-    [15:01:45] TSA: -1
-    [15:01:45] TSS: -1
-    [15:01:45] TPS: -1
-    [15:01:45] pagesize: 4096
-    [15:01:45] min stack size: -1
-    [15:01:45]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size
-    conformance/interfaces/pthread_exit/5-1: execution: UNTESTED: Output: 
-    [15:01:46]System abilities:
-    [15:01:46] TSA: -1
-    [15:01:46] TSS: -1
-    [15:01:46] TPS: -1
-    [15:01:46] pagesize: 4096
-    [15:01:46] min stack size: -1
-    [15:01:46]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size
-    conformance/interfaces/pthread_exit/6-1: execution: UNTESTED: Output: 
-    [15:01:46]System abilities:
-    [15:01:46] TSA: -1
-    [15:01:46] TSS: -1
-    [15:01:46] TPS: -1
-    [15:01:46] pagesize: 4096
-    [15:01:46] min stack size: -1
-    [15:01:46]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size
-    conformance/interfaces/pthread_exit/6-2: execution: UNTESTED: Output: 
-    [15:01:46]System abilities:
-    [15:01:46] TSA: -1
-    [15:01:46] TSS: -1
-    [15:01:46] TPS: -1
-    [15:01:46] pagesize: 4096
-    [15:01:46] min stack size: -1
-    [15:01:46]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size
-    conformance/interfaces/pthread_getschedparam/1-1: execution: FAILED: Output: 
-    Error at pthread_getschedparam: rc=1073741902
-    conformance/interfaces/pthread_getschedparam/1-2: execution: UNRESOLVED: Output: 
-    Error at pthread_setschedparam: rc=1073741902
-    conformance/interfaces/pthread_getschedparam/1-3: execution: UNRESOLVED: Output: 
-    [15:01:49]Test conformance/interfaces/pthread_getschedparam/1-3.c unresolved: got 1073741902 (Function not implemented) on line 223 (Failed to get min priority)
-    conformance/interfaces/pthread_getschedparam/4-1: execution: UNRESOLVED: Output: 
-    [15:01:49]Test conformance/interfaces/pthread_getschedparam/4-1.c unresolved: got 1073741902 (Function not implemented) on line 200 (Unexpected error returned)
-    conformance/interfaces/pthread_join/1-2: execution: UNTESTED: Output: 
-    [15:01:54]System abilities:
-    [15:01:54] TSA: -1
-    [15:01:54] TSS: -1
-    [15:01:54] TPS: -1
-    [15:01:54] pagesize: 4096
-    [15:01:54] min stack size: -1
-    [15:01:54]File conformance/interfaces/pthread_join/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size
-    conformance/interfaces/pthread_join/3-1: execution: UNRESOLVED: Output: 
-    Error in pthread_testcancel().  Cancel request timed out.
-    : (os/kern) successful
-    conformance/interfaces/pthread_join/4-1: execution: UNTESTED: Output: 
-    [15:02:06]System abilities:
-    [15:02:06] TSA: -1
-    [15:02:06] TSS: -1
-    [15:02:06] TPS: -1
-    [15:02:06] pagesize: 4096
-    [15:02:06] min stack size: -1
-    [15:02:06]File conformance/interfaces/pthread_join/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size
-    conformance/interfaces/pthread_join/6-3: execution: UNTESTED: Output: 
-    [15:02:07]System abilities:
-    [15:02:07] TSA: -1
-    [15:02:07] TSS: -1
-    [15:02:07] TPS: -1
-    [15:02:07] pagesize: 4096
-    [15:02:07] min stack size: -1
-    [15:02:07]File conformance/interfaces/pthread_join/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size
-    conformance/interfaces/pthread_key_create/2-1: execution: INTERRUPTED: Output: 
-    2-1.test: /var/tmp/hurd-20090404/./libpthread/sysdeps/hurd/pt-getspecific.c:30: pthread_getspecific: Assertion `key < __pthread_key_count' failed.
-    conformance/interfaces/pthread_kill/2-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_kill/3-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_kill/7-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_kill/8-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_mutex_getprioceiling/1-1: execution: FAILED: Output: 
-    Test FAILED: Error obtaining the priority ceiling
-
-Another system crash, due to conformance/interfaces/pthread_mutex_init/5-1:
-
-    (default pager): dropping data_request because of previous paging errors
-    (default pager): dropping data_request because of previous paging errors
-    (default pager): dropping data_request because of previous paging errors
-    (default pager): dropping data_request because of previous paging errors
-
-Disable the panic-causing test (conformance/interfaces/pthread_mutex_init/5-1)
-and restart:
-
-    conformance/interfaces/pthread_mutex_init/speculative/5-2: execution: UNTESTED: Output: 
-    Implementation is: 
-    	GNU
-    	0.3
-    	GNU-Mach 1.3.99/Hurd-0.3
-    This implementation is not tested yet
-    conformance/interfaces/pthread_mutex_timedlock/5-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_mutex_timedlock/5-2: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_mutex_trylock/4-3: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_mutexattr_getprioceiling/1-1: execution: UNRESOLVED: Output: 
-    Error obtaining the attribute process-shared
-    conformance/interfaces/pthread_mutexattr_getprioceiling/1-2: execution: UNRESOLVED: Output: 
-    Error setting prioceiling to -1
-    conformance/interfaces/pthread_mutexattr_getprioceiling/3-1: execution: FAILED: Output: 
-    Test FAILED: Invalid return code 1073741902. Expected EINVAL or 0.
-    conformance/interfaces/pthread_mutexattr_getprotocol/1-2: execution: UNRESOLVED: Output: 
-    Error setting protocol to 1
-    conformance/interfaces/pthread_mutexattr_getpshared/1-2: execution: UNRESOLVED: Output: 
-    Error in pthread_mutexattr_setpshared(), error: 1073741942
-    conformance/interfaces/pthread_mutexattr_gettype/speculative/3-1: execution: FAILED: Output: 
-    Test FAILED: Incorrect return code.  Expected EINVAL, but got: 0
-    conformance/interfaces/pthread_mutexattr_setprioceiling/1-1: execution: FAILED: Output: 
-    Test FAILED: Error setting prioceiling to -1
-    conformance/interfaces/pthread_mutexattr_setprioceiling/3-1: execution: FAILED: Output: 
-    Test FAILED: Invalid return code 1073741902. Expected EINVAL or 0.
-    conformance/interfaces/pthread_mutexattr_setprioceiling/3-2: execution: FAILED: Output: 
-    Test FAILED: Invalid return code 1073741902. Expected EINVAL or 0.
-    conformance/interfaces/pthread_mutexattr_setprotocol/1-1: execution: UNRESOLVED: Output: 
-    Error setting protocol to 1
-    conformance/interfaces/pthread_mutexattr_setpshared/1-1: execution: FAILED: Output: 
-    Test FAILED: Cannot set pshared attribute to PTHREAD_PROCESS_SHARED. Error code: 1073741942
-    conformance/interfaces/pthread_mutexattr_setpshared/2-2: execution: FAILED: Output: 
-    Test FAILED: Expected return code 0, got: 1073741942
-    conformance/interfaces/pthread_rwlock_rdlock/2-1: execution: FAILED: Output: 
-    main: has priority: 1
-    main: attempt read lock
-    main: acquired read lock
-    main: create wr_thread, with priority: 0
-    wr_thread: attempt write lock
-    main: create rd_thread, with priority: -1
-    rd_thread: attempt read lock
-    rd_thread: acquired read lock
-    rd_thread: unlock read lock
-    Test FAILED: rd_thread did not block on read lock, when a reader owns the lock, and a higher priority writer is waiting for the lock
-    conformance/interfaces/pthread_rwlock_rdlock/2-2: execution: FAILED: Output: 
-    main: attempt read lock
-    main: acquired read lock
-    main: create wr_thread, with priority: 0
-    wr_thread: attempt write lock
-    main: create rd_thread, with priority: 0
-    rd_thread: attempt read lock
-    rd_thread: acquired read lock
-    rd_thread: unlock read lock
-    Test FAILED: rd_thread did not block on read lock, when a reader owns the lock, and an equal priority writer is waiting for the lock
-    conformance/interfaces/pthread_rwlock_unlock/3-1: execution: FAILED: Output: 
-    main: write lock
-    main: create writer1, with priority: 1
-    writer1: attempt write lock
-    main: create reader, with priority: 1
-    reader: attempt read lock
-    main: create writer2, with priority: -1
-    writer2: attempt write lock
-    main: release write lock
-    writer2: acquired writer lock
-    Test fail: writer did not get write lock, when main release the lock
-    conformance/interfaces/pthread_rwlock_unlock/4-1: execution: INTERRUPTED: Output: 
-    4-1.test: /var/tmp/hurd-20090404/./libpthread/sysdeps/generic/pt-rwlock-unlock.c:34: pthread_rwlock_unlock: Assertion `__pthread_spin_trylock (&rwlock->__held) == ((0x10 << 26) | ((16) & 0x3fff))' failed.
-    conformance/interfaces/pthread_rwlock_unlock/4-2: execution: INTERRUPTED: Output: 
-    4-2.test: /var/tmp/hurd-20090404/./libpthread/sysdeps/generic/pt-rwlock-unlock.c:34: pthread_rwlock_unlock: Assertion `__pthread_spin_trylock (&rwlock->__held) == ((0x10 << 26) | ((16) & 0x3fff))' failed.
-    main: attempt read lock
-    main: acquired read lock
-    main: create un_thread
-    un_thread: unlock read lock
-    conformance/interfaces/pthread_rwlock_wrlock/3-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_rwlockattr_getpshared/2-1: execution: UNRESOLVED: Output: 
-    Error at pthread_rwlockattr_setpshared()
-    conformance/interfaces/pthread_rwlockattr_setpshared/1-1: execution: FAILED: Output: 
-    Test FAILED: Error at pthread_rwlockattr_setpshared(), return error: 1073741942
-    conformance/interfaces/pthread_setschedparam/1-1: execution: FAILED: Output: 
-    Error at pthread_setschedparam: rc=1073741902
-    conformance/interfaces/pthread_setschedparam/1-2: execution: UNTESTED: Output: 
-    [08:51:19]File conformance/interfaces/pthread_setschedparam/1-2.c cannot test: Failed to get min SCHED_RR range
-    conformance/interfaces/pthread_setschedparam/4-1: execution: UNRESOLVED: Output: 
-    [08:51:20]Test conformance/interfaces/pthread_setschedparam/4-1.c unresolved: got 1073741902 (Function not implemented) on line 132 (Failed to set thread policy -- need to be root?)
-    conformance/interfaces/pthread_setschedparam/5-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_setschedprio/1-1: execution: UNRESOLVED: Output: 
-    Error at pthread_setschedparam: rc=1073741902
-    conformance/interfaces/pthread_sigmask/10-1: execution: FAILED: Output: 
-    FAIL: SIGKILL was added to the signal mask
-    Test FAILED
-    conformance/interfaces/pthread_sigmask/18-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_sigmask/4-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_sigmask/5-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_sigmask/6-1: execution: HUNG: Output: 
-    conformance/interfaces/pthread_sigmask/9-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/pthread_spin_lock/1-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sched_get_priority_max/1-1: execution: FAILED: Output: 
-    An error occurs: Function not implemented
-    conformance/interfaces/sched_get_priority_max/1-2: execution: FAILED: Output: 
-    An error occurs: Function not implemented
-    conformance/interfaces/sched_get_priority_max/1-3: execution: UNSUPPORTED: Output: 
-    Does not support SS (SPORADIC SERVER)
-    conformance/interfaces/sched_get_priority_max/1-4: execution: FAILED: Output: 
-    An error occurs: Function not implemented
-    conformance/interfaces/sched_get_priority_max/2-1: execution: FAILED: Output: 
-    error is not EINVAL: Function not implemented
-    conformance/interfaces/sched_get_priority_min/1-1: execution: FAILED: Output: 
-    An error occurs: Function not implemented
-    conformance/interfaces/sched_get_priority_min/1-2: execution: FAILED: Output: 
-    An error occurs: Function not implemented
-    conformance/interfaces/sched_get_priority_min/1-3: execution: UNSUPPORTED: Output: 
-    Does not support SS (SPORADIC SERVER)
-    conformance/interfaces/sched_get_priority_min/1-4: execution: FAILED: Output: 
-    An error occurs: Function not implemented
-    conformance/interfaces/sched_get_priority_min/2-1: execution: FAILED: Output: 
-    error is not EINVAL: Function not implemented
-    conformance/interfaces/sched_getparam/1-1: execution: FAILED: Output: 
-    Return code is not zero.
-    conformance/interfaces/sched_getparam/2-1: execution: FAILED: Output: 
-    Different results between pid == 0 and pid == getpid().
-    conformance/interfaces/sched_getparam/3-1: execution: FAILED: Output: 
-    Unexpected error: Function not implemented
-    conformance/interfaces/sched_getparam/4-1: execution: FAILED: Output: 
-    errno is not ESRCH: Function not implemented
-    conformance/interfaces/sched_getparam/6-1: execution: UNRESOLVED: Output: 
-    errno is not EPERM: The system allows a non-rootuser to use sched_getparam(): Function not implemented
-    conformance/interfaces/sched_getparam/speculative/7-1: execution: UNRESOLVED: Output: 
-    sched_getparam() return -1 and sets errno == 1073741902.
-    conformance/interfaces/sched_getscheduler/1-1: execution: FAILED: Output: 
-    Unexpected error: Function not implemented
-    conformance/interfaces/sched_getscheduler/2-1: execution: UNTESTED: Output: 
-    Will not test the behavior of sched_getscheduler() when pid is negative
-     because it is unspecified.
-    conformance/interfaces/sched_getscheduler/3-1: execution: FAILED: Output: 
-    Returned code is -1.
-    conformance/interfaces/sched_getscheduler/4-1: execution: FAILED: Output: 
-    Unexpected error: Function not implemented
-    conformance/interfaces/sched_getscheduler/7-1: execution: FAILED: Output: 
-    errno is not EPERM: Function not implemented
-    conformance/interfaces/sched_rr_get_interval/1-1: execution: FAILED: Output: 
-    Unexpected error: Function not implemented
-    conformance/interfaces/sched_rr_get_interval/2-1: execution: FAILED: Output: 
-    interval.tv_sec  not updated.
-    conformance/interfaces/sched_rr_get_interval/3-1: execution: FAILED: Output: 
-    Returned error is not ESRCH: Function not implemented
-    conformance/interfaces/sched_rr_get_interval/speculative/5-1: execution: UNRESOLVED: Output: 
-    sched_rr_get_interval() return -1 and sets errno == 1073741902.
-    conformance/interfaces/sched_setparam/1-1: execution: UNRESOLVED: Output: 
-    An error occurs when calling sched_getparam(): Function not implemented
-    conformance/interfaces/sched_setparam/10-1: execution: UNRESOLVED: Output: 
-    An error occurs when calling shmget(): Invalid argument
-    conformance/interfaces/sched_setparam/12-1: execution: UNTESTED: Output: 
-    Not yet tested.
-    conformance/interfaces/sched_setparam/13-1: execution: UNTESTED: Output: 
-    Not yet tested.
-    conformance/interfaces/sched_setparam/14-1: execution: UNTESTED: Output: 
-    Not yet tested.
-    conformance/interfaces/sched_setparam/15-1: execution: UNTESTED: Output: 
-    Will not test the effects of the sched_ss_low_priority,
-    sched_ss_repl_period, and sched_ss_init_budget members when the scheduling
-    policy of the target process is not SCHED_FIFO, SCHED_RR, or SCHED_SPORADIC.
-    It is implementation-defined.
-    conformance/interfaces/sched_setparam/16-1: execution: UNTESTED: Output: 
-     Will not test the result of sched_setparam when the scheduling policy of the
-    target process is not SCHED_FIFO, SCHED_RR, or SCHED_SPORADIC.
-    It is implementation-defined.
-    conformance/interfaces/sched_setparam/17-1: execution: UNTESTED: Output: 
-    Will not test that sched_setparam have no effect on the scheduling of threads
-     with system scheduling contention scope.
-    conformance/interfaces/sched_setparam/18-1: execution: UNTESTED: Output: 
-    Will not test that the threads scheduling policy and associated parameters
-    are not affected.
-    conformance/interfaces/sched_setparam/19-1: execution: UNTESTED: Output: 
-    Will not test that the underlying kernel-scheduled entities for the system
-    contention scope threads are not be affected by this sched_setparam().
-    conformance/interfaces/sched_setparam/2-1: execution: UNRESOLVED: Output: 
-    An error occurs when calling sched_setscheduler(): Function not implemented
-    conformance/interfaces/sched_setparam/2-2: execution: UNRESOLVED: Output: 
-    An error occurs when calling sched_setscheduler(): Function not implemented
-    conformance/interfaces/sched_setparam/22-1: execution: UNRESOLVED: Output: 
-    An error occurs when calling sched_getparam(): Function not implemented
-    conformance/interfaces/sched_setparam/23-1: execution: UNRESOLVED: Output: 
-    An error occurs when calling sched_getparam(): Function not implemented
-    conformance/interfaces/sched_setparam/23-2: execution: UNSUPPORTED: Output: 
-    Does not support SS (SPORADIC SERVER)
-    conformance/interfaces/sched_setparam/23-3: execution: UNSUPPORTED: Output: 
-    Does not support SS (SPORADIC SERVER)
-    conformance/interfaces/sched_setparam/23-4: execution: UNSUPPORTED: Output: 
-    Does not support SS (SPORADIC SERVER)
-    conformance/interfaces/sched_setparam/23-5: execution: UNSUPPORTED: Output: 
-    Does not support SS (SPORADIC SERVER)
-    conformance/interfaces/sched_setparam/23-6: execution: UNRESOLVED: Output: 
-    An error occurs when calling sched_getparam(): Function not implemented
-    conformance/interfaces/sched_setparam/23-7: execution: UNRESOLVED: Output: 
-    An error occurs when calling sched_getparam(): Function not implemented
-    conformance/interfaces/sched_setparam/25-1: execution: UNRESOLVED: Output: 
-    An error occurs when calling sched_getscheduler(): Function not implemented
-    conformance/interfaces/sched_setparam/25-2: execution: UNSUPPORTED: Output: 
-    Does not support SS (SPORADIC SERVER)
-    conformance/interfaces/sched_setparam/26-1: execution: UNRESOLVED: Output: 
-    An error occurs when calling sched_getparam(): Function not implemented
-    conformance/interfaces/sched_setparam/27-1: execution: UNRESOLVED: Output: 
-    An error occurs when calling sched_getparam(): Function not implemented
-    conformance/interfaces/sched_setparam/3-1: execution: UNTESTED: Output: 
-    Will not test the behavior of sched_setparam() when pid is negative because
-    it is unspecified.
-    conformance/interfaces/sched_setparam/5-1: execution: UNRESOLVED: Output: 
-    An error occurs when calling sched_getparam(): Function not implemented
-    conformance/interfaces/sched_setparam/6-1: execution: UNTESTED: Output: 
-    Will not test the conditions under which one process has permission to
-    change the scheduling parameters of another process, because they are
-    implementation-defined.
-    conformance/interfaces/sched_setparam/7-1: execution: UNTESTED: Output: 
-    Will not test that implementations may require the requesting process to
-    have the appropriate privilege to set its own scheduling parameters or those
-    of another process.
-    conformance/interfaces/sched_setparam/8-1: execution: UNTESTED: Output: 
-    Will not test that the target process is moved to the tail of the thread
-    list for its priority when it is running.
-    conformance/interfaces/sched_setparam/9-1: execution: UNRESOLVED: Output: 
-    An error occurs when calling shmget(): Invalid argument
-    conformance/interfaces/sched_setscheduler/1-1: execution: UNRESOLVED: Output: 
-    Policy: SCHED_FIFO
-      Error calling sched_setscheduler() for SCHED_FIFO policy
-    Policy: SCHED_RR
-      Error calling sched_setscheduler() for SCHED_RR policy
-    Policy: SCHED_OTHER
-      Error calling sched_setscheduler() for SCHED_OTHER policy
-    conformance/interfaces/sched_setscheduler/10-1: execution: UNTESTED: Output: 
-    Not yet tested.
-    conformance/interfaces/sched_setscheduler/11-1: execution: UNTESTED: Output: 
-    Not yet tested.
-    conformance/interfaces/sched_setscheduler/12-1: execution: UNTESTED: Output: 
-    Will not test that sched_setscheduler have no effect on the scheduling of
-     threads with system scheduling contention scope.
-    conformance/interfaces/sched_setscheduler/13-1: execution: UNTESTED: Output: 
-    Will not test that the threads scheduling policy and associated parameters
-    are not affected.
-    conformance/interfaces/sched_setscheduler/14-1: execution: UNTESTED: Output: 
-    Will not test that the underlying kernel-scheduled entities for the system
-    contention scope threads are not be affected by sched_setscheduler().
-    conformance/interfaces/sched_setscheduler/15-1: execution: UNSUPPORTED: Output: 
-    Process contention scope threads are not supported.
-    conformance/interfaces/sched_setscheduler/16-1: execution: UNRESOLVED: Output: 
-    An error occurs when calling sched_getscheduler(): Function not implemented
-    conformance/interfaces/sched_setscheduler/17-1: execution: UNRESOLVED: Output: 
-    Policy: SCHED_FIFO
-    An error occurs when calling sched_getparam(): Function not implemented
-    conformance/interfaces/sched_setscheduler/17-2: execution: UNSUPPORTED: Output: 
-    Does not support SS (SPORADIC SERVER)
-    conformance/interfaces/sched_setscheduler/17-3: execution: UNSUPPORTED: Output: 
-    Does not support SS (SPORADIC SERVER)
-    conformance/interfaces/sched_setscheduler/17-4: execution: UNSUPPORTED: Output: 
-    Does not support SS (SPORADIC SERVER)
-    conformance/interfaces/sched_setscheduler/17-5: execution: UNRESOLVED: Output: 
-    An error occurs when calling sched_getparam(): Function not implemented
-    conformance/interfaces/sched_setscheduler/17-6: execution: UNRESOLVED: Output: 
-    An error occurs when calling sched_getparam(): Function not implemented
-    conformance/interfaces/sched_setscheduler/17-7: execution: UNRESOLVED: Output: 
-    An error occurs when calling sched_getparam(): Function not implemented
-    conformance/interfaces/sched_setscheduler/19-1: execution: UNRESOLVED: Output: 
-    Policy: SCHED_FIFO
-    An error occurs when calling sched_get_priority_max(): Function not implemented
-    conformance/interfaces/sched_setscheduler/19-2: execution: UNSUPPORTED: Output: 
-    Does not support SS (SPORADIC SERVER)
-    conformance/interfaces/sched_setscheduler/19-3: execution: UNSUPPORTED: Output: 
-    Does not support SS (SPORADIC SERVER)
-    conformance/interfaces/sched_setscheduler/19-4: execution: UNSUPPORTED: Output: 
-    Does not support SS (SPORADIC SERVER)
-    conformance/interfaces/sched_setscheduler/19-5: execution: FAILED: Output: 
-    Unknow error: Function not implemented
-    conformance/interfaces/sched_setscheduler/2-1: execution: UNTESTED: Output: 
-    Will not test the behavior of sched_setscheduler() when pid is negative
-     because it is unspecified.
-    conformance/interfaces/sched_setscheduler/20-1: execution: FAILED: Output: 
-    errno is not EPERM: Function not implemented
-    conformance/interfaces/sched_setscheduler/21-1: execution: FAILED: Output: 
-    errno is not ESRCH: Function not implemented
-    conformance/interfaces/sched_setscheduler/4-1: execution: UNRESOLVED: Output: 
-    An error occurs when calling sched_getparam(): Function not implemented
-    conformance/interfaces/sched_setscheduler/5-1: execution: UNTESTED: Output: 
-    Will not test the condition under which one process has the appropriate
-    privilege to change the scheduling parameters of another process because 
-    they are implementation-defined.
-    conformance/interfaces/sched_setscheduler/6-1: execution: UNTESTED: Output: 
-    Will not test that implementations may require that the requesting process
-    have permission to set its own scheduling parameters or those of another
-    process.
-    conformance/interfaces/sched_setscheduler/7-1: execution: UNTESTED: Output: 
-    Will not test if implementation-defined restrictions apply as to the
-    appropriate privileges required to set a process' own scheduling policy, or
-    another process' scheduling policy, to a particular value.
-    conformance/interfaces/sched_setscheduler/9-1: execution: UNTESTED: Output: 
-    Not yet tested.
-    conformance/interfaces/sem_close/1-1: execution: INTERRUPTED: Output: 
-    unexpected error: sem_close 1-1: sem_open: Operation not supported
-    conformance/interfaces/sem_close/2-1: execution: INTERRUPTED: Output: 
-    unexpected error: sem_close 2-1: sem_open: Operation not supported
-    conformance/interfaces/sem_close/3-1: execution: INTERRUPTED: Output: 
-    unexpected error: sem_close 3-1: sem_open: Operation not supported
-    conformance/interfaces/sem_close/3-2: execution: UNRESOLVED: Output: 
-    [08:56:54]Test conformance/interfaces/sem_close/3-2.c unresolved: got 1073741869 (Operation not supported) on line 113 (Failed to create the semaphore)
-    conformance/interfaces/sem_getvalue/1-1: execution: UNRESOLVED: Output: 
-    unexpected error: sem_getvalue 1-1: sem_open: Operation not supported
-    conformance/interfaces/sem_getvalue/2-1: execution: UNRESOLVED: Output: 
-    unexpected error: sem_getvalue 2-1: sem_open: Operation not supported
-    conformance/interfaces/sem_getvalue/4-1: execution: UNRESOLVED: Output: 
-    unexpected error: sem_getvalue 4-1: sem_open: Operation not supported
-    conformance/interfaces/sem_getvalue/5-1: execution: UNRESOLVED: Output: 
-    unexpected error: sem_getvalue 5-1: sem_open: Operation not supported
-    conformance/interfaces/sem_init/3-2: execution: UNRESOLVED: Output: 
-    [08:56:59]Test conformance/interfaces/sem_init/3-2.c unresolved: got 1073741869 (Operation not supported) on line 135 (Failed to init the semaphore)
-    conformance/interfaces/sem_init/3-3: execution: UNRESOLVED: Output: 
-    [08:57:00]Test conformance/interfaces/sem_init/3-3.c unresolved: got 1073741869 (Operation not supported) on line 134 (Failed to init the semaphore)
-    conformance/interfaces/sem_init/7-1: execution: UNTESTED: Output: 
-    [08:57:01]sysconf( _SC_SEM_NSEMS_MAX ) = -1
-    [08:57:01]File conformance/interfaces/sem_init/7-1.c cannot test: There is no constraint on SEM_NSEMS_MAX
-    conformance/interfaces/sem_open/1-1: execution: FAILED: Output: 
-    TEST FAILED
-    conformance/interfaces/sem_open/1-3: execution: UNRESOLVED: Output: 
-    unexpected error: sem_open 1-3: sem_open: Operation not supported
-    conformance/interfaces/sem_open/1-4: execution: UNRESOLVED: Output: 
-    unexpected error: sem_open 1-4: sem_open: Operation not supported
-    conformance/interfaces/sem_open/10-1: execution: UNRESOLVED: Output: 
-    unexpected error: sem_open 10-1: sem_open: Operation not supported
-    conformance/interfaces/sem_open/15-1: execution: UNRESOLVED: Output: 
-    [08:57:03]Test conformance/interfaces/sem_open/15-1.c unresolved: got 1073741869 (Operation not supported) on line 106 (Failed to sem_open)
-    conformance/interfaces/sem_open/2-1: execution: UNRESOLVED: Output: 
-    unexpected error: sem_open 2-1: sem_open: Operation not supported
-    conformance/interfaces/sem_open/2-2: execution: UNRESOLVED: Output: 
-    unexpected error: sem_open 2-2: sem_open: Operation not supported
-    conformance/interfaces/sem_open/3-1: execution: FAILED: Output: 
-    TEST FAILED
-    conformance/interfaces/sem_open/4-1: execution: FAILED: Output: 
-    TEST FAILED
-    conformance/interfaces/sem_open/6-1: execution: FAILED: Output: 
-    TEST FAILED
-    conformance/interfaces/sem_post/1-1: execution: UNRESOLVED: Output: 
-    unexpected error: sem_post 1-1: sem_open: Operation not supported
-    conformance/interfaces/sem_post/1-2: execution: UNRESOLVED: Output: 
-    unexpected error: sem_post 1-2: sem_open: Operation not supported
-    conformance/interfaces/sem_post/2-1: execution: UNRESOLVED: Output: 
-    unexpected error: sem_post 2-1: sem_open: Operation not supported
-    conformance/interfaces/sem_post/4-1: execution: UNRESOLVED: Output: 
-    unexpected error: sem_post 4-1: sem_open: Operation not supported
-    conformance/interfaces/sem_post/5-1: execution: UNRESOLVED: Output: 
-    unexpected error: sem_post 5-1: sem_open: Operation not supported
-    conformance/interfaces/sem_post/6-1: execution: UNRESOLVED: Output: 
-    unexpected error: sem_post 6-1: sem_open: Operation not supported
-    conformance/interfaces/sem_post/8-1: execution: UNTESTED: Output: 
-    _POSIX_PRIORITY_SCHEDULING not defined
-    conformance/interfaces/sem_timedwait/9-1: execution: FAILED: Output: 
-    In handler
-    TEST FAILED: errno != EINTR
-    conformance/interfaces/sem_unlink/1-1: execution: INTERRUPTED: Output: 
-    unexpected error: sem_unlink 1-1: sem_open: Operation not supported
-    conformance/interfaces/sem_unlink/2-1: execution: INTERRUPTED: Output: 
-    unexpected error: sem_unlink 2-1: sem_open: Operation not supported
-    conformance/interfaces/sem_unlink/2-2: execution: UNRESOLVED: Output: 
-    [08:57:23]Test conformance/interfaces/sem_unlink/2-2.c unresolved: got 1073741869 (Operation not supported) on line 158 (Failed to create the semaphore)
-    conformance/interfaces/sem_unlink/3-1: execution: UNRESOLVED: Output: 
-    [08:57:23]Test conformance/interfaces/sem_unlink/3-1.c unresolved: got 1073741869 (Operation not supported) on line 156 (Failed to create the semaphore)
-    conformance/interfaces/sem_unlink/4-1: execution: FAILED: Output: 
-    TEST FAILED: semaphore does exist
-    conformance/interfaces/sem_unlink/4-2: execution: FAILED: Output: 
-    [08:57:24]Error 1073741869: Operation not supported
-    [08:57:24]Test conformance/interfaces/sem_unlink/4-2.c FAILED: The error was not ENOENT
-    conformance/interfaces/sem_unlink/6-1: execution: UNRESOLVED: Output: 
-    [08:57:25]Test conformance/interfaces/sem_unlink/6-1.c unresolved: got 1073741869 (Operation not supported) on line 107 (Failed to create the semaphore)
-    conformance/interfaces/sem_unlink/7-1: execution: UNRESOLVED: Output: 
-    [08:57:25]Test conformance/interfaces/sem_unlink/7-1.c unresolved: got 1073741869 (Operation not supported) on line 126 (Failed to create the semaphore)
-    conformance/interfaces/sem_unlink/9-1: execution: UNRESOLVED: Output: 
-    [08:57:25]Test conformance/interfaces/sem_unlink/9-1.c unresolved: got 1073741869 (Operation not supported) on line 133 (Failed to create the semaphore)
-    conformance/interfaces/sem_wait/1-1: execution: UNRESOLVED: Output: 
-    unexpected error: sem_wait 1-1: sem_open: Operation not supported
-    conformance/interfaces/sem_wait/1-2: execution: UNRESOLVED: Output: 
-    unexpected error: sem_wait 2-1: sem_open: Operation not supported
-    conformance/interfaces/sem_wait/11-1: execution: UNRESOLVED: Output: 
-    unexpected error: sem_trywait 11-1: sem_open: Operation not supported
-    conformance/interfaces/sem_wait/12-1: execution: INTERRUPTED: Output: 
-    unexpected error: sem_trywait 12-1: sem_open: Operation not supported
-    conformance/interfaces/sem_wait/3-1: execution: UNRESOLVED: Output: 
-    unexpected error: sem_wait 3-1: sem_open: Operation not supported
-    conformance/interfaces/sem_wait/5-1: execution: INTERRUPTED: Output: 
-    unexpected errno: sem_trywait 5-1: sem_open: Operation not supported
-    conformance/interfaces/sem_wait/7-1: execution: UNRESOLVED: Output: 
-    unexpected error: sem_wait 7-1: sem_open: Operation not supported
-    conformance/interfaces/shm_open/1-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/shm_open/10-1: execution: UNTESTED: Output: 
-    Will not test whether the file offset is set because it is unspecified.
-    conformance/interfaces/shm_open/12-1: execution: UNTESTED: Output: 
-    Will not test the behavior of implementation when an application does not
-    specify exactly one of two values: O_RDONLY and O_RDWR.
-    conformance/interfaces/shm_open/14-2: execution: INTERRUPTED: Output: 
-    conformance/interfaces/shm_open/19-1: execution: UNTESTED: Output: 
-    Will not test the effect of calling shm_open() when the shared memory object
-    does not exists, the O_CREAT flags is set, and bits in mode other than the
-    file permission bits are set. It is unspecified.
-    conformance/interfaces/shm_open/2-1: execution: UNTESTED: Output: 
-    Will not test that the shm_open() function create an open file description
-    that refers to the shared memory object and a file descriptor that refers to
-    conformance/interfaces/shm_open/23-1: execution: UNRESOLVED: Output: 
-    error at sem_open: Operation not supported
-    conformance/interfaces/shm_open/24-1: execution: UNTESTED: Output: 
-    Will not test the result of shm_open() when O_EXCL is set and O_CREAT is not
-    set because it is undefined.
-    conformance/interfaces/shm_open/26-2: execution: UNRESOLVED: Output: 
-    You don't have permission to change your UID.
-    Try to rerun this test as root.
-    conformance/interfaces/shm_open/27-1: execution: UNTESTED: Output: 
-    Will not test the result of shm_open() when using O_TRUNC with O_RDONLY.
-    It is undefined.
-    conformance/interfaces/shm_open/28-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/shm_open/28-3: execution: INTERRUPTED: Output: 
-    conformance/interfaces/shm_open/29-1: execution: UNTESTED: Output: 
-    Will not test whether the name and shared memory object state remain valid
-    after a system reboot. It is unspecified.
-    conformance/interfaces/shm_open/3-1: execution: UNTESTED: Output: 
-    Will not test whether the name appears in the file system and is visible to
-    other functions that take pathnames as arguments because it is unspecified.
-    conformance/interfaces/shm_open/36-1: execution: UNTESTED: Output: 
-    It is very difficult to test that the shm_open() function sets errno = EINTR
-    when it is interrupted by a signal.
-    conformance/interfaces/shm_open/37-1: execution: FAILED: Output: 
-    Name: '[GARBAGE]'
-       OK: open  with success.
-    Name: '[GARBAGE]'
-       OK: open  with success.
-    Name: '..'
-       Unexpected error: Is a directory
-    Name: '/'
-       OK: errno == EINVAL
-    Name: '//'
-       OK: errno == EINVAL
-    Name: '/abc'
-       OK: open  with success.
-    Test FAILED
-    conformance/interfaces/shm_open/39-2: execution: UNRESOLVED: Output: 
-    An error occurs when calling pathconf(): Invalid argument
-    conformance/interfaces/shm_open/42-1: execution: UNTESTED: Output: 
-    Will not test that the shm_open() function sets errno to ENOSPC if there is
-    insufficient space for the creation of the new shared memory object.
-    conformance/interfaces/shm_open/5-1: execution: FAILED: Output: 
-    Test FAILED
-    conformance/interfaces/shm_open/6-1: execution: UNTESTED: Output: 
-    Will not test the effect of a name which does not begin with the slash
-    character because it is implementation-defined.
-    conformance/interfaces/shm_open/7-1: execution: UNTESTED: Output: 
-    Will not test the interpretation of slash characters other than the leading
-    slash character in name because it is implementation-defined.
-    conformance/interfaces/shm_open/9-1: execution: UNTESTED: Output: 
-    Will not test that the open file description is new.
-    conformance/interfaces/shm_unlink/10-2: execution: UNRESOLVED: Output: 
-    An error occurs when calling pathconf(): Invalid argument
-    conformance/interfaces/shm_unlink/8-1: execution: UNRESOLVED: Output: 
-    You don't have permission to change your UID.
-    Try to rerun this test as root.
-    conformance/interfaces/shm_unlink/9-1: execution: UNRESOLVED: Output: 
-    You don't have permission to change your UID.
-    Try to rerun this test as root.
-    conformance/interfaces/sigaction/4-37: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/17-23: execution: FAILED: Output: 
-    Caught SIGURG
-    Test FAILED
-    conformance/interfaces/sigaction/12-41: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-4: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/4-28: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/17-26: execution: FAILED: Output: 
-    Caught SIGXFSZ
-    Test FAILED
-    conformance/interfaces/sigaction/12-49: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-8: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-45: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-18: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/4-42: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/12-15: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-25: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/17-7: execution: FAILED: Output: 
-    Caught SIGHUP
-    Test FAILED
-    conformance/interfaces/sigaction/4-48: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/12-23: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/4-34: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/12-24: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/4-43: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/17-22: execution: FAILED: Output: 
-    Caught SIGTRAP
-    Test FAILED
-    conformance/interfaces/sigaction/12-31: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-35: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-46: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-7: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-34: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-3: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/4-52: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/4-30: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/4-51: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/12-13: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/4-36: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/17-21: execution: FAILED: Output: 
-    Caught SIGSYS
-    Test FAILED
-    conformance/interfaces/sigaction/17-11: execution: FAILED: Output: 
-    Caught SIGQUIT
-    Test FAILED
-    conformance/interfaces/sigaction/4-38: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/12-47: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-30: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-44: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/4-50: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/12-27: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-20: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/4-40: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/17-19: execution: FAILED: Output: 
-    Caught SIGPOLL
-    Test FAILED
-    conformance/interfaces/sigaction/12-16: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-51: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-21: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/17-1: execution: FAILED: Output: 
-    Caught SIGABRT
-    Test FAILED
-    conformance/interfaces/sigaction/4-32: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/17-12: execution: FAILED: Output: 
-    Caught SIGSEGV
-    Test FAILED
-    conformance/interfaces/sigaction/12-52: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-10: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-36: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/17-9: execution: FAILED: Output: 
-    Caught SIGINT
-    Test FAILED
-    conformance/interfaces/sigaction/4-47: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/12-11: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/17-10: execution: FAILED: Output: 
-    Caught SIGPIPE
-    Test FAILED
-    conformance/interfaces/sigaction/12-5: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-48: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-19: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/4-46: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/17-17: execution: FAILED: Output: 
-    Caught SIGUSR1
-    Test FAILED
-    conformance/interfaces/sigaction/12-14: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/17-14: execution: FAILED: Output: 
-    Caught SIGTSTP
-    Test FAILED
-    conformance/interfaces/sigaction/17-18: execution: FAILED: Output: 
-    Caught SIGUSR2
-    Test FAILED
-    conformance/interfaces/sigaction/4-41: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/12-43: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-28: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/17-6: execution: FAILED: Output: 
-    Caught SIGFPE
-    Test FAILED
-    conformance/interfaces/sigaction/4-45: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/4-35: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/12-6: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/4-29: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/17-16: execution: FAILED: Output: 
-    Caught SIGTTOU
-    Test FAILED
-    conformance/interfaces/sigaction/4-39: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/12-29: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-9: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/17-25: execution: FAILED: Output: 
-    Caught SIGXCPU
-    Test FAILED
-    conformance/interfaces/sigaction/17-4: execution: FAILED: Output: 
-    Caught SIGCHLD
-    Test FAILED
-    conformance/interfaces/sigaction/12-22: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/17-13: execution: FAILED: Output: 
-    Caught SIGTERM
-    Test FAILED
-    conformance/interfaces/sigaction/4-31: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/12-38: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-12: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/4-44: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/4-49: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/12-40: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-42: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/17-15: execution: FAILED: Output: 
-    Caught SIGTTIN
-    Test FAILED
-    conformance/interfaces/sigaction/17-3: execution: FAILED: Output: 
-    Caught SIGBUS
-    Test FAILED
-    conformance/interfaces/sigaction/12-2: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/17-5: execution: FAILED: Output: 
-    Caught SIGCONT
-    Test FAILED
-    conformance/interfaces/sigaction/12-33: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-17: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/17-2: execution: FAILED: Output: 
-    Caught SIGALRM
-    Test FAILED
-    conformance/interfaces/sigaction/12-37: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/17-20: execution: FAILED: Output: 
-    Caught SIGPROF
-    Test FAILED
-    conformance/interfaces/sigaction/17-8: execution: FAILED: Output: 
-    Caught SIGILL
-    Test FAILED
-    conformance/interfaces/sigaction/4-33: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/12-39: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-50: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/12-32: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaction/4-27: execution: FAILED: Output: 
-    About to stop child
-    Child has continued
-    Test FAILED
-    conformance/interfaces/sigaction/17-24: execution: FAILED: Output: 
-    Caught SIGVTALRM
-    Test FAILED
-    conformance/interfaces/sigaction/12-26: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaltstack/1-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaltstack/11-1: execution: FAILED: Output: 
-    Test FAILED: Expected return value of -1.
-    conformance/interfaces/sigaltstack/12-1: execution: FAILED: Output: 
-    Test FAILED: Expected return value of -1.
-    conformance/interfaces/sigaltstack/2-1: execution: FAILED: Output: 
-    Test FAILED: ss_sp of the handler's stack changed even though SS_DISABLE was set
-    conformance/interfaces/sigaltstack/3-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaltstack/6-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigaltstack/7-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigpause/2-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/sigpending/1-2: execution: INTERRUPTED: Output: 
-    Not all pending signals found
-    conformance/interfaces/sigpending/1-3: execution: INTERRUPTED: Output: 
-    Error with send signals
-    Test FAILED
-    conformance/interfaces/sigqueue/10-1: execution: FAILED: Output: 
-    sigqueue() failed on EINVAL but errno not set correctly
-    conformance/interfaces/sigqueue/11-1: execution: FAILED: Output: 
-    sigqueue() failed on ESRCH but errno not set correctly
-    conformance/interfaces/sigqueue/12-1: execution: FAILED: Output: 
-    sigqueue() failed but errno not set correctly
-    conformance/interfaces/sigqueue/2-1: execution: FAILED: Output: 
-    Could not call sigqueue with sig = 0
-    conformance/interfaces/sigqueue/2-2: execution: FAILED: Output: 
-    sigqueue() failed on ESRCH but errno not set correctly
-    At least one test FAILED -- see output for status
-    conformance/interfaces/sigqueue/3-1: execution: FAILED: Output: 
-    Test FAILED: EPERM error not received
-    conformance/interfaces/sigset/6-1: execution: UNRESOLVED: Output: 
-    Unexpected error while using sigset(): (os/kern) successful
-    conformance/interfaces/sigset/7-1: execution: UNRESOLVED: Output: 
-    Unexpected error while using sigset(): (os/kern) successful
-    conformance/interfaces/sigset/8-1: execution: FAILED: Output: 
-    Test FAILED: sigset() didn't return SIG_HOLD
-    conformance/interfaces/sigsuspend/1-1: execution: UNRESOLVED: Output: 
-    suspending child
-    SIGUSR2 called. Inside handler
-    parent sending child a SIGUSR2 signal
-    parent sending child a SIGUSR1 signal
-    Exit status from child is 1
-    Test UNRESOLVED: Either sigsuspend did not successfully block SIGUSR2, OR sigsuspend returned before handling the signal SIGUSR1
-    conformance/interfaces/sigtimedwait/1-1: execution: FAILED: Output: 
-    Test FAILED: sigtimedwait() did not return in the required time
-    conformance/interfaces/sigtimedwait/4-1: execution: FAILED: Output: 
-    Call to sigtimedwait() failed
-    : Function not implemented
-    conformance/interfaces/sigtimedwait/6-1: execution: FAILED: Output: 
-    Test FAILED: sigtimedwait() did set errno to EAGAIN
-    conformance/interfaces/sigwait/1-1: execution: FAILED: Output: 
-    Signal SIGALRM is not pending!
-    conformance/interfaces/sigwait/3-1: execution: FAILED: Output: 
-    Test FAILED
-    conformance/interfaces/sigwait/6-1: execution: FAILED: Output: 
-    [09:04:10]0 threads were awaken
-    [09:04:10]Test conformance/interfaces/sigwait/6-1.c FAILED: Unexpected number of threads awaken
-    conformance/interfaces/sigwaitinfo/1-1: execution: UNRESOLVED: Output: 
-    Call to sigwaitinfo() failed
-    : Function not implemented
-    conformance/interfaces/sigwaitinfo/3-1: execution: FAILED: Output: 
-    Call to sigwaitinfo() failed
-    : Function not implemented
-    Child calling sigwaitinfo()
-    parent sending child a SIGUSR1 signal
-    Exit status from child is 2
-    Test FAILED
-    conformance/interfaces/sigwaitinfo/9-1: execution: FAILED: Output: 
-    Call to sigwaitinfo() failed
-    : Function not implemented
-    conformance/interfaces/strftime/2-1: execution: INTERRUPTED: Output: 
-    conformance/interfaces/timer_create/1-1: execution: FAILED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_create/10-1: execution: UNRESOLVED: Output: 
-    sysconf(_SC_CPUTIME) returns: -1
-    conformance/interfaces/timer_create/11-1: execution: UNSUPPORTED: Output: 
-    rc = -1
-    _POSIX_THREAD_CPUTIME unsupported
-    conformance/interfaces/timer_create/16-1: execution: FAILED: Output: 
-    errno != EINVAL
-    Test FAILED
-    conformance/interfaces/timer_create/3-1: execution: FAILED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_create/7-1: execution: UNSUPPORTED: Output: 
-    CLOCK_MONOTONIC unsupported
-    conformance/interfaces/timer_create/8-1: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_create/9-1: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_create/speculative/2-1: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_create/speculative/5-1: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_delete/1-1: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_delete/1-2: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_delete/speculative/5-1: execution: FAILED: Output: 
-    timer_delete() returned -1, but didn't set errno!=EINVAL
-    conformance/interfaces/timer_delete/speculative/5-2: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_getoverrun/1-1: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_getoverrun/2-1: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_getoverrun/2-2: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_getoverrun/2-3: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_getoverrun/3-1: execution: UNTESTED: Output: 
-    Cannot be tested as DELAYTIMER_MAX is too large.
-    DELAYTIMER_MAX is ffffffff
-    conformance/interfaces/timer_getoverrun/speculative/6-1: execution: FAILED: Output: 
-    fcn returned -1, but errno!=EINVAL
-    Test FAILED
-    conformance/interfaces/timer_getoverrun/speculative/6-2: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_getoverrun/speculative/6-3: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_gettime/1-1: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_gettime/1-2: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_gettime/1-3: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_gettime/1-4: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_gettime/2-1: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_gettime/2-2: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_gettime/3-1: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_gettime/speculative/6-1: execution: FAILED: Output: 
-    fcn returned -1 but errno!=EINVAL
-    Test FAILED
-    conformance/interfaces/timer_gettime/speculative/6-2: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_gettime/speculative/6-3: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_settime/1-1: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_settime/1-2: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_settime/13-1: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_settime/2-1: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_settime/3-1: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_settime/3-2: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_settime/3-3: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_settime/5-1: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_settime/5-2: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_settime/5-3: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_settime/6-1: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_settime/8-1: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_settime/8-2: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_settime/8-3: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_settime/8-4: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_settime/9-1: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_settime/9-2: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_settime/speculative/12-1: execution: FAILED: Output: 
-    fcn returned -1, but errno!=EINVAL
-    Test FAILED
-    conformance/interfaces/timer_settime/speculative/12-2: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    conformance/interfaces/timer_settime/speculative/12-3: execution: UNRESOLVED: Output: 
-    timer_create() did not return success
-    : Function not implemented
-    functional/threads/schedule/1-1: execution: UNRESOLVED: Output: 
-    unexpected error: scheduler 5-4: pthread_attr_setschedpolicy
-    functional/threads/schedule/1-2: execution: UNRESOLVED: Output: 
-    unexpected error: scheduler 5-5: pthread_setschedparam
-
-
-# IRC, OFTC, #debin-hurd, 2012-12-28
-
-    <pinotree> [...] saw posixtestsuite being completed too \o/
-    <youpi> yep :)
-    <pinotree> (still has a number of failures, but at least can be fully run)
diff --git a/open_issues/open_symlink.mdwn b/open_issues/open_symlink.mdwn
deleted file mode 100644
index 663bfcbd..00000000
--- a/open_issues/open_symlink.mdwn
+++ /dev/null
@@ -1,30 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 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]]
-
-
-# IRC, freenode, #hurd, 2012-01-02
-
-    <pinotree> hm, is it a known issue that open("somesymlink", O_RDONLY |
-      O_NOFOLLOW) does not fail with ELOOP?
-    <youpi> pinotree: iirc there is code for it, maybe not the same behavior as
-      on linux
-
-
-## IRC, OFTC, #debian-hurd, 2013-05-08
-
-    <pinotree> the hurd issue is that O_NOFOLLOW seems broken on symlinks, and
-      thus open(symlink, O_NOFOLLOW) doesn't fail with ELOOP
-    <youpi> I don't really see why it should fail
-    <youpi> since NOFOLLOW says not to follow the symlink
-    <pinotree> yeah, but you cannot open a symlink
-    <youpi> ah right ok
-    <youpi> interesting :)
diff --git a/open_issues/osf_mach.mdwn b/open_issues/osf_mach.mdwn
deleted file mode 100644
index d689bfcb..00000000
--- a/open_issues/osf_mach.mdwn
+++ /dev/null
@@ -1,237 +0,0 @@
-[[!meta copyright="Copyright © 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_gnumach open_issue_hurd]]
-
-IRC, freenode, #hurd, 2011-09-07
-
-    <slpz> tschwinge: do you think that should be possible/convenient to
-      maintain hurd and glibc versions for OSF Mach as branches in the offical
-      git repo?
-    <tschwinge> Is OSF Mach the MkLinux one?
-    <slpz> Yes, it is
-    <tschwinge> slpz: If there's a suitable license, then yes, of course!
-    <tschwinge> Unless there is a proper upstream, of course.
-    <tschwinge> But I don't assume there is?
-    <tschwinge> slpz: What is interesting for us about OSF Mach?
-    <slpz> tschwinge: Peter Bruin and Jose Marchesi did a gnuified version some
-      time ago (gnu-osfmach), so I suppose the license is not a problem. But
-      I'm going to check it, though
-    <slpz> OSF Mach has a number of interesting features
-    <slpz> like migrating threads, advisory pageout, clustered pageout, kernel
-      loaded tasks, short circuited RPC...
-    <tschwinge> Oh!
-    <tschwinge> Good.
-    <slpz> right now I'm testing if it's really worth the effort
-    <tschwinge> Yes.
-    <tschwinge> But if the core codebase is the same (is it?) it may be
-      possible to merge some things?
-    <tschwinge> If the changes can be identified reasonably...
-    <slpz> comparing performance of the specialized RPC of OSF Mach with
-      generic IPC
-    <slpz> That was my first intention, but I think that porting all those
-      features will be much more work than porting Hurd/glibc to it
-    <braunr> slpz: ipc performance currently matters less than clustered
-      pageouts
-    <braunr> slpz: i'm really not sure ..
-    <braunr> i'd personnally adapt the kernel
-    <slpz> braunr: well, clustered pageouts is one of the changes that can be
-      easily ported
-    <slpz> braunr: We can consider OSF Mach code as reasonably stable, and
-      porting its features to GNU Mach will take us to the point of having to
-      debug all that code again
-    <slpz> probably, the hardest feature to be ported is migrating threads
-    <braunr> isn't that what was tried for gnu mach 2 ? or was it only about
-      oskit ?
-    <slpz> IIRC only oskit
-    <tschwinge> slpz: But there have been some advancements in GNU Mach, too.
-      For example the Xen port.
-    <tschwinge> But wen can experiment with it, of course.
-    <slpz> tschwinge: I find easier to move the Xen support from GNU Mach to
-      OSF Mach, than porting MT in the other direction
-    <tschwinge> slpz: And I think MkLinux is a single-server, so I don't this
-      they used IPC as much as we did?
-    <tschwinge> slpz: OK, I see.
-    <braunr> slpz: MT aren't as needed as clustered pageouts :p
-    <braunr> gnumach already has ipc handoff, so MT would just consume less
-      stack space, and only slightly improve raw ipc performance
-    <tschwinge> slpz: But we will surely accept patches that get the Hurd/glibc
-      ported to OSF Mach, no question.
-    <braunr> (it's required for other issues we discussed already, but not a
-      priority imo)
-    <slpz> tschwinge: MkLinux makes heavy use of IPC, but it tries to
-      "short-circuit" it when running as a kernel loaded task
-    <tschwinge> And it's obviously best to keep it in one place.  Luckily it's
-      not CVS branches anymore...  :-)
-    <slpz> braunr: well, I'm a bit obsessed with IPC peformance, if the RPC on
-      OSF Mach really makes a difference, I want it for Hurd right now
-    <slpz> braunr: clustered pages can be implemented at any time :-)
-    <slpz> tschwinge: great!
-    <tschwinge> slpz: In fact, haven'T there already been some Savannah
-      repositories created, several (five?) years ago?
-    <braunr> slpz: the biggest performance issue on the hurd is I/O
-    <braunr> and the easiest way to improve that is better VM transfers
-    <slpz> tschwinge: yes, the HARD project, but I think it wasn't too well
-      received...
-    <tschwinge> slpz: Quite some things changed since then, I'd say.
-    <slpz> braunr: I agree, but IPC is the hardest part to optimize
-    <slpz> braunr: If we have a fast IPC, the rest of improvements are way
-      easier
-    <braunr> slpz: i don't see how faster IPC makes I/O faster :(
-    <braunr> slpz: read
-      http://www.sceen.net/~rbraun/the_increasing_irrelevance_of_ipc_performance_for_microkernel_based_operating_systems.pdf
-      again :)
-    <slpz> braunr: IPC puts the upper limit of how fast I/O could be
-    <braunr> the abstract for my thesis on x15 mach was that the ipc code was
-      the most focused part of the kernel
-    <braunr> so my approach was to optimize everything *else*
-    <braunr> the improvements in UVM (and most notably clustered page
-      transfers) show global system improvements up to 30% in netbsd
-    <braunr> we should really focus on the VM first (which btw, is a pain in
-      the ass with the crappy panicking swap code in place)
-    <braunr> and then complete the I/O system
-    <slpz> braunr: If a system can't transfer data between translators faster
-      than 100 MB/s, faster devices doesn't make much sense
-    <guillem> has anyone considered switching the syscalls to use
-      sysenter/syscall instead of soft interrupts?
-    <slpz> braunr: but I agree on the VM part
-    <braunr> guillem: it's in my thesis .. but only there :)
-    <braunr> slpz: let's reach 100 MiB/s first, then improve IPC
-    <slpz> guillem: that's a must do, also moving to 64 bits :-)
-    <braunr> guillem: there are many tiny observations in it, like the use of
-      global page table entries, which was added by youpi around that time
-    <guillem> slpz: I wanted to fix all warnings first before sending my first
-      batch of 64 bit fixes, but I think I'll just send them after checking
-      they don't introduce regressions on i386
-    <guillem> braunr: interesting I think I might have skimmed over your
-      thesis, maybe I should read it properly some time :)
-    <slpz> braunr: I see exactly as the opposite. First push IPC to its limit,
-      then improve devices/VM
-    <slpz> guillem: that's great :-)
-    <braunr> slpz: improving ipc now will bring *nothing*, whereas improving
-      vm/io now will make the system considerably more useable
-    <guillem> but then fixing 64-bit issues in the Linux code is pretty
-      annoying given that the latest code from upstream has that already fixed,
-      and we are “supposed” to drop the linux code from gnumach at some point
-      :)
-    <braunr> slpz: that's a basic principle in profiling, improve what brings
-      the best gains
-    <slpz> braunr: I'm not thinking about today, I'm thinking about how fast
-      Hurd could be when running on Mach. And, as I said, IPC is the absolute
-      upper limit.
-    <braunr> i'm really not convinced
-    <braunr> there are that many tasks making extensive use of IPCs
-    <braunr> most are cpu/IO bound
-    <slpz> but I have to acknowledge that this concern has been really
-      aliviated by the EPT improvement discovery
-    <braunr> there aren't* that many tasks
-    <slpz> braunr: create a ramdisk an write some files on it
-    <slpz> braunr: there's no I/O in that case, an performance it's really low
-      too
-    <braunr> well, ramdisks don't even work correctly iirc
-    <slpz> I must say that I consider improvements in OOL data moving as if it
-      were in IPC itself
-    <slpz> braunr: you can simulate one with storeio
-    <braunr> slpz: then measure what's slow
-    <braunr> slpz: it couldn't simply be the vm layer
-    <slpz> braunr:
-      http://www.gnu.org/s/hurd/hurd/libstore/examples/ramdisk.html
-    <braunr> ok, it's not a true ramdisk
-    <braunr> it's a stack of a ramdisk and extfs servers
-    <braunr> ext2fs*
-    <braunr> i was thinking about tmpfs
-    <slpz> True, but one of Hurd main advantages is the ability of doing that
-      kind of things
-    <slpz> so they must work with a reasonable performance
-    <braunr> other systems can too ..
-    <braunr> anyway
-    <braunr> i get your point, you want faster IPCs, like everyone does
-    <slpz> braunr: yes, and I also want to know how fast could be, to have a
-      reference when profiling complex services
-    <antrik> slpz: really improving IPC performance probably requires changing
-      the semantics... but we don't know which semantics we want until we have
-      actually tried fixing the existing bottlenecks
-    <antrik> well, not only bottlenecks... also other issues such as resource
-      management
-    <slpz> antrik: I think fixing bottlenecks would probably require changes in
-      some Mach interfaces, not in the IPC subsystem
-    <slpz> antrik: I mean, IPC semantics just provide the basis for messaging,
-      I don't think we will need to change them further
-    <antrik> slpz: right, but only once we have addressed the bottlenecks (and
-      other major shortcomings), we will know how the IPC mechanisms needs to
-      change to get further improvements...
-    <antrik> of course improving Mach IPC performance is interesting too -- if
-      nothing else, then to see how much of a difference it really makes... I
-      just don't think it should be considered an overriding priority :-)
-    <youpi> slpz: I agree with braunr, I don't think improving IPC will bring
-      much on the short term
-    <youpi> the buildds are slow mostly because of bad VM
-    <youpi> like lack of read-ahead, the randomness of object cache pageout,
-      etc.
-    <youpi> that doesn't mean IPC shouldn't be improved of course
-    <youpi> but we have a big margin for iow
-    <youpi> s/iow/now
-    <slpz> youpi: I agree with you and with braunr in that regard. I'm not
-      looking for an inmediate improvement, I just want to see how fast the IPC
-      (specially, OOL data transfers) could be.
-    <slpz> also, migrating threads will help to fix some problems related with
-      resource management
-    <antrik> slpz: BTW, what about Apple's Mach? isn't it essentialy OSF Mach
-      with some further improvements?...
-    <slpz> antrik: IPC is an area with very little room for improvement, so I
-      don't we will fix that bottlenecks by applying some changes there
-    <antrik> well, for large OOL transfers, the limiting facter is certainly
-      also VM rather than the thread model?...
-    <slpz> antrik: yes, but I think is encumbered with the APPLv2 license
-    <antrik> ugh
-    <slpz> antrik: for OOL transfers, VM plays a big role, but IPC also has
-      great deal of responsibility
-    <antrik> as for resource management, migrating threads do not really help
-      much IMHO, as they only affect CPU scheduling. memory usage is a much
-      more pressing issue
-    <antrik> BTW, I have thought about passive objects in the past, but didn't
-      reach any conclusion... so I'm a bit ambivalent about migrating threads
-      :-)
-    <slpz> As an example, in Hurd on GNU Mach, an io_read can't take advantage
-      from copy-on-write, as buffers from the translator always arrive outside
-      user's buffer
-    <slpz> antrik: well, I think cpu scheduling is a big deal ;-)
-    <slpz> antrik: and for memory management, until a better design is
-      implemented, some fixes could be applied to get us to the same level as a
-      monolithic kernel
-    <antrik> to get even close to monolithic systems, we need either a way to
-      account server resources used on client's behalf, or to make servers use
-      client-provided resources. both require changes in the IPC mechanism I
-      think...
-    <antrik> (though *if* we go for the latter option, the CPU scheduling
-      changes of migrating threads would of course be necessary, in addition to
-      any changes regarding memory management...)
-    <antrik> slpz: BTW, I didn't get the point about io_read and COW...
-    <slpz> antrik: AFAIK, the FS cache (which is our primary concern) in most
-      monolithic system is agnostic with respect the users, and only deals with
-      absolute numbers. In our case we can do almost the same by combining Mach
-      and pagers knowledege.
-    <antrik> slpz: my primary concern is that anything program having a hiccup
-      crashes the system... and I'm not sure this can be properly fixed without
-      working memory accounting
-    <antrik> (I guess in can be worked around to some extent by introducing
-      various static limits on processes... but I'm not sure how well)
-    <antrik> it can
-    <slpz> antrik: monolithic system also suffer that problem (remember fork
-      bombs) and it's "solved" by imposing static limits to user processes
-      (ulimit).
-    <slpz> antrik: we do have more problems due to port management, but I think
-      some degree of control can be archieved with a reasonably amount of
-      changes.
-    <antrik> slpz: in a client-server architecture static limits are much less
-      effective... that problem exists on traditional systems too, but only in
-      some specific cases (such as X server); while on a microkernel system
-      it's ubiquitous... that's why we need a *better* solution to this problem
-      to get anywhere close to monolithic systems
diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn
deleted file mode 100644
index 171dc7a0..00000000
--- a/open_issues/packaging_libpthread.mdwn
+++ /dev/null
@@ -1,236 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012 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_libpthread open_issue_glibc]]
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2010-07-31
-
-    <tschwinge> My idea was to have a separate libpthread package.  What do you
-      think about that?
-    <youpi> in the long term, that can't work with glibc
-    <youpi> because of the thread stub stuff
-
-[[libpthread_dlopen]], for example.
-
-    <youpi> it's not really possible to keep synchronized
-    <youpi> because you have to decide which package you unpack first
-    <youpi> (when upgrading)
-    <tschwinge> Hmm, how is that different if two shared libraries are in one
-      package vs. two packages?  It isn't atomic either way?  Aren't sonames /
-      versioned library packages solving that?
-    <tschwinge> ... for incompatible forward changes?
-    <youpi> that'd be a mess to maintain
-    <youpi> Drepper doesn't have this constraint and thus adds members of
-      private fields at will
-    <tschwinge> OK, but how is it different then if the libpthread is in the
-      Hurd package?
-    <youpi> I'm not saying it's better to have libpthread in the Hurd package
-    <tschwinge> OK.
-    <youpi> I'm saying it's useless to package it separately when Drepper makes
-      everything to have us put it along glibc
-    <tschwinge> Then, to goal is to have it in glibc?
-    <tschwinge> OK.   :-)
-    <tschwinge> OK, I can accommodate to that.  Isn't not that we'd want to
-      switch libpthread to something else so quickly.
-    <tschwinge> So our official goal is to have libpthread in glibc, at least
-      for Debian purposese?
-    <youpi> for any port purpose
-    <tschwinge> Ack.
-    <youpi> provided you're using glibc, you're deemed to ship libpthread with
-      it
-    <youpi> because of the strong relations Drepper puts between them
-    <youpi> (just to remind: we already have bugs just because our current
-      libpthread isn't bound enough to glibc: dlopen()ing a library depending
-      on libpthread doesn't work, for instance)
-    <pinotree> yeah, pthread-stubs is linked to almost everywhere -lpthread
-      isn't used
-    <pinotree> (would be nice to not have those issues anymore...)
-    <tschwinge> So -- what do we need to put it into glibc?  We can make
-      libpthread a Git submodule (or move the code; but it's shared also for
-      Neal's viengoos, so perhaps the submodule is better?), plus some glibc
-      make foo, plus some other adaptions (stubs, etc.)
-    <tschwinge> Does that sound about right, or am I missing something
-      fundamental?
-    <youpi> I actually don't know what a git submodule permits :)
-    <youpi> looks like a good thing for this, yes
-    <tschwinge> Unfortunately I can't allocate much time at the moment to work
-      on this.  :-/
-    <youpi> well, as long as I know where we're going, I can know how to
-      package stuff in Debian
-    <tschwinge> That sounds like a plan to me.  libpthread -> glibc as
-      submodule.
-    <youpi> (note: actually, the interface between glibc and the libpthread is
-      the responsibility of the libpthread: it gives a couple of .c files to be
-      shipped in libc.so)
-
-
-# IRC, freenode, #hurd, 2012-04-21
-
-    <youpi> had you tried to build libpthread as a glibc addon?
-    <tschwinge> youpi: No, I only know about libpthread in Hurd build system,
-      and libpthread stand-alone (with the Auto* stuff that I added), but not
-      yet as a glibc add-on.
-    <youpi> k
-    <youpi> I'm trying it atm
-    <tschwinge> Oh, OK.
-    <youpi> that should fix the no-add-needed issue in gcc/binutils, as well as
-      the pthread_threads assertion errors in threaded plugins
-    <youpi> (once I add forward.c, but that part should not be hard)
-    <pinotree> that means also less use of pthread-stubs^
-    <pinotree> ?
-    <youpi> tschwinge: do you remember whether sysdeps/mach/bits/spin* are used
-      by anybody?
-    <youpi> they are half-finished (no __PTHREAD_SPIN_LOCK_INITIALIZER), and
-      come in the way when building in glibc
-    <youpi> pinotree: rid of pthread-stubs yes
-    <pinotree> \o/
-    <tschwinge> youpi: You mean sysdeps/mach/i386/machine-lock.h?  No idea
-      about that one, sorry.
-    <youpi> I'm talking about libpthread
-    <youpi> not glibc
-    <tschwinge> Oh.
-    <tschwinge> sysdeps/i386/bits/spin-lock.h:# define
-      __PTHREAD_SPIN_LOCK_INITIALIZER ((__pthread_spinlock_t) 0)
-    <tschwinge> Anyway, no idea about that either.
-    <youpi> that one is meant to be used with the spin-lock.h just below
-    <youpi> +-inline
-    <youpi> also, I guess signal/ was for the l4 port?
-    <tschwinge> youpi: I guess so.
-    <youpi> tschwinge: I have an issue with sysdeps pt files:
-      sysdeps/hurd/pt-getspecific.c is not looked for by libc ; symlinking into
-      sysdeps/mach/hurd/pt-getspecific.c works
-    <youpi> we don't have a non-mach sysdeps directory?
-    <pinotree> youpi: if you add sysdeps/mach/hurd/Implies containing only
-      "hurd", does sysdeps/hurd work?
-    <youpi> ah, right
-    <pinotree> youpi: did it work? (and, it was needed in sysdeps/mach/hurd, or
-      in libpthread/sysdeps/mach/hurd?)
-    <youpi> pinotree: it worked, it was for libpthread
-    <youpi> good: I got libpthread built and forward working
-
-
-## IRC, freenode, #hurd, 2012-04-23
-
-    <youpi> phew
-    <youpi> confirmed that moving libpthread to glibc fixes the gcc/binutils
-      no-add-needed issue
-
-
-## IRC, freenode, #hurd, 2012-08-07
-
-    <tschwinge> Also, the Savannah hurd/glibc.git one does not/not yet include
-      libpthread.
-    <tschwinge> But that could easily be added as a Git submodule.
-    <tschwinge> youpi: To put libpthread into glibc it is literally enough to
-      make Savannah hurd/libpthread.git appear at [glibc]/libpthread?
-    <youpi> tschwinge: there are some patches needed in the rest of the tree
-    <youpi> see in debian, libpthread_clean.diff, tg-libpthread_depends.diff,
-      unsubmitted-pthread.diff, unsubmitted-pthread_posix_options.diff
-    <tschwinge> The libpthread in Debian glibc is
-      hurd/libpthread.git:b428baaa85c0adca9ef4884c637f289a0ab5e2d6 but with
-      25260994c812050a5d7addf125cdc90c911ca5c1 »Store self in __thread variable
-      instead of threadvar« reverted (why?), [...]
-
-..., and 549aba4335946c26f2701c2b43be0e6148d27c09 »Fix libpthread.so symlink«
-cherry-picked.
-
-    <braunr> tschwinge: is there any plan to merge libpthread.git in glibc.git
-      upstream ?
-    <tschwinge> braunr, youpi: Has not yet been discussed with Roland, as far
-      as I know.
-    <youpi> has not
-    <youpi> libpthread.diff is supposed to be a verbatim copy of the repository
-    <youpi> and then there are a couple patches which don't (yet) make sense
-      upstream
-
-
-## IRC, OFTC, #debian-hurd, 2013-02-08
-
-    <tschwinge> I also have it on my (never-ending) agenda to add libpthread to
-      the tschwinge/Roger_Whittaker branch and/or propose it be added upstream
-      (as a Git submodule?).
-    <pinotree> imho a git submodule could be a solution, if glibc people would
-      accept it
-    <pinotree> if so, libpthread.git would need proper glibc/x.y branches to
-      follow glibc
-    <tschwinge> Yep.
-    <tschwinge> I though that would be the least invasive approach for glibc
-      upstream -- and quite convenient for us, too.
-    <pinotree> after all, git submodules don't track branches, but point to
-      specific commits, no?
-    <tschwinge> Correct.
-    <tschwinge> So we can do locally/in Debian whatever we want, and every once
-      in a while update the upstream glibc commit ID for libpthread.
-    <pinotree> so we could update the git submodule references in glibc when
-      we've tested enough libpthread changes
-    <tschwinge> Just like when committing patches upstream, just without
-      pestering them with all the patches/commits.
-    <tschwinge> Yep.
-
-
-# IRC, freenode, #hurd, 2012-11-16
-
-    <pinotree> *** $(common-objpfx)resolv/gai_suspend.o: uses
-      /usr/include/i386-gnu/bits/pthread.h
-    <pinotree> so the ones in the libpthread addon are not used...
-    <tschwinge> pinotree: The latter at leash should be useful information.
-    <pinotree> tschwinge: i'm afraid i didn't get you :) what are you referring
-      to?
-    <tschwinge> pinotree: s%leash%least -- what I mean was the it's actually a
-      real bug that not the in-tree libpthread addon include files are being
-      used.
-    <pinotree> tschwinge: ah sure -- basically, the stuff in
-      libpthread/sysdeps/generic are not used at all
-    <pinotree> (glibc only uses generic for glibc/sysdeps/generic)
-    <pinotree> tschwinge: i might have an idea how to fix it: moving the
-      contents from libpthread/sysdeps/generic to libpthread/sysdeps/pthread,
-      and that would depend on one of the latest libpthread patches i sent
-
-
-# libihash
-
-## IRC, freenode, #hurd, 2012-11-16
-
-    <pinotree> also, libpthread uses hurd's ihash
-    <tschwinge> Yes, I already thought a little bit about the ihash thing.  I
-      besically see two options: move ihash into glibc ((probably?) not as a
-      public interface, though), or have libpthread use of of the hash
-      implementations that surely are already present in glibc.
-    <tschwinge> My notes say:
-    <tschwinge>       * include/inline-hashtab.h
-    <tschwinge>       * locale/programs/simple-hash.h
-    <tschwinge>       * misc/hsearch_r.c
-    <tschwinge>       * NNS; cf. f46f0abfee5a2b34451708f2462a1c3b1701facd
-    <tschwinge> No idea whether they're equivalent/usable.
-    <pinotree> interesting
-    <tschwinge> And no immediate recollection what NNS is;
-      f46f0abfee5a2b34451708f2462a1c3b1701facd is not a glibc commit after all.
-      ;-)
-    <tschwinge> Oh, and: libiberty: `hashtab.c`
-    <pinotree> hmm, but then you would need to properly ifdef the libpthread
-      hash usage (iirc only for pthread keys) depending on whether it's in
-      glibc or standalone
-    <pinotree> but that shouldn't be an ussue, i guess
-    <pinotree> *issue
-    <tschwinge> No that'd be fine.
-    <tschwinge> My understanding is that the long-term goal (well, no so
-      long-term, actually) is to completely move libpthread into glibc.
-    <pinotree> ie have it buildable only ad glibc addon?
-    <tschwinge> Yes.
-    <tschwinge> No need for more than one mechanism for building it, I think.
-    <tschwinge> Hmm, this doesn't bring us any further:
-      https://www.google.com/search?q=f46f0abfee5a2b34451708f2462a1c3b1701facd
-    <pinotree> yay for acronyms ;)
-    <tschwinge> So, if someone figures out what NNS and this commit it are: one
-      beer.  ;-)
diff --git a/open_issues/page_cache.mdwn b/open_issues/page_cache.mdwn
deleted file mode 100644
index fd503fdc..00000000
--- a/open_issues/page_cache.mdwn
+++ /dev/null
@@ -1,79 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012 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_gnumach]]
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2011-11-28
-
-    <braunr> youpi: would you find it reasonable to completely disable the page
-      cache in gnumach ?
-    <braunr> i'm wondering if it wouldn't help make the system more stable
-      under memory pressure
-    <youpi> assuming cache=writeback in gnumach?
-    <youpi> because disabling the page cache will horribly hit performance
-    <braunr> no, it doesn't have anything to do with the host
-    <braunr> i'm not so sure
-    <braunr> while observing the slab allocator, i noticed our page cache is
-      not used that often
-    <youpi> eeh?
-    <youpi> apart from the damn 4000 limitation, I've seen it used
-    <youpi> (and I don't  why it wouldn't be used)
-    <youpi> (e.g. for all parts of libc)
-    <youpi> ah, no, libc would be kept open by ext2fs
-    <braunr> taht's precisely because of the 4k limit
-    <youpi> but e.g. .o file emitted during make
-    <braunr> well, no
-    <youpi> well, see the summary I had posted some time ago, the 4k limit
-      makes it completely randomized
-    <youpi> and thus you lose locality
-    <braunr> yes
-    <youpi> but dropping the limit would just fix it
-    <braunr> that's my point
-    <youpi> which I had tried to do, and there were issues, you mentioned why
-    <youpi> and (as usual), I haven't had anyu time to have a look at the issue
-      again
-    <braunr> i'm just trying to figure out the pros and cons for having teh
-      current page cache implementation
-    <braunr> but are you saying you tried with a strict limit of 0 ?
-    <youpi> non, I'm saying I tried with no limit
-    <youpi> but then memory fills up
-    <braunr> yes
-    <youpi> so trying to garbage collect
-    <braunr> i tried that too, the system became unstable very quickly
-    <youpi> but refs don't falldown to 0, you said
-    <braunr> did i ?
-    <youpi> or maybe somebody else
-    <youpi> see the list archives
-    <braunr> that's possible
-    <braunr> i'd imagine someone like sergio lopez
-    <youpi> possibly
-    <youpi> somebody that knows memory stuff way better than me in any case
-    <braunr> youpi: i'm just wondering how much we'd loose by disabling the
-      page cache, and if we actually gain more stability (and ofc, if it's
-      worth it)
-    <youpi> no idea, measures will tell
-    <youpi> fixing the page cache shouldn't be too hard I believe, however
-    <youpi> you just need to know what you are doing, which I don't
-    <youpi> I do believe the cache is still at least a bit useful
-    <youpi> even if dumb because of randomness
-    <youpi> e.g. running make lib in the glibc tree gets faster on second time
-    <youpi> because the cache wouldbe filled at least randomly with glibc tree
-      stuff
-    <braunr> yes, i agree on that
-    <youpi> braunr: btw, the current stability is fine for the buildds
-    <youpi> restarting them every few days is ok
-    <youpi> so I'd rather keep the performance :)
-    <braunr> ok
-
-
-# [[gnumach_page_cache_policy]]
diff --git a/open_issues/pci_arbiter.mdwn b/open_issues/pci_arbiter.mdwn
deleted file mode 100644
index 7730cee0..00000000
--- a/open_issues/pci_arbiter.mdwn
+++ /dev/null
@@ -1,256 +0,0 @@
-[[!meta copyright="Copyright © 2012 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_hurd]]
-
-For [[DDE]]/X.org/...
-
-
-# IRC, freenode, #hurd, 2012-02-19
-
-    <youpi> antrik: we should probably add a gsoc idea on pci bus arbitration
-    <youpi> DDE is still experimental for now so it's ok that you  have to
-      configure it by hand, but it should be automatic at some ponit
-
-
-## IRC, freenode, #hurd, 2012-02-21
-
-    <braunr> i'm not familiar with the new gnumach interface for userspace
-      drivers, but can this pci enumerator be written with it as it is ?
-    <braunr> (i'm not asking for a precise answer, just yes - even probably -
-      or no)
-    <braunr> (idk or utsl will do as well)
-    <youpi> I'd say yes
-    <youpi> since all drivers need is interrupts, io ports and iomem
-    <youpi> the latter was already available through /dev/mem
-    <youpi> io ports through the i386 rpcs
-    <youpi> the changes provide both interrupts, and physical-contiguous
-      allocation
-    <youpi> it should be way enough
-    <braunr> youpi: ok
-    <braunr> youpi: thanks for the details :)
-    <antrik> braunr: this was mentioned in the context of the interrupt
-      forwarding interface... the original one implemented by zhengda isn't
-      suitable for a PCI server; but the ones proposed by youpi and tschwinge
-      would work
-    <antrik> same for the physical memory interface: the current implementation
-      doesn't allow delegation; but I already said that it's wrong
-
-
-# IRC, freenode, #hurd, 2012-07-15
-
-    <bddebian> youpi: Oh, BTW, I keep meaning to ask you.  Could sound be done
-      with dde or would there still need to be some kernel work?
-    <youpi> bddebian: we'd need a PCI arbitrer for that
-    <youpi> for now just one userland poking with PCI is fine
-    <youpi> but two can produce bonks
-    <bddebian> They can't use the same?
-    <youpi> that's precisely the matter
-    <youpi> they have to use the same
-    <youpi> and not poke with it themselves
-    <braunr> that's what an arbiter is for
-    <bddebian> OK, so if we don't have a PCI arbiter now, how do things like
-      netdde and video not collide currently?
-    <bddebian> s/netdde/network/
-    <bddebian> or disk for that matter
-    <braunr> bddebian: ah currently, well currently, the network is the only
-      thing using the pci bus
-    <bddebian> How is that possible when I have a PCI video card and disk
-      controller?
-    <braunr> they are accessed through compatible means
-    <bddebian> I suppose one of the hardest parts is prioritization?
-    <braunr> i don't think it matters much, no
-    <youpi> bddebian: netdde and Xorg don't collide essentially because they
-      are not started at the same time (hopefully)
-    <bddebian> braunr: What do you mean it doesn't matter?
-    <braunr> bddebian: well the point is rather serializing access, we don't
-      need more
-    <braunr> do other systems actually schedule access to the pci bus ?
-    <bddebian> From what I am reading, yes
-    <braunr> ok
-
-
-# IRC, freenode, #hurd, 2012-07-16
-
-    <antrik> youpi: the lack of a PCI arbiter is a problem, but I wounldn't
-      consider it a precondition for adding another userspace driver
-      class... it's up to the user to make sure he has only one class active,
-      or take the risk of not doing so...
-    <antrik> (plus, I suspect writing the arbiter is a smaller task than
-      implementing another DDE class anyways...)
-    <bddebian> Where would the arbiter need to reside, in gnumach?
-    <antrik> bddebian: kernel would be one possible place (with the advantage
-      of running both userspace and kernel drivers without the potential for
-      conflicts)
-    <antrik> but I think I would prefer a userspace server
-    <youpi> antrik: we'd rather have PCI devices automatically set up
-    <youpi> just like /dev/netdde is already set up for the user
-    <youpi> so you can't count on the user
-    <youpi> for the arbitrer, it could as well be userland, while still
-      interacting with the kernel for some devices
-    <youpi> we however "just" need to get disk drivers in userland to drop PCI
-      drivers from kernel, actually
-
-
-# IRC, freenode, #hurd, 2012-07-17
-
-    <bddebian> youpi: So this PCI arbiter should be a hurd server?
-    <youpi> that'd be better
-    <bddebian> youpi: Is there anything existing to look at as a basis?
-    <youpi> no idea off-hand
-    <bddebian> I mean you couldn't take what netdde does and generalize it?
-    <youpi> netdde doesn't do any arbitration
-
-
-# IRC, OFTC, #debian-hurd, 2012-07-19
-
-    <bdefreese> youpi: Well at some point if you ever have time I'd like to
-      understand better how you see the PCI architecture working in Hurd.
-      I.E. would you expect the server to do enumeration and arbitration?
-    <youpi> I'd expect both, yes, but that's probably to be discussed rather
-      with antrik, he's the one who took some time to think about it
-    <bdefreese> netdde uses libpciaccess currently, right?
-    <youpi> yes
-    <youpi> libpciaccess would have to be fixed into using the arbitrer
-    <youpi> (that'd fix xorg as well)
-    <bdefreese> Man, I am still a bit unclear on how this all interacting
-      currently.. :(
-    <youpi> currently it's not
-    <youpi> and it's just by luck that it doesn't break
-    <bdefreese> Long term xxxdde would use the new server, correct?
-    <youpi> (well, we are also sure that the gnumach enumeration comes always
-      before the netdde enumeration, and xorg is currently not started
-      automatically, so its enumeration is also always after that)
-    <youpi> yes
-    <youpi> the server would essentially provide an interface equivalent to
-      libpciaccess
-    <bdefreese> Right
-    <bdefreese> In general, where does the pci map get "stored"?  In GNU/Linux,
-      is it all /proc based?
-    <youpi> what do you mean by "pci map" ?
-    <bdefreese> Once I have enumerated all of the buses and devices, does it
-      stay stored or is it just redone for every call to a pci device?
-    <youpi> in linux it's stored in the kernel
-    <youpi> the abritrator would store it itself
-
-
-# IRC, freenode, #hurd, 2012-07-20
-
-    <bddebian> antrik: BTW, youpi says you are the one to talk to for design of
-      a PCI server :)
-    <antrik> oh, am I?
-    * antrik feels honoured :-)
-    <antrik> I guess it's true though: I *did* spent a little thought on
-      it... even mentioned something in my thesis IIRC
-    <antrik> there is one tricky aspect to it though, which I'm not sure how to
-      handle best: we need two different instances of libpciaccess
-    <bddebian> Why two instances of libpciaccess?
-    <antrik> one used by the PCI server to access the hardware directly (using
-      the existing port poking backend), and one using a new backend to access
-      our PCI server...
-    <braunr> bddebian: hum, both i guess ?
-    <bddebian> antrik: Why wouldn't the server access the hardware directly?  I
-      thought libpciaccess was supposed to be generic on purpose?
-    <antrik> hm... guess I wasn't clear
-    <antrik> the point is that the PCI server should use the direct hardware
-      access backend of libpciaccess
-    <antrik> however, *clients* should use the PCI server backend of
-      libpciaccess
-    <antrik> I'm not sure backends can be selected at runtime...
-    <antrik> which might mean that we actually have to compile two different
-      versions of the library. erk.
-    <bddebian> So you are saying the pci server should itself use libpci access
-      rather than having it's own?
-    <antrik> admittedly, that's not the most fundamental design decision to
-      make ;-)
-    <antrik> bddebian: yes. no need to rewrite (or copy) this code...
-    <bddebian> Hmm
-    <antrik> actually that was the plan all along when I first suggested
-      implementing the register poking backend for libpciaccess
-    <bddebian> Hmm, not sure I like it but I am certainly in no position to
-      question it right now :)
-    <braunr> why don't you like it ?
-    <bddebian> I shouldn't need an Xorg specific library to access PCI on my OS
-      :)
-    <braunr> oh
-    <bddebian> Though I don't disagree that reinventing the wheel is a bit
-      tedious. :)
-    <antrik> bddebian: although it originates from X.Org, I don't think there
-      is anything about the library technically making it X-specific...
-    <braunr> yes that's my opinion too
-    <antrik> (well, there are some X-specific functions IIRC, but these do not
-      hurt the other functionality)
-    <bddebian> But what is there is api/abi breakage? :)
-    <bddebian> s/is/if/
-    <antrik> BTW according to rdepends there appear to be a number of non-X
-      things using the library now
-    <pinotree> like, uhm, hurd
-    <antrik> yeah, that too... we are already using it for DDE
-    <pinotree> if you have deb-src lines in your sources.list, use the
-      grep-dctrl power:
-    <pinotree> grep-dctrl -sPackage -FBuild-Depends libpciaccess-dev
-      /var/lib/apt/lists/*_source_Sources | sort -u
-    <bddebian> I know we are using it for netdde.
-    <antrik> nice thing about it is that once we have the PCI server and an
-      appropriate backend for libpciaccess, the same netdde and X binaries
-      should work either with or without the PCI server
-    <bddebian> Then why have the server at all?
-    <braunr> it's the arbiter
-    <braunr> you can use the library directly only if you're the only user
-    <braunr> and what antrik means is that the interface should be the same for
-      both modes
-    <bddebian> Ugh, that is where I am getting confused
-    <bddebian> In that case shouldn't everything use libpciaccess and the PCI
-      server has to arbitrate the requests?
-    <braunr> bd	?
-    <braunr> bddebian: yes
-    <braunr> bddebian: but they use the indirect version of the library
-    <braunr> whereas the server uses the raw version
-    <bddebian> OK, I gotcha (I think)
-    <braunr> (but they both provide the same interface, so if you don't have a
-      pci server and you know you're the only user, the direct version can be
-      used)
-    <bddebian> But I am not sure I see the difference between creating a second
-      library or just moving the raw access to the PCI server :)
-    <braunr> uh, there is no difference in that
-    <braunr> and you shouldn't do it
-    <braunr> (if that's what antrik meant at least)
-    <braunr> if you can select the backend (raw or pci server) easily, then
-      stick to the same code base
-    <bddebian> That's where I struggle.  In my worthless opinion, raw access
-      should be the OS job while indirect access would be the libraries
-      responsibility
-    <braunr> that's true
-    <braunr> but as an optimization, if an application is the only user, it can
-      directly use raw access
-    <bddebian> How would you know that?
-    <bddebian> I'm sorry if these are dumb questions
-    <braunr> hum, don't try to make this behaviour automatic
-    <braunr> it would be selected by the user through command line switches
-    <bddebian> But the OS itself uses PCI for things like disk access and
-      video, no?
-    <braunr> (it could be automatic but it makes things more complicated)
-    <braunr> you don't need an arbiter all the time
-    <braunr> i can't tell you more, wait for antrik to return
-    <braunr> i realize i might already have said some bullshit
-    <antrik> bddebian: well, you have a point there that once we have the
-      arbiter and use it for everthing, it isn't strictly useful to still have
-      the register poking in the library
-    <antrik> however, the code will remain in the library anyways, so we better
-      continue using it rather than introducing redundancy...
-    <antrik> but again, that's rather a side issue concerning the design of the
-      PCI server
-    <bddebian> antrik: Fair enough. :)  So how would I even start on this?
-    <antrik> bddebian: actually, libpciaccess is a good starting point:
-      checking the API should give you a fairly good idea what functionality
-      the server needs to implement
-    <pinotree> (+1 on library (re)use)
-    <bddebian> antrik: KK
-    <antrik> sorry, I'm a bit busy right now...
diff --git a/open_issues/performance.mdwn b/open_issues/performance.mdwn
deleted file mode 100644
index 64b245f2..00000000
--- a/open_issues/performance.mdwn
+++ /dev/null
@@ -1,260 +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]]."]]"""]]
-
-*Performance analysis* ([[!wikipedia Performance_analysis desc="Wikipedia
-article"]]) deals with analyzing how computing resources are used for
-completing a specified task.
-
-[[Profiling]] is one relevant tool.
-
-In [[microkernel]]-based systems, there is generally a considerable [[RPC]]
-overhead.
-
-In a multi-server system, it is non-trivial to implement a high-performance
-[[I/O System|community/gsoc/project_ideas/disk_io_performance]].
-
-When providing [[faq/POSIX_compatibility]] (and similar interfaces) in an
-environemnt that doesn't natively implement these interfaces, there may be a
-severe performance degradation.  For example, in this [[`fork` system
-call|/glibc/fork]]'s case.
-
-[[Unit_testing]] can be used for tracking performance regressions.
-
----
-
-  * [[Degradation]]
-
-  * [[fork]]
-
-  * [[IPC_virtual_copy]]
-
-  * [[microbenchmarks]]
-
-  * [[microkernel_multi-server]]
-
-  * [[gnumach_page_cache_policy]]
-
-  * [[metadata_caching]]
-
-  * [[community/gsoc/project_ideas/object_lookups]]
-
----
-
-
-# IRC, freenode, #hurd, 2012-07-05
-
-    <braunr> the more i study the code, the more i think a lot of time is
-      wasted on cpu, unlike the common belief of the lack of performance being
-      only due to I/O
-
-
-## IRC, freenode, #hurd, 2012-07-23
-
-    <braunr> there are several kinds of scalability issues
-    <braunr> iirc, i found some big locks in core libraries like libpager and
-      libdiskfs
-    <braunr> but anyway we can live with those
-    <braunr> in the case i observed, ext2fs, relying on libdiskfs and libpager,
-      scans the entire file list to ask for writebacks, as it can't know if the
-      pages are dirty or not
-    <braunr> the mistake here is moving part of the pageout policy out of the
-      kernel
-    <braunr> so it would require the kernel to handle periodic synces of the
-      page cache
-    <antrik> braunr: as for big locks: considering that we don't have any SMP
-      so far, does it really matter?...
-    <braunr> antrik: yes
-    <braunr> we have multithreading
-    <braunr> there is no reason to block many threads while if most of them
-      could continue
-    <braunr> -while
-    <antrik> so that's more about latency than throughput?
-    <braunr> considering sleeping/waking is expensive, it's also about
-      throughput
-    <braunr> currently, everything that deals with sleepable locks (both
-      gnumach and the hurd) just wake every thread waiting for an event when
-      the event occurs (there are a few exceptions, but not many)
-    <antrik> ouch
-
-
-## [[!message-id "20121202101508.GA30541@mail.sceen.net"]]
-
-
-## IRC, freenode, #hurd, 2012-12-04
-
-    <damo22> why do some people think hurd is slow? i find it works well even
-      under heavy load inside a virtual machine
-    <braunr> damo22: the virtual machine actually assists the hurd a lot :p
-    <braunr> but even with that, the hurd is a slow system
-    <damo22> i would have thought it would have the potential to be very fast,
-      considering the model of the kernel
-    <braunr> the design implies by definition more overhead, but the true cause
-      is more than 15 years without optimization on the core components
-    <braunr> how so ?
-    <damo22> since there are less layers of code between the hardware bare
-      metal and the application that users run
-    <braunr> how so ? :)
-    <braunr> it's the contrary actually
-    <damo22> VFS -> IPC -> scheduler -> device drivers -> hardware
-    <damo22> that is monolithic
-    <braunr> well, it's not really meaningful
-    <braunr> and i'd say the same applies for a microkernel system
-    <damo22> if the application can talk directly to hardware through the
-      kernel its almost like plugging directly into the hardware
-    <braunr> you never talk directly to hardware
-    <braunr> you talk to servers instead of the kernel
-    <damo22> ah
-    <braunr> consider monolithic kernel systems like systems with one big
-      server
-    <braunr> the kernel
-    <braunr> whereas a multiserver system is a kernel and many servers
-    <braunr> you still need the VFS to identify your service (and thus your
-      server)
-    <braunr> you need much more IPC, since system calls are "replaced" with RPC
-    <braunr> the scheduler is basically the same
-    <damo22> okay
-    <braunr> device drivers are similar too, except they run in thread context
-      (which is usually a bit heavier)
-    <damo22> but you can do cool things like report when an interrupt line is
-      blocked
-    <braunr> and there are many context switches between all that
-    <braunr> you can do all that in a monolithic kernel too, and faster
-    <braunr> but it's far more elegant, and (when well done) easy to do on a
-      microkernel based system
-    <damo22> yes
-    <damo22> i like elegant, makes coding easier if you know the basics
-    <braunr> there are only two major differences between a monolilthic kernel
-      and a multiserver microkernel system
-    * damo22 listens
-    <braunr> 1/ independence of location (your resources could be anywhere)
-    <braunr> 2/ separation of address spaces (your servers have their own
-      addresses)
-    <damo22> wow
-    <braunr> these both imply additional layers of indirection, making the
-      system as a whole slower
-    <damo22> but it would be far more secure though i suspect
-    <braunr> yes
-    <braunr> and reliable
-    <braunr> that's why systems like qnx were usually adopted for critical
-      tasks
-    <damo22> security and reliability are very important, i would switch to the
-      hurd if it supported all the hardware i use 
-    <braunr> so would i :)
-    <braunr> but performance matters too
-    <damo22> not to me
-    <braunr> it should :p
-    <braunr> it really does matter a lot in practice
-    <damo22> i mean, a 2x slowdown compared to linux would not affect me
-    <damo22> if it had all the benefits we mentioned above
-    <braunr> but the hurd is really slow for other reasons than its additional
-      layers of indrection unfortunately
-    <damo22> is it because of lack of optimisation in the core code?
-    <braunr> we're working on these issues, but it's not easy and takes a lot
-      of time :p
-    <damo22> like you said
-    <braunr> yes
-    <braunr> and also because of some fundamental design choices related to the
-      microkernel back in the 80s
-    <damo22> what about the darwin system
-    <damo22> it uses a mach kernel?
-    <braunr> yes
-    <damo22> what is stopping someone taking the MIT code from darwin and
-      creating a monster free OS
-    <braunr> what for ?
-    <damo22> because it already has hardware support
-    <damo22> and a mach kernel
-    <braunr> in kernel drivers ?
-    <damo22> it has kernel extensions
-    <damo22> you can do things like kextload module
-    <braunr> first, being a mach kernel doesn't make it compatible or even
-      easily usable with the hurd, the interfaces have evolved independantly
-    <braunr> and second, we really do want more stuff out of the kernel
-    <braunr> drivers in particular
-    <damo22> may i ask why you are very keen to have drivers out of kernel?
-    <braunr> for the same reason we want other system services out of the
-      kernel
-    <braunr> security, reliability, etc..
-    <braunr> ease of debugging
-    <braunr> the ability to restart drivers separately, without restarting the
-      kernel
-    <damo22> i see
-
-
-# IRC, freenode, #hurd, 2012-09-13
-
-{{$news/2011-q2#phoronix-3}}.
-
-    <braunr> the phoronix benchmarks don't actually test the operating system
-      ..
-    <hroi_> braunr: well, at least it tests its ability to run programs for
-      those particular tasks
-    <braunr> exactly, it tests how programs that don't make much use of the
-      operating system run
-    <braunr> well yes, we can run programs :)
-    <pinotree> those are just cpu-taking tasks
-    <hroi_> ok
-    <pinotree> if you do a benchmark with also i/o, you can see how it is
-      (quite) slower on hurd
-    <hroi_> perhaps they should have run 10 of those programs in parallel, that
-      would test the kernel multitasking I suppose
-    <braunr> not even I/O, simply system calls
-    <braunr> no, multitasking is ok on the hurd
-    <braunr> and it's very similar to what is done on other systems, which
-      hasn't changed much for a long time
-    <braunr> (except for multiprocessor)
-    <braunr> true OS benchmarks measure system calls
-    <hroi_> ok, so Im sensing the view that the actual OS kernel architecture
-      dont really make that much difference, good software does
-    <braunr> not at all
-    <braunr> i'm only saying that the phoronix benchmark results are useless
-    <braunr> because they didn't measure the right thing
-    <hroi_> ok
-
-
-# Optimizing Data Structure Layout
-
-## IRC, freenode, #hurd, 2014-01-02
-
-    <braunr> teythoon_: wow, digging into the vm code :)
-    <teythoon_> i discovered pahole and gnumach was a tempting target :)
-    <braunr> never heard of pahole :/
-    <teythoon_> it's nice
-    <teythoon_> braunr: try pahole -C kmem_cache /boot/gnumach
-    <teythoon_> on linux that is. ...
-    <braunr> ok
-    <teythoon_> braunr: http://paste.debian.net/73864/
-    <braunr> very nice
-
-
-## IRC, freenode, #hurd, 2014-01-03
-
-    <braunr> teythoon: pahole is a very handy tool :)
-    <teythoon> yes
-    <teythoon> i especially like how general it is
-
-
-# Measurement
-
-## coulomb
-
-### [[!message-id "87wqghouoc.fsf@schwinge.name"]]
-
-## IRC, freenode, #hurd, 2014-02-27
-
-    <braunr> tschwinge: about your concern with regard to performance
-      measurements, you could run kvm with hugetlbfs and cpuset
-    <braunr> on a machine that provides nested page tables, this makes the
-      virtualization overhead as small as it could be considering the
-      implementatoin
-    <braunr> hugetlbs reduces the overhead of page faults, and also implies
-      locked memory while cpuset isolates the vm from global scheduling
-    <braunr> hugetlbfs*
-    <tschwinge> Thanks, will look into that.
diff --git a/open_issues/performance/degradation.mdwn b/open_issues/performance/degradation.mdwn
deleted file mode 100644
index 1aaae4d2..00000000
--- a/open_issues/performance/degradation.mdwn
+++ /dev/null
@@ -1,52 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012 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]]."]]"""]]
-
-[[!meta title="Degradation of GNU/Hurd ``system performance''"]]
-
-[[!tag open_issue_gnumach open_issue_hurd]]
-
-[[!toc]]
-
-
-# Email, [[!message-id "87mxg2ahh8.fsf@kepler.schwinge.homeip.net"]] (bug-hurd, 2011-07-25, Thomas Schwinge)
-
-> Building a certain GCC configuration on a freshly booted system: 11 h.
-> Remove build tree, build it again (2nd): 12 h 50 min.  Huh.  Remove build
-> tree, reboot, build it again (1st): back to 11 h.  Remove build tree, build
-> it again (2nd): 12 h 40 min.  Remove build tree, build it again (3rd): 15 h.
-
-IRC, freenode, #hurd, 2011-07-23:
-
-    < antrik> tschwinge: yes, the system definitely gets slower with
-      time. after running for a couple of weeks, it needs at least twice as
-      long to open a new shell for example
-    < antrik> I don't know whether this is only related to swap usage, or there
-      are some serious fragmentation issues
-    < braunr> antrik: both could be induced by fragmentation
-
-
-# During [[IPC_virtual_copy]] testing
-
-IRC, freenode, #hurd, 2011-09-02:
-
-    <manuel> interestingly, running it several times has made the performance
-      drop quite much (i'm getting 400-500MB/s with 1M now, compared to nearly
-      800 fifteen minutes ago)
-    <braunr> manuel: i observed the same behaviour
-    [...]
-
-
-# IRC, freenode, #hurd, 2011-09-22
-
-See [[/open_issues/resource_management_problems/pagers]], IRC, freenode, #hurd,
-2011-09-22.
-
-
-# [[ext2fs_page_cache_swapping_leak]]
diff --git a/open_issues/performance/fork.mdwn b/open_issues/performance/fork.mdwn
deleted file mode 100644
index 5ceb6455..00000000
--- a/open_issues/performance/fork.mdwn
+++ /dev/null
@@ -1,37 +0,0 @@
-[[!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]]
-
-Our [[`fork` implementation|glibc/fork]] is nontrivial.
-
-To do: hard numbers.
-[[Microbenchmarks]]?
-
-
-# Windows / Cygwin
-
-  * <http://www.google.com/search?q=cygwin+fork>
-
-  * <http://www.redhat.com/support/wpapers/cygnus/cygnus_cygwin/architecture.html>
-
-    In particular, *5.6. Process Creation*.
-
-  * <http://archive.gamedev.net/community/forums/topic.asp?topic_id=360290>
-
-  * <http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/how-cygheap-works.txt?cvsroot=src>
-
-    > Cygwin has recently adopted something called the "cygwin heap".  This is
-    > an internal heap that is inherited by forked/execed children.  It
-    > consists of process specific information that should be inherited.  So
-    > things like the file descriptor table, the current working directory, and
-    > the chroot value live there.
-
-  * <http://www.perlmonks.org/?node_id=588994>
diff --git a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn
deleted file mode 100644
index 931fd0ee..00000000
--- a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn
+++ /dev/null
@@ -1,39 +0,0 @@
-[[!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_hurd]]
-
-This one may be considered as a testcase for [[I/O system
-optimization|community/gsoc/project_ideas/disk_io_performance]].
-
-It is taken from the [[binutils testsuite|binutils]],
-`ld/ld-elf/sec64k.exp`, where this
-test may occasionally [[trigger a timeout|binutils#64ksec]].  It is
-extracted from cdf7c161ebd4a934c9e705d33f5247fd52975612 sources, 2010-10-24.
-
-    $ wget -O - http://www.gnu.org/software/hurd/open_issues/performance/io_system/binutils_ld_64ksec/test.tar.xz | xz -d | tar -x
-    $ cd test/
-    $ \time ./ld-new.stripped -o dump dump?.o dump??.o
-    0.00user 0.00system 2:46.11elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
-    0inputs+0outputs (0major+0minor)pagefaults 0swaps
-
-On the idle grubber, this one repeatedly takes a few minutes wall time to
-complete successfully, contrary to a few seconds on a GNU/Linux system.
-
-While processing the object files, there is heavy interaction with the relevant
-[[hurd/translator/ext2fs]] process.  Running [[hurd/debugging/rpctrace]] on
-the testee shows that (primarily) an ever-repeating series of `io_seek` and
-`io_read` is being processed.  Running the testee on GNU/Linux with strace
-shows the equivalent thing (`_llseek`, `read`) -- but Linux' I/O system isn't
-as slow as the Hurd's.
-
-As Samuel figured out later, this slowness may in fact be due to a Xen-specific
-issue, see [[Xen_lseek]].  After the latter has been addressed, we can
-re-evaluate this issue here.
diff --git a/open_issues/performance/io_system/clustered_page_faults.mdwn b/open_issues/performance/io_system/clustered_page_faults.mdwn
deleted file mode 100644
index 8bd6ba72..00000000
--- a/open_issues/performance/io_system/clustered_page_faults.mdwn
+++ /dev/null
@@ -1,165 +0,0 @@
-[[!meta copyright="Copyright © 2011, 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_gnumach open_issue_hurd]]
-
-[[community/gsoc/project_ideas/disk_io_performance]].
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2011-02-16
-
-    <braunr> exceptfor the kernel, everything in an address space is
-      represented with a VM object
-    <braunr> those objects can represent anonymous memory (from malloc() or
-      because of a copy-on-write)
-    <braunr> or files
-    <braunr> on classic Unix systems, these are files
-    <braunr> on the Hurd, these are memory objects, backed by external pagers
-      (like ext2fs)
-    <braunr> so when you read a file
-    <braunr> the kernel maps it from ext2fs in your address space
-    <braunr> and when you access the memory, a fault occurs
-    <braunr> the kernel determines it's a region backed by ext2fs
-    <braunr> so it asks ext2fs to provide the data
-    <braunr> when the fault is resolved, your process goes on
-    <etenil> does the faul occur because Mach doesn't know how to access the
-      memory?
-    <braunr> it occurs because Mach intentionnaly didn't back the region with
-      physical memory
-    <braunr> the MMU is programmed not to know what is present in the memory
-      region
-    <braunr> or because it's read only
-    <braunr> (which is the case for COW faults)
-    <etenil> so that means this bit of memory is a buffer that ext2fs loads the
-      file into and then it is remapped to the application that asked for it
-    <braunr> more or less, yes
-    <braunr> ideally, it's directly written into the right pages
-    <braunr> there is no intermediate buffer
-    <etenil> I see
-    <etenil> and as you told me before, currently the page faults are handled
-      one at a time
-    <etenil> which wastes a lot of time
-    <braunr> a certain amount of time
-    <etenil> enough to bother the user :)
-    <etenil> I've seen pages have a fixed size
-    <braunr> yes
-    <braunr> use the PAGE_SIZE macro
-    <etenil> and when allocating memory, the size that's asked for is rounded
-      up to the page size
-    <etenil> so if I have this correctly, it means that a file ext2fs provides
-      could be split into a lot of pages
-    <braunr> yes
-    <braunr> once in memory, it is managed by the page cache
-    <braunr> so that pages more actively used are kept longer than others
-    <braunr> in order to minimize I/O
-    <etenil> ok
-    <braunr> so a better page cache code would also improve overall performance
-    <braunr> and more RAM would help a lot, since we are strongly limited by
-      the 768 MiB limit
-    <braunr> which reduces the page cache size a lot
-    <etenil> but the problem is that reading a whole file in means trigerring
-      many page faults just for one file
-    <braunr> if you want to stick to the page clustering thing, yes
-    <braunr> you want less page faults, so that there are less IPC between the
-      kernel and the pager
-    <etenil> so either I make pages bigger
-    <etenil> or I modify Mach so it can check up on a range of pages for faults
-      before actually processing
-    <braunr> you *don't* change the page size
-    <etenil> ah
-    <etenil> that's hardware isn't it?
-    <braunr> in Mach, yes
-    <etenil> ok
-    <braunr> and usually, you want the page size to be the CPU page size
-    <etenil> I see
-    <braunr> current CPU can support multiple page sizes, but it becomes quite
-      hard to correctly handle
-    <braunr> and bigger page sizes mean more fragmentation, so it only suits
-      machines with large amounts of RAM, which isn't the case for us
-    <etenil> ok
-    <etenil> so I'll try the second approach then
-    <braunr> that's what i'd recommand
-    <braunr> recommend*
-    <etenil> ok
-
-
-# IRC, freenode, #hurd, 2011-02-16
-
-    <antrik> etenil: OSF Mach does have clustered paging BTW; so that's one
-      place to start looking...
-    <antrik> (KAM ported the OSF code to gnumach IIRC)
-    <antrik> there is also an existing patch for clustered paging in libpager,
-      which needs some adaptation
-    <antrik> the biggest part of the task is probably modifying the Hurd
-      servers to use the new interface
-    <antrik> but as I said, KAM's code should be available through google, and
-      can serve as a starting point
-
-<http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00023.html>
-
-
-# IRC, freenode, #hurd, 2011-07-22
-
-    <braunr> but concerning clustered pagins/outs, i'm not sure it's a mach
-      interface limitation
-    <braunr> the external memory pager interface does allow multiple pages to
-      be transfered
-    <braunr> isn't it an internal Mach VM problem ?
-    <braunr> isn't it simply the page fault handler ?
-    <antrik> braunr: are you sure? I was under the impression that changing the
-      pager interface was among the requirements...
-    <antrik> hm... I wonder whether for pageins, it could actually be handled
-      in the pages instead of Mach... though this wouldn't work for pageouts,
-      so probably not very helpful
-    <antrik> err... in the pagers
-    <braunr> antrik: i'm almost sure
-    <braunr> but i've be proven wrong many times, so ..
-    <braunr> there are two main facts that lead me to think this
-    <braunr> 1/
-      http://www.gnu.org/software/hurd/gnumach-doc/Memory-Objects-and-Data.html#Memory-Objects-and-Data
-      says lengths are provided and doesn't mention the limitation
-    <braunr> 2/ when reading about UVM, one of the major improvements (between
-      10 and 30% of global performance depending on the benchmarks) was
-      implementing the madvise semantics
-    <braunr> and this didn't involve a new pager interface, but rather a new
-      page fault handler
-    <antrik> braunr: hm... the interface indeed looks like it can handle
-      multiple pages in both directions... perhaps it was at the Hurd level
-      where the pager interface needs to be modified, not the Mach one?...
-    <braunr> antrik: would be nice wouldn't it ? :)
-    <braunr> antrik: more probably the page fault handler
-
-
-# IRC, freenode, #hurd, 2011-09-28
-
-    <slpz> antrik: I've just recovered part of my old multipage I/O work
-    <slpz> antrik: I intend to clean and submit it after finishing the changes
-      to the pageout system.
-    <antrik> slpz: oh, great!
-    <antrik> didn't know you worked on multipage I/O
-    <antrik> slpz: BTW, have you checked whether any of the work done for GSoC
-      last year is any good?...
-    <antrik> (apart from missing copyright assignments, which would be a
-      serious problem for the Hurd parts...)
-    <slpz> antrik: It was seven years ago, but I did:
-      http://www.mail-archive.com/bug-hurd@gnu.org/msg10285.html :-)
-    <slpz> antrik: Sincerely, I don't think the quality of that code is good
-      enough to be considered... but I think it was my fault as his mentor for
-      not correcting him soon enough...
-    <antrik> slpz: I see
-    <antrik> TBH, I feel guilty myself, for not asking about the situation
-      immediately when he stopped attending meetings...
-    <antrik> slpz: oh, you even already looked into vm_pageout_scan() back then
-      :-)
-
-
-# [[Read-Ahead]]
diff --git a/open_issues/performance/io_system/read-ahead.mdwn b/open_issues/performance/io_system/read-ahead.mdwn
deleted file mode 100644
index 59f22187..00000000
--- a/open_issues/performance/io_system/read-ahead.mdwn
+++ /dev/null
@@ -1,3076 +0,0 @@
-[[!meta copyright="Copyright © 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_gnumach open_issue_hurd]]
-
-[[!toc]]
-
-
-# [[community/gsoc/project_ideas/disk_io_performance]]
-
-
-# [[gnumach_page_cache_policy]]
-
-
-# 2011-02
-
-[[Etenil]] has been working in this area.
-
-
-## IRC, freenode, #hurd, 2011-02-13
-
-    <etenil> youpi: Would libdiskfs/diskfs.h be in the right place to make
-      readahead functions?
-    <youpi> etenil: no, it'd rather be at the memory management layer,
-      i.e. mach, unfortunately
-    <youpi> because that's where you see the page faults
-    <etenil> youpi: Linux also provides a readahead() function for higher level
-      applications. I'll probably have to add the same thing in a place that's
-      higher level than mach
-    <youpi> well, that should just be hooked to the same common implementation
-    <etenil> the man page for readahead() also states that portable
-      applications should avoid it, but it could be benefic to have it for
-      portability
-    <youpi> it's not in posix indeed
-
-
-## IRC, freenode, #hurd, 2011-02-14
-
-    <etenil> youpi: I've investigated prefetching (readahead) techniques. One
-      called DiskSeen seems really efficient. I can't tell yet if it's patented
-      etc. but I'll keep you informed
-    <youpi> don't bother with complicated techniques, even the most simple ones
-      will be plenty :)
-    <etenil> it's not complicated really
-    <youpi> the matter is more about how to plug it into mach
-    <etenil> ok
-    <youpi> then don't bother with potential pattents
-    <antrik> etenil: please take a look at the work KAM did for last year's
-      GSoC
-    <youpi> just use a trivial technique :)
-    <etenil> ok, i'll just go the easy way then
-
-    <braunr> antrik: what was etenil referring to when talking about
-      prefetching ?
-    <braunr> oh, madvise() stuff
-    <braunr> i could help him with that
-
-
-## IRC, freenode, #hurd, 2011-02-15
-
-    <etenil> oh, I'm looking into prefetching/readahead to improve I/O
-      performance
-    <braunr> etenil: ok
-    <braunr> etenil: that's actually a VM improvement, like samuel told you
-    <etenil> yes
-    <braunr> a true I/O improvement would be I/O scheduling
-    <braunr> and how to implement it in a hurdish way
-    <braunr> (or if it makes sense to have it in the kernel)
-    <etenil> that's what I've been wondering too lately
-    <braunr> concerning the VM, you should look at madvise()
-    <etenil> my understanding is that Mach considers devices without really
-      knowing what they are
-    <braunr> that's roughly the interface used both at the syscall() and the
-      kernel levels in BSD, which made it in many other unix systems
-    <etenil> whereas I/O optimisations are often hard disk drives specific
-    <braunr> that's true for almost any kernel
-    <braunr> the device knowledge is at the driver level
-    <etenil> yes
-    <braunr> (here, I separate kernels from their drivers ofc)
-    <etenil> but Mach also contains some drivers, so I'm going through the code
-      to find the apropriate place for these improvements
-    <braunr> you shouldn't tough the drivers at all
-    <braunr> touch
-    <etenil> true, but I need to understand how it works before fiddling around
-    <braunr> hm
-    <braunr> not at all
-    <braunr> the VM improvement is about pagein clustering
-    <braunr> you don't need to know how pages are fetched
-    <braunr> well, not at the device level
-    <braunr> you need to know about the protocol between the kernel and
-      external pagers
-    <etenil> ok
-    <braunr> you could also implement pageout clustering
-    <etenil> if I understand you well, you say that what I'd need to do is a
-      queuing system for the paging in the VM?
-    <braunr> no
-    <braunr> i'm saying that, when a page fault occurs, the kernel should
-      (depending on what was configured through madvise()) transfer pages in
-      multiple blocks rather than one at a time
-    <braunr> communication with external pagers is already async, made through
-      regular ports
-    <braunr> which already implement message queuing
-    <braunr> you would just need to make the mapped regions larger
-    <braunr> and maybe change the interface so that this size is passed
-    <etenil> mmh
-    <braunr> (also don't forget that page clustering can include pages *before*
-      the page which caused the fault, so you may have to pass the start of
-      that region too)
-    <etenil> I'm not sure I understand the page fault thing
-    <etenil> is it like a segmentation error?
-    <etenil> I can't find a clear definition in Mach's manual
-    <braunr> ah
-    <braunr> it's a fundamental operating system concept
-    <braunr> http://en.wikipedia.org/wiki/Page_fault
-    <etenil> ah ok
-    <etenil> I understand now
-    <etenil> so what's currently happening is that when a page fault occurs,
-      Mach is transfering pages one at a time and wastes time 
-    <braunr> sometimes, transferring just one page is what you want
-    <braunr> it depends on the application, which is why there is madvise()
-    <braunr> our rootfs, on the other hand, would benefit much from such an
-      improvement
-    <braunr> in UVM, this optimization is account for around 10% global
-      performance improvement
-    <braunr> accounted*
-    <etenil> not bad
-    <braunr> well, with an improved page cache, I'm sure I/O would matter less
-      on systems with more RAM
-    <braunr> (and another improvement would make mach support more RAM in the
-      first place !)
-    <braunr> an I/O scheduler outside the kernel would be a very good project
-      IMO
-    <braunr> in e.g. libstore/storeio
-    <etenil> yes
-    <braunr> but as i stated in my thesis, a resource scheduler should be as
-      close to its resource as it can
-    <braunr> and since mach can host several operating systems, I/O schedulers
-      should reside near device drivers
-    <braunr> and since current drivers are in the kernel, it makes sens to have
-      it in the kernel too
-    <braunr> so there must be some discussion about this
-    <etenil> doesn't this mean that we'll have to get some optimizations in
-      Mach and have the same outside of Mach for translators that access the
-      hardware directly?
-    <braunr> etenil: why ?
-    <etenil> well as you said Mach contains some drivers, but in principle, it
-      shouldn't, translators should do disk access etc, yes?
-    <braunr> etenil: ok
-    <braunr> etenil: so ?
-    <etenil> well, let's say if one were to introduce SATA support in Hurd,
-      nothing would stop him/her to do so with a translator rather than in Mach
-    <braunr> you should avoid the term translator here
-    <braunr> it's really hurd specific
-    <braunr> let's just say a user space task would be responsible for that
-      job, maybe multiple instances of it, yes
-    <etenil> ok, so in this case, let's say we have some I/O optimization
-      techniques like readahead and I/O scheduling within Mach, would these
-      also apply to the user-space task, or would they need to be
-      reimplemented?
-    <braunr> if you have user space drivers, there is no point having I/O
-      scheduling in the kernel
-    <etenil> but we also have drivers within the kernel
-    <braunr> what you call readahead, and I call pagein/out clustering, is
-      really tied to the VM, so it must be in Mach in any case
-    <braunr> well
-    <braunr> you either have one or the other
-    <braunr> currently we have them in the kernel
-    <braunr> if we switch to DDE, we should have all of them outside
-    <braunr> that's why such things must be discussed
-    <etenil> ok so if I follow you, then future I/O device drivers will need to
-      be implemented for Mach
-    <braunr> currently, yes
-    <braunr> but preferrably, someone should continue the work that has been
-      done on DDe so that drivers are outside the kernel
-    <etenil> so for the time being, I will try and improve I/O in Mach, and if
-      drivers ever get out, then some of the I/O optimizations will need to be
-      moved out of Mach
-    <braunr> let me remind you one of the things i said
-    <braunr> i said I/O scheduling should be close to their resource, because
-      we can host several operating systems
-    <braunr> now, the Hurd is the only system running on top of Mach
-    <braunr> so we could just have I/O scheduling outside too
-    <braunr> then you should consider neighbor hurds
-    <braunr> which can use different partitions, but on the same device
-    <braunr> currently, partitions are managed in the kernel, so file systems
-      (and storeio) can't make good scheduling decisions if it remains that way
-    <braunr> but that can change too
-    <braunr> a single storeio representing a whole disk could be shared by
-      several hurd instances, just as if it were a high level driver
-    <braunr> then you could implement I/O scheduling in storeio, which would be
-      an improvement for the current implementation, and reusable for future
-      work
-    <etenil> yes, that was my first instinct
-    <braunr> and you would be mostly free of the kernel internals that make it
-      a nightmare
-    <etenil> but youpi said that it would be better to modify Mach instead
-    <braunr> he mentioned the page clustering thing
-    <braunr> not I/O scheduling
-    <braunr> theseare really two different things
-    <etenil> ok
-    <braunr> you *can't* implement page clustering outside Mach because Mach
-      implements virtual memory
-    <braunr> both policies and mechanisms
-    <etenil> well, I'd rather think of one thing at a time if that's alright
-    <etenil> so what I'm busy with right now is setting up clustered page-in
-    <etenil> which need to be done within Mach
-    <braunr> keep clustered page-outs in mind too
-    <braunr> although there are more constraints on those
-    <etenil> yes
-    <etenil> I've looked up madvise(). There's a lot of documentation about it
-      in Linux but I couldn't find references to it in Mach (nor Hurd), does it
-      exist?
-    <braunr> well, if it did, you wouldn't be caring about clustered page
-      transfers, would you ?
-    <braunr> be careful about linux specific stuff
-    <etenil> I suppose not
-    <braunr> you should implement at least posix options, and if there are
-      more, consider the bsd variants
-    <braunr> (the Mach VM is the ancestor of all modern BSD VMs)
-    <etenil> madvise() seems to be posix
-    <braunr> there are system specific extensions
-    <braunr> be careful
-    <braunr> CONFORMING TO POSIX.1b.   POSIX.1-2001 describes posix_madvise(3)
-      with constants POSIX_MADV_NORMAL, etc., with a behav‐ ior close to that
-      described here.  There is a similar posix_fadvise(2) for file access.
-    <braunr> MADV_REMOVE, MADV_DONTFORK, MADV_DOFORK, MADV_HWPOISON,
-      MADV_MERGEABLE, and MADV_UNMERGEABLE  are  Linux- specific.
-    <etenil> I was about to post these
-    <etenil> ok, so basically madvise() allows tasks etc. to specify a usage
-      type for a chunk of memory, then I could apply the relevant I/O
-      optimization based on this
-    <braunr> that's it
-    <etenil> cool, then I don't need to worry about knowing what the I/O is
-      operating on, I just need to apply the optimizations as advised
-    <etenil> that's convenient
-    <etenil> ok I'll start working on this tonight
-    <etenil> making a basic readahead shouldn't be too hard
-    <braunr> readahead is a misleading name
-    <etenil> is pagein better?
-    <braunr> applies to too many things, doesn't include the case where
-      previous elements could be prefetched
-    <braunr> clustered page transfers is what i would use
-    <braunr> page prefetching maybe
-    <etenil> ok
-    <braunr> you should stick to something that's already used in the
-      literature since you're not inventing something new
-    <etenil> yes I've read a paper about prefetching
-    <etenil> ok
-    <etenil> thanks for your help braunr
-    <braunr> sure
-    <braunr> you're welcome
-    <antrik> braunr: madvise() is really the least important part of the
-      picture...
-    <antrik> very few applications actually use it. but pretty much all
-      applications will profit from clustered paging
-    <antrik> I would consider madvise() an optional goody, not an integral part
-      of the implementation
-    <antrik> etenil: you can find some stuff about KAM's work on
-      http://www.gnu.org/software/hurd/user/kam.html
-    <antrik> not much specific though
-    <etenil> thanks
-    <antrik> I don't remember exactly, but I guess there is also some
-      information on the mailing list. check the archives for last summer
-    <antrik> look for Karim Allah Ahmed
-    <etenil> antrik: I disagree, madvise gives me a good starting point, even
-      if eventually the optimisations should run even without it
-    <antrik> the code he wrote should be available from Google's summer of code
-      page somewhere...
-    <braunr> antrik: right, i was mentioning madvise() because the kernel (VM)
-      interface is pretty similar to the syscall
-    <braunr> but even a default policy would be nice
-    <antrik> etenil: I fear that many bits were discussed only on IRC... so
-      you'd better look through the IRC logs from last April onwards...
-    <etenil> ok
-
-    <etenil> at the beginning I thought I could put that into libstore
-    <etenil> which would have been fine
-
-    <antrik> BTW, I remembered now that KAM's GSoC application should have a
-      pretty good description of the necessary changes... unfortunately, these
-      are not publicly visible IIRC :-(
-
-
-## IRC, freenode, #hurd, 2011-02-16
-
-    <etenil> braunr: I've looked in the kernel to see where prefetching would
-      fit best. We talked of the VM yesterday, but I'm not sure about it. It
-      seems to me that the device part of the kernel makes more sense since
-      it's logically what manages devices, am I wrong?
-    <braunr> etenil: you are
-    <braunr> etenil: well
-    <braunr> etenil: drivers should already support clustered sector
-      read/writes
-    <etenil> ah
-    <braunr> but yes, there must be support in the drivers too
-    <braunr> what would really benefit the Hurd mostly concerns page faults, so
-      the right place is the VM subsystem
-
-[[clustered_page_faults]]
-
-
-# 2012-03
-
-
-## IRC, freenode, #hurd, 2012-03-21
-
-    <mcsim> I thought that readahead should have some heuristics, like
-      accounting size of object and last access time, but i didn't find any in
-      kam's patch. Are heuristics needed or it will be overhead for
-      microkernel? 
-    <youpi> size  of object and last access time are not necessarily useful to
-      take into account
-    <youpi> what would usually typically be kept is the amount of contiguous
-      data that has been read lately
-    <youpi> to know whether it's random or sequential, and how much is read
-    <youpi> (the whole size of the object does not necessarily give any
-      indication of how much of it will be read)
-    <mcsim> if big object is accessed often, performance could be increased if
-      frame that will be read ahead will be increased too.
-    <youpi> yes, but the size of the object really does not matter
-    <youpi> you can just observe how much data is read and realize that it's
-      read a lot
-    <youpi> all the more so with userland fs translators
-    <youpi> it's not because you mount a CD image that you need to read it all
-    <mcsim> youpi: indeed. this will be better. But on other hand there is
-      principle about policy and mechanism. And kernel should implement
-      mechanism, but heuristics seems to be policy. Or in this case moving
-      readahead policy to user level would be overhead?
-    <antrik> mcsim: paging policy is all in kernel anyways; so it makes perfect
-      sense to put the readahead policy there as well
-    <antrik> (of course it can be argued -- probably rightly -- that all of
-      this should go into userspace instead...)
-    <mcsim> antrik: probably defpager partly could do that. AFAIR, it is
-      possible for defpager to return more memory than was asked.
-    <mcsim> antrik: I want to outline what should be done during gsoc. First,
-      kernel should support simple readahead for specified number of pages
-      (regarding direction of access) + simple heuristic for changing frame
-      size. Also default pager could make some analysis, for instance if it has
-      many data located consequentially it could return more data then was
-      asked. For other pagers I won't do anything. Is it suitable?
-    <antrik> mcsim: I think we actually had the same discussion already with
-      KAM ;-)
-    <antrik> for clustered pageout, the kernel *has* to make the decision. I'm
-      really not convinced it makes sense to leave the decision for clustered
-      pagein to the individual pagers
-    <antrik> especially as this will actually complicate matters because a) it
-      will require work in *every* pager, and b) it will probably make handling
-      of MADVISE & friends more complex
-    <antrik> implementing readahead only for the default pager would actually
-      be rather unrewarding. I'm pretty sure it's the one giving the *least*
-      benefit
-    <antrik> it's much, much more important for ext2
-    <youpi> mcsim: maybe try to dig in the irc logs, we discussed about it with
-      neal. the current natural place would be the kernel, because it's the
-      piece that gets the traps and thus knows what happens with each
-      projection, while the backend just provides the pages without knowing
-      which projection wants it. Moving to userland would not only be overhead,
-      but quite difficult
-    <mcsim> antrik: OK, but I'm not sure that I could do it for ext2. 
-    <mcsim> OK, I'll dig.
-
-
-## IRC, freenode, #hurd, 2012-04-01
-
-    <mcsim> as part of implementing of readahead project I have to add
-      interface for setting appropriate behaviour for memory range.  This
-      interface than should be compatible with madvise call, that has a lot of
-      possible advises, but most part of them are specific for Linux (according
-      to man page). Should mach also support these Linux-specific values?
-    <mcsim> p.s. these Linux-specific values shouldn't affect readahead
-      algorithm.
-    <youpi> the interface shouldn't prevent from adding them some day
-    <youpi> so that we don't have to add them yet
-    <mcsim> ok. And what behaviour with value MADV_NORMAL should be look like?
-      Seems that it should be synonym to MADV_SEQUENTIAL, isn't it?
-    <youpi> no, it just means "no idea what it is"
-    <youpi> in the linux implementation, that means some given readahead value
-    <youpi> while SEQUENTIAL means twice as much
-    <youpi> and RANDOM means zero
-    <mcsim> youpi: thank you.
-    <mcsim> youpi: Than, it seems to be better that kernel interface for
-      setting behaviour will accept readahead value, without hiding it behind
-      such constants, like VM_BEHAVIOR_DEFAULT (like it was in kam's
-      patch). And than implementation of madvise will call vm_behaviour_set
-      with appropriate frame size. Is that right?
-    <youpi> question of taste, better ask on the list
-    <mcsim> ok
-
-
-## IRC, freenode, #hurd, 2012-06-09
-
-    <mcsim> hello. What fictitious pages in gnumach are needed for?
-    <mcsim> I mean why real page couldn't be grabbed straight, but in sometimes
-      fictitious page is grabbed first and than converted to real?
-    <braunr> mcsim: iirc, fictitious pages are needed by device pagers which
-      must comply with the vm pager interface
-    <braunr> mcsim: specifically, they must return a vm_page structure, but
-      this vm_page describes device memory
-    <braunr> mcsim: and then, it must not be treated like normal vm_page, which
-      can be added to page queues (e.g. page cache)
-
-
-## IRC, freenode, #hurd, 2012-06-22
-
-    <mcsim> braunr: Ah. Patch for large storages introduced new callback
-      pager_notify_evict. User had to define this callback on his own as
-      pager_dropweak, for instance. But neal's patch change this. Now all
-      callbacks could have any name, but user defines structure with pager ops
-      and supplies it in pager_create.
-    <mcsim> So, I just changed notify_evict to confirm it to new style.
-    <mcsim> braunr: I want to changed interface of mo_change_attributes and
-      test my changes with real partitions. For both these I have to update
-      ext2fs translator, but both partitions I have are bigger than 2Gb, that's
-      why I need apply this patch.z
-    <mcsim> But what to do with mo_change_attributes? I need somehow inform
-      kernel about page fault policy.
-    <mcsim> When I change mo_ interface in kernel I have to update all programs
-      that use this interface and ext2fs is one of them.
-
-    <mcsim> braunr: Who do you think better to inform kernel about fault
-      policy? At the moment I've added fault_strategy parameter that accepts
-      following strategies: randow, sequential with single page cluster,
-      sequential with double page cluster and sequential with quad page
-      cluster. OSF/mach has completely another interface of
-      mo_change_attributes. In OSF/mach mo_change_attributes accepts structure
-      of parameter. This structure could have different formats depending o
-    <mcsim> This rpc could be useful because it is not very handy to update
-      mo_change_attributes for kernel, for hurd libs and for glibc. Instead of
-      this kernel will accept just one more structure format.
-    <braunr> well, like i wrote on the mailing list several weeks ago, i don't
-      think the policy selection is of concern currently
-    <braunr> you should focus on the implementation of page clustering and
-      readahead
-    <braunr> concerning the interface, i don't think it's very important
-    <braunr> also, i really don't like the fact that the policy is per object
-    <braunr> it should be per map entry
-    <braunr> i think it mentioned that in my mail too
-    <braunr> i really think you're wasting time on this
-    <braunr> http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00064.html
-    <braunr> http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00029.html
-    <braunr> mcsim: any reason you completely ignored those ?
-    <mcsim> braunr: Ok. I'll do clustering for map entries.
-    <braunr> no it's not about that either :/
-    <braunr> clustering is grouping several pages in the same transfer between
-      kernel and pager
-    <braunr> the *policy* is held in map entries
-    <antrik> mcsim: I'm not sure I properly understand your question about the
-      policy interface... but if I do, it's IMHO usually better to expose
-      individual parameters as RPC arguments explicitly, rather than hiding
-      them in an opaque structure...
-    <antrik> (there was quite some discussion about that with libburn guy)
-    <mcsim> antrik: Following will be ok? kern_return_t vm_advice(map, address,
-      length, advice, cluster_size)
-    <mcsim> Where advice will be either random or sequential
-    <antrik> looks fine to me... but then, I'm not an expert on this stuff :-)
-    <antrik> perhaps "policy" would be clearer than "advice"?
-    <mcsim> madvise has following prototype: int madvise(void *addr, size_t
-      len, int advice);
-    <mcsim> hmm... looks like I made a typo. Or advi_c_e is ok too?
-    <antrik> advise is a verb; advice a noun... there is a reason why both
-      forms show up in the madvise prototype :-)
-    <mcsim> so final variant should be kern_return_t vm_advise(map, address,
-      length, policy, cluster_size)?
-    <antrik> mcsim: nah, you are probably right that its better to keep
-      consistency with madvise, even if the name of the "advice" parameter
-      there might not be ideal...
-    <antrik> BTW, where does cluster_size come from? from the filesystem?
-    <antrik> I see merits both to naming the parameter "policy" (clearer) or
-      "advice" (more consistent) -- you decide :-)
-    <mcsim> antrik: also there is variant strategy, like with inheritance :)
-      I'll choose advice for now.
-    <mcsim> What do you mean under "where does cluster_size come from"?
-    <antrik> well, madvise doesn't have this parameter; so the value must come
-      from a different source?
-    <mcsim> in madvise implementation it could fixed value or somehow
-      calculated basing on size of memory range. In OSF/mach cluster size is
-      supplied too (via mo_change_attributes).
-    <antrik> ah, so you don't really know either :-)
-    <antrik> well, my guess is that it is derived from the cluster size used by
-      the filesystem in question
-    <antrik> so for us it would always be 4k for now
-    <antrik> (and thus you can probably leave it out alltogether...)
-    <antrik> well, fatfs can use larger clusters
-    <antrik> I would say, implement it only if it's very easy to do... if it's
-      extra effort, it's probably not worth it
-    <mcsim> There is sense to make cluster size bigger for ext2 too, since most
-      likely consecutive clusters will be within same group.
-    <mcsim> But anyway I'll handle this later.
-    <antrik> well, I don't know what cluster_size does exactly; but by the
-      sound of it, I'd guess it makes an assumption that it's *always* better
-      to read in this cluster size, even for random access -- which would be
-      simply wrong for 4k filesystem clusters...
-    <antrik> BTW, I agree with braunr that madvice() is optional -- it is way
-      way more important to get readahead working as a default policy first
-
-
-## IRC, freenode, #hurd, 2012-07-01
-
-    <mcsim> youpi: Do you think you could review my code?
-    <youpi> sure, just post it to the list
-    <youpi> make sure to break it down into logical pieces
-    <mcsim> youpi: I pushed it my branch at gnumach repository
-    <mcsim> youpi: or it is still better to post changes to list?
-    <youpi> posting to the list would permit feedback from other people too
-    <youpi> mcsim: posix distinguishes normal, sequential and random
-    <youpi> we should probably too
-    <youpi> the system call should probably be named "vm_advise", to be a verb
-      like allocate etc.
-    <mcsim> youpi: ok. A have a talk with antrik regarding naming, I'll change
-      this later because compiling of glibc take a lot of time.
-    <youpi> mcsim: I find it odd that vm_for_every_page allocates non-existing
-      pages
-    <youpi> there should probably be at least a flag to request it or not
-    <mcsim> youpi: normal policy is synonym to default. And this could be
-      treated as either random or sequential, isn't it?
-    <braunr> mcsim: normally, no
-    <youpi> yes, the normal policy would be the default
-    <youpi> it doesn't mean random or sequential
-    <youpi> it's just to be a compromise between both
-    <youpi> random is meant to make no read-ahead, since that'd be spurious
-      anyway
-    <youpi> while by default we should make readahead
-    <braunr> and sequential makes even more aggressive readahead, which usually
-      implies a greater number of pages to fetch
-    <braunr> that's all
-    <youpi> yes
-    <youpi> well, that part is handled by the cluster_size parameter actually
-    <braunr> what about reading pages preceding the faulted paged ?
-    <mcsim> Shouldn't sequential clean some pages (if they, for example, are
-      not precious) that are placed before fault page?
-    <braunr> ?
-    <youpi> that could make sense, yes
-    <braunr> you lost me
-    <youpi> and something that you wouldn't to with the normal policy
-    <youpi> braunr: clear what has been read previously
-    <braunr> ?
-    <youpi> since the access is supposed to be sequential
-    <braunr> oh
-    <youpi> the application will proabably not re-read what was already read
-    <braunr> you mean to avoid caching it ?
-    <youpi> yes
-    <braunr> inactive memory is there for that
-    <youpi> while with the normal policy you'd assume that the application
-      might want to go back etc.
-    <youpi> yes, but you can help it
-    <braunr> yes
-    <youpi> instead of making other pages compete with it
-    <braunr> but then, it's for precious pages
-    <youpi> I have to say I don't know what a precious page it
-    <youpi> s
-    <youpi> does it mean dirty pages?
-    <braunr> no
-    <braunr> precious means cached pages
-    <braunr> "If precious is FALSE, the kernel treats the data as a temporary
-      and may throw it away if it hasn't been changed. If the precious value is
-      TRUE, the kernel treats its copy as a data repository and promises to
-      return it to the manager; the manager may tell the kernel to throw it
-      away instead by flushing and not cleaning the data"
-    <braunr> hm no
-    <braunr> precious means the kernel must keep it
-    <mcsim> youpi: According to vm_for_every_page. What kind of flag do you
-      suppose? If object is internal, I suppose not to cross the bound of
-      object, setting in_end appropriately in vm_calculate_clusters.
-    <mcsim> If object is external we don't know its actual size, so we should
-      make mo request first. And for this we should create fictitious  pages.
-    <braunr> mcsim: but how would you implement this "cleaning" with sequential
-      ?
-    <youpi> mcsim: ah, ok, I thought you were allocating memory, but it's just
-      fictitious pages
-    <youpi> comment "Allocate a new page" should be fixed :)
-    <mcsim> braunr: I don't now how I will implement this specifically (haven't
-      tried yet), but I don't think that this is impossible
-    <youpi> braunr: anyway it's useful as an example where normal and
-      sequential would be different
-    <braunr> if it can be done simply
-    <braunr> because i can see more trouble than gains in there :)
-    <mcsim> braunr: ok :)
-    <braunr> mcsim: hm also, why fictitious pages ?
-    <braunr> fictitious pages should normally be used only when dealing with
-      memory mapped physically which is not real physical memory, e.g. device
-      memory
-    <mcsim> but vm_fault could occur when object represent some device memory.
-    <braunr> that's exactly why there are fictitious pages
-    <mcsim> at the moment of allocating of fictitious page it is not know what
-      backing store of object is.
-    <braunr> really ?
-    <braunr> damn, i've got used to UVM too much :/
-    <mcsim> braunr: I said something wrong?
-    <braunr> no no
-    <braunr> it's just that sometimes, i'm confusing details about the various
-      BSD implementations i've studied
-    <braunr> out-of-gsoc-topic question: besides network drivers, do you think
-      we'll have other drivers that will run in userspace and have to implement
-      memory mapping ? like framebuffers ?
-    <braunr> or will there be a translation layer such as storeio that will
-      handle mapping ?
-    <youpi> framebuffers typically will, yes
-    <youpi> that'd be antrik's work on drm
-    <braunr> hmm
-    <braunr> ok
-    <youpi> mcsim: so does the implementation work, and do you see performance
-      improvement?
-    <mcsim> youpi: I haven't tested it yet with large ext2 :/
-    <mcsim> youpi: I'm going to finish now moving of ext2 to new interface,
-      than other translators in hurd repository and than finish memory policies
-      in gnumach. Is it ok?
-    <youpi> which new interface?
-    <mcsim> Written by neal. I wrote some temporary code to make ext2 work with
-      it, but I'm going to change this now.
-    <youpi> you mean the old unapplied patch?
-    <mcsim> yes
-    <youpi> did you have a look at Karim's work?
-    <youpi> (I have to say I never found the time to check how it related with
-      neal's patch)
-    <mcsim> I found only his work in kernel. I didn't see his work in applying
-      of neal's patch.
-    <youpi> ok
-    <youpi> how do they relate with each other?
-    <youpi> (I have never actually looked at either of them :/)
-    <mcsim> his work in kernel and neal's patch?
-    <youpi> yes
-    <mcsim> They do not correlate with each other.
-    <youpi> ah, I must be misremembering what each of them do
-    <mcsim> in kam's patch was changes to support sequential reading in reverse
-      order (as in OSF/Mach), but posix does not support such behavior, so I
-      didn't implement this either.
-    <youpi> I can't find the pointer to neal's patch, do you have it off-hand?
-    <mcsim> http://comments.gmane.org/gmane.os.hurd.bugs/351
-    <youpi> thx
-    <youpi> I think we are not talking about the same patch from Karim
-    <youpi> I mean lists.gnu.org/archive/html/bug-hurd/2010-06/msg00023.html
-    <mcsim> I mean this patch:
-      http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00024.html 
-    <mcsim> Oh.
-    <youpi> ok
-    <mcsim> seems, this is just the same
-    <youpi> yes
-    <youpi> from a non-expert view, I would have thought these patches play
-      hand in hand, do they really?
-    <mcsim> this patch is completely for kernel and neal's one is completely
-      for libpager.
-    <youpi> i.e. neal's fixes libpager, and karim's fixes the kernel
-    <mcsim> yes
-    <youpi> ending up with fixing the whole path?
-    <youpi> AIUI, karim's patch will be needed so that your increased readahead
-      will end up with clustered page request?
-    <mcsim> I will not use kam's patch
-    <youpi> is it not needed to actually get pages in together?
-    <youpi> how do you tell libpager to fetch pages together?
-    <youpi> about the cluster size, I'd say it shouldn't be specified at
-      vm_advise() level
-    <youpi> in other OSes, it is usually automatically tuned
-    <youpi> by ramping it up to a maximum readahead size (which, however, could
-      be specified)
-    <youpi> that's important for the normal policy, where there are typically
-      successive periods of sequential reads, but you don't know in advance for
-      how long
-    <mcsim> braunr said that there are legal issues with his code, so I cannot
-      use it.
-    <braunr> did i ?
-    <braunr> mcsim: can you give me a link to the code again please ?
-    <youpi> see above :)
-    <braunr> which one ?
-    <youpi> both
-    <youpi> they only differ by a typo
-    <braunr> mcsim: i don't remember saying that, do you have any link ?
-    <braunr> or log ?
-    <mcsim> sorry, can you rephrase "ending up with fixing the whole path"?
-    <mcsim> cluster_size in vm_advise also could be considered as advise 
-    <braunr> no
-    <braunr> it must be the third time we're talking about this
-    <youpi> mcsim: I mean both parts would be needed to actually achieve
-      clustered i/o
-    <braunr> again, why make cluster_size a per object attribute ? :(
-    <youpi> wouldn't some objects benefit from bigger cluster sizes, while
-      others wouldn't?
-    <youpi> but again, I believe it should rather be autotuned
-    <youpi> (for each object)
-    <braunr> if we merely want posix compatibility (and for a first attempt,
-      it's quite enough), vm_advise is good, and the kernel selects the
-      implementation (and thus the cluster sizes)
-    <braunr> if we want finer grained control, perhaps a per pager cluster_size
-      would be good, although its efficiency depends on several parameters
-    <braunr> (e.g. where the page is in this cluster)
-    <braunr> but a per object cluster size is a large waste of memory
-      considering very few applications (if not none) would use the "feature"
-      ..
-    <braunr> (if any*)
-    <youpi> there must be a misunderstanding
-    <youpi> why would it be a waste of memory?
-    <braunr> "per object"
-    <youpi> so?
-    <braunr> there can be many memory objects in the kernel
-    <youpi> so?
-    <braunr> so such an overhead must be useful to accept it
-    <youpi> in my understanding, a cluster size per object is just a mere
-      integer for each object
-    <youpi> what overhead?
-    <braunr> yes
-    <youpi> don't we have just thousands of objects?
-    <braunr> for now
-    <braunr> remember we're trying to remove the page cache limit :)
-    <youpi> that still won't be more than tens of thousands of objects
-    <youpi> times an integer
-    <youpi> that's completely neglectible
-    <mcsim> braunr: Strange, Can't find in logs. Weird things are happening in
-      my memory :/ Sorry.
-    <braunr> mcsim: i'm almost sure i never said that :/
-    <braunr> but i don't trust my memory too much either
-    <braunr> youpi: depends
-    <youpi> mcsim: I mean both parts would be needed to actually achieve
-      clustered i/o
-    <mcsim> braunr: I made I call vm_advise that applies policy to memory range
-      (vm_map_entry to be specific)
-    <braunr> mcsim: good
-    <youpi> actually the cluster size should even be per memory range
-    <mcsim> youpi: In this sense, yes
-    <youpi> k
-    <mcsim> sorry, Internet connection lags
-    <braunr> when changing a structure used to create many objects, keep in
-      mind one thing
-    <braunr> if its size gets larger than a threshold (currently, powers of
-      two), the cache used by the slab allocator will allocate twice the
-      necessary amount
-    <youpi> sure
-    <braunr> this is the case with most object caching allocators, although
-      some can have specific caches for common sizes such as 96k which aren't
-      powers of two
-    <braunr> anyway, an integer is negligible, but the final structure size
-      must be checked
-    <braunr> (for both 32 and 64 bits)
-    <mcsim> braunr: ok.
-    <mcsim> But I didn't understand what should be done with cluster size in
-      vm_advise? Should I delete it?
-    <braunr> to me, the cluster size is a pager property
-    <youpi> to me, the cluster size is a map property
-    <braunr> whereas vm_advise indicates what applications want
-    <youpi> you could have several process accessing the same file in different
-      ways
-    <braunr> youpi: that's why there is a policy
-    <youpi> isn't cluster_size part of the policy?
-    <braunr> but if the pager abilities are limited, it won't change much
-    <braunr> i'm not sure
-    <youpi> cluster_size is the amount of readahead, isn't it?
-    <braunr> no, it's the amount of data in a single transfer
-    <mcsim> Yes, it is.
-    <braunr> ok, i'll have to check your code
-    <youpi> shouldn't transfers permit unbound amounts of data?
-    <mcsim> braunr: than I misunderstand what readahead is
-    <braunr> well then cluster size is per policy :)
-    <braunr> e.g. random => 0, normal => 3, sequential => 15
-    <braunr> why make it per map entry ?
-    <youpi> because it depends on what the application doezs
-    <braunr> let me check the code
-    <youpi> if it's accessing randomly, no need for big transfers
-    <youpi> just page transfers will be fine
-    <youpi> if accessing sequentially, rather use whole MiB of transfers
-    <youpi> and these behavior can be for the same file
-    <braunr> mcsim: the call is vm_advi*s*e
-    <braunr> mcsim: the call is vm_advi_s_e
-    <braunr> not advice
-    <youpi> yes, he agreed earlier
-    <braunr> ok
-    <mcsim> cluster_size is the amount of data that I try to read at one time.
-    <mcsim> at singe mo_data_request
-    <mcsim> *single
-    <youpi> which, to me, will depend on the actual map
-    <braunr> ok so it is the transfer size
-    <youpi> and should be autotuned, especially for normal behavior
-    <braunr> youpi: it makes no sense to have both the advice and the actual
-      size per map entry
-    <youpi> to get big readahead with all apps
-    <youpi> braunr: the size is not only dependent on the advice, but also on
-      the application behavior
-    <braunr> youpi: how does this application tell this ?
-    <youpi> even for sequential, you shouldn't necessarily use very big amounts
-      of transfers
-    <braunr> there is no need for the advice if there is a cluster size
-    <youpi> there can be, in the case of sequential, as we said, to clear
-      previous pages
-    <youpi> but otherwise, indeed
-    <youpi> but for me it's the converse
-    <youpi> the cluster size should be tuned anyway
-    <braunr> and i'm against giving the cluster size in the advise call, as we
-      may want to prefetch previous data as well
-    <youpi> I don't see how that collides
-    <braunr> well, if you consider it's the transfer size, it doesn't
-    <youpi> to me cluster size is just the size of a window
-    <braunr> if you consider it's the amount of pages following a faulted page,
-      it will
-    <braunr> also, if your policy says e.g. "3 pages before, 10 after", and
-      your cluster size is 2, what happens ?
-    <braunr> i would find it much simpler to do what other VM variants do:
-      compute the I/O sizes directly from the policy
-    <youpi> don't they autotune, and use the policy as a maximum ?
-    <braunr> depends on the implementations
-    <youpi> ok, but yes I agree
-    <youpi> although casting the size into stone in the policy looks bogus to
-      me
-    <braunr> but making cluster_size part of the kernel interface looks way too
-      messy
-    <braunr> it is
-    <braunr> that's why i would have thought it as part of the pager properties
-    <braunr> the pager is the true component besides the kernel that is
-      actually involved in paging ...
-    <youpi> well, for me the flexibility should still  be per application
-    <youpi> by pager you mean the whole pager, not each file, right?
-    <braunr> if a pager can page more because e.g. it's a file system with big
-      block sizes, why not fetch more ?
-    <braunr> yes
-    <braunr> it could be each file
-    <braunr> but only if we have use for it
-    <braunr> and i don't see that currently
-    <youpi> well, posix currently doesn't provide a way to set it
-    <youpi> so it would be useless atm
-    <braunr> i was thinking about our hurd pagers
-    <youpi> could we perhaps say that the policy maximum could be a fraction of
-      available memory?
-    <braunr> why would we want that ?
-    <youpi> (total memory, I mean)
-    <youpi> to make it not completely cast into stone
-    <youpi> as have been in the past in gnumach
-    <braunr> i fail to understand :/
-    <youpi> there must be a misunderstanding then
-    <youpi> (pun not intended)
-    <braunr> why do you want to limit the policy maximum ?
-    <youpi> how to decide it?
-    <braunr> the pager sets it
-    <youpi> actually I don't see how a pager could decide it
-    <youpi> on what ground does it make the decision?
-    <youpi> readahead should ideally be as much as 1MiB
-    <braunr> 02:02 < braunr> if a pager can page more because e.g. it's a file
-      system with big block sizes, why not fetch more ?
-    <braunr> is the example i have in mind
-    <braunr> otherwise some default values
-    <youpi> that's way smaller than 1MiB, isn't it?
-    <braunr> yes
-    <braunr> and 1 MiB seems a lot to me :)
-    <youpi> for readahead, not really
-    <braunr> maybe for sequential
-    <youpi> that's what we care about!
-    <braunr> ah, i thought we cared about normal
-    <youpi> "as much as 1MiB", I said
-    <youpi> I don't mean normal :)
-    <braunr> right
-    <braunr> but again, why limit ?
-    <braunr> we could have 2 or more ?
-    <youpi> at some point you don't get more efficiency
-    <youpi> but eat more memory
-    <braunr> having the pager set the amount allows us to easily adjust it over
-      time
-    <mcsim> braunr: Do you think that readahead should be implemented in
-      libpager?
-    <youpi> than needed
-    <braunr> mcsim: no
-    <braunr> mcsim: err
-    <braunr> mcsim: can't answer
-    <youpi> mcsim: do you read the log of what you have missed during
-      disconnection?
-    <braunr> i'm not sure about what libpager does actually
-    <mcsim> yes
-    <braunr> for me it's just mutualisation of code used by pagers
-    <braunr> i don't know the details
-    <braunr> youpi: yes
-    <braunr> youpi: that's why we want these values not hardcoded in the kernel
-    <braunr> youpi: so that they can be adjusted by our shiny user space OS
-    <youpi> (btw apparently linux uses minimum 16k, maximum 128 or 256k)
-    <braunr> that's more reasonable
-    <youpi> that's just 4 times less :)
-    <mcsim> braunr: You say that pager should decide how much data should be
-      read ahead, but each pager can't implement it on it's own as there will
-      be too much overhead. So the only way is to implement this in libpager.
-    <braunr> mcsim: gni ?
-    <braunr> why couldn't they ?
-    <youpi> mcsim: he means the size, not the actual implementation
-    <youpi> the maximum size, actually
-    <braunr> actually, i would imagine it as the pager giving per policy
-      parameters
-    <youpi> right
-    <braunr> like how many before and after
-    <youpi> I agree, then
-    <braunr> the kernel could limit, sure, to avoid letting pagers use
-      completely insane values
-    <youpi> (and that's just a max, the kernel autotunes below that)
-    <braunr> why not
-    <youpi> that kernel limit could be a fraction of memory, then?
-    <braunr> it could, yes
-    <braunr> i see what you mean now
-    <youpi> mcsim: did you understand our discussion?
-    <youpi> don't hesitate to ask for clarification
-    <mcsim> I supposed cluster_size to be such parameter. And advice will help
-      to interpret this parameter (whether data should be read after fault page
-      or some data should be cleaned before)
-    <youpi> mcsim: we however believe that it's rather the pager than the
-      application that would tell that
-    <youpi> at least for the default values
-    <youpi> posix doesn't have a way to specify it, and I don't think it will
-      in the future
-    <braunr> and i don't think our own hurd-specific programs will need more
-      than that
-    <braunr> if they do, we can slightly change the interface to make it a per
-      object property
-    <braunr> i've checked the slab properties, and it seems we can safely add
-      it per object
-    <braunr> cf http://www.sceen.net/~rbraun/slabinfo.out
-    <braunr> so it would still be set by the pager, but if depending on the
-      object, the pager could set different values
-    <braunr> youpi: do you think the pager should just provide one maximum size
-      ? or per policy sizes ?
-    <youpi> I'd say per policy size
-    <youpi> so people can increase sequential size like crazy when they know
-      their sequential applications need it, without disturbing the normal
-      behavior
-    <braunr> right
-    <braunr> so the last decision is per pager or per object
-    <braunr> mcsim: i'd say whatever makes your implementation simpler :)
-    <mcsim> braunr: how kernel knows that object are created by specific pager?
-    <braunr> that's the kind of things i'm referring to with "whatever makes
-      your implementation simpler"
-    <braunr> but usually, vm_objects have an ipc port and some properties
-      relatedto their pagers
-    <braunr> -usually
-    <braunr> the problem i had in mind was the locking protocol but our spin
-      locks are noops, so it will be difficult to detect deadlocks
-    <mcsim> braunr: and for every policy there should be variable in vm_object
-      structure with appropriate cluster_size?
-    <braunr> if you want it per object, yes
-    <braunr> although i really don't think we want it
-    <youpi> better keep it per pager for now
-    <braunr> let's imagine youpi finishes his 64-bits support, and i can
-      successfully remove the page cache limit
-    <braunr> we'd jump from 1.8 GiB at most to potentially dozens of GiB of RAM
-    <braunr> and 1.8, mostly unused
-    <braunr> to dozens almost completely used, almost all the times for the
-      most interesting use cases
-    <braunr> we may have lots and lots of objects to keep around
-    <braunr> so if noone really uses the feature ... there is no point
-    <youpi> but also lots and lots of memory to spend on it :)
-    <youpi> a lot of objects are just one page, but a lof of them are not
-    <braunr> sure
-    <braunr> we wouldn't be doing that otherwise :)
-    <braunr> i'm just saying there is no reason to add the overhead of several
-      integers for each object if they're simply not used at all
-    <braunr> hmm, 64-bits, better page cache, clustered paging I/O :>
-    <braunr> (and readahead included in the last ofc)
-    <braunr> good night !
-    <mcsim> than, probably, make system-global max-cluster_size? This will save
-      some memory. Also there is usually no sense in reading really huge chunks
-      at once.
-    <youpi> but that'd be tedious to set
-    <youpi> there are only a few pagers, that's no wasted memory
-    <youpi> the user being able to set it for his own pager is however a very
-      nice feature, which can be very useful for databases, image processing,
-      etc.
-    <mcsim> In conclusion I have to implement following: 3 memory policies per
-      object and per vm_map_entry. Max cluster size for every policy should be
-      set per pager.
-    <mcsim> So, there should be 2 system calls for setting memory policy and
-      one for setting cluster sizes.
-    <mcsim> Also amount of data to transfer should be tuned automatically by
-      every page fault. 
-    <mcsim> youpi: Correct me, please, if I'm wrong.
-    <youpi> I believe that's what we ended up to decide, yes
-
-
-## IRC, freenode, #hurd, 2012-07-02
-
-    <braunr> is it safe to say that all memory objects implemented by external
-      pagers have "file" semantics ?
-    <braunr> i wonder if the current memory manager interface is suitable for
-      device pagers
-    <mcsim> braunr: What does "file" semantics mean?
-    <braunr> mcsim: anonymous memory doesn't have the same semantics as a file
-      for example
-    <braunr> anonymous memory that is discontiguous in physical memory can be
-      contiguous in swap
-    <braunr> and its location can change with time
-    <braunr> whereas with a memory object, the data exchanged with pagers is
-      identified with its offset
-    <braunr> in (probably) all other systems, this way of specifying data is
-      common to all files, whatever the file system
-    <braunr> linux uses the struct vm_file name, while in BSD/Solaris they are
-      called vnodes (the link between a file system inode and virtual memory)
-    <braunr> my question is : can we implement external device pagers with the
-      current interface, or is this interface really meant for files ?
-    <braunr> also
-    <braunr> mcsim: something about what you said yesterday
-    <braunr> 02:39 < mcsim> In conclusion I have to implement following: 3
-      memory policies per object and per vm_map_entry. Max cluster size for
-      every policy should be set per pager.
-    <braunr> not per object
-    <braunr> one policy per map entry
-    <braunr> transfer parameters (pages before and after the faulted page) per
-      policy, defined by pagers
-    <braunr> 02:39 < mcsim> So, there should be 2 system calls for setting
-      memory policy and one for setting cluster sizes.
-    <braunr> adding one call for vm_advise is good because it mirrors the posix
-      call
-    <braunr> but for the parameters, i'd suggest changing an already existing
-      call
-    <braunr> not sure which one though
-    <mcsim> braunr: do you know how mo_change_attributes implemented in
-      OSF/Mach?
-    <braunr> after a quick reading of the reference manual, i think i
-      understand why they made it per object
-    <braunr> mcsim: no
-    <braunr> did they change the call to include those paging parameters ?
-    <mcsim> it accept two parameters: flavor and pointer to structure with
-      parameters.
-    <mcsim> flavor determines semantics of structure with parameters.
-    <mcsim>
-      http://www.darwin-development.org/cgi-bin/cvsweb/osfmk/src/mach_kernel/vm/memory_object.c?rev=1.1
-    <mcsim> structure can have 3 different views and what exect view will be is
-      determined by value of flavor
-    <mcsim> So, I thought about implementing similar call that could be used
-      for various purposes.
-    <mcsim> like ioctl
-    <braunr> "pointer to structure with parameters" <= which one ?
-    <braunr> mcsim: don't model anything anywhere like ioctl please
-    <mcsim> memory_object_info_t	attributes
-    <braunr> ioctl is the very thing we want NOT to have on the hurd
-    <braunr> ok attributes
-    <braunr> and what are the possible values of flavour, and what kinds of
-      attributes ?
-    <mcsim> and then appears something like this on each case: behave =
-      (old_memory_object_behave_info_t) attributes;
-    <braunr> ok i see
-    <mcsim> flavor could be  OLD_MEMORY_OBJECT_BEHAVIOR_INFO,
-      MEMORY_OBJECT_BEHAVIOR_INFO, MEMORY_OBJECT_PERFORMANCE_INFO etc
-    <braunr> i don't really see the point of flavour here, other than
-      compatibility
-    <braunr> having attributes is nice, but you should probably add it as a
-      call parameter, not inside a structure
-    <braunr> as a general rule, we don't like passing structures too much
-      to/from the kernel, because handling them with mig isn't very clean
-    <mcsim> ok
-    <mcsim> What policy parameters should be defined by pager?
-    <braunr> i'd say number of pages to page-in before and after the faulted
-      page
-    <mcsim> Only pages before and after the faulted page?
-    <braunr> for me yes
-    <braunr> youpi might have different things in mind
-    <braunr> the page cleaning in sequential mode is something i wouldn't do
-    <braunr> 1/ applications might want data read sequentially to remain in the
-      cache, for other sequential accesses
-    <braunr> 2/ applications that really don't want to cache anything should
-      use O_DIRECT
-    <braunr> 3/ it's complicated, and we're in july
-    <braunr> i'd rather have a correct and stable result than too many unused
-      features
-    <mcsim> braunr: MADV_SEQUENTIAL Expect page references in sequential order.
-      (Hence, pages in the given range can be aggressively read ahead, and may
-      be freed soon after they are accessed.)
-    <mcsim> this is from linux man
-    <mcsim> braunr: Can I at least make keeping in mind that it could be
-      implemented?
-    <mcsim> I mean future rpc interface
-    <mcsim> braunr: From behalf of kernel pager is just a port.
-    <mcsim> That's why it is not clear for me how I can make in kernel
-      per-pager policy
-    <braunr> mcsim: you can't
-    <braunr> 15:19 < braunr> after a quick reading of the reference manual, i
-      think i understand why they made it per object
-    <braunr>
-      http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_madvise.html
-    <braunr> POSIX_MADV_SEQUENTIAL
-    <braunr> Specifies that the application expects to access the specified
-      range sequentially from lower addresses to higher addresses.
-    <braunr> linux might free pages after their access, why not, but this is
-      entirely up to the implementation
-    <mcsim> I know, when but applications might want data read sequentially to
-      remain in the cache, for other sequential accesses this kind of access
-      could be treated rather normal or random
-    <braunr> we can do differently
-    <braunr> mcsim: no
-    <braunr> sequential means the access will be sequential
-    <braunr> so aggressive readahead (e.g. 0 pages before, many after), should
-      be used
-    <braunr> for better performance
-    <braunr> from my pov, it has nothing to do with caching
-    <braunr> i actually sometimes expect data to remain in cache
-    <braunr> e.g. before playing a movie from sshfs, i sometimes prefetch it
-      using dd
-    <braunr> then i use mplayer
-    <braunr> i'd be very disappointed if my data didn't remain in the cache :)
-    <mcsim> At least these pages could be placed into inactive list to be first
-      candidates for pageout.
-    <braunr> that's what will happen by default
-    <braunr> mcsim: if we need more properties for memory objects, we'll adjust
-      the call later, when we actually implement them
-    <mcsim> so, first call is vm_advise and second is changed
-      mo_change_attributes?
-    <braunr> yes
-    <mcsim> there will appear 3 new parameters in mo_c_a: policy, pages before
-      and pages after?
-    <mcsim> braunr: With vm_advise I didn't understand one thing. This call is
-      defined in defs file, so that should mean that vm_advise is ordinal rpc
-      call. But on the same time it is defined as syscall in mach internals (in
-      mach_trap_table).
-    <braunr> mcsim: what ?
-    <braunr> were is it "defined" ? (it doesn't exit in gnumach currently)
-    <mcsim> Ok, let consider vm_map
-    <mcsim> I define it both in mach_trap_table and in defs file.
-    <mcsim> But why?
-    <braunr> uh ?
-    <braunr> let me see
-    <mcsim> Why defining in defs file is not enough?
-    <mcsim> and previous question: there will appear 3 new parameters in
-      mo_c_a: policy, pages before and pages after?
-    <braunr> mcsim: give me the exact file paths please
-    <braunr> mcsim: we'll discuss the new parameters after
-    <mcsim> kern/syscall_sw.c
-    <braunr> right i see
-    <mcsim> here mach_trap_table in defined
-    <braunr> i think they're not used
-    <braunr> they were probably introduced for performance
-    <mcsim> and ./include/mach/mach.defs
-    <braunr> don't bother adding vm_advise as a syscall
-    <braunr> about the parameters, it's a bit more complicated
-    <braunr> you should add 6 parameters
-    <braunr> before and after, for the 3 policies
-    <braunr> but
-    <braunr> as seen in the posix page, there could be more policies ..
-    <braunr> ok forget what i said, it's stupid
-    <braunr> yes, the 3 parameters you had in mind are correct
-    <braunr> don't forget a "don't change" value for the policy though, so the
-      kernel ignores the before/after values if we don't want to change that
-    <mcsim> ok
-    <braunr> mcsim: another reason i asked about "file semantics" is the way we
-      handle the cache
-    <braunr> mcsim: file semantics imply data is cached, whereas anonymous and
-      device memory usually isn't
-    <braunr> (although having the cache at the vm layer instead of the pager
-      layer allows nice things like the swap cache)
-    <mcsim> But this shouldn't affect possibility of implementing of device
-      pager.
-    <braunr> yes it may
-    <braunr> consider how a fault is actually handled by a device
-    <braunr> mach must use weird fictitious pages for that
-    <braunr> whereas it would be better to simply let the pager handle the
-      fault as it sees fit
-    <mcsim> setting may_cache to false should resolve the issue
-    <braunr> for the caching problem, yes
-    <braunr> which is why i still think it's better to handle the cache at the
-      vm layer, unlike UVM which lets the vnode pager handle its own cache, and
-      removes the vm cache completely
-    <mcsim> The only issue with pager interface I see is implementing of
-      scatter-gather DMA (as current interface does not support non-consecutive
-      access)
-    <braunr> right
-    <braunr> but that's a performance issue
-    <braunr> my problem with device pagers is correctness
-    <braunr> currently, i think the kernel just asks pagers for "data"
-    <braunr> whereas a device pager should really map its device memory where
-      the fault happen
-    <mcsim> braunr: You mean that every access to memory should cause page
-      fault?
-    <mcsim> I mean mapping of device memory
-    <braunr> no
-    <braunr> i mean a fault on device mapped memory should directly access a
-      shared region
-    <braunr> whereas file pagers only implement backing store
-    <braunr> let me explain a bit more
-    <braunr> here is what happens with file mapped memory
-    <braunr> you map it, access it (some I/O is done to get the page content in
-      physical memory), then later it's flushed back
-    <braunr> whereas with device memory, there shouldn't be any I/O, the device
-      memory should directly be mapped (well, some devices need the same
-      caching behaviour, while others provide direct access)
-    <braunr> one of the obvious consequences is that, when you map device
-      memory (e.g. a framebuffer), you expect changes in your mapped memory to
-      be effective right away
-    <braunr> while with file mapped memory, you need to msync() it
-    <braunr> (some framebuffers also need to be synced, which suggests greater
-      control is needed for external pagers)
-    <mcsim> Seems that I understand you. But how it is implemented in other
-      OS'es? Do they set something in mmu?
-    <braunr> mcsim: in netbsd, pagers have a fault operatin in addition to get
-      and put
-    <braunr> the device pager sets get and put to null and implements fault
-      only
-    <braunr> the fault callback then calls the d_mmap callback of the specific
-      driver
-    <braunr> which usually results in the mmu being programmed directly
-    <braunr> (e.g. pmap_enter or similar)
-    <braunr> in linux, i think raw device drivers, being implemented as
-      character device files, must provide raw read/write/mmap/etc.. functions
-    <braunr> so it looks pretty much similar
-    <braunr> i'd say our current external pager interface is insufficient for
-      device pagers
-    <braunr> but antrik may know more since he worked on ggi
-    <braunr> antrik: ^
-    <mcsim> braunr: Seems he used io_map
-    <braunr> mcsim: where ar eyou looking at ? the incubator ?
-    <mcsim> his master's thesis
-    <braunr> ah the thesis
-    <braunr> but where ? :)
-    <mcsim> I'll give you a link
-    <mcsim> http://dl.dropbox.com/u/36519904/kgi_on_hurd.pdf
-    <braunr> thanks
-    <mcsim> see p 158
-    <braunr> arg, more than 200 pages, and he says he's lazy :/
-    <braunr> mcsim: btw, have a look at m_o_ready
-    <mcsim> braunr: This is old form of mo_change attributes
-    <mcsim> I'm not going to change it
-    <braunr> mcsim: these are actually the default object parameters right ?
-    <braunr> mcsim: if you don't change it, it means the kernel must set
-      default values until the pager changes them, if it does
-    <mcsim> yes.
-    <antrik> mcsim: madvise() on Linux has a separate flag to indicate that
-      pages won't be reused. thus I think it would *not* be a good idea to
-      imply it in SEQUENTIAL
-    <antrik> braunr: yes, my KMS code relies on mapping memory objects for the
-      framebuffer
-    <antrik> (it should be noted though that on "modern" hardware, mapping
-      graphics memory directly usually gives very poor performance, and drivers
-      tend to avoid it...)
-    <antrik> mcsim: BTW, it was most likely me who warned about legal issues
-      with KAM's work. AFAIK he never managed to get the copyright assignment
-      done :-(
-    <antrik> (that's not really mandatory for the gnumach work though... only
-      for the Hurd userspace parts)
-    <antrik> also I'd like to point out again that the cluster_size argument
-      from OSF Mach was probably *not* meant for advice from application
-      programs, but rather was supposed to reflect the cluster size of the
-      filesystem in question. at least that sounds much more plausible to me...
-    <antrik> braunr: I have no idea whay you mean by "device pager". device
-      memory is mapped once when the VM mapping is established; there is no
-      need for any fault handling...
-    <antrik> mcsim: to be clear, I think the cluster_size parameter is mostly
-      orthogonal to policy... and probably not very useful at all, as ext2
-      almost always uses page-sized clusters. I'm strongly advise against
-      bothering with it in the initial implementation
-    <antrik> mcsim: to avoid confusion, better use a completely different name
-      for the policy-decided readahead size
-    <mcsim> antrik: ok
-    <antrik> braunr: well, yes, the thesis report turned out HUGE; but the
-      actual work I did on the KGI port is fairly tiny (not more than a few
-      weeks of actual hacking... everything else was just brooding)
-    <antrik> braunr: more importantly, it's pretty much the last (and only
-      non-trivial) work I did on the Hurd :-(
-    <antrik> (also, I don't think I used the word "lazy"... my problem is not
-      laziness per se; but rather inability to motivate myself to do anything
-      not providing near-instant gratification...)
-    <braunr> antrik: right
-    <braunr> antrik: i shouldn't consider myself lazy either
-    <braunr> mcsim: i agree with antrik, as i told you weeks ago
-    <braunr> about
-    <braunr> 21:45 < antrik> mcsim: to be clear, I think the cluster_size
-      parameter is mostly orthogonal to policy... and probably not very useful
-      at all, as ext2 almost always uses page-sized clusters. I'm strongly
-      advise against bothering with it
-    <braunr>                 in the initial implementation
-    <braunr> antrik: but how do you actually map device memory ?
-    <braunr> also, strangely enough, here is the comment in dragonflys
-      madvise(2)
-    <braunr> 21:45 < antrik> mcsim: to be clear, I think the cluster_size
-      parameter is mostly orthogonal to policy... and probably not very useful
-      at all, as ext2 almost always uses page-sized clusters. I'm strongly
-      advise against bothering with it
-    <braunr>                 in the initial implementation
-    <braunr> arg
-    <braunr> MADV_SEQUENTIAL  Causes the VM system to depress the priority of
-      pages immediately preceding a given page when it is faulted in.
-    <antrik> braunr: interesting...
-    <antrik> (about SEQUENTIAL on dragonfly)
-    <antrik> as for mapping device memory, I just use to device_map() on the
-      mem device to map the physical address space into a memory object, and
-      then through vm_map into the driver (and sometimes application) address
-      space
-    <antrik> formally, there *is* a pager involved of course (implemented
-      in-kernel by the mem device), but it doesn't really do anything
-      interesting
-    <antrik> thinking about it, there *might* actually be page faults involved
-      when the address ranges are first accessed... but even then, the handling
-      is really trivial and not terribly interesting
-    <braunr> antrik: it does the most interesting part, create the physical
-      mapping
-    <braunr> and as trivial as it is, it requires a special interface
-    <braunr> i'll read about device_map again
-    <braunr> but yes, the fact that it's in-kernel is what solves the problem
-      here
-    <braunr> what i'm interested in is to do it outside the kernel :)
-    <antrik> why would you want to do that?
-    <antrik> there is no policy involved in doing an MMIO mapping
-    <antrik> you ask for the pysical memory region you are interested in, and
-      that's it
-    <antrik> whether the kernel adds the page table entries immediately or on
-      faults is really an implementation detail
-    <antrik> braunr: ^
-    <braunr> yes it's a detail
-    <braunr> but do we currently have the interface to make such mappings from
-      userspace ?
-    <braunr> and i want to do that because i'd like as many drivers as possible
-      outside the kernel of course
-    <antrik> again, the userspace driver asks the kernel to establish the
-      mapping (through device_map() and then vm_map() on the resulting memory
-      object)
-    <braunr> hm i'm missing something
-    <braunr>
-      http://www.gnu.org/software/hurd/gnumach-doc/Device-Map.html#Device-Map
-      <= this one ?
-    <antrik> yes, this one
-    <braunr> but this implies the device is implemented by the kernel
-    <antrik> the mem device is, yes
-    <antrik> but that's not a driver
-    <braunr> ah
-    <antrik> it's just the interface for doing MMIO
-    <antrik> (well, any physical mapping... but MMIO is probably the only real
-      use case for that)
-    <braunr> ok
-    <braunr> i was thinking about completely removing the device interface from
-      the kernel actually
-    <braunr> but it makes sense to have such devices there
-    <antrik> well, in theory, specific kernel drivers can expose their own
-      device_map() -- but IIRC the only one that does (besides mem of course)
-      is maptime -- which is not a real driver either...
-
-[[Mapped-time_interface|microkernel/mach/gnumach/interface/device/time]].
-
-    <braunr> oh btw, i didn't know you had a blog :)
-    <antrik> well, it would be possible to replace the device interface by
-      specific interfaces for the generic pseudo devices... I'm not sure how
-      useful that would be
-    <braunr> there are lots of interesting stuff there
-    <antrik> hehe... another failure ;-)
-    <braunr> failure ?
-    <antrik> well, when I realized that I'm speding a lot of time pondering
-      things, and never can get myself to actually impelemnt any of them, I had
-      the idea that if I write them down, there might at least be *some* good
-      from it...
-    <antrik> unfortunately it turned out that I need so much effort to write
-      things down, that most of the time I can't get myself to do that either
-      :-(
-    <braunr> i see
-    <braunr> well it's still nice to have it
-    <antrik> (notice that the latest entry is two years old... and I haven't
-      even started describing most of my central ideas :-( )
-    <braunr> antrik: i tried to create a blog once, and found what i wrote so
-      stupid i immediately removed it
-    <antrik> hehe
-    <antrik> actually some of my entries seem silly in retrospect as well...
-    <antrik> but I guess that's just the way it is ;-)
-    <braunr> :)
-    <braunr> i'm almost sure other people would be interested in what i had to
-      say
-    <antrik> BTW, I'm actually not sure whether the Mach interfaces are
-      sufficient to implement GEM/TTM... we would certainly need kernel support
-      for GART (as for any other kind IOMMU in fact); but beyond that it's not
-      clear to me
-    <braunr> GEM ? TTM ? GART ?
-    <antrik> GEM = Graphics Execution Manager. part of the "new" DRM interface,
-      closely tied with KMS
-    <antrik> TTM = Translation Table Manager. does part of the background work
-      for most of the GEM drivers
-    <braunr> "The Graphics Execution Manager (GEM) is a computer software
-      system developed by Intel to do memory management for device drivers for
-      graphics chipsets." hmm
-    <antrik> (in fact it was originally meant to provide the actual interface;
-      but the Inter folks decided that it's not useful for their UMA graphics)
-    <antrik> GART = Graphics Aperture
-    <antrik> kind of an IOMMU for graphics cards
-    <antrik> allowing the graphics card to work with virtual mappings of main
-      memory
-    <antrik> (i.e. allowing safe DMA)
-    <braunr> ok
-    <braunr> all this graphics stuff looks so complex :/
-    <antrik> it is
-    <antrik> I have a whole big chapter on that in my thesis... and I'm not
-      even sure I got everything right
-    <braunr> what is nvidia using/doing (except for getting the finger) ?
-    <antrik> flushing out all the details for KMS, GEM etc. took the developers
-      like two years (even longer if counting the history of TTM)
-    <antrik> Nvidia's proprietary stuff uses a completely own kernel interface,
-      which is of course not exposed or docuemented in any way... but I guess
-      it's actually similar in what it does)
-    <braunr> ok
-    <antrik> (you could ask the nouveau guys if you are truly
-      interested... they are doing most of their reverse engineering at the
-      kernel interface level)
-    <braunr> it seems graphics have very special needs, and a lot of them
-    <braunr> and the interfaces are changing often
-    <braunr> so it's not that much interesting currently
-    <braunr> it just means we'll probably have to change the mach interface too
-    <braunr> like you said
-    <braunr> so the answer to my question, which was something like "do mach
-      external pagers only implement files ?", is likely yes
-    <antrik> well, KMS/GEM had reached some stability; but now there are
-      further changes ahead with the embedded folks coming in with all their
-      dedicated hardware, calling for unified buffer management across the
-      whole pipeline (from capture to output)
-    <antrik> and yes: graphics hardware tends to be much more complex regarding
-      the interface than any other hardware. that's because it's a combination
-      of actual I/O (like most other devices) with a very powerful coprocessor
-    <antrik> and the coprocessor part is pretty much unique amongst peripherial
-      devices
-    <antrik> (actually, the I/O part is also much more complex than most other
-      hardware... but that alone would only require a more complex driver, not
-      special interfaces)
-    <antrik> embedded hardware makes it more interesting in that the I/O
-      part(s) are separate from the coprocessor ones; and that there are often
-      several separate specialised ones of each... the DRM/KMS stuff is not
-      prepared to deal with this
-    <antrik> v4l over time has evolved to cover such things; but it's not
-      really the right place to implement graphics drivers... which is why
-      there are not efforts to unify these frameworks. funny times...
-
-
-## IRC, freenode, #hurd, 2012-07-03
-
-    <braunr> mcsim: vm_for_every_page should be static
-    <mcsim> braunr: ok
-    <braunr> mcsim: see http://gcc.gnu.org/onlinedocs/gcc/Inline.html
-    <braunr> and it looks big enough that you shouldn't make it inline
-    <braunr> let the compiler decide for you (which is possible only if the
-      function is static)
-    <braunr> (otherwise a global symbol needs to exist)
-    <braunr> mcsim: i don't know where you copied that comment from, but you
-      should review the description of the vm_advice call in mach.Defs
-    <mcsim> braunr: I see
-    <mcsim> braunr: It was vm_inherit :)
-    <braunr> mcsim: why isn't NORMAL defined in vm_advise.h ?
-    <braunr> mcsim: i figured actually ;)
-    <mcsim> braunr: I was going to do it later when.
-    <braunr> mcsim: for more info on inline, see
-      http://www.kernel.org/doc/Documentation/CodingStyle
-    <braunr> arg that's an old one
-    <mcsim> braunr: I know that I do not follow coding style
-    <braunr> mcsim: this one is about linux :p
-    <braunr> mcsim: http://lxr.linux.no/linux/Documentation/CodingStyle should
-      have it
-    <braunr> mcsim: "Chapter 15: The inline disease"
-    <mcsim> I was going to fix it later during refactoring when I'll merge
-      mplaneta/gsoc12/working to mplaneta/gsoc12/master
-    <braunr> be sure not to forget :p
-    <braunr> and the best not to forget is to do it asap
-    <braunr> +way
-    <mcsim> As to inline. I thought that even if I specify function as inline
-      gcc makes final decision about it.
-    <mcsim> There was a specifier that made function always inline, AFAIR.
-    <braunr> gcc can force a function not to be inline, yes
-    <braunr> but inline is still considered as a strong hint
-
-
-## IRC, freenode, #hurd, 2012-07-05
-
-    <mcsim1> braunr: hello. You've said that pager has to supply 2 values to
-      kernel to give it an advice how execute page fault. These two values
-      should be number of pages before and after the page where fault
-      occurred. But for sequential policy number of pager before makes no
-      sense. For random policy too. For normal policy it would be sane to make
-      readahead symmetric. Probably it would be sane to make pager supply
-      cluster_size (if it is necessary to supply any) that w
-    <mcsim1> *that will be advice for kernel of least sane value? And maximal
-      value will be f(free_memory, map_entry_size)?
-    <antrik> mcsim1: I doubt symmetric readahead would be a good default
-      policy... while it's hard to estimate an optimum over all typical use
-      cases, I'm pretty sure most situtations will benefit almost exclusively
-      from reading following pages, not preceeding ones
-    <antrik> I'm not even sure it's useful to read preceding pages at all in
-      the default policy -- the use cases are probably so rare that the penalty
-      in all other use cases is not justified. I might be wrong on that
-      though...
-    <antrik> I wonder how other systems handle that
-    <LarstiQ> antrik: if there is a mismatch between pages and the underlying
-      store, like why changing small bits of data on an ssd is slow?
-    <braunr> mcsim1: i don't see why not
-    <braunr> antrik: netbsd reads a few pages before too
-    <braunr> actually, what netbsd does vary on the version, some only mapped
-      in resident pages, later versions started asynchronous transfers in the
-      hope those pages would be there
-    <antrik> LarstiQ: not sure what you are trying to say
-    <braunr> in linux :
-    <braunr> 321  *  MADV_NORMAL - the default behavior is to read clusters.
-      This
-    <braunr> 322  *              results in some read-ahead and read-behind.
-    <braunr> not sure if it's actually what the implementation does
-    <antrik> well, right -- it's probably always useful to read whole clusters
-      at a time, especially if they are the same size as pages... that doesn't
-      mean it always reads preceding pages; only if the read is in the middle
-      of the cluster AIUI
-    <LarstiQ> antrik: basically what braunr just pasted
-    <antrik> and in most cases, we will want to read some *following* clusters
-      as well, but probably not preceding ones
-    * LarstiQ nods
-    <braunr> antrik: the default policy is usually rather sequential
-    <braunr> here are the numbers for netbsd
-    <braunr>  166 static struct uvm_advice uvmadvice[] = {
-    <braunr>  167         { MADV_NORMAL, 3, 4 },
-    <braunr>  168         { MADV_RANDOM, 0, 0 },
-    <braunr>  169         { MADV_SEQUENTIAL, 8, 7},
-    <braunr>  170 };
-    <braunr> struct uvm_advice {
-    <braunr>          int advice;
-    <braunr>          int nback;
-    <braunr>          int nforw;
-    <braunr> };
-    <braunr> surprising isn't it ?
-    <braunr> they may suggest sequential may be backwards too
-    <braunr> makes sense
-    <antrik> braunr: what are these numbers? pages?
-    <braunr> yes
-    <antrik> braunr: I suspect the idea behind SEQUENTIAL is that with typical
-      sequential access patterns, you will start at one end of the file, and
-      then go towards the other end -- so the extra clusters in the "wrong"
-      direction do not actually come into play
-    <antrik> only situation where some extra clusters are actually read is when
-      you start in the middle of a file, and thus do not know yet in which
-      direction the sequential read will go...
-    <braunr> yes, there are similar comments in the linux code
-    <braunr> mcsim1: so having before and after numbers seems both
-      straightforward and in par with other implementations
-    <antrik> I'm still surprised about the almost symmetrical policy for NORMAL
-      though
-    <antrik> BTW, is it common to use heuristics for automatically recognizing
-      random and sequential patterns in the absence of explicit madise?
-    <braunr> i don't know
-    <braunr> netbsd doesn't use any, linux seems to have different behaviours
-      for anonymous and file memory
-    <antrik> when KAM was working on this stuff, someone suggested that...
-    <braunr> there is a file_ra_state struct in linux, for per file read-ahead
-      policy
-    <braunr> now the structure is of course per file system, since they all use
-      the same address
-    <braunr> (which is why i wanted it to be per pager in the first place)
-    <antrik> mcsim1: as I said before, it might be useful for the pager to
-      supply cluster size, if it's different than page size. but right now I
-      don't think this is something worth bothering with...
-    <antrik> I seriously doubt it would be useful for the pager to supply any
-      other kind of policy
-    <antrik> braunr: I don't understand your remark about using the same
-      address...
-    <antrik> braunr: pre-mapping seems the obvious way to implement readahead
-      policy
-    <antrik> err... per-mapping
-    <braunr> the ra_state (read ahead state) isn't the policy
-    <braunr> the policy is per mapping, parts of the implementation of the
-      policy is per file system
-    <mcsim1> braunr: How do you look at following implementation of NORMAL
-      policy: We have fault page that is current. Than we have maximal size of
-      readahead block. First we find first absent pages before and after
-      current. Than we try to fit block that will be readahead into this
-      range. Here could be following situations: in range RBS/2 (RBS -- size of
-      readahead block) there is no any page, so readahead will be symmetric; if
-      current page is first absent page than all 
-    <mcsim1> RBS block will consist of pages that are after current; on the
-      contrary if current page is last absent than readahead will go backwards.
-    <mcsim1> Additionally if current page is approximately in the middle of the
-      range we can decrease RBS, supposing that access is random.
-    <braunr> mcsim1: i think your gsoc project is about readahead, we're in
-      july, and you need to get the job done
-    <braunr> mcsim1: grab one policy that works, pages before and after are
-      good enough
-    <braunr> use sane default values, let the pagers decide if they want
-      something else
-    <braunr> and concentrate on the real work now
-    <antrik> braunr: I still don't see why pagers should mess with that... only
-      complicates matters IMHO
-    <braunr> antrik: probably, since they almost all use the default
-      implementation
-    <braunr> mcsim1: just use sane values inside the kernel :p
-    <braunr> this simplifies things by only adding the new vm_advise call and
-      not change the existing external pager interface
-
-
-## IRC, freenode, #hurd, 2012-07-12
-
-    <braunr> mcsim: so, to begin with, tell us what state you've reached please
-    <mcsim> braunr: I'm writing code for hurd and gnumach. For gnumach I'm
-      implementing memory policies now. RANDOM and NORMAL seems work, but in
-      hurd I found error that I made during editing ext2fs. So for now ext2fs
-      does not work
-    <braunr> policies ?
-    <braunr> what about mechanism ?
-    <mcsim> also I moved some translators to new interface.
-    <mcsim> It works too
-    <braunr> well that's impressive
-    <mcsim> braunr: I'm not sure yet that everything works
-    <braunr> right, but that's already a very good step
-    <braunr> i thought you were still working on the interfaces to be honest
-    <mcsim> And with mechanism I didn't implement moving pages to inactive
-      queue
-    <braunr> what do you mean ?
-    <braunr> ah you mean with the sequential policy ?
-    <mcsim> yes
-    <braunr> you can consider this a secondary goal
-    <mcsim> sequential I was going to implement like you've said, but I still
-      want to support moving pages to inactive queue
-    <braunr> i think you shouldn't
-    <braunr> first get to a state where clustered transfers do work fine
-    <mcsim> policies are implemented in function calculate_clusters
-    <braunr> then, you can try, and measure the difference
-    <mcsim> ok. I'm now working on fixing ext2fs
-    <braunr> so, except from bug squashing, what's left to do ?
-    <mcsim> finish policies and ext2fs; move fatfs, ufs, isofs to new
-      interface; test this all; edit patches from debian repository, that
-      conflict with my changes; rearrange commits and fix code indentation;
-      update documentation;
-    <braunr> think about measurements too
-    <tschwinge> mcsim: Please don't spend a lot of time on ufs.  No testing
-      required for that one.
-    <braunr> and keep us informed about your progress on bug fixing, so we can
-      test soon
-    <mcsim> Forgot about moving system to new interfaces (I mean determine form
-      of vm_advise and memory_object_change_attributes)
-    <braunr> s/determine/final/
-    <mcsim> braunr: ok.
-    <braunr> what do you mean "moving system to new interfaces" ?
-    <mcsim> braunr: I also pushed code changes to gnumach and hurd git
-      repositories
-    <mcsim> I met an issue with memory_object_change_attributes when I tried to
-      use it as I have to update all applications that use it. This includes
-      libc and translators that are not in hurd repository or use debian
-      patches. So I will not be able to run system with new
-      memory_object_change_attributes interface, until I update all software
-      that use this rpc
-    <braunr> this is a bit like the problem i had with my change
-    <braunr> the solution is : don't do it
-    <braunr> i mean, don't change the interface in an incompatible way
-    <braunr> if you can't change an existing call, add a new one
-    <mcsim> temporary I changed memory_object_set_attributes as it isn't used
-      any more.
-    <mcsim> braunr: ok. Adding new call is a good idea :)
-
-
-## IRC, freenode, #hurd, 2012-07-16
-
-    <braunr> mcsim: how did you deal with multiple page transfers towards the
-      default pager ?
-    <mcsim> braunr: hello. Didn't handle this yet, but AFAIR default pager
-      supports multiple page transfers.
-    <braunr> mcsim: i'm almost sure it doesn't
-    <mcsim> braunr: indeed
-    <mcsim> braunr: So, I'll update it just other translators.
-    <braunr> like other translators you mean ?
-    <mcsim> *just as
-    <mcsim> braunr: yes
-    <braunr> ok
-    <braunr> be aware also that it may need some support in vm_pageout.c in
-      gnumach
-    <mcsim> braunr: thank you
-    <braunr> if you see anything strange in the default pager, don't hesitate
-      to talk about it
-    <mcsim> braunr: ok. I didn't finish with ext2fs yet.
-    <braunr> so it's a good thing you're aware of it now, before you begin
-      working on it :)
-    <mcsim> braunr: I'm working on ext2 now.
-    <braunr> yes i understand
-    <braunr> i meant "before beginning work on the default pager"
-    <mcsim> ok
-
-    <antrik> mcsim: BTW, we were mostly talking about readahead (pagein) over
-      the past weeks, so I wonder what the status on clustered page*out* is?...
-    <mcsim> antrik: I don't work on this, but following, I think, is an example
-      of *clustered* pageout: _pager_seqnos_memory_object_data_return: object =
-      113, seqno = 4, control = 120, start_address = 0, length = 8192, dirty =
-      1. This is an example of debugging printout that shows that pageout
-      manipulates with chunks bigger than page sized.
-    <mcsim> antrik: Another one with bigger length
-      _pager_seqnos_memory_object_data_return: object = 125, seqno = 124,
-      control = 132, start_address = 131072, length = 126976, dirty = 1, kcopy
-    <antrik> mcsim: that's odd -- I didn't know the functionality for that even
-      exists in our codebase...
-    <antrik> my understanding was that Mach always sends individual pageout
-      requests for ever single page it wants cleaned...
-    <antrik> (and this being the reason for the dreadful thread storms we are
-      facing...)
-    <braunr> antrik: ok
-    <braunr> antrik: yes that's what is happening
-    <braunr> the thread storms aren't that much of a problem now
-    <braunr> (by carefully throttling pageouts, which is a task i intend to
-      work on during the following months, this won't be an issue any more)
-
-
-## IRC, freenode, #hurd, 2012-07-19
-
-    <mcsim> I moved fatfs, ufs, isofs to new interface, corrected some errors
-      in other that I already moved, moved kernel to new interface (renamed
-      vm_advice to vm_advise and added rpcs memory_object_set_advice and
-      memory_object_get_advice). Made some changes in mechanism and tried to
-      finish ext2 translator.
-    <mcsim> braunr: I've got an issue with fictitious pages...
-    <mcsim> When I determine bounds of cluster in external object I never know
-      its actual size. So, mo_data_request call could ask data that are behind
-      object bounds. The problem is that pager returns data that it has and
-      because of this fictitious pages that were allocated are not freed.
-    <braunr> why don't you know the size ?
-    <mcsim> I see 2 solutions. First one is do not allocate fictitious pages at
-      all (but I think that there could be issues). Another lies in allocating
-      fictitious pages, but then freeing them with mo_data_lock.
-    <mcsim> braunr: Because pages does not inform kernel about object size.
-    <braunr> i don't understand what you mean
-    <mcsim> I think that second way is better.
-    <braunr> so how does it happen ?
-    <braunr> you get a page fault
-    <mcsim> Don't you understand problem or solutions?
-    <braunr> then a lookup in the map finds the map entry
-    <braunr> and the map entry gives you the link to the underlying object
-    <mcsim> from vm_object.h: 	vm_size_t		size;		/*
-      Object size (only valid if internal)				 */
-    <braunr> mcsim: ugh
-    <mcsim> For external they are either 0x8000 or 0x20000...
-    <braunr> and for internal ?
-    <braunr> i'm very surprised to learn that
-    <mcsim> braunr: for internal size is actual
-    <braunr> right sorry, wrong question
-    <braunr> did you find what 0x8000 and 0x20000 are ?
-    <mcsim> for external I met only these 2 magic numbers when printed out
-      arguments of functions _pager_seqno_memory_object_... when they were
-      called.
-    <braunr> yes but did you try to find out where they come from ?
-    <mcsim> braunr: no. I think that 0x2000(many zeros) is maximal possible
-      object size.
-    <braunr> what's the exact value ?
-    <mcsim> can't tell exactly :/ My hurd box has broken again.
-    <braunr> mcsim: how does the vm find the backing content then ?
-    <mcsim> braunr: Do you know if it is guaranteed that map_entry size will be
-      not bigger than external object size?
-    <braunr> mcsim: i know it's not
-    <braunr> but you can use the map entry boundaries though
-    <mcsim> braunr: vm asks pager
-    <braunr> but if the page is already present
-    <braunr> how does it know ?
-    <braunr> it must be inside a vm_object ..
-    <mcsim> If I can use these boundaries than the problem, I described is not
-      actual.
-    <braunr> good
-    <braunr> it makes sense to use these boundaries, as the application can't
-      use data outside the mapping
-    <mcsim> I ask page with vm_page_lookup
-    <braunr> it would matter for shared objects, but then they have their own
-      faults :p
-    <braunr> ok
-    <braunr> so the size is actually completely ignord
-    <mcsim> if it is present than I stop expansion of cluster.
-    <braunr> which makes sense
-    <mcsim> braunr: yes, for external.
-    <braunr> all right
-    <braunr> use the mapping boundaries, it will do
-    <braunr> mcsim: i have only one comment about what i could see
-    <braunr> mcsim: there are 'advice' fields in both vm_map_entry and
-      vm_object
-    <braunr> there should be something else in vm_object
-    <braunr> i told you about pages before and after
-    <braunr> mcsim: how are you using this per object "advice" currently ?
-    <braunr> (in addition, using the same name twice for both mechanism and
-      policy is very sonfusing)
-    <braunr> confusing*
-    <mcsim> braunr: I try to expand cluster as much as it possible, but not
-      much than limit
-    <mcsim> they both determine policy, but advice for entry has bigger
-      priority
-    <braunr> that's wrong
-    <braunr> mapping and content shouldn't compete for policy
-    <braunr> the mapping tells the policy (=the advice) while the content tells
-      how to implement (e.g. how much content)
-    <braunr> IMO, you could simply get rid of the per object "advice" field and
-      use default values for now
-    <mcsim> braunr: What sense these values for number of pages before and
-      after should have?
-    <braunr> or use something well known, easy, and effective like preceding
-      and following pages
-    <braunr> they give the vm the amount of content to ask the backing pager
-    <mcsim> braunr: maximal amount, minimal amount or exact amount?
-    <braunr> neither
-    <braunr> that's why i recommend you forget it for now
-    <braunr> but
-    <braunr> imagine you implement the three standard policies (normal, random,
-      sequential)
-    <braunr> then the pager assigns preceding and following numbers for each of
-      them, say [5;5], [0;0], [15;15] respectively
-    <braunr> these numbers would tell the vm how many pages to ask the pagers
-      in a single request and from where
-    <mcsim> braunr: but in fact there could be much more policies.
-    <braunr> yes
-    <mcsim> also in kernel context there is no such unit as pager.
-    <braunr> so there should be a call like memory_object_set_advice(int
-      advice, int preceding, int following);
-    <braunr> for example
-    <braunr> what ?
-    <braunr> the pager is the memory manager
-    <braunr> it does exist in kernel context
-    <braunr> (or i don't understand what you mean)
-    <mcsim> there is only port, but port could be either pager or something
-      else
-    <braunr> no, it's a pager
-    <braunr> it's a port whose receive right is hold by a task implementing the
-      pager interface
-    <braunr> either the default pager or an untrusted task
-    <braunr> (or null if the object is anonymous memory not yet sent to the
-      default pager)
-    <mcsim> port is always pager?
-    <braunr> the object port is, yes
-    <braunr>         struct ipc_port         *pager;         /* Where to get
-      data */
-    <mcsim> So, you suggest to keep set of advices for each object?
-    <braunr> i suggest you don't change anything in objects for now
-    <braunr> keep the advice in the mappings only, and implement default
-      behaviour for the known policies
-    <braunr> mcsim: if you understand this point, then i have nothing more to
-      say, and we should let nowhere_man present his work
-    <mcsim> braunr: ok. I'll implement only default behaviors for know policies
-      for now.
-    <braunr> (actually, using the mapping boundaries is slightly unoptimal, as
-      we could have several mappings for the same content, e.g. a program with
-      read only executable mapping, then ro only)
-    <braunr> mcsim: another way to know the "size" is to actually lookup for
-      pages in objects
-    <braunr> hm no, that's not true
-    <mcsim> braunr: But if there is no page we have to ask it
-    <mcsim> and I don't understand why using mappings boundaries is unoptimal
-    <braunr> here is bash
-    <braunr> 0000000000400000    868K r-x--  /bin/bash
-    <braunr> 00000000006d9000     36K rw---  /bin/bash
-    <braunr> two entries, same file
-    <braunr> (there is the anonymous memory layer for the second, but it would
-      matter for the first cow faults)
-
-
-## IRC, freenode, #hurd, 2012-08-02
-
-    <mcsim> braunr: You said that I probably need some support in vm_pageout.c
-      to make defpager work with clustered page transfers, but TBH I thought
-      that I have to implement only pagein. Do you expect from me implementing
-      pageout either? Or I misunderstand role of vm_pageout.c?
-    <braunr> no
-    <braunr> you're expected to implement only pagins for now
-    <braunr> pageins
-    <mcsim> well, I'm finishing merging of ext2fs patch for large stores and
-      work on defpager in parallel.
-    <mcsim> braunr: Also I didn't get your idea about configuring of paging
-      mechanism on behalf of pagers.
-    <braunr> which one ?
-    <mcsim> braunr: You said that pager has somehow pass size of desired
-      clusters for different paging policies.
-    <braunr> mcsim: i said not to care about that
-    <braunr> and the wording isn't correct, it's not "on behalf of pagers"
-    <mcsim> servers?
-    <braunr> pagers could tell the kernel what size (before and after a faulted
-      page) they prefer for each existing policy
-    <braunr> but that's one way to do it
-    <braunr> defaults work well too
-    <braunr> as shown in other implementations
-
-
-## IRC, freenode, #hurd, 2012-08-09
-
-    <mcsim> braunr: I'm still debugging ext2 with large storage patch
-    <braunr> mcsim: tough problems ?
-    <mcsim> braunr: The same issues as I always meet when do debugging, but it
-      takes time.
-    <braunr> mcsim: so nothing blocking so far ?
-    <mcsim> braunr: I can't tell you for sure that I will finish up to 13th of
-      August and this is unofficial pencil down date.
-    <braunr> all right, but are you blocked ?
-    <mcsim> braunr: If you mean the issues that I can not even imagine how to
-      solve than there is no ones.
-    <braunr> good
-    <braunr> mcsim: i'll try to review your code again this week end
-    <braunr> mcsim: make sure to commit everything even if it's messy
-    <mcsim> braunr: ok
-    <mcsim> braunr: I made changes to defpager, but I haven't tried
-      them. Commit them too?
-    <braunr> mcsim: sure
-    <braunr> mcsim: does it work fine without the large storage patch ?
-    <mcsim> braunr: looks fine, but TBH I can't even run such things like fsx,
-      because even without my changes it failed mightily at once.
-
-[[file_system_exerciser]].
-
-    <braunr> mcsim: right, well, that will be part of another task :)
-
-
-## IRC, freenode, #hurd, 2012-08-13
-
-    <mcsim> braunr: hello. Seems ext2fs with large store patch works.
-
-
-## IRC, freenode, #hurd, 2012-08-19
-
-    <mcsim> hello. Consider such situation. There is a page fault and kernel
-      decided to request pager for several pages, but at the moment pager is
-      able to provide only first pages, the rest ones are not know yet. Is it
-      possible to supply only one page and regarding rest ones tell the kernel
-      something like: "Rest pages try again later"?
-    <mcsim> I tried pager_data_unavailable && pager_flush_some, but this seems
-      does not work.
-    <mcsim> Or I have to supply something anyway?
-    <braunr> mcsim: better not provide them
-    <braunr> the kernel only really needs one page
-    <braunr> don't try to implement "try again later", the kernel will do that
-      if other page faults occur for those pages
-    <mcsim> braunr: No, translator just hangs
-    <braunr> ?
-    <mcsim> braunr: And I even can't deattach it without reboot
-    <braunr> hangs when what 
-    <braunr> ?
-    <braunr> i mean, what happens when it hangs ?
-    <mcsim> If kernel request 2 pages and I provide one, than when page fault
-      occurs in second page translator hangs.
-    <braunr> well that's a bug
-    <braunr> clustered pager transfer is a mere optimization, you shouldn't
-      transfer more than you can just to satisfy some requested size
-    <mcsim> I think that it because I create fictitious pages before calling
-      mo_data_request
-    <braunr> as placeholders ?
-    <mcsim> Yes. Is it correct if I will not grab fictitious pages?
-    <braunr> no
-    <braunr> i don't know the details well enough about fictitious pages
-      unfortunately, but it really feels wrong to use them where real physical
-      pages should be used instead
-    <braunr> normally, an in-transfer page is simply marked busy
-    <mcsim> But If page is already marked busy kernel will not ask it another
-      time.
-    <braunr> when the pager replies, you unbusy them
-    <braunr> your bug may be that you incorrectly use pmap
-    <braunr> you shouldn't create mmu mappings for pages you didn't receive
-      from the pagers
-    <mcsim> I don't create them
-    <braunr> ok so you correctly get the second page fault
-    <mcsim> If pager supplies only first pages, when asked were two, than
-      second page will not become un-busy.
-    <braunr> that's a bug
-    <braunr> your code shouldn't assume the pager will provide all the pages it
-      was asked for
-    <braunr> only the main one
-    <mcsim> Will it be ok if I will provide special attribute that will keep
-      information that page has been advised?
-    <braunr> what for ?
-    <braunr> i don't understand "page has been advised"
-    <mcsim> Advised page is page that is asked in cluster, but there wasn't a
-      page fault in it.
-    <mcsim> I need this attribute because if I don't inform kernel about this
-      page anyhow, than kernel will not change attributes of this page.
-    <braunr> why would it change its attributes ?
-    <mcsim> But if page fault will occur in page that was asked than page will
-      be already busy by the moment.
-    <braunr> and what attribute ?
-    <mcsim> advised
-    <braunr> i'm lost
-    <braunr> 08:53 < mcsim> I need this attribute because if I don't inform
-      kernel about this page anyhow, than kernel will not change attributes of
-      this page.
-    <braunr> you need the advised attribute because if you don't inform the
-      kernel about this page, the kernel will not change the advised attribute
-      of this page ?
-    <mcsim> Not only advised, but busy as well.
-    <mcsim> And if page fault will occur in this page, kernel will not ask it
-      second time. Kernel will just block.
-    <braunr> well that's normal
-    <mcsim> But if kernel will block and pager is not going to report somehow
-      about this page, than translator will hang.
-    <braunr> but the pager is going to report
-    <braunr> and in this report, there can be less pages then requested
-    <mcsim> braunr: You told not to report
-    <braunr> the kernel can deduce it didn't receive all the pages, and mark
-      them unbusy anyway
-    <braunr> i told not to transfer more than requested
-    <braunr> but not sending data can be a form of communication
-    <braunr> i mean, sending a message in which data is missing
-    <braunr> it simply means its not there, but this info is sufficient for the
-      kernel
-    <mcsim> hmmm... Seems I understood you. Let me try something.
-    <mcsim> braunr: I informed kernel about missing page as follows:
-      pager_data_supply (pager, precious, writelock, i, 1, NULL, 0); Am I
-      right?
-    <braunr> i don't know the interface well
-    <braunr> what does it mean 
-    <braunr> ?
-    <braunr> are you passing NULL as the data for a missing page ?
-    <mcsim> yes
-    <braunr> i see
-    <braunr> you shouldn't need a request for that though, avoiding useless ipc
-      is a good thing
-    <mcsim> i is number of page, 1 is quantity
-    <braunr> but if you can't find a better way for now, it will do
-    <mcsim> But this does not work :(
-    <braunr> that's a bug
-    <braunr> in your code probably
-    <mcsim> braunr: supplying NULL as data returns MACH_SEND_INVALID_MEMORY
-    <braunr> but why would it work ?
-    <braunr> mach expects something
-    <braunr> you have to change that
-    <mcsim> It's mig who refuses data. Mach does not even get the call.
-    <braunr> hum
-    <mcsim> That's why I propose to provide new attribute, that will keep
-      information regarding whether the page was asked as advice or not.
-    <braunr> i still don't understand why
-    <braunr> why don't you fix mig so you can your null message instead ?
-    <braunr> +send
-    <mcsim> braunr: because usually this is an error
-    <braunr> the kernel will decide if it's an erro
-    <braunr> r
-    <braunr> what kinf of reply do you intend to send the kernel with for these
-      "advised" pages ?
-    <mcsim> no reply. But when page fault will occur in busy page and it will
-      be also advised, kernel will not block, but ask this page another time.
-    <mcsim> And how kernel will know that this is an error or not?
-    <braunr> why ask another time ?!
-    <braunr> you really don't want to flood pagers with useless messages
-    <braunr> here is how it should be
-    <braunr> 1/ the kernel requests pages from the pager
-    <braunr> it know the range
-    <braunr> 2/ the pager replies what it can, full range, subset of it, even
-      only one page
-    <braunr> 3/ the kernel uses what the pager replied, and unbusies the other
-      pages
-    <mcsim> First time page was asked because page fault occurred in
-      neighborhood. And second time because PF occurred in page. 
-    <braunr> well it shouldn't
-    <braunr> or it should, but then you have a segfault
-    <mcsim> But kernel does not keep bound of range, that it asked.
-    <braunr> if the kernel can't find the main page, the one it needs to make
-      progress, it's a segfault
-    <mcsim> And this range could be supplied in several messages.
-    <braunr> absolutely not
-    <braunr> you defeat the purpose of clustered pageins if you use several
-      messages
-    <mcsim> But interface supports it
-    <braunr> interface supported single page transfers, doesn't mean it's good
-    <braunr> well, you could use several messages
-    <braunr> as what we really want is less I/O
-    <mcsim> Noone keeps bounds of requested range, so it couldn't be checked
-      that range was split 
-    <braunr> but it would be so much better to do it all with as few messages
-      as possible
-    <braunr> does the kernel knows the main page ?
-    <braunr> know*
-    <mcsim> Splitting range is not optimal, but it's not an error.
-    <braunr> i assume it does
-    <braunr> doesn't it ?
-    <mcsim> no, that's why I want to provide new attribute.
-    <braunr> i'm sorry i'm lost again
-    <braunr> how does the kernel knows a page fault has been serviced ?
-    <braunr> know*
-    <mcsim> It receives an interrupt
-    <braunr> ?
-    <braunr> let's not mix terms
-    <mcsim> oh.. I read as received. Sorry
-    <mcsim> It get mo_data_supply message. Than it replaces fictitious pages
-      with real ones.
-    <braunr> so you get a message
-    <braunr> and you kept track of the range using fictitious pages
-    <braunr> use the busy flag instead, and another way to retain the range
-    <mcsim> I allocate fictitious pages to reserve place. Than if page fault
-      will occur in this page fictitious page kernel will not send another
-      mo_data_request call, it will wait until fictitious page unblocks.
-    <braunr> i'll have to check the code but it looks unoptimal to me
-    <braunr> we really don't want to allocate useless objects when a simple
-      busy flag would do
-    <mcsim> busy flag for what? There is no page yet
-    <braunr> we're talking about mo_data_supply
-    <braunr> actually we're talking about the whole page fault process
-    <mcsim> We can't mark nothing as busy, that's why kernel allocates
-      fictitious page and marks it as busy until real page would be supplied.
-    <braunr> what do you mean "nothing" ?
-    <mcsim> VM_PAGE_NULL
-    <braunr> uh ?
-    <braunr> when are physical pages allocated ?
-    <braunr> on request or on reply from the pager ?
-    <braunr> i'm reading mo_data_supply, and it looks like the page is already
-      busy at that time
-    <mcsim> they are allocated by pager and than supplied in reply
-    <mcsim> Yes, but these pages are fictitious
-    <braunr> show me please
-    <braunr> in the master branch, not yours
-    <mcsim> that page is fictitious?
-    <braunr> yes
-    <braunr> i'm referring to the way mach currently does things
-    <mcsim> vm/vm_fault.c:582
-    <braunr> that's memory_object_lock_page
-    <braunr> hm wait
-    <braunr> my bad
-    <braunr> ah that damn object chaining :/
-    <braunr> ok
-    <braunr> the original code is stupid enough to use fictitious pages all the
-      time, you probably have to do the same
-    <mcsim> hm... Attributes will be useless, pager should tell something about
-      pages, that it is not going to supply.
-    <braunr> yes
-    <braunr> that's what null is for
-    <mcsim> Not null, null is error.
-    <braunr> one problem i can think of is making sure the kernel doesn't
-      interpret missing as error
-    <braunr> right
-    <mcsim> I think better have special value for mo_data_error
-    <braunr> probably
-
-
-### IRC, freenode, #hurd, 2012-08-20
-
-    <antrik> braunr: I think it's useful to allow supplying the data in several
-      batches. the kernel should *not* assume that any data missing in the
-      first batch won't be supplied later.
-    <braunr> antrik: it really depends
-    <braunr> i personally prefer synchronous approaches
-    <antrik> demanding that all data is supplied at once could actually turn
-      readahead into a performace killer
-    <mcsim> antrik: Why? The only drawback I see is higher response time for
-      page fault, but it also leads to reduced overhead.
-    <braunr> that's why "it depends"
-    <braunr> mcsim: it brings benefit only if enough preloaded pages are
-      actually used to compensate for the time it took the pager to provide
-      them
-    <braunr> which is the case for many workloads (including sequential access,
-      which is the common case we want to optimize here)
-    <antrik> mcsim: the overhead of an extra RPC is negligible compared to
-      increased latencies when dealing with slow backing stores (such as disk
-      or network)
-    <mcsim> antrik: also many replies lead to fragmentation, while in one reply
-      all data is gathered in one bunch. If all data is placed consecutively,
-      than it may be transferred next time faster.
-    <braunr> mcsim: what kind of fragmentation ?
-    <antrik> I really really don't think it's a good idea for the page to hold
-      back the first page (which is usually the one actually blocking) while
-      it's still loading some other pages (which will probably be needed only
-      in the future anyways, if at all)
-    <antrik> err... for the pager to hold back
-    <braunr> antrik: then all pagers should be changed to handle asynchronous
-      data supply
-    <braunr> it's a bit late to change that now
-    <mcsim> there could be two cases of data placement in backing store: 1/ all
-      asked data is placed consecutively; 2/ it is spread among backing
-      store. If pager gets data in one message it more like place it
-      consecutively. So to have data consecutive in each pager, each pager has
-      to try send data in one message. Having data placed consecutive is
-      important, since reading of such data is much more faster.
-    <braunr> mcsim: you're confusing things ..
-    <braunr> or you're not telling them properly
-    <mcsim> Ok. Let me try one more time
-    <braunr> since you're working *only* on pagein, not pageout, how do you
-      expect spread pages being sent in a single message be better than
-      multiple messages ?
-    <mcsim> braunr: I think about future :)
-    <braunr> ok
-    <braunr> but antrik is right, paging in too much can reduce performance
-    <braunr> so the default policy should be adjusted for both the worst case
-      (one page) and the average/best (some/mane contiguous pages)
-    <braunr> through measurement ideally
-    <antrik> mcsim: BTW, I still think implementing clustered pageout has
-      higher priority than implementing madvise()... but if the latter is less
-      work, it might still make sense to do it first of course :-)
-    <braunr> many*
-    <braunr> there aren't many users of madvise, true
-    <mcsim> antrik: Implementing madvise I expect to be very simple. It should
-      just translate call to vm_advise
-    <antrik> well, that part is easy of course :-) so you already implemented
-      vm_advise itself I take it?
-    <mcsim> antrik: Yes, that was also quite easy.
-    <antrik> great :-)
-    <antrik> in that case it would be silly of course to postpone implementing
-      the madvise() wrapper. in other words: never mind my remark about
-      priorities :-)
-
-
-## IRC, freenode, #hurd, 2012-09-03
-
-    <mcsim> I try a test with ext2fs. It works, than I just recompile ext2fs
-      and it stops working, than I recompile it again several times and each
-      time the result is unpredictable.
-    <braunr> sounds like a concurrency issue
-    <mcsim> I can run the same test several times and ext2 works until I
-      recompile it. That's the problem. Could that be concurrency too?
-    <braunr> mcsim: without bad luck, yes, unless "several times" is a lot
-    <braunr> like several dozens of tries
-
-
-## IRC, freenode, #hurd, 2012-09-04
-
-    <mcsim> hello. I want to tell that ext2fs translator, that I work on,
-      replaced for my system old variant that processed only single pages
-      requests. And it works with partitions bigger than 2 Gb.
-    <mcsim> Probably I'm not for from the end.
-    <mcsim> But it's worth to mention that I didn't fix that nasty bug that I
-      told yesterday about.
-    <mcsim> braunr: That bug sometimes appears after recompilation of ext2fs
-      and always disappears after sync or reboot. Now I'm going to finish
-      defpager and test other translators.
-
-
-## IRC, freenode, #hurd, 2012-09-17
-
-    <mcsim> braunr: hello. Do you remember that you said that pager has to
-      inform kernel about appropriate cluster size for readahead?
-    <mcsim> I don't understand how kernel store this information, because it
-      does not know about such unit as "pager".
-    <mcsim> Can you give me an advice about how this could be implemented?
-    <youpi> mcsim: it can store it in the object
-    <mcsim> youpi: It too big overhead
-    <mcsim> youpi: at least from my pow
-    <mcsim> *pov
-    <braunr> mcsim: we discussed this already
-    <braunr> mcsim: there is no "pager" entity in the kernel, which is a defect
-      from my PoV
-    <braunr> mcsim: the best you can do is follow what the kernel already does
-    <braunr> that is, store this property per object$
-    <braunr> we don't care much about the overhead for now
-    <braunr> my guess is there is already some padding, so the overhead is
-      likely to be amortized by this
-    <braunr> like youpi said
-    <mcsim> I remember that discussion, but I didn't get than whether there
-      should be only one or two values for all policies. Or each policy should
-      have its own values?
-    <mcsim> braunr: ^
-    <braunr> each policy should have its own values, which means it can be
-      implemented with a simple static array somewhere
-    <braunr> the information in each object is a policy selector, such as an
-      index in this static array
-    <mcsim> ok
-    <braunr> mcsim: if you want to minimize the overhead, you can make this
-      selector a char, and place it near another char member, so that you use
-      space that was previously used as padding by the compiler
-    <braunr> mcsim: do you see what i mean ?
-    <mcsim> yes
-    <braunr> good
-
-
-## IRC, freenode, #hurd, 2012-09-17
-
-    <mcsim> hello. May I add function krealloc to slab.c?
-    <braunr> mcsim: what for ?
-    <mcsim> braunr: It is quite useful for creating dynamic arrays
-    <braunr> you don't want dynamic arrays
-    <mcsim> why?
-    <braunr> they're expensive
-    <braunr> try other data structures
-    <mcsim> more expensive than linked lists?
-    <braunr> depends
-    <braunr> but linked lists aren't the only other alternative
-    <braunr> that's why btrees and radix trees (basically trees of arrays)
-      exist
-    <braunr> the best general purpose data structure we have in mach is the red
-      black tree currently
-    <braunr> but always think about what you want to do with it
-    <mcsim> I want to store there sets of sizes for different memory
-      policies. I don't expect this array to be big. But for sure I can use
-      rbtree for it.
-    <braunr> why not a static array ?
-    <braunr> arrays are perfect for known data sizes
-    <mcsim> I expect from pager to supply its own sizes. So at the beginning in
-      this array is only default policy. When pager wants to supply it own
-      policy kernel lookups table of advice. If this policy is new set of sizes
-      then kernel creates new entry in table of advice.
-    <braunr> that would mean one set of sizes for each object
-    <braunr> why don't you make things simple first ?
-    <mcsim> Object stores only pointer to entry in this table.
-    <braunr> but there is no pager object shared by memory objects in the
-      kernel
-    <mcsim> I mean struct vm_object
-    <braunr> so that's what i'm saying, one set per object
-    <braunr> it's useless overhead
-    <braunr> i would really suggest using a global set of policies for now
-    <mcsim> Probably, I don't understand you. Where do you want to store this
-      static array?
-    <braunr> it's a global one
-    <mcsim> "for now"? It is not a problem to implement a table for local
-      advice, using either rbtree or dynamic array.
-    <braunr> it's useless overhead
-    <braunr> and it's not a single integer, you want a whole container per
-      object
-    <braunr> don't do anything fancy unless you know you really want it
-    <braunr> i'll link the netbsd code again as a very good example of how to
-      implement global policies that work more than decently for every file
-      system in this OS
-    <braunr>
-      http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/uvm/uvm_fault.c?rev=1.194&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
-    <braunr> look for uvmadvice
-    <mcsim> But different translators have different demands. Thus changing of
-      global policy for one translator would have impact on behavior of another
-      one.
-    <braunr> i understand
-    <braunr> this isn't l4, or anything experimental
-    <braunr> we want something that works well for us
-    <mcsim> And this is acceptable?
-    <braunr> until you're able to demonstrate we need different policies, i'd
-      recommend not making things more complicated than they already are and
-      need to be
-    <braunr> why wouldn't it ?
-    <braunr> we've been discussing this a long time :/
-    <mcsim> because every process runs in isolated environment and the fact
-      that there is something outside this environment, that has no rights to
-      do that, does it surprises me.
-    <braunr> ?
-    <mcsim> ok. let me dip in uvm code. Probably my questions disappear
-    <braunr> i don't think it will
-    <braunr> you're asking about the system design here, not implementation
-      details
-    <braunr> with l4, there are as you'd expect well defined components
-      handling policies for address space allocation, or paging, or whatever
-    <braunr> but this is mach
-    <braunr> mach has a big shared global vm server with in kernel policies for
-      it
-    <braunr> so it's ok to implement a global policy for this
-    <braunr> and let's be pragmatic, if we don't need complicated stuff, why
-      would we waste time on this ?
-    <mcsim> It is not complicated.
-    <braunr> retaining a whole container for each object, whereas they're all
-      going to contain exactly the same stuff for years to come seems overly
-      complicated for me
-    <mcsim> I'm not going to create separate container for each object.
-    <braunr> i'm not following you then
-    <braunr> how can pagers upload their sizes in the kernel ?
-    <mcsim> I'm going to create a new container only for combination of cluster
-      sizes that are not present in table of advice.
-    <braunr> that's equivalent
-    <braunr> you're ruling out the default set, but that's just an optimization
-    <braunr> whenever a file system decides to use other sizes, the problem
-      will arise
-    <mcsim> Before creating a container I'm going to lookup a table. And only
-      than create
-    <braunr> a table ?
-    <mcsim> But there will be the same container for a huge bunch of objects
-    <braunr> how do you select it ?
-    <braunr> if it's a per pager container, remember there is no shared pager
-      object in the kernel, only ports to external programs
-    <mcsim> I'll give an example
-    <mcsim> Suppose there are only two policies. At the beginning we have table
-      {{random = 4096, sequential = 8096}}. Than pager 1 wants to add new
-      policy where random cluster size is 8192. He asks kernel to create it and
-      after this table will be following: {{random = 4096, sequential = 8192},
-      {random = 8192, sequential = 8192}}. If pager 2 wants to create the same
-      policy as pager 1, kernel will lockup table and will not create new
-      entry. So the table will be the same.
-    <mcsim> And each object has link to appropriate table entry
-    <braunr> i'm not sure how this can work
-    <braunr> how can pagers 1 and 2 know the sizes are the same for the same
-      policy ?
-    <braunr> (and actually they shouldn't)
-    <mcsim> For faster lookup there will be create hash keys for each entry
-    <braunr> what's the lookup key ?
-    <mcsim> They do not know
-    <mcsim> The kernel knows
-    <braunr> then i really don't understand
-    <braunr> and how do you select sizes based on the policy ?
-    <braunr> and how do you remove unused entries ?
-    <braunr> (ok this can be implemented with a simple ref counter)
-    <mcsim> "and how do you select sizes based on the policy ?" you mean at
-      page fault?
-    <braunr> yes
-    <mcsim> entry or object keeps pointer to appropriate entry in the table
-    <braunr> ok your per object data is a pointer to the table entry and the
-      policy is the index inside
-    <braunr> so you really need a ref counter there
-    <mcsim> yes
-    <braunr> and you need to maintain this table
-    <braunr> for me it's uselessly complicated
-    <mcsim> but this keeps design clear
-    <braunr> not for me
-    <braunr> i don't see how this is clearer
-    <braunr> it's just more powerful
-    <braunr> a power we clearly don't need now
-    <braunr> and in the following years
-    <braunr> in addition, i'm very worried about the potential problems this
-      can introduce
-    <mcsim> In fact I don't feel comfortable from the thought that one
-      translator can impact on behavior of another.
-    <braunr> simple example: the table is shared, it needs a lock, other data
-      structures you may have added in your patch may also need a lock
-    <braunr> but our locks are noop for now, so you just can't be sure there is
-      no deadlock or other issues
-    <braunr> and adding smp is a *lot* more important than being able to select
-      precisely policy sizes that we're very likely not to change a lot
-    <braunr> what do you mean by "one translator can impact another" ?
-    <mcsim> As I understand your idea (I haven't read uvm code yet) that there
-      is a global table of cluster sizes for different policies. And every
-      translator can change values in this table. That is what I mean under one
-      translator will have an impact on another one.
-    <braunr> absolutely not
-    <braunr> translators *can't* change sizes
-    <braunr> the sizes are completely static, assumed to be fit all
-    <braunr> -be
-    <braunr> it's not optimial but it's very simple and effective in practice
-    <braunr> optimal*
-    <braunr> and it's not a table of cluster sizes
-    <braunr> it's a table of pages before/after the faulted one
-    <braunr> this reflects the fact tha in mach, virtual memory (implementation
-      and policy) is in the kernel
-    <braunr> translators must not be able to change that
-    <braunr> let's talk about pagers here, not translators
-    <mcsim> Finally I got you. This is an acceptable tradeoff.
-    <braunr> it took some time :)
-    <braunr> just to clear something
-    <braunr> 20:12 < mcsim> For faster lookup there will be create hash keys
-      for each entry
-    <braunr> i'm not sure i understand you here
-    <mcsim> To found out if there is such policy (set of sizes) in the table we
-      can lookup every entry and compare each value. But it is better to create
-      a hash value for set and thus find equal policies.
-    <braunr> first, i'm really not comfortable with hash tables
-    <braunr> they really need careful configuration
-    <braunr> next, as we don't expect many entries in this table, there is
-      probably no need for this overhead
-    <braunr> remember that one property of tables is locality of reference
-    <braunr> you access the first entry, the processor automatically fills a
-      whole cache line
-    <braunr> so if your table fits on just a few, it's probably faster to
-      compare entries completely than to jump around in memory
-    <mcsim> But we can sort hash keys, and in this way find policies quickly.
-    <braunr> cache misses are way slower than computation
-    <braunr> so unless you have massive amounts of data, don't use an optimized
-      container
-    <mcsim> (20:38:53) braunr: that's why btrees and radix trees (basically
-      trees of arrays) exist
-    <mcsim> and what will be the key?
-    <braunr> i'm not saying to use a tree instead of a hash table
-    <braunr> i'm saying, unless you have many entries, just use a simple table
-    <braunr> and since pagers don't add and remove entries from this table
-      often, it's on case reallocation is ok
-    <braunr> one*
-    <mcsim> So here dynamic arrays fit the most?
-    <braunr> probably
-    <braunr> it really depends on the number of entries and the write ratio
-    <braunr> keep in mind current processors have 32-bits or (more commonly)
-      64-bits cache line sizes
-    <mcsim> bytes probably?
-    <braunr> yes bytes
-    <braunr> but i'm not willing to add a realloc like call to our general
-      purpose kernel allocator
-    <braunr> i don't want to make it easy for people to rely on it, and i hope
-      the lack of it will make them think about other solutions instead :)
-    <braunr> and if they really want to, they can just use alloc/free
-    <mcsim> Under "other solutions" you mean trees?
-    <braunr> i mean anything else :)
-    <braunr> lists are simple, trees are elegant (but add non negligible
-      overhead)
-    <braunr> i like trees because they truely "gracefully" scale
-    <braunr> but they're still O(log n)
-    <braunr> a good hash table is O(1), but must be carefully measured and
-      adjusted
-    <braunr> there are many other data structures, many of them you can find in
-      linux
-    <braunr> but in mach we don't need a lot of them
-    <mcsim> Your favorite data structures are lists and trees. Next, what
-      should you claim, is that lisp is your favorite language :)
-    <braunr> functional programming should eventually rule the world, yes
-    <braunr> i wouldn't count lists are my favorite, which are really trees
-    <braunr> as*
-    <braunr> there is a reason why red black trees back higher level data
-      structures like vectors or maps in many common libraries ;)
-    <braunr> mcsim: hum but just to make it clear, i asked this question about
-      hashing because i was curious about what you had in mind, i still think
-      it's best to use static predetermined values for policies
-    <mcsim> braunr: I understand this.
-    <braunr> :)
-    <mcsim> braunr: Yeah. You should be cautious with me :)
-
-
-## IRC, freenode, #hurd, 2012-09-21
-
-    <antrik> mcsim: there is only one cluster size per object -- it depends on
-      the properties of the backing store, nothing else.
-    <antrik> (while the readahead policies depend on the use pattern of the
-      application, and thus should be selected per mapping)
-    <antrik> but I'm still not convinced it's worthwhile to bother with cluster
-      size at all. do other systems even do that?...
-
-
-## IRC, freenode, #hurd, 2012-09-23
-
-    <braunr> mcsim: how long do you think it will take you to polish your gsoc
-      work ?
-    <braunr> (and when before you begin that part actually, because we'll to
-      review the whole stuff prior to polishing it)
-    <mcsim> braunr: I think about 2 weeks
-    <mcsim> But you may already start review it, if you're intended to do it
-      before I'll rearrange commits.
-    <mcsim> Gnumach, ext2fs and defpager are ready. I just have to polish the
-      code.
-    <braunr> mcsim: i don't know when i'll be able to do that
-    <braunr> so expect a few weeks on my (our) side too
-    <mcsim> ok
-    <braunr> sorry for being slow, that's how hurd development is :)
-    <mcsim> What should I do with libc patch that adds madvise support?
-    <mcsim> Post it to bug-hurd?
-    <braunr> hm probably the same i did for pthreads, create a topic branch in
-      glibc.git
-    <mcsim> there is only one commit
-    <braunr> yes
-    <braunr> (mine was a one liner :p)
-    <mcsim> ok
-    <braunr> it will probably be a debian patch before going into glibc anyway,
-      just for making sure it works
-    <mcsim> But according to term. I expect that my study begins in a week and
-      I'll have to do some stuff then, so actually probably I'll need a week
-      more.
-    <braunr> don't worry, that's expected
-    <braunr> and that's the reason why we're slow
-    <mcsim> And what should I do with large store patch?
-    <braunr> hm good question
-    <braunr> what did you do for now ?
-    <braunr> include it in your work ?
-    <braunr> that's what i saw iirc
-    <mcsim> Yes. It consists of two parts.
-    <braunr> the original part and the modificaionts ?
-    <braunr> modifications*
-    <braunr> i think youpi would know better about that
-    <mcsim> First (small) adds notification to libpager interface and second
-      one adds support for large stores.
-    <braunr> i suppose we'll probably merge the large store patch at some point
-      anyway
-    <mcsim> Yes both original and modifications
-    <braunr> good
-    <mcsim> I'll split these parts to different commits and I'll try to make
-      support for large stores independent from other work.
-    <braunr> that would be best
-    <braunr> if you can make it so that, by ommitting (or including) one patch,
-      we can add your patches to the debian package, it would be great
-    <braunr> (only with regard to the large store change, not other potential
-      smaller conflicts)
-    <mcsim> braunr: I also found several bugs in defpager, that I haven't fixed
-      since winter.
-    <braunr> oh
-    <mcsim> seems nobody hasn't expect them.
-    <braunr> i'm very interested in those actually (not too soon because it
-      concerns my work on pageout, which is postponed after pthreads and
-      select)
-    <mcsim> ok. than I'll do it first.
-
-
-## IRC, freenode, #hurd, 2012-09-24
-
-    <braunr> mcsim: what is vm_get_advice_info ?
-    <mcsim> braunr: hello. It should supply some machine specific parameters
-      regarding clustered reading. At the moment it supplies only maximal
-      possible size of cluster.
-    <braunr> mcsim: why such a need ?
-    <mcsim> It is used by defpager, as it can't allocate memory dynamically and
-      every thread has to allocate maximal size beforehand 
-    <braunr> mcsim: i see
-
-
-## IRC, freenode, #hurd, 2012-10-05
-
-    <mcsim> braunr: I think it's not worth to separate large store patch for
-      ext2 and patch for moving it to new libpager interface. Am I right?
-    <braunr> mcsim: it's worth separating, but not creating two versions
-    <braunr> i'm not sure what you mean here
-    <mcsim> First, I applied large store patch, and than I was changing patched
-      code, to make it work with new libpager interface. So changes to make
-      ext2 work with new interface depend on large store patch.
-    <mcsim> braunr: ^
-    <braunr> mcsim: you're not forced to make each version resulting from a new
-      commit work
-    <braunr> but don't make big commits
-    <braunr> so if changing an interface requires its users to be updated
-      twice, it doesn't make sense to do that
-    <braunr> just update the interface cleanly, you'll have one or more commits
-      that produce intermediate version that don't build, that's ok
-    <braunr> then in another, separate commit, adjust the users
-    <mcsim> braunr: The only user now is ext2. And the problem with ext2 is
-      that I updated not the version from git repository, but the version, that
-      I've got after applying the large store patch. So in other words my
-      question is follows: should I make a commit that moves to new interface
-      version of ext2fs without large store patch?
-    <braunr> you're asking if you can include the large store patch in your
-      work, and by extension, in the main branch
-    <braunr> i would say yes, but this must be discussed with others
-
-
-## IRC, freenode, #hurd, 2013-02-18
-
-    <braunr> mcsim: so, currently reviewing gnumach
-    <mcsim> braunr: hello
-    <braunr> mcsim: the review branch, right ?
-    <mcsim> braunr: yes
-    <mcsim> braunr: What do you start with?
-    <braunr> memory refreshing
-    <braunr> i see you added the advice twice, to vm_object and vm_map_entry
-    <braunr> iirc, we agreed to only add it to map entries
-    <braunr> am i wrong ?
-    <mcsim> let me see
-    <braunr> the real question being: what do you use the object advice for ?
-    <mcsim> >iirc, we agreed to only add it to map entries
-    <mcsim> braunr: TBH, do not remember that. At some point we came to
-      conclusion that there should be only one advice. But I'm not sure if it
-      was final point.
-    <braunr> maybe it wasn't, yes
-    <braunr> that's why i've just reformulated the question
-    <mcsim>         if (map_entry && (map_entry->advice != VM_ADVICE_DEFAULT))
-    <mcsim>                 advice = map_entry->advice;
-    <mcsim>         else
-    <mcsim>                 advice = object->advice;
-    <braunr> ok
-    <mcsim> It just participates in determining actual advice 
-    <braunr> ok that's not a bad thing
-    <braunr> let's keep it
-    <braunr> please document VM_ADVICE_KEEP
-    <braunr> and rephrase "How to handle page faults" in vm_object.h to
-      something like 'How to tune page fault handling"
-    <braunr> mcsim: what's the point of VM_ADVICE_KEEP btw ?
-    <mcsim> braunr: Probably it is better to remove it?
-    <braunr> well if it doesn't do anything, probably
-    <mcsim> braunr: advising was part of mo_set_attributes before
-    <mcsim> no it is redudant
-    <braunr> i see
-    <braunr> so yes, remove it
-    <mcsim> s/no/now
-    <braunr> (don't waste time on a gcs-like changelog format for now)
-    <braunr> i also suggest creating _vX branches
-    <braunr> so we can compare the changes between each of your review branches
-    <braunr> hm, minor coding style issues like switch(...) instead of switch
-      (...)
-    <braunr> why does syscall_vm_advise return MACH_SEND_INTERRUPTED if the
-      target map is NULL ?
-    <braunr> is it modelled after an existing behaviour ?
-    <braunr> ah, it's the syscall version
-    <mcsim> braunr: every syscall does so
-    <braunr> and the error is supposed to be used by user stubs to switch to
-      the rpc version
-    <braunr> ok
-    <braunr> hm
-    <braunr> you've replaced obsolete port_set_select and port_set_backup calls
-      with your own
-    <braunr> don't do that
-    <braunr> instead, add your calls to the new gnumach interface
-    <braunr> mcsim: out of curiosity, have you actually tried the syscall
-      version ?
-    <mcsim> braunr: Isn't it called by default?
-    <braunr> i don't think so, no
-    <mcsim> than no
-    <braunr> ok
-    <braunr> you could name vm_get_advice_info vm_advice_info
-    <mcsim> regarding obsolete calls, did you say that only in regard of
-      port_set_* or all other calls too?
-    <braunr> all of the
-    <braunr> m
-    <braunr> i missed one, yes
-    <braunr> the idea is: don't change the existing interface
-    <mcsim> >you could name vm_get_advice_info vm_advice_info
-    <mcsim> could or should? i.e. rename?
-    <braunr> i'd say should, to remain consistent with the existing similar
-      calls
-    <mcsim> ok
-    <braunr> can you explain KERN_NO_DATA a bit more ?
-    <braunr> i suppose it's what servers should answer for neighbour pages that
-      don't exist in the backend, right ?
-    <mcsim> kernel can ask server for some data to read them beforehand, but
-      server can be in situation when it does not know what data should be
-      prefetched
-    <mcsim> yes
-    <braunr> ok
-    <mcsim> it is used by ext2 server
-    <mcsim> with large store patch
-    <braunr> so its purpose is to allow the kernel to free the preallocated
-      pages that won't be used
-    <braunr> do i get it right ?
-    <mcsim> no.
-    <mcsim> ext2 server has a buffer for pages and when kernel asks to read
-      pages ahead it specifies region of that buffer 
-    <braunr> ah ok
-    <mcsim> but consecutive pages in buffer does not correspond to consecutive
-      pages on disk
-    <braunr> so, the kernel can only prefetch pages that were already read by
-      the server ?
-    <mcsim> no, it can ask a server to prefetch pages that were not read by
-      server
-    <braunr> hum
-    <braunr> ok
-    <mcsim> but in case with buffer, if buffer page is empty, server does not
-      know what to prefetch
-    <braunr> i'm not sure i'm following
-    <braunr> well, i'm sure i'm not following
-    <braunr> what happens when the kernel requests data from a server, right
-      after a page fault ?
-    <braunr> what does the message afk for ?
-    <mcsim> kernel is unaware regarding actual size of file where was page
-      fault because of buffer indirection, right?
-    <braunr> i don't know what "buffer" refers to here
-    <mcsim> this is buffer in memory where ext2 server reads pages
-    <mcsim> with large store patch ext2 server does not map the whole disk, but
-      some of its pages
-    <mcsim> and it maps these pages in special buffer
-    <mcsim> that means that constructiveness of pages in memory does not mean
-      that they are consecutive on disk or logically (belong to the same file)
-    <braunr> ok so it's a page pool
-    <braunr> with unordered pages
-    <braunr> but what do you mean when you say "server does not know what to
-      prefetch"
-    <braunr> it normally has everything to determine that
-    <mcsim> For instance, page fault occurs that leads to reading of
-      4k-file. But kernel does not know actual size of file and asks to
-      prefetch 16K bytes
-    <braunr> yes
-    <mcsim> There is no sense to prefetch something that does not belong to
-      this file
-    <braunr> yes but the server *knows* that
-    <mcsim> and server answers with KERN_NO_DATA
-    <mcsim> server should always say something about every page that was asked 
-    <braunr> then, again, isn't the purpose of KERN_NO_DATA to notify the
-      kernel it can release the preallocated pages meant for the non existing
-      data ?
-    <braunr> (non existing or more generally non prefetchable)
-    <mcsim> yes
-    <braunr> then
-    <braunr> why did you answer no to
-    <braunr> 15:46 < braunr> so its purpose is to allow the kernel to free the
-      preallocated pages that won't be used
-    <braunr> is there something missing ?
-    <braunr> (well obviously, notify the kernel it can go on with page fault
-      handling)
-    <mcsim> braunr: sorry, misunderstoo/misread 
-    <braunr> ok
-    <braunr> so good, i got this right :)
-    <braunr> i wonder if KERN_NO_DATA may be a bit too vague
-    <braunr> people might confuse it with ENODATA
-    <mcsim> Actually, this is transformation of ENODATA
-    <mcsim> I was looking among POSIX error codes and thought that this is the
-      most appropriate
-    <braunr> i'm not sure it is
-    <braunr> first, it's about STREAMS, a commonly unused feature
-    <braunr> and second, the code is obsolete
-    <mcsim> braunr: AFAIR purpose of KERN_NO_DATA is not only free
-      pages. Without this call something should hang
-    <braunr> 15:59 < braunr> (well obviously, notify the kernel it can go on
-      with page fault handling)
-    <mcsim> yes
-    <braunr> hm
-    <mcsim> sorry again
-    <braunr> i don't see anything better for the error name for now
-    <braunr> and it's really minor so let's keep it as it is
-    <braunr> actually, ENODATA being obsolete helps here
-    <braunr> ok, done for now, work calling
-    <braunr> we'll continue later or tomorrow
-    <mcsim> braunr: ok
-    <braunr> other than that, this looks ok on the kernel side for now
-    <braunr> the next change is a bit larger so i'd like to take the time to
-      read it
-    <mcsim> braunr: ok
-    <mcsim> regarding moving calls in mach.defs, can I put them elsewhere?
-    <braunr> gnumach.defs
-    <braunr> you'll probably need to rebase your changes to get it
-    <mcsim> braunr: I'll rebase this later, when we finish with review
-    <braunr> ok
-    <braunr> keep the comments in a list then, not to forget
-    <braunr> (logging irc is also useful)
-
-
-## IRC, freenode, #hurd, 2013-02-20
-
-    <braunr> mcsim: why does VM_ADVICE_DEFAULT have its own entry ?
-    <mcsim> braunr:  this kind of fallback mode 
-    <mcsim> i suppose that even random strategy could even read several pages
-      at once
-    <braunr> yes
-    <braunr> but then, why did you name it "default" ?
-    <mcsim> because it is assigned by default
-    <braunr> ah
-    <braunr> so you expect pagers to set something else
-    <braunr> for all objects they create
-    <mcsim> yes
-    <braunr> ok
-    <braunr> why not, but add a comment please
-    <mcsim> at least until all pagers will support clustered reading
-    <mcsim> ok
-    <braunr> even after that, it's ok
-    <braunr> just say it's there to keep the previous behaviour by default
-    <braunr> so people don't get the idea of changing it too easily
-    <mcsim> comment in vm_advice.h?
-    <braunr> no, in vm_fault.C
-    <braunr> right above the array
-    <braunr> why does vm_calculate_clusters return two ranges ?
-    <braunr> also, "Function PAGE_IS_NOT_ELIGIBLE is used to determine if",
-      PAGE_IS_NOT_ELIGIBLE doesn't look like a function
-    <mcsim> I thought make it possible not only prefetch range, but also free
-      some memory that is not used already
-    <mcsim> braunr: ^
-    <mcsim> but didn't implement it :/
-    <braunr> don't overengineer it
-    <braunr> reduce to what's needed
-    <mcsim> braunr: ok
-    <mcsim> braunr: do you think it's worth to implement?
-    <braunr> no
-    <mcsim> braunr: it could be useful for sequential policy
-    <braunr> describe what you have in mind a bit more please, i think i don't
-      have the complete picture
-    <mcsim> with sequential policy user supposed to read strictly in sequential
-      order, so pages that user is not supposed to read could be put in unused
-      list 
-    <braunr> what pages the user isn't supposed to read ?
-    <mcsim> if user read pages in increasing order than it is not supposed to
-      read pages that are right before the page where page fault occured
-    <braunr> right ?
-    <braunr> do you mean higher ?
-    <mcsim> that are before
-    <braunr> before would be lower then
-    <braunr> oh
-    <braunr> "right before"
-    <mcsim> yes :)
-    <braunr> why not ?
-    <braunr> the initial assumption, that MADV_SEQUENTIAL expects *strict*
-      sequential access, looks wrong
-    <braunr> remember it's just a hint
-    <braunr> a user could just acces pages that are closer to one another and
-      still use MADV_SEQUENTIAL, expecting a speedup because pages are close
-    <braunr> well ok, this wouldn't be wise
-    <braunr> MADV_SEQUENTIAL should be optimized for true sequential access,
-      agreed
-    <braunr> but i'm not sure i'm following you
-    <mcsim> but I'm not going to  page these pages out. Just put in unused
-      list, and if they will be used later they will be move to active list
-    <braunr> your optimization seem to be about freeing pages that were
-      prefetched and not actually accessed
-    <braunr> what's the unused list ?
-    <mcsim> inactive list
-    <braunr> ok
-    <braunr> so that they're freed sooner
-    <mcsim> yes
-    <braunr> well, i guess all neighbour pages should first be put in the
-      inactive list
-    <braunr> iirc, pages in the inactive list aren't mapped
-    <braunr> this would force another page fault, with a quick resolution, to
-      tell the vm system the page was actually used, and must become active,
-      and paged out later than other inactive pages
-    <braunr> but i really think it's not worth doing it now
-    <braunr> clustered pagins is about improving I/O
-    <braunr> page faults without I/O are orders of magnitude faster than I/O
-    <braunr> it wouldn't bring much right now
-    <mcsim> ok, I remove this, but put in TODO
-    <mcsim> I'm not sure that right list is inactive list, but the list that is
-      scanned to pageout pages to swap partition. There should be such list
-    <braunr> both the active and inactive are
-    <braunr> the active one is scanned when the inactive isn't large enough
-    <braunr> (the current ratio of active pages is limited to 1/3)
-    <braunr> (btw, we could try increasing it to 1/2)
-    <braunr> iirc, linux uses 1/2
-    <braunr> your comment about unlock_request isn't obvious, i'll have to
-      reread again
-    <braunr> i mean, the problem isn't obvious
-    <braunr> ew, functions with so many indentation levels :/
-    <braunr> i forgot how ugly some parts of the mach vm were
-    <braunr> mcsim: basically it's ok, i'll wait for the simplified version for
-      another pass
-    <mcsim> simplified?
-    <braunr> 22:11 < braunr> reduce to what's needed
-    <mcsim> ok
-    <mcsim> and what comment?
-    <braunr> your XXX in vm_fault.c
-    <braunr> when calling vm_calculate_clusters
-    <mcsim> is m->unlock_request the same for all cluster or I should
-      recalculate it for every page?
-    <mcsim> s/all/whole
-    <braunr> that's what i say, i'll have to come back to that later
-    <braunr> after i have reviewed the userspace code i think
-    <braunr> so i understand the interactions better
-    <mcsim> braunr: pushed v1 branch
-    <mcsim> braunr: "Move new calls to gnumach.defs file" and "Implement
-      putting pages in inactive list with sequential policy" are in my TODO
-    <braunr> mcsim: ok
-
-
-## IRC, freenode, #hurd, 2013-02-24
-
-    <braunr> mcsim: where does the commit from neal (reworking libpager) come
-      from ?
-    <braunr> (ok the question looks a little weird semantically but i think you
-      get my point)
-    <mcsim> braunr: you want me to give you a link to mail with this commit?
-    <braunr> why not, yes
-    <mcsim> http://permalink.gmane.org/gmane.os.hurd.bugs/446
-    <braunr> ok so
-      http://lists.gnu.org/archive/html/bug-hurd/2012-06/msg00001.html
-    <braunr> ok so, we actually have three things to review here
-    <braunr> that libpager patch, the ext2fs large store one, and your work
-    <braunr> mcsim: i suppose something in your work depends on neal's patch,
-      right ?
-    <braunr> i mean, why did you work on top of it ?
-    <mcsim> Yes
-    <mcsim> All user level code
-    <braunr> i see it adds some notifications
-    <mcsim> no
-    <mcsim> notifacations are for large store
-    <braunr> ok
-    <mcsim> but the rest is for my work
-    <braunr> but what does it do that you require ?
-    <mcsim> braunr: this patch adds support for multipage work. There were just
-      stubs that returned errors for chunks longer than one page before.
-    <braunr> ok
-    <braunr> for now, i'll just consider that it's ok, as well as the large
-      store patch
-    <braunr> ok i've skipped all patches up to "Make mach-defpager process
-      multipage requests in m_o_data_request." since they're obvious
-    <braunr> but this one isn't
-    <braunr> mcsim: why is the offset member a vm_size_t in struct block ?
-    <braunr> (these things matter for large file support on 32-bit systems)
-    <mcsim> braunr: It should be vm_offset_t, right?
-    <braunr> yes
-    <braunr> well
-    <braunr> it seems so but
-    <braunr> im not sure what offset is here
-    <braunr> vm_offset is normally the offset inside a vm_object
-    <braunr> and if we want large file support, it could become a 64-bit
-      integer
-    <braunr> while vm_size_t is a size inside an address space, so it's either
-      32 or 64-bit, depending on the address space size
-    <braunr> but here, if offset is an offset inside an address space,
-      vm_size_t is fine
-    <braunr> same question for send_range_parameters
-    <mcsim> braunr: TBH, I do not differ vm_size_t and vm_offset_t well
-    <braunr> they can be easily confused yes
-    <braunr> they're both offsets and sizes actually
-    <braunr> they're integers
-    <mcsim> so here I used vm_offset_t because field name is offset
-    <braunr> but vm_size_t is an offset/size inside an address space (a
-      vm_map), while vm_offset_t is an offset/size inside an object
-    <mcsim> braunr: I didn't know that
-    <braunr> it's not clear at all
-    <braunr> and it may not have been that clear in mach either
-    <braunr> but i think it's best to consider them this way from now on
-    <braunr> well, it's not that important anyway since we don't have large
-      file support, but we should some day :/
-    <braunr> i'm afraid we'll have it as a side effect of the 64-bit port
-    <braunr> mcsim: just name them vm_offset_t when they're offsets for
-      consistency
-    <mcsim> but seems that I guessed, because I use vm_offset_t variables in
-      mo_ functions
-    <braunr> well ok, but my question was about struct block
-    <braunr> where you use vm_size_t
-    <mcsim> braunr: I consider this like a mistake
-    <braunr> ok
-    <braunr> moving on
-    <braunr> in upload_range, there are two XXX comments
-    <braunr> i'm not sure to understand
-    <mcsim> Second XXX I put because at the moment when I wrote this not all
-      hurd libraries and servers supported size different from vm_page_size 
-    <mcsim> But then I fixed this and replaced vm_page_size with size in
-      page_read_file_direct
-    <braunr> ok then update the comment accordingly
-    <mcsim> When I was adding third XXX, I tried to check everything. But I
-      still had felling that I forgot something.
-    <mcsim> No it is better to remove second and third XXX, since I didn't find
-      what I missed
-    <braunr> well, that's what i mean by "update" :)
-    <mcsim> ok
-    <mcsim> and first XXX just an optimisation. Its idea is that there is no
-      case when the whole structure is used in one function.
-    <braunr> ok
-    <mcsim> But I was not sure if was worth to do, because if there will appear
-      some bug in future it could be hard to find it. 
-    <mcsim> I mean that maintainability decreases because of using union
-    <mcsim> So, I'd rather keep it like it is
-    <braunr> how is struct send_range_parameters used ?
-    <braunr> it doesn't looked to be something stored long
-    <braunr> also, you're allowed to use GNU extensions
-    <mcsim> It is used to pass parameters from one function to another
-    <mcsim> which of them?
-    <braunr> see
-      http://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/Unnamed-Fields.html#Unnamed-Fields
-    <braunr> mcsim: if it's used to pass parameters, it's likely always on the
-      stack
-    <mcsim> braunr: I use it when necessary
-    <braunr> we really don't care much about a few extra words on the stack
-    <braunr> the difference in size would 
-    <mcsim> agree
-    <braunr> matter
-    <braunr> oops
-    <braunr> the difference in size would matter if a lot of those were stored
-      in memory for long durations
-    <braunr> that's not the case, so the size isn't a problem, and you should
-      remove the comment
-    <mcsim> ok
-    <braunr> mcsim: if i get it right, the libpager rework patch changes some
-      parameters from byte offset to page frame numbers
-    <mcsim> braunr: yes
-    <braunr> why don't you check errors in send_range ?
-    <mcsim> braunr: it was absent in original code, but you're right, I should
-      do this
-    <braunr> i'm not sure how to handle any error there, but at least an assert
-    <mcsim> I found a place where pager just panics
-    <braunr> for now it's ok
-    <braunr> your work isn't about avoiding panics, but there must be a check,
-      so if we can debug it and reach that point, we'll know what went wrong
-    <braunr> i don't understand the prototype change of default_read :/
-    <braunr> it looks like it doesn't return anything any more
-    <braunr> has it become asynchronous ?
-    <mcsim> It was returning some status before, but now it handles this status
-      on its own
-    <braunr> hum
-    <braunr> how ?
-    <braunr> how do you deal with errors ?
-    <mcsim> in old code default_read returned kr and this kr was used to
-      determine what m_o_ function will be used
-    <mcsim> now default_read calls m_o_ on its own
-    <braunr> ok
-
-
-## IRC, freenode, #hurd, 2013-03-06
-
-    <mcsim> braunr: hi, regarding memory policies. Should I create separate
-      policy that will do pageout or VM_ADVICE_SEQUENTIAL is good enough?
-    <mcsim> braunr: at the moment it is exactly like NORMAL 
-    <braunr> mcsim: i thought you only did pageins
-    <mcsim> braunr: yes, but I'm doing pageouts now
-    <braunr> oh
-    <braunr> i'd prefer you didn't :/
-    <braunr> if you want to improve paging, i have a suggestion i believe is a
-      lot better
-    <braunr> and we have 3 patches concerning libpager that we need to review,
-      polish, and merge in
-    <mcsim> braunr: That's not hard, and I think I know what to do
-    <braunr> yes i understand that
-    <braunr> but it may change the interface and conflict with the pending
-      changes
-    <mcsim> braunr: What changes?
-    <braunr> the large store patch, neal's libpager rework patch on top of
-      which you made your changes, and your changes
-    <braunr> the idea i have in mind was writeback throttling
-
-[[hurd/translator/ext2fs]], [[hurd/libpager]].
-
-    <braunr> i was planning on doing it myself but if you want to work on it,
-      feel free to
-    <braunr> it would be a much better improvement at this time than clustered
-      pageouts
-    <braunr> (which can then immediately follow
-    <braunr> )
-    <mcsim> braunr: ok
-    <mcsim> braunr: but this looks much more bigger task for me
-    <braunr> we'll talk about the strategy i had in mind tomorrow
-    <braunr> i hope you find it simple enough
-    <braunr> on the other hand, clustered pageouts are very similar to pageins
-    <braunr> and we have enough paging related changes to review that adding
-      another wouldn't be such a problem actually
-    <mcsim> so, add?
-    <braunr> if that's what you want to do, ok
-    <braunr> i'll think about your initial question tomorrow
-
-
-## IRC, freenode, #hurd, 2013-09-30
-
-    <antrik> talking about which... did the clustered I/O work ever get
-      concluded?
-    <braunr> antrik: yes, mcsim was able to finish clustered pageins, and it's
-      still on my TODO list
-    <braunr> it will get merged eventually, now that the large store patch has
-      also been applied
-
-
-## IRC, freenode, #hurd, 2013-12-31
-
-    <braunr> mcsim: do you think you'll have time during january to work out
-      your clustered pagein work again ? :)
-    <mcsim> braunr: hello. yes, I think. Depends how much time :)
-    <braunr> shouldn't be much i guess
-    <mcsim> what exactly should be done there?
-    <braunr> probably a rebase, and once the review and tests have been
-      completed, writing the full changelogs
-    <mcsim> ok
-    <braunr> the libpager notification on eviction patch has been pushed in as
-      part of the merge of the ext2fs large store patch
-    <braunr> i have to review neal's rework patch again, and merge it
-    <braunr> and then i'll test your work and make debian packages for
-      darnassus
-    <braunr> play with it a bit, see how itgoes
-    <braunr> mcsim: i guess you could start with
-      62004794b01e9e712af4943e02d889157ea9163f (Fix bugs and warnings in
-      mach-defpager)
-    <braunr> rebase it, send it as a patch on bug-hurd, it should be
-      straightforward and short
-
-
-## IRC, freenode, #hurd, 2014-03-04
-
-    <teythoon> btw, has mcsim worked on vectorized i/o ? there was someting you
-      wanted to integrate
-    <teythoon> not sure what
-    <braunr> clustered pageins
-    <braunr> but he seems busy
-    <teythoon> oh, pageins
diff --git a/open_issues/performance/ipc_virtual_copy.mdwn b/open_issues/performance/ipc_virtual_copy.mdwn
deleted file mode 100644
index 9708ab96..00000000
--- a/open_issues/performance/ipc_virtual_copy.mdwn
+++ /dev/null
@@ -1,395 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-IRC, freenode, #hurd, 2011-09-02:
-
-    <slpz> what's the usual throughput for I/O operations (like "dd
-      if=/dev/zero of=/dev/null") in one of those Xen based Hurd machines
-      (*bber)?
-    <braunr> good question
-    <braunr> slpz: but don't use /dev/zero and /dev/null, as they don't have
-      anything to do with true I/O operations
-    <slpz> braunr: in fact, I want to test the performance of IPC's virtual
-      copy operations
-    <braunr> ok
-    <slpz> braunr: sorry, the "I/O" was misleading
-    <braunr> use bs=4096 then i guess
-    <slpz> bs > 2k
-    <braunr> ?
-    <slpz> braunr: everything about 2k is copied by vm_map_copyin/copyout
-    <slpz> s/about/above/
-    <slpz> braunr: MiG's stubs check for that value and generate complex (with
-      out_of_line memory) messages if datalen is above 2k, IIRC
-    <braunr> ok
-    <braunr> slpz: found it, thanks
-    <tschwinge> tschwinge@strauss:~ $ dd if=/dev/zero of=/dev/null bs=4k & p=$!
-      && sleep 10 && kill -s INFO $p && sleep 1 && kill $p
-    <tschwinge> [1] 13469
-    <tschwinge> 17091+0 records in
-    <tschwinge> 17090+0 records out
-    <tschwinge> 70000640 bytes (70 MB) copied, 17.1436 s, 4.1 MB/s
-    <tschwinge> Note, however 10 s vs. 17 s!
-    <tschwinge> And this is slow compared to heal hardware:
-    <tschwinge> thomas@coulomb:~ $ dd if=/dev/zero of=/dev/null bs=4k & p=$! &&
-      sleep 10 && kill -s INFO $p && sleep 1 && kill $p
-    <tschwinge> [1] 28290
-    <tschwinge> 93611+0 records in
-    <tschwinge> 93610+0 records out
-    <tschwinge> 383426560 bytes (383 MB) copied, 9.99 s, 38.4 MB/s
-    <braunr> tschwinge: is the first result on xen vm ?
-    <tschwinge> I think so.
-    <braunr> :/
-    <slpz> tschwinge: Thanks! Could you please try with a higher block size,
-      something like 128k or 256k?
-    <tschwinge> strauss is on a machine that also hosts a buildd, I think.
-    <braunr> oh ok
-    <pinotree> yes, aside either rossini or mozart
-    <tschwinge> And I can confirm that with dd if=/dev/zero of=/dev/null bs=4k
-      running, a parallel sleep 10 takes about 20 s (on strauss).
-
-[[open_issues/time]]
-
-    <braunr> slpz: i'll set up xen hosts soon and can try those tests while
-      nothing else runs to have more accurate results
-    <tschwinge> tschwinge@strauss:~ $ dd if=/dev/zero of=/dev/null bs=256k &
-      p=$! && sleep 10 && kill -s INFO $p && sleep 1 && kill $p
-    <tschwinge> [1] 13482
-    <tschwinge> 4566+0 records in
-    <tschwinge> 4565+0 records out
-    <tschwinge> 1196687360 bytes (1.2 GB) copied, 13.6751 s, 87.5 MB/s
-    <braunr> slpz: gains are logarithmic beyond the page size
-    <tschwinge> thomas@coulomb:~ $ dd if=/dev/zero of=/dev/null bs=256k & p=$!
-      && sleep 10 && kill -s INFO $p && sleep 1 && kill $p
-    <tschwinge> [1] 28295
-    <tschwinge> 6335+0 records in
-    <tschwinge> 6334+0 records out
-    <tschwinge> 1660420096 bytes (1.7 GB) copied, 9.99 s, 166 MB/s
-    <tschwinge> This time a the sleep 10 decided to take 13.6 s.
-      ``Interesting.''
-    <slpz> tschwinge: Thanks again. The results for the Xen machine are not bad
-      though. I can't obtain a throughput over 50MB/s with KVM.
-    <tschwinge> slpz: Want more data (bs)?  Just tell.
-    <braunr> slpz: i easily get more than that
-    <braunr> slpz: what buffer size do you use ?
-    <slpz> tschwinge: no, I just wanted to see if Xen has an upper limit beyond
-      KVM's. Thank you.
-    <slpz> braunr: I try with different sizes until I find the maximum
-      throughput for a certain amount of requests (count)
-    <slpz> braunr: are you working with KVM?
-    <braunr> yes
-    <braunr> slpz: my processor is a model name      : Intel(R) Core(TM)2 Duo
-      CPU     E7500  @ 2.93GHz
-    <braunr> Linux silvermoon 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC
-      2011 x86_64 GNU/Linux
-    <braunr> (standard amd64 squeeze kernel)
-    <slpz> braunr: and KVM's version?
-    <braunr> squeeze (0.12.5)
-    <braunr> bbl
-    <gnu_srs> 212467712 bytes (212 MB) copied, 9.95 s, 21.4 MB/s on kvm for me!
-    <slpz> gnu_srs: which block size?
-    <gnu_srs> 4k, and  61.7 MB/s with 256k
-    <slpz> gnu_srs: could you try with 512k and 1M?
-    <gnu_srs> 512k: 56.0 MB/s, 1024k: 40.2 MB/s Looks like the peak is around a
-      few 100k
-    <slpz> gnu_srs: thanks!
-    <slpz> I've just obtained 1.3GB/s with bs=512k on other (newer) machine
-    <braunr> on which hw/vm ?
-    <slpz> I knew this is a cpu-bound test, but I couldn't imagine faster
-      processors could make this difference
-    <slpz> braunr: Intel(R) Core(TM) i5 CPU         650  @ 3.20GHz
-    <slpz> braunr: KVM
-    <braunr> ok
-    <braunr> how much time did you wait before reading the result ?
-    <slpz> that was 20x times better than the same test on my Intel(R)
-      Core(TM)2 Duo CPU     T7500  @ 2.20GHz
-    <slpz> braunr: I've repeated the test with a fixed "count"
-    <gnu_srs> My box is: Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz: Max
-      is 67 MB/s around 140k block size
-    <braunr> yes but how much time did dd run ?
-    <gnu_srs>  10 s plus/minus a few fractions of a second,
-    <braunr> try waiting 30s
-    <slpz> braunr: didn't check, let me try again
-    <braunr> my kvm peaks at 130 MiB/s with bs 512k / 1M
-    <gnu_srs> 2029690880 bytes (2.0 GB) copied, 30.02 s, 67.6 MB/s, bs=140k
-    <braunr> gnu_srs: i'm very surprised with slpz's result of 1.3 GiB/s
-    <slpz> braunr: over 60 s running, same performance
-    <braunr> nice
-    <braunr> i wonder what makes it so fast
-    <braunr> how much cache ?
-    <gnu_srs> Me too, I cannot get better values than around 67 MB/s
-    <braunr> gnu_srs: same questions
-    <slpz> braunr: 4096KB, same as my laptop
-    <braunr> slpz: l2 ? l3 ?
-    <gnu_srs> kvm: cache=writeback, CPU: 4096 KB
-    <braunr> gnu_srs: this has nothing to do with the qemu option, it's about
-      the cpu
-    <slpz> braunr: no idea, it's the first time I touch this machine. I going
-      to see if I find the model in processorfinder
-    <braunr> under my host linux system, i get a similar plot, that is,
-      performance drops beyond bs=1M
-    <gnu_srs> braunr: OK, bu I gave you the cache size too, same as slpz.
-    <braunr> i wonder what dd actually does
-    <braunr> read() and writes i guess
-    <slpz> braunr: read/write repeatedly, nothing fancy 
-    <braunr> slpz: i don't think it's a good test for virtual copy
-    <braunr> io_read_request, vm_deallocate, io_write_request, right
-    <braunr> slpz: i really wonder what it is about i5 that improves speed so
-      much
-    <slpz> braunr: me too
-    <slpz> braunr: L2: 2x256KB, L3: 4MB
-    <slpz> and something calling "SmartCache"
-    <gnu_srs> slpz: where did you find these values?
-    <slpz> gnu_srs: ark.intel.com and wikipedia
-    <gnu_srs> aha, cpuinfo just gives cache size.
-    <slpz> that "SmartCache" thing seems to be just L2 cache sharing between
-      cores. Shouldn't make a different since we're using only one core, and I
-      don't see KVM hooping between them.
-    <manuel> with bs=256k: 7004487680 bytes (7.0 GB) copied, 10 s, 700 MB/s
-    <manuel> (qemu/kvm, 3 * Intel(R) Xeon(R) E5504 2GHz, cache size 4096 KB)
-    <slpz> manuel: did you try with 512k/1M?
-    <manuel> bs=512k: 7730626560 bytes (7.7 GB) copied, 10 s, 773 MB/s
-    <manuel> bs=1M: 7896825856 bytes (7.9 GB) copied, 10 s, 790 MB/s
-    <slpz> manuel: those are pretty good numbers too
-    <braunr> xeon processor
-    <gnu_srs> lshw gave me: L1 Cache 256KiB, L2 cache 4MiB
-    <slpz> sincerely, I've never seen Hurd running this fast. Just checked
-      "uname -a" to make sure I didn't take the wrong image :-)
-    <manuel> for bs=256k, 60s: 40582250496 bytes (41 GB) copied, 60 s, 676 MB/s
-    <braunr> slpz: i think you can assume processor differences alter raw
-      copies too much to get any valuable results about virtual copy operations
-    <braunr> you need a specialized test program
-    <manuel> and bs=512k, 60s, 753 MB/s
-    <slpz> braunr: I'm using the mach_perf suite from OSFMach to do the
-      "serious" testing. I just wanted a non-synthetic test to confirm the
-      readings.
-
-[[!taglink open_issue_gnumach]] -- have a look at *mach_perf*.
-
-    <braunr> manuel: how much cache ? 2M ?
-    <braunr> slpz: ok
-    <braunr> manuel: hmno, more i guess
-    <manuel> braunr: /proc/cpuinfo says cache size      : 4096 KB
-    <braunr> ok
-    <braunr> manuel: performance should drop beyond bs=2M
-    <braunr> but that's not relevant anyway
-    <gnu_srs> Linux:  bs=1M, 10.8 GB/s
-    <slpz> I think this difference is too big to be only due to a bigger amount
-      of CPU cycles...
-    <braunr> slpz: clearly
-    <slpz> gnu_srs: your host system has 64 or 32 bits?
-    <slpz> braunr: I'm going to investigate a bit
-    <slpz> but this accidental discovery just made my day. We're able to run
-      Hurd at decent speeds on newer hardware!
-    <braunr> slpz: what result do you get with the same test on your host
-      system ?
-    <manuel> interestingly, running it several times has made the performance
-      drop quite much (i'm getting 400-500MB/s with 1M now, compared to nearly
-      800 fifteen minutes ago)
-
-[[Degradataion]].
-
-    <slpz> braunr: probably an almost infinite throughput, but I don't consider
-      that a valid test, since in Linux, the write operation to "/dev/null"
-      doesn't involve memory copying/moving
-    <braunr> manuel: i observed the same behaviour
-    <gnu_srs> slpz: Host system is 64 bit
-    <braunr> slpz: it doesn't on the hurd either
-    <braunr> slpz: (under 2k, that is)
-    <braunr> over*
-    <slpz> braunr: humm, you're right, as the null translator doesn't "touch"
-      the memory, CoW rules apply
-    <braunr> slpz: the only thing which actually copies things around is dd
-    <braunr> probably by simply calling read()
-    <braunr> which gets its result from a VM copy operation, but copies the
-      content to the caller provided buffer
-    <braunr> then vm_deallocate() the data from the storeio (zero) translator
-    <braunr> if storeio isn't too dumb, it doesn't even touch the transfered
-      buffer (as anonymous vm_map()ped memory is already cleared)
-
-[[!taglink open_issue_documentation]]
-
-    <braunr> so this is a good test for measuring (profiling?) our ipc overhead
-    <braunr> and possibly the vm mapping operations (which could partly explain
-      why the results get worse over time)
-    <braunr> manuel: can you run vminfo | wc -l on your gnumach process ?
-    <slpz> braunr: Yes, unless some special situation apply, like the source
-      address/offset being unaligned, or if the translator decides to return
-      the result in a different buffer (which I assume is not the case for
-      storeio/zero)
-    <manuel> braunr: 35
-    <braunr> slpz: they can't be unaligned, the vm code asserts that
-    <braunr> manuel: ok, this is normal
-    <slpz> braunr: address/offset from read()
-    <braunr> slpz: the caller provided buffer you mean ?
-    <slpz> braunr: yes, and the offset of the memory_object, if it's a pager
-      based translator
-    <braunr> slpz: highly unlikely, the compiler chooses appropriate alignments
-      for such buffers
-    <slpz> braunr: in those cases, memcpy is used over vm_copy
-    <braunr> slpz: and the glibc memcpy() optimized versions can usually deal
-      with that
-    <braunr> slpz: i don't get your point about memory objects
-    <braunr> slpz: requests on memory objects always have aligned values too
-    <slpz> braunr: sure, but can't deal with the user requesting non
-      page-aligned sizes
-    <braunr> slpz: we're considering our dd tests, for which we made sure sizes
-      were page aligned
-    <slpz> braunr: oh, I was talking in a general sense, not just in this dd
-      tests, sorry
-    <slpz> by the way, dd on the host tops at 12 GB/s with bs=2M
-    <braunr> that's consistent with our other results
-    <braunr> slpz: you mean, even on your i5 processor with 1.3 GiB/s on your
-      hurd kvm ?
-    <slpz> braunr: yes, on the GNU/Linux which is running as host
-    <braunr> slpz: well that's not consistent
-    <slpz> braunr: consistent with what?
-    <braunr> slpz: i get roughly the same result on my host, but ten times less
-      on my hurd kvm
-    <braunr> slpz: what's your kernel/kvm versions ?
-    <slpz> 2.6.32-5-amd64 (debian's build) 0.12.5
-    <braunr> same here
-    <braunr> i'm a bit clueless
-    <braunr> why do i only get 130 MiB/s where you get 1.3 .. ? :)
-    <slpz> well, on my laptop, where Hurd on KVM tops on 50 MB/s, Linux gets a
-      bit more than 10 GB/s
-    <braunr> see
-    <braunr> slpz: reduce bs to 256k and test again if you have time please
-    <slpz> braunr: on which system?
-    <braunr> slpz: the fast one
-    <braunr> (linux host)
-    <slpz> braunr: Hurd?
-    <slpz> ok
-    <slpz> 12 GB/s
-    <braunr> i get 13.3
-    <slpz> same for 128k, only at 64k starts dropping
-    <slpz> maybe, on linux we're being limited by memory speed, while on Hurd's
-      this test is (much) more CPU-bound?
-    <braunr> slpz: maybe
-    <braunr> too bad processor stalls aren't easy to measure
-    <slpz> braunr: that's very true. It's funny when you read a paper which
-      measures performance by cycles on an old RISC processor. That's almost
-      impossible to do (with reliability) nowadays :-/
-    <slpz> I wonder which throughput can achieve Hurd running bare-metal on
-      this machine...
-    <antrik> both the Xeon and the i5 use cores based on the Nehalem
-      architecture
-    <antrik> apparently Nehalem is where Intel first introduces nested page
-      tables
-    <antrik> which pretty much explains the considerably lower overhead of VM
-      magic
-    <cjuner> antrik, what are nested page tables? (sounds like the 4-level page
-      tables we already have on amd64, or 2-level or 3-level on x86 pae)
-    <antrik> page tables were always 2-level on x86
-    <antrik> that's unrelated
-    <antrik> nested page tables means there is another layer of address
-      translation, so the VMM can do it's own translation and doesn't care what
-      the guest system does => no longer has to intercept all page table
-      manipulations
-    <braunr> antrik: do you imply it only applies to virtualized systems ?
-    <antrik> braunr: yes
-    <slpz> antrik: Good guess. Looks like Intel's EPT are doing the trick by
-      allowing the guest OS deal with its own page faults
-    <slpz> antrik: next monday, I'll try disabling EPT support in KVM on that
-      machine (the fast one). That should confirm your theory empirically.
-    <slpz> this also means that there're too many page faults, as we should be
-      doing virtual copies of memory that is not being accessed
-    <slpz> and looking at how the value of "page faults" in "vmstat" increases,
-      shows that page faults are directly proportional to the number of pages
-      we are asking from the translator
-    <slpz> I've also tried doing a long read() directly, to be sure that "dd"
-      is not doing something weird, and it shows the same behaviour.
-    <braunr> slpz: dd does copy buffers
-    <braunr> slpz: i told you, it's not a good test case for pure virtual copy
-      evaluation
-    <braunr> antrik: do you know if xen benefits from nested page tables ?
-    <antrik> no idea
-
-[[!taglink open_issue_xen]]
-
-    <slpz> braunr: but my small program doesn't, and still provokes a lot of
-      page faults
-    <braunr> slpz: are you certain it doesn't ?
-    <slpz> braunr: looking at google, it looks like recent Xen > 3.4 supports
-      EPT
-    <braunr> ok
-    <braunr> i'm ordering my new server right now, core i5 :)
-    <slpz> braunr: at least not explicitily. I need to look at MiG stubs again,
-      I don't remember if they do something weird.
-    <antrik> braunr: sandybridge or nehalem? :-)
-    <braunr> antrik: no idea
-    <antrik> does it tell a model number?
-    <braunr> not yet
-    <braunr> but i don't have a choice for that, so i'll order it first, check
-      after
-    <antrik> hehe
-    <antrik> I'm not sure it makes all that much difference anyways for a
-      server... unless you are running it at 100% load ;-)
-    <braunr> antrik: i'm planning on running xen guests suchs as new buildd
-    <antrik> hm... note though that some of the nehalem-generation i5s were
-      dual-core, while all the new ones are quad
-    <braunr> it's a quad
-    <antrik> the newer generation has better performance per GHz and per
-      Watt... but considering that we are rather I/O-limited in most cases, it
-      probably won't make much difference
-    <antrik> not sure whether there are further virtualisation improvements
-      that could be relevant...
-    <braunr> buildds spend much time running gcc, so even such improvements
-      should help
-    <braunr> there, server ordered :)
-    <braunr> antrik: model name      : Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz
-
-IRC, freenode, #hurd, 2011-09-06:
-
-    <slpz> youpi: what machines are being used for buildd? Do you know if they
-      have EPT/RVI?
-    <youpi> we use PV Xen there
-    <slpz> I think Xen could also take advantage of those technologies. Not
-      sure if only in HVM or with PV too.
-    <youpi> only in HVM
-    <youpi> in PV it does not make sense: the guest already provides the
-      translated page table
-    <youpi> which is just faster than anything else
-
-IRC, freenode, #hurd, 2011-09-09:
-
-    <antrik> oh BTW, for another data point: dd zero->null gets around 225 MB/s
-      on my lowly 1 GHz Pentium3, with a blocksize of 32k
-    <antrik> (but only half of that with 256k blocksize, and even less with 1M)
-    <antrik> the system has been up for a while... don't know whether it's
-      faster on a freshly booted one
-
-IRC, freenode, #hurd, 2011-09-15:
-
-    <sudoman>
-      http://www.reddit.com/r/gnu/comments/k68mb/how_intelamd_inadvertently_fixed_gnu_hurd/
-    <sudoman> so is the dd command pointed to by that article a measure of io
-      performance?
-    <antrik> sudoman: no, not really
-    <antrik> it's basically the baseline of what is possible -- but the actual
-      slowness we experience is more due to very unoptimal disk access patterns
-    <antrik> though using KVM with writeback caching does actually help with
-      that...
-    <antrik> also note that the title of this post really makes no
-      sense... nested page tables should provide similar improvements for *any*
-      guest system doing VM manipulation -- it's not Hurd-specific at all
-    <sudoman> ok, that makes sense. thanks :)
-
-IRC, freenode, #hurd, 2011-09-16:
-
-    <slpz> antrik: I wrote that article (the one about How AMD/Intel fixed...)
-    <slpz> antrik: It's obviously a bit of an exaggeration, but it's true that
-      nested pages supposes a great improvement in the performance of Hurd
-      running on virtual machines
-    <slpz> antrik: and it's Hurd specific, as this system is more affected by
-      the cost of page faults
-    <slpz> antrik: and as the impact of virtualization on the performance is
-      much higher than (almost) any other OS.
-    <slpz> antrik: also, dd from /dev/zero to /dev/null it's a measure on how
-      fast OOL IPC is.
diff --git a/open_issues/performance/microbenchmarks.mdwn b/open_issues/performance/microbenchmarks.mdwn
deleted file mode 100644
index de3a54b7..00000000
--- a/open_issues/performance/microbenchmarks.mdwn
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-Microbenchmarks may give useful hints, or they may not.
-
-<http://www.ibm.com/developerworks/java/library/j-jtp02225.html>
diff --git a/open_issues/performance/microkernel_multi-server.mdwn b/open_issues/performance/microkernel_multi-server.mdwn
deleted file mode 100644
index 0382c835..00000000
--- a/open_issues/performance/microkernel_multi-server.mdwn
+++ /dev/null
@@ -1,226 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2013 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_documentation]]
-
-Performance issues due to the microkernel/multi-server system architecture?
-
-
-# IRC, freenode, #hurd, 2011-07-26
-
-    < CTKArcher> I read that, because of its microkernel+servers design, the
-      hurd was slower than a monolithic kernel, is that confirmed ?
-    < youpi> the hurd is currently slower than current monolithic kernels, but
-      it's not due to the microkernel + servers design
-    < youpi> the microkernel+servers design makes the system call path longer
-    < youpi> but you're bound by disk and network speed
-    < youpi> so the extra overhead will not hurt so much
-    < youpi> except dumb applications keeping doing system calls all the time
-      of course, but they are usually considered bogus
-    < braunr> there may be some patterns (like applications using pipes
-      extensively, e.g. git-svn) which may suffer from the design, but still in
-      an acceptable range
-    < CTKArcher> so, you are saying that disk and network are more slowing the
-      system than the longer system call path and because of that, it wont
-      really matter ?
-    < youpi> braunr: they should sitll be fixed because they'll suffer (even if
-      less) on monolithic kernels
-    < youpi> CTKArcher: yes
-    < braunr> yes
-    < CTKArcher> mmh
-    < youpi> CTKArcher: you might want to listen to AST's talk at fosdem 10
-      iirc, about minix
-    < youpi> they even go as far as using an IPC for each low-level in/out
-    < youpi> for security
-    < braunr> this has been expected for a long time
-    < braunr> which is what motivated research in microkernels
-    < CTKArcher> I've already downloaded the video :)
-    < youpi> and it has been more and more true with faster and faster cpus
-    < braunr> but in 95, processors weren't that fast compared to other
-      components as they are now
-    < youpi> while disk/mem haven't evovled so fast
-
-
-# IRC, freenode, #hurd, 2013-09-30
-
-    <snadge> ok.. i noticed when installing debian packages in X, the mouse
-      lagged a little bit
-    <snadge> that takes me back to classic linux days
-    <snadge> it could be a side effect of running under virtualisation who
-      knows
-    <braunr> no
-    <braunr> it's because of the difference of priorities between server and
-      client tasks
-    <snadge> is it simple enough to increase the priority of the X server?
-    <snadge> it does remind me of the early linux days.. people were more
-      interested in making things work, and making things not crash.. than
-      improving the desktop interactivity or responsiveness
-    <snadge> very low priority :P
-    <braunr> snadge: actually it's not the difference in priority, it's the
-      fact that some asynchronous processing is done at server side
-    <braunr> the priority difference just gives more time overall to servers
-      for that processing
-    <braunr> snadge: when i talk about servers, i mean system (hurd) servers,
-      no x
-    <snadge> yeah.. linux is the same.. in the sense that, that was its
-      priority and focus
-    <braunr> snadge: ?
-    <snadge> servers
-    <braunr> what are you talking about ?
-    <snadge> going back 10 years or so.. linux had very poor desktop
-      performance
-    <braunr> i'm not talking about priorities for developers
-    <snadge> it has obviously improved significantly
-    <braunr> i'm talking about things like nice values
-    <snadge> right.. and some of the modifications that have been done to
-      improve interactivity of an X desktop, are not relevant to servers
-    <braunr> not relevant at all since it's a hurd problem, not an x problem
-    <snadge> yeah.. that was more of a linux problem too, some time ago was the
-      only real point i was making.. a redundant one :p
-    <snadge> where i was going with that.. was desktop interactivity is not a
-      focus for hurd at this time
-    <braunr> it's not "desktop interactivity"
-    <braunr> it's just correct scheduling
-    <snadge> is it "correct" though.. the scheduler in linux is configurable,
-      and selectable
-    <snadge> depending on the type of workload you expect to be doing
-    <braunr> not really
-    <snadge> it can be interactive, for desktop loads.. or more batched, for
-      server type loads.. is my basic understanding
-    <braunr> no
-    <braunr> that's the scheduling policy
-    <braunr> the scheduler is cfs currently
-    <braunr> and that's the main difference
-    <braunr> cfs means completely fair
-    <braunr> whereas back in 2.4 and before, it was a multilevel feedback
-      scheduler
-    <braunr> i.e. a scheduler with a lot of heuristics
-    <braunr> the gnumach scheduler is similar, since it was the standard
-      practice from unix v6 at the time
-    <braunr> (gnumach code base comes from bsd)
-    <braunr> so 1/ we would need a completely fair scheduler too
-    <braunr> and 2/ we need to remove asynchronous processing by using mostly
-      synchronous rpc
-    <snadge> im just trying to appreciate the difference between async and sync
-      event processing
-    <braunr> on unix, the only thing asynchronous is signals
-    <braunr> on the hurd, simply cancelling select() can cause many
-      asynchronous notifications at the server to remove now unneeded resources
-    <braunr> when i say cancelling select, i mean one or more fds now have
-      pending events, and the others must be cleaned
-    <snadge> yep.. thats a pretty fundamental change though isnt it? .. if im
-      following you, you're talking about every X event.. so mouse move,
-      keyboard press etc etc etc
-    <snadge> instead of being handled async.. you're polling for them at some
-      sort of timing interval?
-    <snadge> never mind.. i just read about async and sync with regards to rpc,
-      and feel like a bit of a noob
-    <snadge> async provides a callback, sync waits for the result.. got it :p
-    <snadge> async is resource intensive on hurd for the above mentioned
-      reasons.. makes sense now
-    <snadge> how about optimising the situation where a select is cancelled,
-      and deferring the signal to the server to clean up resources until a
-      later time?
-    <snadge> so like java.. dont clean up, just make a mess
-    <snadge> then spend lots of time later trying to clean it up.. sounds like
-      my life ;)
-    <snadge> reuse stale objects instead of destroying and recreating them, and
-      all the problems associated with that
-    <snadge> but if you're going to all these lengths to avoid sending messages
-      between processes
-    <snadge> then you may as well just use linux? :P
-    <snadge> im still trying to wrap my head around how converting X to use
-      synchronous rpc calls will improve responsiveness
-    <pinotree> what has X to do with it?
-    <snadge> nothing wrong with X.. braunr just mentioned that hurd doesnt
-      really handle the async calls so well
-    <snadge> there is more overhead.. that it would be more efficient on hurd,
-      if it uses sync rpc instead
-    <snadge> and perhaps a different task scheduler would help also
-    <snadge> ala cfs
-    <snadge> but i dont think anyone is terribly motivated in turning hurd into
-      a desktop operating system just yet.. but i could be wrong ;)
-    <braunr> i didn't say that
-    <snadge> i misinterpreted what you said then .. im not surprised, im a
-      linux sysadmin by trade.. and have basic university OS understanding (ie
-      crap all) at a hobbyist level
-    <braunr> i said there is asynchronous processing (i.e. server still have
-      work to do even when there is no client)
-    <braunr> that processing mostly comes from select requests cancelling what
-      they installed
-    <braunr> ie.e. you select fd 1 2 3, even on 2, you cancel on 1 and 3
-    <braunr> those cancellations aren't synchronous
-    <braunr> the client deletes ports, and the server asynchronously receives
-      dead name notifications
-    <braunr> since servers have a greater priority, these notifications are
-      processed before the client can continue
-    <braunr> which is what makes you feel lag
-    <braunr> X is actually a client here
-    <braunr> when i say server, i mean hurd servers
-    <braunr> the stuff implementing sockets and files
-    <braunr> also, you don't need to turn the hurd into a desktop os
-    <braunr> any correct way to do fair scheduling will do
-    <snadge> can the X client be made to have a higher priority than the hurd
-      servers?
-    <snadge> or perhaps something can be added to hurd to interface with X
-    <azeem_> well, the future is wayland
-    <snadge> ufs .. unfair scheduling.. give priority to X over everything else
-    <snadge> hurd almost seams ideal for that idea.. since the majority of the
-      system is seperated from the kernel
-    <snadge> im likely very wrong though :p
-    <braunr> snadge: the reason we elevated the priority of servers is to avoid
-      delaying the processing of notifications
-    <braunr> because each notification can spawn a server thread
-    <braunr> and this lead to cases where processing notifications was so slow
-      that spawning threads would occur more frequently, leading to the server
-      exhausting its address space because of thread stacks
-    <snadge> cant it wait for X though? .. or does it lead to that situation
-      you just described
-    <braunr> we should never need such special cases
-    <braunr> we should remove async notifications
-    <snadge> my logic is this.. if you're not running X then it doesnt
-      matter.. if you are, then it might.. its sort of up to you whether you
-      want priority over your desktop interface or whether it can wait for more
-      important things, which creates perceptible lag
-    <braunr> snadge: no it doesn't
-    <braunr> X is clearly not the only process involved
-    <braunr> the whole chain should act synchronously
-    <braunr> from the client through the server through the drivers, including
-      the file system and sockets, and everything that is required
-    <braunr> it's a general problem, not specific to X
-    <snadge> right.. from googling around, it looks like people get very
-      excited about asyncronous
-    <snadge> there was a move to that for some reason.. it sounds great in
-      theory
-    <snadge> continue processing something else whilst you wait for a
-      potentially time consuming process.. and continue processing that when
-      you get the result
-    <snadge> its also the only way to improve performance with parallelism?
-    <snadge> which is of no concern to hurd at this time
-    <braunr> snadge: please don't much such statements when you don't know what
-      you're talking about
-    <braunr> it is a concern
-    <braunr> and yes, async processing is a way to improve performance
-    <braunr> but don't mistake async rpc and async processing
-    <braunr> async rpc simply means you can send and receive at any time
-    <braunr> sync means you need to recv right after send, blocking until a
-      reply arrives
-    <braunr> the key word here is *blocking*ù
-    <snadge> okay sure.. that makes sense
-    <snadge> what is the disadvantage to doing it that way?
-    <snadge> you potentially have more processes that are blocking?
-    <braunr> a system implementing posix such as the hurd needs signals
-    <braunr> and some event handling facility like select
-    <braunr> implementing them synchronously means a thread ready to service
-      these events
-    <braunr> the hurd currently has such a message thread
-    <braunr> but it's complicated and also a scalability concern
-    <braunr> e.g. you have at least two thread per process
-    <braunr> bbl
diff --git a/open_issues/perl.mdwn b/open_issues/perl.mdwn
deleted file mode 100644
index 62d29ac1..00000000
--- a/open_issues/perl.mdwn
+++ /dev/null
@@ -1,113 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-[[!meta title="Foster Perl programming"]]
-
-[[!template id=note text="""**2011-08**.  A dependency loop in Debian GNU/Hurd
-currently leads to: *Could not perform immediate configuration on 'perl'*.
-Easy workaround:
-
-    # apt-get install perl perl-base -o APT::Immediate-Configure=false
-
-"""]]
-
-
-Resolve issues uncovered by Perl's test suite, and enable Hurd-specific
-features.
-
-There is a [[!FF_project 264]][[!tag bounty]] on this task.
-
-# Bugs in perl
-
-There is a bug in perl's putenv which makes it interact badly with fakeroot-tcp and fakeroot-sysv (not fakeroot-hurd), this shows up as this
-
-    *** glibc detected *** /usr/bin/perl: free(): invalid pointer: 0x01026000 ***
-    
-See http://rt.perl.org/rt3/Ticket/Display.html?id=91452 for details
-
-A workaround is to do this before building packages calling perl inside fakeroot:
-
-export FAKEROOTUID=0 FAKEROOTEUID=0 FAKEROOTSUID=0 FAKEROOTFUID=0 FAKEROOTGID=0 FAKEROOTEGID=0 FAKEROOTSGID=0 FAKEROOTFGID=0
-
----
-
-
-# Part I
-
-First, make the language functional, have its test suite pass without errors.
-
-
-## Original [[community/GSoC]] Task Description
-
-[[!inline pages=community/gsoc/project_ideas/perl_python feeds=no]]
-
-
-## IRC, OFTC, #debian-hurd, 2011-11-08
-
-    <Dom> pinotree: so, with your three fixes applied to 5.14.2, there are
-      still 9 tests failing. They don't seem to be regressions in perl, since
-      they also fail when I build 5.14.0 (even though the buildd managed it).
-    <Dom> What do you suggest as the way forward?
-    <Dom> (incidentally I'm trying on strauss's sid chroot to see how that
-      compares)
-    <pinotree> Dom: samuel makes buildds build perl with nocheck (otherwise
-      we'd have no perl at all)
-    <pinotree> which tests still fail?
-    <Dom> ../cpan/Sys-Syslog/t/syslog.t ../cpan/Time-HiRes/t/HiRes.t
-      ../cpan/autodie/t/recv.t ../dist/IO/t/io_pipe.t ../dist/threads/t/libc.t
-      ../dist/threads/t/stack.t ../ext/Socket/t/socketpair.t io/pipe.t
-      op/sigdispatch.t
-    <Dom> buildds> I see
-    <pinotree> ah ok, those that are failing for me even with my patches
-    <Dom> I hadn't spotted that the builds were done with nocheck.
-    <Dom> (but only sometimes...)
-    <Dom> Explains a lot
-    <pinotree> syslog is kind of non-working on hurd, and syslog.t succeeds in
-      buildds (as opposted to crash the machine...) because there's no /var/log
-      in chroots
-    <pinotree> libc.t appears to succeed too in buildds
-    * Dom notices how little memory strauss has, and cancels the build, now
-        that he *knows* that running out of memory caused the crahses
-    <pinotree> iirc HiRes.t, io_pipe.t , pipe.t and sigdispatch.t fails because
-      of trobules we have with posix signals
-    <pinotree> socketpair.t is kind of curious, it seems to block on
-      socketpair()...
-    * Dom wonders if a wiki page tracking this would be worthwhile
-    <pinotree> stack.t fails because we cannot set a different size for pthread
-      stacks, yet (similar failing test cases are also in the python test
-      suite)
-    <Dom> if there are problems which aren't going to get resolved any time
-      soon, it may be worth a few SKIPs conditional on architecture, depending
-      on how serious the issue is
-    <Dom> then we'd get better visibility of other/new issues
-    <Dom> (problems which aren't bugs in perl, that is)
-    <pinotree> understandable, yes
-    <pinotree> i think nobody digged much deeper in the failing ones yet, to
-      actually classify them as due to glibc/hurd/mach
-    <pinotree> (eg unlike the pipe behaviour in sysconf.t i reported)
-
-### 2011-11-26
-
-    <pinotree> cool, my recvfrom() fix also makes the perl test recv.t pass
-
-
----
-
-
-# Part II
-
-Next, Hurd-specific features can be added.  Add an interface to the
-language/environment for being able to do [[RPC]] calls, in order to program
-[[hurd/translator]]s natively in Perl.
-
-
-## Original [[community/GSoC]] Task Description
-
-[[!inline pages=community/gsoc/project_ideas/language_bindings feeds=no]]
diff --git a/open_issues/perlmagick.mdwn b/open_issues/perlmagick.mdwn
deleted file mode 100644
index 8a57a8fd..00000000
--- a/open_issues/perlmagick.mdwn
+++ /dev/null
@@ -1,107 +0,0 @@
-[[!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]]."]]"""]]
-
-[[!debbug 557771]]
-
-# Bisecting
-
-  * Good
-
-      * 7:6.4.0.9.dfsg1-1 (2008-04-22) built from
-        <http://snapshot.debian.net/package/imagemagick>
-      * 6.4.0-11
-      * 6.4.1-0
-      * 6.4.1-1
-
-  * Bad
-
-      * 6.4.1-2
-      * 6.4.1-5
-      * 6.4.1-10
-      * 6.4.2-10
-      * 6.4.5-9
-      * 6.4.8-0 / Debian 6.4.8.0-1
-      * 6.5.5-3 / Debian 6.5.5.3-1
-      * 6.5.8.3-1 from Debian unstable (also in testing)
-      * Svn trunk (r848)
-
-
-# 6.4.1-1 -> 6.4.1-2
-
-    -CFLAGS = -g -O2 -Wall -W -pthread
-    +CFLAGS = -fopenmp -g -O2 -Wall -W -pthread
-    -GOMP_LIBS = 
-    +GOMP_LIBS = -lgomp
-    -LDFLAGS = -lfreetype -lz
-    +LDFLAGS = -fopenmp -lfreetype -lz
-
-Etc.
-
-    +/usr/include/pthread.h:
-    +
-    +/usr/include/pthread/pthread.h:
-    +
-    +/usr/include/bits/spin-lock-inline.h:
-    +
-    +/usr/include/bits/cancelation.h:
-    +
-    +/usr/include/bits/pthread-np.h:
-    +
-    +/usr/lib/gcc/i486-gnu/4.4.2/include/omp.h:
-
-
-# State as of 2011-03-06
-
-freenode, #hurd channel, 2011-03-06:
-
-    <pinotree> tschwinge: (speaking on working perl, how did it en with that
-      "(glibc) double free" crash with perl?)
-    <pinotree> *end
-    <tschwinge> I think I remember I suspected it's a libgomp (!) issue in the
-      end.  I have not yet continued working on that.
-    <pinotree> libogmp? looks like you know more than me, then :)
-    <youpi> tschwinge: oh, I'm interested
-    <youpi> I know a bit about libgomp :)
-    <tschwinge> I bisected this down to where Imagemagick added -fgomp (or
-      whatever it is).  And then the perl library (Imagemagick.pm?) which loads
-      the imagemagick.so segfaulted.
-    <tschwinge> ImageMagick did this change in the middle of a x.x.x.something
-      release..
-    <tschwinge> My next step would have been to test whether libgomp works at
-      all for us.
-    <youpi> ./usr/sbin/debootstrap:DEBOOTSTRAP_CHECKSUM_FIELD="SHA$SHA_SIZE"
-    <youpi> erf
-    <youpi> so they switched to another checksum
-    <youpi> but we don't have that one on all of our packages :)
-    <youpi> tschwinge: 
-    <youpi> buildd@bach:~$ OMP_NUM_THREADS=2 ./test
-    <youpi> I'm 0x1
-    <youpi> I'm 0x3
-    <youpi> libgomp works at least a bit
-    <tschwinge> OK.
-    <pinotree> i guess we should hope the working bits don't stop at that point
-      ;)
-    <tschwinge> If open_issues/perlmagick is to be believed a diff of 6.4.1-1
-      and 6.4.1-2 should tell what exactly was changed.
-    <tschwinge> Oh!
-    <tschwinge> I even have it on the page already!  ;-)
-    <tschwinge> -fopenmp
-    <youpi> I've tried the pragmas that imagemagick uses
-    <youpi> they work
-    <tschwinge> Might be the issue fixed itself?
-    <youpi> I don't know, it's the latest libc here
-    <youpi> (and latest hurd, to be uploaded)
-
-
-# Other
-
-[[!debbug 551017]]
-
-Code in Svn: `+ 1` missing to account for both `/` and `\0`.
diff --git a/open_issues/pfinet.mdwn b/open_issues/pfinet.mdwn
deleted file mode 100644
index 7aadd736..00000000
--- a/open_issues/pfinet.mdwn
+++ /dev/null
@@ -1,27 +0,0 @@
-[[!meta copyright="Copyright © 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_hurd]]
-
-In certain situations, pfinet spawns more and more threads,
-apparently without any bounds.
-
-The thread creation happens in bursts rather than continuously.
-According to a backtrace in GDB,
-all the threads are functional and waiting for client requests.
-(The bursts are getting smaller as the number of threads rises,
-but probably only because the enormous number of existing threads
-slows down processing in general.)
-
-This can be triggered quite reliably by X clients running on the Hurd system,
-connected to an X server on another machine over TCP,
-and transferring fairly large amounts of data.
-The easiest way to reproduce it I found is launching freeciv-gtk2,
-pressing the "new game" button, and then simply waiting for a while.
diff --git a/open_issues/pfinet_timers.mdwn b/open_issues/pfinet_timers.mdwn
deleted file mode 100644
index 244ca98b..00000000
--- a/open_issues/pfinet_timers.mdwn
+++ /dev/null
@@ -1,177 +0,0 @@
-[[!meta copyright="Copyright © 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_hurd]]
-
-
-# IRC, freenode, #hurd, 2013-02-11
-
-    <braunr> now that there is a pthread_hurd_cond_timedwait_np function
-      available, we could replace the ulgy timers in pfinet
-
-
-# IRC, freenode, #hurd, 2013-04-02
-
-    <braunr> youpi: also, i think i know why fakeroot is slow on the hurd
-    <braunr> well, pfinet actually
-    <youpi> tcp flow control?
-    <braunr> i think it's because of our timer resolution
-    <youpi> ah
-    <braunr> and i think i spotted a small mistake in the timer emulation code
-      btw
-    <braunr> it's so obvious i even doubt it's actually true :)
-    <braunr> see timer_emul.c:timer_function
-    <braunr> the code checks for timers->expires < jiffies
-    <braunr> shouldn't it be "<="
-    <braunr> ?
-    <youpi> well it'd be equivalent
-    <youpi> if ==, then wait becomes 0 in the else
-    <braunr> see the second scheck
-    <braunr> the one performed right before running the callback
-    <youpi> ah, the while?
-    <braunr> yes
-    <youpi> I'd say <= could do it yes
-    <braunr> ok
-    <braunr> i have hurd packages ready to be tested
-    <youpi> although I'm unsure it'd make a difference
-    <youpi> do you notice some?
-    <braunr> just waiting for my current glibc to finish building
-    <braunr> and i'll test right after
-    <braunr> i think it would actually
-    <youpi> in which case?
-    <braunr> the timer resolution is 10ms
-    <braunr> it's huge
-    <braunr> well, i hope it fixes fakeroot slowness :)
-    <youpi> so timers below that would trigger immediately?
-    <braunr> or equal
-    <braunr> taht's the problem
-    <braunr> for 10ms, timers that have expired must wait for the next tick to
-      fire
-    <youpi> I include "equal" in below
-    <youpi> actually :)
-    <braunr> then yes :)
-    <braunr> soryy i never know when equal is implicit
-    <youpi> because they boil down to expires = jiffies
-    <youpi> in french it's implicit
-    <youpi> but anyway here equal is not really important
-    <braunr> right
-    <braunr> why ?
-    <youpi> it's the fact that 1ms would be rounded up to 10ms, not down to 0ms
-    <braunr> well, doing that seems reasonable
-    <youpi> or rather, rounded down to 0ms, but waited for 10ms because of the
-      <
-    <braunr> we do want timers not to fire before the time event
-    <youpi> I'm however wondering which part of the code would have timer below
-      10ms
-    <braunr> well, a select with low timeout from a client perhaps ?
-    <youpi> but then we have to round up
-    <youpi> as you say we don't want to fire before some time
-    <braunr> well yes
-    <braunr> that's fine
-    <youpi> all that being said, linux has been having 10ms clock for a long
-      time
-    <braunr> but when the timer fires, i.e. when expires == jiffie, we do want
-      it to fire
-    <youpi> highres timers are only relativeley recent
-    <braunr> not at jiffie + 1
-    <youpi> braunr: ah, right, so we don't wait for 20ms instead of 10ms
-    <braunr> yes
-    <youpi> ok, so it's not a miracle fix, but could bring 2times fix
-    <braunr> well, pfinet eats 40% of my processor when this problem occurs
-    <braunr> which i'm seeing right now
-    <youpi> yes, I've seen that too
-    <braunr> so it may be a visible win
-    <braunr> build finished :) let's see
-    <youpi> Mmm, thinking again
-    <youpi> indeed
-    <youpi> when expires become jiffies
-    <youpi> we mach_msg (0)
-    <youpi> but don't do anything
-    <youpi> and then restart
-    <youpi> so just eaten cpu for nothing
-    <braunr> is there a small package that builds fast and uses fakeroot a lot
-      ?
-    <youpi> something like a package which has a lot of data to install at make
-      install
-    <braunr> or i can rebuild glibc with -nc
-    <youpi> ok, I've checked in linux
-    <pinotree> libarchive's testsuite used to intermittently failing under
-      fakeroot
-    <youpi> it's definitely <= which is meant
-    <braunr> it looks better
-    <braunr> but still not 100% cpu
-    <youpi> at any rate, as long as it doesn't seem to break anything, please
-      push the fix
-    <youpi> it definitely makes sense
-    <youpi> (and I don't see why it could break anything)
-    <braunr> ok
-    <braunr> i'll look into this timer problem a bit more, there may be other
-      code involved
-    <braunr> yes, schedule_timeout could need a review
-    <braunr> actually, fakeroot rm -rf * is a good test
-    <braunr> and it's still damn slow
-
-
-## IRC, freenode, #hurd, 2013-11-04
-
-    <braunr> i think i know why fakeroot is slow no
-    <braunr> now
-    <braunr> schedule_timeout as implemented in pfinet can only be awaken by a
-      timeout
-    <braunr> even when the expected even comes in earlier
-    <braunr> so yes, the proper solution is to rewrite the timers using
-      interruptible_sleep_on_timeout (and in turn
-      pthread_hurd_cond_timedwait_np)
-    <braunr> hm no, it's still not that straightforward :(
-
-
-## IRC, freenode, #hurd, 2013-11-05
-
-    <braunr> youpi: i found the bug slowing down fakeroot-tcp
-    <braunr> it's actually a bug that slows down anything using the loopback
-      device
-    <braunr> (although there still is a problem with fakeroot chown)
-    <youpi> oh!
-    <braunr> basically
-    <braunr> the loopback device calls netif_rx from its xmit function
-    <braunr> which is perfectly fine
-    <braunr> except the glue code makes mark_bh (used to raise bottom halves)
-      broadcast a condition
-    <braunr> and since netif_rx is called from within xmit, which is called
-      from the net_bh worker thread
-    <braunr> the thread itself is never waiting for the condition when it is
-      broadcast
-    <braunr> it's very simple to fix, i'll send a patch later
-    <braunr> netcat to netcat now consumes 100% cpu
-    <braunr> as does fakeroot ls -Rl
-    <braunr> but for some reason fakeroot chown is still extremely slow
-    <braunr> and i've seen deadlocks in glibc (e.g. setlocale() getting the
-      locale lock, which is locked again in case libfakeroot fails and calls
-      strerror)
-    <braunr> so still a bit of debugging work needed
-
-
-## IRC, freenode, #hurd, 2013-11-06
-
-    <braunr> chown being slow with fakeroot-tcp can also be seen on linux
-
-    <teythoon> did your recent patch improve the performance of fakeroot-tcp ?
-    <braunr> yes
-    <teythoon> very nice :)
-    <braunr> but fakeroot chown is still slow
-    <braunr> although it's also slow on linux
-    <braunr> so i'm not looking into that any more for the time being
-    <braunr> as long as it's not used recursively on huge directories, it's
-      fine
-
-
-## IRC, freenode, #hurd, 2013-11-09
-
-    <teythoon> braunr: fakeroot-tcp is indeed much faster now :)
diff --git a/open_issues/pfinet_vs_system_time_changes.mdwn b/open_issues/pfinet_vs_system_time_changes.mdwn
deleted file mode 100644
index 09b00d30..00000000
--- a/open_issues/pfinet_vs_system_time_changes.mdwn
+++ /dev/null
@@ -1,101 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012 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_hurd]]
-
-
-# IRC, unknown channel, unknown date
-
-    <grey_gandalf> I did a sudo date...
-    <grey_gandalf> and the machine hangs
-
-This was very likely a misdiagnosis.
-
-
-# IRC, freenode, #hurd, 2011-03-25
-
-    <tschwinge> antrik: I suspect it'S some timing stuff in pfinet that perhaps
-      uses absolute time, and somehow wildely gets confused?
-    <antrik> tschwinge: BTW, pfinet doesn't actually die I think -- it just
-      drops open connections...
-    <antrik> perhaps it thinks they timed out
-    <tschwinge> antrik: Isn't the translator restarted instead?
-    <antrik> don't think so
-    <antrik> when pfinet actually dies, I also loose the NFS mounts, which
-      doesn't happen in this case
-    <antrik> hehe "... and the machine hangs"
-    <antrik> he didn't bother to check that the machine is perfectly fine, only
-      the SSH connection got dropped
-    <tschwinge> Ah, I see.  So it'S perhaps indeed simply closes TCP
-      connections that have been without data for ``too long''?
-    <antrik> yeah, that's my guess
-    <antrik> my clock is speeding, so ntpdate sets it in the past
-    <antrik> perhaps there is some math that concludes the connection have been
-      inactive for -200 seconds, which (unsigned) is more than any timeout :-)
-    <tschwinge> (The other way round, you might likely get some integer
-      wrap-around, and thus the same result.)
-    <tschwinge> Yes.
-
-
-# IRC, freenode, #hurd, 2011-10-26
-
-    <antrik> anyways, when ntpdate adjusts to the past, the connections hang,
-      roughly for the amount of time being adjusted
-    <antrik> they do not die though
-    <antrik> (well, if it's long enough, they probably timeout on the other
-      side...)
-
-
-# IRC, freenode, #hurd, 2011-10-27
-
-    <antrik> oh, another interesting thing I observed is that the the subhurd
-      pfinet did *not* drop the connection... only the main Hurd one. I thought
-      the clock is system-wide?...
-    <tschwinge> It is.
-    <antrik> it's really fascinating that only the pfinet on the Hurd instance
-      where I set the date is affected, and not the pfinet in the other
-      instance
-
-
-# IRC, freenode, #hurd, 2012-06-28
-
-    <bddebian> great, now setting the date/time fucked my machine
-    <pinotree> yes, we lack a monotonic clock
-    <pinotree> there are select() loops that use gettimeofday to determine how
-      much time to wait
-    <pinotree> thus if the time changes (eg goes back), the calculation goes
-      crazy
-    <antrik> pinotree: didn't you implement a monotonic clock?...
-    <pinotree> started to
-    <antrik> bddebian: did it really fuck the machine? normally it only resets
-      TCP connections...
-    <pinotree> yeah, i remember such gettimeofay-based select-loops at least in
-      pfinet
-    <antrik> I don't think it's a loop. it just drops the connections,
-      believing they have timed out
-    <bddebian> antrik: Well in this case I don't know because I am at work but
-      it fucked me because I now cannot get to it.. :)
-    <antrik> bddebian: that's odd... you should be able to just log in again
-      IIRC
-
-
-# IRC, freenode, #hurd, 2012-07-29
-
-    <antrik> pfinet can't cope with larger system time changes because it can't
-      use a monotonic clock
-
-[[clock_gettime]].
-
-    <braunr> well when librt becomes easily usable everywhere (it it's
-      possible), it will be quite easy to work around this issue
-    <pinotree> yes and no, you just need a monotonic clock and clock_gettime
-      able to use it
-    <braunr> why "no" ?
diff --git a/open_issues/pflocal_reauth.mdwn b/open_issues/pflocal_reauth.mdwn
deleted file mode 100644
index a575783e..00000000
--- a/open_issues/pflocal_reauth.mdwn
+++ /dev/null
@@ -1,42 +0,0 @@
-[[!meta copyright="Copyright © 2011, 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]]
-
-IRC, freenode, #hurd, 2011-04-02
-
-    <pinotree> youpi: i'm playing with pflocal, and noticing that a simple C
-      executable doesn't trigger reauthenticate
-    <pinotree> youpi: i've put a debug output (to file) in S_io_reauthenticate,
-      and with a simple C test (which uses unix sockets) it isn't called
-    <youpi> pinotree: it seems pflocal should return FS_RETRY_REAUTH in
-      retry_type
-    <youpi> to make glibc call reauthentication
-    <pinotree> pflocal?
-    <youpi> yes, in the dir_lookup handler
-
-[[hurd/interface/dir_lookup]].
-
-    <pinotree> isn't that ext2fs?
-    <youpi> libtrivfs had dir_lookup() too
-    <youpi> trivfs_check_open_hook can be used to tweak its behavior
-    <pinotree> ah, missed that pflocal was using libtrivfs, sorry
-    <youpi> there are probably very few translators which don't use one of the
-      lib*fs :)
-    <antrik> pinotree: what are you trying to do with pflocal?
-    <pinotree> local socket scredentials (SCM_CREDS)
-    <antrik> ah
-    <antrik> don't really know what that is, but I remember reading some
-      mention of it ;-)
-
----
-
-See also [[pflocal_socket_credentials_for_local_sockets]] and
-[[sendmsg_scm_creds]].
diff --git a/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn b/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn
deleted file mode 100644
index d252eb54..00000000
--- a/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn
+++ /dev/null
@@ -1,66 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2013 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_hurd]]
-
-
-# IRC, freenode, #hurd, 2011-03-28
-
-    <pinotree> basically, i'm trying to implement socket credentials for local
-      sockets, and i guessed doing it in pflocal would be the appropriate place
-    <pinotree> what i thought was filling the cmsg data for MSG_CRED at
-      S_socket_recv() call
-    <pinotree> in case i missed it, would there be a way to "identify" the
-      other side of the port associated to the sock_user of that call?
-    <pochu> pinotree: that's needed by dbus right? cool! (and I don't know)
-    <pinotree> (yes, and gamin)
-    <youpi> pinotree: you have them already, they're just not stored
-    <youpi> see S_io_reauthenticate
-    <youpi> Throw away the ids we went through all that trouble to get...
-    <youpi> (comment)
-    * pinotree looks
-    <pinotree> hm, and who calls that rpc?
-    <youpi> everybody
-    <youpi> since that's how ext2fs knows the permission to apply, for instance
-    <pinotree> ah, i was referring to the reauthenticate of pflocal, not
-      auth_server_authenticate()
-    <youpi> that's what I'm saying
-    <youpi> see __hurd_file_name_lookup_retry, which is the very internal part
-      of open()
-    <youpi> it calls io_reauthenticate()
-    <youpi> to authenticate itself to the underlying translator of the opened
-      node
-    <pinotree> youpi: so, hm, could be an option make the result of pflocal's
-      S_io_reauthenticate cached in the sock_user struct?
-    <youpi> yes
-    <pinotree> nice thanks, i will try that change first
-
-
-# IRC, OFTC, #debian-hurd, 2013-02-20
-
-    <pinotree> youpi: while debugging #700530, it seems that xorg does not have
-      working socket credentials on kfreebsd (and hurd too)
-    <pinotree> julien provided sune with
-      http://people.debian.org/~jcristau/kbsd-peercred.diff to test, but of
-      course that won't work for us (even if we would have working socket
-      credentials with cmsg)
-    <pinotree> (that patch is not tested yet)
-    <pinotree> at least, we're aware there's another place in need for working
-      socket credentials now
-    <youpi> k
-    <pinotree> youpi: (the patch above has been confirmed to work, with
-      s/SOL_SOCKET/0/ )
-    <youpi> 0 ?!
-    <pinotree> yeah
-
-
----
-
-See also [[pflocal_reauth]] and [[sendmsg_scm_creds]].
diff --git a/open_issues/pflocal_x_slowness.mdwn b/open_issues/pflocal_x_slowness.mdwn
deleted file mode 100644
index 9bc18128..00000000
--- a/open_issues/pflocal_x_slowness.mdwn
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_hurd]]
-
-IRC, #hurd, 2010-08-10
-
-    <antrik> m1k11e: I think the X slowness is a problem in pflocal, i.e. the translator handling UNIX domain sockets
-    <antrik> (X clients communicate with a local X server using domain sockets)
diff --git a/open_issues/phython.mdwn b/open_issues/phython.mdwn
deleted file mode 100644
index 62f70be0..00000000
--- a/open_issues/phython.mdwn
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-Go through James Morrison's (phython) pages, <http://hurd.dyndns.org/>, (via
-Intrernet Archive Wayback Machine), and archive / hunt down what's still
-interesting.
diff --git a/open_issues/placement_of_virtual_memory_regions.mdwn b/open_issues/placement_of_virtual_memory_regions.mdwn
deleted file mode 100644
index 39478f20..00000000
--- a/open_issues/placement_of_virtual_memory_regions.mdwn
+++ /dev/null
@@ -1,103 +0,0 @@
-[[!meta copyright="Copyright © 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_gnumach]]
-
-# IRC, freenode, #hurd, 2011-07-13
-
-    <braunr> does anyone know if posix (or mach) has requirements or a policy
-      about the placement of allocations of virtual space ?
-    <braunr> a policy such as bottom-up ?
-    <braunr> or "find lowest vailable space" ?
-    <jkoenig> braunr, you mean for vm_allocate ? You may want to check mmap()
-      but I can't remember ever coming across such a thing (except maybe
-      wrt. alignment)
-    <braunr> i was wondering how e.g. libraries are linked near the stack
-      (possibly at slightly random addresses)
-    <braunr> does the linker walk the address space entries top-down ?
-    <braunr> jkoenig: i didn't see anything either in the mach interface, but i
-      may have missed something
-    <braunr> jkoenig: most systems i've been studying mark the vm regions for
-      the heap and the stack
-    <braunr> but for mach, the stack is just allocated virtual memory at the
-      top of the space
-    <braunr> so the "placement policy" is either completely outside the kernel,
-      or relies on its interface
-    <jkoenig> braunr, actually I'm surprised Mach would even dictate where the
-      (one?) stack should be, I would have expected  it to be the job of
-      whatever creates a thread to make this kind of choice
-    <braunr> jkoenig: threads have their own stacks, under the responsibility
-      of the user trhead implementation
-    <braunr> but a program usually needs a stack even before it runs
-    <braunr> i had to set one to bootstrap modules in v0.1
-    <braunr> but i wonder if it's just for bootstrapping (and then propagated
-      by fork()) or part of the interface
-    <braunr> but this doesn't matter much actually, the allocation mechanism i
-      have in mind can actually support multiple policies
-    <jkoenig> I would guess the former (just for bootstrapping), since a new
-      task has no thread, and a new thread has no state. (but I'm no expert)
-    <braunr> i think so
-    <braunr> i'll have a look at the exec server
-    <braunr> jkoenig: did the previous implementation of procfs show task maps
-      ?
-    <jkoenig> braunr, I don't think so, I would probably have felt compelled to
-      include them in the new one if it did :-)
-    <braunr> hmmm
-    <braunr> we definitely need that
-    <jkoenig> is there a compelling use case you think about in particular?
-    <braunr> yes
-    <braunr> i failed to understand how gnumach behaved wrt ipc right spaces
-
-[[rework_gnumach_ipc_spaces]]
-
-    <braunr> and when i did, i found out my work was impossible to integrate
-    <jkoenig> "ipc right spaces" ?
-    <braunr> each task have an ipc space, which contains righs
-    <braunr> rights
-    <braunr> the ipc translation layer converts space/name and space/port
-      tuples to rights
-    <braunr> i wanted to replace the splay tree with a radix tree but didn't
-      get how the ipc table made the splay tree almost unused
-    <braunr> i don't want to make this kind of mistake again, so i'd like a
-      clear and detailed view of the vm spaces
-    <braunr> (it's only compelling for myself, all right)
-    <braunr> but
-    <braunr> we have vminfo
-    <braunr> rbraun@nordrassil:~$ vminfo $$ | wc -l
-    <braunr> 1046
-    <braunr> oh my
-    <braunr> in comparison, a firefox instance has less than 500 on linux
-    <jkoenig> you mean there's some kind of port name table (or functional
-      equivalent) which actually resides in the task's memory? (and that's what
-      shows up at the beginning of the address space with prot=0?)
-    <braunr> jkoenig: sorry for being confusing, it's not that at all
-    <jkoenig> (btw feel free to tell me to just go read the source or whatever)
-    <braunr> jkoenig: don't worry
-    <jkoenig> braunr, no problem
-    <braunr> jkoenig: i just compared a previous attempt to improve gnumach
-      which failed because i didn't have enough insight of the inner workings
-      of the kernel
-    <braunr> jkoenig: i really want to miss as little as possible on the vm
-      part, so having detailed information about what actually happens on
-      running hurd systems is something i need
-
-
-# IRC, freenode, #hurd, 2011-07-24
-
-    <braunr> oh btw, i noticed there are many mappings below the program text
-    <braunr> most notably, the stack
-    <braunr> except for special applications like wine, could this break
-      anything ?
-    <braunr> i also wonder how libraries are mapped, because there is nothing
-      to perform top-down allocations
-    <braunr> which means if the region below the program text is exhausted,
-      libraries could be mapped right after the heap
-    <youpi> it shouldn't break anything except things like wine & libgc, yes
-    <braunr> which could make malloc() fail :/
diff --git a/open_issues/populate_hurd_git_with_submodules_etc.mdwn b/open_issues/populate_hurd_git_with_submodules_etc.mdwn
deleted file mode 100644
index c89b95e9..00000000
--- a/open_issues/populate_hurd_git_with_submodules_etc.mdwn
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-[[!meta title="populate hurd.git with submodules, etc."]]
-
-Populate the top-level *[Savannah]/hurd.git* with a bunch of submodules
-(various translators; everything that's intersting), have it serve as sort of a
-tested distribution (because the submodules are versioned), plus adding build
-machinery / cross-compilation support, etc.
diff --git a/open_issues/posix_fadv_volatile.mdwn b/open_issues/posix_fadv_volatile.mdwn
deleted file mode 100644
index 6bd25e3e..00000000
--- a/open_issues/posix_fadv_volatile.mdwn
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-[[!meta title="POSIX_FADV_VOLATILE"]]
-
-[[!tag open_issue_gnumach open_issue_hurd]]
-
-May be interesting to watch what happens: LWN, Jonathan Corbet,
-[`POSIX_FADV_VOLATILE`](http://lwn.net/Articles/468896/), 2011-11-22.
diff --git a/open_issues/prelink.mdwn b/open_issues/prelink.mdwn
deleted file mode 100644
index ad85b9e2..00000000
--- a/open_issues/prelink.mdwn
+++ /dev/null
@@ -1,27 +0,0 @@
-[[!meta copyright="Copyright © 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_porting]]
-
-The *prelink* package, as distributed via Debian unstable, does build on
-GNU/Hurd.  After installing the satisfiable dependencies, use
-`dpkg-buildpackage -b -uc -d` to ignore SELinux and libc6-dev dependencies.
-
-It is unclear whether it also does work.  The testsuite (run manually) does
-*FAIL* on all tests, which is due to the prelinker doing something to the
-copied `ld.so.1` so that it faults on every invocation.  This does not happen
-on GNU/Linux.
-
-Not much in the prelinker is Linux-specific.  `src/get.c`'s `is_ldso_soname`
-should already cover our `ld.so.1` case (and what about `ld.so`?).  At the end
-of `src/arch-i386.c`, `.dynamic_linker` has to be set properly.  And, in that
-file there are some Linux process VM constants, of which `REG2S` and `REG2E`
-are the only relevant in the `!exec_shield` case.  Probably these need to be
-adjusted.  What else?
diff --git a/open_issues/problematic_packages.mdwn b/open_issues/problematic_packages.mdwn
deleted file mode 100644
index 700e3d71..00000000
--- a/open_issues/problematic_packages.mdwn
+++ /dev/null
@@ -1,31 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-[[!meta title="Problematic packages"]]
-
-[[!tag open_issue_gnumach open_issue_hurd]]
-
-This page lists the few packages whose build makes the Debian buildd box crash as of 2014, November 1st:
-
-* Kill pfinet
-
-  * nbd
-  * socklog
-
-* Kill the session
-
-  * idzebra
-  * ruby-hiredis
-  * libxs
-
-* Out of memory
-
-  * php-yac
-  * gnu-smalltalk
diff --git a/open_issues/proc_server_proc_exception_raise.mdwn b/open_issues/proc_server_proc_exception_raise.mdwn
deleted file mode 100644
index 1d0e92a3..00000000
--- a/open_issues/proc_server_proc_exception_raise.mdwn
+++ /dev/null
@@ -1,37 +0,0 @@
-[[!meta copyright="Copyright © 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_hurd]]
-
-IRC, freenode, #hurd, 2011-08-11
-
-    < youpi> in which error cases a reply port will actually have been consumed
-      by mach_msg ?
-    < youpi> it seems at least MACH_SEND_NOTIFY_IN_PROGRESS do?
-    < braunr>
-      http://www.gnu.org/software/hurd/gnumach-doc/Message-Send.html#Message-Send
-    < braunr> "These return codes imply that the message was returned to the
-      caller with a pseudo-receive operation: "
-    < braunr> isn't it what you're looking for ?
-    < youpi> well, it's hard to tell from the name
-    < youpi> I don't know what "pseudo-receiv operation" means
-    < braunr> it's described below
-    < youpi> ew
-    < braunr> it looks close enough to a normal receive to assume it consumes
-      the reply port
-    < youpi> so it's even more complex than what I thought
-    < youpi> well, no, it returns the right
-    < youpi> actually the error I'm getting is MACH_RCV_INVALID_NAME
-    < youpi> which I guess means the sending part succeeded
-    < youpi> the case at stake is proc/mgt.c: S_proc_exception_raise()
-    < youpi> when the proc_exception_raise() forward fails
-    < youpi> currently we always return 0, but if proc_exception_raise()
-      actually managed to send the message, the reply port was consumed and
-      MIG_NO_REPLY should be returned instead
diff --git a/open_issues/procfs_umount.mdwn b/open_issues/procfs_umount.mdwn
deleted file mode 100644
index f31467df..00000000
--- a/open_issues/procfs_umount.mdwn
+++ /dev/null
@@ -1,24 +0,0 @@
-[[!meta copyright="Copyright © 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_hurd]]
-
-As soon as one has accessed /proc/mounts, /proc can't be umount: 
-
-    # settrans -ga /proc
-    settrans: /proc: Device or resource busy
-
-This is because mtab is still mounted on /proc/mounts:
-
-    # settrans -ga /proc/mounts
-    # settrans -ga /proc
-
-settrans -R is supposed to be doing this, but unfortunately this is not
-implemented yet in libnetfs, see #ifdef NOTYET in netfs_shutdown.
diff --git a/open_issues/profiling.mdwn b/open_issues/profiling.mdwn
deleted file mode 100644
index e7dde903..00000000
--- a/open_issues/profiling.mdwn
+++ /dev/null
@@ -1,371 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 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]]."]]"""]]
-
-[[!meta title="Profiling, Tracing"]]
-
-*Profiling* ([[!wikipedia Profiling_(computer_programming) desc="Wikipedia
-article"]]) is a tool for tracing where CPU time is spent.  This is usually
-done for [[performance analysis|performance]] reasons.
-
-  * [[hurd/debugging/rpctrace]]
-
-  * [[gprof]]
-
-    Should be working, but some issues have been reported, regarding GCC spec
-    files.  Should be possible to fix (if not yet done) easily.
-
-  * [[glibc]]'s sotruss
-
-  * [[ltrace]]
-
-  * [[latrace]]
-
-  * [[community/gsoc/project_ideas/dtrace]]
-
-    Have a look at this, integrate it into the main trees.
-
-  * [[LTTng]]
-
-  * [[SystemTap]]
-
-  * ... or some other Linux thing.
-
-
-# IRC, freenode, #hurd, 2013-06-17
-
-    <congzhang> is that possible we develop rpc msg analyse tool? make it clear
-      view system at different level?
-    <congzhang> hurd was dynamic system, how can we just read log line by line
-    <kilobug> congzhang: well, you can use rpctrace and then analyze the logs,
-      but rpctrace is quite intrusive and will slow down things (like strace or
-      similar)
-    <kilobug> congzhang: I don't know if a low-overhead solution could be made
-      or not
-    <congzhang> that's the problem
-    <congzhang> when real system run, the msg cross different server, and then
-      the debug action should not intrusive the process itself
-    <congzhang> we observe the system and analyse os
-    <congzhang> when rms choose microkernel, it's expect to accelerate the
-      progress, but not
-    <congzhang> microkernel make debug a litter hard
-    <kilobug> well, it's not limited to microkernels, debugging/tracing is
-      intrusive and slow things down, it's an universal law of compsci
-    <kilobug> no, it makes debugging easier
-    <congzhang> I don't think so
-    <kilobug> you can gdb the various services (like ext2fs or pfinet) more
-      easily
-    <kilobug> and rpctrace isn't any worse than strace
-    <congzhang> how easy when debug lpc
-    <kilobug> lpc ?
-    <congzhang> because cross context
-    <congzhang> classic function call
-    <congzhang> when find the bug source, I don't care performance, I wan't to
-      know it's right or wrong by design, If it work as I expect 
-    <congzhang> I optimize it latter
-    <congzhang> I have an idea, but don't know weather it's usefull or not
-    <braunr> rpctrace is a lot less instrusive than ptrace based tools
-    <braunr> congzhang: debugging is not made hard by the design choice, but by
-      implementation details
-    <braunr> as a simple counter example, someone often cited usb development
-      on l3 being made a lot easier than on a monolithic kernel
-    <congzhang> Collect the trace information first, and then layout the msg by
-      graph, when something wrong, I focus the trouble rpc, and found what
-      happen around
-    <braunr> "by graph" ?
-    <congzhang> yes
-    <congzhang> braunr: directed graph or something similar
-    <braunr> and not caring about performance when debugging is actually stupid
-    <braunr> i've seen it on many occasions, people not being able to use
-      debugging tools because they were far too inefficient and slow
-    <braunr> why a graph ?
-    <braunr> what you want is the complete trace, taking into account cross
-      address space boundaries
-    <congzhang> yes
-    <braunr> well it's linear
-    <braunr> switching server
-    <congzhang> by independent process view it's linear
-    <congzhang> it's linear on cpu's view too
-    <congzhang> yes, I need complete trace, and dynamic control at microkernel
-      level
-    <congzhang> os, if server crash, and then I know what's other doing, from
-      the graph
-    <congzhang> graph needn't to be one, if the are not connect together, time
-      sort them
-    <congzhang> when hurd was complete ok, some tools may be help too
-    <braunr> i don't get what you want on that graph
-    <congzhang> sorry, I need a context
-    <congzhang> like uml sequence diagram, I need what happen one by one
-    <congzhang> from server's view and from the function's view
-    <braunr> that's still linear
-    <braunr> so please stop using the word graph
-    <braunr> you want a trace
-    <braunr> a simple call trace
-    <congzhang> yes, and a tool
-    <braunr> with some work gdb could do it
-    <congzhang> you mean under  some microkernel infrastructure help 
-    <congzhang> ?
-    <braunr> if needed
-    <congzhang> braunr: will that be easy?
-    <braunr> not too hard
-    <braunr> i've had this idea for a long time actually
-    <braunr> another reason i insist on migrating threads (or rather, binding
-      server and client threads)
-    <congzhang> braunr: that's  great
-    <braunr> the current problem we have when using gdb is that we don't know
-      which server thread is handling the request of which client
-    <braunr> we can guess it
-    <braunr> but it's not always obvious
-    <congzhang> I read the talk, know some of your idea
-    <congzhang> make things happen like classic kernel, just from function
-      ,sure:)
-    <braunr> that's it
-    <congzhang> I think you and other do a lot of work to improve the mach and
-      hurd, buT we lack the design document and the diagram, one diagram was
-      great than one thousand words
-    <braunr> diagrams are made after the prototypes that prove they're doable
-    <braunr> i'm not a researcher
-    <braunr> and we have little time
-    <braunr> the prototype is the true spec
-    <congzhang> that's why i wan't cllector the trace info and show, you can
-      know what happen and how happen, maybe just suitable for newbie, hope
-      more young hack like it
-    <braunr> once it's done, everything else is just sugar candy around it
-
-
-# IRC, freenode, #hurd, 2014-01-05
-
-    <teythoon> braunr: do you speak ocaml ?
-    <teythoon> i had this awesome idea for a universal profiling framework for
-      c
-    <teythoon> universal as in not os dependent, so it can be easily used on
-      hurd or in gnu mach
-    <teythoon> it does a source transformation, instrumenting what you are
-      interested in
-    <teythoon> for this transformation, coccinelle is used
-    <teythoon> i have a prototype to measure how often a field in a struct is
-      accessed
-    <teythoon> unfortunately, coccinelle hangs while processing kern/slab.c :/
-    <youpi> teythoon:  I do speak ocaml
-    <teythoon> awesome :)
-    <teythoon> unfortunately, i do not :/
-    <teythoon> i should probably get in touch with the coccinelle devs, most
-      likely the problem is that coccinelle runs in circles somewhere
-    <youpi> it's not so complex actually
-    <youpi> possibly,  yes
-    <teythoon> do you know coccinelle ?
-    <youpi> the only really peculiar thing in ocaml is lambda calculus
-    <youpi> +c
-    <youpi> I know a bit, although I've never really written an semantic patch
-      myself
-    <teythoon> i'm okay with that
-    <youpi> but I can understand them
-    <youpi> then ocaml should be fine for you :)
-    <youpi> just ask the few bits that you don't understand :)
-    <teythoon> yeah, i haven't really made an effort yet
-    <youpi> writing ocaml is a bit more difficult because you need to
-      understand the syntax, but for putting printfs it should be easy enough
-    <youpi> if you get a backtrace with ocamldebug (it basically works like
-      gdb), I can probably explain you what might be happening
-
-
-## IRC, freenode, #hurd, 2014-01-06
-
-    <teythoon> braunr: i'm not doing microoptimizations, i'm developing a
-      profiler :p
-    <braunr> teythoon: nice :)
-    <teythoon> i thought you might like it
-    <braunr> teythoon: you may want to look at
-      http://pdos.csail.mit.edu/multicore/dprof/
-    <braunr> from the same people who brought radixvm
-    <teythoon> which data structure should i test it with next ?
-    <braunr> uh, no idea :)
-    <braunr> the ipc ones i suppose
-    <teythoon> yeah, or the task related ones
-    <braunr> but be careful, there many "inline" versions of many ipc functions
-      in the fast paths
-    <braunr> and when they say inline, they really mean they copied it
-    <braunr> +are
-    <teythoon> but i have a microbenchmark for ipc performance
-    <braunr> you sure have been busy ;p
-    <braunr> it's funny you're working on a profiler at the same time a
-      collegue of mine said he was interested in writing one in x15 :)
-    <teythoon> i don't think inlining is a problem for my tool
-    <teythoon> well, you can use my tool for x15
-    <braunr> i told him he could look at what you did
-    <braunr> so i expect he'll ask soon
-    <teythoon> cool :)
-    <teythoon> my tool uses coccinelle to instrument c code, so this works in
-      any environment
-    <teythoon> one just needs a little glue and a method to get the data
-    <braunr> seems reasonable
-    <teythoon> for gnumach, i just stuff a tiny bit of code into the kdb
-
-    <teythoon> hm debians bigmem patch with my code transformation makes
-      gnumach hang early on
-    <teythoon> i don't even get a single message from gnumach
-    <braunr> ouch
-    <teythoon> or it is somethign else entirely
-    <teythoon> it didn't even work without my patches o_O
-    <teythoon> weird
-    <teythoon> uh oh, the kmem_cache array is not properly aligned
-    <teythoon> braunr: http://paste.debian.net/74588/
-    <braunr> teythoon: do you mean, with your patch ?
-    <braunr> i'm not sure i understand
-    <braunr> are you saying gnumach doesn't start because of an alignment issue
-      ?
-    <teythoon> no, that's unrelated
-    <teythoon> i skipped the bigmem patch, have a running gnumach with
-      instrumentation
-    <braunr> hum, what is that aliased column ?
-    <teythoon> but, despite my efforts with __attribute__((align(64))), i see
-      lot's of accesses to kmem_cache objects which are not properly aligned
-    <braunr> is that reported by the performance counters ?
-    <teythoon> no
-    <teythoon> http://paste.debian.net/74593/
-    <braunr> aer those the previous lines accessed by other unrelated code ?
-    <braunr> previous bytes in the same line*
-    <teythoon> this is a patch generated to instrument the code
-    <teythoon> so i instrument field access of the form i->a
-    <teythoon> but if one does &i->a, my approach will no longer keep track of
-      any access through that pointer
-    <teythoon> so i do not count that as an access but as creating an alias for
-      that field
-    <braunr> ok
-    <teythoon> so if that aliased count is not zero, the tool might
-      underestimate the access count
-    <teythoon> hm
-    <teythoon> static struct kmem_cache kalloc_caches[KALLOC_NR_CACHES]
-      __attribute__((align(64)));
-    <teythoon> but
-    <teythoon> nm gnumach|grep kalloc_caches
-    <teythoon> c0226e20 b kalloc_caches
-    <teythoon> ah, that's fine
-    <braunr> yes
-    <teythoon> nevr mind
-    <braunr> don't we have a macro for the cache line size ?
-    <teythoon> ah, there are a great many more kmem_caches around and noone
-      told me ...
-    <braunr> teythoon: eh :)
-    <braunr> aren't you familiar with type-specific caches ?
-    <teythoon> no, i'm not familiar with anything in gnumach-land
-    <braunr> well, it's the regular slab allocator, carrying the same ideas
-      since 1994
-    <braunr> it's pretty much the same in linux and other modern unices
-    <teythoon> ok
-    <braunr> the main difference is likely that we allocate our caches
-      statically because we have no kernel modules and know we'll never destroy
-      them, only reap them
-    <teythoon> is there a macro for the cache line size ?
-    <teythoon> there is one burried in the linux source
-    <teythoon> L1_CACHE_BYTES from linux/src/include/asm-i386/cache.h
-    <braunr> there is one in kern/slab.h
-    <teythoon> but it is out of date
-    <teythoon> there is ?
-    <braunr> but it's commented out
-    <braunr> only used when SLAB_USE_CPU_POOLS is defined
-    <braunr> but the build system should give you CPU_L1_SHIFT
-    <teythoon> hm
-    <braunr> and we probably should define CPU_L1_SIZE from that
-      unconditionnally in config.h or a general param.h file if there is one
-    <braunr> the architecture-specific one perhaps
-    <braunr> although it's exported to userland so maybe not
-
-
-## IRC, freenode, #hurd, 2014-01-07
-
-    <teythoon> braunr: linux defines ____cacheline_aligned :
-      http://lxr.free-electrons.com/source/include/linux/cache.h#L20
-    <teythoon> where would i put a similar definition in gnumach ?
-    <taylanub> .oO( four underscores ?!? )
-    <teythoon> heh
-    <teythoon> yes, four
-    <braunr> teythoon: yes :)
-
-    <teythoon> are kmem_cache objects ever allocated dynamically in gnumach ?
-    <braunr> no
-    <teythoon> hm
-    <braunr> i figured that, since there are no kernel modules, there is no
-      need to allocate them dynamically, since they're never destroyed
-    <teythoon> so i aligned all statically declarations with
-      __attribute__((align(1 << CPU_L1_SHIFT)))
-    <teythoon> but i still see 77% of all accesses being to objects that are
-      not properly aligned o_O
-    <teythoon> ah
-    <teythoon> >,<
-    <braunr> you could add an assertion in kmem_cache_init to find out what's
-      wrong
-    <teythoon> *aligned
-    <braunr> eh :)
-    <braunr> right
-    <teythoon> grr
-    <teythoon> sweet, the kmem_caches are now all properly aligned :)
-    <braunr> :)
-
-    <braunr> hm
-    <braunr> i guess i should change what vmstat reports as "cache" from the
-      cached objects to the external ones (which map files and not anonymous
-      memory)
-    <teythoon> braunr: http://paste.debian.net/74869/
-    <teythoon> turned out that struct kmem_cache was actually an easy target
-    <teythoon> no bitfields, no embedded structs that were addressed as such
-      (and not aliased)
-    <braunr> :)
-
-
-## IRC, freenode, #hurd, 2014-01-09
-
-    <teythoon> braunr: i didn't quite get what you and youpi were talking about
-      wrt to the alignment attribute
-    <teythoon> define a type for struct kmem_cache with the alignment attribute
-      ? is that possible ?
-    <teythoon> ah, like it's done for kmem_cpu_pool
-    <braunr> teythoon: that's it :)
-    <braunr> note that aligning a struct doesn't change what sizeof returns
-    <teythoon> heh, that save's one a whole lot of trouble indeed
-    <braunr> you have to align a member inside for that
-    <teythoon> why would it change the size ?
-    <braunr> imagine an array of such structs
-    <teythoon> ah
-    <teythoon> right
-    <teythoon> but it fits into two cachelines exactly
-    <braunr> that wouldn't be a problem with an array either
-    <teythoon> so an array of those will still be aligned element-wise
-    <teythoon> yes
-    <braunr> and it's often used like that, just as i did for the cpu pools
-    <braunr> but then one is tempted to think the size of each element has
-      changed too
-    <braunr> and then use that technique for, say, reserving a whole cache line
-      for one variable
-    <teythoon> ah, now i get that remark ;)
-    <braunr> :)
-
-    <teythoon> braunr: i annotated struct kmem_cache in slab.h with
-      __cacheline_aligned and it did not have the desired effect
-    <braunr> can you show the diff please ?
-    <teythoon> http://paste.debian.net/75192/
-    <braunr> i don't know why :/
-    <teythoon> that's how it's done for kmem_cpu_pool
-    <braunr> i'll try it here
-    <teythoon> wait
-    <teythoon> i made a typo
-    <teythoon> >,<
-    <teythoon> __cachline_aligned
-    <teythoon> bad one
-    <braunr> uh :)
-    <braunr> i don't see it
-    <braunr> ah yes
-    <braunr> missing e
-    <teythoon> yep, works like a charme :)
-    <teythoon> nice, good to know :)
-    <braunr> :)
-    <teythoon> given the previous discussion, shall i send it to the list or
-      commit it right away ?
-    <braunr> i'd say go ahead and commit
diff --git a/open_issues/ps_SIGSEGV.mdwn b/open_issues/ps_SIGSEGV.mdwn
deleted file mode 100644
index 24d5cb4f..00000000
--- a/open_issues/ps_SIGSEGV.mdwn
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!meta copyright="Copyright © 2013 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_hurd]]
-
-
-# IRC, freenode, #hurd, 2013-02-05
-
-    <braunr> ps -l segfaults
-    <braunr> ah, perhaps because of the subhurd
diff --git a/open_issues/pth.mdwn b/open_issues/pth.mdwn
deleted file mode 100644
index 12bf5098..00000000
--- a/open_issues/pth.mdwn
+++ /dev/null
@@ -1,28 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010 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_porting]]
-
-IRC, unknown channel, unknown date.
-
-    <azeem> seems pth still doesn't work
-    <bddebian> Doesn't build or doesn't work?
-    <azeem> both
-    <azeem> some configure test keep grinding the CPU, same for the test suite
-    <azeem> which apparently runs pth_init() and never returns
-
-    <azeem> actually, pth fails to build right now
-    <azeem> pth_mctx.c:477: error: request for member '__pc' in something not a structure or union
-
-    <azeem> I know the pth test suite fails (it locks up the machine) or used to fail, so I guess porting work for pth would be needed
-    <azeem> < marcusb> from reading the pth/PORTING document, porting libpth shouldn't be too hard...
-
-    <youpi> dropped pth [from the channel's topic], as we think we know why it fails (sigaltstack is bogus)
diff --git a/open_issues/pthread_atfork.mdwn b/open_issues/pthread_atfork.mdwn
deleted file mode 100644
index d386e5c0..00000000
--- a/open_issues/pthread_atfork.mdwn
+++ /dev/null
@@ -1,111 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2013 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_libpthread]]
-
-`pthread_atfork` is not actually implemented, making some programs fail. Code
-can probably be borrowed from `nptl/sysdeps/unix/sysv/linux/register-atfork.c`.
-
-
-# IRC, OFTC, #debian-hurd, 2013-08-21
-
-    <pinotree> SRCDIR/opal/mca/memory/linux/arena.c:387: warning: warning:
-      pthread_atfork is not implemented and will always fail
-
-
-# Samuel's implementation
-
-TODO.
-
-
-## IRC, OFTC, #debian-hurd, 2013-10-08
-
-    <pinotree> youpi: if you need/want to test your pthread_atfork
-      implementation, you can check libposix-atfork-perl and its test suite
-      (whose test 004 hangs now, with eglibc -93)
-    <youpi> while it failed previously indeed
-    <youpi> we might simply need to rebuild perl against it
-    <youpi> (I see ifdef pthread_atfork in perl)
-
-
-## undefined reference to `__start__hurd_atfork_prepare_hook'
-
-### IRC, freenode, #hurd, 2013-10-16
-
-    <teythoon> tschwinge: I'd love to try your cross-gnu tool, the wiki page
-      suggests that the list of required source packages is outdated. can you
-      give me some hints?
-    <teythoon> tschwinge: I got this error running cross-gnu:
-      http://paste.debian.net/58303/
-        make[4]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/setjmp'
-        make subdir=string -C ../string ..=../ objdir=/home/teythoon/repos/hurd/cross/obj/glibc -f Makefile -f ../elf/rtld-Rules rtld-all rtld-modules='rtld-strchr.os rtld-strcmp.os rtld-strcpy.os rtld-strlen.os rtld-strnlen.os rtld-memchr.os rtld-memcmp.os rtld-memmove.os rtld-memset.os rtld-mempcpy.os rtld-stpcpy.os rtld-memcpy.os rtld-rawmemchr.os rtld-argz-count.os rtld-argz-extract.os rtld-stpncpy.os'
-        make[4]: Entering directory `/home/teythoon/repos/hurd/cross/src/glibc/string'
-        make[4]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/string'
-        make[4]: Entering directory `/home/teythoon/repos/hurd/cross/src/glibc/string'
-        make[4]: Nothing to be done for `rtld-all'.
-        make[4]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/string'
-        make[3]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/elf'
-        i686-pc-gnu-gcc   -shared -static-libgcc -Wl,-O1  -Wl,-z,defs -Wl,-dynamic-linker=/lib/ld.so.1  -B/home/teythoon/repos/hurd/cross/obj/glibc/csu/  -Wl,--version-script=/home/teythoon/repos/hurd/cross/obj/glibc/libc.map -Wl,-soname=libc.so.0.3 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -nostdlib -nostartfiles -e __libc_main -L/home/teythoon/repos/hurd/cross/obj/glibc -L/home/teythoon/repos/hurd/cross/obj/glibc/math -L/home/teythoon/repos/hurd/cross/obj/glibc/elf -L/home/teythoon/repos/hurd/cross/obj/glibc/dlfcn -L/home/teythoon/repos/hurd/cross/obj/glibc/nss -L/home/teythoon/repos/hurd/cross/obj/glibc/nis -L/home/teythoon/repos/hurd/cross/obj/glibc/rt -L/home/teythoon/repos/hurd/cross/obj/glibc/resolv -L/home/teythoon/repos/hurd/cross/obj/glibc/crypt -L/home/teythoon/repos/hurd/cross/obj/glibc/mach -L/home/teythoon/repos/hurd/cross/obj/glibc/hurd -Wl,-rpath-link=/home/teythoon/repos/hurd/cross/obj/glibc:/home/teythoon/repos/hurd/cross/obj/glibc/math:/home/teythoon/repos/hurd/cross/obj/glibc/elf:/home/teythoon/repos/hurd/cross/obj/glibc/dlfcn:/home/teythoon/repos/hurd/cross/obj/glibc/nss:/home/teythoon/repos/hurd/cross/obj/glibc/nis:/home/teythoon/repos/hurd/cross/obj/glibc/rt:/home/teythoon/repos/hurd/cross/obj/glibc/resolv:/home/teythoon/repos/hurd/cross/obj/glibc/crypt:/home/teythoon/repos/hurd/cross/obj/glibc/mach:/home/teythoon/repos/hurd/cross/obj/glibc/hurd -o /home/teythoon/repos/hurd/cross/obj/glibc/libc.so -T /home/teythoon/repos/hurd/cross/obj/glibc/shlib.lds /home/teythoon/repos/hurd/cross/obj/glibc/csu/abi-note.o /home/teythoon/repos/hurd/cross/obj/glibc/elf/soinit.os /home/teythoon/repos/hurd/cross/obj/glibc/libc_pic.os /home/teythoon/repos/hurd/cross/obj/glibc/elf/sofini.os /home/teythoon/repos/hurd/cross/obj/glibc/elf/interp.os /home/teythoon/repos/hurd/cross/obj/glibc/elf/ld.so /home/teythoon/repos/hurd/cross/obj/glibc/mach/libmachuser-link.so /home/teythoon/repos/hurd/cross/obj/glibc/hurd/libhurduser-link.so -lgcc
-        /home/teythoon/repos/hurd/cross/obj/glibc/libc_pic.os: In function `__fork':
-        /home/teythoon/repos/hurd/cross/src/glibc/posix/../sysdeps/mach/hurd/fork.c:70: undefined reference to `__start__hurd_atfork_prepare_hook'
-        /home/teythoon/repos/hurd/cross/lib/gcc/i686-pc-gnu/4.8.1/../../../../i686-pc-gnu/bin/ld: /home/teythoon/repos/hurd/cross/obj/glibc/libc_pic.os: relocation R_386_GOTOFF against undefined hidden symbol `__start__hurd_atfork_prepare_hook' can not be used when making a shared object
-        /home/teythoon/repos/hurd/cross/lib/gcc/i686-pc-gnu/4.8.1/../../../../i686-pc-gnu/bin/ld: final link failed: Bad value
-        collect2: error: ld returned 1 exit status
-        make[2]: *** [/home/teythoon/repos/hurd/cross/obj/glibc/libc.so] Error 1
-        make[2]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/elf'
-        make[1]: *** [elf/subdir_lib] Error 2
-        make[1]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc'
-        make: *** [all] Error 2
-        + rm -f /home/teythoon/repos/hurd/cross/sys_root/lib/ld.so
-        + exit 100
-        
-        binutils-2.23.2,
-        gcc-4.8.1,
-        everything else is from git as specified in the wiki.
-
-
-### IRC, freenode, #hurd, 2013-10-24
-
-    <AliciaC> in recent glibc commits (tschwinge/Roger_Whittaker branch) there
-      are references to _hurd_atfork_* symbols in sysdeps/mach/hurd/fork.c, and
-      some _hurd_fork_* symbols, some of the _hurd_fork_* symbols seem to be
-      defined in Hurd's boot/frankemul.ld (mostly guessing by their names being
-      mentioned, I don't know linker script syntax), but those _hurd_atfork_*
-      symbols don't seem to be defined there, are they supposed to be defined
-      elsewhere or is th
-    <AliciaC> does anyone know where the _hurd_atfork_* group of symbols
-      referenced in glibc are defined (if anywhere)?
-    <youpi> AliciaC: it's the DEFINE_HOOK (_hurd_atfork_prepare_hook, (void));
-      in glibc/sysdeps/mach/hurd/fork.c
-    <AliciaC> hm, is that not just a declaration?
-    <youpi> no, it's a definition, as its name suggests :
-    <AliciaC> (despite the macro name)
-    <youpi> :)
-    <AliciaC> ok
-    <AliciaC> I should look into it more, I could have sworn I was getting
-      undefined references, but maybe the symbol names used are different from
-      those defined, but that'd be odd as well, in the same file and all
-    <AliciaC> I mean, I do get undefined references, but question is if it's to
-      things that should have been defined or not
-    <youpi> what undefined references do you gaT?
-    <youpi> s/gaT/get
-    <AliciaC> I'll get back to you once I have that system up again
-    <AliciaC> youpi: sysdeps/mach/hurd/fork.c:70: undefined reference to
-      `__start__hurd_atfork_prepare_hook'
-    <AliciaC> fork.c:70: 'RUN_HOOK (_hurd_atfork_prepare_hook, ());'
-    <AliciaC> DEFINE_HOOK (_hurd_atfork_prepare_hook, (void)); is higher up in
-      the file
-    <AliciaC> though there is also this message: build/libc_pic.os: relocation
-      R_386_GOTOFF against undefined hidden symbol
-      `__start__hurd_atfork_prepare_hook' can not be used when making a shared
-      object
-
-
-### [[!message-id "878uvfmwvs.fsf@kepler.schwinge.homeip.net"]]
diff --git a/open_issues/python.mdwn b/open_issues/python.mdwn
deleted file mode 100644
index 403ff8aa..00000000
--- a/open_issues/python.mdwn
+++ /dev/null
@@ -1,47 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-[[!meta title="Foster Python programming"]]
-
-Resolve issues uncovered by Python's test suite, and enable Hurd-specific
-features.
-
-There is a [[!FF_project 260]][[!tag bounty]] on this task.
-
----
-
-
-# Part I
-
-First, make the language functional, have its test suite pass without errors.
-
-
-## Original [[community/GSoC]] Task Description
-
-[[!inline pages=community/gsoc/project_ideas/perl_python feeds=no]]
-
-
-## Analysis
-
-  * [[select_bogus_fd]]
-
----
-
-
-# Part II
-
-Next, Hurd-specific features can be added.  Add an interface to the
-language/environment for being able to do [[RPC]] calls, in order to program
-[[hurd/translator]]s natively in Python.
-
-
-## Original [[community/GSoC]] Task Description
-
-[[!inline pages=community/gsoc/project_ideas/language_bindings feeds=no]]
diff --git a/open_issues/resource_management_problems.mdwn b/open_issues/resource_management_problems.mdwn
deleted file mode 100644
index daf97954..00000000
--- a/open_issues/resource_management_problems.mdwn
+++ /dev/null
@@ -1,131 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010, 2013 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_gnumach open_issue_hurd open_issue_viengoos]]
-
-[[microkernel/Mach]] interfaces do not allow for proper resource accounting,
-when a server allocates resources on behalf of a client.
-
-Mach can't do a good job at resource management, as it doesn't have enough
-information how resources are used: which data is important and which is
-discardable, for example.
-
-These issues are what Neal Walfield is working on with his new kernel
-[[microkernel/viengoos]].
-
-
-# Kernel
-
-Inside the [[kernel]], there is commonly a need to allocate resources according
-to externally induced demand, dynamically.  For example, for memory-management
-data structures (page tables), process table entries, thread control blocks,
-[[capability]] tables, incoming network packages, blocks that are read in from
-disk, the keyboard type-ahead buffer for a in-kernel keyboard driver.  Some of
-these are due to actions driven by user-space requests, others are due to
-actions internal to the the kernel itself.  Some of these buffers can be sized
-statically (keyboard type-ahead buffer), and are thus unproblematic.  Others
-are not, and should thus be attributed to their user space entities.  In the
-latter (ideal) case, all resources -- that is, including those needed inside
-the kernel -- that a user space task needs for execution are provided by itself
-(and, in turn, provided by its parent / principal), and the kernel itself does
-not need to allocate any resources dynamically out of an its own memory pool.
-This avoids issues like [[microkernel/Mach]]'s [[zalloc_panics]] upon user
-space processes allocating too many [[microkernel/mach/port]]s, for example.
-
-[[!toggleable id=fof_plos09 text="""[[!template id=note
-text="*[[fof\_plos09|microkernel/barrelfish]]*:
-{{$microkernel/barrelfish#fof_plos09}}"]]"""]]
-
-[[!toggleable id=sel4 text="""[[!template id=note
-text="[[*sel4*|microkernel/l4]]: {{$microkernel/l4#sel4}}"]]"""]]
-
-In [[!toggle id=fof_plos09 text="[fof\_plos09]"]], the authors describe in
-section 3 how they model their [[capability]] system according to [[!toggle
-id=sel4 text="[sel4]"]] using a *retype* operation that *takes an existing
-capability and produces one or more derived capabilities [...] used to create
-new kernel-level memory objects (such as page tables or execution contexts)
-from capabilities to raw regions of RAM*.
-
-This is, of course, non-trivial to implement, and also requires changing the
-[[RPC]] interfaces, for example, but it is a valid approach, a research topic.
-
-([[!taglink open_issue_documentation]]: compare this to Linux [`vmsplice`'s
-SPLICE_F_GIFT
-flag](http://www.kernel.org/doc/man-pages/online/pages/man2/vmsplice.2.html#DESCRIPTION).)
-
-
-## IRC, freenode, #hurd, 2011-07-31
-
-    < braunr> one of the biggest problems on the hurd is that, when a client
-      makes a call, kernel (and other) resources are allocated on behalf of the
-      server performaing the requested action
-    < braunr> performing*
-    < braunr> this makes implementing scheduling and limits difficult
-    < CTKArcher> And could changing the kernel change anything to that ?
-    < braunr> yes but you'd probably need to change its interface as well
-    < braunr> iirc, the critique describes resource containers
-    < braunr> but no work has been done on the current hurd (hence the hurdng
-      attempts)
-
-
-## IRC, freenode, #hurd, 2013-08-13
-
-In context of <https://teythoon.cryptobitch.de/posts/my-worst-week-yet/>.
-
-    <braunr> teythoon: actually, thread migration isn't required for resource
-      accounting
-
-[[Mach_migrating_threads]].
-
-    <teythoon> braunr: but it solves it for free, doesn't it?
-    <braunr> teythoon: no
-    <braunr> it's really more complicated than that
-
-
-# Further Examples
-
-  * [[hurd/critique]]
-
-  * [[IO_accounting]]
-
-  * [[translators_set_up_by_untrusted_users]], and [[pagers]]
-
-  * [[configure_max_command_line_length]]
-
-
-## [[hurd/translator/exec]] server
-
-### IRC, freenode, #hurd, 2013-08-05
-
-    <teythoon> unzipping stuff in the exec server enables a dos on filesystem
-      translators
-    <teythoon> https://teythoon.cryptobitch.de/gsoc/heap/hello-1g.bz2 is
-      /hurd/hello padded with a gig of zeros, compressed with bzip2
-    <teythoon> if set as an passive translator, it stalls other requests to the
-      filesystem, at least it does if ext2fs is used
-    <braunr> teythoon: ?
-    <braunr> teythoon: what's the dos here ?
-    <teythoon> I can prevent you from doing anything with the root filesystem
-    <teythoon> I'm kind of surprised myself, maybe a lock is held during the
-      exec of the translator?
-    <teythoon> the filesystem the hello-1g.bz2 translator is bound to is
-      affected
-    <braunr> teythoon: i don't understand
-    <braunr> have you tried starting something from another file system ?
-    <braunr> the lock may simply be in the exec server itself
-    <teythoon> no, starting other things works fine
-    <teythoon> but on the other hand, a find / is stalled
-    <braunr> :/
-    <braunr> *sigh*
-    <teythoon> don't worry
-    <teythoon> there is a solution :p
-    <braunr> :)
-    <teythoon> and it only requires deleting code
diff --git a/open_issues/resource_management_problems/configure_max_command_line_length.mdwn b/open_issues/resource_management_problems/configure_max_command_line_length.mdwn
deleted file mode 100644
index 6c0a0d99..00000000
--- a/open_issues/resource_management_problems/configure_max_command_line_length.mdwn
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!meta copyright="Copyright © 2009 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_porting]]
-
-    <terpstra> do the buildds also crash?
-    <youpi> sometimes
-    <youpi> usually when a configure scripts tries to find out how large a
-      command line can be
-    <youpi> (thus eating all memory)
diff --git a/open_issues/resource_management_problems/io_accounting.mdwn b/open_issues/resource_management_problems/io_accounting.mdwn
deleted file mode 100644
index 113b965a..00000000
--- a/open_issues/resource_management_problems/io_accounting.mdwn
+++ /dev/null
@@ -1,49 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-IRC, freenode, #hurd, 2011-07-22
-
-    <braunr> an interesting question i've had in mind for a few weeks now is
-      I/O accounting
-    <braunr> what *is* I/O on a microkernel based system ?
-    <braunr> can any cross address space transfer be classified as I/O ?
-
-IRC, freenode, #hurd, 2011-07-29
-
-    < braunr> how does the hurd account I/O ?
-    < youpi> I don't think it does
-    < youpi> not an easy task, actually
-    < youpi> since gnumach has no idea about it
-    < braunr> yes
-    < braunr> another centralization issue
-    < braunr> does network access count as I/O on linux ?
-    < youpi> no
-    < braunr> not even nfs ?
-    < youpi> else you'd get 100% for servers :)
-    < braunr> right
-    < youpi> nfs goes through vfs first
-    < braunr> i'll rephrase my question
-    < youpi> I'd need to check but I believe it can check nfs
-    < braunr> does I/O accounting occur at the vfs level or block layer ?
-    < youpi> I don't know, but I beleive vfs
-    < youpi> (at least that's how I'd do it)
-    < braunr> i don't have any more nfs box to test that :/
-    < braunr> personally i'd do it at the block layer :)
-    < youpi> well, both
-    < youpi> so e2fsck can show up too
-    < braunr> yes
-    < youpi> it's just a matter of ref counting
-    < youpi> apparently nfs doesn't account
-    < youpi> find . -printf "" doesn't show up in waitio
-    < braunr> good
-    < youpi> well, depends on the point of view
-    < youpi> as a user, you'd like to know whether your processes are stuck on
-      i/o (be it disk or net)
-    < braunr> this implies clearly defining what io is
diff --git a/open_issues/resource_management_problems/pagers.mdwn b/open_issues/resource_management_problems/pagers.mdwn
deleted file mode 100644
index 4c36703c..00000000
--- a/open_issues/resource_management_problems/pagers.mdwn
+++ /dev/null
@@ -1,322 +0,0 @@
-[[!meta copyright="Copyright © 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_gnumach]]
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2011-09-14
-
-Coming from [[translators_set_up_by_untrusted_users]], 2011-09-14 discussion:
-
-    <slpz> antrik: I think a tunable option for preventing non-root users from
-      creating pagers and attaching translators could also be desirable
-    <antrik> slpz: why would you want to prevent creating pagers and attaching
-      translators?
-    <tschwinge> Preventing resource exhaustion, I guess.
-    <slpz> antrik: security and (as tschwinge says) for prevent a rouge pager
-      from exhausting the system.
-    <slpz> antrik: without the ability to use translators for non-root users,
-      Hurd can provide (almost) the same level of resource protection than
-      other *nixes
-
-See also: [[translators_set_up_by_untrusted_users]],
-[[hurd/translator/tmpfs/tmpfs_vs_defpager]].
-
-    <braunr> the hurd is about that though
-    <slpz> there should be also a limit on the number of outstanding requests
-      that a task can have, and some other easily traceable values
-    <braunr> port messages queues have limits
-    <antrik> slpz: anything can exhaust the system. there are much more basic
-      limits that are missing... and I don't see how translators or pagers are
-      special in that regard
-    <slpz> braunr: that's what I said tunable. If I don't share my computer
-      with untrusted users, I want full functionality. Otherwise, I can enable
-      that limitation
-    <slpz> braunr: but I think those limits are on reception
-    <braunr> that's a wrong solution
-    <slpz> antrik: because pagers are external memory objects, and those are
-      treated differently
-    <braunr> compared to what ?
-    <braunr> and yes, the limit is on the message queue, on reception
-    <braunr> why is that a problem ?
-    <slpz> antrik: forbidding the use of translator was for security, to avoid
-      the problem of traversing an untrusted FS
-    <slpz> braunr: compared to anonymous memory
-    <slpz> braunr: because if the limit is on reception, a task can easily do a
-      DoS against a server
-    <braunr> hm actually, the problems we have with swap handling is that
-      anonymous memory is handled in a very similar way as other objects
-    <slpz> braunr: I want to limit the number of outstanding (unprocessed
-      messages in queues) requests
-    <braunr> slpz: the solution isn't about forbidding the use of translators,
-      but changing common code (libc i guess) not to use them, they can still
-      run beside
-    <slpz> braunr: that's because, currently, the external page limit is not
-      enforced
-    <braunr> i'm also not sure about DoS attacks
-    <braunr> if i'm right, there is often one port for each managed object,
-      which usually exist per client
-    <slpz> braunr: yes, that could an option too (for translators, not for
-      pagers)
-    <braunr> i don't see how pagers wouldn't be translators on the hurd
-    <slpz> braunr: all pagers are translators, but not all translators are
-      pagers ;-)
-    <braunr> so if it works for translators, it also works for pagers
-    <slpz> braunr: it would fix the security issue, but not the resource
-      exhaustion problem, with only affects to pagers
-    <braunr> i just don't see a point in implementing resource limits before
-      even fixing other fundamental issues
-    <braunr> the only way to avoid resource exhaustion is resource limits
-    <antrik> slpz: just not following untrusted translators is much more useful
-      than forbidding them alltogether
-    <braunr> and the main problem of mach is resource accounting
-    <braunr> so first, fix that, using the critique as a starting point
-
-[[hurd/critique]].
-
-    <slpz> braunr: i'm not saying that this should be implemented right now,
-      i'm just pointing out this possibility
-    <braunr> i think we're all mostly aware of it
-    <slpz> braunr: resource accounting, as it's expressed in the critique,
-      would be wonderful, but it's just too complex IMHO
-    <braunr> it requires carefully designed changes to the interface yes
-    <slpz> to the interface, to the internals, to user space tasks...
-    <braunr> the internals wouldn't be impacted that much
-    <braunr> user space tasks would mostly include hurd servers
-    <braunr> if the changes are centralized in libraries, it should be easy to
-      provide to the servers
-
-
-# IRC, freenode, #hurd, 2011-09-22
-
-    <slpz> antrik: I've also implemented a simple resource control on dirty
-      pages and changed pageout_scan to free external pages, and only touch
-      anonymous memory if it's really needed
-    <slpz> antrik: those combined make the system work better under heavy load
-    <slpz> antrik: 1.5 GB of RAM and another 1.5 GB of swap helps a lot, too
-      :-)
-    <antrik> hm... I'm not sure what these things mean exactly TBH... but I
-      wonder whether some of these could fix the performance degradation (and
-      ultimate crash) I described recently...
-
-[[/open_issues/default_pager]], [[system performance degradation
-(?)|performance/degradation]].
-
-    <antrik> care to explain them to a noob like me?
-    <slpz> probably not. During my tests, I've noticed that, at some points,
-      the system performance starts to degrade, and this doesn't change until
-      it's restarted
-    <slpz> but I wasn't able to create a test case to reproduce the bug...
-    <slpz> antrik: Sure. First, I've changed GNU Mach to:
-    <slpz>  - Classify all pages from data_supply as external, and count them
-      in vm_page_external_count (previously, this variable was always zero)
-
-[[/open_issues/mach_vm_pageout]]
-
-    <slpz>  - Count all pages for which a  data_unlock has been requested as
-      potentially dirty pages
-    <antrik> there is one important bit I forgot to mention in my recent
-      report: one "reliable" way to cause growing swap usage is simply
-      installing a lot of debian packages (e.g. running an apt-get upgrade)
-    <antrik> some other kinds of I/O also seem to have such an effect, but I
-      wasn't able to pinpoint specific situations
-    <slpz>  - Establish a limit on how many potentially dirty pages are
-      allowed. If it's reached, a notification (right now it's just a bogus
-      m_o_data_unlock, to avoid implementing a new RPC) it's sent to the pager
-      which has generated the page fault
-    <slpz>  - Establish a hard limit on those dirt pages. If it's reached,
-      threads asking for a data_unlock are blocked until someone cleans some
-      pages. This should be improved with a forced pageout, if needed.
-    <slpz>  - And finally, in vm_pageout_scan, run over the inactive queue
-      searching for clean, external pages, freeing them. If it's not possible
-      to free enough pages, or if vm_page_external_count is less than 10% of
-      system's memory, the "normal" pageout is used.
-    <slpz> I need to clean up things a little, but I want to send a preliminary
-      patch to bug-hurd ASAP, to have more people testing it.
-    <slpz> antrik: Do you thing that performance degradation can be related
-      with the number of threads of your ext2fs translators?
-    <antrik> slpz: hm... I didn't watch that recently; but in the past, I
-      observe that the thread count is pretty constant after it reaches
-      something like 14000 on heavy load...
-    <antrik> err... wait, 14000 was ports :-)
-    <antrik> I doubt my system would survive 14000 threads ;-)
-    <antrik> don't remember thread count... I guess I should start watching
-      this again
-    <slpz> antrik: I was thinking that 14000 threads sound like a lot :-)
-    <slpz> what I know for sure, is that when operating with large files, the
-      deactivation of all pages of the memory object which is done after every
-      operation really hurts to performance
-    <antrik> right now my root FS has 5100 ports and a mere 71 thread... but
-      then, it's almost freshly booted :-)
-    <slpz> that's why I've just commented that operation in my code, since it's
-      not really needed anymore :-)
-    <slpz> anyway, after submitting all my pending mails to bug-hurd, I'll try
-      to hunt that bug. Sounds funny.
-    <antrik> regarding your explanation, I'm still trying to wrap my head
-      around some of the details. I must admit that I don't remember what
-      data_unlock does... or maybe I never fully understood it
-    <antrik> the limit on dirty pages is global?
-    <slpz> yes, right now it's global
-    <marcusb> I try to find the old discussion of the thread storm stuff
-    <marcusb> there was some concern about deadlocks
-    <slpz> marcusb: yes, because we were talking about putting an static limit
-      for the server threads of a translators
-    <slpz> marcusb: and that was wrong (my fault, I was even dumber back then
-      :-P)
-    <marcusb> oh boy digging in old mail is no fun.  first I see mistakes in my
-      english.  then I see quite complicated pager stuff I don't ever remember
-      touching.  but there is a patch, and it has my name on it
-    <marcusb> I think I lost a couple of the early years of my hurd hacking :)
-    <antrik> hm... I reread the chapter on locking, and it's still above me :-(
-    <marcusb> not sure what you are talking about, but if there are any
-      specific questions...
-    <antrik> marcusb: external pager interface
-
-[[microkernel/mach/external_pager_mechanism]].
-
-    <marcusb> uuuuh ;)
-    <antrik> memory_object_lock_request(), memory_object_lock_completed(),
-      memory_object_data_unlock()
-    <marcusb> is that from the mach manual?
-    <antrik> yes
-    <antrik> I didn't really understand that part when I first read it a couple
-      of years ago, and I still don't understand it now :-(
-    <marcusb> I am sure I didn't understand it either
-    <marcusb> and maybe I missed my window :)
-    <marcusb> let's see
-    <antrik> hehe
-    <antrik> slpz: what exactly do you mean by "the pager which has generated
-      the page fault"?
-    <antrik> marcusb: essentially I'm trying to understand the explanation of
-      the changes slpz did, but there are several bits totally obscure to me
-      :-(
-    <slpz> antrik: when a I/O operation is requested to ext2fs, it maps the
-      object in question to it's own space, and then memcpy's from/to there
-    <slpz> antrik: so the translator (which is also a pager) is the one who
-      generates the page fault
-    <marcusb> yeah
-    <marcusb> antrik: it's important to understand which messages are sent by
-      the kernel to the manager and which are sent the other way
-    <marcusb> if the dest port is memory_object_t, that indicates a msg from
-      kernel to manager.  if it is memory_object_control_t, it's a msg from
-      manager to kernel
-    <slpz> antrik: m_o_lock_request it's used by the pager to "settle" the
-      status of a memory object, m_o_lock_completed is the answer from the
-      kernel when the lock has been completed (only if the client has requested
-      to be notified), and m_o_data_unlock is a request from the kernel to
-      change the level of protection for a page (it's called from vm_fault.c)
-    <marcusb> slpz: but it's not pagers generating page faults, but users of
-      the memory object on the other side
-    <antrik> marcusb: well, I think the direction is clear to me... but the
-      purpose not really :-)
-    <marcusb> ie a client that mapped a file
-    <slpz> antrik: in ext2fs, all pages are initially provided to the kernel
-      (via data_supply) write protected. When a write operation is done over
-      one of those pages, a page fault it's generated, which sends a
-      m_o_data_unlock to the pager, which answers (if convenient) which a
-      page_lock decreasing the protection level
-    <marcusb> antrik: one use of lock_request is when you want to shut down
-      cleanly and want to get the dirty pages written back to you from the
-      kernel.
-    <marcusb> antrik: the other thing may be COW strategies
-    <slpz> marcusb: well, pagers and clients are in the same task for most
-      translators, like ext2fs
-    <marcusb> slpz: oh.
-    <slpz> marcusb: but yes, a read operation in a mmap'ed file would trigger
-      the fault in a client user task
-    <marcusb> slpz: I think I forgot everything about pagers :)
-    <slpz> marcusb: pager-memcpy.c is the key :-)
-    <marcusb> slpz: what becomes of the fault then?  the kernel sees it's a
-      mapped memory object.  will it then talk to the manager or to a pager? 
-    <antrik> slpz: the translator causes the faults itself when it handles
-      io_read()/io_write() requests I suppose, as opposed to clients accessing
-      mmap()ed objects which then generate the faults?...
-    <antrik> ah, that's actually what you already said above :-)
-    <slpz> marcusb: I'm not sure what do you mean by "manager"...
-    <marcusb> manager == memory object
-    <marcusb> mh
-    <slpz> marcusb: for all external objects, it will ask to their current
-      pager
-    <marcusb> slpz: I think I am missing a couple of details, so nevermind.
-      It's starting to come back to me, but I am a bit afraid of that ;)
-    <marcusb> what I love about the Hurd is how damn readable the code is
-    <marcusb> considering it's an object system, it's so much nicer to read
-      than gtk stuff
-    <slpz> when you get the big picture, it's actually somewhat fun to see how
-      data moves around just to fulfill a simple read()
-    <marcusb> you should make a diagram!
-    <marcusb> bonus point for animated video ;)
-
-[[hurd/IO_path]].
-
-    <slpz> marcusb: heh, take a look at the hurd specific parts of glibc... I
-      cry in pain every time a do that...
-    <marcusb> slpz: oh yeah, rdwr-internal.
-    <marcusb> oh man
-    <marcusb> slpz: funny thing, I just looked at them the other day because of
-      the security issue
-    <slpz> marcusb: I think there was one, maybe a slice from someone's
-      presentation...
-    <marcusb> I think I was always confused about the pager/memobj/kernel
-      interactions
-    <slpz> marcusb: I'm barely able to read Roland's glibc code. I think it's
-      out of my reach.
-    <antrik> marcusb: I think part of the problem is confusing terminology
-    <marcusb> it's good that you are instrumenting the mach kernel to see
-      what's actually going on in there.  it was a black book for me, but neal
-      too a peek and got a much better understanding of the performance issues
-      than I ever did
-    <antrik> when talking about "pager", we usually mean the process doing the
-      paging; but in mach terminology this actually seems to be the "manager",
-      while a "pager" is an individual object in the manager process... or
-      something like that ;-)
-    <marcusb> antrik: I just never took a look at the big picture.  I look at
-      the parts
-    <marcusb> I knew the tail, ears, and legs of the elephant.
-    <marcusb> it's a lot of code for a beginner
-    <antrik> I never understood the distinction between "pager" and "memory
-      object" though...
-    <antrik> maybe "pager" refers to the object in the external pager, while
-      "memory object" is the part managed in Mach itself?...
-    <marcusb> memory object is a real object, to which you can send messages.
-      it's implemented in the server
-    <antrik> hm... maybe it's the other way around then ;-)
-    <marcusb> there is also the default pager
-    <marcusb> I think the pager is just another name for the process that
-      serves the memory object (default pager == memory object for anonymous
-      memory == swap)
-    <marcusb> but!
-    <marcusb> there is also libpager
-
-[[hurd/libpager]]
-
-    <marcusb> and that's a more complicated beast
-    <antrik> actually, the correct term seems to be "default memory manager"...
-    <marcusb> yeah
-    <marcusb> from mach's pov
-    <marcusb> we always called it default pager in the Hurd
-    <antrik> marcusb: problem is that "pager" is sometimes used in the Mach
-      documentation to refer to memory object ports IIRC
-    <marcusb> isn't it defpager executable?
-    <marcusb> could be
-    <marcusb> it's the same thing, really
-    <antrik> indeed, the program implementing the default memory manager is
-      called "default pager"... so the terminology is really inconsistent
-    <marcusb> the hurd's pager library is a high level abstraction for mach's
-      external memory object interface.
-    <marcusb> i wouldn't worry about it too much
-    <antrik> I never looked at libpager
-    <marcusb> you should!
-    <marcusb> it's an important beast
-    <antrik> never seemed relevant to anything I did so far...
-    <antrik> though maybe it would help understanding
-    <marcusb> it's related to what you are looking now :)
diff --git a/open_issues/resource_management_problems/zalloc_panics.mdwn b/open_issues/resource_management_problems/zalloc_panics.mdwn
deleted file mode 100644
index 9c29b07c..00000000
--- a/open_issues/resource_management_problems/zalloc_panics.mdwn
+++ /dev/null
@@ -1,99 +0,0 @@
-[[!meta copyright="Copyright © 2005, 2007, 2008, 2010, 2012 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_gnumach open_issue_hurd]]
-
-Written by antrik / Olaf Buddenhagen, last updated: 12 Apr 2007.
-
-The Hurd sometimes crashes with a kernel panic saying someting like: "Panic: zalloc failed: zone map exhausted".
-
-These panics are generally caused by some kind of kernel resource exhaustion, but there are several differnt reasons for that.
-
-It used to happen very often under heavy disk load (like large compile jobs), or in a reproducible test case by opening a large number of ports to /dev/null and then closing them all very quickly. The reason for this particular problem has been identified a while back: The multithreaded Hurd servers create a new worker thread whenever a new request (RPC) comes in while all existing threads are busy. When the server is hammered with lots of requests -- which happens both under heavy disk load, and when quickly closing many ports to one server -- it will create an absurd number of threads, causing the resource exhaustion.
-
-The Debian hurd package contains a patch by k0ro (Sergio Lopez), which fixes this by limiting the amount of created threads in a rather simplistic but very effective manner. This patch however hasn't been included in upstream CVS so far. A more elegant solution, suitable for upstream inclusion, would be desirable.
-
-Some panics still seem to happen in very specific situations, like the one described at <https://savannah.gnu.org/bugs/?19426> . These are probably the result of bugs that cause port leaks, accidental fork bombs, or similar problems.
-
-In principle, resource exhaustion can also happen by normal use, though this is rather unlikely in the absence of bugs or malicious programs. Nevertheless, all these problems could be avoided (or limited in effect) by introducing some limits on number of processes per user, number of threads and ports per process/user etc.
-
-Trying to track down causes for the panics, I got some interesting results. (UPDATE: Many of my original observations were clearly related to the server thread explosion problem. To avoid confusion, I now removed these, as this is no longer an open issue.)
-
-* It all started with someone (probably azeem) mentioning that builing some package always crashes Hurd at the same stage of the Debian packaging process (UPDATE: Almost all of these panics when building packages were a result of the thread explosion and don't happen anymore.)
-* Someone (maybe he himself) pointed out that this stage is characterized by many processes being quickly created and destroyed
-* Someone else (probably hde) started some experimenting, to get a reproducible test case
-* He realized that just starting and killing five child processes in quick succession suffices to kill some Hurd systems
-* I tried to confirm this, but it turned out my system is more robust
-
-As I could never reproduce the problem with a small number of quickly killed processes, I can't say whether this problem still exists. While I could reproduce such an effect with first opening and then very quickly closing many ports (which is more or less what happens when quickly killing many processes), I needed really large numbers of processes/ports for that. The thread throtteling patch fixed my test case; but it seems unlikely that killing only five processes could have caused a thread explosion, so maybe hde's observation was a different problem really...
-
-I started various other experiments with creating child processes (fork bombs), resulting in a number of interesting observations:
-
-* Just forking a large number of processes crashes the Hurd reliably (not surprising)
-* The number of processes at which the panic occurs is very constant (typicallly +-2) under stable conditions, as long as forking doesn't happen too fast
-* The exact number depends on various conditions:
-  * Run directly from the Mach console, it's around 1040 on my machine (given enough RAM); however, it drops to 940 when started through a raw ssh session, and to 990 when run under screen through ssh (TODO: check number of ports open per process depending on how it is started) UPDATE: In a later test, I got somewhat larger numbers (don't remember exactly, but well above 1000), but still very constant between successive runs. Not sure what effected this change.
-  * It doesn't depend on whether normal user or root
-  * With only 128 MiB of RAM, the numbers drop slightly (like 100 less or so); no further change between 256 and 384 MiB
-  * Lowering zone\_map\_size in mach/kern/zalloc.c reduces the numbers (quite exactly half from 8 MiB to 4 MiB)
-  * There seems to be some saturation near 16 MiB however: The difference between 8 MiB and 16 MiB is significantly smaller
-  * Also, with 8 MiB or 4 MiB, the difference between console/ssh/screen becomes much more apparent (500 vs. 800, 250 vs. 400)
-  * With more than 16 MiB, Mach doesn't even boot
-* Creating the processes very fast results in a sooner and less predictable crash (TODO: Check whether this is still the case with thread throtteling?)
-* Creating processes recursively (fork only one child which forks the next one etc.) results in faster crash
-* rpcinfo shows that child processes have more ports open by default, which is very likely the reason for the above observation
-* Opening many ports from a few processes doesn't usually cause a system crash; there are only lots of open() failures and translator faults once some limit is reached... Seems the zalloc-full condition is better caught on open() than on fork() (TODO: investigate this further, with different memory sizes, different zone\_map\_size, different kinds of resources using zalloc etc.)
-* After opening/leaking lots of ports to /dev/null (32768 it seems), the NULL translator somehow becomes disfunctional, and a new instance is started
-
-While most of these Observations clearly show an exhaustion of kernel memory which is not surprising, some of the oddities seem to indicate problems that might deserve further investigation.
-
-
-# IRC, freenode, #hurd, 2012-04-01
-
-    <mel__> antrik: i just found
-      http://www.gnu.org/software/hurd/open_issues/resource_management_problems/zalloc_panics.html
-      -- that is from 2007. is this still the current status?
-    <youpi> mel__: probably
-    <mcsim> mel__: gnumach has no more zalloc allocator, so I doubt if it could
-      be a problem.
-
-[[gnumach_memory_management]].
-
-    <youpi> mcsim: but it still has an allocator
-    <youpi> which can run out of resources
-    <mcsim> AFAIR, now there is no such limit.
-    <youpi> err, there is
-    <youpi> the size of your RAM :)
-    <mcsim> In zalloc appearing of this message didn't depend of available size
-      of free ram.
-    <youpi> then update the description, but I'm still getting allocation
-      errors, when userland makes crazy things like creating millions of tasks
-    <mcsim> At least it could appear when there still was free memory
-    <youpi> and that's not surprising
-    <youpi> sure, I know that *some* limits have been removed, but there
-      weren't so many, and I have seen cases where it's simply mach running out
-      of memory
-    <youpi> also, we have a limited amount of virtual addressing space
-    <antrik> mel__: this writeup is outdated in several regards. *some* of the
-      observations might still be relevant, but nothing that seems
-      particularily important
-    <antrik> the zalloc panics have pretty much disappeared after the default
-      zalloc zone size has been considerably extended (which was not possible
-      before because of some bug)
-    <mel__> i see
-    <antrik> but as mcsim pointed out, with the new allocator not relying on a
-      fixed-sized zalloc zone at all, they are even less likely, and should
-      happen only if all memory is exhausted
-    <antrik> I guess this outdated report can just be dropped
-    <mcsim> I think, that now it is problem rather of absence of OOM-killer or
-      resource manager
-    <antrik> mcsim: right :-)
-    <antrik> (and we have separate articles about that)
diff --git a/open_issues/rework_gnumach_ipc_spaces.mdwn b/open_issues/rework_gnumach_ipc_spaces.mdwn
deleted file mode 100644
index 20ae126d..00000000
--- a/open_issues/rework_gnumach_ipc_spaces.mdwn
+++ /dev/null
@@ -1,728 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2013 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_gnumach]]
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2011-05-07
-
-    <braunr> things that are referred to as "system calls" in glibc are
-      actually RPCs to the kernel or other tasks, those RPCs have too lookup
-      port rights
-    <braunr> the main services have tens of thousands of ports, looking up one
-      is slow
-
-There is a [[!FF_project 268]][[!tag bounty]] on this task.
-
-
-# IRC, freenode, #hurd, 2011-04-23
-
-    <braunr> youpi: is there any use of the port renaming facility ?
-    <youpi> I don't know
-    <braunr> at least, did you see such use ?
-    <braunr> i wonder why mach mach_port_insert_right() lets the caller specify
-      the port name
-    <youpi> ../hurd-debian/hurd/serverboot/default_pager.c:	kr =
-      mach_port_rename(	default_pager_self,
-    <braunr> mach_port_rename() is used only once, in the default pager
-    <braunr> so it's not that important
-    <braunr> but mach_port_insert_right() lets userspace task decide the port
-      name value
-    <youpi> just to repeat myself again, I don't know port stuff very much :)
-    <braunr> well you know that a port denotes a right, which denotes a port
-    <youpi> yes, but I don't have any real experience with it
-    <braunr> err
-    <braunr> port name
-    <braunr> the only reason I see is that the caller, say /hurd/exec running a
-      fork()
-    <braunr> hm
-    <braunr> no, i don't even see the reason here
-    <braunr> port names should be allocated by the kernel only, like file
-      descriptors
-    <youpi> you can choose file descriptor values too
-    <braunr> really ?
-    <youpi> with dup2, yes
-    <braunr> oh
-    <braunr> hm
-    <braunr> what's the data structure in current unices to store file
-      descriptors ?
-    <braunr> a hash table ?
-    <youpi> I don't know
-    <braunr> i'll have to look at that
-    <braunr> FYI, i'm asking these questions because i'm thinking of reworking
-      ipc spaces
-    <braunr> i believe the use of splay trees completely destroys performance
-      of tasks with many many port names such as the root file system
-    <youpi> that can be a problem yes
-    <youpi> since there are 3 ports per opened file, and like 3 per thread too
-    <braunr> + the page cache
-    <youpi> with a few thousand opened files and threads, that makes a lot
-    <youpi> by "opened file" I meant page cache actually
-    <braunr> i saw numbers up to 30k
-    <braunr> ok
-    <youpi> on buildds I easily see 100k ports
-    <braunr> for a single task ?
-    <braunr> wow
-    <youpi> yes
-    <youpi> the page cache is 4k files
-    <braunr> so that's definitely worth the try
-    <youpi> so that already makes 12k ports
-    <youpi> and 4k is not so big
-    <braunr> it's limited to 4K ?
-    <youpi> I haven't been able to check where the 100k come from yet
-    <youpi> braunr: yas
-    <braunr> could be leaks :/
-    <youpi> yes
-    <braunr> omg, a hard limit on the page cache ..
-    <youpi> vm/vm_object.c:int		vm_object_cached_max = 4000;	/* may
-      be patched*/
-    <braunr> mach is really old :(
-    <youpi> I've raised it
-    <youpi> before it was 200
-    <youpi> ...
-    <braunr> oO
-    <youpi> I tried to dro pthe limit, but then I was lacking memory
-    <youpi> which I believe have fixed the other day, but I have to test again
-    <braunr> that implementation doesn't know how to deal with memory pressure
-    <youpi> yes
-    <braunr> i saw your recent changes about adding warnings in such cases
-    <braunr> so, back to ipc spaces
-    <braunr> i think splay trees 1/ can get very unbalanced easily
-    <braunr> which isn't hard to imagine
-    <braunr> and 2/ make poor usage of the cpu caches because they're BST and
-      write a lot to memory
-    <youpi> maybe you could write a patch which would dump statistics on that?
-    <braunr> that's part of the job i'm assigning to myself
-    <youpi> ok
-    <braunr> i'd like to try replacing splay trees with radix trees
-    <youpi> I can run it on the buildds
-    <youpi> buildds are very good stress-tests :)
-    <braunr> :)
-    <youpi> 22h building -> 77k ports
-    <youpi> 26h building -> 97k ports
-    <youpi> the problem is that when I add leak debugging (backtraces), I'm
-      getting out of memory :)
-    <braunr> that will be a small summer of code outside the gsoc :p
-    <braunr> :/
-    <braunr> backtraces are very consuming
-    <youpi> but that's only because of hardcoded limits
-    <youpi> I'll have to test again with bigger limits
-    <braunr> again ..
-    <braunr> evil hard limits
-    <youpi> well, actually we could as well just drop them
-    <youpi> but we'd also need to easily get statistics on zone/vm_maps usage
-    <youpi> because else we don't see leaks
-    <youpi> (except that the machine eventually crashes)
-    <braunr> hm
-    <braunr> i haven't explained why i was asking my questions actually
-    <braunr> so, i want radix trees, because they're nice
-    <braunr> they reduce the paths lengths
-    <braunr> they don't get too unbalanced (they're invariant wrt the order of
-      operations)
-    <braunr> they don't need to write to memory on lookups
-    <braunr> the only drawback is that they can create much overhead if their
-      usage pattern isn't appropriate
-    <braunr> elements in such a structure should be close, so that they share
-      common nodes
-    <youpi> the common usage pattern in ext2fs is a big bunch of ever-open
-      ports :)
-    <braunr> if there is one entry per node, it's a big waste
-    <braunr> yes
-    <youpi> there are 3, actually
-    <braunr> but the port names have low values
-    <braunr> they're allocated sequentially, beginning at 0
-    <braunr> (or 1 actually)
-    <braunr> which is perfect for radix trees
-    <youpi> yes
-    <youpi>  97989: send
-    <braunr> but if anyone can rename
-    <braunr> this introduces a new potential weakness
-    <youpi> ah, if it's just a weakness it's probably not a problem
-    <youpi> I thought it was even a no-go
-    <braunr> i think so
-    <youpi> I guess port rename is very seldom
-    <braunr> but in a future version, it would be nice not to allow port
-      renaming
-    <braunr> unless there are similar issues in current unix kernels
-    <braunr> in which case i'd say it's acceptable
-    <youpi> there are
-    <braunr> of that order ?
-    <youpi> and it'd be useful for e.g. processing
-      tracing/debugging/tweaking/whatever
-    <youpi> it's also used to hide fds from a process
-    <braunr> port renaming you mean ?
-    <youpi> you allocate them very high
-    <youpi> yes
-    <braunr> ok
-    <youpi> choosing your port name, generally
-    <youpi> to match what the process expects for instance
-    <braunr> then it would be a matter of resource limiting (which we totally
-      lack afaik)
-    <braunr> along the number of maximum open files, you would have a number of
-      maximum rights
-    <braunr> does that seem fine to you ?
-    <youpi> if done throught rlimits, sure
-    <braunr> something similar yes
-    <youpi> (_no_ PORTS_MAX ;) )
-    <braunr> oh and, in addition, i remember gnumach has a special
-      configuration of the processor in which caching is limited
-    <braunr> like write-through only
-    <youpi> didn't I fix that recently ?
-    <braunr> i don't know :)
-    <braunr> CR0=e001003b
-    <braunr> i don't think it's fixed
-    <youpi> I mean, in the git
-    <braunr> ah
-    <youpi> not in the debian package
-    <braunr> didn't tried the git version yet
-    <braunr> last time i tried (which was a long time ago), it made the kernel
-      crash
-    <braunr> have you figured why ?
-    <youpi> I'm not aware of that
-    <braunr> anyway, splay trees write a lot, and most trees write a lot even
-      at insertion/removal to rebalance
-    <youpi> braunr: Mmm, there's no clearance of CD in the kernel actually
-    <braunr> with radix trees, even if caching can't be fully enabled, it would
-      make much better use of it
-    <braunr> so if port renaming isn't a true issue, i'll choose that data
-      structure
-    <youpi> that'd probably be better yes
-    <youpi> I'm surprised by the CD, I do remember fixing something like this
-      lately
-    <braunr> there are several levels where CD can be set
-    <braunr> the processors ORs all those if i'm right
-    <braunr> to determine if caching is enabled 
-    <youpi> I know
-    <braunr> ok
-    <youpi> but in my memory that was at the CR* level, precisely
-    <braunr> maybe for xen only ?
-    <youpi> no
-    <braunr> well good luck if you hunt that one, i'm off, see you :)
-    <youpi> braunr: ah, no, it was the PGE flag that I had fixed
-
-    <antrik> braunr: explicit port naming is used for example to pass some
-      initial ports to a new task at well-known places IIRC
-    <antrik> braunr: but these tend to be low numbers, so I don't see a problem
-      there
-    <antrik> (I'm not familiar with radix trees... why would high numbers be a
-      problem?)
-
-    <youpi> braunr: iirc the ipc space is limited to ~192k ports
-
-    <braunr> antrik: in most cases i've seen, the insert_right() call is used
-      on task_self()
-    <braunr> and if there really are special ports (like the bootstrap or
-      device ports), they should have special names
-    <braunr> IIRC, these ports are given through command line expansion by the
-      kernel at boot time
-    <braunr> but it seems reasonable to think of port renaming as a potentially
-      useful feature
-    <braunr> antrik: the problem with radix trees isn't them being high, it's
-      them being sparse
-    <braunr> you get the most efficient trees when entries have keys that are
-      close to each other
-    <braunr> because radix trees are a type of tries (the path in the tree is
-      based on the elements composing the key)
-    <braunr> so the more common prefixes you have, the less external nodes you
-      need
-    <braunr> here, keys are port names, but they can be memory addresses or
-      offsets in memory objects (like in the page cache)
-    <braunr> the radix algorithm takes a few bits, say 4 or 6, at a time from a
-      key, and uses that as an index in a node
-    <braunr> if keys are sparse, there can be as little as one entry per node
-    <braunr> IIRC, the worst case (on entry per node with the maximum possible
-      number of nodes for a 32-bits key) is 2% entries
-    <braunr> the reste being null entries and almost-empty nodes containing
-      them
-    <braunr> so if you leave the ability to give port rights the names you
-      want, you can create such worst case trees
-    <braunr> which may consume several MiB of memory per tree
-    <braunr> tens of MiB i'd say
-    <braunr> on the other hand, in the current state, almost all hurd
-      applications use sequentially allocated port names, close to 0 (which
-      allows a nice optimization)
-    <braunr> so a radix ree would be the most efficient
-    <antrik> well, if some processes really feel they must use random numbers
-      for port names, they *ought* to be penalized ;-)
-
-
-# IRC, freenode, #hurd, 2011-04-27
-
-    <braunr> antrik: remember when you asked why high numbers would be a
-      problem with radix trees ?
-    <braunr> here is a radix tree with one entry, which key is around 5000
-    <braunr> [  656.296412] tree height: 3
-    <braunr> [  656.296412] index:  0, level:  0, height:  3, count:  1,
-      bitmap: 0000000000000002
-    <braunr> [  656.296412] index:  1, level:  1, height:  2, count:  1,
-      bitmap: 0000000000004000
-    <braunr> [  656.296412] index: 14, level:  2, height:  1, count:  1,
-      bitmap: 0000000000000080
-    <braunr> three levels, each with an external node (dynamically allocated),
-      for one entry
-    <braunr> so in the worst case of entries with keys close to the highest
-      values, the could be many external nodes with higher paths lengths than
-      when keys are close to 0
-    <braunr> which also brings the problem of port name allocation
-    <braunr> can someone with access to a buildd which has an uptime of at
-      least a few days (and did at least one build) show me the output of
-      portinfo 3 | tail ?
-    <braunr> port names are allocated linearly IIRC, like PIDs, and some parts
-      of the kernel may rely on them not being reused often
-    <braunr> but for maximum effifiency, they should be
-    <braunr> efficiency*
-    <braunr> 00:00 < braunr> can someone with access to a buildd which has an
-      uptime of at least a few days (and did at least one build) show me the
-      output of portinfo 3 | tail ?
-    <braunr> :)
-    <youpi> it's almost like wc -l
-    <youpi>   4905: receive
-    <youpi> vs 4647
-    <youpi> for /
-    <youpi>  52902: receive
-    <youpi> vs 52207
-    <youpi> for the chroot
-    <braunr> even after several builds ?
-    <braunr> and several days ?
-    <youpi> that's after 2 days
-    <youpi> it's not so many builds
-    <youpi> rossini is not so old
-    <youpi> (7h)
-    <youpi> but many builds
-    <youpi> 70927: send
-    <youpi> vs 70938
-    <braunr> ok
-    <braunr> so it seems port names are reused
-    <braunr> good
-    <youpi> yes they are clearly
-    <braunr> i think i remember a comment about why the same port name
-      shouldn't be reused too soon
-    <youpi> well, it could help catching programming errors
-    <braunr> that it helped catch bugs in applications that could
-      deallocate/reallote quickly
-    <braunr> reallocate*
-    <braunr> without carefuly synchronization
-    <braunr> careful
-    <braunr> damn, i'm tired :/
-    <youpi> but that's about debugging
-    <youpi> so we don't care about performance there
-    <braunr> yes
-    <braunr> i'll try to improve allocation performance too
-    <braunr> using e.g. bitmaps in each external node back to the root so that
-      unused slots are quickly found
-    <braunr> i thknk that's what idr does in linux
-    <antrik> braunr: idr?
-    <braunr> antrik: a data structure used to map integers to pointers
-    <braunr> http://fxr.watson.org/fxr/source/lib/idr.c?v=linux-2.6
-
-
-# IRC, freenode, #hurd, 2011-06-08
-
-    <braunr> hm, reverse space/port to name lookups also suck
-    <braunr> having separate types for simple ipc entries and splay tree
-      entries really makes many parts of the ipc code complicated
-    <braunr> and a global hash table for these operations is scary
-
-
-# IRC, freenode, #hurd, 2011-06-09
-
-    <braunr> hm nice, my radix tree code runs inside gnumach, along with the
-      original splay tree code and assertions making sure results are the same
-    <braunr> there is this "collision" thing i'm not sure to understand but
-      once this is solved, replacing the splay trees should be easy
-
-    <braunr> youpi: is there a way to easily know the number of send rights
-      associated to a port ?
-    <youpi> portinfo ?
-    <braunr> portinfo gives information in a space
-    <braunr> but this is specific to a port
-    <braunr> is there an option for that ?
-    <youpi> -v
-    <braunr> hm ok
-    <youpi>     25: send (refs: 550)
-    <braunr> nice
-    <braunr> youpi: if you have time, could you give me the min/max/avg numbers
-      of send rights referring to the same port on buildds ?
-    <braunr> i'm trying to estimate if it's better to have space->list_of_ports
-      or port->list_of_spaces to replace the global ipc hash table
-    <braunr> the latter seems better but there could be unexpected cases on
-      machines using large amounts of resources like the buildds
-    <youpi> max is 64k
-    <youpi> min is 1 of course :)
-    <braunr> 64k
-    <braunr> then it's not what i'm looking for
-    <youpi> avg is 55
-    <braunr> isn't this the number of urefs ?
-    <youpi> I don't know
-    <braunr> hmm
-    <braunr> what i'm looking for is the number of *pure send rights* for the
-      same port
-    <braunr> i don't think portinfo can give it
-    <braunr> there can only be one such send right per task for the same port
-    <braunr> 64k would mean there are 64k tasks
-    <youpi> ok, so it's more difficult
-    <youpi> it means using -t
-    <braunr> ahh
-    <youpi> and run n^2 portinfo over the n processes
-    <braunr> i see
-    <youpi> Mmm, that will however still show any duplicate send right
-    <youpi> but then by min/max/avg, you mean, over time ?
-    <braunr> i'll change the source code, simpler
-    <youpi> e.g. min would be right after boot?
-    <braunr> min is 1
-    <youpi> 1 what ?
-    <braunr> 1 send right to a port
-    <youpi> ah, 1 for a given port
-    <braunr> yes
-    <youpi> ok, it becomes really hairy to compute, I don't hav ethe time :)
-    <braunr> avg and max are more interesting :)
-    <braunr> no worries
-    <youpi> braunr: I wouldn't be surprised that max is the number of tasks
-    <youpi> e.g. for a send port to the proc server for instance
-    <braunr> youpi: it is, but i'm not looking for potential numbers
-    <youpi> I'm not talking about a potential number, but an actual number
-      that's almost always true
-    <braunr> for one port, yes
-    <braunr> but yes, ok for max
-    <braunr> this makes choosing an appropriate data structure difficult
-
-    <antrik> braunr: actually, min number of send rights to a port is 0... but
-      I'm sure you know that already :-)
-
-    <antrik> youpi: normally each client gets a separate port. I'm not sure
-      there are any ports with send rights distributed over many tasks...
-
-    <jkoenig> antrik, what about / ?
-
-    <youpi> antrik: not necessarily
-
-    <antrik> jkoenig: not sure... isn't the "/" port authenticated to the
-      specific user?
-
-    <jkoenig> antrik, I guess so, but a single user could still have many
-      tasks.
-    <jkoenig> (wrt /)
-    <antrik> jkoenig: well, in theory the tasks having exactly the same UIDs
-      and GITs could probably share an auth token... but that's not how things
-      are handled in general
-    <antrik> at least I don't think so
-    <antrik> tasks are authenticated, not users
-    <antrik> err... GIDs :-)
-    <jkoenig> antrik, still, my quick glance to the fork() code seemed to
-      indicate the port is inherited as-is, maybe authentication happens only
-      when something is actually looked up?
-    <jkoenig> hmm "rpctrace ls -d /" does not show any authentication calls,
-      only a lookup("") on the root which returns a different port
-    <jkoenig> so I guess the root port is "deauthenticated" or something when
-      the uid of a process is changed.
-    <antrik> too bad cfhammer isn't around, he digged into all this stuff...
-    <antrik> I know that there is a mechanism which reauths all FDs when the
-      IDs of a process change
-    <antrik> but I'm not sure the "/" port uses this mechanism
-
-    <braunr> antrik: but the radix tree codee is really used as is, which means
-      no locking, no preloading before locking, all of this because simple
-      locks don't exist on UP, and because the kernel isn't preemptible
-
-[[microkernel/mach/gnumach/preemption]].
-
-    <braunr> antrik: and yes, min number is 0, but in that case you don't need
-      (space, port) -> right lookups :)
-    <braunr> antrik: or put in another way, whichever reasonable structure you
-      use, when it's empty, you don't care much
-    <braunr> which also means that the min number has actually no value here
-    <braunr> because the same applies to 1
-
-    <braunr> then what seems to take most time is forks
-    <braunr> and i hope my upcoming kernel changes will help the situation a
-      bit
-    <pinotree> what are your incoming gnumach changes about?
-    <braunr> the ipc translation layer speed
-    <braunr> which basically means operating on port names (looking them up,
-      inserting, removing, renaming, looking up send rights to a specific
-      ports) will be faster
-    <braunr> and i believe forks are (one of) the most demanding use cases wrt
-      ipc space manipulation
-    <braunr> i'm really surprised how badly the splay trees are used
-    <braunr> the worst case for this data structure is traversal
-    <braunr> and this is done in many situations
-    <braunr> leaving the tree in its worst case shape
-    <braunr> and i didn't mentioned the bunch of memory writes occurring, event
-      for things like lookups or traversals
-    <braunr> this is slow and can disrupt many cpu cache lines
-    <braunr> and when there are 10k to 100+k (e.g. in some ext2fs instances on
-      buildds), just imagine the number of operations involved in those
-      operations
-    <braunr> a simple traversal_next involves a rotation *gasp*
-    <braunr> this means potentially writing on 3 different cache lines, for
-      *one* next operation
-    <pinotree> what are you replacing that splay tree with?
-    <braunr> radix trees
-    <braunr> much shorter paths
-    <braunr> extremely few memory writes
-    <braunr> locality of reference when traversing
-    <braunr> good cache usage (as many of the top nodes are reused)
-    <braunr> the two drawbacks are 1/ memory allocation for external nodes,
-      which means the tree must be preloaded before locking
-    <braunr> and 2/ high memory overhead if the keys are sparse
-    <braunr> but this isn't the case with port names, unless someone messes it
-      up by assigning random names to many rights
-
-    <antrik> braunr: so, when will we see the first performance comparision?
-      :-)
-    <braunr> antrik: that's a topic of itself, how to compare ?
-    <braunr> antrik: the thing is, my current gnumach patches only makes
-      assertions
-    <braunr> this is the best way i found to test my tree in real life
-      conditions
-    <braunr> much cleanup is needed
-    <braunr> and what i'd like to do is to completely replace all teh
-      translation layer structures with it
-    <braunr> which means removing much code, making sure it still works as
-      expected
-    <braunr> this is tedious
-    <braunr> so one month at least
-    <antrik> braunr: comparing shouldn't be too hard... the average configure
-      script does a lot of forking, which should be a good benchmark according
-      to your observations
-    <braunr> rough estimates are easy, yes
-    <braunr> but my observations my be wrong :p
-    <antrik> braunr: well, we don't really need precise numbers...
-    <antrik> unless you need to do some kind of fine-tuning?
-    <braunr> i don't know yet
-
-
-# IRC, freenode, #hurd, 2011-06-18
-
-    < braunr> hmm, i'm having a problem with integrating my radix tree code in
-      gnumach
-    < braunr> inserting into such a tree can trigger memory allocation
-    < braunr> so commonly, the tree i loaded with nodes before insertion,
-      usually if it requires strong locking
-    < braunr> ipc spaces are locked using "simple locks" (which are spin locks)
-    < braunr> but spin locks are noops on UP, and gnumach is always UP ..
-    < braunr> so, should i still include preloading code, even if it'll end up
-      dead code ?
-    < antrik> hm... I think we discussed this before; but isn't gnumach
-      supposed to be SMP-capable, minus bugs?...
-    < braunr> it is
-    < braunr> but ofc, if i choose not to include preloading, i'll write
-      #errors so that the day gnumach is built for SMP again, such support will
-      be included
-    < antrik> oh, sorry, I think I misread. what is UP?
-    < braunr> uniprocessor
-    < antrik> well, if it's just bugs forcing the current UP state, I think
-      saying that gnumach is always UP is a stretch...
-    < braunr> sure, but it's a practical consideration
-    < antrik> does the locking complicate stuff? or is it just performance
-      considerations?
-    < braunr> no it's about correctness and completeness
-    < braunr> if you don't preload a tree before locking
-    < braunr> and memory allocation occurs while you're holding a simple lock
-    < braunr> and memory allocation requires the kernel to sleep
-    < braunr> you're screwed
-    < braunr> but i hate the idea of including code that won't be used and
-      which won't be easy to test
-    < braunr> so i'm wondering if it's ok for now to just put this in a TODO
-      comment and write it when the time is right
-    < braunr> or if i should spens the week adding this and tweaking the
-      userspace implementation to "emulate" spin locks
-    < antrik> well, it's tricky situation. on one hand, it seems stupid to
-      include handling for something that presently isn't used, and it's not
-      clear when it will. on the other hand, I'd rather not see additional
-      problems introduced that will make fixing SMP even harder...
-    < braunr> that's why i'm asking here
-    < antrik> of course, you could resolve this question by fixing SMP
-      first... ;-)
-    < braunr> ew
-    < antrik> well, I guess it would be best first to make the code work... and
-      we can still decide about the locking thing before it goes mainline I'd
-      say?
-    < braunr> "make the code work" ?
-    < antrik> I mean make gnumach work with your radix tree code
-    < braunr> without preloading then
-    < antrik> yeah... as a first step... I guess adding it later won't be any
-      harder than adding it right now?
-    < braunr> not much
-    < braunr> testing is what requires time really
-
-
-# IRC, freenode, #hurd, 2011-06-27
-
-    < braunr> ok, here is the radix tree code:
-      http://git.sceen.net/rbraun/libbraunr.git/
-    < braunr> the preloading stuff will be added in the kernel only, as it's
-      really pointless and not easily doable in userspace
-    < youpi> preloading?
-    < braunr> youpi: yes, preloading
-    < braunr> radix trees allocate external nodes
-    < youpi> well, providing a url at some random time of some random day is
-      not a great way  to get eyes on it :)
-    < braunr> and ipc spaces are locked when inserting/allocating names
-    < braunr> we normally don't need preloading in gnumach
-    < braunr> since there is no preemption nor SMP
-
-[[microkernel/mach/gnumach/preemption]].
-
-    < braunr> but in case someone changes that, i'd like the code to be mostly
-      ready
-    < braunr> and correctly handle those ugly simple locks
-    < braunr> youpi: is what i say clear enough or do you need more background
-      on what is done ?
-    < youpi> about preloading?
-    < braunr> yes
-    < youpi> I guess it means allocating nodes in advance?
-    < braunr> yes
-    < youpi> k
-    < braunr> before locking the ipc spaces
-
-
-# IRC, freenode, #hurd, 2011-06-28
-
-    < braunr> antrik: i think i won't write the code for the preloading stuff
-      actually
-    < braunr> antrik: it's not very difficult, but i really hate the idea of
-      not being able to reliably test it
-    < braunr> antrik: and i'd rather concentrate on integrating the radix tree
-      code in gnu mach now
-    < braunr> (i've already removed much code, even some files which weren't
-      actually used before my changes !)
-    < braunr> hmm, i won't be able not to write the preloading code after all
-    < antrik> braunr: not able not to write? how's that?
-    < braunr> antrik: it's actually required
-    < braunr> there are three functions, ipc_entry_get, ipc_entry_alloc, and
-      ipc_entry_grow_table
-    < braunr> ipc_entry_get cannot allocate memory
-    < braunr> if it fails, ipc_entry_grow_table is called, which will allocate
-      memory
-    < braunr> ipc_entry_alloc calls both of them depending on the result of
-      ipc_entry_get
-    < braunr> this is the equivalent of the preloading thing i had in mind
-    < braunr> not a bad thing after all
-    < braunr> the only thing i'm afraid of are the "optimized" version of those
-      ipc functions in te so-called fast paths
-    < braunr> i'm afraid if i don't deal right with those, the kernel may end
-      up using mostly slow paths
-    < braunr> but considering the purpose of those fast paths was merely to
-      avoid the overhead of function calls and some locking functions, it
-      shouldn't be that bad
-    < braunr> this is such a mess eh
-    < antrik> hurray microoptimisations ;-)
-    < braunr> there, the preload functions are done, easy :)
-    < antrik> braunr: seems you spent less time implementing it than pondering
-      whether you should implement it ;-)
-    < braunr> well, i couldn't implement it correctly before knowing what
-      should have been done exactly
-    < braunr> and there are still other problems :/
-    < braunr> and the other problems make me reconsider if this was useful at
-      all eh
-    < braunr> youpi: i'm unable to find where ipc tree entries are released
-      except in ipc_entry_alloc_name(), which could mean they're leaked ...
-    < braunr> youpi: would you have time to take a look ?
-    < youpi> they aren't in ipc_entry_dealloc() ?
-    < braunr> no .....
-    < youpi> it's not so unprobable that they're only freed when the task quits
-    < braunr> i don't see that either
-    < braunr> i only see them released in ipc_entry_alloc_name()
-    < braunr> so maybe they're reused
-    < braunr> but i'm not sure about that when reading the code
-    < braunr> oh wait, yes, they are :/
-    < braunr> my bad
-    < youpi> in the ipc_splay_tree_* fucntions I guess?
-    < braunr> yes
-    < braunr> it's just surprsing to see them allocated outside the tree code
-      only
-    < braunr> but released in both the entry and the splay tree code ...
-
-
-# IRC, freenode, #hurd, 2011-06-29
-
-    < braunr> hmm i missed an important thing :/
-    < braunr> and it's scary
-    < braunr> it looks like the splay tree is mainly used when names are
-      provided
-    < braunr> whereas the entry table is used when names are allocated
-    < braunr> which means the table is the main ipc data structure, even for
-      tasks with lots of rights
-    < braunr> i can make my root ext2fs have more than 10k rights, and i see
-      the ipc table table grow along that number ...
-    < braunr> now thetable has 15k+ entries
-    < braunr> IOW there is no point to put the radix tree code in gnumach :(
-    < antrik> braunr: what do you mean by "provided" and "allocated"?
-    < antrik> and what is that table you are talking about?
-    < braunr> antrik: provided means the user space tasks gives the name of the
-      new right
-    < braunr> antrik: allocated means the kernel generates it
-    < braunr> antrik: the table i'm talking about is is_table in struct
-      ipc_space
-    < braunr>  55  *      Every space has a non-NULL is_table with
-      is_table_size entries.
-    < braunr>  56  *      A space may have a NULL is_tree.  is_tree_small
-      records the
-    < braunr>  57  *      number of entries in the tree that, if the table were
-      to grow
-    < braunr>  58  *      to the next larger size, would move from the tree to
-      the table.
-    < braunr> here is the description which mislead me (in addition of the
-      obscure code)
-    < braunr>  50  *      Spaces hold capabilities for ipc_object_t's (ports
-      and port sets).
-    < braunr>  51  *      Each ipc_entry_t records a capability.  Most
-      capabilities have
-    < braunr>  52  *      small names, and the entries are elements of a table.
-    < braunr>  53  *      Capabilities can have large names, and a splay tree
-      holds
-    < braunr>  54  *      those entries.  The cutoff point between the table
-      and the tree
-    < braunr>  55  *      is adjusted dynamically to minimize memory
-      consumption.
-    < antrik> ah, so the rights with a low name are in a linear table, and only
-      those with "random" high names are stored in the splay tree instead?
-    < antrik> seems a rather complex design... I guess though there isn't much
-      room for further optimisation there :-(
-    < antrik> (well, except for code size optimisation -- which could in fact
-      make a considerable difference...)
-    < braunr> well there are problems with this approach, but most don't
-      concern performance
-    < braunr> when the table gets big (close to the page size or more), it gets
-      remapped when reallocated
-    < braunr> which will incur some penalty because of the tlb
-    < braunr> but it's annoying even for small tables
-    < braunr> the initial table size is 4 entries, and from what i can see,
-      most tables are 128 entries wide when tasks are destroyed
-    < braunr> an obvious simple optimization is to set a larger default size
-    < braunr> the same applies for the dead name tables
-    < braunr> those reallocations are a pain, and they're due to this design
-    < braunr> they can also fail because of fragmentation
-    < braunr> there would be a point to radix trees if they would replace all
-      that, and not just the splay tree
-    < braunr> but this would cause a lot of changes in a lot of places, and in
-      particular the "optimized" fast paths i mentioned yesterday
-    < braunr> we'll see how they perform in x15 :>
-    < braunr> there is a slight noticeable improvement when increasing the
-      initial size of the entry table
-    < antrik> braunr: well, if you use them in a completely different
-      implementation, there will be no way of telling whether they make a
-      difference
-    < antrik> how did you test the improvement?
-    < braunr> antrik: no actually it's completely negligeable
-    < braunr> hm
-    < braunr> is that a valid word ? :)
-    < braunr> negligible
-    < braunr> youpi: did you see my comments about the ipc stuff this earlier
-      today ?
-    < braunr> youpi: well to make things short, when port names are allocated,
-      the right they refer to is allocated from the ipc table
-    < braunr> youpi: the splay tree is only used for user provided names
-    < braunr> youpi: i had tables as large as the number of rights in a space
-      (i could easily reach 20k)
-    < braunr> youpi: whereas the splay trees had at most ~40 entries ..
diff --git a/open_issues/rm_fr.mdwn b/open_issues/rm_fr.mdwn
deleted file mode 100644
index aab52d97..00000000
--- a/open_issues/rm_fr.mdwn
+++ /dev/null
@@ -1,39 +0,0 @@
-[[!meta copyright="Copyright © 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_hurd]]
-
-From: Samuel Thibault <samuel.thibault@gnu.org>
-Subject: rm -fr slowness
-
-I have always been surprised by the slowness of a mere rm -fr. Looking a
-bit inside, I see that diskfs_dirremove_hard() calls diskfs_file_update
-(dp, 1) (as does diskfs_truncate, diskfs_direnter_hard, and
-diskfs_dirrewrite_hard). diskfs_file_update then calls pager_sync on
-the pager, which thus writes back the whole ext2fs pager!
-
-This sounds a bit excessive to me, an unlink could just record it in
-memory and actually sync later.  Also, the wait flag is set, so we
-really waits for all I/Os, which basically means strictly serializing
-file removals: remove one file, wait for the disk to have done it
-(~10ms), remove the next one, etc.  I guess this is for safety reasons
-against crashes, but isn't the sync option there for such kind of
-
-
-# IRC, freenode, #hurd, 2011-07-23
-
-    <antrik> youpi: hm... async deletion does have one downside: I just removed
-      something to make space, and retried the other command immediately
-      afterwards, and it still said "no space left on device"... a few seconds
-      later (after the next regular sync I suppose?) it worked
-    <youpi> well, that's sorta expected, yes
-    <youpi> we get the same on Linux
-    <youpi> Mmm, on second thought, I'm not sure how that can happen
-    <youpi> the asynchronous thing is for disk writes, not cache writes
diff --git a/open_issues/robustness.mdwn b/open_issues/robustness.mdwn
deleted file mode 100644
index 4b0cdc9b..00000000
--- a/open_issues/robustness.mdwn
+++ /dev/null
@@ -1,217 +0,0 @@
-[[!meta copyright="Copyright © 2011, 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_documentation open_issue_hurd]]
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2011-11-18
-
-    <nocturnal> I'm learning about GNU Hurd and was speculating with a friend
-      who is also a computer enthusiast. I would like to know if Hurds
-      microkernel can recover services should they crash? and if it can, does
-      that recovery code exist in multiple services or just one core kernel
-      service? 
-    <braunr> nocturnal: you should read about passive translators
-    <braunr> basically, there is no dedicated service to restore crashed
-      servers
-    <etenil> Hi everyone!
-    <braunr> services can crash and be restarted, but persistence support is
-      limited, and rather per serivce
-    <braunr> actually persistence is more a side effect than a designed thing
-    <braunr> etenil: hello
-    <etenil> braunr: translators can also be spawned on an ad-hoc basis, for
-      instance when accessing a particular file, no?
-    <braunr> that's what being passive, for a translator, means
-    <etenil> ah yeah I thought so :)
-
-
-# Reincarnation Server
-
-## IRC, freenode, #hurd, 2011-11-19
-
-    <chromaticwt> will hurd ever have the equivalent of a rs server?, is that
-      even possible with hurd?
-    <youpi> chromaticwt: what is an rs server ?
-    <chromaticwt> a reincarnation server
-    <youpi> ah, like minix. Well, the main ground issue is restoring existing
-      information, such as pids of processes, etc.
-    <youpi> I don't know how minix manages it
-    <antrik> chromaticwt: I have a vision of a session manager that could also
-      take care of reincarnation... but then, knowing myself, I'll probably
-      never imlement it
-    <youpi> we do get proc  crashes from times to times
-    <youpi> it'd be cool to see the system heal itself :)
-    <braunr> i need a better description of reincarnation
-    <braunr> i didn't think it would make core servers like proc able to get
-      resurrected in a safe way
-    <antrik> depends on how it is implemented
-    <antrik> I don't know much about Minix, but I suspect they can recover most
-      core servers
-    <antrik> essentially, the condition is to make all precious state be
-      constantly serialised, and held by some third party, so the reincarnated
-      server could restore it
-    <braunr> should it work across reboots ?
-    <antrik> I haven't thought about the details of implementing it for each
-      core server; but proc should be doable I guess... it's not necessary for
-      the system to operate, just for various UNIX mechanisms
-    <antrik> well, I'm not aware of the Minix implementation working across
-      reboots. the one I have in mind based on a generic session management
-      infrastructure should though :-)
-
-
-## IRC, freenode, #hurd, 2012-12-06
-
-    <Tekk_> out of curiosity, would it be possible to strap on a resurrection
-      server to hurd?
-    <Tekk_> in the future, that is
-    <braunr> sure
-    <Tekk_> cool :)
-    <braunr> but this requires things like persistence
-    <spiderweb> like a reincarnation server?
-    <braunr> it's a lot of works, with non negligible overhead
-    <Tekk_> spiderweb: yes, exactly. I didn't remember tanenbaum's wording on
-      that
-    <braunr> i'm pretty sure most people would be against that
-    <spiderweb> braunr: why so?
-    <Tekk_> it was actually the feature that convinced me that ukernels were a
-      good idea
-    <Tekk_> spiderweb: because then you need a process that keeps track of all
-      the other servers
-    <Tekk_> and they have to be replying to "useless" pings to see if they're
-      still alive
-    <braunr> spiderweb: the hurd community isn't looking for a system reliable
-      in critical environments
-    <braunr> just a general purpose system
-    <braunr> and persistence requires regular data saves
-    <braunr> it's expensive
-    <Tekk_> as well as that
-    <braunr> we already have performance problems because of the nature of the
-      system, adding more without really looking for the benefits is useless
-    <spiderweb> so you can't theoretically have both?
-    <braunr> persistence and performance ?
-    <braunr> it's hard
-    <Tekk_> spiderweb: you need to modify the other translators to be
-      persistent
-    <braunr> only the ones you care about actually
-    <braunr> but it's just better to make the critical servers very stable
-    <Tekk_> so it's not just turning on and off the reincarnation
-    <braunr> (there isn't that much code there)
-    <braunr> and the other servers restartable
-    <mcsim> braunr: I think that if there will be aim to make something like
-      resurrection server than it will be needed rewrite most servers to make
-      them stateless, isn't it?
-    <braunr> that's a lot easier and already works with non essential passive
-      translators
-    <Tekk_> mcsim: pretty much
-    <braunr> mcsim: only those you care about
-    <braunr> mcsim: the proc auth exec servers for example, perhaps the file
-      system servers that can act as root fs, but the others would simply be
-      restarted by the passive translator mechanism
-    <spiderweb> what about restarting device drivers, that would be simple
-      right?
-    <braunr> that's perfectly doable, yes
-    <spiderweb> (being an OS newbie) - it does seem to me that the whole
-      reincarnation server concept could quite possibly be a band aid.
-    <braunr> spiderweb: no it really works
-    <braunr> many systems do that actually
-    <braunr> let me give you a link
-    <braunr>
-      http://ftp.sceen.net/curios_improving_reliability_through_operating_system_structure.pdf
-    <braunr> it's a bit old, but there is a review of systems aiming at
-      resilience and how they achieve part of it
-    <spiderweb> neat, thanks
-    <braunr> actually it's not that old at all
-    <braunr> around 2007
-
-
-## IRC, freenode, #hurd, 2013-08-26
-
-    < teythoon> I came across some paper about process reincarnation and
-      created a little prototype a while back:
-    < teythoon> http://darnassus.sceen.net/gitweb/teythoon/reincarnation.git/
-    < teythoon> and I looked into restarting the exec server in case it
-      dies. the exec server is an easy target since it has no state of its own
-    < teythoon> the only problem is that there is no exec server around to
-      start a new one
-    < youpi> teythoon: there could be another exec server only used to
-      (re)start the exec server
-    < youpi> that other exec server could even be restarted by the normal exec
-      server
-    < pinotree> what about a watchdog server?
-    < teythoon> youpi: yes, I had the same idea, i actually patched /hurd/init
-      to do that, it's just not yet working
-    < pinotree> make it watch other servers (exec included), and make exec
-      watch the watchdog only
-    < teythoon> pinotree: look at my prototype, there is a watchdog server
-    < braunr> teythoon: what's the point of reincarnation without persistence ?
-    < teythoon> braunr: there is no point in reincarnation w/o persistence of
-      course
-    < teythoon> my prototype does a limited form of persistence
-    < teythoon> the point was to see whether I can mitm a translator and
-      restart it on demand and to gain more insight into the whole translator
-      mechanism
-    < braunr> teythoon: ok
-    < teythoon> braunr: see the readme, it retains state across reincarnations
-    < braunr> teythoon: how ?
-    < teythoon> braunr: the server can store a checkpoint using the
-      reincarnation_checkpoint procedure
-    < teythoon>
-      http://darnassus.sceen.net/gitweb/teythoon/reincarnation.git/blame/HEAD:/reincarnation.defshttp://darnassus.sceen.net/gitweb/teythoon/reincarnation.git/blame/HEAD:/reincarnation.defs
-    < teythoon> uh >,< sorry, pasted twice
-    < braunr> oh ok
-
-
-## IRC, freenode, #hurd, 2014-02-01
-
-    <pere> btw, can hurd upgrade the kernel without reboot?
-    <teythoon> no
-    <teythoon> but since most functionality is not within the kernel, the more
-      interesting question is, what parts of the hurd can be replaced at
-      runtime
-    <pere> ok.  what is the answer to that question?
-    <teythoon> no hurd server can be restarted transparently, i.e. w/o its
-      clients noticing that
-    <teythoon> however, if a server is not in use, it can be easily restarted
-    <teythoon> transparently restarting servers would be nice
-    <teythoon> and i believe it is even possible on mach
-    <braunr> teythoon: how ?
-    <teythoon> one has to retain two things, client-related state and the port
-      right
-    <braunr> doesn't that require persistence ?
-    <teythoon> it does
-    <teythoon> but i see no reason why it should not be possible to implement
-      this on top of mach
-    <braunr> maybe
-    <teythoon> the most crucial thing is to preserve the receive port, and to
-      replace the server without race-conditions
-    <teythoon> receive rights can be transfered using the notification
-      mechanism
-
-    <antrik> braunr: restarting servers doesn't exactly require
-      persistance. you only need to pass the state from the old server to the
-      new one, rather than serialising it for on-disk storage. it's a slightly
-      easier requirement...
-    <antrik> (most notably, you don't need any magic to keep the capabilities
-      around -- just pass them over using normal IPC)
-    <teythoon> antrik: i agree, but then again, once this is in place, adding
-      persistence is only a little step
-    <antrik> teythoon: depends. if it's implemented with persistence in mind
-      from the beginning, it might be a fairly small step indeed; but
-      otherwise, it could be two entirely different things
-    <antrik> this also depends on the kind of persistence you want
-    <antrik> I must say that for the kind of persistence *I* would like, it is
-      indeed quite related
-    <teythoon> well, please elaborate a little :)
-    <teythoon> what do you have in mind ?
-    <antrik> busy right now... remind me some other time if I forget :-)
-    <teythoon> sure
diff --git a/open_issues/rpc_stub_generator.mdwn b/open_issues/rpc_stub_generator.mdwn
deleted file mode 100644
index d4622d67..00000000
--- a/open_issues/rpc_stub_generator.mdwn
+++ /dev/null
@@ -1,146 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 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_mig]]
-
-
-# Originally in context of [[user/jkoenig/java]]
-
-  * [[tschwinge]] has to read about RMI and CORBA.
-
-  * MIG
-
-      * Hacking [[microkernel/mach/MIG]] shouldn't be too difficult.
-
-          * (Unless you want to make MIG's own code (that is, not the generated
-            code, but MIG itself) look a bit more nice, too.)  ;-)
-
-      * There are also alternatives to MIG.  If there is interest, the following
-        could be considered:
-
-          * FLICK ([[!GNU_Savannah_task 5723]]).  [[tschwinge]] has no idea yet if
-            there would be any benefits over MIG, like better modularity (for the
-            backends)?  If we feel like it, we could spend a little bit of time on
-            this.
-
-          * For [[microkernel/Viengoos]], Neal has written a RPC stub generator
-            entirely in C Preprocessor macros.  While this is obviously not
-            directly applicable, perhaps we can get some ideas from it.
-
-          * Anything else that would be worth having a look at?  (What are other
-            microkernels using?)
-
-
-# IRC, freenode, #hurd, 2012-12-27
-
-    <braunr> i'll soon have userspace on x15, and begin system calls, and of
-      course IPC
-    <braunr> and, since i personally have a strong disgust for IDLs, i was
-      thinking of manually writing the RPC "stubs", with helper functions and
-      macros
-    <braunr> what do you think of that ?
-    <pinotree> IDLs could have the advantage you can generate any kind of
-      language output out of them
-    <youpi> I'd not recommend that
-    <youpi> as ugly as IDLs are, they are useful
-    <pinotree> maybe pick something with proper per-arch types and
-      structs... :)
-    <braunr> youpi: what feature do you consider that important in an IDL ?
-    <braunr> i mean important enough to want to keep it
-    <youpi> argument matching between client and server code
-    <braunr> well obviously, but system wide protocols such as the hurd's tend
-      not to change much
-    <youpi> we've still seen bugs about that
-    <youpi> even without changing the protocol
-    <braunr> pinotree: i agree about the language thing, but wrapping libraries
-      also do
-    <braunr> what IDL would you then recommend ?
-    <pinotree> corba! :p
-    * pinotree runs
-    <braunr> well don't run
-    <braunr> it's actually at the top of my list :p
-    <braunr> the parser is free, and allows writing custom backends
-    <braunr> and there is already support for many languages
-    * pinotree some time ago fixed omniorb in debian
-    <pinotree> (to compile on hurd, i mean)
-    <braunr> i thought i could delay this problem some more but it's actually
-      coming quite fast :/
-    <braunr> i suppose it would make sense to use an already popular IDL so
-      that support for other languages is readily available
-    <pinotree> and/or people already know it
-    <braunr> hm that's secondary imo
-    <braunr> it's not that hard to learn an idl (providing it's simple,
-      i.e. not mig-like)
-    <braunr> hm how about google protocol buffers ?
-    <pinotree> wow, not bad at a first glance (never seen it)
-    <pinotree> structs, optional fields, builtin strings
-    <braunr> the nice thing about it is that it focuses on serialization most,
-      but has basic rpc support that allows using whatever communication
-      channel you want
-    <braunr> it may still be overkill for a microkernel based system
-    <pinotree> otoh rpc is everything in a microkernel-based os
-    <braunr> when i say overkill, i mean too slow
-    <pinotree> we still have 1024-sized string_t...
-    <braunr> yes, mig is totally hairy ...
-    <braunr> hum, c++ only, no c :/
-    <pinotree> there seems to be a C compiler, install protobuf-c-compiler
-    <braunr> v0.15, doesn't seem widely used
-    <pinotree> even on 0.14 (currently in debian)
-    <braunr> it also seems to rely on contiguous messages, whereas i want
-      scatter-gather to be used with x15
-    <braunr> once more, i fell back on omg idl
-    <braunr> oh, there is also flick that looks interesting
-
-
-# IRC, freenode, #hurd, 2013-13-16
-
-    <tschwinge> braunr: By the way, regarding your recent IDL considerations
-      (and I too suggest using some kind of RPC generator basone on whichever
-      IDL) -- are you aware that for Viengoos, Neal has written a RPC stub
-      generator entirely in C Preprocessor macros?  No idea whather that's
-      suitable for your case, but may be worth having a look at.
-    <neal> it probably isn't easy to port to Mach
-    <neal> genode has an ipc generator as well
-    <neal> which is written in a real langugage
-    <neal> that might be worth checking out as well
-    <neal> (note: I haven't followed the conversation at all.)
-    <braunr> i was considering using macros only too actually
-    <braunr> (i thought genode had switched to complex c++ templates)
-    <neal> dunno
-    <neal> I'm not up to date
-    <neal> macros are nice, but marshalling complicated data structures is hard
-    <sekon_> why implement it with just macros ??
-    <neal> no lexer, no parser
-    <neal> no special special tools
-    <neal> the first are a burden
-    <neal> the latter is a pain
-    <neal>
-      http://git.savannah.gnu.org/gitweb/?p=hurd/viengoos.git;a=blob;f=libviengoos/viengoos/rpc.h;h=721768358a0299637fb79f226aea6a304571da85;hb=refs/heads/viengoos-on-bare-metal
-    <neal> in the same directory, you there are headers that use it
-    <braunr> neal: cf. http://genode.org/documentation/release-notes/11.05
-    <braunr> tschwinge: why do you recommend an IDL ?
-    <neal> braunr: What about it?
-    <braunr> neal: it shows the difference between the earlier ipc/rpc
-      interface, and the new one based only on templates and dynamic
-      marshalling using c++ streams
-    <neal> ok
-    <tschwinge> braunr: In my book, the definition of RPC interfaces is just
-      "data" in the sense that it describes data structures (exchanged
-      messages) and as such should be expressed as data (by means of an IDL),
-      instead of directly codifying it in a specific programming language.
-    <tschwinge> Of course, there may be other reasons for doing the latter
-      anyway, such as performance/optimization reasons.
-    <braunr> tschwinge: well, from my pov, you're justifying the use of an idl
-      from the definition of an rpc
-    <braunr> i'm not sure it makes much sense for me
-    <braunr> in addition, the idl becomes the "specific programming language"
-    <tschwinge> Well, I see it as data that has to be translated into several
-      formats: different programming languages' stub code.
-    <braunr> you could consider c the "common" language :)
diff --git a/open_issues/rpc_to_self_with_rendez-vous_leading_to_duplicate_port_destroy.mdwn b/open_issues/rpc_to_self_with_rendez-vous_leading_to_duplicate_port_destroy.mdwn
deleted file mode 100644
index 9db92250..00000000
--- a/open_issues/rpc_to_self_with_rendez-vous_leading_to_duplicate_port_destroy.mdwn
+++ /dev/null
@@ -1,163 +0,0 @@
-[[!meta copyright="Copyright © 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_hurd]]
-
-[RPC to self with rendez-vous leading to duplicate port
-destroy](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00045.html)
-
-IRC, freenode, #hurd, 2011-03-14
-
-    <antrik> youpi: I wonder, why does the root FS call diskfs_S_dir_lookup()
-      at all?...
-    <youpi> errr, because a client asked for it?
-    <youpi> (problem with RPCs is you can't easily know where they come from :)
-      )
-    <youpi> (especially when it's the root fs...)
-    <antrik> ah, it's about a client request... didn't see that
-    <youpi> well, I just said "is called", yes
-    <antrik> I do not really understand though why it tries to reauthenticate
-      against itself...
-    <antrik> I fear my memory of the lookup mechanism grew a bit dim
-    <youpi> see the source
-    <youpi> it's about a translated entry
-    <antrik> (and I never fully understood some aspects anyways...)
-    <youpi> it needs to start the translated entry as another user, possibly
-    <antrik> yes, but a translated entry normally would be served by *another*
-      process?...
-    <youpi> sure, but ext2fs has to prepare it
-    <youpi> thus reauthenticate to prepare the correct set of rights
-    <antrik> prepare what?
-    <youpi> rights
-    <youpi> so the process is not root, doesn't have / opened as root, etc.
-    <antrik> rights for what?
-    <youpi> err, about everything
-    <antrik> IIRC the reauthentication is done by the parent FS on the port to
-      the *translated* node
-    <antrik> and the translated node should be a different process?...
-    <youpi> that's not what I read in the source
-    <youpi> fshelp_fetch_root
-    <youpi> ports[INIT_PORT_CRDIR] = reauth (getcrdir ());
-    <youpi> here, getcrdir() returns ext2fs itself
-    <antrik> well, perhaps the issue is that I have no idea what
-      fshelp_fetch_root() does, nor why it is called here...
-    <youpi> it notably starts the translator that dir_lookup is looking at, if
-      needed
-    <youpi> possibly as a different user, thus reauthentication of CRDIR
-    <antrik> so this is about a port that is passed to the translator being
-      started?
-    <youpi> no
-    <youpi> well, depends on what you mean by "port"
-    <youpi> it's about reauthenticating a port to be passed to the translator
-      being started
-    <youpi> and for that a rendez-vous port is needed for the reauthentication
-    <youpi> and that's the one at stake
-    <antrik> yeah, I meant the port that is reauthenticated
-    <antrik> what is CRDIR?
-    <youpi> current root dir ...
-    <antrik> so the parent translator passes it's own root dir to the child
-      translator; and the issue is that for the root FS the root dir points to
-      the root FS itself...
-    <youpi> yes
-    <antrik> OK, that makes sense
-    <youpi> (but that's only one example, rgrep mach_port_destroy hurd/ show
-      other potential issues)
-    <antrik> well, that's actually what I wanted to mention next... why is the
-      rendez-vous port destroyed, instead of just deallocating the port right
-      and letting reference counting to it's thing?...
-    <antrik> do its thing
-    <youpi> "just to make sure" I guess
-    <antrik> it's pretty obvious that this will cause trouble for any RPC
-      referencing itself...
-    <youpi> well, follow-up with that on the list
-    <youpi> with roland/tb in CC
-    <youpi> only they would know any real reason for destroy
-    <youpi> btw, if you knew how we could make _hurd_select()'s raw __mach_msg
-      call be interruptible by signals, that'll permit to fix sudo
-    <youpi> (damn, I need sleep, my tenses are all wrong)
-    <antrik> BTW, does this cause any actual trouble?...
-    <antrik> I don't know much about interruption... cfhammer might have a
-      better idea, he look into that stuff quite a bit AIUI
-    <antrik> looked
-    <antrik> (hehe, it's not only your tenses... guess there's something in the
-      ether ;-) )
-    <youpi> it makes sudo, mailq, etc. fail sometimes
-    <antrik> I mean the rendez-vous thing
-    <youpi> that's it, yes 
-    <youpi> sudo etc. fail at least due to this
-    <antrik> so these are two different problems that both affect sudo?
-    <antrik> (rendez-vous and interruption I mean)
-    <youpi> yes
-    <youpi> with my patch the buildds have much fewer issues, but still some
-    <youpi> (my interrupt-related patch)
-    <youpi> I'm installing a s/destroy/deallocate/ version of ext2fs on the
-      buildds, we'll see how it behaves
-    <youpi> (it fixes my testcase at least)
-    <antrik> interrupt-related patch?
-    <antrik> only thing interrupt-related I remember was the reauthentication
-      race...
-    <youpi> that's what I mean
-    <antrik> well, cfhammer investigated this is quite some depth, explaining
-      quite well why the race is only mitigated but still exists... problem is
-      that we didn't know how to fix it properly
-    <antrik> because nobody seems to understand the cancellation code, except
-      perhaps for Roland and Thomas
-    <antrik> (and I'm not even entirely sure about them :-) )
-    <antrik> I think his findings and our conclusions are documented on the
-      ML...
-    <youpi> by "much fewer issues", I mean that some of the symptoms have
-      disappeared, others haven't
-    <antrik> BTW, couldn't the rendez-vous thing be worked around by simply
-      ignoring the errors from the failing deallocate?...
-    <youpi> no, failing deallocate are actually dangerous
-    <antrik> why?
-    <youpi> since the name might have been reused for something else in the
-      meanwhile
-    <youpi> that's the whole point of the warning I had added in the kernel
-      itself
-    <antrik> I see
-    <youpi> such things really deserve tracking, since they can have any kind
-      of consequence
-    <antrik> does Mach try to reuse names quickly, rather than only after
-      wrapping around?...
-    <youpi> it seems to
-    <antrik> OK, then this is a serious problem indeed
-    <youpi> (note: I rarely divine issues when there aren't actual frequent
-      symptoms :) )
-    <antrik> well, the problem with the warning is that it only shows in the
-      cases that do *not* cause a problem... so it's hard to associate them
-      with any specific issues
-    <youpi> well, most of the time the port is not reused quickly enough
-    <youpi> so in most case it shows up more often than causing problem
-
-IRC, freenode, #hurd, 2011-03-14
-
-    <youpi> ok, mach_port_deallocate actually can't be used
-    <youpi> since mach_reply_port() returns a receive right, not a send right
-    * youpi guesses he will really have to manage to understand all that port
-        stuff completely
-    <antrik> oh, right
-    <antrik> youpi: hm... now I'm confused though. if one client holds a
-      receive right, the other client (or in this case the same process) should
-      have a send or send-once right -- these should *not* share the same name
-      in my understanding
-    <antrik> destroying the receive right should turn the send right into a
-      dead name
-    <antrik> so unless I'm missing something, the destroy shouldn't be a
-      problem, and there must be something else going wrong
-    <antrik> hm... actually I'm probably wrong
-    <antrik> yeah, definitely wrong. receive rights and "ordinary" send rights
-      share the name. only send-once rights are special
-    <antrik> I wonder whether the problem could be worked around by using a
-      send-once right...
-    <antrik> mach_port_mod_refs(mach_task_self(), name,
-      MACH_PORT_RIGHT_RECEIVE, -1) can be used to deallocate only the receive
-      right
-    <antrik> oh, you already figured that out :-)
diff --git a/open_issues/runit.mdwn b/open_issues/runit.mdwn
deleted file mode 100644
index 659b81ea..00000000
--- a/open_issues/runit.mdwn
+++ /dev/null
@@ -1,50 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2009, 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_porting]]
-
-The `runit` package doesn't work, even its test suite doesn't finish.
-
-[[Thomas_Schwinge|tschwinge]] once was having a look at that, but this very
-report is just from his memory, and his memory is dim...  The problem *might*
-either be a time stamping issue (which might be fixed by now) or it *might* be
-the `select` call failing issue we're seeing from time to time.  Or something
-else.
-
-[[Harish Badrinath|harishbadrinath]]
-Originally answered by Samuel Thibault:
->  120->proc_dostop_request ( 138) = 0
->
-> </snip>
-
-Usual issue with rpctrace: it does not support fork().
-
-    I've checked a backtrace in gdb, got this:
-    
-     0x0105af6c in mach_msg_trap ()
-       at /build/eglibc-jWVnRE/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    1  0x0105b769 in __mach_msg (msg=0x1024af8, option=258, send_size=0, rcv_size=40, rcv_name=140,
-       timeout=1000020, notify=0) at msg.c:110
-    2  0x01062251 in _hurd_select (nfds=2, pollfds=0x1024dc0, readfds=0x0, writefds=0x0, exceptfds=0x0,
-       timeout=0x1024bbc, sigmask=0x0) at hurdselect.c:324
-    3  0x0114427b in __poll (fds=0x1024dc0, nfds=2, timeout=1000020) at ../sysdeps/mach/hurd/poll.c:48
-    4  0x0804b770 in iopause (x=0x1024dc0, len=2, deadline=0x1024dd8, stamp=0x1024de8) at iopause.c:29
-    5  0x08048efc in main (argc=2, argv=0x1024e94) at runsv.c:543
-    
-    and main() shows up as:
-    
-       sig_unblock(sig_term);
-       sig_unblock(sig_child);
-     ->  iopause(x, 2 +haslog, &deadline, &now);
-       sig_block(sig_term);
-       sig_block(sig_child);
-
-So it simply looks like the known "signals don't interrupt select" bug.
diff --git a/open_issues/sa_siginfo_sa_sigaction.mdwn b/open_issues/sa_siginfo_sa_sigaction.mdwn
deleted file mode 100644
index 4e1fa849..00000000
--- a/open_issues/sa_siginfo_sa_sigaction.mdwn
+++ /dev/null
@@ -1,96 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012 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]]."]]"""]]
-
-[[!meta title="SA_SIGINFO, SA_SIGACTION"]]
-
-[[!tag open_issue_glibc]]
-
-Note: SA_SIGINFO has now been implemented by Jérémie Koenig.  It will be
-uploaded in Debian eglibc 2.13-19.
-
-IRC, #hurd, August / September 2010:
-
-    <giselher> Hy, I came across SA_SIGINFO in cherokee, I have the void sighandler(int num) prototype but how do I add the sa_handler field?
-    <pinotree> if SA_SIGACTION is not defined, then you use sa_handler instead of sa_sigaction, and not add SA_SIGINFO in the sa_flags
-    <giselher> SA_SIGINFO is not defined
-    <pinotree> s/SA_SIGACTION/SA_SIGINFO/ above, yes
-    <giselher> K
-    <giselher> I am not sure if I fully understand this, there is the  line "act.sa_flags = SA_SIGINFO" and how do I have to change that >_>
-    <pinotree> can you paste the source in a pastebin?
-    <giselher> k
-    <giselher> http://archhurd.pastebin.com/N8BCnG6g at line 790
-    <pinotree> something along the lines of http://www.archhurd.pastebin.com/tdpcFD5G
-    <pinotree> note that in the handler the siginfo_t parameter is used, which cannot be done if SA_SIGINFO is not defined
-    <pinotree> (that code still won't compile, yet)
-    <giselher> btw: is there a reason why SA_SIGINFO is not implemented?
-    <giselher> the guildlines only say "It's not implemented"
-    <azeem> 09:43 < azeem> signal stuff is tricky :-/
-    <azeem> basically it was pending on a complete rewrite by Roland, which never occured
-    <youpi> I have an almost complete implementation, just not finished yet
-    <youpi> (only the siginfo part)
-    <azeem> nobody really groked that code for years until youpi showed up, but he added partial support AFAIK, not having much time on his hand
-    <azeem> ah, he's here
-    <azeem> :)
-    <giselher> oh, should I just wait ?
-    <youpi> no
-    <giselher> k
-    <youpi> there are OSes which don't have SA_SIGINFO
-    <youpi> just cope with them: use sa_handler instead of sa_sigaction, and don't set SA_SIGINFO
-    <youpi> (i.e. replace with 0 in your example)
-    <giselher> ok
-    <youpi> when SA_SIGINFO becomes available, it'll just be used
-
-IRC, freenode, #hurd, 2011-08-20:
-
-    < youpi> erf, tcpwrappers will need si_pid
-    < jkoenig> I could implement it not too far away in the future, we just
-      need a version of msg_sig_post() with a siginfo argument or something.
-    < youpi> I can also see a lot of packages using SA_SIGINFO for no reason...
-    < youpi> (probably copy/pasty code)
-    < youpi>   sa.sa_flags = SA_SIGINFO;
-    < youpi>   sa.sa_handler = parse_config;
-    < youpi> void parse_config(int)
-    < youpi> yay
-    < youpi>     if(siginf->si_signo == SIGXCPU)
-    < youpi>       fprintf(stderr, "Exceeded CPU usage.\n");
-    < youpi> ...
-    < youpi> jkoenig: actually most package don't actually use the SA_SIGINFO
-      they request...
-    < youpi> jkoenig: si_pid should get us almost all actually used coverage
-    < youpi> I've seen only one example using si_errno
-    < jkoenig> ok
-    < youpi> oh, it's actually supported by your patch
-    < youpi> (errno)
-    < jkoenig> but I guess since implementing si_pid will require a new RPC, we
-      might as well plan for the rest
-    < youpi> jkoenig: indeed
-    < jkoenig> youpi, hmm I doubt it's properly filled in in all circumstances?
-    < youpi> ok, well, we'll see
-    < pinotree> jkoenig: if it can be of help, boost::unit_test queries various
-      fields of siginfo_t depending on the signal
-    < pinotree> jkoenig: also, pulseaudio uses siginfo_t for remapping faulting
-      memory on SIGBUS
-    < jkoenig> pinotree, oh ok good to know
-    < pinotree> *faulty
-    < youpi> jkoenig: well, I guess you had checked that the si_addr field is
-      correct in a few simple testcase :)
-    < jkoenig> hmm I think so, yes
-    < jkoenig> I ran like, "* (char *) 0x12345678;" or something IIRC
-    < youpi> ok
-    < jkoenig> I seem to remember mach generated SIGBUS instead of SIGSEGV
-      depending on the upper bit, or something (I can't quite remember)
-    < jkoenig> but when sigsegv was generated si_addr was right.
-    < pinotree> jkoenig: (see boost/test/impl/execution_monitor.ipp in boost
-      sources)
-    < pinotree> maybe you can try the unit tests for boost::unit_tests, if any
-      :)
-    < pinotree> (while src/pulsecore/memtrap.c in PA)
-     * pinotree stops doing MrObvious™
diff --git a/open_issues/sbcl.mdwn b/open_issues/sbcl.mdwn
deleted file mode 100644
index 4bbf92ef..00000000
--- a/open_issues/sbcl.mdwn
+++ /dev/null
@@ -1,31 +0,0 @@
-[[!meta copyright="Copyright © 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_porting]]
-
-IRC, freenode, #hurd, 2011-08-12
-
-    < zyg> did the segment registers had any purpose? I see fs is set equal to
-      others, but on linux fs is 0 (atleast on this x86 box).
-    < braunr> zyg: it can be used by special applications like wine, yes
-    < zyg> braunr: thanks.. I'm reading up on linux actually. It seems gs can
-      be used for TLS, fs in syscall to pass userspace.
-    < braunr> zyg: why are you interested in that ?
-    < zyg> a native compiler under linux places assumptions on fs register. So
-      I'm trying to find out what it should do under gnumach/hurd.
-    < braunr> what compiler ?
-    < zyg> braunr: it's sbcl
-    < braunr> ok
-    < youpi> zyg: the same, basically
-    < zyg> ok.. looking at the code, I've remarked where it sets up FS, because
-      /usr/include/asm/ldt.h:struct user_desc is missing. I must search for the
-      equiv.
-    < youpi> zyg: mach/i386/mach_i386.h
-    < youpi> the descriptor structure
diff --git a/open_issues/screen.mdwn b/open_issues/screen.mdwn
deleted file mode 100644
index e0394f0d..00000000
--- a/open_issues/screen.mdwn
+++ /dev/null
@@ -1,120 +0,0 @@
-[[!meta copyright="Copyright © 2009, 2010 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_porting]]
-
-Typing `C-c` (*SIGINT*) in a *screen* session (Debian package 4.0.3-14; -11 is
-fine):
-
-  * shell prompt: no reaction (nothing printed)
-  * `sleep 10` running: `^C` printed, but SIGINT is not sent.
-    
-[[!debbug 522689#38]].
-
----
-
-Revisit this issue: [[!debbug 97343]] -- special handling of `TIOCSCTTY`
-depending on `__GNU__`.
-
----
-
-`#ifdef linux` and friends are used in quite a number of places.
-
----
-
-All diffs are GNU/Linux vs. GNU/Hurd.
-
-     /*
-      * If your system supports BSD4.4's seteuid() and setegid(), define
-      * HAVE_SETEUID.
-      */
-    -/* #undef HAVE_SETEUID */
-    +#define HAVE_SETEUID 1
-
-TODO: check.
-
----
-
-     /*
-      * define HAVE_SVR4_PTYS if you have a /dev/ptmx character special
-      * device and support the ptsname(), grantpt(), unlockpt() functions.
-      */
-    -#define HAVE_SVR4_PTYS 1
-    +/* #undef HAVE_SVR4_PTYS */
-     
-     /*
-      * define HAVE_GETPT if you have the getpt() function.
-      */
-     #define HAVE_GETPT 1
-     
-     /*
-      * define HAVE_OPENPTY if your system has the openpty() call.
-      */
-    -/* #undef HAVE_OPENPTY */
-    +#define HAVE_OPENPTY 1
-     
-     /* 
-      * define PTYRANGE0 and or PTYRANGE1 if you want to adapt screen
-      * to unusual environments. E.g. For SunOs the defaults are "qpr" and 
-      * "0123456789abcdef". For SunOs 4.1.2 
-      * #define PTYRANGE0 "pqrstuvwxyzPQRST" 
-      * is recommended by Dan Jacobson.
-      */
-    -/* #undef PTYRANGE0 */
-    -/* #undef PTYRANGE1 */
-    +#define PTYRANGE0 "pq"
-    +#define PTYRANGE1 "0123456789abcdefghijklmnopqrstuv"
-
-TODO: check: `HAVE_SVR4_PTYS` is due to `configure.in` doing `test -c
-/dev/ptmx`.  But: even if we don't have that file, we still have `ptsname`,
-`grantpt`, `unlockpt`.
-
----
-
-     gcc -c -I. -I.    -g -O2 -O2 -g -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers pty.c
-    +pty.c: In function 'OpenPTY':
-    +pty.c:323: warning: implicit declaration of function 'openpty'
-    +pty.c: At top level:
-    +pty.c:75: warning: 'PtyName' defined but not used
-    +pty.c:86: warning: 'PtyProto' defined but not used
-    +pty.c:87: warning: 'TtyProto' defined but not used
-
-TODO: check.
-
----
-
-    --- linux/osdef.h       2009-10-06 18:43:53.000000000 +0200
-    +++ screen-4.0.3/osdef.h        2009-10-06 18:49:49.000000000 +0200
-    @@ -42,13 +42,19 @@
-     #endif
-     
-     #ifdef SYSV
-    +extern char *strchr __P((char *, int));
-    +extern char *strrchr __P((char *, int));
-    +extern char *memset __P((char *, int, int));
-    +extern int   memcmp __P((char *, char *, int));
-     #else
-     #endif
-     
-     #ifndef USEBCOPY
-     # ifdef USEMEMCPY
-    +extern void  memcpy __P((char *, char *, int));
-     # else
-     #  ifdef USEMEMMOVE
-    +extern void  memmove __P((char *, char *, int));
-     #  else
-     #  endif
-     # endif
-
-TODO: check.
-
----
-
-  * [[screen_dead_session]]
diff --git a/open_issues/screen_dead_session.mdwn b/open_issues/screen_dead_session.mdwn
deleted file mode 100644
index fe51523b..00000000
--- a/open_issues/screen_dead_session.mdwn
+++ /dev/null
@@ -1,69 +0,0 @@
-[[!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_porting]]
-
-Comparing to GNU/Linux, on GNU/Hurd it happens much more often and easily for
-*screen* sessions to become *dead*.  This is annoying, as it defeats one of
-*screen*'s main purposes.
-
-[[!toc]]
-
-
-# One reproducible scenario goes like this
-
-  * `ssh [somewhere]`,
-
-  * start a *screen* session, and some long-running process *P* in there,
-
-  * at some point the link is forcefully terminated (also known as disconnect
-    after 24 hours with consumer DSL),
-
-  * *P* will continue to execute,
-
-  * at some point, *P* will terminate / hang (after having received some kind
-    of signal?), and the *screen* session will be reported as *dead*.
-
-
-# Another one, not as often reproduced
-
-  * `ssh [somewhere]`,
-
-  * start a *screen* session, and some long-running process *P* in there,
-
-  * at some point the link is forcefully terminated (also known as disconnect
-    after 24 hours with consumer DSL),
-
-  * `ssh [somewhere]`,
-
-  * `screen -x`, and notice that *P* will *immediatelly* terminate / hang
-    (after having received some kind of signal?), and the *screen* session will
-    *immediatelly* be reported as *dead*.  (Perhaps the other way round: upon
-    re-attaching, the *screen* session goes bonkers and takes *P* with it?)
-
-
-# IRC, freenode, #hurd, 2011-10-19
-
-    <antrik> tschwinge: hm... haven't seen screen dying in a long time
-    <tschwinge> antrik: It's easy, and goes like this: have a session on one
-      system, log in from another, do screen -x and wait some time.
-    <antrik> I do this regularily. haven't had a crash in ages.
-    <antrik> (BTW, I'm not sure I ever had a crash on srceen -x... at that
-      time, I wasn't using -x. I often had crashes with screen -r. my
-      impression back then was that it works better when doing -rd -- in fact,
-      I always do that now, so I can't say whether crashes still happen with
-      only -r...)
-
-2011-10-26:
-
-    <antrik> so I was saying the other day that I haven't had a screen crash in
-      a long time... well, here it was :-(
-    <antrik> this time it didn't crash on reconnect though, but already
-      before. probably when I killed the hanging ssh connection
diff --git a/open_issues/secure_file_descriptor_handling.mdwn b/open_issues/secure_file_descriptor_handling.mdwn
deleted file mode 100644
index 16c8c85c..00000000
--- a/open_issues/secure_file_descriptor_handling.mdwn
+++ /dev/null
@@ -1,28 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 2013 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]]
-
-`O_CLOEXEC`, `dup3` et al.; see
-<http://udrepper.livejournal.com/20407.html>.  [[tschwinge]] once worked
-on this, posted patches to [[mailing_lists/libc-alpha]].  This works needs to
-be resumed
-and finished.
-
-Add tests from Linux kernel commit messages for `t/dup3` et al.
-
-Validate completeness according to <https://wiki.freebsd.org/AtomicCloseOnExec>
-or a similar list.
-
-In <http://lwn.net/Articles/417421/> an interesting point is made: *you [may]
-want some [[unix/file_descriptor]] to still be open if 'exec' fails, but you
-don't want it to be open after the exec succeeds*.  [[I|tschwinge]]'m not sure
-whether our current `O_CLOEXEC` implementation adheres to that.
diff --git a/open_issues/security.mdwn b/open_issues/security.mdwn
deleted file mode 100644
index d8ffc04e..00000000
--- a/open_issues/security.mdwn
+++ /dev/null
@@ -1,28 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2013 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]]."]]"""]]
-
-There are [[several aspects to security|/security]] that are (mainly) relevant
-to the design space.
-
-There are also security issues in the implemenation space, for example using
-the correct coding paradigms.
-
-Large parts of our code base have not beed audited, either manually or in an
-automated fashion.
-
-[[Unit testing]] is one aspect: testing for reliably failing for invalid input.
-
-[[Code analysis]] is another aspect.
-
-All publically usable interfaces provide attacking targets.  This includes all
-[[system call]]s and [[RPC]] interfaces.
-
-Fuzzing techniques can be use for locating possible issues; see discussion on
-the [[code_analysis]] page.
diff --git a/open_issues/select.mdwn b/open_issues/select.mdwn
deleted file mode 100644
index caecc437..00000000
--- a/open_issues/select.mdwn
+++ /dev/null
@@ -1,2440 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 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]]
-
-There are a lot of reports about this issue, but no thorough analysis.
-
-
-# Short Timeouts
-
-## `elinks`
-
-IRC, unknown channel, unknown date:
-
-    <paakku> This is related to ELinks... I've looked at the select()
-      implementation for the Hurd in glibc and it seems that giving it a short
-      timeout could cause it not to report that file descriptors are ready.
-    <paakku> It sends a request to the Mach port of each file descriptor and
-      then waits for responses from the servers.
-    <paakku> Even if the file descriptors have data for reading or are ready
-      for writing, the server processes might not respond immediately.
-    <paakku> So if I want ELinks to check which file descriptors are ready, how
-      long should the timeout be in order to ensure that all servers can
-      respond in time?
-    <paakku> Or do I just imagine this problem?
-
-
-## [[dbus]]
-
-
-## IRC
-
-### IRC, freenode, #hurd, 2012-01-31
-
-    <braunr> don't you find vim extremely slow lately ?
-    <braunr> (and not because of cpu usage but rather unnecessary sleeps)
-    <jkoenig> yes.
-    <braunr> wasn't there a discussion to add a minimum timeout to mach_msg for
-      select() or something like that during the past months ?
-    <youpi> there was, and it was added
-    <youpi> that could be it
-    <youpi> I don't want to drop it though, some app really need it
-    <braunr> as a debian patch only iirc ?
-    <youpi> yes
-    <braunr> ok
-    <braunr> if i'm right, the proper solution was to fix remote servers
-      instead of client calls
-    <youpi> (no drop, unless the actual bug gets fixed of course)
-    <braunr> so i'm guessing it's just a hack in between
-    <youpi> not only
-    <youpi> with a timeout of zero, mach will just give *no* time for the
-      servers to give an answer
-    <braunr> that's because the timeout is part of the client call
-    <youpi> so the protocol has to be rethought, both server/client side
-    <braunr> a suggested solution was to make it a parameter
-    <braunr> i mean, part of the message
-    <braunr> not a mach_msg parameter
-    <jkoenig> OTOH the servers should probably not be trusted to enforce the
-      timeout.
-    <braunr> why ?
-    <jkoenig> they're not necessarily trusted. (but then again, that's not the
-      only circumstances where that's a problem)
-    <braunr> there is a proposed solution for that too (trust root and self
-      servers only by default)
-    <jkoenig> I'm not sure they're particularily easy to identify in the
-      general case
-    <braunr> "they" ? the solutions you mean ?
-    <braunr> or the servers ?
-    <youpi> jkoenig: you can't trust the servers in general to provide an
-      answer, timeout or not
-    <jkoenig> yes the root/self servers.
-    <braunr> ah
-    <youpi> jkoenig: you can stat the actual node before dereferencing the
-      translator
-    <jkoenig> could they not report FD activity asynchronously to the message
-      port? libc would cache the state
-    <youpi> I don't understand what you mean
-    <youpi> anyway, really making the timeout part of the message is not a
-      problem
-    <braunr> 10:10 < youpi> jkoenig: you can't trust the servers in general to
-      provide an answer, timeout or not
-    <youpi> we already trust everything (e.g. read() ) into providing an answer
-      immediately
-    <braunr> i don't see why
-    <youpi> braunr: put sleep(1) in S_io_read()
-    <youpi> it'll not give you an immediate answer, O_NODELAY being set or not
-    <braunr> well sleep is evil, but let's just say the server thread blocks
-    <braunr> ok
-    <braunr> well fix the server
-    <youpi> so we agree
-    <braunr> ?
-    <youpi> in the current security model, we trust the server into achieve the
-      timeout
-    <braunr> yes
-    <youpi> and jkoenig's remark is more global than just select()
-    <braunr> taht's why we must make sure we're contacting trusted servers by
-      default
-    <youpi> it affects read() too
-    <braunr> sure
-    <youpi> so there's no reason not to fix select()
-    <youpi> that's the important point
-    <braunr> but this doesn't mean we shouldn't pass the timeout to the server
-      and expect it to handle it correctly
-    <youpi> we keep raising issues with things, and not achieve anything, in
-      the Hurd
-    <braunr> if it doesn't, then it's a bug, like in any other kernel type
-    <youpi> I'm not the one to convince :)
-    <braunr> eh, some would say it's one of the goals :)
-    <braunr> who's to be convinced then ?
-    <youpi> jkoenig: 
-    <youpi> who raised the issue
-    <braunr> ah
-    <youpi> well, see the irc log :)
-    <jkoenig> not that I'm objecting to any patch, mind you :-)
-    <braunr> i didn't understand it that way
-    <braunr> if you can't trust the servers to act properly, it's similar to
-      not trusting linux fs code
-    <youpi> no, the difference is that servers can be non-root
-    <youpi> while on linux they can't
-    <braunr> again, trust root and self
-    <youpi> non-root fuse mounts are not followed by default
-    <braunr> as with fuse
-    <youpi> that's still to be written
-    <braunr> yes
-    <youpi> and as I said, you can stat the actual  node and then dereference
-      the translator afterwards
-    <braunr> but before writing anything, we'd better agree on the solution :)
-    <youpi> which, again, "just" needs to be written
-    <antrik> err... adding a timeout to mach_msg()? that's just wrong
-    <antrik> (unless I completely misunderstood what this discussion was
-      about...)
-
-
-#### IRC, freenode, #hurd, 2012-02-04
-
-    <youpi> this is confirmed: the select hack patch hurts vim performance a
-      lot
-    <youpi> I'll use program_invocation_short_name to make the patch even more
-      ugly
-    <youpi> (of course, we really need to fix select somehow)
-    <pinotree> could it (also) be that vim uses select() somehow "badly"?
-    <youpi> fsvo "badly", possibly, but still
-    <gnu_srs1> Could that the select() stuff be the reason for a ten times
-      slower ethernet too, e.g. scp and apt-get?
-    <pinotree> i didn't find myself neither scp nor apt-get slower, unlike vim
-    <youpi> see strace: scp does not use select
-    <youpi> (I haven't checked  apt yet)
-
-
-### IRC, freenode, #hurd, 2012-02-14
-
-    <braunr> on another subject, I'm wondering how to correctly implement
-      select/poll with a timeout on a multiserver system :/
-    <braunr> i guess a timeout of 0 should imply a non blocking round-trip to
-      servers only
-    <braunr> oh good, the timeout is already part of the io_select call
-
-
-### IRC, freenode, #hurdfr, 2012-02-22
-
-    <braunr> le gros souci de notre implé, c'est que le timeout de select est
-      un paramètre client
-    <braunr> un paramètre passé directement à mach_msg
-    <braunr> donc si tu mets un timeout à 0, y a de fortes chances que mach_msg
-      retourne avant même qu'un RPC puisse se faire entièrement (round-trip
-      client-serveur donc)
-    <braunr> et donc quand le timeout est à 0 pour du non bloquant, ben tu
-      bloques pas, mais t'as pas tes évènements ..
-    <abique|work> peut-être que passer le timeout de 10ms à 10 us améliorerait
-      la situation.
-    <abique|work> car 10ms c'est un peut beaucoup :)
-    <braunr> c'est l'interval timer système historique unix
-    <braunr> et mach n'est pas préemptible
-    <braunr> donc c'est pas envisageable en l'état
-    <braunr> ceci dit c'est pas complètement lié
-    <braunr> enfin si, il nous faudrait qqchose de similaire aux high res
-      timers de linux
-    <braunr> enfin soit des timer haute résolution, soit un timer programmable
-      facilement
-    <braunr> actuellement il n'y a que le 8254 qui est programmé, et pour
-      assurer un scheduling à peu près correct, il est programmé une fois, à
-      10ms, et basta
-    <braunr> donc oui, préciser 1ms ou 1us, ça changera rien à l'interval
-      nécessaire pour déterminer que le timer a expiré
-
-
-### IRC, freenode, #hurd, 2012-02-27
-
-    <youpi> braunr: extremely dirty hack
-    <youpi> I don't even want to detail :)
-    <braunr> oh
-    <braunr> does it affect vim only ?
-    <braunr> or all select users ?
-    <youpi> we've mostly seen it with vim
-    <youpi> but possibly fakeroot has some issues too
-    <youpi> it's very little probable that only vim has the issue :)
-    <braunr> i mean, is it that dirty to switch behaviour depending on the
-      calling program ?
-    <youpi> not all select users
-    <braunr> ew :)
-    <youpi> just those which do select({0,0})
-    <braunr> well sure
-    <youpi> braunr: you guessed right :)
-    <braunr> thanks anyway
-    <braunr> it's probably a good thing to do currently
-    <braunr> vim was getting me so mad i was using sshfs lately
-    <youpi> it's better than nothing yes
-
-
-### IRC, freenode, #hurd, 2012-07-21
-
-    <braunr> damn, select is actually completely misdesigned :/
-    <braunr> iiuc, it makes servers *block*, in turn :/
-    <braunr> can't be right
-    <braunr> ok i understand it better
-    <braunr> yes, timeouts should be passed along with the other parameters to
-      correctly implement non blocking select
-    <braunr> (or the round-trip io_select should only ask for notification
-      requests instead of making a server thread block, but this would require
-      even more work)
-    <braunr> adding the timeout in the io_select call should be easy enough for
-      whoever wants to take over a not-too-complicated-but-not-one-liner-either
-      task :)
-    <antrik> braunr: why is a blocking server thread a problem?
-    <braunr> antrik: handling the timeout at client side while server threads
-      block is the problem
-    <braunr> the timeout must be handled along with blocking obviously
-    <braunr> so you either do it at server side when async ipc is available,
-      which is the case here
-    <braunr> or request notifications (synchronously) and block at client side,
-      waiting forthose notifications
-    <antrik> braunr: are you saying the client has a receive timeout, but when
-      it elapses, the server thread keeps on blocking?...
-    <braunr> antrik: no i'm referring to the non-blocking select issue we have
-    <braunr> antrik: the client doesn't block in this case, whereas the servers
-      do
-    <braunr> which obviously doesn't work ..
-    <braunr> see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=79358
-    <braunr> this is the reason why vim (and probably others) are slow on the
-      hurd, while not consuming any cpu
-    <braunr> the current work around is that whenevever a non-blocking select
-      is done, it's transformed into a blocking select with the smallest
-      possible timeout
-    <braunr> whenever*
-    <antrik> braunr: well, note that the issue only began after fixing some
-      other select issue... it was fine before
-    <braunr> apparently, the issue was raised in 2000
-    <braunr> also, note that there is a delay between sending the io_select
-      requests and blocking on the replies
-    <braunr> when machines were slow, this delay could almost guarantee a
-      preemption between these steps, making the servers reply soon enough even
-      for a non blocking select
-    <braunr> the problem occurs when sending all the requests and checking for
-      replies is done before servers have a chance the send the reply
-    <antrik> braunr: I don't know what issue was raised in 2000, but I do know
-      that vim worked perfectly fine until last year or so. then some select
-      fix was introduced, which in turn broke vim
-    <braunr> antrik: could be the timeout rounding, Aug 2 2010
-    <braunr> hum but, the problem wasn't with vim
-    <braunr> vim does still work fine (in fact, glibc is patched to check some
-      well known process names and selectively fix the timeout)
-    <braunr> which is why vim is fast and view isn't
-    <braunr> the problem was with other services apparently
-    <braunr> and in order to fix them, that workaround had to be introduced
-    <braunr> i think it has nothing to do with the timeout rounding
-    <braunr> it must be the time when youpi added the patch to the debian
-      package
-    <antrik> braunr: the problem is that with the patch changing the timeout
-      rounding, vim got extremely slow. this is why the ugly hacky exception
-      was added later...
-    <antrik> after reading the report, I agree that the timeout needs to be
-      handled by the server. at least the timeout=0 case.
-    <pinotree> vim uses often 0-time selects to check whether there's input
-    <antrik> client-side handling might still be OK for other timeout settings
-      I guess
-    <antrik> I'm a bit ambivalent about that
-    <antrik> I tend to agree with Neal though: it really doesn't make much
-      sense to have a client-side watchdog timer for this specific call, while
-      for all other ones we trust the servers not to block...
-    <antrik> or perhaps not. for standard sync I/O, clients should expect that
-      an operation could take long (though not forever); but they might use
-      select() precisely to avoid long delays in I/O... so it makes some sense
-      to make sure that select() really doesn't delay because of a busy server
-    <antrik> OTOH, unless the server is actually broken (in which anything
-      could happen), a 0-time select should never actually block for an
-      extended period of time... I guess it's not wrong to trust the servers on
-      that
-    <antrik> pinotree: hm... that might explain a certain issue I *was*
-      observing with Vim on Hurd -- though I never really thought about it
-      being an actual bug, as opposed to just general Hurd sluggishness...
-    <antrik> but it makes sense now
-    <pinotree> antrik:
-      http://patch-tracker.debian.org/patch/series/view/eglibc/2.13-34/hurd-i386/local-select.diff
-    <antrik> so I guess we all agree that moving the select timeout to the
-      server is probably the most reasonably approach...
-    <antrik> braunr: BTW, I wouldn't really consider the sync vs. async IPC
-      cases any different. the client blocks waiting for the server to reply
-      either way...
-    <antrik> the only difference is that in the sync IPC case, the server might
-      want to take some special precaution so it doesn't have to block until
-      the client is ready to receive the reply
-    <antrik> but that's optional and not really select-specific I'd say
-    <antrik> (I'd say the only sane approach with sync IPC is probably for the
-      server never to wait -- if the client fails to set up for receiving the
-      reply in time, it looses...)
-    <antrik> and with the receive buffer approach in Viengoos, this can be done
-      really easy and nice :-)
-
-
-#### IRC, freenode, #hurd, 2012-07-22
-
-    <braunr> antrik: you can't block in servers with sync ipc
-    <braunr> so in this case, "select" becomes a request for notifications
-    <braunr> whereas with async ipc, you can, so it's less efficient to make a
-      full round trip just to ask for requests when you can just do async
-      requests (doing the actual blocking) and wait for any reply after
-    <antrik> braunr: I don't understand. why can't you block in servers with
-      async IPC?
-    <antrik> braunr: err... with sync IPC I mean
-    <braunr> antrik: because select operates on more than one fd
-    <antrik> braunr: and what does that got to do with sync vs. async IPC?...
-    <antrik> maybe you are thinking of endpoints here, which is a whole
-      different story
-    <antrik> traditional L4 has IPC ports bound to specific threads; so
-      implementing select requires a separate client thread for each
-      server. but that's not mandatory for sync IPC. Viengoos has endpoints not
-      bound to threads
-    <braunr> antrik: i don't know what "endpoint" means here
-    <braunr> but, you can't use sync IPC to implement select on multiple fds
-      (and thus possibly multiple servers) by blocking in the servers
-    <braunr> you'd block in the first and completely miss the others
-    <antrik> braunr: I still don't see why... or why async IPC would change
-      anything in that regard
-    <braunr> antrik: well, you call select on 3 fds, each implemented by
-      different servers
-    <braunr> antrik: you call a sync select on the first fd, obviously you'll
-      block there
-    <braunr> antrik: if it's async, you don't block, you just send the
-      requests, and wait for any reply
-    <braunr> like we do
-    <antrik> braunr: I think you might be confused about the meaning of sync
-      IPC. it doesn't in any way imply that after sending an RPC request you
-      have to block on some particular reply...
-    <youpi> antrik: what does sync mean then?
-    <antrik> braunr: you can have any number of threads listening for replies
-      from the various servers (if using an L4-like model); or even a single
-      thread, if you have endpoints that can listen on replies from different
-      sources (which was pretty much the central concern in the Viengoos IPC
-      design AIUI)
-    <youpi> antrik: I agree with your "so it makes some sense to make sure that
-      select() really doesn't delay because of a busy server" (for blocking
-      select) and "OTOH, unless the server is actually broken (in which
-      anything could happen), a 0-time select should never actually block" (for
-      non-blocking select)
-    <antrik> youpi: regarding the select, I was thinking out loud; the former
-      statement was mostly cancelled by my later conclusions...
-    <antrik> and I'm not sure the latter statement was quite clear
-    <youpi> do you know when it was?
-    <antrik> after rethinking it, I finally concluded that it's probably *not*
-      a problem to rely on the server to observe the timout. if it's really
-      busy, it might take longer than the designated timeout (especially if
-      timeout is 0, hehe) -- but I don't think this is a problem
-    <antrik> and if it doens't observe the timout because it's
-      broken/malicious, that's not more problematic that any other RPC the
-      server doesn't handle as expected
-    <youpi> ok
-    <youpi> did somebody wrote down the conclusion "let's make select timeout
-      handled at server side" somewhere?
-    <antrik> youpi: well, neal already said that in a followup to the select
-      issue Debian bug... and after some consideration, I completely agree with
-      his reasoning (as does braunr)
-
-
-#### IRC, freenode, #hurd, 2012-07-23
-
-    <braunr> antrik: i was meaning sync in the most common meaning, yes, the
-      client blocking on the reply
-    <antrik> braunr: I think you are confusing sync IPC with sync I/O ;-)
-    <antrik> braunr: by that definition, the vast majority of Hurd IPC would be
-      sync... but that's obviously not the case
-    <antrik> synchronous IPC means that send and receive happen at the same
-      time -- nothing more, nothing less. that's why it's called synchronous
-    <braunr> antrik: yes
-    <braunr> antrik: so it means the client can't continue unless he actually
-      receives
-    <antrik> in a pure sync model such as L4 or EROS, this means either the
-      sender or the receiver has to block, so synchronisation can happen. which
-      one is server and which one is client is completely irrelevant here --
-      this is about individual message transfer, not any RPC model on top of it
-    <braunr> i the case of select, i assume sender == client
-    <antrik> in Viengoos, the IPC is synchronous in the sense that transfer
-      from the send buffer to the receive buffer happens at the same time; but
-      it's asynchronous in the sense that the receiver doesn't necessarily have
-      to be actively waiting for the incoming message
-    <braunr> ok, i was talking about a pure sync model
-    <antrik> (though it most cases it will still do so...)
-    <antrik> braunr: BTW, in the case of select, the sender is *not* the
-      client. the reply is relevant here, not the request -- so the client is
-      the receiver
-    <antrik> (the select request is boring)
-    <braunr> sorry, i don't understand, you seem to dismiss the select request
-      for no valid reason
-    <antrik> I still don't see how sync vs. async affects the select reply
-      receive though... blocking seems the right approach in either case
-    <braunr> blocking is required
-    <braunr> but you either block in the servers, or in the client
-    <braunr> (and if blocking in the servers, the client also blocks)
-    <braunr> i'll explain how i see it again
-    <braunr> there are two approaches to implementing select
-    <braunr> 1/ send requests to all servers, wait for any reply, this is what
-      the hurd does
-    <braunr> but it's possible because you can send all the requests without
-      waiting for the replies
-    <braunr> 2/ send notification requests, wait for a notification
-    <braunr> this doesn't require blocking in the servers (so if you have many
-      clients, you don't need as many threads)
-    <braunr> i was wondering which approach was used by the hurd, and if it
-      made sense to change
-    <antrik> TBH I don't see the difference between 1) and 2)... whether the
-      message from the server is called an RPC reply or a notification is just
-      a matter of definition
-    <antrik> I think I see though what you are getting at
-    <antrik> with sync IPC, if the client sent all requests and only afterwards
-      started to listen for replies, the servers might need to block while
-      trying to deliver the reply because the client is not ready yet
-    <braunr> that's one thing yes
-    <antrik> but even in the sync case, the client can immediately wait for
-      replies to each individual request -- it might just be more complicated,
-      depending on the specifics of the IPC design
-    <braunr> what i mean by "send notification requests" is actually more than
-      just sending, it's a complete RPC
-    <braunr> and notifications are non-blocking, yes
-    <antrik> (with L4, it would require a separate client thread for each
-      server contacted... which is precisely why a different mechanism was
-      designed for Viengoos)
-    <braunr> seems weird though
-    <braunr> don't they have a portset like abstraction ?
-    <antrik> braunr: well, having an immediate reply to the request and a
-      separate notification later is just a waste of resources... the immediate
-      reply would have no information value
-    <antrik> no, in original L4 IPC is always directed to specific threads
-    <braunr> antrik: some could see the waste of resource as being the
-      duplication of the number of client threads in the server
-    <antrik> you could have one thread listening to replies from several
-      servers -- but then, replies can get lost
-    <braunr> i see
-    <antrik> (or the servers have to block on the reply)
-    <braunr> so, there are really no capabilities in the original l4 design ?
-    <antrik> though I guess in the case of select() it wouldn't really matter
-      if replies get lost, as long as at least one is handled... would just
-      require the listener thread by separate from the thread sending the
-      requests
-    <antrik> braunr: right. no capabilities of any kind
-    <braunr> that was my initial understanding too
-    <braunr> thanks
-    <antrik> so I partially agree: in a purely sync IPC design, it would be
-      more complicated (but not impossible) to make sure the client gets the
-      replies without the server having to block while sending replies
-
-    <braunr> arg, we need hurd_condition_timedwait (and possible
-      condition_timedwait) to cleanly fix io_select
-    <braunr> luckily, i still have my old patch for condition_timedwait :>
-    <braunr> bddebian: in order to implement timeouts in select calls, servers
-      now have to use a hurd_condition_timedwait function
-    <braunr> is it possible that a thread both gets canceled and timeout on a
-      wait ?
-    <braunr> looks unlikely to me
-
-    <braunr> hm, i guess the same kind of compatibility constraints exist for
-      hurd interfaces
-    <braunr> so, should we have an io_select1 ?
-    <antrik> braunr: I would use a more descriptive name: io_select_timeout()
-    <braunr> antrik: ah yes
-    <braunr> well, i don't really like the idea of having 2 interfaces for the
-      same call :)
-    <braunr> because all select should be select_timeout :)
-    <braunr> but ok
-    <braunr> antrik: actually, having two select calls may be better
-    <braunr> oh it's really minor, we do'nt care actually
-    <antrik> braunr: two select calls?
-    <braunr> antrik: one with a timeout and one without
-    <braunr> the glibc would choose at runtime
-    <antrik> right. that was the idea. like with most transitions, that's
-      probably the best option
-    <braunr> there is no need to pass the timeout value if it's not needed, and
-      it's easier to pass NULL this way
-    <antrik> oh
-    <antrik> nah, that would make the transition more complicated I think
-    <braunr> ?
-    <braunr> ok
-    <braunr> :)
-    <braunr> this way, it becomes very easy
-    <braunr> the existing io_select call moves into a select_common() function
-    <antrik> the old variant doesn't know that the server has to return
-      immediately; changing that would be tricky. better just use the new
-      variant for the new behaviour, and deprecate the old one
-    <braunr> and the entry points just call this common function with either
-      NULL or the given timeout
-    <braunr> no need to deprecate the old one
-    <braunr> that's what i'm saying
-    <braunr> and i don't understand "the old variant doesn't know that the
-      server has to return immediately"
-    <antrik> won't the old variant block indefinitely in the server if there
-      are no ready fds?
-    <braunr> yes it will
-    <antrik> oh, you mean using the old variant if there is no timeout value?
-    <braunr> yes
-    <antrik> well, I guess this would work
-    <braunr> well of course, the question is rather if we want this or not :)
-    <antrik> hm... not sure
-    <braunr> we need something to improve the process of changing our
-      interfaces
-    <braunr> it's really painful currnelty
-    <antrik> inside the servers, we probably want to use common code
-      anyways... so in the long run, I think it simplifies the code when we can
-      just drop the old variant at some point
-    <braunr> a lot of the work we need to do involves changing interfaces, and
-      we very often get to the point where we don't know how to do that and
-      hardly agree on a final version :
-    <braunr> :/
-    <braunr> ok but
-    <braunr> how do you tell the server you don't want a timeout ?
-    <braunr> a special value ? like { -1; -1 } ?
-    <antrik> hm... good point
-    <braunr> i'll do it that way for now
-    <braunr> it's the best way to test it
-    <antrik> which way you mean now?
-    <braunr> keeping io_select as it is, add io_select_timeout
-    <antrik> yeah, I thought we agreed on that part... the question is just
-      whether io_select_timeout should also handle the no-timeout variant going
-      forward, or keep io_select for that. I'm really not sure
-    <antrik> maybe I'll form an opinion over time :-)
-    <antrik> but right now I'm undecided
-    <braunr> i say we keep io_select
-    <braunr> anyway it won't change much
-    <braunr> we can just change that at the end if we decide otherwise
-    <antrik> right
-    <braunr> even passing special values is ok
-    <braunr> with a carefully written hurd_condition_timedwait, it's very easy
-      to add the timeouts :)
-    <youpi> antrik, braunr: I'm wondering, another solution is to add an
-      io_probe, i.e. the server has to return an immediate result, and the
-      client then just waits for all results, without timeout
-    <youpi> that'd be a mere addition in the glibc select() call: when timeout
-      is 0, use that, and otherwise use the previous code
-    <youpi> the good point is that it looks nicer in fs.defs
-    <youpi> are there bad points?
-    <youpi> (I don't have the whole issues in the mind now, so I'm probably
-      missing things)
-    <braunr> youpi: the bad point is duplicating the implementation maybe
-    <youpi> what duplication ?
-    <youpi> ah you mean for the select case
-    <braunr> yes
-    <braunr> although it would be pretty much the same
-    <braunr> that is, if probe only, don't enter the wait loop
-    <youpi> could that be just some ifs here and there?
-    <youpi> (though not making the code easier to read...)
-    <braunr> hm i'm not sure it's fine
-    <youpi> in that case oi_select_timeout looks ncier ideed :)
-    <braunr> my problem with the current implementation is having the timeout
-      at the client side whereas the server side is doing the blocking
-    <youpi> I wonder how expensive a notification is, compared to blocking
-    <youpi> a blocking indeed needs a thread stack
-    <youpi> (and kernel thread stuff)
-    <braunr> with the kind of async ipc we have, it's still better to do it
-      that way
-    <braunr> and all the code already exists
-    <braunr> having the timeout at the client side also have its advantage
-    <braunr> has*
-    <braunr> latency is more precise
-    <braunr> so the real problem is indeed the non blocking case only
-    <youpi> isn't it bound to kernel ticks anyway ?
-    <braunr> uh, not if your server sucks
-    <braunr> or is loaded for whatever reason
-    <youpi> ok, that's not what I understood by "precision" :)
-    <youpi> I'd rather call it robustness :)
-    <braunr> hm
-    <braunr> right
-    <braunr> there are several ways to do this, but the io_select_timeout one
-      looks fine to me
-    <braunr> and is already well on its way
-    <braunr> and it's reliable
-    <braunr> (whereas i'm not sure about reliability if we keep the timeout at
-      client side)
-    <youpi> btw make the timeout nanoseconds
-    <braunr> ??
-    <youpi> pselect uses timespec, not timeval
-    <braunr> do we want pselect ?
-    <youpi> err, that's the only safe way with signals
-    <braunr> not only, no
-    <youpi> and poll is timespec also
-    <youpi> not only??
-    <braunr> you mean ppol
-    <braunr> ppoll
-    <youpi> no, poll too
-    <youpi> by "the only safe way", I mean for select calls
-    <braunr> i understand the race issue
-    <youpi> ppoll is a gnu extension
-    <braunr> int poll(struct pollfd *fds, nfds_t nfds, int timeout);
-    <youpi> ah, right, I was also looking at ppoll
-    <youpi> any
-    <youpi> way
-    <youpi> we can use nanosecs
-    <braunr> most event loops use a pipe or a socketpair
-    <youpi> there's no reason not to
-    <antrik> youpi: I briefly considered special-casisg 0 timeouts last time we
-      discussed this; but I concluded that it's probably better to handle all
-      timeouts server-side
-    <youpi> I don't see why we should even discuss that
-    <braunr> and translate signals to writes into the pipe/socketpair
-    <youpi> antrik: ok
-    <antrik> you can't count on select() timout precision anyways
-    <antrik> a few ms more shouldn't hurt any sanely written program
-    <youpi> braunr: "most" doesn't mean "all"
-    <youpi> there *are* applications which use pselect
-    <braunr> well mach only handles millisedonds
-    <braunr> seconds
-    <youpi> and it's not going out of the standard
-    <youpi> mach is not the hurd
-    <youpi> if we change mach, we can still keep the hurd ipcs
-    <youpi> anyway
-    <youpi> agagin
-    <youpi> I reallyt don't see the point of the discussion
-    <youpi> is there anything *against* using nanoseconds?
-    <braunr> i chose the types specifically because of that :p
-    <braunr> but ok i can change again
-    <youpi> becaus what??
-    <braunr> i chose to use mach's native time_value_t
-    <braunr> because it matches timeval nicely
-    <youpi> but it doesn't match timespec nicely
-    <braunr> no it doesn't
-    <braunr> should i add a hurd specific time_spec_t then ?
-    <youpi> "how do you tell the server you don't want a timeout ? a special
-      value ? like { -1; -1 } ?"
-    <youpi> you meant infinite blocking?
-    <braunr> youpi: yes
-    <braunr> oh right, pselect is posix
-    <youpi> actually posix says that there can be limitations on the maximum
-      timeout supported, which should be at least 31 days
-    <youpi> -1;-1 is thus fine
-    <braunr> yes
-    <braunr> which is why i could choose time_value_t (a struct of 2 integer_t)
-    <youpi> well, I'd say gnumach could grow a nanosecond-precision time value
-    <youpi> e.g. for clock_gettime precision and such
-
-[[clock_gettime]].
-
-    <braunr> so you would prefer me adding the time_spec_t time to gnumach
-      rather than the hurd ?
-    <youpi> well, if hurd RPCs are using mach types and there's no mach type
-      for nanoseconds, it m akes sense to add one
-    <youpi> I don't know about the first part
-    <braunr> yes some hurd itnerfaces also use time_value_t
-    <antrik> in general, I don't think Hurd interfaces should rely on a Mach
-      timevalue. it's really only meaningful when Mach is involved...
-    <antrik> we could even pass the time value as an opaque struct. don't
-      really need an explicit MIG type for that.
-    <braunr> opaque ?
-    <youpi> an opaque type would be a step backward from multi-machine support
-      ;)
-    <antrik> youpi: that's a sham anyways ;-)
-    <youpi> what?
-    <youpi> ah, using an opaque type, yes :)
-    <braunr> probably why my head bugged while reading that
-    <antrik> it wouldn't be fully opaque either. it would be two ints, right?
-      even if Mach doesn't know what these two ints mean, it still could to
-      byte order conversion, if we ever actually supported setups where it
-      matters...
-    <braunr> so uh, should this new time_spec_t be added in gnumach or the hurd
-      ?
-    <braunr> youpi: you're the maintainer, you decide :p
-    *** antrik (~olaf@port-92-195-60-96.dynamic.qsc.de) has joined channel
-          #hurd
-    <youpi> well, I don't like deciding when I didn't even have read fs.defs :)
-    <youpi> but I'd say the way forward is defining it in the hurd
-    <youpi> and put a comment "should be our own type" above use of the mach
-      type
-    <braunr> ok
-    *** antrik (~olaf@port-92-195-60-96.dynamic.qsc.de) has quit: Remote host
-          closed the connection
-    <braunr> and, by the way, is using integer_t fine wrt the 64-bits port ?
-    <youpi> I believe we settled on keeping integer_t a 32bit integer, like xnu
-      does
-    *** elmig (~elmig@a89-155-34-142.cpe.netcabo.pt) has quit: Quit: leaving
-    <braunr> ok so it's not
-    *** antrik (~olaf@port-92-195-60-96.dynamic.qsc.de) has joined channel
-          #hurd
-    <braunr> uh well
-    <youpi> why "not" ?
-    <braunr> keeping it 32-bits for the 32-bits userspace hurd
-    <braunr> but i'm talking about a true 64-bits version
-    <braunr> wouldn't integer_t get 64-bits then ?
-    <youpi> I meant we settled on a no
-    <youpi> like xnu does
-    <braunr> xnu uses 32-bits integer_t even when userspace runs in 64-bits
-      mode ?
-    <youpi> because things for which we'd need 64bits then are offset_t,
-      vm_size_t, and such
-    <youpi> yes
-    <braunr> ok
-    <braunr> youpi: but then what is the type to use for long integers ?
-    <braunr> or uintptr_t
-    <youpi> braunr: uintptr_t
-    <braunr> the mig type i mean
-    <youpi> type memory_object_offset_t     = uint64_t;
-    <youpi> (and size)
-    <braunr> well that's a 64-bits type
-    <youpi> well, yes
-    <braunr> natural_t and integer_t were supposed to have the processor word
-      size
-    <youpi> probably I didn't understand your question
-    <braunr> if we remove that property, what else has it ?
-    <youpi> yes, but see rolands comment on this
-    <braunr> ah ?
-    <youpi> ah, no, he just says the same
-    <antrik> braunr: well, it's debatable whether the processor word size is
-      really 64 bit on x86_64...
-    <antrik> all known compilers still consider int to be 32 bit
-    <antrik> (and int is the default word size)
-    <braunr> not really
-    <youpi> as in?
-    <braunr> the word size really is 64-bits
-    <braunr> the question concerns the data model
-    <braunr> with ILP32 and LP64, int is always 32-bits, and long gets the
-      processor word size
-    <braunr> and those are the only ones current unices support
-    <braunr> (which is why long is used everywhere for this purpose instead of
-      uintptr_t in linux)
-    <antrik> I don't think int is 32 bit on alpha?
-    <antrik> (and probably some other 64 bit arches)
-    <braunr> also, assuming we want to maintain the ability to support single
-      system images, do we really want RPC with variable size types ?
-    <youpi> antrik: linux alpha's int is 32bit
-    <braunr> sparc64 too
-    <youpi> I don't know any 64bit port with 64bit int
-    <braunr> i wonder how posix will solve the year 2038 problem ;p
-    <youpi> time_t is a long
-    <youpi> the hope is that there'll be no 32bit systems by 2038 :)
-    <braunr> :)
-    <youpi> but yes, that matters to us
-    <youpi> number of seconds should not be just an int
-    <braunr> we can force a 64-bits type then
-    <braunr> i tend to think we should have no variable size type in any mig
-      interface
-    <braunr> youpi: so, new hurd type, named time_spec_t, composed of two
-      64-bits signed integers
-    <pinotree> braunr: i added that in my prototype of monotonic clock patch
-      for gnumach
-    <braunr> oh
-    <youpi> braunr: well, 64bit is not needed for the nanosecond part
-    <braunr> right
-    <braunr> it will be aligned anyway :p
-    <youpi> I know
-    <youpi> uh, actually linux uses long there
-    <braunr> pinotree: i guess your patch is still in debian ?
-    <braunr> youpi: well yes
-    <braunr> youpi: why wouldn't it ? :)
-    <pinotree> no, never applied
-    <youpi> braunr: because 64bit is not needed
-    <braunr> ah, i see what you mean
-    <youpi> oh, posix says longa ctually
-    <youpi> *exactly* long
-    <braunr> i'll use the same sizes
-    <braunr> so it fits nicely with timespec
-    <braunr> hm
-    <braunr> but timespec is only used at the client side
-    <braunr> glibc would simply move the timespec values into our hurd specific
-      type (which can use 32-bits nanosecs) and servers would only use that
-      type
-    <braunr> all right, i'll do it that way, unless there are additional
-      comments next morning :)
-    <antrik> braunr: we never supported federations, and I'm pretty sure we
-      never will. the remnants of network IPC code were ripped out some years
-      ago. some of the Hurd interfaces use opaque structs too, so it wouldn't
-      even work if it existed. as I said earlier, it's really all a sham
-    <antrik> as for the timespec type, I think it's easier to stick with the
-      API definition at RPC level too
-
-
-#### IRC, freenode, #hurd, 2012-07-24
-
-    <braunr> youpi: antrik: is vm_size_t an appropriate type for a c long ?
-    <braunr> (appropriate mig type)
-    <antrik> I wouldn't say so. while technically they are pretty much
-      guaranteed to be the same, conceptually they are entirely different
-      things -- it would be confusing at least to do it that way...
-    <braunr> antrik: well which one then ? :(
-    <antrik> braunr: no idea TBH
-    <braunr> antrik_: that should have been natural_t and integer_t
-    <braunr> so maybe we should new types to replace them
-    <antrik_> braunr: actually, RPCs should never have nay machine-specific
-      types... which makes me realise that a 1:1 translation to the POSIX
-      definition is actually not possible if we want to follow the Mach ideals
-    <braunr> i agree
-    <braunr> (well, the original mach authors used natural_t in quite a bunch
-      of places ..)
-    <braunr> the mig interfaces look extremely messy to me because of this type
-      issue
-    <braunr> and i just want to move forward with my work now
-    <braunr> i could just use 2 integer_t, that would get converted in the
-      massive future revamp of the interfaces for the 64-bits userspace
-    <braunr> or 2 64-bits types
-    <braunr> i'd like us to agree on one of the two not too late so i can
-      continue
-
-
-#### IRC, freenode, #hurd, 2012-07-25
-
-    <antrik_> braunr: well, for actual kernel calls, machine-specific types are
-      probably hard to avoid... the problem is when they are used in other RPCs
-    <braunr> antrik: i opted for a hurd specific time_data_t = struct[2] of
-      int64
-    <braunr> and going on with this for now
-    <braunr> once it works we'll finalize the types if needed
-    <antrik> I'm really not sure how to best handle such 32 vs. 64 bit issues
-      in Hurd interfaces...
-    <braunr> you *could* consider time_t and long to be machine specific types
-    <antrik> well, they clearly are
-    <braunr> long is
-    <braunr> time_t isn't really
-    <antrik> didn't you say POSIX demands it to be longs?
-    <braunr> we could decide to make it 64 bits in all versions of the hurd
-    <braunr> no
-    <braunr> posix requires the nanoseconds field of timespec to be long
-    <braunr> the way i see it, i don't see any problem (other than a little bit
-      of storage and performance) using 64-bits types here
-    <antrik> well, do we really want to use a machine-independent time format,
-      if the POSIX interfaces we are mapping do not?...
-    <antrik> (perhaps we should; I'm just uncertain what's better in this case)
-    <braunr> this would require creating new types for that
-    <braunr> probably mach types for consistency
-    <braunr> to replace natural_t and integer_t
-    <braunr> now this concerns a totally different issue than select
-    <braunr> which is how we're gonna handle the 64-bits port
-    <braunr> because natural_t and integer_t are used almost everywhere
-    <antrik> indeed
-    <braunr> and we must think of 2 ports
-    <braunr> the 32-bits over 64-bits gnumach, and the complete 64-bits one
-    <antrik> what do we do for the interfaces that are explicitly 64 bit?
-    <braunr> what do you mean ?
-    <braunr> i'm not sure there is anything to do
-    <antrik> I mean what is done in the existing ones?
-    <braunr> like off64_t ?
-    <antrik> yeah
-    <braunr> they use int64 and unsigned64
-    <antrik> OK. so we shouldn't have any trouble with that at least...
-    <pinotree> braunr: were you adding a time_value_t in mach, but for
-      nanoseconds?
-    <braunr> no i'm adding a time_data_t to the hurd
-    <braunr> for nanoseconds yes
-    <pinotree> ah ok
-    <pinotree> (maybe sure it is available in hurd/hurd_types.defs)
-    <braunr> yes it's there
-    <pinotree> \o/
-    <braunr> i mean, i didn't forget to add it there
-    <braunr> for now it's a struct[2] of int64
-    <braunr> but we're not completely sure of that
-    <braunr> currently i'm teaching the hurd how to use timeouts
-    <pinotree> cool
-    <braunr> which basically involves adding a time_data_t *timeout parameter
-      to many functions
-    <braunr> and replacing hurd_condition_wait with hurd_condition_timedwait
-    <braunr> and making sure a timeout isn't an error on the return path
-    * pinotree has a simplier idea for time_data_t: add a file_utimesns to
-        fs.defs
-    <braunr> hmm, some functions have a nonblocking parameter
-    <braunr> i'm not sure if it's better to replace them with the timeout, or add the timeout parameter
-    <braunr> considering the functions involved may return EWOULDBLOCK
-    <braunr> for now i'll add a timeout parameter, so that the code requires as little modification as possible
-    <braunr> tell me your opinion on that please
-    <antrik> braunr: what functions?
-    <braunr> connq_listen in pflocal for example
-    <antrik> braunr: I don't really understand what you are talking about :-(
-    <braunr> some servers implement select this way :
-    <braunr> 1/ call a function in non-blocking mode, if it indicates data is available, return immediately
-    <braunr> 2/ call the same function, in blocking mode
-    <braunr> normally, with the new timeout parameter, non-blocking could be passed in the timeout parameter (with a timeout of 0)
-    <braunr> operating in non-blocking mode, i mean
-    <braunr> antrik: is it clear now ? :)
-    <braunr> i wonder how the hurd managed to grow so much code without a cond_timedwait function :/
-    <braunr> i think i have finished my io_select_timeout patch on the hurd side
-    <braunr> :)
-    <braunr> a small step for the hurd, but a big one against vim latencies !!
-    <braunr> (which is the true reason i'm working on this haha)
-    <braunr> new hurd rbraun/io_select_timeout branch for those interested
-    <braunr> hm, my changes clashes hard with the debian pflocal patch by neal :/
-    <braunr> clash*
-    <antrik> braunr: replace I'd say. no need to introduce redundancy; and code changes not affecting interfaces are cheap
-    <antrik> (in general, I'm always in favour of refactoring)
-    <braunr> antrik: replace what ?
-    <antrik> braunr: wow, didn't think moving the timeouts to server would be such a quick task :-)
-    <braunr> antrik: :)
-    <antrik> 16:57 < braunr> hmm, some functions have a nonblocking parameter
-    <antrik> 16:58 < braunr> i'm not sure if it's better to replace them with the timeout, or add the timeout parameter
-    <braunr> antrik: ah about that, ok
-
-
-#### IRC, freenode, #hurd, 2012-07-26
-
-    <pinotree> braunr: wrt your select_timeout branch, why not push only the
-      time_data stuff to master?
-    <braunr> pinotree: we didn't agree on that yet
-
-    <braunr> ah better, with the correct ordering of io routines, my hurd boots
-      :)
-    <pinotree> and works too? :p
-    <braunr> so far yes
-    <braunr> i've spotted some issues in libpipe but nothing major
-    <braunr> i "only" have to adjust the client side select implementation now
-
-
-#### IRC, freenode, #hurd, 2012-07-27
-
-    <braunr> io_select should remain a routine (i.e. synchronous) for server
-      side stub code
-    <braunr> but should be asynchronous (send only) for client side stub code
-    <braunr> (since _hurs_select manually handles replies through a port set)
-
-
-##### IRC, freenode, #hurd, 2013-02-09
-
-    <braunr> io_select becomes a simpleroutine, except inside the hurd, where
-      it's a routine to keep the receive and reply mig stub code
-    <braunr> (the server side)
-
-
-#### IRC, freenode, #hurd, 2012-07-28
-
-    <braunr> why are there both REPLY_PORTS and IO_SELECT_REPLY_PORT macros in
-      the hurd ..
-    <braunr> and for the select call only :(
-    <braunr> and doing the exact same thing unless i'm mistaken
-    <braunr> the reply port is required for select anyway ..
-    <braunr> i just want to squeeze them into a new IO_SELECT_SERVER macro
-    <braunr> i don't think i can maintain the use the existing io_select call
-      as it is
-    <braunr> grr, the io_request/io_reply files aren't synced with the io.defs
-      file
-    <braunr> calls like io_sigio_request seem totally unused
-    <antrik> yeah, that's a major shortcoming of MIG -- we shouldn't need to
-      have separate request/reply defs
-    <braunr> they're not even used :/
-    <braunr> i did something a bit ugly but it seems to do what i wanted
-
-
-#### IRC, freenode, #hurd, 2012-07-29
-
-    <braunr> good, i have a working client-side select
-    <braunr> now i need to fix the servers a bit :x
-    <braunr> arg, my test cases work, but vim doesn't :((
-    <braunr> i hate select :p
-    <braunr> ah good, my problems are caused by a deadlock because of my glibc
-      changes
-    <braunr> ah yes, found my locking problem
-    <braunr> building my final libc now
-    * braunr crosses fingers
-    <braunr> (the deadlock issue was of course a one liner)
-    <braunr> grr deadlocks again
-    <braunr> grmbl, my deadlock is in pfinet :/
-    <braunr> my select_timeout code makes servers deadlock on the libports
-      global lock :/
-    <braunr> wtf..
-    <braunr> youpi: it may be related to the failed asserttion
-    <braunr> deadlocking on mutex_unlock oO
-    <braunr> grr
-    <braunr> actually, mutex_unlock sends a message to notify other threads
-      that the lock is ready
-    <braunr> and that's what is blocking ..
-    <braunr> i'm not sure it's a fundamental problem here
-    <braunr> it may simply be a corruption
-    <braunr> i have several (but not that many) threads blocked in mutex_unlock
-      and one blocked in mutex_lcok
-    <braunr> i fail to see how my changes can create such a behaviour
-    <braunr> the weird thing is that i can't reproduce this with my test cases
-      :/
-    <braunr> only vim makes things crazy
-    <braunr> and i suppose it's related to the terminal
-    <braunr> (don't terminals relay select requests ?)
-    <braunr> when starting vim through ssh, pfinet deadlocks, and when starting
-      it on the mach console, the console term deadlocks
-    <pinotree> no help/hints when started with rpctrace?
-    <braunr> i only get assertions with rpctrace
-    <braunr> it's completely unusable for me
-    <braunr> gdb tells vim is indeed blocked in a select request
-    <braunr> and i can't see any in the remote servers :/
-    <braunr> this is so weird ..
-    <braunr> when using vim with the unmodified c library, i clearly see the
-      select call, and everything works fine ....
-    <braunr>     2e27:       a1 c4 d2 b7 f7          mov    0xf7b7d2c4,%eax
-    <braunr>     2e2c:       62                      (bad)  
-    <braunr>     2e2d:       f6 47 b6 69             testb  $0x69,-0x4a(%edi)
-    <braunr> what's the "bad" line ??
-    <braunr> ew, i think i understand my problem now
-    <braunr> the timeout makes blocking threads wake prematurely
-    <braunr> but on an mutex unlock, or a condition signal/broadcast, a message
-      is still sent, as it is expected a thread is still waiting
-    <braunr> but the receiving thread, having returned sooner than expected
-      from mach_msg, doesn't dequeue the message
-    <braunr> as vim does a lot of non blocking selects, this fills the message
-      queue ...
-
-
-#### IRC, freenode, #hurd, 2012-07-30
-
-    <braunr> hm nice, the problem i have with my hurd_condition_timedwait seems
-      to also exist in libpthread
-
-[[!taglink open_issue_libpthread]].
-
-    <braunr> although at a lesser degree (the implementation already correctly
-      removes a thread that timed out from a condition queue, and there is a
-      nice FIXME comment asking what to do with any stale wakeup message)
-    <braunr> and the only solution i can think of for now is to drain the
-      message queue
-    <braunr> ah yes, i know have vim running with my io_select_timeout code :>
-    <braunr> but hum
-    <braunr> eating all cpu
-    <braunr> ah nice, an infinite loop in _hurd_critical_section_unlock
-    <braunr> grmbl
-    <tschwinge> braunr: But not this one?
-      http://www.gnu.org/software/hurd/open_issues/fork_deadlock.html
-    <braunr> it looks similar, yes
-    <braunr> let me try again to compare in detail
-    <braunr> pretty much the same yes
-    <braunr> there is only one difference but i really don't think it matters
-    <braunr> (#3  _hurd_sigstate_lock (ss=0x2dff718) at hurdsig.c:173
-    <braunr> instead of
-    <braunr> #3  _hurd_sigstate_lock (ss=0x1235008) at hurdsig.c:172)
-    <braunr> ok so we need to review jeremie's work
-    <braunr> tschwinge: thanks for pointing me at this
-    <braunr> the good thing with my patch is that i can reproduce in a few
-      seconds
-    <braunr> consistently
-    <tschwinge> braunr: You're welcome.  Great -- a reproducer!
-    <tschwinge> You might also build a glibc without his patches as a
-      cross-test to see the issues goes away?
-    <braunr> right
-    <braunr> i hope they're easy to find :)
-    <tschwinge> Hmm, have you already done changes to glibc?  Otherwise you
-      might also simply use a Debian package from before?
-    <braunr> yes i have local changes to _hurd_select
-    <tschwinge> OK, too bad.
-    <tschwinge> braunr: debian/patches/hurd-i386/tg-hurdsig-*, I think.
-    <braunr> ok
-    <braunr> hmmmmm
-    <braunr> it may be related to my last patch on the select_timeout branch
-    <braunr> (i mean, this may be caused by what i mentioned earlier this
-      morning)
-    <braunr> damn i can't build glibc without the signal disposition patches :(
-    <braunr> libpthread_sigmask.diff depends on it
-    <braunr> tschwinge: doesn't libpthread (as implemented in the debian glibc
-      patches) depend on global signal dispositions ?
-    <braunr> i think i'll use an older glibc for now
-    <braunr> but hmm which one ..
-    <braunr> oh whatever, let's fix the deadlock, it's simpler
-    <braunr> and more productive anyway
-    <tschwinge> braunr: May be that you need to revert some libpthread patch,
-      too.  Or even take out the libpthread build completely (you don't need it
-      for you current work, I think).
-    <tschwinge> braunr: Or, of course, you locate the deadlock.  :-)
-    <braunr> hum, now why would __io_select_timeout return
-      EMACH_SEND_INVALID_DEST :(
-    <braunr> the current glibc code just transparently reports any such error
-      as a false positive oO
-    <braunr> hm nice, segfault through recursion
-    <braunr> "task foo destroying an invalid port bar" everywhere :((
-    <braunr> i still have problems at the server side ..
-    <braunr> ok i think i have a solution for the "synchronization problem"
-    <braunr> (by this name, i refer to the way mutex and condition variables
-      are implemented"
-    <braunr> (the problem being that, when a thread unblocks early, because of
-      a timeout, another may still send a message to attempt it, which may fill
-      up the message queue and make the sender block, causing a deadlock)
-    <braunr> s/attempt/attempt to wake/
-    <bddebian> Attempts to wake a dead thread?
-    <braunr> no
-    <braunr> attempt to wake an already active thread
-    <braunr> which won't dequeue the message because it's doing something else
-    <braunr> bddebian: i'm mentioning this because the problem potentially also
-      exists in libpthread
-
-[[!taglink open_issue_libpthread]].
-
-    <braunr> since the underlying algorithms are exactly the same
-    <youpi> (fortunately the time-out versions are not often used)
-    <braunr> for now :)
-    <braunr> for reference, my idea is to make the wake call truely non
-      blocking, by setting a timeout of 0
-    <braunr> i also limit the message queue size to 1, to limit the amount of
-      spurious wakeups
-    <braunr> i'll be able to test that in 30 mins or so
-    <braunr> hum
-    <braunr> how can mach_msg block with a timeout of 0 ??
-    <braunr> never mind :p
-    <braunr> unfortunately, my idea alone isn't enough
-    <braunr> for those interested in the problem, i've updated the analysis in
-      my last commit
-      (http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout&id=40fe717ba9093c0c893d9ea44673e46a6f9e0c7d)
-
-
-#### IRC, freenode, #hurd, 2012-08-01
-
-    <braunr> damn, i can't manage to make threads calling condition_wait to
-      dequeue themselves from the condition queue :(
-    <braunr> (instead of the one sending the signal/broadcast)
-    <braunr> my changes on cthreads introduce 2 intrusive changes
-    <braunr> the first is that the wakeup port is limited to 1 port, and the
-      wakeup operation is totally non blocking
-    <braunr> which is something we should probably add in any case
-    <braunr> the second is that condition_wait dequeues itself after blocking,
-      instead of condition_signal/broadcast
-    <braunr> and this second change seems to introduce deadlocks, for reasons
-      completely unknown to me :((
-    <braunr> limited to 1 message*
-    <braunr> if anyone has an idea about why it is bad for a thread to remove
-      itself from a condition/mutex queue, i'm all ears
-    <braunr> i'm hitting a wall :(
-    <braunr> antrik: if you have some motivation, can you review this please ?
-      http://www.sceen.net/~rbraun/0001-Rework-condition-signal-broadcast.patch
-    <braunr> with this patch, i get threads blocked in condition_wait,
-      apparently waiting for a wakeup that never comes (or was already
-      consumed)
-    <braunr> and i don't understand why :
-    <braunr> :(
-    <bddebian> braunr: The condition never happens?
-    <braunr> bddebian: it works without the patch, so i guess that's not the
-      problem
-    <braunr> bddebian: hm, you could be right actually :p
-    <bddebian> braunr: About what? :)
-    <braunr> 17:50 < bddebian> braunr: The condition never happens?
-    <braunr> although i doubt it again
-    <braunr> this problem is getting very very frustrating
-    <bddebian> :(
-    <braunr> it frightens me because i don't see any flaw in the logic :(
-
-
-#### IRC, freenode, #hurd, 2012-08-02
-
-    <braunr> ah, seems i found a reliable workaround to my deadlock issue, and
-      more than a workaround, it should increase efficiency by reducing
-      messaging
-    * braunr happy
-    <kilobug> congrats :)
-    <braunr> the downside is that we may have a problem with non blocking send
-      calls :/
-    <braunr> which are used for signals
-    <braunr> i mean, this could be a mach bug
-    <braunr> let's try running a complete hurd with the change
-    <braunr> arg, the boot doesn't complete with the patch .. :(
-    <braunr> grmbl, by changing only a few bits in crtheads, the boot process
-      freezes in an infinite loop in somethign started after auth
-      (/etc/hurd/runsystem i assume)
-
-
-#### IRC, freenode, #hurd, 2012-08-03
-
-    <braunr> glibc actually makes some direct use of cthreads condition
-      variables
-    <braunr> and my patch seems to work with servers in an already working
-      hurd, but don't allow it to boot
-    <braunr> and the hang happens on bash, the first thing that doesn't come
-      from the hurd package
-    <braunr> (i mean, during the boot sequence)
-    <braunr> which means we can't change cthreads headers (as some primitives
-      are macros)
-    <braunr> *sigh*
-    <braunr> the thing is, i can't fix select until i have a
-      condition_timedwait primitive
-    <braunr> and i can't add this primitive until either 1/ cthreads are fixed
-      not to allow the inlining of its primitives, or 2/ the switch to pthreads
-      is done
-    <braunr> which might take a loong time :p
-    <braunr> i'll have to rebuild a whole libc package with a fixed cthreads
-      version
-    <braunr> let's do this
-    <braunr> pinotree: i see two __condition_wait calls in glibc, how is the
-      double underscore handled ?
-    <pinotree> where do you see it?
-    <braunr> sysdeps/mach/hurd/setpgid.c and sysdeps/mach/hurd/setsid.c
-    <braunr> i wonder if it's even used
-    <braunr> looks like we use posix/setsid.c now
-    <pinotree> #ifdef noteven
-    <braunr> ?
-    <pinotree> the two __condition_wait calls you pointed out are in such
-      preprocessor block
-    <pinotree> s
-    <braunr> but what does it mean ?
-    <pinotree> no idea
-    <braunr> ok
-    <pinotree> these two files should be definitely be used, they are found
-      earlier in the vpath
-    <braunr> hum, posix/setsid.c is a nop stub
-    <pinotree> i don't see anything defining "noteven" in glibc itself nor in
-      hurd
-    <braunr> :(
-    <pinotree> yes, most of the stuff in posix/, misc/, signal/, time/ are
-      ENOSYS stubs, to be reimplemented in a sysdep
-    <braunr> hm, i may have made a small mistake in cthreads itself actually
-    <braunr> right
-    <braunr> when i try to debug using a subhurd, gdb tells me the blocked
-      process is spinning in ld ..
-    <braunr> i mean ld.so
-    <braunr> and i can't see any debugging symbol
-    <braunr> some progress, it hangs at process_envvars
-    <braunr> eh
-    <braunr> i've partially traced my problem
-    <braunr> when a "normal" program starts, libc creates the signal thread
-      early
-    <braunr> the main thread waits for the creation of this thread by polling
-      its address
-    <braunr> (i.e. while (signal_thread == 0); )
-    <braunr> for some reason, it is stuck in this loop
-    <braunr> cthread creation being actually governed by
-      condition_wait/broadcast, it makes some sense
-    <bddebian> braunr: When you say the "main" thread, do you mean the main
-      thread of the program?
-    <braunr> bddebian: yes
-    <braunr> i think i've determined my mistake
-    <braunr> glibc has its own variants of the mutex primitives
-    <braunr> and i changed one :/
-    <bddebian> Ah
-    <braunr> it's good news for me :)
-    <braunr> hum no, that's not exactly what i described
-    <braunr> glibc has some stubs, but it's not the problem, the problem is
-      that mutex_lock/unlock are macros, and i changed one of them
-    <braunr> so everything that used that macro inside glibc wasn't changed
-    <braunr> yes!
-    <braunr> my patched hurd now boots :)
-    * braunr relieved
-    <braunr> this experience at least taught me that it's not possible to
-      easily change the singly linked queues of thread (waiting for a mutex or
-      a condition variable) :(
-    <braunr> for now, i'm using a linear search from the start
-    <braunr> so, not only does this patched hurd boot, but i was able to use
-      aptitude, git, build a whole hurd, copy the whole thing, and remove
-      everything, and it still runs fine (whereas usually it would fail very
-      early)
-    * braunr happy
-    <antrik> and vim works fine now?
-    <braunr> err, wait
-    <braunr> this patch does only one thing
-    <braunr> it alters the way condition_signal/broadcast and
-      {hurd_,}condition_wait operate
-    <braunr> currently, condition_signal/broadcast dequeues threads from a
-      condition queue and wake them
-    <braunr> my patch makes these functions only wake the target threads
-    <braunr> which dequeue themselves
-    <braunr> (a necessary requirement to allow clean timeout handling)
-    <braunr> the next step is to fix my hurd_condition_wait patch
-    <braunr> and reapply the whole hurd patch indotrucing io_select_timeout
-    <braunr> introducing*
-    <braunr> then i'll be able to tell you
-    <braunr> one side effect of my current changes is that the linear search
-      required when a thread dequeues itself is ugly
-    <braunr> so it'll be an additional reason to help the pthreads porting
-      effort
-    <braunr> (pthreads have the same sort of issues wrt to timeout handling,
-      but threads are a doubly-linked lists, making it way easier to adjust)
-    <braunr> +on
-    <braunr> damn i'm happy
-    <braunr> 3 days on this stupid bug
-    <braunr> (which is actually responsible for what i initially feared to be a
-      mach bug on non blocking sends)
-    <braunr> (and because of that, i worked on the code to make it sure that 1/
-      waking is truely non blocking and 2/ only one message is required for
-      wakeups
-    <braunr> )
-    <braunr> a simple flag is tested instead of sending in a non blocking way
-      :)
-    <braunr> these improvments should be ported to pthreads some day
-
-[[!taglink open_issue_libpthread]]
-
-    <braunr> ahah !
-    <braunr> view is now FAST !
-    <mel-> braunr: what do you mean by 'view'?
-    <braunr> mel-: i mean the read-only version of vim
-    <mel-> aah
-    <braunr> i still have a few port leaks to fix
-    <braunr> and some polishing
-    <braunr> but basically, the non-blocking select issue seems fixed
-    <braunr> and with some luck, we should get unexpected speedups here and
-      there
-    <mel-> so vim was considerable slow on the Hurd before? didn't know that.
-    <braunr> not exactly
-    <braunr> at first, it wasn't, but the non blocking select/poll calls
-      misbehaved
-    <braunr> so a patch was introduced to make these block at least 1 ms
-    <braunr> then vim became slow, because it does a lot of non blocking select
-    <braunr> so another patch was introduced, not to set the 1ms timeout for a
-      few programs
-    <braunr> youpi: darnassus is already running the patched hurd, which shows
-      (as expected) that it can safely be used with an older libc
-    <youpi> i.e. servers with the additional io_select?
-    <braunr> yes
-    <youpi> k
-    <youpi> good :)
-    <braunr> and the modified cthreads
-    <braunr> which is the most intrusive change
-    <braunr> port leaks fixed
-    <gnu_srs> braunr: Congrats:-D
-    <braunr> thanks
-    <braunr> it's not over yet :p
-    <braunr> tests, reviews, more tests, polishing, commits, packaging
-
-
-#### IRC, freenode, #hurd, 2012-08-04
-
-    <braunr> grmbl, apt-get fails on select in my subhurd with the updated
-      glibc
-    <braunr> otherwise it boots and runs fine
-    <braunr> fixed :)
-    <braunr> grmbl, there is a deadlock in pfinet with my patch
-    <braunr> deadlock fixed
-    <braunr> the sigstate and the condition locks must be taken at the same
-      time, for some obscure reason explained in the cthreads code
-    <braunr> but when a thread awakes and dequeues itself from the condition
-      queue, it only took the condition lock
-    <braunr> i noted in my todo list that this could create problems, but
-      wanted to leave it as it is to really see it happen
-    <braunr> well, i saw :)
-    <braunr> the last commit of my hurd branch includes the 3 line fix
-    <braunr> these fixes will be required for libpthreads
-      (pthread_mutex_timedlock and pthread_cond_timedwait) some day
-    <braunr> after the select bug is fixed, i'll probably work on that with you
-      and thomas d
-
-
-#### IRC, freenode, #hurd, 2012-08-05
-
-    <braunr> eh, i made dpkg-buildpackage use the patched c library, and it
-      finished the build oO
-    <gnu_srs> braunr: :)
-    <braunr> faked-tcp was blocked in a select call :/
-    <braunr> (with the old libc i mean)
-    <braunr> with mine i just worked at the first attempt
-    <braunr> i'm not sure what it means
-    <braunr> it could mean that the patched hurd servers are not completely
-      compatible with the current libc, for some weird corner cases
-    <braunr> the slowness of faked-tcp is apparently inherent to its
-      implementation
-    <braunr> all right, let's put all these packages online
-    <braunr> eh, right when i upload them, i get a deadlock
-    <braunr> this one seems specific to pfinet
-    <braunr> only one deadlock so far, and the libc wasn't in sync with the
-      hurd
-    <braunr> :/
-    <braunr> damn, another deadlock as soon as i send a mail on bug-hurd :(
-    <braunr> grr
-    <pinotree> thou shall not email
-    <braunr> aptitude seems to be a heavy user of select
-    <braunr> oh, it may be due to my script regularly chaning the system time
-    <braunr> or it may not be a deadlock, but simply the linear queue getting
-      extremely large
-
-
-#### IRC, freenode, #hurd, 2012-08-06
-
-    <braunr> i have bad news :( it seems there can be memory corruptions with
-      my io_select patch
-    <braunr> i've just seen an auth server (!) spinning on a condition lock
-      (the internal spin lock), probably because the condition was corrupted ..
-    <braunr> i guess it's simply because conditions embedded in dynamically
-      allocated structures can be freed while there are still threads waiting
-      ...
-    <braunr> so, yes the solution to my problem is simply to dequeue threads
-      from both the waker when there is one, and the waiter when no wakeup
-      message was received
-    <braunr> simple
-    <braunr> it's so obvious i wonder how i didn't think of it earlier :(-
-    <antrik> braunr: an elegant solution always seems obvious afterwards... ;-)
-    <braunr> antrik: let's hope this time, it's completely right
-    <braunr> good, my latest hurd packages seem fixed finally
-    <braunr> looks like i got another deadlock
-    * braunr hangs himselg
-    <braunr> that, or again, condition queues can get very large (e.g. on
-      thread storms)
-    <braunr> looks like this is the case yes
-    <braunr> after some time the system recovered :(
-    <braunr> which means a doubly linked list is required to avoid pathological
-      behaviours
-    <braunr> arg
-    <braunr> it won't be easy at all to add a doubly linked list to condition
-      variables :(
-    <braunr> actually, just a bit messy
-    <braunr> youpi: other than this linear search on dequeue, darnassus has
-      been working fine so far
-    <youpi> k
-    <youpi> Mmm, you'd need to bump the abi soname if changing the condition
-      structure layout
-    <braunr> :(
-    <braunr> youpi: how are we going to solve that ?
-    <youpi> well, either bump soname, or finish transition to libpthread :)
-    <braunr> it looks better to work on pthread now
-    <braunr> to avoid too many abi changes
-
-[[libpthread]].
-
-
-#### IRC, freenode, #hurd, 2012-08-07
-
-    <rbraun_hurd> anyone knows of applications extensively using non-blocking
-      networking functions ?
-    <rbraun_hurd> (well, networking functions in a non-blocking way)
-    <antrik> rbraun_hurd: X perhaps?
-    <antrik> it's single-threaded, so I guess it must be pretty async ;-)
-    <antrik> thinking about it, perhaps it's the reason it works so poorly on
-      Hurd...
-    <braunr> it does ?
-    <rbraun_hurd> ah maybe at the client side, right
-    <rbraun_hurd> hm no, the client side is synchronous
-    <rbraun_hurd> oh by the way, i can use gitk on darnassys
-    <rbraun_hurd> i wonder if it's because of the select fix
-    <tschwinge> rbraun_hurd: If you want, you could also have a look if there's
-      any improvement for these:
-      http://www.gnu.org/software/hurd/open_issues/select.html (elinks),
-      http://www.gnu.org/software/hurd/open_issues/dbus.html,
-      http://www.gnu.org/software/hurd/open_issues/runit.html
-    <tschwinge> rbraun_hurd: And congratulations, again!  :-)
-    <rbraun_hurd> tschwinge: too bad it can't be merged before the pthread port
-      :(
-    <antrik> rbraun_hurd: I was talking about server. most clients are probably
-      sync.
-    <rbraun_hurd> antrik: i guessed :)
-    <antrik> (thought certainly not all... multithreaded clients are not really
-      supported with xlib IIRC)
-    <rbraun_hurd> but i didn't have much trouble with X 
-    <antrik> tried something pushing a lot of data? like, say, glxgears? :-)
-    <rbraun_hurd> why not
-    <rbraun_hurd> the problem with tests involving "a lot of data" is that it
-      can easily degenerate into a livelock
-    <antrik> yeah, sounds about right
-    <rbraun_hurd> (with the current patch i mean)
-    <antrik> the symptoms I got were general jerkiness, with occasional long
-      hangs
-    <rbraun_hurd> that applies to about everything on the hurd
-    <rbraun_hurd> so it didn't alarm me
-    <antrik> another interesting testcase is freeciv-gtk... it reporducibly
-      caused a thread explosion after idling for some time -- though I don't
-      remember the details; and never managed to come up with a way to track
-      down how this happens...
-    <rbraun_hurd> dbus is more worthwhile
-    <rbraun_hurd> pinotree: hwo do i test that ?
-    <pinotree> eh?
-    <rbraun_hurd> pinotree: you once mentioned dbus had trouble with non
-      blocking selects
-    <pinotree> it does a poll() with a 0s timeout
-    <rbraun_hurd> that's the non blocking select part, yes
-    <pinotree> you'll need also fixes for the socket credentials though,
-      otherwise it won't work ootb
-    <rbraun_hurd> right but, isn't it already used somehow ?
-    <antrik> rbraun_hurd: uhm... none of the non-X applications I use expose a
-      visible jerkiness/long hangs pattern... though that may well be a result
-      of general load patterns rather than X I guess
-    <rbraun_hurd> antrik: that's my feeling
-    <rbraun_hurd> antrik: heavy communication channels, unoptimal scheduling,
-      lack of scalability, they're clearly responsible for the generally
-      perceived "jerkiness" of the system
-    <antrik> again, I can't say I observe "general jerkiness". apart from slow
-      I/O the system behaves rather normally for the things I do
-    <antrik> I'm pretty sure the X jerkiness *is* caused by the socket
-      communication
-    <antrik> which of course might be a scheduling issue
-    <antrik> but it seems perfectly possible that it *is* related to the select
-      implementation
-    <antrik> at least worth a try I'd say
-    <rbraun_hurd> sure
-    <rbraun_hurd> there is still some work to do on it though
-    <rbraun_hurd> the client side changes i did could be optimized a bit more
-    <rbraun_hurd> (but i'm afraid it would lead to ugly things like 2 timeout
-      parameters in the io_select_timeout call, one for the client side, the
-      other for the servers, eh)
-
-
-#### IRC, freenode, #hurd, 2012-08-07
-
-    <braunr> when running gitk on [darnassus], yesterday, i could push the CPU
-      to 100% by simply moving the mouse in the window :p
-    <braunr> (but it may also be caused by the select fix)
-    <antrik> braunr: that cursor might be "normal"
-    <rbraunrh> antrik: what do you mean ?
-    <antrik> the 100% CPU
-    <rbraunh> antrik: yes i got that, but what would make it normal ?
-    <rbraunh> antrik: right i get similar behaviour on linux actually
-    <rbraunh> (not 100% because two threads are spread on different cores, but
-      their cpu usage add up to 100%)
-    <rbraunh> antrik: so you think as long as there are events to process, the
-      x client is running
-    <rbraunh> thath would mean latencies are small enough to allow that, which
-      is actually a very good thing
-    <antrik> hehe... sound kinda funny :-)
-    <rbraunh> this linear search on dequeue is a real pain :/
-
-
-#### IRC, freenode, #hurd, 2012-08-09
-
-`screen` doesn't close a window/hangs after exiting the shell.
-
-    <rbraunh> the screen issue seems linked to select :p
-    <rbraunh> tschwinge: the term server may not correctly implement it
-    <rbraunh> tschwinge: the problem looks related to the term consoles not
-      dying
-    <rbraunh> http://www.gnu.org/software/hurd/open_issues/term_blocking.html
-
-[[Term_blocking]].
-
-
-### IRC, freenode, #hurd, 2012-12-05
-
-    <braunr> well if i'm unable to build my own packages, i'll send you the one
-      line patch i wrote that fixes select/poll for the case where there is
-      only one descriptor
-    <braunr> (the current code calls mach_msg twice, each time with the same
-      timeout, doubling the total wait time when there is no event)
-
-
-#### IRC, freenode, #hurd, 2012-12-06
-
-    <braunr> damn, my eglibc patch breaks select :x
-    <braunr> i guess i'll just simplify the code by using the same path for
-      both single fd and multiple fd calls
-    <braunr> at least, the patch does fix the case i wanted it to .. :)
-    <braunr> htop and ping act at the right regular interval
-    <braunr> my select patch is :
-    <braunr>    /* Now wait for reply messages.  */
-    <braunr> -  if (!err && got == 0)
-    <braunr> +  if (!err && got == 0 && firstfd != -1 && firstfd != lastfd)
-    <braunr> basically, when there is a single fd, the code calls io_select
-      with a timeout
-    <braunr> and later calls mach_msg with the same timeout
-    <braunr> effectively making the maximum wait time twice what it should be
-    <pinotree> ouch
-    <braunr> which is why htop and ping are "laggy"
-    <braunr> and perhaps also why fakeroot is when building libc
-    <braunr> well
-    <braunr> when building packages
-    <braunr> my patch avoids entering the mach_msg call if there is only one fd
-    <braunr> (my failed attempt didn't have the firstfd != -1 check, leading to
-      the 0 fd case skipping mach_msg too, which is wrong since in that case
-      there is just no wait, making applications use select/poll for sleeping
-      consume all cpu)
-
-    <braunr> the second is a fix in select (yet another) for the case where a
-      single fd is passed
-    <braunr> in which case there is one timeout directly passed in the
-      io_select call, but then yet another in the mach_msg call that waits for
-      replies
-    <braunr> this can account for the slowness of a bunch of select/poll users
-
-
-#### IRC, freenode, #hurd, 2012-12-07
-
-    <braunr> finally, my select patch works :)
-
-
-#### IRC, freenode, #hurd, 2012-12-08
-
-    <braunr> for those interested, i pushed my eglibc packages that include
-      this little select/poll timeout fix on my debian repository
-    <braunr> deb http://ftp.sceen.net/debian-hurd experimental/
-    <braunr> reports are welcome, i'm especially interested in potential
-      regressions
-
-
-#### IRC, freenode, #hurd, 2012-12-10
-
-    <gnu_srs> I have verified your double timeout bug in hurdselect.c.
-    <gnu_srs>  Since I'm also working on hurdselect I have a few questions
-      about where the timeouts in mach_msg and io_select are implemented.
-    <gnu_srs> Have a big problem to trace them down to actual code: mig magic
-      again?
-    <braunr> yes
-    <braunr> see hurd/io.defs, io_select includes a waittime timeout:
-      natural_t; parameter
-    <braunr> waittime is mig magic that tells the client side not to wait more
-      than the timeout
-    <braunr> and in _hurd_select, you can see these lines :
-    <braunr>             err = __io_select (d[i].io_port, d[i].reply_port,
-    <braunr>                                /* Poll only if there's a single
-      descriptor.  */
-    <braunr>                                (firstfd == lastfd) ? to : 0,
-    <braunr> to being the timeout previously computed
-    <braunr> "to"
-    <braunr> and later, when waiting for replies :
-    <braunr>       while ((msgerr = __mach_msg (&msg.head,
-    <braunr>                                    MACH_RCV_MSG | options,
-    <braunr>                                    0, sizeof msg, portset, to,
-    <braunr>                                    MACH_PORT_NULL)) ==
-      MACH_MSG_SUCCESS)
-    <braunr> the same timeout is used
-    <braunr> hope it helps
-    <gnu_srs> Additional stuff on io-select question is at
-      http://paste.debian.net/215401/
-    <gnu_srs> Sorry, should have posted it before you comment, but was
-      disturbed.
-    <braunr> 14:13 < braunr> waittime is mig magic that tells the client side
-      not to wait more than the timeout
-    <braunr> the waittime argument is a client argument only
-    <braunr> that's one of the main source of problems with select/poll, and
-      the one i fixed 6 months ago
-    <gnu_srs> so there is no relation to the third argument of the client call
-      and the third argument of the server code?
-    <braunr> no
-    <braunr> the 3rd argument at server side is undoubtedly the 4th at client
-      side here
-    <gnu_srs> but for the fourth argument there is?
-    <braunr> i think i've just answered that
-    <braunr> when in doubt, check the code generated by mig when building glibc
-    <gnu_srs> as I said before, I have verified the timeout bug you solved.
-    <gnu_srs> which code to look for RPC_*?
-    <braunr> should be easy to guess
-    <gnu_srs> is it the same with mach_msg()? No explicit usage of the timeout
-      there either.
-    <gnu_srs> in the code for the function I mean.
-    <braunr> gnu_srs: mach_msg is a low level system call
-    <braunr> see
-      http://www.gnu.org/software/hurd/gnumach-doc/Mach-Message-Call.html#Mach-Message-Call
-    <gnu_srs> found the definition of __io_select in: RPC_io_select.c, thanks.
-    <gnu_srs> so the client code to look for wrt RPC_ is in hurd/*.defs? what
-      about the gnumach/*/include/*.defs?
-    <gnu_srs> a final question: why use a timeout if there is a single FD for
-      the __io_select call, not when there are more than one?
-    <braunr> well, the code is obviously buggy, so don't expect me to justify
-      wrong code
-    <braunr> but i suppose the idea was : if there is only one fd, perform a
-      classical synchronous RPC, whereas if there are more use a heavyweight
-      portset and additional code to receive replies
-
-    <youpi> exim4 didn't get fixed by the libc patch, unfortunately
-    <braunr> yes i noticed
-    <braunr> gdb can't attach correctly to exim, so it's probably something
-      completely different
-    <braunr> i'll try the non intrusive mode
-
-
-##### IRC, freenode, #hurd, 2013-01-26
-
-    <braunr> ah great, one of the recent fixes (probably select-eintr or
-      setitimer) fixed exim4 :)
-
-
-#### IRC, freenode, #hurd, 2012-12-11
-
-    <gnu_srs1> braunr: What is the technical difference of having the delay at
-      io_select compared to mach_msg for one FD?
-    <braunr> gnu_srs1: it's a slight optimization
-    <braunr> instead of doing a send and a receive, the same mach_msg call is
-      used for both
-    <braunr> (for L4 guys it wouldn't be considered a slight optimization :))
-
-
-#### IRC, freenode, #hurd, 2012-12-17
-
-    <braunr> tschwinge:
-      http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/select_timeout_for_one_fd
-    <braunr> gnu_srs: talking about that, can you explain :
-    <braunr> "- The pure delay case is much faster now, making it necessary to                                                                                                                                                    
-    <braunr> introduce a delay of 1 msec when the timeout parameter is set to
-      zero.                                                                                                                                              
-    <braunr> "
-    <gnu_srs> I meant poll with zero delay needs a delay to make sure the file
-      descriptors are ready. Testing it now.
-    <braunr> for me, the "pure delay" case is the case where there is no file
-      descriptor
-    <braunr> when the timeout is 0 is the non-blocking case
-    <braunr> and yes, you need 1ms for the non-blocking case when there are
-      file descriptors
-    <gnu_srs> sorry bad wording (again)
-    <braunr> (note however that this last "requirement" is very hurd specific,
-      and due to a design issue)
-    <braunr> the work i did six months ago fixes it, but depends on pthreads
-      for correct performances (or rather, a thread library change, but
-      changing cthreads was both difficult and pointless)
-    <braunr> also, i intend to work on io_poll as a replacement for io_select,
-      that fixes the "message storm" (i love these names) caused by dead-name
-      notifications resulting from the way io_select works
-
-
-#### IRC, freenode, #hurd, 2012-12-19
-
-    <braunr> tschwinge: i've tested the glibc rbraun/select_timeout_for_one_fd
-      branch for a few days on darnassus now, and nothing wrong to report
-
-
-#### IRC, freenode, #hurd, 2012-12-20
-
-    <youpi> braunr: so, shall I commit the single hurd select timeout fix to
-      the debian package?
-    <braunr> youpi: i'd say so yes
-
-
-#### IRC, freenode, #hurd, 2013-01-03
-
-    <braunr> gnu_srs: sorry, i don't understand your poll_timeout patch
-    <braunr> it basically reverts mine for poll only
-    <braunr> but why ?
-    <gnu_srs> braunr: It does not revert your select patch, if there is one FD
-      the timeout is at io_select, if not one the timeout is at mach_msg
-    <braunr> but why does it only concern poll ?
-    <braunr> (and why didn't i do it this way in the first place ?)
-    <braunr> (or maybe i did ?)
-    <gnu_srs> there are problems with a timeout of zero for poll, depending on
-      the implementation the FDs can result in not being ready.
-    <braunr> but that's also true with select
-    <gnu_srs> the cases I've tested only have problems for poll, not select
-    <braunr> we'll have to create test cases for both
-    <braunr> but your solution doesn't hold anyway
-    <braunr> our current workaround for this class of problems is to set a
-      lower bound on the timeout to 1
-    <braunr> (which comes from a debian specific patch)
-    <gnu_srs> see the test code i sent,
-      http://lists.gnu.org/archive/html/bug-hurd/2012-12/msg00043.html,
-      test_poll+select.c
-    <braunr> the patch might be incomplete though
-    <braunr> i know, but your solution is still wrong
-    <braunr> see debian/patches/hurd-i386/local-select.diff in the debian
-      eglibc package
-    <gnu_srs> and in that message I have introduced a minimum timeout for poll
-      of 1ms.
-    <braunr> yes but you shouldn't
-    <braunr> this is a *known* bug, and for now we have a distribution-specific
-      patch
-    <braunr> in other words, we can't commit that crap upstream
-    <gnu_srs> well, according to youpi there is a need for a communication to
-      flag when the FDs are ready, not yet implemented.
-    <braunr> i'm not sure what you mean by that
-    <youpi> I don't understand what you refer to
-    <braunr> there is a need for a full round-trip even in the non blocking
-      case
-    <braunr> which is implemented in one of my hurd branches, but awaits
-      pthreads integration for decent scalability
-    <youpi> the only difference between poll and select is that select can stop
-      the loop on error, while poll needs to continue
-    <braunr> youpi: don't you think the glibc select patch is incomplete ?
-    <youpi> incomplete in what direction?
-    <youpi> the minimum 1ms delay is a completely bogus workaround
-    <gnu_srs> youpi:
-      http://lists.gnu.org/archive/html/bug-hurd/2012-11/msg00001.html
-    <youpi> so I wouldn't say it's even completing anything :)
-    <braunr> hm no never mind, it's not
-    <braunr> i thought it missed some cases where the delay made sense, but no
-    <braunr> the timeout can only be 0 if the timeout parameter is non NULL
-    <braunr> gnu_srs: during your tests, do you run with the debian eglibc
-      package (including your changes), or from the git glibc ?
-    <gnu_srs> I run with -37, -38, with my minimum poll changes, my 3 cases,
-      and 3 case-poll updates.
-    <braunr> so you do have the debian patches
-    <braunr> so you normally have this 1ms hack
-    <braunr> which means you shouldn't need to make the poll case special
-    <gnu_srs> A admit the 1ms patch is not possible to submit upstream, but it
-      makes things work (and youpi use it for vim)
-    <braunr> i'll try to reproduce your ntpdate problem with -38 when i have
-      some time
-    <braunr> uh, no, vim actually doesn't use the hack :p
-    <youpi> gnu_srs: it's the contrary: we have to avoid it for vim
-    <gnu_srs>  if (strcmp(program_invocation_short_name, "vi") &&
-      strcmp(program_invocation_short_name, "vim") &&
-      strcmp(program_invocation_short_name, "vimdiff") && !to)
-    <gnu_srs>         to = 1;
-    <youpi> that does what we are saying
-    <braunr> strcmp returns 0 on equality
-    <gnu_srs> aha, OK then
-    <gnu_srs> I don't have that hack in my code. I have tested vim a little,
-      but cannot judge, since I'm not a vi user.
-    <braunr> you don't ?
-    <braunr> you should have it if the package patches were correctly applied
-    <gnu_srs> Maybe somebody else could compile a libc with the 3-split code to
-      test it out?
-    <braunr> that's another issue
-    <gnu_srs> I mean the patch I sent to the list, there the vi{m} hack is not
-      present.
-    <braunr> well obviously
-    <braunr> but i'm asking about the poll_timeout one
-    <gnu_srs> A, OK, it's very easy to test that version too but currently -38
-      maybe has a regression due to some other patch.
-    <braunr> that's another thing we're interested in
-    <gnu_srs> Unfortunately it takes a _long_ time to build a new version of
-      libc (several hours...)
-    <braunr> -38 is already built
-    <gnu_srs> yes, but removing patches one by one and rebuilding.
-    <braunr> but then, the "regression" you mention concerns a package that
-      wasn't really working before
-    <braunr> removing ?
-    <braunr> ah, to identify the trouble carrying one
-    <gnu_srs> ntpdate works with -37, no problem...
-    <gnu_srs> but not with -38
-    <braunr> again, trace it with -38
-    <braunr> to see on what it blocks
-    <gnu_srs> as I wrote yesterday gdb hangs the box hard and rpctrace bugs
-      out, any ideas?
-    <youpi> printf
-    <braunr> gdb from a subhurd
-    <gnu_srs> I'm suspecting the setitimer patch: Without it gdb ntpdate does
-      not freeze hard any longer, bt full: http://paste.debian.net/221491/
-    Program received signal SIGINT, Interrupt.
-    0x010477cc in mach_msg_trap ()
-        at /usr/src/kernels/eglibc/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    2       kernel_trap (__mach_msg_trap,-25,7)
-    (gdb) thread apply all bt full
-    
-    Thread 6 (Thread 3158.6):
-    #0  0x010477cc in mach_msg_trap ()
-        at /usr/src/kernels/eglibc/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x01047fc9 in __mach_msg (msg=0x52fd4, option=1282, send_size=0, 
-        rcv_size=0, rcv_name=132, timeout=100, notify=0) at msg.c:110
-            ret = <optimized out>
-    #2  0x010ec3a8 in timer_thread () at ../sysdeps/mach/hurd/setitimer.c:90
-            err = <optimized out>
-            msg = {header = {msgh_bits = 4608, msgh_size = 32, 
-                msgh_remote_port = 0, msgh_local_port = 132, msgh_seqno = 78, 
-                msgh_id = 23100}, return_code = 17744699}
-    
-    setitimer.c:90
-          err = __mach_msg (&msg.header,
-                            MACH_RCV_MSG|MACH_RCV_TIMEOUT|MACH_RCV_INTERRUPT,
-                            0, 0, _hurd_itimer_port,
-                            _hurd_itimerval.it_value.tv_sec * 1000 +
-                            _hurd_itimerval.it_value.tv_usec / 1000,
-                            MACH_PORT_NULL);
-
-[[alarm_setitimer]].
-
-    <braunr> gdb ?
-    <braunr> i thought ntpdate was the program freezing
-    <gnu_srs> the freeze is due to -38
-    <braunr> yes we know that
-    <braunr> but why do you say "gdb ntpdate" instead of "ntpdate" ?
-    <gnu_srs> yes, ntpdate freezes: without gdb kill -9 is OK, with gdb it
-      freezes hard (with setitimer pacth).
-    <braunr> we don't care much about the kill behaviour
-    <braunr> ntpdate does indeed makes direct calls to setitimer
-    <gnu_srs> without the setitimer patch: without gdb ntpdate freezes (C-c is
-      OK), with gdb C-c gives the paste above
-    <braunr> sorry i don't understand
-    <braunr> *what* is the problem ?
-    <youpi> there are two of them
-    <youpi> ntpdate freezing
-    <youpi> gdb freezing
-    <braunr> ok
-    <youpi> he's saying gdb freezing is due to the setitimer patch
-    <braunr> yes that's what i understand now
-    <braunr> what he said earlier made me think ntpdate was freezing with -38
-    <gnu_srs> better: ntpdate hangs, gdb ntpdate freezes (with the setitimer
-      patch)
-    <braunr> what's the behaviour in -37, and then what is the behaviour with
-      -38 ?
-    <braunr> (of both actions, so your answer should give us four behaviours)
-    <youpi> gnu_srs: what is the difference between "hangs" and "freezes" ?
-    <gnu_srs> -37 no problem, both with and without gdb.
-    <braunr> you mean ntpdate doesn't freeze with -37, and does with -38 ?
-    <gnu_srs> hangs: kill -9 is sufficient, freezes: reboot, checking file
-      system etc
-    <braunr> and i really mean ntpdate, not gdb whatever
-    <gnu_srs> the ntpdate hang (without the setitimer patch) in -38 can be due
-      to the poll stuff: Have to check further with my poll patch...
-
-
-#### IRC, freenode, #hurd, 2013-01-04
-
-    <gnu_srs> Summary of the eglibc-2.13-38 issues: without the
-      unsubmitted-setitimer_fix.diff patch and with
-    <gnu_srs> my poll_timeout.patch fix in
-      http://lists.gnu.org/archive/html/bug-hurd/2012-12/msg00042.html
-    <gnu_srs> ntpdate works again :)
-    <gnu_srs> please consider reworking the setitimer patch and add a poll case
-      in hurdselect.c:-D 
-    <gnu_srs> Additional info: vim prefers to use select before poll,. With the
-      proposed changes (small,3-split),
-    <gnu_srs> only poll is affected by the 1ms default timeout, i.e. the
-      current vi hack is no longer needed.
-    <braunr> gnu_srs: the setitimer patch looks fine, and has real grounds
-    <braunr> gnu_srs: your poll_timeout doesn't
-    <braunr> so unless you can explain where the problem comes from, we
-      shouldn't remove the setitimer patch and add yours
-    <braunr> in addition
-    <braunr> 09:30 < gnu_srs> only poll is affected by the 1ms default timeout,
-      i.e. the current vi hack is no longer needed.
-    <braunr> that sentence is complete nonsense
-    <braunr> poll and select are implemented using the same rpc, which means
-      they're both broken
-    <braunr> if the vi hack isn't needed, it means you broke every poll user
-    <braunr> btw, i think your ntpdate issue is very similar to the gitk one
-    <braunr> gitk currently doesn't work because of select/poll
-    <braunr> it does work fine with my hurd select branch though
-    <braunr> which clearly shows a more thorough change is required, and your
-      hacks won't do any good (you may "fix" ntpdate, and break many other
-      things)
-    <gnu_srs> braunr: Why don't you try ntpdate yourself on -38 (none of my
-      patches applied)
-    <braunr> you're missing the point
-    <braunr> the real problem is the way select/poll is implemented, both at
-      client *and* server sides
-    <gnu_srs> 09:30 etc: The current implementation is slower than the 3-way
-      patch. Therefore it in not needed in the current implementation (I didn't
-      propose that either)
-    <braunr> hacks at the client side only are pointless, whatever you do
-    <braunr> slower ?
-    <braunr> it's not about performance but correctness
-    <braunr> your hack *can't* solve the select/poll correctness issue
-    <gnu_srs> yes, slower on my kvm boxes...
-    <braunr> so it's normal that ntpdate and other applications such as gitk
-      are broken
-    <braunr> if you try to fix it by playing with the timeout, you'll just
-      break the applications that were fixed in the past by playing with the
-      timeout another way
-    <braunr> can you understand that ?
-    <gnu_srs> forget the timeout default, it's a side issue.
-    <braunr> the *real* select/poll issue is that non blocking calls
-      (timeout=0) don't have the time to make a full round trip at the server
-    <braunr> no it's not, it's the whole problem
-    <braunr> some applications work with a higher timeout, some like gitk don't
-    <braunr> ntpdate might act just the same
-    <gnu_srs> yes of course, and I have not addressed this problem either, I'm
-      mostly interested in the 3-way split.
-    <braunr> well, it looks like you're trying to ..
-    <gnu_srs> to be able to submit my poll patches (not yet published)
-    <braunr> i suggest you postpone these changes until the underlying
-      implementation works
-    <braunr> i strongly suspect the split to be useless
-    <braunr> we shouldn't need completely different paths just for this
-      conformance issue
-    <braunr> so wait until select/poll is fixed, then test again
-    <gnu_srs> Read the POSIX stuff: poll and select are different.
-    <braunr> i know
-    <braunr> their expected behaviour is
-    <braunr> that's what needs to be addressed
-    <braunr> but you can't do that now, because there are other bugs in the way
-    <braunr> so you'll have a hard time making sure your changes do fix your
-      issues, because the problems might be cause by the other problems
-    <gnu_srs> since you are the one who knows best, why don't you implement
-      everything yourself.
-    <braunr> well, i did
-    <braunr> and i'm just waiting for the pthreads hurd to spread before
-      adapting my select branch
-
-[[libpthread]].
-
-    <braunr> it won't fix the conformance issue, but it will fix the underlying
-      implementation (the rpc)
-    <braunr> and then you'll have reliable results for the tests you're
-      currently doing
-    <gnu_srs> why not even trying out the cases I found to have problems??
-    <braunr> because i now know why you're observing what you're observing
-    <braunr> i don't need my eyes to see it to actually imagine it clerly
-    <braunr> when i start gitk and it's hanging, i'm not thinking 'oh my, i
-      need to hack glibc select/poll !!!'
-    <braunr> because i know the problem
-    <braunr> i know what needs to be done, i know how to do it, it will be done
-      in time
-    <braunr> please try to think the same way ..
-    <braunr> you're fixing problems by pure guessing, without understanding
-      what's really happenning
-    <gnu_srs> (10:59:17 AM) braunr: your hack *can't* solve the select/poll
-      correctness issue: which hack?
-    <braunr> "please consider removing setitimer because it blocks my ntpdate"
-    <braunr> gnu_srs: all your select related patches
-    <braunr> the poll_timeout, the 3-way split, they just can't
-    <braunr> changes need to be made at the server side too
-    <braunr> you *may* have fixed the conformance issue related to what is
-      returned, but since it get mixed with the underlying implementation
-      problems, your tests aren't reliable
-    <gnu_srs> well some of the test code is from gnulib, their code is not
-      reliable?
-    <braunr> their results aren't
-    <braunr> why is that so hard to understand for you ?
-    <gnu_srs> (11:08:05 AM) braunr: "please consider removing setitimer because
-      it blocks my ntpdate": It's not my ntpdate, it's a program that fails to
-      run on -38, but does on -37!
-    <braunr> it doesn't mean glibc -37 is right
-    <braunr> it just means the ntpdate case seems to be handled correctly
-    <braunr> a correct implementation is *ALWAYS* correct
-    <braunr> if there is one wrong case, it's not, and we know our select/poll
-      implementation is wrong
-    <gnu_srs> no of course not, and the ntpdate implementation is not correct?
-      file a bug upstream then.
-    <braunr> you're starting to say stupid things again
-    <braunr> ntpdate and gnulib tests can't be right if they use code that
-      isn't right
-    <braunr> it doesn't mean they'll always fail either, the programs that fail
-      are those for which select/poll behaves wrong
-    <braunr> same thing for setitimer btw
-    <braunr> we know it was wrong, and i think it was never working actually
-    <gnu_srs> where are the missing test cases then? maybe you should publish
-      correct code so we can try it out?
-    <braunr> i have, but there are dependencies that prevent using it right now
-    <braunr> which is why i'm waiting for pthreads hurd to spread
-    <braunr> pthreads provide the necessary requirements for select to be
-      correctly implemented at server side
-    <gnu_srs> well conformance with your code could be tested on Linux,
-      kFreeBSD, etc
-    <braunr> ?
-    <braunr> i'm not writing test units
-    <gnu_srs> /code/test code/
-    <braunr> the problem is *NOT* the test code
-    <braunr> the problem is some of our system calls
-    <braunr> it's the same for ntpdate and gitk and all other users
-    <gnu_srs> then the gnulib, ntpdate, gitk code is _not_ wrong
-    <braunr> no, but their execution is, and thus their results
-    <braunr> which is ok, they're tests
-    <braunr> they're here precisely to tell us if one case works
-    <braunr> they must all pass to hope their subject is right
-    <braunr> so, again, since there are several problems with our low level
-      calls, you may have fixed one, but still suffer from others
-    <braunr> so even if you did fix something, you may not consider the test
-      failure as an indication that your fix is wrong
-    <braunr> but if you try to make your changes fix everything just to have
-      results that look valid, it's certain to fail, since you only fix the
-      client side, and it's *known* the server side must be changed too
-    <gnu_srs> do you consider unsubmitted-single-hurdselect-timeout.diff and
-      local-select.diff a hack or not?
-    <braunr> the first isn't, since it fixes the correctness of the call for
-      one case, at the cost of some performance
-    <braunr> the second clearly is
-    <braunr> which is the difference between unsubmitted-* and local-*
-    <gnu_srs> and my proposal to modify the first is a hack?
-    <braunr> yes
-    <braunr> it reverts a valid change to "make things work" whereas we know
-      the previous behaviour was wrong
-    <braunr> that's close to the definition of a hack
-    <gnu_srs> "make things work" meaning breaking some applications?
-    <braunr> yes
-    <braunr> in this case, those using poll with one file descriptor and
-      expecting a timeout, not twice the timeout
-    <braunr> well, your change isn't really a revert
-    <braunr> hum yes actually it is
-    <gnu_srs> the timeout is correct
-    <braunr> no, it looks correct
-    <braunr> how did you test it ?
-    <braunr> and same question as yesterday: why only poll ?
-    <gnu_srs> see the code I mentioned before
-    <braunr> no i won't look
-    <braunr> it doesn't explain anything
-    <gnu_srs> I have not found any problems with select, only poll (yes, this
-      is a user perspective)
-    <braunr> that's what i call "pure guessing"
-    <braunr> you just can't explain why it fixes things
-    <braunr> because you don't know
-    <braunr> you don't understand what's really happening in the system
-    <braunr> there is a good idea in your change
-    <braunr> but merely for performance, not correctness
-    <braunr> (your change makes it possible to save the mach_msg receive if the
-      io_select blocked, which is good, but not required)
-
-See also [[alarm_setitimer]].
-
-
-#### IRC, freenode, #hurd, 2013-01-22
-
-    <gnu_srs> youpi: Maybe it's overkill to have a separate case for DELAY; but
-      it enhances readability (and simplifies a lot too)
-    <youpi> but it reduces factorization
-    <youpi> if select is already supposed to behave the same way as delay,
-      there is no need for a separate code
-    <gnu_srs> OK; I'll make a two-way split then. What about POLL and nfds=0,
-      timeout !=0?
-    <braunr> gnu_srs: handle nfds=0 as a pure timeout as the linux man page
-      describes
-    <braunr> it makes sense, and as other popular systems do it, it's better to
-      do it the same way
-    <braunr> and i disagree with you, factorization doesn't imply less
-      readability
-    <gnu_srs> So you agree with me to have a special case for DELAY?
-    <gnu_srs> Coding style is a matter of taste: for me case a: case b: etc is
-      more readable than "if then elseif then else ..."
-    <braunr> it's not coding style
-    <braunr> avoiding duplication is almost always best
-    <braunr> whatever the style
-    <braunr> i don't see the need for a special delay case
-    <braunr> it's the same mach_msg call
-    <braunr> (for now)
-    <braunr> gnu_srs: i'd say the only reason to duplicate is when you can't do
-      otherwise
-    <gnu_srs> ways of coding then... And I agree with the idea of avoiding code
-      duplication, ever heard of Literate Programming
-    <braunr> we'll need a "special case" when the timeout is handled at the
-      server side, but it's like two lines ..
-
-
-#### IRC, freenode, #hurd, 2013-02-11
-
-    <youpi> braunr: the libpthread hurd_cond_timedwait_np looks good to me
-
-
-##### IRC, freenode, #hurd, 2013-02-15
-
-    <youpi> braunr: does cond_timedwait_np depend on the cancellation fix?
-    <braunr> yes
-    <youpi> ok
-    <braunr> the timeout fix
-    <youpi> so I also have to pull that into my glibc build
-    <braunr> (i fixed cancellation too because the cleanup routine had to be
-      adjusted anyway
-    <braunr> )
-    <youpi> ah, and I need the patches hurd package too
-    <braunr> if unsure, you can check my packages
-    <youpi> ok, not for tonight then
-    <braunr> i listed the additional patches in the changelog
-    <youpi> yep, I'll probably use them
-
-
-#### IRC, freenode, #hurd, 2013-02-11
-
-    <youpi> braunr: I don't understand one change in glibc:
-    <youpi> - err = __io_select (d[i].io_port, d[i].reply_port, 0, &type);
-    <youpi> + err = __io_select (d[i].io_port, d[i].reply_port, type);
-    <braunr> youpi: the waittime parameter ahs been removed
-    <braunr> has*
-    <youpi> where? when?
-    <braunr> in the hurd branch
-    <youpi> in the defs?
-    <braunr> yes
-    <youpi> I don't see this change
-    <youpi> only the addition of io_select_timeout
-    <braunr> hum
-    <youpi> also, io_select_timeout should be documented along io_select in
-      hurd.texi
-    <braunr> be6e5b86bdb9055b01ab929cb6b6eec49521ef93
-    <braunr>     Selectively compile io_select{,_timeout} as a routine
-    <braunr>     * hurd/io.defs (io_select_timeout): Declare as a routine if
-    <braunr>     _HURD_IO_SELECT_ROUTINE is defined, or a simpleroutine
-      otherwise.
-    <braunr>     (io_select): Likewise. In addition, remove the waittime
-      timeout parameter.
-    <youpi> ah, it's in another commit
-    <braunr> yes, perhaps misplaced
-    <braunr> that's the kind of thing i want to polish
-    <braunr> my main issue currently is that time_data_t is passed by value
-    <braunr> i'm trying to pass it by address
-    <youpi> I don't know the details of routine vs simpleroutine
-    <braunr> it made sense for me to remove the waittime parameter at the same
-      time as adding the _HURD_IO_SELECT_ROUTINE macro, since waittime is what
-      allows glibc to use a synchronous RPC in an asynchronous way
-    <youpi> is it only a matter of timeout parameter?
-    <braunr> simpleroutine sends a message
-    <braunr> routine sends and receives
-    <braunr> by having a waittime parameter, _hurd_select could make io_select
-      send a message and return before having a reply
-    <youpi> ah, that's why in glibc you replaced MACH_RCV_TIMED_OUT by 0
-    <braunr> yes
-    <youpi> it seems a bit odd to have a two-face call
-    <braunr> it is
-    <youpi> can't we just keep it as such?
-    <braunr> no
-    <youpi> damn
-    <braunr> well we could, but it really wouldn't make any sense
-    <youpi> why not?
-    <braunr> because the way select is implemented implies io_select doesn't
-      expect a reply
-    <braunr> (except for the single df case but that's an optimization)
-    <braunr> fd*
-    <youpi> that's how it is already, yes?
-    <braunr> yes
-    <braunr> well yes and no
-    <braunr> that's complicated :)
-    <braunr> there are two passes
-    <braunr> let me check before saying anything ;p
-    <youpi> :)
-    <youpi> in the io_select(timeout=0) case, can it ever happen that we
-      receive an answer?
-    <braunr> i don't think it is
-    <braunr> you mean non blocking right ?
-    <braunr> not infinite timeout
-    <youpi> I mean calling io_select with the timeout parameter being set to 0
-    <braunr> so yes, non blocking
-    <braunr> no, i think we always get MACH_RCV_TIMED_OUT
-    <youpi> for me non-blocking can mean a lot of things :)
-    <braunr> ok
-    <braunr> i was thinking mach_msg here
-    <braunr> ok so, let's not consider the single fd case
-    <braunr> the first pass simply calls io_select with a timeout 0 to send
-      messages
-    <youpi> I don't think it's useful to try to optimize it
-    <youpi> it'd only lead to bugs :)
-    <braunr> me neither
-    <braunr> yes
-    <youpi> (as was shown :) )
-    <braunr> what seems useful to me however is to optimize the io_select call
-    <braunr> with a waittime parameter, the generated code is an RPC (send |
-      receive)
-    <braunr> whereas, as a simpleroutine, it becomes a simple send
-    <youpi> ok
-    <youpi> my concern is that, as you change it, you change the API of the
-      __io_select() function
-    <youpi> (from libhurduser)
-    <braunr> yes but glibc is the only user
-    <braunr> and actually no
-    <braunr> i mean
-    <braunr> i change the api at the client side only
-    <youpi> that's what I mean
-    <braunr> remember that io.Defs is almost full
-    <youpi> "full" ?
-    <braunr> i'm almost certain it becomes full with io_select_timeout
-    <braunr> there is a practical limit of 100 calls per interface iirc
-    <braunr> since the reply identifiers are request + 100
-    <youpi> are we at it already?
-    <braunr> i remember i had problems with it so probably
-    <youpi> but anyway, I'm not thinking about introducing yet another RPC
-    <youpi> but get a reasonable state of io_select
-    <braunr> i'l have to check that limit
-    <braunr> it looks wrong now
-    <braunr> or was it 50
-    <braunr> i don't remember :/
-    <braunr> i understand
-    <braunr> but what i can guarantee is that, while the api changes at the
-      client side, it doesn't at the server side
-    <youpi> ideally, the client api of io_select could be left as it is, and
-      libc use it as a simpleroutine
-    <youpi> sure, I understand that
-    <braunr> which means glibc, whether patched or not, still works fine with
-      that call
-    <braunr> yes it could
-    <braunr> that's merely a performance optimization
-    <youpi> my concern is that an API depends on the presence of
-      _HURD_IO_SELECT_ROUTINE, and backward compatibility being brought by
-      defining it! :)
-    <braunr> yes
-    <braunr> i personally don't mind much
-    <youpi> I'd rather avoid the clutter
-    <braunr> what do you mean ?
-    <youpi> anything that avoids this situation
-    <youpi> like just using timeout = 0
-    <braunr> well, in that case, we'll have both a useless timeout at the
-      client side
-    <braunr> and another call for truely passing a timeout
-    <braunr> that's also weird
-    <youpi> how so a useless timeout at the client side?
-    <braunr> 22:39 < youpi> - err = __io_select (d[i].io_port, d[i].reply_port,
-      0, &type);
-    <braunr> 0 here is the waittime parameter
-    <youpi> that's a 0-timeout
-    <braunr> and it will have to be 0
-    <youpi> yes
-    <braunr> that's confusing
-    <youpi> ah, you mean the two io_select calls?
-    <braunr> yes
-    <youpi> but isn't that necessary for the several-fd case, anyway?
-    <braunr> ?
-    <braunr> if the io_select calls are simple routines, this useless waittime
-      parameter can just be omitted like i did
-    <youpi> don't we *have* to make several calls when we select on several
-      fds?
-    <braunr> suure but i don't see how it's related
-    <youpi> well then I don't see what optimization you are doing then
-    <youpi> except dropping a parameter
-    <youpi> which does not bring much to my standard :)
-    <braunr> a simpleroutine makes mach_msg take a much shorter path
-    <youpi> that the 0-timeout doesn't take?
-    <braunr> yes
-    <braunr> it's a send | receive
-    <youpi> ok, but that's why I asked before
-    <braunr> so there are a bunch of additional checks until the timeout is
-      handled
-    <youpi> whether timeout=0 means we can't get a receive
-    <youpi> and thus the kernel could optimize
-    <braunr> that's not the same thing :)
-    <youpi> ok
-    <braunr> it's a longer path to the same result
-    <youpi> I'd really rather see glibc building its own private simpleroutine
-      version of io_select
-    <youpi> iirc we already have such kind of thing
-    <braunr> ok
-    <braunr> well there are io_request and io_reply defs
-    <braunr> but i haven't seen them used anywhere
-    <braunr> but agreed, we should do that
-    <youpi> braunr: the prototype for io_select seems bogus in the io_request,
-      id_tag is no more since ages :)
-    <braunr> youpi: yes
-    <braunr> youpi: i'll recreate my hurd branch with only one commit
-    <braunr> without the routine/simpleroutine hack
-    <braunr> and with time_data_t passed by address
-    <braunr> and perhaps other very minor changes
-    <youpi> braunr: the firstfd == -1 test needs a comment
-    <braunr> or better, i'll create a v2 branch to make it easy to compare them
-    <braunr> ok
-    <youpi> braunr: actually it's also the other branch of the if which needs a
-      comment: "we rely on servers implementing the timeout"
-    <braunr> youpi: ok
-    <youpi> -                 (msg.success.result & SELECT_ALL) == 0)
-    <youpi> why removing that test?
-    <youpi> you also need to document the difference between got and ready
-    <braunr> hm i'll have to remember
-    <braunr> i wrote this code like a year ago :)
-    <braunr> almost
-    <youpi> AIUI, got is the number of replies
-    <braunr> but i think it has to do with error handling
-    <braunr> and
-    <braunr> +                       if (d[i].type)
-    <braunr> +                         ++ready;
-    <youpi> while ready is the number of successful replies
-    <braunr> is what replaces it
-    <braunr> youpi: yes
-    <braunr> the poll wrapper already normalizes the timeout parameter to
-      _hurd_select
-    <braunr> no you probably don't
-    <braunr> the whole point of the patch is to remove this ugly hack
-    <braunr> youpi: ok so
-    <braunr> 23:24 < youpi> -                 (msg.success.result & SELECT_ALL)
-      == 0)
-    <braunr> when a request times out
-    <youpi> ah, right
-    <braunr> we could get a result with no event
-    <braunr> and no error
-    <braunr> and this is what makes got != ready
-    <youpi> tell that to the source, not me :)
-    <braunr> sure :)
-    <braunr> i'm also saying it to myself
-    <braunr> ... :)
-    <youpi> right, using io_select_request() is only an optimization, which we
-      can do later
-    <braunr> what i currently do is remove the waittime parameter from
-      io_select
-    <braunr> what we'll do instead (soon) is let the parameter there to keep
-      the API unchancged
-    <braunr> but always use a waittime of 0
-    <braunr> to make the mach_msg call non blocking
-    <braunr> then we'll try to get the io_request/io_reply definitions back so
-      we can have simpleroutines (send only) version of the io RPCs
-    <braunr> and we'll use io_select_request (without a waittime)
-    <braunr> youpi: is that what you understood too ?
-    <youpi> yes
-    <youpi> (and we can do that later)
-    <braunr> gnu_srs: does it make more sense for you ?
-    <braunr> this change is quite sparsed so it's not easy to get the big
-      picture
-    <braunr> sparse*
-    <braunr> it requires changes in libpthread, the hurd, and glibc
-    <youpi> the libpthread change can be almost forgotten
-    <youpi> it's just yet another cond_foo function :)
-    <braunr> well not if he's building his own packages
-    <youpi> right
-    <youpi> ok, apart from the io_select_request() and documenting the newer
-      io_select_timeout(), the changes seem good to me
-    <braunr> youpi: actually, a send | timeout takes the slow path in mach_msg
-    <braunr> and i actually wonder if send | receive | timeout = 0 can get a
-      valid reply from the server
-    <braunr> but the select code already handles that so it shouldn't be much
-      of a problem
-    <youpi> k
-
-
-##### IRC, freenode, #hurd, 2013-02-12
-
-    <braunr> hum
-    <braunr> io_select_timeout actually has to be a simpleroutine at the client
-      side :/
-    <braunr> grmbl
-    <youpi> ah?
-    <braunr> otherwise it blocks
-    <youpi> how so?
-    <braunr> routines wait for replies
-    <youpi> even with timeout 0?
-    <braunr> there is no waittime for io_select_timeout
-    <braunr> adding one would be really weird
-    <youpi> oh, sorry, I thought you were talking about io_select
-    <braunr> it would be more interesting to directly use
-      io_select_timeout_request
-    <braunr> but this means additional and separate work to make the
-      request/reply defs up to date
-    <braunr> and used
-    <braunr> personally i don't mind, but it matters for wheezy
-    <braunr> youpi: i suppose it's not difficult to add .defs to glibc, is it ?
-    <braunr> i mean, make glibc build the stub code
-    <youpi> it's probably not difficult indeed
-    <braunr> ok then it's better to do that first
-    <youpi> yes
-    <youpi> there's faultexec for instance in hurd/Makefile
-    <braunr> ok
-    <youpi> or rather, apparently it'd be simply user-interfaces
-    <youpi> it'll probably be linked into libhurduser
-    <youpi> but with an odd-enough name it shouldn't matter
-    <braunr> youpi: adding io_request to the list does indeed build the RPCs :)
-    <braunr> i'll write a patch to sync io/io_reply/io_request
-    <braunr> youpi: oh by the way, i'm having a small issue with the
-      io_{reply,request} interfaces
-    <braunr> the generated headers both share the same enclosing macro
-      (_io_user)
-    <braunr> so i'm getting compiler warning
-    <braunr> s
-    <youpi> we could fix that quickly in mig, couldn't we?
-    <braunr> youpi: i suppose, yes, just mentioning
-
-
-##### IRC, freenode, #hurd, 2013-02-19
-
-    <youpi> in the hurdselect.c code, I'd rather see it td[0]. rather than
-      td->
-    <braunr> ok
-    <youpi> otherwise it's frownprone
-    <youpi> (it has just made me frown :) )
-    <braunr> yes, that looked odd to me too, but at the same time, i didn't
-      want it to seem to contain several elements
-    <youpi> I prefer it to look like there could be several elements (and then
-      the reader has to find out how many, i.e. 1), rather than it to look like
-      the pointer is not initialized
-    <braunr> right
-    <youpi> I'll also rather move that code further
-    <youpi> so the preparation can set timeout to 0
-    <youpi> (needed for poll)
-    <youpi> how about turning your branch into a tg branch?
-    <braunr> feel free to add your modifications on top of it
-    <braunr> sure
-    <youpi> ok
-    <youpi> I'll handle these then
-    <braunr> youpi: i made an updated changelog entry in the
-      io_select_timeout_v3 branch
-    <youpi> could you rather commit that to the t/io_select_timeout branch I've
-      just created?
-    <braunr> i mean, i did that a few days ago
-    <youpi> (in the .topmsg file)
-    <youpi> ah
-    <youpi> k
-
-
-##### IRC, freenode, #hurd, 2013-02-26
-
-    <braunr> youpi: i've just pushed a rbraun/select_timeout_pthread_v4 branch
-      in the hurd repository that includes the changes we discussed yesterday
-    <braunr> untested, but easy to compare with the previous version
-
-
-##### IRC, freenode, #hurd, 2013-02-27
-
-    <youpi> braunr: io_select_timeout seems to be working fine here
-    <youpi> braunr: I feel like uploading them to debian-ports, what do you
-      think?
-    <braunr> youpi: the packages i rebuild last night work fine too
-
-
-# See Also
-
-See also [[select_bogus_fd]] and [[select_vs_signals]].
diff --git a/open_issues/select_bogus_fd.mdwn b/open_issues/select_bogus_fd.mdwn
deleted file mode 100644
index 17aced4a..00000000
--- a/open_issues/select_bogus_fd.mdwn
+++ /dev/null
@@ -1,55 +0,0 @@
-[[!meta copyright="Copyright © 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]]
-
-
-# Python
-
-IRC, freenode, #hurd, 2011-04-13
-
-    <abeaumont> ok, cause of first python testsuite failure located, now the
-      hard part, how to best fix it :)
-    <abeaumont> how to redesign the code to avoid the problem... that's the
-      hard part, mostly cause i lack contextual info
-    <abeaumont> tschwinge: the problem is pretty much summarized by this
-      comment in _hurd_select (in glibc): /* If one descriptor is bogus, we
-      fail completely.  */
-    <pochu> does POSIX say anything about what to do if one fd is invalid?
-    <pochu> and the other question is why python is calling select() with an
-      invalid fd
-    <abeaumont> pochu: yep, it says it should not fail completelly
-    <pochu> then that's our bug :)
-    <pinotree> abeaumont: just note that (at least on debian) some tests may
-      hang forever or cause hurd/mach to die
-    <pinotree> abeaumont: see in the debian/rules of the packaging of each
-      pythonX.Y source
-    <pinotree> ... there's a list of the tests excluded from the test suite run
-    <abeaumont> well, to be precise, python has a configure check for
-      'broken_poll' which hurd fails, and therefore python's select module is
-      not built, and anything depending on it fails
-    <abeaumont> broken_poll checks exactly for that posix requirement
-    <abeaumont> the reason for python using a non-existant
-      descriptor... unknown :D
-    <pochu> we should fix select to not fail miserably in that case
-    <pinotree> abeaumont: we have a patch to fix the broken poll check to
-      actually disable the poll module
-    <pochu> pinotree: but the proper fix is to fix select(), which is what
-      abeaumont is looking at
-    <abeaumont> pinotree: i'd say that's exactly what python's configure check
-      does itself -- disable building the select module
-    <pochu> abeaumont: what pinotree means is that the check is broken, see
-      http://patch-tracker.debian.org/patch/series/view/python2.6/2.6.6-8/hurd-broken-poll.diff
-    <pinotree> yes, the configure check for poll does the check, but not
-      everything of the poll module gets disabled (and you get a build failure)
-
----
-
-See also [[select]] and [[select_vs_signals]].
diff --git a/open_issues/select_vs_signals.mdwn b/open_issues/select_vs_signals.mdwn
deleted file mode 100644
index db616acb..00000000
--- a/open_issues/select_vs_signals.mdwn
+++ /dev/null
@@ -1,62 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2013 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]]
-
-
-# `sudo`
-
-`sudo [task]` hands after finishing `[task]`.
-
-IRC, freenode, #hurd, 2011-04-02
-
-    <youpi> the sudo bug is select() not being able to get interrupted by
-      signals
-
-
-# IRC, freenode, #hurd, 2013-01-05
-
-In context of [[alarm_setitimer]].
-
-    <youpi> it's a know issue in select
-    <youpi> it's not interruptible by a SIGALRM for instance
-    <youpi> which is what ntpdate uses
-    <youpi> when __io_select is used, it *is* interruptible
-    <youpi> but when __mach_msg is used, it is *not* interruptible
-    <youpi> it happens that by luck, ntpdate uses just one fd, and thus it's
-      __io_select which is used, and thus it gets an interruption after 1s
-      (instead of after 60s, the timeout)
-    <youpi> with braunr's patch, it's __mach_msg which is used to wait, and
-      thus the interruption doesn't happen, and we have to wait  60s, the
-      timeout...
-    <youpi> so braunr's patch is still correct, it's the __mach_msg call which
-      we do need to make interruptible (it was already on the todolist)
-
-Proposed patch: [[!message-id
-"20130105162817.GW5965@type.youpi.perso.aquilenet.fr"]].
-
-
-## IRC, freenode, #hurd, 2013-01-15
-
-    <_d3f> Hello, any one else having problems with git?
-    <braunr> _d3f: yes
-    <braunr> _d3f: it will be fixed in the next glibc release
-    <_d3f> oh thx. what was the problem?
-    <braunr> http://lists.gnu.org/archive/html/bug-hurd/2013-01/msg00005.html
-    <WhiteKIBA> exactly this problem is preventing us building glibc
-    <braunr> it's indeed very annoying
-    <braunr> and this fix will probably have a visible and positive effect on
-      other issues
-    <_d3f> let's hope so. 
-    <braunr> well, i'm already using it and see the difference
-
----
-
-See also [[select]] and [[select_bogus_fd]].
diff --git a/open_issues/sendmsg_scm_creds.mdwn b/open_issues/sendmsg_scm_creds.mdwn
deleted file mode 100644
index d4a6126e..00000000
--- a/open_issues/sendmsg_scm_creds.mdwn
+++ /dev/null
@@ -1,172 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 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]]
-
-
-# IRC, unknown channel, unknown date
-
-    <pinotree> Credentials: s_uid 1000, c_uid 1000, c_gid 100, c_pid 2722
-    <pinotree> 2722: Credentials: s_uid 1000, c_uid 1000, c_gid 100, c_pid 2724
-    <pinotree> \o/
-    <youpi> \o/
-    <pinotree> the patch is even short, after all: http://paste.debian.net/54795/
-    --- a/sysdeps/mach/hurd/sendmsg.c
-    +++ b/sysdeps/mach/hurd/sendmsg.c
-    @@ -18,6 +18,7 @@
-     
-     #include <errno.h>
-     #include <string.h>
-    +#include <unistd.h>
-     #include <sys/socket.h>
-     #include <sys/un.h>
-     
-    @@ -45,6 +46,7 @@
-       mach_msg_type_number_t amount;
-       int dealloc = 0;
-       int i;
-    +  struct sockaddr_storage sa;
-     
-       /* Find the total number of bytes to be written.  */
-       len = 0;
-    @@ -122,6 +124,34 @@
-       err = EIEIO;
-         }
-     
-    +  memset (&sa, 0, sizeof (struct sockaddr_storage));
-    +  if (addr)
-    +    {
-    +      memcpy (&sa, addr, addr_len);
-    +    }
-    +  else
-    +    {
-    +      getsockname (fd, (struct sockaddr *) &sa, &addr_len);
-    +    }
-    +  addr = (struct sockaddr_un *) &sa;
-    +  if (message && (addr->sun_family == AF_LOCAL))
-    +    {
-    +      struct cmsghdr *cm;
-    +      struct msghdr *m = (struct msghdr *) message;
-    +      for (cm = CMSG_FIRSTHDR (m); cm; cm = CMSG_NXTHDR (m, cm))
-    +      {
-    +        if (cm->cmsg_level == SOL_SOCKET && cm->cmsg_type == SCM_CREDS)
-    +	     {
-    +	           struct cmsgcred *cred = (struct cmsgcred *) CMSG_DATA (cm);
-    +		         cred->cmcred_pid = __getpid ();
-    +			       cred->cmcred_uid = __getuid ();
-    +			             cred->cmcred_euid = __geteuid ();
-    +				           cred->cmcred_gid = __getgid ();
-    +					         cred->cmcred_ngroups = getgroups (sizeof (cred->cmcred_groups) / sizeof (gid_t), cred->cmcred_groups);
-    +						     }
-    +						     }
-    +    }
-    +
-       err = HURD_DPORT_USE (fd,
-           	 ({
-    			  if (err)
-    <youpi> what checks that the pid is correct?
-    <youpi> and uid, etc.
-    <pinotree> hm?
-    <youpi> credential is not only about one claiming to the other his uid & such
-    <youpi> it's about the kernel or whatever authority tell to an end the identity of the other end
-    <pinotree> yep
-    <pinotree> but given that the data is then send to pflocal, this code is the last part that runs on the application side
-    <youpi> pflocal could as well just request the info from proc
-    <youpi> it will have to anyway, to check that it's true
-    <pinotree> hm
-    <pinotree> yeah, though about that, chose this approach as "quicker" (of course not definitive)
-    <youpi> well at least it shows we're able to transmit something :)
-    <pinotree> well it just manipulates the data which gets send nicely already ;)
-    <youpi> but really, it's most probably up to pflocal to check authentication from proc and give it to the other end
-    <youpi> the application sender part would be just the RPC authentication calls
-    <youpi> Mmm, just realizing: so receiver part already exists actually, right?
-    <youpi> (since it's just about letting the application reading from the message structure)
-    <pinotree> yep
-    <youpi> ok, good :)
-
-
-## IRC, freenode, #hurd, 2011-08-11
-
-    < pinotree> (but that patch is lame)
-
-
-## IRC, freenode, #hurd, 2013-05-09
-
-    <gnu_srs> youpi: Since you are online tonight, which authentication
-      callbacks to be used for SCM_CREDS calls. 
-    <gnu_srs> I have working code and need to add this to make things
-      complete. The auth server, lib* or where?  
-    <youpi> I don't understand the question
-    <gnu_srs> authentication callbacks like for SCM_RIGHTS, see 
-    <gnu_srs>
-      http://www.gnu.org/software/hurd/open_issues/sendmsg_scm_creds.html
-    <youpi> I still don't understand: what are you trying to do actually?
-    <gnu_srs> solving the SCM_CREDS propbems with e.g. dbus.
-    <youpi> so what is the relation with pinotree's patch on the page above?
-    <youpi> (I have no idea of the current status of all that)
-    <gnu_srs> his patch was not merged, right? have to shut down, sorry, bbl,
-      gn8
-    <pinotree> that patch was not merged since it is not in the correct place
-    <youpi> as I said, I have no idea about the status
-    <pinotree> youpi: basically, it boils down to knowing, when executing the
-      code implementing an rpc, who requested that rpc (pid, uid, gid)
-    <youpi> i.e. getting information about the reply port for instance?
-    <youpi> well that might be somehow faked
-    <youpi> (by perhaps giving another task's port as reply port)
-    <pinotree> for example (which would be the code path for SCM_CREDS), when
-      you call call the socket sendmsg(), pflocal would know who did that rpc
-      and fill the auxilliary data)
-    <pinotree> s,)$,,
-    <pinotree> youpi: yes, i know about this faking issue, iirc also antrik
-      mentioned quite some time ago
-    <youpi> ok
-    <pinotree> that's one of the (imho) two issues of this
-    <pinotree> my hurd-foo is not enough to know whether there are solutions to
-      the problem above
-
-
-### IRC, freenode, #hurd, 2013-05-14
-
-    <gnu_srs> Hi, regarding SCM_CREDS, I have some working code in
-      sendmsg.c. Now I need to make a callback to authenticate the pid, uid,
-      etc
-    <gnu_srs> Where to hook call that into pflocal? 
-    <gnu_srs> the auth server?
-    <gnu_srs> maybe _io_restrict_auth is the correct call to use (same as for
-      SCM_RIGHTS)?
-
-
-### IRC, freenode, #hurd, 2013-05-17
-
-    <gnu_srs> I'm working on the scm credentials right now to enable (via dbus)
-      more X window managers to work properly.
-    <gnu_srs> seems to be rather tricky:-(
-    <pochu> gnu_srs: I guess you also need SCM_CREDS, right?
-    <gnu_srs> hi pochu, that's what I'm working on, extending your SCM_RIGHTS
-      work to SCM_CREDS
-    <pinotree> that's what i did as proof, years ago?
-    <gnu_srs> it would be good to know which server calls to make, I'll be back
-      with proposals of functions to use.
-    <pinotree> there was a talk, years ago when i started with this, and few
-      days ago too
-    <pinotree> every methods has its own drawbacks, and basically so far it
-      seems that in every method the sender identity can be faked somehow
-    <gnu_srs> pinotree: Yes of course your patch was perfect, but it seemed
-      like people wanted a server acknowledgement too.
-    <pinotree> no, my patch was not perfect at all
-    <pinotree> if it was, it would have been cleaned up and sent few years ago
-      already
-
-
----
-
-See also [[dbus]], [[pflocal_socket_credentials_for_local_sockets]] and
-[[pflocal_reauth]].
diff --git a/open_issues/serial_console.mdwn b/open_issues/serial_console.mdwn
deleted file mode 100644
index 827fd211..00000000
--- a/open_issues/serial_console.mdwn
+++ /dev/null
@@ -1,106 +0,0 @@
-[[!meta copyright="Copyright © 2010, 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_documentation]]
-
-
-# IRC, freenode, #hurdfr, 2010-09-20
-
-    <youpi> tu peux compiler ton gnumach pour qu'il utilise la console série, et tu
-      mets le port série sur la console qemu
-    <youpi> -AC_DEFINE([RCLINE], [-1], [com port for the remote console])
-    <youpi> +AC_DEFINE([RCLINE], [0], [com port for the remote console])
-    <youpi> dans i386/configfrag.ac
-    <manuel> grumpf, peu pratique :)
-    <youpi> ben après t'auras accès vraiment à ton gnumach
-    <youpi> messages de noyau etc.
-    <manuel> oui c'est sûr, mais j'ai aucune idée de comment je configure qemu &
-      co, ça va être sportif encore
-    <youpi> -serial vc
-    <manuel> je lance pas moi-même le qemu, donc j'imagine qqch comme -serial
-      tcp::qqch,server
-    <youpi> ben t'as pas accès à la console alors ?
-    <youpi> mais sinon via tcp ça devrait aller oui
-    <manuel> si, via telnet
-    <manuel> youpi: et après, tu fais comment pour envoyer le c-a-D toi ?
-    <manuel> (question sans doute bête)
-    <youpi> c'est un code différent via com1 iirc
-    <manuel> mmmmmmmmmhhhhhh
-    <youpi> (c'est pas bête: c-a-d c'est pas vraiment défini pour un port série)
-    <manuel> tu sais où je peux le trouver ?
-    <youpi> ah tiens non yena pas
-    <youpi> mais bon spa dur à ajouter
-    <manuel> bcp trop compliqué pour moi
-    <youpi> dans i386/i386at/com.c, à la première ligne ttyinput()
-    <youpi> tu compares c à ce que tu veux
-    <youpi> et dans ce cas tu appelles kdb_kintr
-    <youpi> (sans paramètre)
-    <youpi> mais sinon ya pas vraiment besoin d'appeller explicitement le
-      débuggueur hein
-    <manuel> ah ?
-    <youpi> dès que tu mets debug_all_traps à 1 dans traps.c, il sera invoqué lors
-      du segv
-    <manuel> ok
-    <youpi> pour xen j'ai mis £ comme raccourcis
-    <manuel> ça me paraît plus simple dans ce cas
-    <youpi> clin d'œil à la société anglaise :)
-
-
-# IRC, freenode, #hurd, 2014-02-20
-
-    <gg0> 04:06:45< gg0> ok a configuration that works w/o patching anything is
-      9600 7S1 [ 7bits - parity Space - 1 stopbit ]
-    <gg0> 04:07:57< gg0> it displays correctly gnumach, ext2fs and following
-      outputs
-    <gg0> 04:28:05< gg0> youpi: instead if you want a patch, this one makes
-      gnumach default to 8N1. someone should still implement serial line
-      settings for ext2fs though
-    <gg0> seems something broke it later
-    <gg0> or it never worked on real hardware
-    <braunr> we definitely want it to work with 8N1
-    <gg0> never had problems with _virtual_ serial consoles
-    <gg0> never = during last 2 years = since
-      http://git.savannah.gnu.org/gitweb/?p=hurd/gnumach.git;a=commitdiff;h=2a603e88f86bee88e013c2451eacf076fbcaed81
-    <gg0> but i don't think i was on real hardware at that time
-
-
-## IRC, freenode, #hurd, 2014-02-21
-
-    <gg0> yeah, i have one rebuilt trying to fix serial console (already give
-      up)
-    <teythoon> what were you trying to fix ?
-    <gg0> i didn't fix anything but it's been useful somehow :)
-    <gg0> this one http://paste.debian.net/plain/83292
-    <gg0> initial messages from mach/hurd outputs like there was no line feed
-    <gg0> each line overwrites previous one
-    <gg0> then ext2fs outputs garbage
-    <gg0> then openrc start outputting fine
-    <gg0> minicom 9600 8N1
-    <teythoon> this is from a real machine ?
-    <gg0> yep real machine
-    <teythoon> nice :)
-    <gg0> i fixed last line, last garbage, by switching c: from 38400 to 9600
-      in inittab
-    <teythoon> i've a vt510 terminal connected to my hurd box, and i started to
-      make the serial setting in gnumach more configurable
-    <gg0> and disabling T0
-    <teythoon> didn't finish it though
-    <gg0> physical vt510 connected to virtual hurd box?
-    <teythoon> no, it's a real box as well
-    <gg0> good. and does it behave as described/pasted above?
-    <teythoon> currently i do not put the mach console on the serial line
-    <teythoon> b/c it has a fixed baud rate of 9600
-    <teythoon> and both grub and the getty are configured at a higher speed
-    <teythoon> hence my desire to improve gnumachs serial port setup
-    <gg0> i don't care much about speed. such no-line-feed behavior is quite
-      annoying though
-    <gg0> i thought it was related to CRMOD which afaiu should translate cr to
-      cr-lf, but i was surely missing something
-    <gg0> (annoying till one does ^A-A to make minicom add line feeds itself)
diff --git a/open_issues/servers_default-pager_permissions.mdwn b/open_issues/servers_default-pager_permissions.mdwn
deleted file mode 100644
index 58dba1cb..00000000
--- a/open_issues/servers_default-pager_permissions.mdwn
+++ /dev/null
@@ -1,27 +0,0 @@
-[[!meta copyright="Copyright © 2012 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]]."]]"""]]
-
-[[!meta title="/servers/default-pager permissions"]]
-
-[[!tag open_issue_hurd]]
-
-IRC, freenode, #hurd, 2012-01-14:
-
-    <youpi> antrik: what are the permissions that are supposed to be given to
-      /servers/default-pager ?
-    <antrik> olaf@alien:~$ ls -l /servers/default-pager
-    <antrik> crw-rw-rw- 1 root root 0, 0 Sep 17  2004 /servers/default-pager
-    <antrik> oh, interesting... in the other system it's different
-    <antrik> olaf@alien:~$ ls -l /sub/servers/default-pager
-    <antrik> crw-r--r-- 1 root root 0, 0 Jul 10  2006
-      /sub/servers/default-pager
-    <antrik> both are Debian, the latter installed with crosshurd
-    <antrik> (and native-install run in a chroot or subhurd, don't remember
-      which...)
diff --git a/open_issues/settrans_directory_symlink.mdwn b/open_issues/settrans_directory_symlink.mdwn
deleted file mode 100644
index 86148a52..00000000
--- a/open_issues/settrans_directory_symlink.mdwn
+++ /dev/null
@@ -1,52 +0,0 @@
-[[!meta copyright="Copyright © 2012 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_hurd]]
-
-This works:
-
-    $ touch a && settrans a /hurd/symlink b
-
-This doesn't:
-
-    $ mkdir a && settrans a /hurd/symlink b
-    settrans: a: Is a directory
-
-It's the same `file_set_translator` RPC both times, and it's [[translator
-short-circuiting|hurd/translator/short-circuiting]] which makes the latter one
-fail:
-
-`libdiskfs/file-set-trans.c`:
-
-    [...]
-      /* Set passive translator */
-      if (passive_flags & FS_TRANS_SET)
-        {
-          if (!(passive_flags & FS_TRANS_FORCE))
-            {
-              /* Handle the short-circuited translators */
-              mode_t newmode = 0;
-    
-              if (diskfs_shortcut_symlink && !strcmp (passive, _HURD_SYMLINK))
-                newmode = S_IFLNK;
-              [...]
-    
-              if (newmode)
-                {
-                  if (S_ISDIR (np->dn_stat.st_mode))
-                    {
-                      /* We can't allow this, because if the mode of the directory
-                         changes, the links will be lost.  Perhaps it might be
-                         allowed for empty directories, but that's too much of a
-                         pain.  */
-                      mutex_unlock (&np->lock);
-                      return EISDIR;
-                    }
-    [...]
diff --git a/open_issues/sigpipe.mdwn b/open_issues/sigpipe.mdwn
deleted file mode 100644
index 0df3560e..00000000
--- a/open_issues/sigpipe.mdwn
+++ /dev/null
@@ -1,345 +0,0 @@
-[[!meta copyright="Copyright © 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]]
-
-[[!GNU_Savannah_bug 461]]
-
-IRC, freenode, #hurd, 2011-04-20
-
-    <svante_> I found a problem from 2002 by Marcus Brinkmann that I think is
-      related to my problems: http://savannah.gnu.org/bugs/?461. He has a test
-      file called pipetest.c that shows that SIGPIPE is not triggered reliably.
-    <svante_> Cited from the bug report: The attached test program does not
-      trigger SIGPIPE reliably, because closing the read end of the pipe
-      happens asynchronously. The write can succeed because the read end might
-      not have been closed yet.
-    <svante_> I have debugged this program on both Hurd and Linux, and the
-      problem in Hurd remains:-(
-    <svante_> Anybody looked into the almost ten year old
-      bug:http://savannah.gnu.org/bugs/?461 this one is definitely related to
-      the build problems of e.g. ghc6 and ruby1.9.1. Should I mention this on
-      the ML?
-    <youpi> that could be it indeed
-    <youpi> does th bug still happen?
-    <azeem> depends on: new interface io_close
-    <azeem> which depends on: POSIX record locking
-    <svante_> youpi: Yes it does, I've tested the pipetest.c file submitted by
-      Marcus B on both Linux and Hurd
-    <azeem> that would've maybe been a nice GSOC task
-    <youpi> azeem: err, the contrary for posix record locking, non ?
-    <azeem> argh
-    <azeem> why would POSIX record locking depend on this?
-    <azeem> well anyway, then have POSIX record locking be a GSOC task :)
-    <azeem> I wasn't aware that would also fix ruby and ghc building :)
-    <youpi> http://permalink.gmane.org/gmane.os.hurd.devel.readers/265
-    <youpi> (for io_close stuff)
-    <youpi> http://comments.gmane.org/gmane.os.hurd.devel.readers/63 actually
-    <azeem> I guess if they didn't implement it/agreed on something back then
-      it'd be quite hard to do it now
-    <svante_> azeem: marcus recently showed up here. Maybe he can help out/has
-      ideas?
-    <azeem> well yeah
-    <azeem> but marcus was the junior guy back then
-    <azeem> <marcus> but it's a very hurdish solution (ie, complex, buggy, and
-      not implemented)
-    <azeem> maybe we can go for something simpler
-    <youpi> azeem: what is this quote about?
-    <azeem> don't remember
-    <azeem> not io_close I'd say
-
-2011-04-21
-
-    <antrik> svante_: why do you think the problem you see in ruby and ghc is
-      related to async close() ?
-
-2011-04-22
-
-    <svante_> Well: the test case I'm running on ruby is giving me an EBADF
-      after 8 successful loops, and tracing within eglibc points towards
-      __mutex_lock_solid or __spin_lock,  __spin_lock_solid from
-      mach/lock-intern.h from cthreads.
-
-2011-04-23
-
-    <antrik> srs1: yeah, I saw it... but I still wonder what makes you think
-      this is related to async FD closing?
-    <srs1> antrik: Every test case showing the problems are related to fd.h and
-      the functions there, especially the ones used in the function:
-      _HURD_FD_H_EXTERN_INLINE struct hurd_fd *_hurd_fd_get (int fd) and so is
-      the pipetest from Marcus too.
-    <srs1> I have not yet been able to trace further with gdb since most
-      variables are optimized out and adding print statements does not work, at
-      least not yet. Now I'm trying to build eglibc with -O1 to see if the
-      optimized out variables are there or not.
-    <youpi> srs1: he means the ghc6 issue
-    <youpi> (and the ruby issue)
-    <srs1> youpi: Yes, the ghc6 and ruby ends at the functions I mentioned in
-      fd,h 
-    <srs1> Both ghc6 and ruby programs are writing to a file when the error
-      happens. If they are using a pipeline or not I don't know yet, I think it
-      is a regular file write.
-    <srs1> I can send your the ruby program if you like: It is a c-file so
-      debugging is possible. ghc6 is worse, since that program cannot be
-      debugged directly with gdb. 
-    <antrik> pipetest also results in the program hanging in locking stuff?...
-    <srs1> pipetest does not hang, but gives no output as it should. Running it
-      in gdb with single stepping shows the correct behavior, but then gdb
-      hangs if I try to single stepping further, continue at the right place
-      works!
-    <antrik> I haven't looked at the pipetest program. do you have the link
-      handy?
-    <antrik> never mind, got it
-    <antrik> srs1: that sounds like a GDB problem...
-    <youpi> most probably, yes
-    <youpi> (and I've always seen issues like this in gdb on hurd)
-    <antrik> actually I think it's expected... the RPC handling code has some
-      explicit GDB hooks AIUI; trying to single-step into this code is probably
-      expected to wreck havoc...
-    <youpi> well, it should have some sane behavior
-    <youpi> even if it's "skip to next point where it's debuggable"
-    <antrik> srs1: note that there is no BADF involved in the pipetest AIUI...
-
-2011-04-28
-
-    <antrik> what is the actual problem you are seeing BTW?
-    <gnu_srs1> antrik: in ruby the problem is: Exception `IOError' at
-      tool/mkconfig.rb:12 - closed stream
-    <gnu_srs1> Triggered by ruby:io.c:internal_read_func() calling
-      sysdeps/mach/hurd/read.c returning a negative number of bytes read. 
-    <abeaumont> gnu_srs1: why do you think that error is locking related?
-    <gnu_srs1> This happens after 8 iterations of the read loop with 8192 bytes
-      read each time.
-    <abeaumont> but that doesn't involve locking at all, does it?
-    <gnu_srs1> I think it is, if there is a pipepline set up??
-    <gnu_srs1> Also the ghc6 hang ends up in hangs in sysdeps/mach/hurd/read.c
-      traced into fd.h where all things happen (including setting locks and
-      mutexes)
-    <braunr> what locking ?
-    <braunr> stdio locking is different from file locking
-    <braunr> and a pipe doesn't imply file locking at all
-    <abeaumont> read may block on pipes, but it's unrelated to flock
-    <gnu_srs1> Look into the file fd.h, maybe you can describe things
-      better. I'm not fluent in this stuff.
-    <gnu_srs1> Has a pipe has a file descriptor associated to it? What about a
-      file read/write?
-    <abeaumont> a pipe provides 2 file descriptors, one for reading and another
-      one for writting
-    <abeaumont> i may give a look at that if i manage to build glibc
-      succesfully...
-    <gnu_srs1> Take a look at the realevant code from fd.h:
-      http://pastebin.com/kesBpjy4
-    <abeaumont> the ruby error happens just trying to build ruby1.9?
-    <abeaumont> gnu_srs1: from what you said, the error occurs while reading,
-      so i don't see how it can be related to that code
-    <abeaumont> you already got a descriptor if you're reading from it
-    <gnu_srs1> I have not tried anything else than ruby1.9.1. I can send you
-      the ruby debug setup and files if you are interested.
-    <abeaumont> gnu_srs1: ok, i'll try to build ruby1.9.1 later... let's see if
-      i can build glibc first
-    <gnu_srs1>  abeaumont: well, the read suddenly returns -1 bytes read,
-      resulting in a file descriptor of -1 (instead of +3).
-    <abeaumont> gnu_srs1: i see
-    <antrik> gnu_srs1: are you sure the hang really happens in _hurd_fd_get()?
-      could you give us a backtrace?
-    <antrik> gnu_srs1: there are many reasons why read() can return -1; errno
-      should indicate the reason. unfortunately, I can't make much out of
-      ruby's "translation" of the error :-)
-    <gnu_srs1> antrik: In the ruby case there is no hang: The steam is closed
-      by read() giving an error code !=0. This triggers things in the ruby
-      code:  A negative number of bytes read and a negative fd results, and an
-      error error is triggered in the ruby code.
-    <gnu_srs1> antrik: See http://pastebin.com/eZmaZQJr
-    <antrik> gnu_srs1: yes, this all sounds perfectly right. the question is
-      *why* read() returns an error code. we'd need to know what error it is
-      exactly, and in what situation it occurs. tracing the libc code is not at
-      all useful here
-    <antrik> uhm... 1073741833 is errno?...
-    <gnu_srs1> BTW: I think the error code is EBADF (badfile descriptor?). The
-      integer version of it is 1073741833, see the pastebin i linked to.
-    <antrik> you could use perror() to get something more readable :-)
-    <antrik> or error() with the right arguments
-    <gnu_srs1> I used integer when printing, but looking into fd.h I think it
-      is EBADF  (I did get this result once in gdb)
-    <antrik> fd.h won't tell you anything. most error codes are generated by
-      the server, not by libc
-    <antrik> BADF might be generated in libc when ruby tries to read on FD -1
-    <antrik> (no idea why it tries to do that... perhaps there is actually
-      something wrong/stupid in ruby's error handling)
-    <gnu_srs1> Well I single-stepped in fd.h using gdb and printing err gave
-      EBADf. err is declared as: error_t err in read.c
-    <antrik> at which point did you single-step? while fd was still 3?
-    <gnu_srs1> I don't think the problem is in ruby, it is in mach/hurd!
-      Similar problems with ghc, python-apt, etc
-    <gnu_srs1> Yes, fd=3 was not changed. I cannot trace into fd.h from
-      read.c. That is the problem with all cases! Need to leave for a while
-      now.
-    <antrik> sorry, I don't see *anything* similar in the ghc failure.
-    <antrik> I don't know about python-apt
-    <antrik> for the ghc case, I'd like to see a GDB backtrace from the point
-      where it is hanging
-    <antrik> just to be clear: anything I/O-related will involve fd.h
-      somewhere. that doesn't in any way indicate the problems are related. in
-      fact the symptoms you described are very different, and I'm pretty
-      certain these are completely different issues
-    <gnu_srs1> antrik: Here is a backtrace,
-      http://pastebin.com/wvCiXFjB. Numbers 6,7,8 are from the calling Haskell
-      functions. They cannot be debugged by gdb. Nice to see that somebody is
-      showing interest at last:-/
-    <antrik> hm... I wonder whether the _hurd_intr_rpc_msg_in_trap is a result
-      of the ^C?
-    <antrik> if so, it seems to be a "normal" bloking read() operation. so
-      again probably not related to libc code at all
-    <gnu_srs1> Where is this blocking read() code located mach/hurd?
-    <antrik> io_read() is implemented by whatever server handles the FD in
-      question
-    <antrik> I guess rpctrace will be more helpful here than GDB... to see what
-      the program is trying to do here
-    <gnu_srs1> Why don't I get there with gdb?
-    <antrik> err... the server is a different process
-    <antrik> you are only tracing the client code
-    <gnu_srs1> OK, here is a rpctrace for ruby:
-      http://pastebin.com/sdPiKGBW.Nice programs you have, no manual pages, and
-      the program hang
-    <gnu_srs1> s/http://pastebin.com/sdPiKGBW.Nice
-      /http://pastebin.com/sdPiKGBW. BTW: Nice/ 
-    <gnu_srs1> antrik: Do you want the rpctrace of the ghc hang too? If that is
-      the case, do you need the whole file. From the ruby case the last part
-      looked most interesting:
-      libpthread/sysdeps/generic/pt-mutex-timedlock.c: assert (mutex->owner !=
-      self);
-    <antrik> gnu_srs1: hm... you get that assertion only with rpctrace? guess
-      it doesn't work properly then :-(
-    <gnu_srs1> Is it visible on the client side?
-    <antrik> gnu_srs1: that assertion *is* from the client side. I'm just
-      surprised that apparently it's only triggered when you run it in rpctrace
-    <antrik> how did you invoke rpctrace?
-    <gnu_srs1> rpctrace "command with options" > rpctrace.out 2>&1
-    <antrik> well, I'd like to know the "command with options" part :-)
-    <gnu_srs1> OK: for ruby: ./miniruby ./ tool/mkconfig.rb as before.
-    <antrik> OK, so it just runs the ruby interpreter and no other processes
-    <gnu_srs1> No other processes involved!
-    <abeaumont> gnu_srs1: i can reproduce the ruby error, no let's dig in it :D
-    <antrik> gnu_srs1: rpctrace for ghc could be useful too... but if it's too
-      long, pasting only the last bit might suffice
-    <gnu_srs1> antrik: OK, will do that. Do you find anything interesting?
-    <gnu_srs1>  abeaumont: Using gdb: gdb ./miniruby; (gdb) break io.c:569; c8;
-      break fd.h:72 or break read.c:27 and you are there. Beware of gdb
-      hanging, so you need another terminal to kill -9 gdb (sometimes a reboot
-      is needed :-(
-    <antrik> gnu_srs1: no, the ruby rpctrace is useless; apparently rpctrace
-      makes it break before reaching the relevant part :-(
-    <abeaumont> thanks gnu_srs1 
-    <gnu_srs1> antrik: Hope for better luck with ghc:
-      http://pastebin.com/dgcrA05t
-    <antrik> hm... it hangs at proc_dostop() again... whatever that means
-
-2011-05-07
-
-    <gnu_srs> One question about ruby: I know where the problems occur in ruby
-      code. Can I switch to the kernel thread just before in gdb to single step
-      from there?
-    <youpi> you can put a breakpoint, can't you?
-    <antrik> gnu_srs: kernel thread?
-    <gnu_srs> Yes, but will single stepping from there lead me to the Hurd
-      code. I have not succeeded to do that yet!
-    <youpi> you mean the translator code?
-    <gnu_srs> Well, Roland did call it the signal thread, there are at least
-      two threads per process, a signal thread and a main (user) thread.
-    <youpi> then it's a thread in gdb
-    <youpi> just use the thread gdb commands to access it
-    <gnu_srs> I do find two threads in gdb, yes. But following only the user
-      thread does not lead me to the cause of the problems.
-    <gnu_srs> And following the other (signal thread) has not been successful
-      so far.
-    <youpi> multithreading debugging in gdb is painful yes
-    <youpi> single-step isn't really an option in it
-    <antrik> gnu_srs: well, as I said before, the cause is probably not in the
-      libc code anyways. it would be much more relevant to find out what the FD
-      in question is, and what "special" thing Ruby does to it to trigger the
-      problematic behaviour...
-    <youpi> it's simpler to put printfs etc.
-    <antrik> youpi: well, printf doesn't work in the FD code :-)
-    <youpi> you can make it work
-    <youpi> open /dev/mem, write to 0xb8000
-    <youpi> I'm not even joking
-    <gnu_srs> I have printfs in the ruby code. And at some parts in eglibc (but
-      it is not possible to put them at all places I want, as mentioned before)
-    <antrik> sure, there are ways to debug this code too... but I don't think
-      it's useful. so far there is no indication that this will help finding
-      the actual issue
-    <gnu_srs> The problem is not file descriptors. It is that an ongoing read
-      suddenly returns -1 bytes read. And then the ruby code assigns a negative
-      file descriptor in the exception handling.
-    <youpi> a *read* ?
-    <youpi> with errno == 0 ?
-    <gnu_srs> Yes, a read!
-    <youpi> how ruby comes to assigning a negative fd from that?
-    <youpi> does it somehow close the fd?
-    <gnu_srs> The errno reported from the read is EBADF!
-    <youpi> did you try to rpctrace it?
-    <gnu_srs> I don't bother too much about ruby exception handling. The error
-      has already happened in the read operation. And that lead me to eglibc
-      code.... and so on...
-    <youpi> do you know what kind of file this fd was supposed to be on?
-    <youpi> sure, that's debugging
-    <gnu_srs> Yes I did rpctrace, but that was not successful. rpctrace just
-      hang! Buggy code?
-    <antrik> youpi: I assume that's Ruby's way to indicate that the FD is not
-      valid anymore, after the previous error
-    <youpi> does the program fork?
-    <youpi> antrik: possibly
-    <youpi> rpctrace has known issues, yes
-    <youpi> gnu_srs: did you trace close()s by hand with printfs?
-    <gnu_srs> Ho w to find out if it forks?
-    <youpi> what does rpctrace stop on ?
-    <gnu_srs> Well, I don't remember. Antrik?
-    <antrik> proc_dostop() IIRC
-    <antrik> or something like that
-    <gnu_srs> I did not find any close() statements in the code I debugged.
-    <youpi> ok, proc_dostop() is typically a sign of fork()
-    <youpi> gnu_srs: that doesn't necessarily mean it's not called
-    <antrik> gnu_srs: I think his point is that something else might close the
-      FD, causing the error you see
-    <youpi> anything can happen in the wild :)
-    <antrik> gnu_srs: as I said before, the next step is to find out what this
-      FD is, and what happens to it...
-    <gnu_srs> antrik: Any ideas how to find out?
-    <youpi> what is the backtrace?
-    <gnu_srs> Well I know the fd number, it is either 3 or 5 in my tests. Does
-      the number matter?
-    <youpi> yes, it's not std{in,out,err}
-    <gnu_srs> How to get a backtrace of a program that does not hang?
-    <youpi> make it hang at the point of failure
-    <youpi> when read returns -1
-    <youpi> so you know who did the read
-    <gnu_srs> I have to run the loop several times before the number of bytes
-      read is -1.
-    <youpi> you mean running the program several times ?
-    <youpi> or just let the loop continue for some time?
-    <pinotree> if it's the latter, you can add breakpoints with conditions
-    <gnu_srs> No the read loop runs for 7 iterations, and fails the 8th time!
-    <youpi> then make it hang when read() returns -1
-    <Mr_Spock> could you paste your code somewhere?
-    <youpi> when debugging, you're allowed to do all kinds of ugly things, you
-      know ;)
-    <gnu_srs> OK, I'll try that.
-    <gnu_srs> MR_Spock: The easiest way would be to try to build
-      ruby1.9.1. Then I can help you from where it fails. 
-    <gnu_srs> pinotree: How to give a breakpoint with a condition?
-    <pinotree> break where if condition
-    <youpi> see help break
-    <youpi> oh, there's even a thread condition nowadays, good
-    <gnu_srs> Thanks for the discussion. I have to get into the real world for
-      a while now. To be continued.
-    <antrik> gnu_srs: well, if you already know that the loop runs several
-      times before the error occurs, you apparently already looked at the
-      higher-level code that is relevant here...
-    <youpi> but it may be generic code, and not tell what calls it
diff --git a/open_issues/smp.mdwn b/open_issues/smp.mdwn
deleted file mode 100644
index 89474d25..00000000
--- a/open_issues/smp.mdwn
+++ /dev/null
@@ -1,47 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 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]]."]]"""]]
-
-[[!meta title="SMP"]]
-
-[[!tag open_issue_glibc open_issue_gnumach open_issue_hurd]]
-
-See also the [[FAQ entry|faq/smp]].
-
-
-# IRC, freenode, #hurd, 2012-09-30
-
-    <braunr> i expect smp to be our next gsoc project
-
-
-## IRC, freenode, #hurd, 2013-01-02
-
-    <braunr> i'd like to mentor someone for adding smp to gnumach
-
-
-## IRC, freenode, #hurd, 2013-03-14
-
-    <braunr> but i'm afraid we'll have to fight obscur smp-safety issues
-    <braunr> for one, drivers are much probably not smp safe and would require
-      a big kernel lock
-    <braunr> userspace (such as signal delivery in libc) might be affected too
-    <braunr> smp isn't that easy
-
-
-## Richard, 2013-03-20
-
-This task actually looks too big for a GSoC project.
-
-
-## IRC, freenode, #hurd, 2013-09-30
-
-    <braunr> also, while the problem with hurd is about I/O, it's actually a
-      lot more about caching, and even with more data cached in, the true
-      problem is contention, in which case having several processors would
-      actually slow things down even more
diff --git a/open_issues/socat.mdwn b/open_issues/socat.mdwn
deleted file mode 100644
index 1961a9a8..00000000
--- a/open_issues/socat.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!meta copyright="Copyright © 2009 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_porting]]
-
-`socat` needs porting.  Some work has already been done in 2007, see
-<http://www.dest-unreach.org/socat/contrib/socat-hurd.html> or contact
-[[Thomas_Schwinge|tschwinge]].
diff --git a/open_issues/some_todo_list.mdwn b/open_issues/some_todo_list.mdwn
deleted file mode 100644
index 7a7d7487..00000000
--- a/open_issues/some_todo_list.mdwn
+++ /dev/null
@@ -1,112 +0,0 @@
-[[!meta copyright="Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009,
-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_hurd]]
-
-This todo is primarily targetted at the Hurd proper
-and applications that rely on the Hurd interfaces.
-
-* psmisc
-
-The tools provided by the psmisc package are linux centric. Killall and pstree, for instance, require Linux's proc file system but could just as easily use Hurd's libps.
-
-* tmpfs
-* ppp
-* unionfs/stowfs
-* supermount translator
-
-From Marcus, 2002:
-
-* xkb driver for console (for international users)
-* kbd leds in console (well, in general, Roland's new driver in oskit for that crap)
-* fixing tmpfs (it's buggy, Neal says it's Mach's fault)
-* adding posix shared memory (requires the io\_close call to be implemented)
-* adding posix file locking (requires the io\_close call to be implemented)
-* testing
-  * find + various filesystems (are inode numbers for . and .. sane?)
-  * ext2fs with other block sizes than 4096
-  * --help and --version and --usage in all programs
-    * I have seen ^V in some --help output, might be argp bug
-    * Verify that all options are documented clearly, and that no unimplemented options appear
-    * Is the short and long description in the help output correct?
-  * Is the return value of all programs correct (eg, does main() return a sane value)
-  * Is the suid bit correctly set for all installed programs?
-  * Translators
-    * Does settrans -g work? -fg?
-    * Does stat() work on all translated nodes and give proper data?
-    * What about chown, chmod (some translators should pass this through to the underlying node, esp in /dev!)
-    * Does statfs give correct data?
-    * Are all inode numbers and link counts correct?
-* We also should have a "make check" test suite. We can add this once Jeff finished his automake patches
-* pick up the other things
-  * new console is basically done
-    * needs integration of course
-    * X switching support
-* there is certainly more to do ...
-
-Wolfgang list of [Easy tasks](http://mail.gnu.org/pipermail/help-hurd/2002-July/006413.html) on July 28, 2002:
-
-<table border="1" cellpadding="1" cellspacing="0">
-  <tr>
-    <th bgcolor="#99CCCC"><strong>Difficulty</strong></th>
-    <th bgcolor="#99CCCC"><strong>Task</strong></th>
-  </tr>
-  <tr>
-    <td> 0 </td>
-    <td> Check if all programs handle options (at least --help, --version and --usage; don't forget about the shell scripts) </td>
-  </tr>
-  <tr>
-    <td> 1 </td>
-    <td> Check if all translators respond to "settrans -g" </td>
-  </tr>
-  <tr>
-    <td> 1 </td>
-    <td> More tests of this kind </td>
-  </tr>
-  <tr>
-    <td> 2 </td>
-    <td> Fix those of the above who don't work as intended </td>
-  </tr>
-  <tr>
-    <td> 2 </td>
-    <td> Document (in doc/hurd.texi) all undocumented programs (translators as well as programs in utils/ and sutils/ and some others) </td>
-  </tr>
-  <tr>
-    <td> 1 </td>
-    <td> Find a POSIX test suite, run it on GNU/Hurd, report the results </td>
-  </tr>
-  <tr>
-    <td> 1 </td>
-    <td> Find more useful test suites to run </td>
-  </tr>
-  <tr>
-    <td> 3 </td>
-    <td> Update INSTALL-cross </td>
-  </tr>
-  <tr>
-    <td> 2 </td>
-    <td> Check if all the store classes in libstore work (we have many of them, look into the Makefile) </td>
-  </tr>
-  <tr>
-    <td> 4 </td>
-    <td> Fix those who don't work </td>
-  </tr>
-  <tr>
-    <td> 2 </td>
-    <td> Document all still undocumented store classes </td>
-  </tr>
-  <tr>
-    <td> 2 </td>
-    <td> The console is pretty new code, it told me it wants to get tested </td>
-  </tr>
-</table>
-
-Where difficulty 0 means trivial and 4 means tricky; the difficulty has nothing to do with the importance.
diff --git a/open_issues/ssh.mdwn b/open_issues/ssh.mdwn
deleted file mode 100644
index 6d000b00..00000000
--- a/open_issues/ssh.mdwn
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!meta copyright="Copyright © 2013 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_porting]]
-
-Ssh compression does not work at the server level for some reason:
-
-    Jul  2 18:06:08 debian sshd[405]: fatal: buffer_uncompress: inflate returned -3
-
-One has to disable compression in /etc/sshd_config: 
-
-    Compression no
-
diff --git a/open_issues/strict_aliasing.mdwn b/open_issues/strict_aliasing.mdwn
deleted file mode 100644
index 0e59f796..00000000
--- a/open_issues/strict_aliasing.mdwn
+++ /dev/null
@@ -1,44 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 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_gnumach open_issue_hurd open_issue_mig]]
-
-
-# IRC, freenode, #hurd, 2012-07-04
-
-    <braunr> we should perhaps build the hurd with -fno-strict-aliasing,
-      considering the number of warnings i can see during the build :/
-    <pinotree> braunr: wouldn't be better to "just" fix the mig-generated stubs
-      instead?
-    <braunr> pinotree: if we can rely on gcc for the warnings, yes
-    <braunr> but i suspect there might be other silent issues in very old code
-
-
-# IRC, freenode, #hurd, 2012-07-12
-
-    <braunr> btw, i'm building glibc right now, and i can see a few strict
-      aliasing warnings
-    <braunr> fixing them will allow us to avoid wasting time on very obscure
-      issues (if gcc catches them all)
-    <tschwinge> The strict aliasing things should be fixed, yes.  Some might be
-      from MIG.
-
-
-# IRC, freenode, #hurd, 2013-10-17
-
-    <braunr> we should build gnumach and the hurd with -fno-strict-aliasing
-    <pinotree> aren't the mig-generated stubs the only issues related to that?
-    <braunr> no
-    <teythoon> b/c we often have pointers of different type pointing to the
-      same address? for example code using libports?
-    <braunr> the old linux code, including pfinet, and even the hurd libraries,
-      use techniques that assume aliasing
-    <braunr> exactly
-    <teythoon> right, I agree
diff --git a/open_issues/subhurd_error_messages.mdwn b/open_issues/subhurd_error_messages.mdwn
deleted file mode 100644
index 46b58fa4..00000000
--- a/open_issues/subhurd_error_messages.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_hurd]]
-
-IRC, unknown channel, unknown date:
-
-    <antrik> BTW, many things in a subhurd print various error messages that are never visible on a normal Hurd...
diff --git a/open_issues/subhurd_vs_proc_server.mdwn b/open_issues/subhurd_vs_proc_server.mdwn
deleted file mode 100644
index 36d150f8..00000000
--- a/open_issues/subhurd_vs_proc_server.mdwn
+++ /dev/null
@@ -1,54 +0,0 @@
-[[!meta copyright="Copyright © 2013 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_hurd]]
-
-
-# IRC, freenode, #hurd, 2013-02-09
-
-    <youpi> also, can you actually gdb a process of another subhurd?
-    <braunr> yes
-    <youpi> but you need to talk to its proc server, don't you?
-    <braunr> i don't know
-    <braunr> but i did it several times
-    <youpi> how?
-    <braunr> the usual way
-    <braunr> gdb /path/to/bin pid
-    <youpi> but which pid?
-    <braunr> the hard part was finding the right pid
-    <youpi> well, gdb still needs to talk with the right proc too
-    <braunr> i don't think it does
-    <youpi> btw about the "unable to adjust libports thread priority" errors
-      I'm seeing on the buildd consoles
-    <braunr> from what i've seen, proc "creates" tasks when it first sees them
-      too
-    <youpi> it's about the destination port
-    <braunr> yes
-    <braunr> i have those when starting a subhurd too
-    <youpi> so it would mean that proc somehow got bogus
-    <youpi> ah
-    <youpi> so  you can actually use your own proc
-    <braunr> yes
-    <braunr> and it feels bogus to me
-    <youpi> and I guess mach lets that proc access the task because your proc
-      is privileged
-    <braunr> probably
-    <braunr> it feels bogus because, you can't rely on pids being allocated per
-      task
-    <braunr> what i mean is that, if some tasks spawn and die quickly
-    <braunr> and you start another application running long enough to see it in
-      ps
-    <braunr> it's pid will be +1, not +the number of created tasks
-    <braunr> which means the proc server will never have seen those previous
-      tasks
-    <braunr> it's minor but a bit confusing
-    <braunr> i personally don't like seeing the tasks of other systems in ps :/
-    <braunr> and despite the ability to use gdb from another hurd, i think we
-      should improve the intra system debugging tools
diff --git a/open_issues/sync_but_still_unclean_filesystem.mdwn b/open_issues/sync_but_still_unclean_filesystem.mdwn
deleted file mode 100644
index eae98077..00000000
--- a/open_issues/sync_but_still_unclean_filesystem.mdwn
+++ /dev/null
@@ -1,39 +0,0 @@
-[[!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_gnumach open_issue_hurd]]
-
-Also filed as [[!GNU_Savannah_bug 29292]].
-
-\#hurd, 2010, end of May / beginning of June
-
-    [runnign sync, but sill unclean filesystem at next boot]
-    <slpz> guillem: when libpager syncs an object, it sends an m_o_lock_request
-      and waits (if the synchronous argument was specified) for a
-      m_o_lock_completed. But m_o_lock_completed only means that dirty pages
-      have been sent to the translator, and this one still needs to write them
-      to the backing storage
-    <slpz> guillem: there's no problem if sync() returns before actually
-      writting the changes to disk, but this also happens when shutting down
-      the translator
-    <slpz> guillem: in theory, locking mechanisms in libpager should prevent
-      this from happening by keeping track of write operations, but this seems
-      to fail in some situations
-
-It helps a lot to run [[`syncfs --synchronous /`|hurd/syncfs]] before issuing
-the `halt` or `reboot` command.  This will prevent most of the uncleanliness.
-Of course, [[hurd/translator/ext2fs]] is meant to be doing this to-disk
-synchronization internally upon translator shutdown, but evidently it doesn't
-in all cases.
-
-Apparently diskfs simply does not set filesystems as read-only:
-<http://lists.gnu.org/archive/html/bug-hurd/2011-08/msg00024.html>.
-
-A patch was applied, and the sync issue does not seem to happen any more.
diff --git a/open_issues/synchronous_ipc.mdwn b/open_issues/synchronous_ipc.mdwn
deleted file mode 100644
index 53d5d69d..00000000
--- a/open_issues/synchronous_ipc.mdwn
+++ /dev/null
@@ -1,185 +0,0 @@
-[[!meta copyright="Copyright © 2012 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_hurd]]
-
-
-# IRC, freenode, #hurd, 2012-07-20
-
-From [[Genode RPC|microkernel/genode/rpc]].
-
-    <braunr> assuming synchronous ipc is the way to go (it seems so), there is
-      still the need for some async ipc (e.g signalling untrusted recipients
-      without risking blocking on them)
-    <braunr> 1/ do you agree on that and 2/ how would this low-overhead async
-      ipc be done ? (and 3/ are there relevant examples ?
-    <antrik> if you think about this stuff too much you will end up like marcus
-      and neal ;-)
-    <braunr> antrik: likely :)
-    <antrik> the truth is that there are various possible designs all with
-      their own tradeoffs, and nobody can really tell which one is better
-    <braunr> the only sensible one i found is qnx :/
-    <braunr> but it's still messy
-    <braunr> they have what they call pulses, with a strictly defined format
-    <braunr> so it's actually fine because it guarantees low overhead, and can
-      easily be queued
-    <braunr> but i'm not sure about the format
-    <antrik> I must say that Neal's half-sync approach in Viengoos still sounds
-      most promising to me. it's actually modelled after the needs of a
-      Hurd-like system; and he thought about it a lot...
-    <braunr> damn i forgot to reread that
-    <braunr> stupid me
-    <antrik> note that you can't come up with a design that allows both a)
-      delivering reliably and b) never blocking the sender -- unless you cache
-      in the kernel, which we don't want
-    <antrik> but I don't think it's really necessary to fulfill both of these
-      requirements
-    <antrik> it's up to the receiver to make sure it gets important signals
-    <braunr> right
-    <braunr> caching in the kernel is ok as long as the limit allows the
-      receiver to handle its signals
-    <antrik> in the Viengoos approach, the receiver can allocate a number of
-      receive buffers; so it's even possible to do some queuing if desired
-    <braunr> ah great, limits in the form of resources lent by the receiver
-    <braunr> one thing i really don't like in mach is the behaviour on full
-      message queues
-    <braunr> blocking :/
-    <braunr> i bet the libpager deadlock is due to that
-
-[[libpager_deadlock]].
-
-    <braunr> it simply means async ipc doesn't prevent at all from deadlocks
-    <antrik> the sender can set a timeout. blocking only happens when setting
-      it to infinite...
-    <braunr> which is commonly the case
-    <antrik> well, if you see places where blocking is done but failing would
-      be more appropriate, try changing them I'd say...
-    <braunr> it's not that easy :/
-
-
-# IRC, freenode, #hurd, 2012-08-18
-
-    <lcc> what is the deepest design mistake of the HURD/gnumach?
-    <braunr> lcc: async ipc
-    <savask> braunr: You mentioned that moving to L4 will create problems. Can
-      you name some, please?
-    <savask> I thought it was going to be faster on L4
-    <braunr> the problem is that l4 *only* provides sync ipc
-    <braunr> so implementing async communication would require one seperated
-      thread for each instance of async communication
-    <savask> But you said that the deepest design mistake of Hurd is asynch
-      ipc.
-    <braunr> not the hurd, mach
-    <braunr> and hurd depends on it now
-    <braunr> i said l4 provides *only* sync ipc
-    <braunr> systems require async communication tools
-    <braunr> but they shouldn't be built entirely on top of them
-    <savask> Hmm, so you mean mach has bad asynch ipc?
-    <braunr> you can consider mach and l4 as two extremes in os design
-    <braunr> mach *only* has async ipc
-    <lcc> what was viengoos trying to explore?
-    * savask is confused
-    <braunr> lcc: half-sync ipc :)
-    <braunr> lcc: i can't tell you more on that, i need to understand it better
-      myself before any explanation attempt
-    <savask> You say that mach problem is asynch ipc. And L4's problem is it's
-      sync ipc. That means problems are in either of them!
-    <braunr> exactly
-    <lcc> how did apple resolve issues with mach?
-    <savask> What is perfect then? A "golden middle"?
-    <braunr> lcc: they have migrating threads, which make most rpc behave as if
-      they used sync ipc
-    <braunr> savask: nothing is perfect :p
-    <mcsim> braunr: but why async ipc is the problem?
-    <braunr> mcsim: it requires in-kernel buffering
-    <savask> braunr: Yes, but we can't have problems everywhere o_O
-    <braunr> mcsim: this not only reduces communication performance, but
-      creates many resource usage problems
-    <braunr> mcsim: and potential denial of service, which is what we
-      experience most of the time when something in the hurd fails
-    <braunr> savask: there are problems we can live with
-    <mcsim> braunr: But this could be replaced by userspace server, isn't it?
-    <braunr> savask: this is what monolithic kernels do
-    <braunr> mcsim: what ?
-    <braunr> mcsim: this would be the same, this central buffering server would
-      suffer from the same kind of issue
-    <mcsim> braunr: async ipc. Buffer can hold special server
-    <mcsim> But there could be created several servers, and queue could have
-      limit.
-    <braunr> queue limits are a problem
-    <braunr> when a queue limit is reached, you either block (= sync ipc) or
-      lose a message
-    <braunr> to keep messaging reliable, mach makes senders block
-    <braunr> the problem is that async ipc is often used to avoid blocking
-    <braunr> so blocking when you don't expect it can create deadlocks
-    <braunr> savask: a good compromise is to use sync ipc most of the time, and
-      async ipc for a few special cases, like signals
-    <braunr> this is what okl4 does if i'm right
-    <braunr> i'm not sure of the details, but like many other projects they
-      realized current systems simply need good support for async ipc, so they
-      extended l4 or something on top of it to provide it
-    <braunr> it took years of research for very smart people to get to some
-      consensus like "sync ipc is better but async is needed too"
-    <braunr> personaly i don't like l4 :/
-    <braunr> really not
-    <mcsim> braunr: Anyway there is some queue for messaging, but at the moment
-      if it overflows panics kernel. And with limited queue servers will panic.
-    <braunr> mcsim: it can't overflow
-    <braunr> mach blocks senders
-    <braunr> queuing basically means "block and possible deadlock" or "lose
-      messages and live with it"
-    <mcsim> So, deadlocks are still possible?
-    <braunr> of course
-    <braunr> have a look at the libpager debian patch and the discussion around
-      it
-    <braunr> it's a perfect example
-    <youpi> braunr: it makes gnu mach slow as hell sometimes, which I guess is
-      because all threads (which can ben 1000s) wake at the same time
-    <braunr> youpi: you mean are created ?
-    <braunr> because they'll have to wake in any case
-    <braunr> i can understand why creating lots of threads is slower, but
-      cthreads never destroyes kernel threads
-    <braunr> doesn't seem to be a mach problem, rather a cthreads one
-    <braunr> i hope we're able to remove the patch after pthreads are used
-
-[[libpthread]].
-
-    <mcsim> braunr: You state that hurd can't move to sync ipc, since it
-      depends on async ipc. But at the same time async ipc doesn't guarantee
-      that task wouldn't block. So, I don't understand why limited queues will
-      lead to more deadlocks?
-    <braunr> mcsim: async ipc can block because of queue limits
-    <braunr> mcsim: if you remove the limit, you remove the deadlock problem,
-      and replace it with denial of service
-    <braunr> mcsim: i didn't say the hurd can't move to sync ipc
-    <braunr> mcsim: i said it came to depend on async ipc as provided by mach,
-      and we would need to change that
-    <braunr> and it's tricky
-    <youpi> braunr: no, I really mean are woken. The timeout which gets dropped
-      by the patch makes threads wake after some time, to realize they should
-      go away. It's a hell long when all these threads wake at the same time
-      (because theygot created at the same time)
-    <braunr> ahh
-
-    <antrik> savask: what is perfect regarding IPC is something nobody can
-      really answer... there are competing opinions on that matter. but we know
-      by know that the Mach model is far from ideal, and that the (original) L4
-      model is also problematic -- at least for implementing a UNIX-like system
-    <braunr> personally, if i'd create a system now, i'd use sync ipc for
-      almost everything, and implement posix-like signals in the kernel
-    <braunr> that's one solution, it's not perfect
-    <braunr> savask: actually the real answer may be "noone knows for now and
-      it still requires work and research"
-    <braunr> so for now, we're using mach
-    <antrik> savask: regarding IPC, the path explored by Viengoos (and briefly
-      Coyotos) seems rather promising to me
-    <antrik> savask: and yes, I believe that whatever direction we take, we
-      should do so by incrementally reworking Mach rather than jumping to a
-      completely new microkernel...
diff --git a/open_issues/syslog.mdwn b/open_issues/syslog.mdwn
deleted file mode 100644
index ab32b2e1..00000000
--- a/open_issues/syslog.mdwn
+++ /dev/null
@@ -1,116 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 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_hurd]]
-
-[[!toc]]
-
-
-# IRC, unknown channel, unknown date
-
-    <tschwinge> scolobb: In wiki edit 60accafa79f645ae61b578403f7fc0c11914b725
-      I see that you intend(ed) to use syslog for logging debug messages.  I
-      thought I'd point you to
-      http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00042.html -- no
-      idea if that's still an issue or what went wrong at that time.  Perhaps
-      you can have a look?
-    <scolobb> tschwinge: Thanks for information! Currently I'm logging some
-      debug messages to a simple file, but I'll now check whether the issue
-      you've pointed out is still present.
-    <scolobb> tschwinge: I am getting absolutely abnormal results: when I call
-      syslog() from a simple C program for the first time, the message goes to
-      the system log. However, any further calls to syslog() do just
-      nothing... I am able to send something to syslog only after reboot (it
-      doesn't help if I restart syslogd).
-
-
-# IRC, freenode, #hurd, 2011-08-08
-
-    < pinotree> wow, `logger` + a simple C udp server can cause havoc
-    < pinotree> youpi: ever seen something like
-      http://paste.debian.net/hidden/72cf4b77/ ?
-    < pinotree> and then also other servers (like pflocal, pfinet, few more)
-      start becoming crazy (using 100% cpu)
-    < youpi> nope
-    < pinotree> iirc in one of the few tries i got the message "Resource lost."
-      from the closed ssh connection
-    < pinotree> i was trying to see why syslog doesn't work, but this basically
-      surprised me...
-    < pinotree> oh, i found an apparently working syslog daemon
-    < pinotree> dsyslog
-    < gg0> have you tried syslog-ng? IIRC it writes in /var/log/messages by
-      default.
-    < pinotree> yeah, it seems to stop receiving messages are few
-    < pinotree> gg0: are you using syslog-ng?
-    < gg0> pinotree: I should fire hurd vm up. I seem I kept dirty-patched
-      busybox syslog, I don't even know if it works, at least it starts
-      http://bugs.debian.org/636162
-    < pinotree> maintainer said "not really"
-    < gg0> well, if all other syslogs use shm and sems, they won't work too,
-      right?
-    < youpi> shm should work with the latest libc
-    < youpi> what won't is sysv sem
-    < youpi> (i.e. semget)
-
-
-IRC, OFTC, #debian-hurd, 2011-11-02:
-
-    * pinotree sighs at #645790 :/
-    <tschwinge> pinotree: W.r.t. 645790 -- yeah, ``someone'' should finally
-      figure out what's going on with syslog.
-      http://lists.gnu.org/archive/html/bug-hurd/2008-07/msg00152.html
-    <tschwinge> pinotree: And this...
-      http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00042.html
-    <pinotree> tschwinge: i did that 20 invocations tests recently, and
-      basically none of them has been logged
-    <pinotree> tschwinge: when i started playing with logger more, as result i
-      had some server that started taking all the cpu, followed by other
-      servers and in the end my ssh connection were dropped and i had nothing
-      to do (not even login from console)
-    <tschwinge> pinotree: Sounds like ``fun''.  Hopefully we can manage to
-      understand (and fix the underlying issue) why a simple syslog()
-      invocation can make the whole system instable.
-    <pinotree> tschwinge: to be honest, i got havoc in the system when i told
-      syslog to manually look for /dev/log (-u /dev/log), possibly alao when
-      telling to use a datagram socket (-d)
-    <pinotree> but even if a normal syslog() invocation does not cause havoc,
-      there's still the "lost messages" issue
-    <tschwinge> Yep.  What I've been doing ever since, is deinstall all
-      *syslog* packages.
-    <tschwinge> This ``fixed'' all syslog() hangs.
-
-
-# IRC, freenode, #hurd, 2012-03-28
-
-    <braunr> i can see lots of CRON processes hanging around
-    <braunr> pinotree: crontab -l was hanging too when trying to quickly see
-      what went wrong
-    <braunr> so it may be an unreleased lock of some kind
-    <antrik> braunr: do you have syslog installed by any chance?...
-    <antrik> IIRC that bug has never been fixed :-(
-    <braunr> yes syslogd is running
-    <antrik> that's probably the culprit then
-    <braunr> ok
-    <braunr> i'll just disable it for now then
-    <antrik> the error has existed for years
-    <antrik> was similar for me though: for a long time I have been hearing
-      about this issue, and only suddenly I started experiencing it myself...
-    <antrik> it depends on how many things are actually logged. IIRC the hang
-      happens when some client sends 128 messages to syslog or something like
-      that
-
-
-# IRC, freenode, #hurd, 2013-02-09
-
-    <pinotree> tschwinge: looks like now you could disable syslog no
-    <pinotree> ... more
-    <tschwinge> It that working now?
-    <pinotree> should be yes, samuel fixed its issue many months ago
diff --git a/open_issues/system_call_mechanism.mdwn b/open_issues/system_call_mechanism.mdwn
deleted file mode 100644
index 68418097..00000000
--- a/open_issues/system_call_mechanism.mdwn
+++ /dev/null
@@ -1,56 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012 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_gnumach]]
-
-[[!toc]]
-
-
-# IRC, freenode, #hurd, 2011-05-07
-
-    <braunr> very simple examples: system calls use old call gates, which are
-      the slowest path to kernel space
-    <braunr> modern processors have dedicated instructions now
-
-
-# IRC, freenode, #hurd, 2012-04-22
-
-    <braunr> rah: basically, system calls are slower on mach because they use
-      call gates instead of newer sysenter/sysexit
-    <youpi> braunr: sysenter/exit is a x86_64 thing
-    <braunr> rah: apart from that, the code can't get much simpler, and *I*
-      know, for i have studied it, and wrote a compatible version in a clone
-      attempt
-    <youpi> braunr: on a x86_64 port we'd probably use sysenter/exit
-    <braunr> youpi: no there are 32-bits instructions, i don't remember if
-      they're called sysenter, it's in my thesis though so i'm sure of it :)
-    <youpi> braunr: ah, the other part
-    <youpi> is linux-x86 using them?
-    <braunr> youpi: yes, glibc uses them
-    <youpi> and does it really change much nowadays?
-    <youpi> what is the actual difference between int 80 and sysenter?
-    <braunr> less checking
-    <youpi> checking what?
-    <youpi> the idt?
-    <braunr> ring levels for example
-    <youpi> well, checking a ring is fast :)
-    <braunr> depending on the original and requested levels, there are lookups
-      in tables
-    <braunr> sysenter always assume 3 to 0 and 0 to 3 for sysexit
-    <youpi> ah, also it assumes things about segments
-    <youpi> so that indeed makes context things simpler
-    <braunr> right
-    <braunr> but mach doesn't uses int 0x80
-    <braunr> it uses an lcall
-    <braunr> which is a bit slower from what I could read some time ago
-    <braunr> (not sure if it's still relevant)
-    <youpi> actually in 64bit mode I had to catch lcall from the invalid
-      instruction trap
-    <youpi> perhaps it got dropped in 64bit mode
diff --git a/open_issues/system_crash_nmap.mdwn b/open_issues/system_crash_nmap.mdwn
deleted file mode 100644
index 25d9a1c6..00000000
--- a/open_issues/system_crash_nmap.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_gnumach]]
-
-IRC, unknown channel, unknown date:
-
-    <Casper_> Hmm, `nmap hurd -p 1-` seems to reliably make a hurd machine reboot.
diff --git a/open_issues/system_crash_pflocal_fifo.mdwn b/open_issues/system_crash_pflocal_fifo.mdwn
deleted file mode 100644
index 1dddc44e..00000000
--- a/open_issues/system_crash_pflocal_fifo.mdwn
+++ /dev/null
@@ -1,41 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_gnumach]]
-
-IRC, unknown channel, unknown date:
-
-`cat < /dev/zero | cat > /dev/null` will eventually make the system crash,
-likewise when using a FIFO.
-
-    <antrik> hm... VM activity seems much higher when running fifo than pfinet... may be the cause
-    <antrik> "zero filled" and "page faults" are serveral times higher with pipe than with pfinet
-    <antrik> (cow faults however are about the same...)
-    <antrik> pflocal is about the same as fifo
-    
-    <antrik> no, because it usually takes like 20 minutes until it crashes, sometimes much longer
-    
-    <antrik> not sure, but the longest so far was in the range of hours IIRC
-    
-    <antrik> I think I never tested what happens on "cat /dev/zero >/dev/null"... another thing yet to try
-    
-    <antrik> Linux BTW seems to employ some major VM trickery in this case -- dd shows a transfer rate of 10 GB/s...
-    
-    <antrik> no, no anomalies in vmstat
-    <antrik> the only observation I made is that number of page faults and some other number rise pretty quickly with pflocal and fifo, but not with pfinet
-    <antrik> I guess that's somehow related to the fact that pfinet doesn't crash -- though I guess the difference is simply that pfinet is way slower...
-    <antrik> (haven't checked that, though)
-    
-    <antrik> BTW, I'm not sure you got it right: the test case is "cat /dev/zero|cat >/dev/null", *not* "cat /dev/zero >/dev/null"
-    
-    <antrik> OK, "cat /dev/zero|tail -c 1" also crashes, so it's definitely not related to /dev/null
-    <antrik> "dd if=/dev/zero|tail -c 1" crashes as well
-    <antrik> but "tail -c 1 /dev/zero" doesn't seem to
-    <antrik> cool... running multiple instances of the pipe test also considerably speeds up the crash
diff --git a/open_issues/system_initialization.mdwn b/open_issues/system_initialization.mdwn
deleted file mode 100644
index 0df1078e..00000000
--- a/open_issues/system_initialization.mdwn
+++ /dev/null
@@ -1,42 +0,0 @@
-[[!meta copyright="Copyright © 2011, 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_hurd]]
-
-
-# IRC, freenode, #hurd, 2011-03-30
-
-    <kilobug> init=/bin/sh hack doesn't work for GNU/Hurd ?
-    <antrik> kilobug: I don't think you can override init on Hurd. the init
-      server is actually involved in bootstrapping part of the system core
-    <antrik> at some point we discussed the possibility to reduce the Hurd init
-      server to *only* do that, and then pass on to standard sysv init... with
-      that it could actually work
-
-
-# IRC, freenode, #hurd, 2013-11-29
-
-    <teythoon> we need to make the bootstrap code more robust and fix the error
-      handling there
-    <teythoon> for example, you can kill the exec server and the rootfs w/o
-      /hurd/init noticing it...
-    <braunr> yes
-    <teythoon> there are plans in init.c to take over the exception port of the
-      essential processes
-    <teythoon> that could help
-
-
-# [[hurd_init]]
-
-
-# [[Anatomy_of_a_Hurd_System]]
-
-
-# [[systemd]]
diff --git a/open_issues/system_stats.mdwn b/open_issues/system_stats.mdwn
deleted file mode 100644
index ce34ec09..00000000
--- a/open_issues/system_stats.mdwn
+++ /dev/null
@@ -1,45 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 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_documentation]]There should be a page listing ways to get
-system statistics, how to interpret them, and some example/expected values.
-
-
-# IRC, frenode, #hurd, 2012-11-04
-
-    <mcsim> Hi, is that normal that memory cache "ipc_port" is 24 Mb already?
-      Some memory has been already swapped out.
-    <mcsim> Other caches are big too
-    <braunr> how many ports ?
-    <mcsim> 45922
-    <braunr> yes it's normal
-    <braunr> ipc_port              0010      76   4k    50  45937 302050
-      24164k       4240k
-    <braunr> it's a bug in exim
-    <braunr> or triggered by exim, from time to time
-    <braunr> lots of ports are created until the faulty processes are killed
-    <braunr> the other big caches you have are vm_object and vm_map_entry,
-      probably because of a big build like glibc
-    <braunr> and if they remain big, it's because there was no memory pressure
-      since they got big
-    <braunr> memory pressure can only be caused by very large files on the
-      hurd, because of the limited page cache size (4000 objects at most)
-    <braunr> the reason you have swapped memory is probably because of a glibc
-      test that allocates a very large (more than 1.5 GiB iirc) block and fills
-      it
-    <mcsim> yes
-    <braunr> (a test that fails with the 2G/2G split of the debian kernel, but
-      not on your vanilla version btw)
-
-
-## IRC, frenode, #hurd, 2013-01-26
-
-    <braunr> ah great, one of the recent fixes (probably select-eintr or
-      setitimer) fixed exim4 :)
diff --git a/open_issues/systemd.mdwn b/open_issues/systemd.mdwn
deleted file mode 100644
index d2506046..00000000
--- a/open_issues/systemd.mdwn
+++ /dev/null
@@ -1,3694 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 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_porting]]
-
-  * <http://www.freedesktop.org/wiki/Software/systemd>
-
-  * <http://0pointer.de/blog/projects/systemd.html>,
-    <http://0pointer.de/blog/projects/systemd-update.html>
-
-  * <http://lwn.net/Articles/389149/>
-
-Will need to have something like Linux'
-[*cgroups*](http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cgroups/cgroups.txt;hb=HEAD).
-Introduction: [*Ressourcen-Verwaltung mit Control Groups (cgroups)*
-(german)](http://www.pro-linux.de/artikel/2/1464/ressourcen-verwaltung-mit-control-groups-cgroups.html),
-Daniel Gollub, Stefan Seyfried, 2010-10-14.
-
-Likely there's also some other porting needed.
-
-
-# Discussion
-
-This also captures discussion about other init systems, not only systemd.  Also
-note the additional [[upstart]] page.
-
-
-## IRC, OFTC, #debian-hurd, 2011-05-19
-
-    <pinotree> pochu: http://news.gmane.org/gmane.comp.gnome.desktop - the
-      "systemd as dependency" and all the messages in it don't give me a bright
-      future for gnome on hurd...
-    <pochu> yeah, I've read the thread
-    <pochu> it's only a proposal so far... hopefully it'll be rejected, or they
-      will only accept the interfaces that other OSes can implement...
-    <pochu> we'll see
-    <pinotree> you can always help me with kde on hurd, would be nice ;)
-    <pochu> hehe
-    <pinotree> pochu: well, even if the depenency is rejected, the whole «don't
-      give a damn about non-linux and only bless linux for the "gnome os"» is a
-      bit... worrying attitude
-    <pochu> yeah... it doesn't come from all the community though
-    <pochu> I'm sure some people have always thought that way
-    <tschwinge> Or we could get systemd going?  :-)
-    <pochu> good luck with that :p
-    <guillem> tschwinge: haha!? :)
-    <tschwinge> That bad?
-    <guillem> tschwinge: if you mean by that forking indefinitely then maybe
-    <guillem> tschwinge: upstream has expressely stated multiple times, no
-      interest whatsoever in any kind of portability to anything non-Linux
-    <guillem> or even older Linux versions!
-    <guillem> to the point of rejecting patches, because they "clutter" the
-      source code...
-    <tschwinge> Well, then let's ``just'' implement the Linux interfaces.  :-)
-    <guillem> tschwinge: then you'll be always playing catch up
-    <guillem> tschwinge: for example several of the Linux-only things upstream
-      makes heavy use of, are pretty recent Linux-only additions to the kernel,
-      but equivalents have been present on FreeBSD for years
-    <tschwinge> Yeah.  I'm half-serious, half-joking.
-    <tschwinge> I haven't looked at the systemd code at all.
-    <guillem>
-      https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00447.html
-      for a list of its dependencies
-    <guillem> some are just glibc extensions though
-    <guillem> and some are IMO optional and should be conditionalized, but...
-    <guillem> pochu: I don't think that attitude is that old, there was a time
-      when Linux was not used widely, or even that functional, I think it has
-      been taking strength since the Linux Plumbers Cartel started :)
-    <guillem> as in one thing is not caring about anything non-Linux, the other
-      is outright rejecting portability fixes
-    <guillem> tschwinge: in any case, these "recent" events are "pissing me
-      off" to the point of having considered several times implementing
-      portable replacements for some of those Utopia projects, the problem as
-      always is time though :)
-    <guillem> tschwinge: and the issue is not only with systemd, upstart's
-      upstream has the same approach to portability, if you want to port it,
-      you'll have to maintain a fork
-    <pochu> let's create our own init system, make it better than anyone else,
-      and when people start switching to it, let's start using hurd-only APIs
-      :)
-    <tschwinge> We already had someone work on that.  Like ten years ago.  DMD.
-      Daemon Managing Daemons.  <http://directory.fsf.org/project/DMD/>
-    <guillem> the real problem with that attitude is not the lack of care for
-      portabilty, the real problem is that these people are pushing for their
-      stuff all over the stack, and most of the time deprecating their own
-      stuff after a while when they have rewritten it from scratch, leaving the
-      burden of maintaining the old stuff to the other ports
-    <guillem> witness HAL, ConsoleKit, etc etc
-    <guillem> (anyway enough ranting I guess :)
-    <tschwinge> Yeah, it's true, though.
-    <pochu> agreed
-
-
-## IRC, freenode, #hurd, 2013-01-18
-
-    <braunr> systemd relies on linux specific stuff that is difficult to
-      implement
-    <braunr> notably cgroups to isolate the deamons it starts so it knows when
-      they stopped regardless of their pid
-    <braunr> just assume you can't use systemd on anything else than linux
-
-
-## IRC, OFTC, #debian-hurd, 2013-08-12
-
-    <azeem> huh, Lennert Poettering just mentioned the Hurd in his systmd talk
-    <azeem> well, in the context of you IPC in Unix sucks and kdbus
-    <azeem> s/you/how/
-    <pinotree> QED
-    <pinotree> what did you expect? :)
-    <azeem> I didn't quite get it, but he seemed to imply the Hurd was a step
-      in the right direction over Unix
-    <azeem> (which is obvious, but it wasn't obvious he had that opinion)
-
-
-## IRC, OFTC, #debian-hurd, 2013-08-13
-
-    <azeem> so cgroups seems to be most prominent thing the systemd people
-      think the Hurd lacks
-    <tschwinge> azeem: In 2010, I came to the same conclusion,
-      <http://www.gnu.org/software/hurd/open_issues/systemd.html>.  ;-)
-    <azeem> heh
-    <tschwinge> I don't think of any show-stopper for implementing that -- just
-      someone to do it.
-    <youpi> azeem: which part of cgroups, like being able to kill a cgroup?
-    <youpi> it shouldn't be very hard to implement what systemd needs
-    <azeem> probably also the resource allocation etc.
-    <azeem> the questions are I guess (i) do the cgroups semantics make sense
-      from our POV and/or do we accept that cgroups is the "standard" now and
-      (ii) should systemd require concrete implementations or just the concept
-      in a more abstract sense
-    <teythoon> being the first non Linux OS that runs systemd would be a nice
-      showcase of Hurds flexibility
-    <azeem> maybe upstart is less trouble
-    <pinotree> azeem: possibly
-    <azeem> teythoon: can you just include upstart in your GSOC? kthxbye
-    <pinotree> at least libnih (the library with base utilities and such used
-      by upstart) required a working file monitor (and the current
-      implementation kind of exposes a fd) and certain semantics for waitid
-    <pinotree> libnih/upstart have "just" the issue of being under CLA...
-    <azeem> pinotree: yeah, true
-    <azeem> I suggested "startup" as a name for a fork
-    <pinotree> imho there would be no strict need to fork
-    <teythoon> azeem: but upstart is a lot less interesting. last time I used
-      it it wasn't even possible to disable services in a clean way
-    <pochu> pinotree: is that still so now that Scott works for google?
-    <pinotree> pochu: yeah, since it's a Canonical CLA, not rally something
-      tied to a person
-    <pinotree> (iirc)
-    <pochu> sure, but scott is the maintainer...
-    <pochu> shrug
-    <azeem> nah, scott left upstart
-    <azeem> AFAIK
-    <azeem> at least James Hunt gave a talk earlier with Steve Langasek and
-      introduced himself as the upstart maintainer
-    <azeem> also I heard in the hallway track that the upstart people are
-      somewhat interested in BSD/Hurd support as they see it as a selling point
-      against systemd
-    <pinotree> pochu: it's just like FSF CLA for GNU projects: even if the
-      maintainers/contributors change altogether, copyright assignment is still
-      FSF
-    <azeem> but their accents were kinda annoying/hard to follow so I didn't
-      follow their talk closesly to see whether they brought it up
-    <azeem> pinotree: well, it's not
-    <pochu> azeem: looking at https://code.launchpad.net/libnih, I'm not sure
-      libnih has a maintainer anymore...
-    <azeem> pinotree: first off, you're not signing over the copyright with
-      their CLA, just giving them the right to relicense
-    <azeem> pinotree: but more importantaly, the FSF announced in a legally
-      binding way that they will not take things non-free 
-    <azeem> anyway, I'll talk to the upstart guys about libnih
-
-
-### IRC, OFTC, #debian-hurd, 2013-08-15
-
-    <azeem> btw, I talked to vorlon about upstart and the Hurd
-    <azeem> so the situation with libnih is that it is basically
-      feature-complete, but still maintained by Scott
-    <azeem> upstart is leveraging it heavily
-    <azeem> and Scott was (back in the days) against patches for porting
-    <azeem> for upstart proper, Steve said he would happily take porting
-      patches
-
-
-### IRC, OFTC, #debian-hurd, 2013-11-28
-
-    <azeem> teythoon: did you see they got libnih ported to kfreebsd?
-    <azeem> http://lists.debian.org/debian-devel/2013/11/msg00395.html
-    <azeem> "I haven't started looking into Hurd yet," sounds promising
-    <teythoon> saw that
-    <teythoon> i looked at libnih too
-    <teythoon> wrote a mail about that
-
-
-## IRC, freenode, #hurd, 2013-08-26
-
-    < youpi> teythoon: I tend to agree with mbanck
-    < youpi> although another thing worth considering would be adding something
-      similar to control groups
-    < youpi> AIUI, it's one of the features that systemd really requires
-    < braunr> uhg, cgroups already
-    < braunr> youpi: where is that discussion ?
-    < youpi> it was a private mail
-    < braunr> oh ok
-    < teythoon> right, so about upstart
-    < teythoon> to be blunt, I do not like upstart, though my experience with
-      it is limited and outdated
-    < braunr> that was quick :)
-    < braunr> i assume this follows your private discussion with youpi and
-      mbank ?
-    < teythoon> I used it on a like three years old ubuntu and back then it
-      couldn't do stufft hat even sysvinit could do
-    < teythoon> there was not much discussion, mbank suggested that I could
-      work on upstart
-    < teythoon> b/c it might be easier to support than systemd
-    < teythoon> which might be very well true, then again what's the benefit of
-      having upstart? I'm really curious, I should perhaps read up on its
-      features
-    < pinotree> event-based, etc
-    < youpi> it is also about avoiding being pushed out just because we don't
-      support it?
-    < teythoon> yes, but otoh systemd can do amazing things, the featurelist of
-      upstart reads rather mondane in comparison
-    < youpi> I don't really have an opinion over either, apart from portability
-      of the code
-    < braunr> teythoon: the system requirements for systemd would take much
-      time to implement in comparison to what we already have
-    < braunr> i still have maksym's work on last year gsoc on my list
-    < braunr> waiting to push in the various libpager related patches first
-    < teythoon> so you guys think it's worthwile to port upstart?
-    < braunr> no idea
-    < braunr> teythoon: on another subject
-    < azeem_> teythoon: I like systemd more, but the hallway track at Debconf
-      seemed to imply most people like Upstart better except for the CLA
-    < azeem_> which I totally forgot to address
-    < youpi> CLA ?
-    < azeem_> contributor license agreement
-    < braunr> since you've now done very good progress, is your work available
-      in the form of ready-to-test debian packages ?
-    < teythoon> braunr: it is
-    < teythoon> braunr: http://teythoon.cryptobitch.de/gsoc/heap/debian/
-    < braunr> i remember urls in some of your mails
-    < braunr> ah thanks
-    < braunr> "cryptobitch" hum :)
-    < azeem_> in any case, everbody assumed either Upstart or Systemd are way
-      ahead of systemvinit
-    < braunr> sysvinit is really ancient :)
-    < azeem_> apart from the non-event-driven fundamental issue, a lot of
-      people critized that the failure rate at writing correct init-scripts
-      appears to be too high
-    < azeem_> one of the questions brought up was whether it makes sense to
-      continue to ship/support systemvinit once a switch is made to
-      systemd/upstart for the Linux archs
-    < azeem_> systemvinit scripts might bitrot
-    < azeem_> but anyway, I don't see a switch happen anytime soon
-    < teythoon> well, did upstart gain the capability of disabling a service
-      yet?
-    < azeem_> teythoon: no idea, but apparently:
-      http://askubuntu.com/questions/19320/recommended-way-to-enable-disable-services/20347#20347
-    < teythoon> azeem_: then there is hope yet ;)
-    < azeem_> the main selling point of Upstart is that it shipped in several
-      LTS releases and is proven technology (and honestly, I don't read a lot
-      of complaints online about it)
-    < azeem_> (I don't agree that SystemD is unproven, but that is what the
-      Upstart guys implied)
-    < teythoon> am I the only one that thinks that upstart is rather
-      unimpressive?
-     * azeem_ doesn't have an opinion on it
-    < azeem> teythoon:
-      http://penta.debconf.org/dc13_schedule/events/1027.en.html has slides and
-      the video
-    < azeem> teythoon: eh, appears the link to the slides is broken, but they
-      are here:
-      http://people.canonical.com/~jhunt/presentations/debconf13/upstart-debconf-2013.pdf
-    < braunr> teythoon: actually, from the presentation, i'd tend to like
-      upstart
-    < braunr> dependency, parallelism and even runlevel compatibility flows
-      naturally from the event based model
-    < braunr> sysv compatibility is a great feature
-    < braunr> it does look simple
-    < braunr> i admit it's "unimpressive" but do we want an overkill init
-      system ?
-    < braunr> teythoon: what makes you not like it ?
-    < azeem> Lennart critized that upstart doesn't generate events, just
-      listens to them
-    < azeem> (which is a feature, not a bug to some)
-    < braunr> azeem: ah yes, that could be a lack
-    < azeem> braunr: http://penta.debconf.org/dc13_schedule/events/983.en.html
-      was the corresponding SystemD talk by Lennart, though he hasn't posted
-      slides yet I think
-    < teythoon> braunr: well, last time I used it it was impossible to cleanly
-      disable a service
-    < teythoon> also ubuntu makes such big claims about software they develop,
-      and when you read up on them it turns out that most of the advertised
-      functionality will be implemented in the near future
-    < teythoon> then they ship software as early as possible only to say later
-      that is has proven itself for so many years
-    < teythoon> and tbh I hate to be the one that helped port upstart to hurd
-      (and maybe kfreebsd as a byproduct) and later debian choses upstart over
-      systemd b/c it is available for all debian kernels
-    < kilobug> teythoon: ubuntu has a tendency to ship software too early when
-      it's not fully mature/stable, but that doesn't say anything about the
-      software itself
-    < pinotree> teythoon: note the same is sometimes done on fedora for young
-      technologies (eg systemd)
-    < azeem> teythoon: heh, fair enough
-    < p2-mate> braunr: I would prefer if my init doesn't use ptrace :P
-    < teythoon> p2-mate: does upstart use ptrace?
-    < p2-mate> teythoon: yes
-    < teythoon> well, then I guess there won't be an upstart for Hurd for some
-      time, no?
-    < kilobug> p2-mate: why does it use ptrace for ?
-    < p2-mate> kilobug: to find out if a daemon forked 
-    < kilobug> hum I see
-    < azeem> p2-mate: the question is whether there's a Hurdish way to
-      accomplish the same
-    < p2-mate>
-      http://bazaar.launchpad.net/~upstart-devel/upstart/trunk/view/head:/init/job_process.c
-    < p2-mate> see job_process_trace_new  :)
-    < kilobug> azeem: it doesn't seem too complicated to me to have a way to
-      get proc notify upstart of forks
-    < p2-mate> azeem: that's a good question. there is a linuxish way to do
-      that using cgroups
-    < azeem> right, there's a blueprint suggesting cgroups for Upstart here:
-      https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-upstart-overcome-ptrace-limitations
-    < teythoon> yes, someone should create a init system that uses cgroups for
-      tracking child processes >,<
-    < teythoon> kilobug: not sure it is that easy. who enforces that proc_child
-      is used for a new process? isn't it possible to just create a new mach
-      task that has no ties to the parent process?
-    < teythoon> azeem: what do you mean by "upstart does not generate events"?
-      there are "emits X" lines in upstart service descrpitions, surely that
-      generates event X?
-    < azeem> I think the critique is that this (and those upstart-foo-bridges)
-      are bolted on, while SystemD just takes over your systems and "knows"
-      about them first-hand
-    < azeem> but as I said, I'm not the expert on this
-    < teythoon> uh, in order to install upstart one has to remove sysvinit
-      ("yes i am sure...") and it fails to bring up the network on booting the
-      machine
-    < teythoon> also, both systemd and upstart depend on dbus, so no cookie for
-      us unless that is fixed first, right?
-    < pinotree> true
-    < teythoon> well, what do you want me to do for the next four weeks?
-    < youpi> ideally you could make both upstart and systemd work on hurd-i"86
-    < pinotree> both in 4 weeks?
-    < youpi> so hurd-i386 doesn't become the nasty guy that makes people tend
-      for one or the other
-    < youpi> I said "ideally"
-    < youpi> I don't really have any idea how much work is required by either
-      of the two
-    < youpi> I'd tend to think the important thing to implement is something
-      similar to control groups, so both upstart (which is supposed to use them
-      someday) and systemd can be happy about it
-    < teythoon> looks like upstarts functionality depending on ptrace is not
-      required, but can be enabled on a per service base
-    < teythoon> so a upstart port that just lacks this might be possible
-    < teythoon> youpi: the main feature of cgroups is that a process cannot
-      escape its group, no? i'm not sure how this could be implemented atop of
-      mach in a secure and robust way
-    < teythoon> b/c any process can just create mach tasks
-    < youpi> maybe we need to add a feature in mach itself, yes
-    < teythoon> ok, implementing cgroups sounds fun, I could do that
-    < youpi> azeem: are you ok with that direction?
-    < azeem> well, in general yes; however, AIUI, cgroups is being redesigned
-      upstream, no?
-    < youpi> that's why I said "something like cgroups"
-    < azeem> ah, ok
-    < youpi> we can do something simple enough to avoid design quesetions, and
-      that would still be enough for upstart & systemd
-    < azeem>
-      (http://www.linux.com/news/featured-blogs/200-libby-clark/733595-all-about-the-linux-kernel-cgroups-redesign)
-      btw
-    < braunr> p2-mate: upstart uses ptrace ?
-    < p2-mate> yes
-    < youpi> teythoon: and making a real survey of what needs to be fixed for
-      upstart & systemd
-    < p2-mate> see my link posted earlier
-    < braunr> ah already answered
-    < braunr> grmbl
-    < braunr> it's a simple alternative to cgroups though
-    < braunr> teythoon: dbus isn't a proble
-    < braunr> problem
-    < braunr> it's not that hard to fix
-    < youpi> well, it hasn't been fixed for a long time now :)
-    < braunr> we're being slow, that's all
-    < braunr> and interested by other things
-    < gg0> 12:58 < teythoon> btw, who is this heroxbd fellow and why has he
-      suddenly taken interest in so many debian gsoc projects?
-    < gg0> http://lists.debian.org/debian-hurd/2013/05/msg00133.html
-    < gg0> i notice nobody mentioned openrc
-    < pinotree> he's the debian student working on integrating openrc
-    < gg0> pinotree: no, the student is Bill Wang, Benda as he says is a
-      co-mentor
-      https://wiki.debian.org/SummerOfCode2013/Projects#OpenRC_init_system_in_Debian
-    < pinotree> whatever, it's still the openrc gsoc
-    < azeem> well, they wanted to look at it WRT the Hurd, did they follow-up
-      on this?
-    < gg0> btw wouldn't having openrc on hurd be interesting too?
-    < pinotree> imho not really
-    < gg0> no idea whether Bill is also trying to figure out what to do,
-      probably not
-    < azeem> somebody could ping that thread you mentioned above to see whether
-      they looked at the Hurd and/or need help/advice
-    < gg0> azeem: yeah somebody who could provide such help/advice. like.. you?
-      for instance
-     * gg0 can just paste urls
-    < azeem> they should just follow-up on-list
-
-
-## IRC, freenode, #hurd, 2013-08-28
-
-    <teythoon> anyone knows a user of cgroups that is not systemd? so far I
-      found libcg, that looks like a promising first target to port first,
-      though not surprisingly it is also somewhat linux specific
-    <taylanub> teythoon: OpenRC optionally uses cgroups IIRC.
-    <taylanub> Not mandatory because unlike systemd it actually tries (at all)
-      to be portable.
-
-
-## IRC, freenode, #hurd, 2013-09-02
-
-    <teythoon> braunr: I plan to patch gnumach so that the mach tasks keep a
-      reference to the task that created them and to make that information
-      available
-    <teythoon> braunr: is such a change acceptable?
-    <braunr> teythoon: what for ?
-    <teythoon> braunr: well, the parent relation is currently only implemented
-      in the Hurd, but w/o this information tracked by the kernel I don't see
-      how I can prevent malicious/misbehaving applications to break out of
-      cgroups
-    <teythoon> also I think this will enable us to fix the issue with tracking
-      which tasks belong to which subhurd in the long term
-    <braunr> ah cgroups
-    <braunr> yes cgroups should partly be implemented in the kernel ...
-    <braunr> teythoon: that doesn't surprise me
-    <braunr> i mean, i think it's ok
-    <braunr> the kernel should implement tasks and threads as closely as the
-      hurd (or a unix-like system) needs it
-    <teythoon> braunr: ok, cool
-    <teythoon> braunr: I made some rather small and straight forward changes to
-      gnumach, but it isn't doing what I thought it would do :/
-    <teythoon> braunr: http://paste.debian.net/33717/
-    <braunr> you added a field to task_basic_info
-    <braunr> thereby breaking the ABI
-    <teythoon> braunr: my small test program says: my task port is 1(pid 13)
-      created by task -527895648; my parent task is 31(pid 1)
-    <teythoon> braunr: no, it is not. I appended a field and these structures
-      are designed to be extendable
-    <braunr> hm
-    <braunr> ok
-    <braunr> although i'm not so sure
-    <braunr> there are macros defining the info size, depending on what you ask
-    <braunr> you may as well get garbage
-    <braunr> have you checked that ?
-    <teythoon> i initialized my struct to zero before calling mach
-    <braunr> teythoon: can you put some hardcoded value, just to make sure data
-      is correctly exported ?
-    <teythoon> braunr: right, good idea
-    <teythoon> braunr: my task port is 1(pid 13) created by task 3; my parent
-      task is 31(pid 1) -- so yes, hardcoding 3 works
-    <braunr> ok
-    <teythoon> braunr: also I gathered evidence that the convert_task_to_port
-      thing works, b/c first I did not have the task_reference call just before
-      that so the reference count was lowered (convert... consumes a reference)
-      and the parent task was destroyed
-    <teythoon> braunr: I must admit I'm a little lost. I tried to return a
-      reference to task rather than task->parent_task, but that didn't work
-      either
-    <teythoon> braunr: I feel like I'm missing something here
-    <teythoon> maybe I should get aquainted with the kernel debugger
-    <teythoon> err, the kernel debugger is not accepting any symbol names, even
-      though the binary is not stripped o_O
-    <teythoon> err, neither the kdb nor gdb attached to qemu translates
-      addresses to symbols, gdb at least translates symbols to addresses when
-      setting break points
-    <teythoon> how did anyone ever debug a kernel problem under these
-      conditions?
-    <braunr> teythoon: i'll have a look at it when i have some time
-
-
-## IRC, freenode, #hurd, 2013-09-03
-
-    <teythoon> :/ I believe the startup_notify interface is ill designed... an
-      translator can defer the system shutdown indefinitely
-    <braunr> it can
-    <teythoon> that's bad
-    <braunr> yes
-    <braunr> the hurd has a general tendency to trust its "no mutual trust
-      required" principle
-    <braunr> to rely on it a bit too much
-    <teythoon> well, at least it's a privileged operation to request this kind
-      of notification, no?
-    <braunr> why ?
-    <braunr> teythoon: it normally is used mostly by privileged servers
-    <braunr> but i don't think there is any check on the recipient
-    <teythoon> braunr: b/c getting the port to /hurd/init is done via
-      proc_getmsgport
-    <braunr> teythoon: ?
-    <teythoon> braunr: well, in order to get the notifications one needs the
-      msgport of /hurd/init and getting that requires root privileges
-    <braunr> teythoon: oh ok then
-    <braunr> teythoon: what's bad with it then ?
-    <teythoon> braunr: even if those translators are somewhat trusted, they can
-      (and do) contain bugs and stall the shutdown
-    <teythoon> I think this even happened to me once, I think it was the pfinet
-      translator
-    <braunr> teythoon: how do you want it to behave instead ?
-    <teythoon> braunr: well, /hurd/init notifies the processes sequentially,
-      that seems suboptimal, better to send async notifications to all of them
-      and then to collect all the answers
-    <teythoon> braunr: if one fails to answer within a rather large time frame
-      (say 5 minutes) shutdown anyway
-    <braunr> i agree with async notifications but
-    <braunr> i don't agree with the timeout
-    <teythoon> for reference, a (voluntary) timeout of 1 minute is hardcoded in
-      /hurd/init
-    <braunr> the timeout should be a parameter
-    <braunr> it's common on large machines to have looong shutdown delays
-    <teythoon> of the notification?
-    <braunr> the answer means "ok i'm done you can shutdown"
-    <braunr> well this can take long
-    <braunr> most often, administrators simply prefer to trust their program is
-      ok and won't take longer than it needs to, even if it's long
-    <teythoon> and not answering at all causes the shutdown / reboot to fail
-      making the system hang
-    <braunr> i know
-    <teythoon> in a state where it is not easily reached if you do not have
-      access to it
-    <braunr> but since it only concerns essential servers, it should befine
-    <braunr> essential servers are expected to behave well
-    <teythoon> it concerns servers that have requested a shutdown notification
-    <braunr> ok so no essential but system servers
-    <teythoon> essential servers are only exec, proc, /
-    <teythoon> yes
-    <braunr> the same applies
-    <pinotree> init and auth too, no?
-    <teythoon> yes
-    <braunr> you expect root not to hang himself
-    <teythoon> I do expect all software to contain bugs
-    <braunr> yes but you also expect them to provide a minimum level of
-      reliability
-    <braunr> otherwise you can just throw it all away
-    <teythoon> no, not really
-    <braunr> well
-    <teythoon> I know, that's my dilemma basically ;)
-    <braunr> if you don't trust your file system, you make frequent backups
-    <braunr> if you don't trust your shutdown code, you're ready to pull the
-      plug manually
-    <braunr> (or set a watchdog or whatever)
-    <braunr> what i mean is
-    <braunr> we should NEVER interfere with a program that is actually doing
-      its job just because it seems too long
-    <braunr> timeouts are almost never the best solution
-    <braunr> they're used only when necessary
-    <braunr> e.g. across networks
-    <braunr> it's much much much worse to interrupt a proper shutdown process
-      because it "seems too long" than just trust it behaves well 99999%%%% of
-      the time
-    <braunr> in particular because this case deals with proper data flushing,
-      which is an extremely important use case
-    <teythoon> it's hard/theoretically impossible to distinguish between taking
-      long and doing nothing
-    <braunr> it's impossible
-    <braunr> agreed
-    <braunr> => trust
-    <braunr> if you don't trust, you run real time stuff
-    <braunr> and you don't flush data on disk
-    <teythoon> ^^
-    <braunr> (which makes a lot of computer uses impossible as well)
-    <teythoon> there are only 2 people I trust, and the other one is not
-      /hurd/pfinet
-    <braunr> if this shutdown procedure is confined to the TCB, it's fine to
-      trust it goes well
-    <teythoon> tcb?
-    <braunr> trusted computing base
-    <braunr> http://en.wikipedia.org/wiki/Trusted_computing_base
-    * teythoon shudders
-    <teythoon> "trust" is used way to much these days
-    <teythoon> and I do not like the linux 2.0 ip stack to be part of our TCB
-    <braunr> basically, on a multiserver system like the hurd, the tcb is every
-      server on the path to getting a service done from a client
-    <braunr> then make it not request to be notified
-    <braunr> or make two classes of notifications
-    <braunr> because unprivileged file systems should be notified too
-    <teythoon> indeed
-    <teythoon> by the way, we should have a hurdish libnotify or something for
-      this kind of notifications
-    <braunr> but in any case, it should really be policy
-    <braunr> we should ... :)
-    <teythoon> ^^
-
-
-## IRC, freenode, #hurd, 2013-09-04
-
-    <teythoon> braunr: btw, I now believe that no server that requested
-      shutdown notifications can stall the shutdown for more than 1 minute
-      *unless* its message queue is full
-    <teythoon> so any fs should better sync within that timeframe
-    <braunr> where is this 1 min defined ?
-    <teythoon> init/init.c search for 60000
-    <braunr> ew
-    <teythoon> did I just find the fs corruption bug everyone was looking for?
-    <braunr> no
-    <braunr> what corruption bug ?
-    <teythoon> not sure, I thought there was still some issues left with
-      unclean filesystems every now and then
-    <teythoon> *causing
-    <braunr> yes but we know the reasons
-    <teythoon> ah
-    <braunr> involving some of the funniest names i've seen in computer
-      terminology :
-    <braunr> writeback causing "message floods", which in turn create "thread
-      storms" in the servers receiving them
-    <teythoon> ^^ it's usually the other way around, storms causing floods >,,
-    <braunr> teythoon: :)
-    <braunr> let's say it's a bottom-up approach
-    <teythoon> then the fix is easy, compile mach with -DMIGRATING_THREADS :)
-    <braunr> teythoon: what ?
-    <teythoon> well, that would solve the flood/storm issue, no?
-    <braunr> no
-    <braunr> the real solution is proper throttling
-    <braunr> which can stem from synchronous rpc (which is the real property we
-      want from migrating threads)
-    <braunr> but the mach writeback interface is async
-    <braunr> :p
-
-
-## IRC, freenode, #hurd, 2013-09-05
-
-    <braunr> teythoon: oh right, forgot about your port issue
-    <teythoon> don't worry, I figured by now that this must be a pointer
-    <teythoon> and I'm probably missing some magic that transforms this into a
-      name for the receiver
-    <teythoon> (though I "found" this function by looking at the mig
-      transformation for ports)
-    <braunr> i was wondering why you called the convert function manually
-    <braunr> instead of simply returning the task
-    <braunr> and let mig do the magic
-    <teythoon> b/c then I would have to add another ipc call, no?
-    <braunr> let me see the basic info call again
-    <braunr> my problem with this code is that it doesn't take into account the
-      ipc space of the current task
-    <braunr> which means you probably really return the ipc port
-    <braunr> the internal kernel address of the struct
-    <braunr> indeed, ipc_port_t convert_task_to_port(task)
-    <braunr> i'd personally make a new rpc instead of adding it to basic info
-    <braunr> basic info doesn't create rights
-    <braunr> what you want to achieve does
-    <braunr> you may want to make it a special port
-    <braunr> i.e. a port created at task creation time
-    <teythoon> y?
-    <braunr> it also means you need to handle task destruction and reparent
-    <teythoon> yes, I thought about that
-    <braunr> see
-      http://www.gnu.org/software/hurd/gnumach-doc/Task-Special-Ports.html#Task-Special-Ports
-    <braunr> for now you may simply turn the right into a dead name when the
-      parent dies
-    <braunr> although adding a call and letting mig do it is simpler
-    <braunr> mig handles reference counting, users just need to task_deallocate
-      once done
-    <teythoon> o_O mig does reference counting of port rights?
-    <braunr> mig/mach_msg
-    <teythoon> is there anything it *doesn't* do?
-    <braunr> i told you, it's a very complicated messaging interface
-    <braunr> coffee ?
-    <braunr> fast ?
-    <teythoon> ^^
-    <braunr> mig knows about copy_send/move_send/etc...
-    <braunr> so even if it doesn't do reference counting explicitely, it does
-      take care of that
-    <teythoon> true
-    <braunr> in addition, the magic conversions are intended to both translate
-      names into actual structs, and add a temporary reference at the same time
-    <braunr> teythoon: everything clear now ? :)
-    <teythoon> braunr: no, especially not why you suggested to create a special
-      port. but this will have to wait for tomorrow ;)
-
-
-## IRC, OFTC, #debian-hurd, 2013-09-06
-
-    <vorlon> teythoon: hi there
-    <vorlon> so I've been following your blog entries about cgroups on
-      hurd... very impressive :)
-    <vorlon> but I think there's a misunderstanding about upstart and
-      cgroups... your "conjecture" in
-      https://teythoon.cryptobitch.de/posts/what-will-i-do-next-cgroupfs-o/ is
-      incorrect
-    <vorlon> cgroups does not give us the interfaces that upstart uses to
-      define service readiness; adding support for cgroups is interesting to
-      upstart for purposes of resource partitioning, but there's no way to
-      replace ptrace with cgroups for what we're doing
-    <teythoon> vorlon: hi and thanks for the fish :)
-    <teythoon> vorlon: what is it exactly that upstart is doing with ptrace
-      then?
-    <teythoon> .,oO( your nick makes me suspicious for some reason... ;)
-    <teythoon> service readiness, what does that mean exactly?
-    <vorlon> teythoon: so upstart uses ptrace primarily for determining service
-      readiness.  The idea is that traditionally, you know an init script is
-      "done" when it returns control to the parent process, which happens when
-      the service process has backgrounded/daemonized; this happens when the
-      parent process exits
-    <vorlon> in practice, however, many daemons do this badly
-    <vorlon> so upstart tries to compensate, by not just detecting that the
-      parent process has exited, but that the subprocess has exited
-    <vorlon> (for the case where the upstart job declares 'expect daemon')
-    <vorlon> cgroups, TTBOMK, will let you ask "what processes are part of this
-      group" and possibly even "what process is the leader for this group", but
-      doesn't really give you a way to detect "the lead process for this group
-      has changed twice"
-    <vorlon> now, it's *better* in an upstart/systemd world for services to
-      *not* daemonize and instead stay running in the foreground, but then
-      there's the question of how you know the service is "ready" before moving
-      on to starting other services that depend on it
-    <vorlon> systemd's answer to this is socket-based activation, which we
-      don't really endorse for upstart for a variety of reasons
-    <teythoon> hm, okay
-    <teythoon> so upstart does this only if expect daemon is declared in the
-      service description?
-    <vorlon> (in part because I've seen security issues when playing with the
-      systemd implementation on Fedora, which Lennart assures me are
-      corner-cases specific to cups, but I haven't had a chance to test yet
-      whether he's right)
-    <teythoon> and it is not used to track children, but only to observe the
-      daemonizing process?
-    <vorlon> yes
-    <teythoon> and it then detaches from the processes?
-    <vorlon> yes
-    <vorlon> once it knows the service is "ready", upstart doesn't care about
-      tracking it; it'll receive SIGCHLD when the lead process dies, and that's
-      all it needs to know
-    <teythoon> ok, so I misunderstood the purpose of the ptracing, thanks for
-      clarifying this
-    <vorlon> my pleasure :)
-    <vorlon> I realize that doesn't really help with the problem of hurd not
-      having ptrace
-    <teythoon> no, but thanks anyway
-    <vorlon> fwiw, the alternative upstart recommends for detecting service
-      readiness is for the process to raise SIGSTOP when it's ready
-    <vorlon> doesn't require ptracing, doesn't require socket-based activation
-      definitions; does require the service to run in a different mode than
-      usual where it will raise the signal at the correct time
-    <teythoon> right, but that requires patching it, same as the socket
-      activation stuff of systemd
-    <vorlon> (this is upstart's 'expect stop')
-    <vorlon> yes
-    <vorlon> though at DebConf, there were some evil ideas floating around
-      about doing this with an LD_PRELOAD or similar ;)
-    <vorlon> (overriding 'daemonize')
-    <vorlon> er, 'daemon()'
-    <teythoon> ^^
-    <vorlon> and hey, what's suspicious about my /nick? vorlons are always
-      trustworthy
-    <vorlon> ;)
-    <teythoon> sure they are
-    <teythoon> but could this functionality be reasonably #ifdef'ed out for a
-      proof of concept port?
-    <vorlon> hmm, you would need to implement some kind of replacement... if
-      you added cgroups support to upstart as an alternative
-    <vorlon> that could work
-    <vorlon> i.e., you would need upstart to know when the service has exited;
-      if you aren't using ptrace, you don't know the "lead pid" to watch for,
-      so you need some other mechanism --> cgroups
-    <vorlon> and even then, what do you do for a service like openssh, which
-      explicitly wants to leave child processes behind when it restarts?
-    <teythoon> right...
-    <vorlon> oh, I was hoping you knew the answer to this question ;)  Since
-      AFAICS, openssh has no native support for cgroups
-    <teythoon> >,< I don't, but I'll think about what you've said... gotta go,
-      catch what's left of the summer ;)
-    <teythoon> fwiw I consider fork/exec/the whole daemonizing stuff fubar...
-    <teythoon> see you around :)
-    <vorlon> later :)
-
-
-## IRC, OFTC, #debian-hurd, 2013-09-07
-
-    <teythoon> vorlon: I thought about upstarts use of ptrace for observing the
-      daemonizing process and getting hold of the child
-    <teythoon> vorlon: what if cgroup(f)s would guarantee that the order of
-      processes listed in x/tasks is the same they were added in?
-    <teythoon> vorlon: that way, the first process in the list would be the
-      daemonized child after the original process died, no?
-    <vorlon> teythoon: that doesn't tell you how many times the "lead" process
-      has changed, however
-    <vorlon> you need synchronous notifications of the forks in order to know
-      that, which currently we only get via ptrace
-
-
-## IRC, OFTC, #debian-hurd, 2013-09-08
-
-    <teythoon> vorlon: ok, but why do the notifications have to be synchronous?
-      does that imply that the processes need to be stopped until upstart does
-      something?
-    <vorlon> teythoon: well, s/synchronous/reliable/
-    <vorlon> you're right that it doesn't need to be synchronous; but it can't
-      just be upstart polling the status of the cgroup
-    <vorlon> because processes may have come and gone in the meantime
-    <teythoon> vorlon: ok, cool, b/c the notifications of process changes I'm
-      hoping to introduce into the proc server for my cgroupfs do carry exactly
-      this kind of information
-    <vorlon> cool
-    <vorlon> are you discussing an API for this with the Linux cgroups
-      maintainers?
-    <teythoon> otoh it would be somewhat "interesting" to get upstart to use
-      this b/c of the way the mach message handling is usually implemented
-    <vorlon> :)
-    <teythoon> no, I meant in order for me to be able to implement cgroupfs I
-      had to create these kind of notifications, it's not an addition to the
-      cgroups api
-    <teythoon> is upstart multithreaded?
-    <vorlon> no
-    <vorlon> threads are evil ;)
-    <teythoon> ^^ I mostly agree
-    <vorlon> it uses a very nice event loop, leveraging signalfd among other
-      things
-    <teythoon> uh oh, signalfd sounds rather Linuxish
-    <pinotree> it is
-    <vorlon> I think xnox mentioned when he was investigating it that kfreebsd
-      now also supports it
-    <vorlon> but yeah, AFAIK it's not POSIX
-    <pinotree> it isn't, yes
-    <vorlon> but it darn well should be
-    <vorlon> :)
-    <vorlon> it's the best improvement to signal handling in a long time
-    <teythoon> systemd also uses signalfd
-    <teythoon> umm, it seems I was wrong about Hurd not having ptrace, the wiki
-      suggests that we do have it
-    <pinotree> FSVO "have"
-    <teythoon> ^^
-    <xnox> vorlon: teythoon: so ok kFreeBSD/FreeBSD ideally I'd be using
-      EVFILT_PROC from kevent which allows to receive events & track: exit,
-      fork, exec, track (follow across fork)
-    <xnox> upstart also uses waitid()
-    <xnox> so a ptrace/waitid should be sufficient to track processes, if Hurd
-      has them.
-
-
-## IRC, freenode, #hurd, 2013-09-09
-
-    <youpi> teythoon: yes, the shutdown notifications do stall the process
-    <youpi> but no more than a minute, or so
-    <youpi> teythoon: btw, did you end up understanding the odd thing in
-      fshelp_start_translator_long?
-    <youpi> I haven't had the time to have a look
-    <teythoon> youpi: what odd thing? the thing about being implemented by hand
-      instead of using the mig stub?
-    <youpi> the thing about the port being passed twice
-    <youpi> XXX this looks wrong to me, please have a look
-    <youpi> in the mach_port_request_notification call
-    <teythoon> ah, that was alright, yes
-    <youpi> ok
-    <youpi> so I can drop it from my TODO :)
-    <teythoon> this is done on the control port so that a translator is
-      notified if the "parent" translator dies
-    <teythoon> was that in fshelp_start_translator_long though? I thought that
-      was somewhere else
-    <youpi> that's what the patch file says
-    <youpi> +++ b/libfshelp/start-translator-long.c
-    <youpi> @@ -293,6 +293,7 @@ fshelp_start_translator_long (fshelp_open_fn_t
-      underlying_open_fn,
-    <youpi> +  /* XXX this looks wrong to me, bootstrap is used twice as
-      argument... */
-    <youpi>                                    bootstrap,
-      MACH_NOTIFY_NO_SENDERS, 0,
-    <teythoon> right
-    <teythoon> I remember that when I got a better grip of the idea of
-      notifications I figured that this was indeed okay
-    <teythoon> I'll have a quick look though
-    <youpi> ok
-    <teythoon> ah, I remember, this notifies the parent translator if the child
-      dies, right
-    <teythoon> and it is a NO_SENDERS notification, so it is perfectly valid to
-      use the same port twice, as we only hold a receive right
-
-
-## IRC, freenode, #hurd, 2013-09-10
-
-    <teythoon> braunr: are pthreads mapped 1:1 to mach threads?
-    <braunr> teythoon: yes
-    <teythoon> I'm reading the Linux cgroups "documentation" and it talks about
-      tasks (Linux threads) and thread group IDs (Linux processes) and I'm
-      wondering how to map this accurately onto Hurd concepts...
-    <teythoon> apparently on Linux there are PIDs/TIDs that can be used more or
-      less interchangeably from userspace applications
-    <teythoon> the Linux kernel however knows only PIDs, and each thread has
-      its own, and those threads belonging to the same (userspace) PID have the
-      same thread group id
-    <teythoon> aiui on Mach threads belong to a Mach task, and there is no
-      global unique identifier exposed for threads, right?
-    <teythoon> braunr: ^
-    <tschwinge> teythoon: There is its thread port, which in combination with
-      its task port should make it unique?  (I might be missing context.)
-    <tschwinge> Eh, no.  The task port's name will only locally be unique.
-    * tschwinge confused himself.
-    <teythoon> tschwinge, braunr: well, the proc server could of course create
-      TIDs for threads the same way it creates PIDs for tasks, but that should
-      probably wait until this is really needed
-    <teythoon> for the most part, the tasks and cgroup.procs files contain the
-      same information on Linux, and not differentiating between the two just
-      means that cgroupfs is not able to put threads into cgroups, just
-      processes
-    <teythoon> that might be enough for now
-
-
-## IRC, freenode, #hurd, 2013-09-11
-
-    <teythoon> ugh, some of the half-backed Linux interfaces will be a real
-      pain in the ass to support
-    <teythoon> they do stuff like write(2)ing file descriptors encoded as
-      decimal numbers for notifications :-/
-    <braunr> teythoon: for cgroup ?
-    <teythoon> braunr: yes, they have this eventfd based notification mechanism
-    <teythoon> braunr: but I fear that this is a more general problem
-    <braunr> do we need eventfd ?
-    <teythoon> I mean passing FDs around is okay, we can do this just fine with
-      ports too, but encoding numbers as an ascii string and passing that
-      around is just not a nice interface
-    <braunr> so what ?
-    <teythoon> it's not a designed interface, it's one people came up with b/c
-      it was easy to implement
-    <braunr> if it's meant for compatibility, that's ok
-    <teythoon> how would you implement this then? as a special case in the
-      write(2) implementation in the libc? that sounds horrible but I do hardly
-      see another way
-    <teythoon> ok, some more context: the cgroup documentation says
-    <teythoon> write "<event_fd> <control_fd> <args>" to cgroup.event_control.
-    <teythoon> where event_fd is the eventfd the notification should be sent to
-    <pinotree> theorically they could have used sendmsg + a custom payload
-    <teythoon> control_fd is an fd to the pseudo file one wants notifications
-      for
-    <teythoon> yes, they could have, that would have been nicer to implement
-    <teythoon> but this...
-
-
-## IRC, freenode, #hurd, 2013-09-12
-
-    <teythoon> ugh, gnumachs build system drives me crazy %-/
-    <pinotree> oh there's worse than that
-    <teythoon> I added a new .defs file, did as Makerules.mig.am told me to do,
-      but it still does not create the stubs I need
-    <braunr> teythoon: gnumach doesn't
-    <braunr> teythoon: glibc does
-    <braunr> well, gnumach only creates the stubs it needs
-    <braunr> teythoon: you should perhaps simply use gnumach.defs
-    <teythoon> braunr: sure it does, e.g. vm/memory_object_default.user.c
-    <braunr> teythoon: what are you trying to add ?
-    <teythoon> braunr: I was trying to add a notification mechanism for new
-      tasks
-    <teythoon> b/c now the proc server has to query all task ports to discover
-      newly created tasks, this seems wasteful
-    <teythoon> also if the proc server could be notified on task creation, the
-      parent task is still around, so the notification can carry a reference to
-      it
-    <teythoon> that way gnumach wouldn't have to track the relationship, which
-      would create all kind of interesting questions, like whether tasks would
-      have to be reparented if the parent dies
-    <braunr> teythoon: notifications aren't that simple either
-    <teythoon> y not?
-    <braunr> 1/ who is permitted to receive them
-    <braunr> 2/ should we contain them to hurd systems ? (e.g. should a subhurd
-      receive notifications concerning tasks in other hurd systems ?)
-    <teythoon> that's easy imho. 1/ a single process that has a host_priv
-      handle is able to register for the notifications once
-    <braunr> what are the requirements so cgroups work as expected concerning
-      tasks ?
-    <braunr> teythoon: a single ?
-    <teythoon> i.e. the first proc server that starts
-    <braunr> then how will subhurd proc servers work ?
-    <teythoon> 2/ subhurds get the notifications from the first proc server,
-      and only those that are "for them"
-    <braunr> ok
-    <braunr> i tend to agree
-    <braunr> this removes the ability to debug the main hurd from a subhurd
-    <teythoon> this way the subhurds proc server doesn't even have to have the
-      host_priv porsts
-    <teythoon> yes, but I see that as a feature tbh
-    <braunr> me too
-    <braunr> and we can still debug the subhurd from the main
-    <teythoon> it still works the other way around, so it's still...
-    <teythoon> yes
-    <braunr> what would you include in the notification ?
-    <teythoon> a reference to the new task (proc needs that anyway) adn one to
-      the parent task (so proc knows what the parent process is and/or for
-      which subhurd it is)
-    <braunr> ok
-    <braunr> 17:21 < braunr> what are the requirements so cgroups work as
-      expected concerning tasks ?
-    <braunr> IOW, why is the parental relation needed ?
-    <braunr> (i don't know much about the details of cgroup)
-    <teythoon> well, currently we rely on proc_child to build this relation
-    <teythoon> but any task can use task_create w/o proc_child
-    <teythoon> until one claims a newly created task with proc_child, its
-      parent is pid 1
-    <braunr> that's about the hurd
-    <braunr> i'm rather asking about cgroups
-    <teythoon> ah
-    <teythoon> the child process has to end up in the same cgroup as the parent
-    <braunr> does a cgroup include its own pid namespace ?
-    <teythoon> not quite sure what you mean, but I'd say no
-    <teythoon> do you mean pid namespace as in the Linux sense of that phrase?
-    <teythoon> cgroups group processes(threads) into groups
-    <teythoon> on Linux, you can then attach controllers to that, so that
-      e.g. scheduling decisions or resource restrictions can be applied to
-      groups
-    <teythoon> braunr: http://paste.debian.net/38950/
-    <braunr> teythoon: ok so a cgroup is merely a group of processes supervised
-      by a controller
-    <braunr> for resource accounting/scheudling
-    <braunr> teythoon: where does dev_pager.c do the same ?
-    <teythoon> braunr: yes. w/o such controllers cgroups can still be used for
-      subprocess tracking
-    <teythoon> braunr: well, dev_pager.c uses mig generated stubs from
-      memory_object_reply.defs
-    <braunr> ah memory_object_reply ok
-    <braunr> teythoon: have you tried adding it to EXTRA_DIST ?
-    <braunr> although i don't expect it will change much
-    <braunr> teythoon: hum, you're not actually creating client stubs
-    <braunr> create a kern/task_notify.cli file
-    <braunr> as it's done with device/memory_object_reply.cli
-    <braunr> see #define KERNEL_USER 1
-    <teythoon> braunr: right, thanks :)
-
-
-## IRC, freenode, #hurd, 2013-09-13
-
-    <teythoon> hm, my notification system for newly created tasks kinda works
-    <teythoon> as in I get notified when a new task is created
-    <teythoon> but the ports for the new task and the parent that are carried
-      in the notification are both MACH_PORT_DEAD
-    <teythoon> do I have to add a reference manually before sending it?
-    <teythoon> that would make sense, the mig magic transformation function for
-      task_t consumes a reference iirc
-    <braunr> ah yes
-    <braunr> that reference counting stuff is some hell
-    <teythoon> braunr: ah, there's more though, the mig transformations are
-      only done in the server stub, not in the client, so I still have to
-      convert_task_to_port myself afaics
-    <teythoon> awesome, it works :)
-    <braunr> :)
-    <teythoon> ugh, the proc_child stuff is embedded deep into libc and signal
-      handling stuff...
-    <teythoon> "improving" the child_proc stuff with my shiny new notifications
-      wrecks havoc on the system
-
-
-## IRC, freenode, #hurd, 2014-01-03
-
-    <gg0> openrc on debian
-      https://buildd.debian.org/status/package.php?p=openrc&suite=experimental
-    <braunr> gg0: ah nice
-
-
-## IRC, freenode, #hurd, 2014-01-11
-
-    <gnu_srs1> teythoon: is the Hurd boot now fully init compatible? I would
-      like to try to boot with a ported openrc in a sandbox kvm:P
-
-
-### IRC, freenode, #hurd, 2014-01-12
-
-    <teythoon> gnu_srs1: yes, go ahead
-    <teythoon> gnu_srs1: you'll have to switch to sysvinit first
-    <teythoon> for that, you need patched sysvinit packages
-
-    <gnu_srs> teythoon: do you mean the parches in #721917?
-    <teythoon> gnu_srs: yes, mostly, but there is one final patch missing
-    <gg0> uploading patched sysvinit to debian-ports? (or braunr's or
-      teythoon's repos)
-    <teythoon> gg0, gnu_srs: they are actually here
-      http://teythoon.cryptobitch.de/gsoc/heap/debian/ but outdated
-    <gnu_srs> teythoon: if the sysvinit patches are outdated, can you update
-      them please? and provide a package for upload to -ports (as gg0 proposed)
-    <teythoon> gnu_srs: i will
-    <gnu_srs> tks:)
-
-
-### IRC, freenode, #hurd, 2014-01-13
-
-    <teythoon> gnu_srs: i updated the sysvinit patches
-    <teythoon> gnu_srs: for your convenience, here are packages:
-      http://darnassus.sceen.net/~teythoon/heap/sysvinit/
-    <teythoon> gnu_srs: you have to install the sysvinit-core package first,
-      then the others
-    <teythoon> to switch to sysvinit, do update-alternatives --config runsystem
-      and select runsystem.sysv
-    <teythoon> then, do reboot-hurd and hope for the best ;)
-
-    <gnu_srs> teythoon: thanks, will try soon. Are you submitting the updated
-      patches to #721917 too?
-    <teythoon> gnu_srs: i already did
-    <gnu_srs> good;-)
-    <gnu_srs> teythoon: rebooted with sysv:http://paste.debian.net/75925/
-    <teythoon> gnu_srs: please, whenever you run into a problem, give more
-      context
-    <teythoon> which file are you talking about ?
-    <teythoon> also, as the postinst script advised you, you need to use
-      {halt,reboot}-hurd *whenever* you switch the runsystem
-    <teythoon> not doing so wont do any harm, but it wont work
-    <teythoon> shutdown: /run/initctl: No such file or directory  <-- that's
-      what happens if you run reboot (=reboot-sysv) w/o sysvinit being run
-    <teythoon> if you don't get a getty on the console, check /etc/inittab
-    <gnu_srs> I did note see a message from any posinst script about
-      {halt,reboot}-hurd, only LC* related messages
-    <gnu_srs> A I missed it: You must use halt-hurd or reboot-hurd to halt or
-      reboot the
-    <gnu_srs> system whenever you change the runsystem.
-    <gnu_srs> I don't see anything suspicious in /etc/inittab,
-      eg. 1:2345:respawn:/sbin/getty 38400 tty1 is there
-    <teythoon> 7:2345:respawn:/sbin/getty 38400 console
-    <teythoon> then, you'll get a getty on the mach console, even if the
-      hurd-console does not start
-    <gnu_srs> teythoon: with 7:2345:respawn:/sbin/getty 38400 console in
-      /etc/inittab I get a (mach) console.
-    <gnu_srs> never seen that mentioned anywhere
-    <gnu_srs> anyway, the image is now booted with sysvinit. next to try will
-      be openrc:P
-    <teythoon> gnu_srs: you haven't heard of the inittab entry for the mach
-      console before b/c the inittab was not used before on the hurd
-    <teythoon> i should probably write that down in the wiki somewhere...
-    <youpi> shouldn't the upgrade of the sysvinit package do it too?
-    <youpi> (does it at least install a correct version on newer installs?)
-    <teythoon> it probably should / i'm not sure
-
-
-## IRC, freenode, #hurd, 2014-01-13
-
-    <teythoon> gnu_srs: have you ported openrc already ?
-    <gnu_srs> I made it build (with temporary workarounds for PATH_MAX) but
-      need to change at least one file to be hurd-specific before trying to
-      boot
-    <teythoon> cool :)
-    <gg0> i guess not much different from http://paste.debian.net/plain/75893/
-    <gg0> (i didn't say it sucks but one can find it out by taking a look)
-    <gnu_srs> gg0: Have you talked to zigo in #openrc?. He has partial patches
-      (submitted to the debian repo), you do and me too.
-    <gnu_srs> Maybe we should align our work.
-    <gnu_srs> The file to make Hurd-specific  is: init.sh.GNU (you start with
-      copy of the Linux version, I start from a copy of the BSD version).
-    <gnu_srs> BTW: I don't think fstabinfo is available for GNU/Hurd!
-    <gnu_srs> gg0: Sorry, fstabinfo and moutinfo are parts of openrc, my bad:-D
-    <gnu_srs> mountinfo*
-
-
-## IRC, freenode, #hurd, 2014-01-15
-
-    <gnu_srs> Hi, is these some simple way to find out the sequence of commands
-      executed during boot:
-    <gnu_srs> current using runsystem.gnu and with sysv-rc using runsystem.sysv
-    <gnu_srs> I need to edit on file of OpenRC before trying to boot with
-      it. (mainly mounting /run/*)
-    <gnu_srs> Is mount functional or is settrans .needed?
-
-
-## IRC, freenode, #hurd, 2014-01-16
-
-    <ArneBab> gnu_srs: you are adding OpenRC? cool!
-    <gnu_srs> ArneBab: Working on it, will try booting when my questions here
-      have been answered ;-)
-    <teythoon> gnu_srs: mount is functional enough to boot Debian/Hurd using
-      sysvinit
-    <teythoon> gnu_srs: you could add "set -x" to runsystem.*, or add "bash" to
-      just drop into a shell and examine the environment interactively
-    <gnu_srs> teythoon: Hi, is mount a wrapper on top of settrans ...? 
-    <teythoon> yes
-    <gnu_srs> how to log the boot sequence, when booting the mach console is
-      cleared when the hurd console starts?
-    <teythoon> you could just disable the hurd console
-    <gnu_srs> and the kvm console does not have scrolling functionality
-    <teythoon> it's actually the mach console that lacks this
-    <gnu_srs> copying manually is cumbersome, even if all is readable
-    <teythoon> but as a workaround you can use kvm .... -curses and use xterms
-      backlog
-    <teythoon> and c&p works then :)
-    <gnu_srs> tks, I'll try with that:P
-
-
-## IRC, freenode, #hurd, 2014-01-17
-
-    <gnu_srs> BTW: zigo successfully booted openrc on Hurd, I haven't tried
-      yet,, you know things coming in between. He used my patches to create
-      updated ones:)
-    <gnu_srs> that version is now in experimental (I still have to operate away
-      all those PATH_MAX issues, and fins at least one sh file). 
-    <teythoon> :/
-
-
-## IRC, freenode, #hurd, 2014-01-21
-
-    <gnu_srs> teythoon: I don't get a scrollable output when using -curses in
-      kvm, to be able to see all startup messages. Any other ideas? 
-    <teythoon> gnu_srs: are you sure ? i just tested this, and it works nicely
-      for me
-    <teythoon> gnu_srs: that's how i created all the "screenshots" for my blog
-      posts
-    <gnu_srs> teythoon: kvm -m 1024 -net nic,model=rtl8139 -net
-      user,hostfwd=tcp::5564-:22 -curses -hda debian-hurd-20140115.img 
-    <teythoon> ah, my bad
-    <teythoon> gnu_srs: try -nographic
-    <teythoon> oh, and maybe you need to add console=com0 to the gnumach
-      command line
-    <teythoon> b/c with -nographic, the first serial port is connected to qemus
-      stdio
-    <teythoon> sorry, i mixed this up
-    <gnu_srs> and how to add console=com0 to the qemu start oprtions? -kernel
-      and -append are Linux only
-    <teythoon> # grep console /etc/default/grub
-    <teythoon> GRUB_CMDLINE_GNUMACH="console=com0 --crash-debug"
-    <teythoon> and if you want grub on the serial port:
-    <teythoon> # grep serial /etc/default/grub
-    <teythoon> GRUB_TERMINAL=serial
-    <teythoon> GRUB_SERIAL_COMMAND="serial --speed=9600 --unit=0 --word=8
-      --parity=no --stop=1"
-    <gnu_srs> teythoon: with -nographic I don't get any output at all?
-    <teythoon> did you run update-grub ?
-    <gnu_srs> aha, will do
-    <gnu_srs> still no scrollbar with gnome-terminal, will try with xterm and
-      rxvt
-    <gnu_srs> it works: with rxvt, tks:-D
-    <teythoon> good :)
-    <teythoon> i found -nographic to be quite handy
-    <gnu_srs> in /etc/default/grub: GRUB_CMDLINE_LINUX_DEFAULT="quiet" and
-      GRUB_CMDLINE_LINUX=""  #GRUB_DISABLE_LINUX_UUID=true
-    <gnu_srs> linux configuration parameters in a gnumach boot setup?
-    <teythoon> those won't be used
-    <teythoon> unless the grub scripts find a linux kernel in /boot
-    <teythoon> it's just the stock debian configuration file
-    <gnu_srs> nevertheless:-(
-    <teythoon> what ?
-    <gnu_srs> there could be OS-specific files: Linux, kFreeBSD, Hurd?
-    <teythoon> or, preferebly, one that works on every os ? like it is now ;)
-    <gnu_srs> OK, one that works on every OS, with a common part and
-      OS-specific parts?
-    <teythoon> that's how it is now
-    <teythoon> stuff with LINUX in it is used for linux
-    <teythoon> stuff with GNUMACH in it is used for gnumach
-
-
-## IRC, freenode, #hurd, 2014-01-22
-
-    <gnu_srs> teythoon: A boot message segfault: (syv-rc specific?)
-    <gnu_srs>  + exec /sbin/init -a
-    <gnu_srs> INIT: version 2.88 booting
-    <gnu_srs> Using makefile-style concurrent boot in runlevel S.
-    <gnu_srs> end_request: I/O error, dev 02:00, sector 0
-    <gnu_srs> Segmentation fault
-    <gnu_srs> Activating swap...done.
-    <gnu_srs> Checking root file system...fsck from util-linux 2.20.1
-    <gnu_srs> another: mount: cannot remount /proc: Invalid argument
-    <gnu_srs> ...
-    <gnu_srs> df: Warning: cannot read table of mounted file systems: No such
-      file or directory
-    <gnu_srs> openrc boots on Hurd, login (user,root) works, read-only mode so
-      far, have to tweak some scripts:)
-    <braunr> not bad
-    <ArneBab> gnu_srs: woah!
-    <ArneBab> very cool!
-
-
-## IRC, freenode, #hurd, 2014-01-22
-
-    <ArneBab> I think with that you are doing the most useful thing to avoid
-      OpenRC: If it provides almost the same as systemd and runs on the Hurd,
-      then there is no technical reason for using systemd, but many against it.
-    <ArneBab> s/avoid OpenRC/avoid systemd/
-    <ArneBab> (gah, brain is jumbled)
-    <Shentino> I hate systemd because it monopolizes cgroups
-    <Shentino> which is SUPPOSED to be a generic interface open to anyone
-    <Shentino> I do not want an unholy alliance in a kernel-user api
-    <azeem_> ArneBab: the openrc maintainer will take care it will get
-      communicated
-    <azeem_> ArneBab: also, not sure what you mean about systemd, the question
-      isn't so much between openrc vs. systemd, but upstart vs. systemd
-    <azeem_> at least for the Technical Committee decision, none of the
-      tech-ctte members seems to consider openrc as n realistic contender
-    <azeem_> s/as n/as a/
-    <gnu_srs> azeem_: seem like it is so:-(
-    <gnu_srs> maybe in a future, if openrc gets some attention and developers,
-      it could become a one-for-all solution;-)
-    <teythoon> gnu_srs: nice :)
-    <teythoon> ignore the proc related message
-    <teythoon> gnu_srs: there is no way to associate the segfault with a
-      process for me, can you shed some light on which process dies ?
-    <teythoon> as for df complaining, you could fix this up like youpi did:
-    <teythoon> grep ln /etc/hurd/rc
-    <teythoon> ln -s /proc/mounts /var/run/mtab
-    <teythoon> the proper way is to fix our libc of course
-    <gnu_srs> teythoon: I was just coping the boot messages, I don't know
-      either which process segfaults
-    <teythoon> hm, maybe you can make openrc more verbose about what it starts
-    <gnu_srs> All I wrote earlier was from sysv-rc
-    <teythoon> ah
-    <teythoon> i've never seen that then
-    <ArneBab> azeem_: actually I think OpenRC is the only sane choice: It is
-      the only choice which supports other kernels.
-    <ArneBab> Shentino: I can’t stand systemd, because it establishes a tight
-      control over the init process by encouraging developers to add
-      dependencies to libraries which are so tightly coupled with others, that
-      they cannot be adapted without affecting the whole system.
-    <ArneBab> Shentino: But I wrote about that in much more details:
-      http://draketo.de/light/english/top-5-systemd-troubles TL;DR:
-      distributions become completely dependent on a small group and they throw
-      away the skills their maintainers already have (shell scripting)
-    <ArneBab> And systemd is Linux-only… 
-    <ArneBab> …with no intention of changing that.
-    <braunr> why would debian strive to support other kernels ?
-    <braunr> instead of other kernels adjusting ?
-    <braunr> if posix introduces new apis, are we going to say no, or are we
-      going to try and support them ?
-    <braunr> the issue of multi-kernel support is completely irrelevant
-    <braunr> what you're saying about tight coupling is actually the only real
-      issue of systemd
-    <ArneBab> braunr: I see a difference between providing a stable API which
-      others can easily replicate and a running target with no intention to
-      become cross-kernel usable (my experience with udev suggests that they
-      won’t really try to keep anything stable for long).
-    <ArneBab> braunr: but the tight coupling is the main issue for me, too:
-      that creates a vulnerability for the free software community.
-    <braunr> no, the free software community doesn't risk much here
-    <braunr> it's a technical problem
-    <braunr> ok, yes, posix as a point of convergence is clearly not the same
-      as linux as an implementation that diverges
-    <braunr> agreed
-    <ArneBab> if the systemd people decide to go a certain direction which
-      makes it impossible to provide a certain feature while using their new
-      tech, then there is a problem.
-    <braunr> but it still implies we have to adapt
-    <braunr> from my point of view, multi-kernel distributions are a technical
-      heresy
-    <braunr> if you want something really efficient, you want it very well
-      integrated
-    <teythoon> i'm concerned by the linux kernel making up interfaces w/o
-      proper considerations
-    <ArneBab> braunr: in Gentoo we had all the hassle with /usr on a separate
-      partition. There are usecases for that, and Gentoo wanted to provide
-      them, but udev (now systemd) made that impossible.
-    <braunr> teythoon: yes i'm concerned about that too
-    <teythoon> we will never be able to implement the cgroup interface for
-      example b/c it is too badly designed
-    <braunr> badly ?
-    <braunr> it's system specific
-    <ArneBab> braunr: also the systemd folks could essentially hold Linus at
-      ransom: “We couple userspace tightly to implementation details in the
-      kernel, so when you break the implementation in a way which we don’t
-      like, you’ll break userspace in the worst possible way”
-    <braunr> it's very hard to design an interface without properly
-      understanding what it would internally imply in the implementation
-    <braunr> ArneBab: that's already the case
-    <teythoon> system specific in a way that it will be impossible to implement
-      on non-monolithic kernels
-    <braunr> teythoon: exactly
-    <braunr> they didn't think of that because they don't care
-    <braunr> and why would they ?
-    <braunr> it doesn't make the interface bad per se
-    <ArneBab> it is the case in systemd, but not in sysVinit
-    <braunr> well it is too
-    <braunr> but sysvint is less demanding
-    <braunr> again, the coupling is the problem
-    <ArneBab> yes
-    <braunr> systemd comes from people with other goals and interests
-    <ArneBab> I think everything I wrote comes down to that.
-    <braunr> they're very technical, very business oriented
-    <braunr> they want to get up to speed with competitors quickly
-    <braunr> they're not wrong in doing that
-    <braunr> it just helps understand why they get with such results
-    <ArneBab> A distribution would be foolish to let other people take over a
-      crucial part of the system when those other people have a track record of
-      coupling more and more parts of the system with their product.
-    <braunr> and i agree, i don't want it either
-    <braunr> but please, stop with the nonsense
-    <braunr> don't say openrc is the only sane one because it's the only
-      multikernel one
-    <braunr> personally, i consider that very argument almost insane itself
-    <braunr> considering distributions that are hardly used can really have any
-      weight in the decision is absurd
-    <ArneBab> openrc is the only sane one, because it keeps already aquired
-      skills useful.
-    <braunr> s/distributions/kernels/
-    <ArneBab> (that’s my opinion)
-    <braunr> we have to make progress
-    <braunr> the init system is clearly obsolete and lacking features
-    <braunr> so "acquired" skills here are irrelevant too
-    <braunr> if it takes acquiring new skills to operate a better init system,
-      i'm all for it
-    <braunr> after all, it makes a lot more sense to me than all those fancy
-      languages/technologies like C# and ruby that have gained so much
-      popularity in so little time
-    <ArneBab> If you can get a similarly good init system wiothut forcing
-      people to learn new skills, that’s a big win.
-    <braunr> you probably can't
-    <ArneBab> OpenRC is pretty close in features to systemd
-    <teythoon> err
-    <teythoon> not even close
-    <braunr> teythoon is right
-    <braunr> openrc is just sysvinit++
-    <teythoon> no
-    <teythoon> openrc replaces the sysv rc, not sysvinit
-    <braunr> ok
-    <teythoon> it complements it
-    <braunr> i wasn"'t being pedantic here
-    <teythoon> nicely in my opinion
-    <braunr> yes i like it too
-    <braunr> but i'm afraid it's not a complete solution
-    <ArneBab> I think I need to be more pedantic in what I say: A system-boot
-      with OpenRC is pretty close in features to a system-boot using systemd.
-    <braunr> on the other hand, when i see discussions about event driven
-      systems and handling of dependencies, it sounds like something like
-      openrc could do the job, and something else, system-specific, would
-      handle the rest
-    <braunr> ArneBab: i disagree
-    <teythoon> me too
-    <teythoon> ArneBab: have you actually used systemd?
-    <ArneBab> I have read about what it provides.
-    <ArneBab> My udev experience burned me pretty badly.
-    <braunr> udev is only one part
-    <braunr> but actually, coupling is both a problem and a great feature
-    <teythoon> yes
-    <braunr> it's precisely the integration of many services previously
-      organized in a very messy way that makes it better
-    <braunr> and cgroups, by accurately tracking resources, allow even better
-      control
-    <teythoon> heh, i watched lennarts recent talk about kdbus
-    <ArneBab> but it does so by pulling in more and more parts instead of
-      providing a clean interface which separate projects can use.
-    <braunr> again, the coupling is too tight
-    <braunr> it's hard to hook in between
-    <ArneBab> teythoon: I watched lennart troll a talk pretty badly…
-    <ArneBab> braunr: yes
-    <teythoon> he cites mach and hurd for having an nice ipc mechanism, and
-      linux lacking such a system
-    <braunr> haha
-    <braunr> i was expecting such comparisons :)
-    <ArneBab> that’s why he writes an init-system which does not run on the
-      Hurd… 
-    <teythoon> ArneBab: that's trolling on your part ;)
-    <braunr> :)
-    <ArneBab> somehow yes… 
-    <braunr> what i personally get out of this is that, in the end, proper
-      messaging at the kernel level is something people do want
-    <braunr> and if you make stuff like x use it, why not things like the
-      network stack and the file system
-    <teythoon> i wish the linux kernel would allow the kernel devs to write
-      nicer interfaces
-    <ArneBab> yes
-    <braunr> they're almost in the process of acknowledging the merits of
-      multiserver architectures :)
-    <teythoon> b/c they lack a proper ipc mechanism, they do stuff like ad-hoc
-      filesystem-based interfaces that are crappy to support on the hurd :-/
-    * ArneBab has been out of the loop for too long… 
-    <braunr> teythoon: what file system do you consider "crappy to support on
-      the hurd" ?
-    <teythoon> braunr: cgroupfs in particular
-    <teythoon> not crappy, but impossible
-    <braunr> well, that's probably because we need realy resource containers
-      first
-    <braunr> real*
-    <teythoon> no, we'll never be able to implement the current interface
-    <braunr> i didn't study it as you did so i trust you
-    <teythoon> braunr:
-      http://teythoon.cryptobitch.de/posts/cgroupfs-is-as-cgroupy-as-it-gets/
-    <braunr> ok this would require proper support at the client side
-    <teythoon> yes
-    <braunr> i wouldn't say impossible but definitely not as clean as we would
-      want it
-    <braunr> far from it
-    <teythoon> how would you ever implement it w/o fixing the client
-      (i.e. fixing the interface first) ?
-    <braunr> the client would translate the request
-    <teythoon> magical write retries ?
-    <braunr> probably
-    <teythoon> uh
-    <braunr> clients are the only entities which know what their file
-      desctiptors refer to
-    <braunr> descriptors*
-    <teythoon> yes
-    <braunr> so writing such a request would make the client get a magic retry,
-      and use the proper rpc, passing the proper rights instead
-    <teythoon> yeah, i can see how that could work
-    <teythoon> but i'm not sure that we should go down this path ...
-    <braunr> we probably really do'nt want to :)
-    <braunr> i'd personally be fine if debian would allow two init systems
-    <teythoon> me too
-    <braunr> with the powerful linux-specific one still allowing sysvinit
-      scripts
-    <teythoon> in particular b/c the sysvinit scripts are already there
-    <braunr> from what i've read, they all provide some decent backward
-      compatibility with sysvinit
-    <teythoon> yes
-    <braunr> and i think we can count on the linux community to riot if,
-      assuming systemd was chosen, it becomes too hard to use and tweak
-    <braunr> again, these people want their software to be used
-    <braunr> so they'll probably manage something decent in the long run,
-      whatever is chosen
-    <braunr> i don't care much
-    <braunr> :)
-    <kilobug> AFAIK Debian is planning to let users chose the init system, the
-      discussion is only on what should be the main/default one; but I might
-      have misunderstood it
-    <braunr> that was one of the possibilities, yes
-    <braunr> maybe we could help the debate by agreeing on whether or not we
-      consider supporting ports is that important, as port maintainers,
-      considering we'll probably keep the ability to use sysvinit scripts
-      anyway
-    <braunr> and making that decision known
-    <teythoon> and stating that we consider openrc an worthwile incremental
-      improvement, whatever debian decides to do wrt to the default init system
-    <braunr> for example, yes
-    <braunr> we should discuss that with youpi and thomas
-    <braunr> tschwinge: ^
-    <braunr> when they have some time later :)
-
-
-## IRC, freenode, #hurd, 2014-01-24
-
-    <gnu_srs> Good news, a successful boot of Hurd with OpenRC:
-      http://paste.debian.net/78119/ :-)
-    <gnu_srs> ramains to fix the false negative for checkpath -W
-    <gnu_srs> remains*
-    <braunr> not bad
-
-    <gnu_srs> teythoon: btw, the segfault happens when starting the bootlogd
-      service: 
-    <gnu_srs> end_request: I/O error, dev 02:00, sector 0
-    <gnu_srs> Segmentation fault
-    <teythoon> gnu_srs: nice progress :)
-    <teythoon> i've never seen bootlogd crash like that, though i
-    <teythoon> i'm not sure it is installed
-    <gnu_srs> how can I check / ? it is mounted RW and even if cd to /run which
-      is on tmpfs, fsysopts --readonly fails:
-    <gnu_srs> :fsysopts: /: --readonly: Device or resource busy
-    <gnu_srs> I don't have bootlogd installed the segfault is at:
-    <gnu_srs> checkroot.sh: hwclock.sh mountdevsubfs.sh hostname.sh hdparm
-      keyboard-setup
-    <gnu_srs> called by /etc/rcS.d/S06checkroot.sh
-    <teythoon> you should probably create this directory that it fails to
-      create early in the boot process
-
-
-## IRC, freenode, #hurd, 2014-01-25
-
-    <antrik> braunr: being Linux-only is *part* of the "tight coupling"
-      strategy of the systemd cabal
-    <antrik> of course you could implement all the Linux-specific interfaces on
-      other systems; as you could implement any other interfaces relied upon or
-      provided by systemd components...
-    <antrik> (this is in fact Lennart's favourit cop-out argument whenever
-      someone raises concern about this)
-    <antrik> the problem however is that such alternative implementations
-      usually have prohibitive costs
-    <braunr> yes i know
-    <antrik> (and Lennart knows that perfectly well... he doesn't exactly take
-      pains to conceal the fact that it's a cop-out)
-    <antrik> their whole point is to create a tightly integrated stack of
-      monopolistic components, giving a shit about any possible alternatives
-    <antrik> this does have an obvious appeal: it *significantly* reduces the
-      cost of innovation within their stack
-    <antrik> at the same time however it kills the traditional innovation
-      driver in the free software eco-system, which is competition among
-      interchangable components
-    <antrik> quite frankly, it makes little sense that other distributions are
-      embracing systemd in droves: the tight coupling pretty much turns them
-      all into Fedora look-alikes, questioning the point of their very
-      existence...
-    <zacts> what is dmd?
-    <antrik> as for Debian considering fringe kernels in their decision, I
-      think it makes *perfect* sense: the real value of Debian is precisely the
-      fact that it supports so many different things, making it a good base to
-      build upon
-    <antrik> (it's just unfortunate that many Debian developers do not realise
-      this, and instead try to compete with user-oriented distributions...)
-    <antrik> zacts: daemon managing daemon? yet another new init system...
-    <zacts> yeah
-    <zacts> didn't know if you have an opinion on it vs systemd
-    <zacts> and whether or not hurd will use it..
-    <antrik> hm... not sure whether I do ;-)
-    <braunr> antrik: one could argue an init system is hard to make
-      interchangeable without also making it quite poor in functionality
-    <antrik> the GNU system uses it, right? when using the GNU system with the
-      Hurd (as it's really meant to be), that would obviously mean using DMD
-      with Hurd. though I'm not sure whether anyone has actually tried that
-      combination ;-)
-    <braunr> just to make it clear, i'm totally not in favor of systemd
-    <braunr> i'm just trying to measure the value of an interchangeable init
-      system here
-    <braunr> value versus cost
-    <braunr> why is it bad to try to compete with user oriented distros ?
-    <antrik> braunr: I suspect most of the really good things about systemd
-      could be kept while making it somewhat more open at fairly little cost...
-    <antrik> braunr: because that's not Debian's strength -- and never will be
-    <antrik> trying to compete in this space too hard is bound to fail, at only
-      bears the risk of loosing the actual strengths
-    <braunr> antrik: sounds true
-    <antrik> hm... thinking about it, I'd say it actually makes more sense for
-      the init system to be distribution-specific than kernel-specific...
-    <braunr> that makes sense
-    <braunr> but systemd isn't just an init system
-    <antrik> it's really the distribution's job to create a well-integrated
-      system. and basically, that's what the systemd cabal is doing for
-      Fedora...
-    <antrik> it's just problematic that they have so much influence in
-      important upstream projects, that they are basically killing any chance
-      for others to integrate things in different ways
-    <braunr> antrik: agreed
-    <braunr> the tight coupling i refer to is about the init system and the
-      upstream projects you mention such as udev, acpid, console-kit, etc..
-    <antrik> yeah... and GNOME
-    <braunr> is it really that coupled now ?
-    <antrik> don't really know; but judging from remarks people make, it must
-      be pretty bad
-    <braunr> this reminds me of the talk on gnome 3 last year at fosdem
-    <braunr> it would have been hilarious if gnome wasn't such an important
-      project
-    <antrik> (specifically, GNOME is now pretty much tied to logind AIUI, which
-      is not entirely inseparable from systemd -- but again, the cost is
-      prohibitive...)
-    <teythoon> i don't get what all the hate here is about ...
-    <antrik> in fact, certain people used that as an argument why Debian must
-      switch to systemd as init, as they are already pretty much forced to use
-      various of the other coupled components anyways, and trying to decouple
-      them is too costly for Debian...
-    <braunr> teythoon: hate ? here ?
-    <teythoon> i mean they don't do this for fun, they actually provide
-      something of value, right ?
-    <braunr> some value
-    <antrik> teythoon: they?
-    <braunr> but they remove the kind of value that made free software evolve
-      the way it did, as antrik said
-    <teythoon> the evil cabal around systemd ;)
-    <antrik> I didn't say "evil"... not explicitly at least ;-)
-    <teythoon> then again, if you are runnign linux/gnome3 and plug in a second
-      monitor, that one is automatically activated
-    <braunr> yes, that's what they want to achieve
-    <teythoon> that's what they achieved
-    <braunr> i mean, they targetted that, it's not a side effect
-    <teythoon> and anyone not happy with how they did that can surely provide a
-      nicer solution ;)
-    <antrik> teythoon: as I said, there are clearly good aspects to what they
-      are doing -- but at the same time it's very dangerous to the free
-      software eco-system...
-    <braunr> teythoon: not easily
-    <teythoon> antrik: i don't buy that
-    <braunr> i do
-    <teythoon> braunr: yes, not easily. that is kind of the point, right ?
-    <braunr> pulling projects such as gnome into a category of kernel specific
-      applications is dangerous
-    <braunr> teythoon: well, considering who they are and the means they have,
-      they could have spent the time to do it right for everyone
-    <teythoon> maybe
-    <antrik> err... activating a second monitor is not in any way tied to
-      systemd or related compontents... I think you are talking about a second
-      seat
-    <teythoon> that's another killer feature they achieved, yes
-    <antrik> (which is nice, but quite frankly, a niche use case in my book...)
-    <teythoon> maybe you're not the typical user
-    <antrik> I'm not. but the *typical* user definitely doesn't care about
-      multi-seat
-    <teythoon> if you say so
-    <teythoon> antrik: when you say it's dangerous what 'they' are doing, what
-      do you mean exactly ?
-    <teythoon> dangerous for whom ?
-    <antrik> asides from schools in developing countries, who try everything to
-      save on IT costs, I really can't think of many users for multi-seat...
-    <teythoon> (maybe schools all around the world trying to cut down their
-      costs?)
-    <teythoon> or like everyone, here, a $30 dongle that gives you an extra
-      workstation, how awesome is that ?
-    <antrik> teythoon: see above: they are killing the ability to combine
-      interchangable components, which has always been a core asset of the free
-      software ecosystem
-    <teythoon> antrik: so gnome is going for systemd, and gnome loses the
-      ability to be used w/o systemd
-    <teythoon> why do you care ? how does this affect the whole ecosystem ?
-    <teythoon> i really don't get why everyone is getting so upset about this
-    <antrik> teythoon: who cares about a dongle giving an extra workstation?
-      the remaining users of workstations are either corporate -- who prefer
-      dedicated boxes for organisational reasons -- or gamers, who want all the
-      power to themselves...
-    <braunr> teythoon: well gnome is kind of one of the major destkop software
-      in the free software world
-    <antrik> s/one of//
-    <teythoon> antrik: you stated that you havent used gnome3, yet you have an
-      opinion how tightly it should be coupled with systemd or linux
-    <teythoon> people who haven't used systemd or upstart have an opinion about
-      which one should be preferred
-    <braunr> teythoon: why do you think people shouldn't think about systems as
-      a whole ?
-    <antrik> teythoon: actually, I am using it (for some value of "use") --
-      though in legacy mode, as my hardware can't run the new bling...
-    <braunr> in that case, people shouldn't be allowed to vote, because that
-      would require them to be politicians ..
-    <teythoon> it's okay to think about that
-    <braunr> i don't think it is
-    <antrik> teythoon: but seriously, whether *I* have used it is quite beside
-      the point. I have no illusions about being a niche user
-    <braunr> people don't need to use something to actually understand it
-    <teythoon> but i cannot stand all the whining lately in the free software
-      world...
-    <braunr> whining isn't fair
-    <braunr> i mean, the word
-    <teythoon> y ?
-    <braunr> it's a big problem and complaining to force a debate is important
-    <teythoon> yes, but "they" are solving problems, and everyone is
-      complaining for one reason or the other
-    <braunr> they are also creating problems
-    <braunr> and not everyone is complaining
-    <teythoon> as opposed to offering alternatives
-    <braunr> that's a major issue, a lot of people are favorable to these
-      changes
-    <teythoon> and if you don't like what "they" are building, you are free not
-      to use it, no ? that's a freedom too ;)
-    <braunr> no
-    <braunr> you aren't
-    <teythoon> what ?
-    <braunr> that's precisely the point
-    <braunr> you'll be de facto forced to use it if you want to keep using the
-      rest
-    <teythoon> i'm free not to use gnome3
-    <braunr> you won't be free from using linux if you want gnome3
-    <teythoon> what kind of argument is that ?
-    <braunr> i'm abusing the word freedom
-    <braunr> because it has no clear meaning in practice
-    <braunr> as antrik said, it's about interchangeability and portability
-    <braunr> and alternatives
-    <braunr> accepting the way systemd is designed is a major shift towards
-      making linux its own standard, away from the rest
-    <braunr> and the way it's done isn't thought to easily allow the
-      alternatives to keep up with the changes
-    <teythoon> we agreed the other day that they shouldn't create ad-hoc
-      interfaces like they do, yes
-    <braunr> well that's the whole point
-    <teythoon> you just talked "about the way systemd is designed"
-    <braunr> they could invest some more effort to make well designed
-      interfaces that allow changing both the dependencies and the services
-      provided
-    <teythoon> how is that related to bad interface design ?
-    <braunr> for me, it's almost a synonym
-    <braunr> and we discussed it
-    <teythoon> aren't tightness of coupling and quality of interfaces
-      completely orthogonal ?
-    <braunr> it is designed with a narrow set of apparently company directed
-      interested towards a single system, a single distribution even, and
-      nothing else
-    <braunr> no
-    <braunr> absolutely not, when it's about something that should be
-      interchangeable
-    <braunr> an interface that forces tight coupling is of low quality to me
-    <antrik> braunr: they claim it's not actually company-directed... and I
-      tend to believe them on *that* point TBH
-    <braunr> antrik: this would have been a valid reason at least
-    <antrik> teythoon: it's just not right that some people can no longer use
-      major pieces of free software just because a tiny but highly vocal cabal
-      decides to disrupt the whole ecosystem
-    <teythoon> what are you talking about ? you are free to use older versions
-      of the software
-    <braunr> i's not technically feasible
-    <braunr> or it would require forking to maintain
-    <braunr> again, it's the start of a rift
-    <teythoon> but, if the gnome people want to go into that direction, who are
-      you to say that they shouldn't ?? that's what i get the least about this
-      kind of argument...
-    <braunr> i'm part of the free software community
-    <braunr> more accurately, the free unix-like community
-    <teythoon> and you are actively developing gnome... ?
-    <braunr> if they want to get out of this community, they'll hurt it, and
-      themselves
-    <braunr> do you understand what a rift is ?
-    <teythoon> but that's their choice, no ?
-    <braunr> a major division ?
-    <braunr> so what ?
-    <braunr> it doesn't mean it's a good one
-    <teythoon> you pick the desktop environment you like next best and be done
-      with it ?
-    <braunr> it's almost public service at this point
-    <braunr> what if they all do the same thing ?
-    <teythoon> err
-    <teythoon> they don't
-    <braunr> you won't be free to do what you want because the technical
-      possibility will have disappeared
-    <braunr> kde might
-    <braunr> if only to compete with gnome
-    <teythoon> well, if you don't like hte direction a project is taking, you
-      fork it
-    <teythoon> that's what happened
-    <braunr> exactly ..
-    <teythoon> why the long faces ?
-    <braunr> forks increase complexity and reduce manpower
-    <braunr> fork == division
-    <braunr> forking in the free software community is normally a last resort
-    <teythoon> huh ? since when is this considered a bad thing ?
-    <braunr> it's not a bad thing per se
-    <braunr> it usually implies a bad situation
-    <teythoon> < braunr> fork == division
-    <teythoon> and division == rift
-    <braunr> think of these situations that were caused by stupid drama and
-      lead to the duplication of a lot of effort
-    <braunr> openbsd, eglibc, jenkins, to name a few
-    <teythoon> i don't
-    <teythoon> why would i ? i never created these forks
-    <braunr> it affects the community as a whole
-    <teythoon> but the people who did thought it was necessary
-    <braunr> the fact they could do it is good, the fact they had to do it
-      isn't
-    <braunr> they were usually forced by the situation
-    <braunr> and often by the stupidity of other people
-    <teythoon> someone forced someone else to fork a project ? with a gun or
-      something like this ?
-    <teythoon> i don't buy this ;)
-    <braunr> of course not ..
-    <braunr> eglibc was forced by the inability of drepper to accept a whole
-      class of patches
-    <braunr> openbsd because theo de raadt has some huge ego
-    <braunr> for jenkins, it was a licensing issue iirc
-    <braunr> nothing technical at all
-    <braunr> nothing in the interest of the community
-    <teythoon> err
-    <teythoon> it brings diversity
-    <braunr> no
-    <braunr> netbsd versus freebsd brings diversity
-    <teythoon> i thought that was a good thing
-    <braunr> openbsd was just agotistic crap
-    <braunr> ego*
-    <teythoon> if there is no diversity, why should stuff be interchangeable if
-      there are no alternatives?
-    <braunr> and netbsd and freebsd aren't exactly forks, they're both bsd
-      based but had different goals from the start
-    <braunr> that's not what i'm talking about
-    <braunr> eglibc isn't exactly a new libc
-    <braunr> it's glibc+the stuff that should have gone into it
-    <antrik> teythoon: the stuff the systemd cabal does builds on the work of
-      thousands of projects and people; yet they act as if the don't own anyone
-      anything, and it's fine to boot out large parts of the community whos
-      work they are building on
-    <braunr> iceweasel isn't a whole new firefox
-    <braunr> most often, alternatives aren't forks of one another
-    <braunr> if they are, they have diverged a lot
-    <teythoon> antrik: that is your interpretation, and i respectfully disagree
-      with it;)
-    <braunr> and usually have different goals
-    <braunr> that's diversity, and i'm very ok with it
-    <braunr> (being a hurd guy and all)
-    <braunr> but forking because of decisions that prevent alternatives is a
-      very bad reason to fork
-    <teythoon> again, who are you to tell a project (say gnome) what they
-      should do or not ?
-    <braunr> that question makes no sense
-    <braunr> we're trying to think objectively
-    <braunr> forget who we are
-    <braunr> think about what should be done
-    <teythoon> no such thing ;)
-    <braunr> ok well, in that case, i'm a very smart person who knows a lot of
-      things, and people had better do what i tell them ;p
-    <braunr> satisfied ? :)
-    <teythoon> yes
-    <teythoon> that's much better actually
-    <braunr> not really ..
-    <teythoon> it's more honest
-    <braunr> no it was sarcasm
-    <braunr> what was honest are the arguments i explained
-    <braunr> why care about who says them ?
-    <teythoon> i do
-    <antrik> teythoon: there is not much interpretation in there really. some
-      of their own statements are quite explicit...
-    <braunr> damn non scalable kernel ..
-    <teythoon> who is "their"? what statements ?
-    <braunr> teythoon: when building glibc, there are so many nodes to fake
-      that ext2fs+fakeroot allocate enough ports to starve kernel memory ...
-    <teythoon> if i were mr. gnome3 and you would tell me that i should cuddle
-      with systemd b/c that's bad for one reason or another, the first thing
-      i'd like to know is who is telling me that
-    <braunr> teythoon: why not solely consider the argument ?
-    <teythoon> braunr: yes, i can imagine fakeroot doing that
-    <antrik> teythoon: Lennart and his friends. not sure how much of these
-      statements I have seen written down -- part of it I heard myself from
-      their own mouths
-    <teythoon> braunr: b/c maybe i like to develop my project in the direction
-      i want
-    <braunr> that's unrelated
-    <teythoon> and if anyone disagrees, she may fork
-    <braunr> this is a debate
-    <teythoon> why ?
-    <teythoon> so now we are debating what i may develop or not ? you lost me
-      ;)
-    <braunr> a way to reach consensus
-    <braunr> many people are discussing so that projects like debian and gnome3
-      make the best decisions
-    <braunr> a naive way to explain it is that the result is the sum of what
-      everyone likes and how louds he speaks for it
-    <teythoon> sure but you are not a gnome developer, no ?
-    <braunr> no, but again, i'm a free software community member
-    <braunr> and this affects the whole community
-    <braunr> because gnome3 is a major software component used by a lot of
-      people
-    <braunr> well, gnome at least
-    <teythoon> so the gnome project needs to seek consensus with everyone of
-      the free software community ?
-    <braunr> no
-    <braunr> that would be unanimity
-    <teythoon> but wrt to the systemd integration ?
-    <braunr> siding with systemd is starting to get away from the free software
-      community
-    <braunr> or, by bringing a lot of people along, dividing it
-    <teythoon> that's your interpretation
-    <braunr> yes
-    <braunr> always
-    <braunr> you don't have to say it, we're not doing raw science here
-    <braunr> it's implicit
-    <teythoon> i think it's important to point that out and make it explicit
-    <braunr> you made it several times
-    <braunr> we got the point
-    <braunr> what matters in the current discussion is whether you agree or not
-      and why
-    <braunr> and this will be your interpretation too
-    <braunr> and we'll see if it's convincing
-    <braunr> but, from experience, i expect noone will be convinced ;p
-    <teythoon> ^^
-    <braunr> the issue is too tied with the core goals we have in mind
-    <teythoon> but why does it matter whether i agree or not
-    <teythoon> that's my point actually
-    <braunr> you seem to have a problem understanding the issue, i was trying
-      to convince you there is one
-    <braunr> so, if i want to achieve that, it matters
-    <teythoon> what core goals ?
-    <braunr> basic dialectic
-    <braunr> well, for example, for me, i want people to think of the system as
-      a whole
-    <braunr> i want something effective, technically very good, and that
-      respects user freedoms
-    <braunr> i also want alternatives, i won't explain why, let's say it's
-      obvious
-    <teythoon> i agree
-    <braunr> well, systemd people don't think of the system as a whole
-    <braunr> here, what i call "system" is very large
-    <braunr> it would almost equal society
-    <braunr> i understand why they do that
-    <braunr> they have the right to do that
-    <braunr> but then i could say i understand why people make proprietary
-      software, and they also have the right to do it, i still won't approve it
-    <braunr> it contradicts my personal goals, my personal view of how things
-      should be
-    <teythoon> i completely agree
-    <teythoon> but then again, what you said now and the way you said it was
-      very different
-    <braunr> maybe, it's 3am, i'm sick and exhausted :)
-    <teythoon> more abstract
-    <braunr> when i give an opinion
-    <braunr> actually, when anyone gives an opinion
-    <braunr> i consider it implicit that it's their point of view alone
-    <braunr> they're not enforcing anything
-    <braunr> merely speaking out
-    <teythoon> people tend to overestimate the importance of their own opinion
-    <braunr> hm i wouldn't say so
-    <braunr> and that's probably why the "who" doesn't matter a lot to me
-    <braunr> it would matter if the person in question had real power
-    <braunr> and his opinion could have a strong influence
-    <braunr> in which case it wouldn't be overestimated
-    <braunr> i could say what i think to systemd people
-    <antrik> teythoon: quite frankly, I'm not sure what you are complaining
-      about. the systemd followers are trying to impose their opinions on
-      various projects. other people (including braunr and me, among many
-      others) are voicing counter-opinions. what's wrong with that?
-    <braunr> but i'm pertty certain the weight they'll associate to what i tell
-      them will be very low :)
-    <braunr> antrik: he called it "annoying whining"
-    <braunr> i think it's the only problem
-    <antrik> braunr: I don't think the systemd people associate much weight to
-      *anything* others say... ;-)
-    <braunr> heh :)
-    <braunr> to make an historic analogy
-    <braunr> it seems to me they're repeating the same mistakes others did
-      during the unix wars
-    <teythoon> antrik: but when you say "the systemd followers are trying to
-      impose their opinion on various projects", don't you dismiss the
-      possibility that the gnome3 people just want to make external displays
-      hot-pluggable?
-    <braunr> of course they do
-    <braunr> don't you dismiss that proprietary software author just want to
-      make money ?
-    <teythoon> no
-    <braunr> well, if that's the only thing you keep in mind to make your
-      opinion, you'll miss important points
-    <teythoon> that is an example of course
-    <braunr> they're sacrificing interchangeability and starting a possibly
-      major rift in the community for hot pluggable displays
-    <braunr> it may not be worth it
-    <teythoon> not supporting stuff like that might make the whole ecosystem
-      obsolete
-    <braunr> i'm not saying it shouldn't be done
-    <braunr> i'm saying it should be done while sacrificing other important
-      things
-    <braunr> it would just take a little mort effort
-    <braunr> and even if it wasn't done
-    <teythoon> that's what i meant by "whining"
-    <teythoon> no offense
-    <braunr> what is the problem of it being "obsolete" ?
-    <teythoon> but talk is cheap, offering alternative solutions is hard
-    <braunr> isn't unix obsolete ? isn't xorg obsolete ?
-    <braunr> hum no
-    <teythoon> no one did, so they implemented their nice features
-    <braunr> the point isn't to offer alternative solutions
-    <braunr> it's to make them possible
-    <braunr> or at least, not deny their technical feasibility because they
-      don't care
-    <braunr> teythoon: see, "interchangeability and starting a possibly major
-      rift" don't look to conflict with your personal goals
-    <braunr> that's the point where i think i can no longer do anything to
-      convince you
-    <braunr> so i'll head to bed :)
-    <teythoon> heh, me too :)
-    <braunr> honestly, i don't care a lot
-    <braunr> i mean
-    <braunr> it won't change much for me
-    <braunr> but again, my brain is wired to think of things as a whole
-    <braunr> on that note, good night :)
-    <teythoon> good night :)
-    <antrik> teythoon: again, IT'S NOT ABOUT DISPLAYS
-    <antrik> believe me, I do have some understanding how display hotplugging
-      works
-    <antrik> also, the problem is not that gnome3 supports logind. the problem
-      is that gnome3 works *only* with logind now AIUI
-    <antrik> there is yet another way to state the fundamental problem
-    <antrik> there is a kind of social contract among free software projects:
-      every maintainer takes a reasonable amount of extra effort to support use
-      cases beyond his own. in return, his use cases are supported by other
-      maintainers
-    <antrik> the systemd guys are breaking this contract, by explicitly
-      refusing, up front, to take *any* effort to accomodate other projects'
-      needs
-
-
-## IRC, freenode, #hurd, 2014-01-28
-
-    <azeem_> teythoon:
-      https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/EgKwQV8te7s
-    <teythoon> azeem_: pffff :)
-    <braunr> heh
-    <teythoon> which reminds me
-    <teythoon> if we want to state our position wrt the default init system
-      debate we should probably do it right now
-    <braunr> yes
-    <teythoon> ml or collaborative editor ?
-    <azeem_> well, tech-ctte chair called the vote only for the default init
-      system for the Linux-ports
-    <azeem_> the vote got shot down on technicalities, but that might stand
-    <azeem_> I think that is a good thing, cause it implies that not one init
-      system has to be adopted across all ports
-    <teythoon> we talked the other day that it might make sense just to state
-      our view and our needs
-    <azeem_> sure.
-    <azeem_> I think what's needed is (i) an init-system agnostic system to set
-      the enable/disable state of services (ii) possibly mandating a .ini-style
-      config file along the style of whatever init system gets chosen as
-      default for Linux, to be used by non-Linux init systems as inut
-    <azeem_> input*
-    <azeem_> just my 0.02 EUR
-    <teythoon> uh
-    <braunr> looks overkill
-    <teythoon> i was thinking more along the lines of 1) we have never used the
-      default debian init system and are cool with not using the default in the
-      future, 2) we intend to use sysvinit in the future, 3) to that end, we
-      ask the init script machinery to be left in place
-    <braunr> but then, people managed to write stuff like libvirt
-    <braunr> so who knows
-    <teythoon> 4) we will help maintaining it as part of our porter effort
-    <braunr> i agree with teythoon 
-    <teythoon> 5) we look forward to using openrc as incremental improvement,
-      complementing our sysvinit boot solution
-    <braunr> yes that would be nice
-    <teythoon> i'll write a draft to debian-hurd, ok ?
-    <gnu_srs> openrc now has a dependency loop resolver, so parallel would
-      work:)
-    <teythoon> so is insserv, isn't it ?
-    <gnu_srs> there were complaints on openrc
-      https://bugs.gentoo.org/show_bug.cgi?id=391945 in the tech-ctte
-      discussions, now fixed
-    <azeem_> gnu_srs: please accept the fact that openrc will not be picked by
-      the tech-ctte for the Linux ports
-    <gnu_srs> azeem_: I do, I'm referring to arguments during the discussion
-      (history) 
-    <azeem_> sure, just checking
-    <ArneBab> teythoon: your post is being used to portray systemd cgroups
-      treatment as the right way…
-    <teythoon> ArneBab: so ?
-    <braunr> it probably is the right way
-    <braunr> that's not the problem
-    <ArneBab> do you want to clear that up? (do I remember correctly that you
-      did not like that way?)
-    <braunr> we don't like the cgroups interface
-    <teythoon> i will
-    <braunr> not the feature
-    <ArneBab> braunr: that’s what I meant
-    <teythoon> exactly
-    <braunr> the feature amounts to resource containers in the hurd critique
-      ...
-    <braunr> we do want that too :)
-    <braunr> anatoly: you want them to rewrite cgroups ?
-    <braunr> err
-    <braunr> ArneBab: ^
-
-[[dbus_in_linux_kernel]].
-
-    <teythoon> i've been thinking
-    <teythoon> maybe the magic write stuff isn't that bad after all
-    <braunr> :)
-    <braunr> i was thinking the same thing actually
-    <teythoon> i mean, it's not the nicest thing, but it shows how flexible our
-      solution is
-    <braunr> the hurd is a lot about glue code already so why not
-    <teythoon> the problem is that there is no way to test cgroupfs
-    <teythoon> the main user is systemd, and it requires tons of other stuff
-    <braunr> right
-    <teythoon> any other user of cgroups is also probably using other
-      linux-interfaces too
-
-
-## IRC, freenode, #hurd, 2014-01-29
-
-    <gnu_srs> About openrc having a dependency loop resolver: <teythoon>: so is
-      insserv, isn't it ?
-    <gnu_srs> I found is_loop_detected() in insserv/listing.c but that one just
-      exits without telling where the loop is
-
-
-## IRC, OFTC, #debian-hurd, 2014-01-29
-
-    * youpi trying the new sysvinit
-    <youpi> hopefully we'll then be able to at last use the proper ifup/ifdown
-      debian way for networking :)
-    <youpi> teythoon: why leaving hurd's runsystem by default rather than
-      sysvinit's?
-    <youpi> ah, another issue, too, now that /dev/vcs appears in /proc/mounts,
-      umountfs would umount it
-    <youpi> ideally umountfs would not umount passive translators
-    <youpi> we could blacklist /dev/vcs in umountfs, but the same issue would
-      happen for user-defined translators in their own home, for instance
-
-
-## IRC, freenode, #hurd, 2014-01-30
-
-    <gnu_srs> booting with the new sysvinit and openrc versions: works:), but
-      only in recovery mode:-( Hangs before INIT: version 2.88 booting
-    <gnu_srs> after start ext2fs: Hurd server bootstrap: ext2fs[device:hd0s1]
-      exec init proc authtask c1120dc8 deallocating an invalid port 134517370,
-      most probably a bug.
-    <gnu_srs> related or an openrc problem? will test with sysv-rc
-    <youpi> I don't have such issue with sysv-rc
-    <gnu_srs> k!
-    <gnu_srs> shouldn't recovery mode mean starting in runlevel 1, I get
-      runlevel 2?
-    <youpi> it should
-    <pere> gnu_srs: recovery mode normally mean single user, which is between
-      rcS and rc2
-    <gnu_srs> I get INIT: Entering runlevel: 2
-    <pere> rcS.d should really have been named rcboot.d, as that is really what
-      it is.
-    <youpi> ah, right, recovery is not single
-    <youpi> (single as in init 1)
-    <pere> runlevel 1 is not single user either.  it is more a gateway into
-      single user.  see /etc/init.d/single to see what happen at the end of
-      runlevel 1.
-    <gnu_srs> init 1 and init 2 seems to work
-    <gnu_srs> well, the openrc dependency loop detector has found an init
-      script loop, maybe it has to be fixed?
-    <gnu_srs> disabling the hurd console solved the dependency loop problems,
-      thanks openrc;-)
-    <gnu_srs> (have to dig deeper to see where the loop is, and how to solve
-      it)
-
-
-## IRC, freenode, #hurd, 2014-01-31
-
-    <gnu_srs> Hi, does the hurd console work with sysv-rc: In operc I get with
-      #console -d vga -d pc_mouse --repeat=mouse -d pc_kbd --repeat=kbd -d
-      generic_speaker -c /dev/vcs
-    <gnu_srs> console: Console library initialization failed: Not a directory
-    <teythoon> gnu_srs: yes, it works with sysvrc
-    <teythoon> gnu_srs: check that /dev/vcs has the appropriate translator
-      record
-    <gnu_srs> showtrans /dev/vcs: empty on another box: /hurd/console
-    <teythoon> yes, fix that and your console will be fine
-    <gnu_srs> settrans /dev/vcs /hurd/console?
-    <gnu_srs> or should it be active?
-    <teythoon> no, set an passive translator record so that this will be
-      persistent
-    <gnu_srs> something is wrong: when starting the hurd console screen is
-      blanked (and hangs)
-    <gnu_srs> can I get the hurd console when running with the serial console
-      (to see boot messages)?
-    <teythoon> gnu_srs: yes, yuo can
-    <gnu_srs> will try that image then, tks:)
-    <gnu_srs> teythoon: how to create all underlying directories? ls /dev/vcs:
-      1 2 3 4 5 6
-    <teythoon> don't, /hurd/console takes care of that
-    <gnu_srs> is settrans /dev/vcs /hurd/console correct?
-    <teythoon> yes
-    <sjbalaji> What are those underlying directories representing ?
-    <teythoon> the hurd console is a console multiplexer
-    <teythoon> bringing multiple virtual consoles to the hurd
-    <teythoon> # showtrans /dev/tty1
-    <teythoon> /hurd/term /dev/tty1 hurdio /dev/vcs/1/console
-    <gnu_srs> aha:  console -d vga -d pc_mouse --repeat=mouse -d pc_kbd
-      --repeat=kbd -d generic_speaker -c /dev/vcs
-    <gnu_srs> task c1120e70 deallocating an invalid port 1782, most probably a
-      bug.
-    <sjbalaji> teythoon: Is it that /dev/tty1 has multiple translators ?
-    <teythoon> no
-    <teythoon> exactly one translator is bound to any given node in the vfs
-    <gnu_srs> something is strange with the hurd console: booting with it
-      enabled still runs the mach console, halting:
-      http://paste.debian.net/79438/
-    <teythoon> what is strange about taht ?
-    <gnu_srs> when starting the hurd console:  task c1120e70 deallocating an
-      invalid port 1782, most probably a bug.
-    <teythoon> so ?
-    <gnu_srs> and the paste when halting: twice
-    <teythoon> that is a known issue
-    <gnu_srs> with the hurd console?
-    <teythoon> how do you know it's the hurd console ?
-    <teythoon> that message comes from the kernel
-    <teythoon> currently, it is not possible to tell which process is
-      responsible
-    <teythoon> b/c the task is given as a pointer to the kernel task structure
-    <teythoon> not as a pid
-    <gnu_srs> I don't ,it is triggered by it at least
-    <teythoon> currently there is no way to map the former to the latter
-    <teythoon> why do you think it's a problem ? is something not working as
-      expected ?
-    <gnu_srs> maybe a reproducible way to hunt that bug!
-    <teythoon> we have one already
-    <teythoon> it happens every time the hurd boots
-    <gnu_srs> yes, hurd console does not start, even when enabled:-(
-    <teythoon> then please say so ;)
-    <gnu_srs> I did:  (11:23:30) srs: something is strange with the hurd
-      console: booting with it enabled still runs the mach console, halting:
-      http://paste.debian.net/79438/
-    <teythoon> where do you say that the hurd console did not start ?
-    <gnu_srs> maybe it is easier to hunt the bug in an already booted system
-    <teythoon> you just said that the mach console is still active, wich it is
-      even if the hurd console starts
-    <teythoon> yes
-    <teythoon> please start the hurd console by hand
-    <teythoon> -d current_vcs -c /dev/vcs -d vga -d pc_kbd --keymap us
-      --repeat=kbd -d pc_mouse --protocol=ps/2 --repeat=mouse
-    <teythoon> err
-    <teythoon> /bin/console -d current_vcs -c /dev/vcs -d vga -d pc_kbd
-      --keymap us --repeat=kbd -d pc_mouse --protocol=ps/2 --repeat=mouse
-    <gnu_srs> when I log in I have the mach console not the hurd console
-    <teythoon> yes, log in as root, then run that command
-    <gnu_srs> I've done that: (11:10:27) srs: aha:  console -d vga -d pc_mouse
-      --repeat=mouse -d pc_kbd --repeat=kbd -d generic_speaker -c /dev/vcs
-    <gnu_srs> please read?
-    <teythoon> and you discovered in that process that /dev/vcs lacked a
-      translator record
-    <teythoon> did you run it again after fixing that ?
-    <gnu_srs> the reply was: (11:10:27) srs: task c1120e70 deallocating an
-      invalid port 1782, most probably a bug.
-    <teythoon> well, if you are feeling that what i ask you to do is
-      unreasonable, i'm not sure how i can help you
-    <gnu_srs> yes, the translator was running!
-    <teythoon> you could hunt down the port deallocation bug, that'd be awesome
-      and most welcomed
-    <teythoon> but i don't believe it is causing your console malfunction
-    <gnu_srs> I did what you asked for??
-    <gnu_srs> I'll do it again!
-    <gnu_srs> ok, now I don't get that error, but still no hurd console? the
-      process is running, logging out and then in, no hurd console.
-    <gnu_srs> not possible in serial console?
-    <teythoon> no, the hurd console is displayed using the graphic card
-    <teythoon> you asked for that with -d vga ;)
-    <teythoon> not sure if there are any other display drivers
-    <teythoon> when you asked whether you can use the serial line, i assumed
-      you used both qemus graphic terminal and a serial console
-    <teythoon> try kvm ... -serial telnet::1236,server,nowait, then use telnet
-      localhost 1236 to connect to the serial console
-    <teythoon> then, you can start the hurd console over the serial console and
-      see whether that worked
-    <gnu_srs> OK; that's what I asked before. I tried with the graphic one,
-      I'll try again
-    <gnu_srs> telnet output is empty
-    <gnu_srs> frozen
-    <teythoon> did you start a getty there ?
-    <gnu_srs> in hurd?
-    <teythoon> b/c if you dropped the console=com0 argument from you gnumach
-      command line, the mach console will be put on the vga screen, not on the
-      serial console
-    <gnu_srs> I dropped  console=com0 from grub.cfg, yes
-    <teythoon> ok
-    <teythoon> so simply no one is talking to the serial port anymore
-    <teythoon> did you try to start the hurd console ?
-    <gnu_srs> I did before, can do  it again
-    <gnu_srs> startin the HC blanks the screen, and freezes the vga output:-(
-      ssh still working
-    <teythoon> hm
-    <teythoon> try  ps Ax | grep tty, are there any term servers running for
-      /dev/tty1..6 ?
-    <gnu_srs> lplenty of them: http://paste.debian.net/79442/
-    <teythoon> good, even gettys are there
-    <gnu_srs> and the console translator runs
-    <teythoon> hm
-    <gnu_srs> root  1224     5 7 months /hurd/console
-    <gnu_srs> root  1227  1226 7 months /bin/console -d vga -d pc_mouse
-      pc_mouse -d pc_kb...
-    <teythoon> yes, everything looks good
-    <teythoon> just to be sure, you are currently using the qemus graphical
-      frontend, right ?
-    <gnu_srs> yes
-    <teythoon> hm :/
-    <teythoon> gnu_srs: do you see loginpr processes ?
-    <gnu_srs> nope
-    <teythoon> hum
-    <teythoon> this strikes me as odd
-    <teythoon> on my system, i see no gettys but only loginpr processes
-    <teythoon> this is b/c the hurd getty does little other than to print some
-      text and run the login program
-    <teythoon> but on your system the getty sticks around
-    <teythoon> is /sbin/getty really the hurd getty? it's easily recognized by
-      its crappieness:
-    <teythoon> /sbin/getty --help || echo $?
-    <teythoon> 1
-    <gnu_srs> 1
-    <teythoon> hm
-    <teythoon> still funny though
-    <teythoon> you could try to run the hurd console, then run a getty manually
-    <teythoon> e.g. /sbin/getty 38400 tty1
-    <gnu_srs> from the ssh login?
-    <teythoon> yes
-    <gnu_srs> then the graphic display is back showing the loin prompt:P
-    <teythoon> weird
-    <teythoon> well, so most things work
-    <teythoon> that's a good thing
-    <teythoon> funny that hurds getty should get stuck like this
-    <gnu_srs> and the terminal is hurd:-)
-    <teythoon> any chance you can produce a stack trace of one of your getty
-      processes ?
-    <gnu_srs> how?
-    <teythoon> gdb --pid=the_pid /sbin/getty
-    <teythoon> then, do bt like usual
-    <gnu_srs> so you mean tty2-6 are broken?
-    <teythoon> no
-    <teythoon> it's just for some reason your gettys do not behave nicely when
-      run from init
-    <gnu_srs> from running tty2: bt #0  0x01087b09 in ?? ()
-    <gnu_srs> #1  0x00000000 in ?? ()
-    <gnu_srs> not much
-    <teythoon> hm :/
-    <teythoon> indeed
-    <teythoon> our getty logs to syslog, can you see anythign of interest here
-      ?
-    <gnu_srs> Jan 31 12:00:46 debian-openrc-20140123 rsyslogd-2066: could not
-      load module '/usr/lib/rsyslog/imklog.so', dlopen:
-      /usr/lib/rsyslog/imklog.so: undefined symbol: klogAfterRun
-    <gnu_srs>  [try http://www.rsyslog.com/e/2066 ]
-    <gnu_srs> nothing tty releated
-    <teythoon> gnu_srs: oh, i just noticed, please look into auth.log, the
-      getty stuff ends up there
-    <gnu_srs> teythoon: http://paste.debian.net/79465/
-    <teythoon> well, that is interesting :)
-    <gnu_srs> /dev/tty1 not a directory?
-    <teythoon> for instance, yes
-    <teythoon> it says bad syntax if it was invoked in the wrong way, i.e. not
-      with exactly two arguments
-    <teythoon> that might have been you yourself, right ?
-    <teythoon> with getty --help i mean
-    <teythoon> for the not a directory message, please verify that
-    <teythoon> # showtrans /dev//tty1
-    <teythoon> /hurd/term /dev/tty1 hurdio /dev/vcs/1/console
-    <teythoon> and stat /dev/vcs/1/console says it's a character special file
-    <gnu_srs> I used exactly: /sbin/getty --help || echo $?
-    <teythoon> yes, that accounts for that bad syntax message
-    <gnu_srs> what so bad about that?
-    <gnu_srs>  showtrans /dev//tty1
-    <gnu_srs> /hurd/term /dev/tty1 hurdio /dev/vcs/1/console
-    <teythoon> getty is so simple minded that it doesn't really parse its
-      arguments
-    <gnu_srs> stat: http://paste.debian.net/79469/
-    <teythoon> looks nice
-    <teythoon> everything looks nice, i'm at my wits end here
-    <gnu_srs> and everything works OK with sysv-rc?
-    <teythoon> yes
-    <teythoon> by the way, are you using the sysvinit init scripts or something
-      openrc related ?
-    <gnu_srs> openrc use all the scripts in /etc/init.d
-    <teythoon> actually, could you try to kill -HUP 1 ?
-    <gnu_srs> BTW: the dependency loop detector has found many loops in those
-      scripts 
-    <gnu_srs>  kill -HUP 1: nothing happens
-    <teythoon> ok, try to kill one of those gettys and see if the one that
-      respawns works
-    <teythoon> then again, the getty should try to reopen the device every
-      minute until it succeeds
-    <gnu_srs> getty tty1 and tty2 disappeared? kill -HUP tty3 respawns
-      immediately
-    <gnu_srs> now no getty processes are left?
-    <gnu_srs> /dev//tty4: Not a directory etc?
-    <teythoon> sorry, i should have expressed myself more clearly
-    <teythoon> kill -HUP 1 sends a SIGHUP to sysvinit, this makes it reload
-      it's configuration
-    <teythoon> when i said kill some getty, i meant just kill some_pid
-    <teythoon> when you said 'kill -HUP tty3 respawns immediately', did you
-      mean you killed the getty that was listening on /dev/tty3, and then a new
-      one appeared and you got a login prompt at tty3 ?
-    <gnu_srs> a new pid appeared, the login prompt is on tty1
-    <gnu_srs> this one? /hurd/term /dev/tty1 hurdio /dev/vcs/1/console
-    <teythoon> i'd like to invite you to look at daemons/getty.c
-    <gnu_srs> not a big piece of code: anything specific?
-    <teythoon> no, just look what it roughly does
-    <gnu_srs> not a directory is not coming from that code
-    <teythoon> correct
-    <gnu_srs> it execl-s login
-    <teythoon> yes
-    <teythoon> inevitably
-    <teythoon> but you do not observe this
-    <gnu_srs> how come when they are running?
-    <teythoon> this is the question that you will have to answer in order to
-      make any progress
-    <gnu_srs> I killed only one of them:  kill -HUP 1031 and they all
-      disappeared
-    <teythoon> i thought along these lines: the most obvious way to stall getty
-      is if it never exits that loop
-    <teythoon> so i guessed it might be failing to open the device
-    <teythoon> we already observed that getty works fine if invoked by you
-      manually
-    <teythoon> the question thus is, what is different when getty is invoked by
-      init ?
-    <teythoon> if a process started by init in this way is killed, init will
-      restart it
-    <teythoon> please note, that if anyone says kill that process, she means
-      send a signal that results in process termination
-    <teythoon> and while sighup causes processes to die if the signal is not
-      handled, it is not the ideal signal to kill processes
-    <teythoon> b/c some processes handle sighup
-    <teythoon> like sysvinit, which reloads its configuration
-    <teythoon> many daemons do this
-    <teythoon> see 'man 7 signal' for how signals affect processes
-    <gnu_srs> sorry, have to leave for now, bbl and thanks a LOT so far:)
-    <teythoon> ok :)
-    <teythoon> you are welcome :)
-    <gnu_srs> teythoon: I'm back but cannot spend to much time on this
-      tonight. Maybe you should try it yourself, do you want another image on
-      my box? 
-    <teythoon> it'd be nice if you put your packages somewhere
-    <gnu_srs> there are no special packages sysvinit  (-46) and openrc (-8)
-    <teythoon> surely openrc with some patches ?
-    <gnu_srs> from #openrc: (17:37:41) srs: start with sysvinit and make it
-      work first!
-    <gnu_srs> (17:28:43) srs: zigo: Then I copied that working image to
-      another, and changing hostname, and continued from there.
-    <gnu_srs> openrc with the hurd patches for /lib/rc/sh/init.sh (v8 should be
-      available from experimental by now)
-    <teythoon> sweet :)
-    <teythoon> gnu_srs: maybe it was just some weird issue with your system
-    <teythoon> i just switched to openrc and everything seems to just work
-    <teythoon> i'll redo what i just did more cleanly to get a clean test vm...
-    <gnu_srs> nice:)
-    <gnu_srs> teythoon: And you got the hurd console?
-    <teythoon> heh, i believe so >,<
-    <teythoon> i didn't see it b/c i was using --nographic
-    <teythoon> but ps Ax looked alright
-    <teythoon> hrm
-    <teythoon> gnu_srs: i can reproduce your trouble, umount still strips the
-      translator record from /dev/vcs
-    <teythoon> at system shutdown time
-    <gnu_srs> so that's the reason. Additionally I have to issue halt twice
-      from a ssh login, see http://paste.debian.net/79517/
-    <teythoon> funny indeed
-    <teythoon> gnu_srs: i can reliably recover the hurd console by doing
-    <teythoon> settrans /dev/vcs /hurd/console && service hurd-console restart
-      && pkill getty ; sleep 5 ; pkill getty
-    <teythoon> humm, as you say, halt doesn't work
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-01
-
-    <pere> I've just uploaded a new new sysvinit package to experimental, with
-      all the latest hurd fixes.  
-
-
-## IRC, freenode, #hurd, 2014-02-01
-
-    <gnu_srs> 17:53:28< teythoon> settrans /dev/vcs /hurd/console && service
-      hurd-console restart && pkill getty ; sleep 5 ; pkill getty
-    <gnu_srs> teythoon: Any ideas on how to solve this?
-    <teythoon> gnu_srs: yes, i have that on my todo list
-    <gnu_srs> so it is not an openrc problem?
-    <teythoon> gnu_srs: no
-
-
-## IRC, freenode, #hurd, 2014-02-01
-
-    <teythoon> start ext2fs: Hurd server bootstrap: ext2fs[gunzip:device:rd0]
-      exec init proc au
-    <teythoon> thtask with pid 6 deallocating an invalid port 134517370, most
-      probably a bug.  
-    <teythoon> :)
-    <teythoon> pid 6 is exec o_O
-    <gnu_srs> teythoon: Nice to see that you added pid numbers for error
-      print-outs:)
-    <gnu_srs> so the boot error comes from the exec sever?
-    <teythoon> so it seems
-    <gnu_srs> server*
-    <gnu_srs> have you found where?
-    <teythoon> no
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-02
-
-    <pere> but when I install the new packages, and run update-alternatives
-      --config runsystem to select sysv, the boot fail with: start ext2fs: Hurd
-      server bootstrap: ext2fs[device:hd0s1] exec init proc authtask c1128dc8
-      deallocationg and invalid port 134517370, most probably a bug.
-    <pere> was that the wrong approach?
-    <pere> is there some way to recover when hurd fail to boot with sysvinit?
-    <pere> I was able to boot in recovery mode. :)
-    <pere> and this time sysvinit booted.  saw a segfault message just after
-      sysvinit started, no idea what caused it.
-    <pere> looks like it is startpar that segfaults.
-    <pere> looks like the invalid port message come every time, no matter if
-      the boot hang or not.
-    <pere> I was wrong.  it isn't startpar segfaulting, it is something in
-      rcS.d/.
-    <pere> bootlogd is the process segfaulting at boot.
-    <pere> looks like the boot success rate is 30% or so.
-    <pere> reported bootlogd problem as <URL: http://bugs.debian.org/737375 >.
-      I really miss valgrind. :)
-    <teythoon> pere: yes, the invalid port message is from the exec server
-    <teythoon> pere: i see the hurd boot process hang sometimes, no matter if i
-      use sysvinit or not
-    <teythoon> i believe it's a race condition in the ext2fs, not sure though
-    <pere> teythoon: but did the frequency of the hang go up with sysvinit or
-      not? to me it seem like that.
-    <teythoon> pere: yes, i believe it got worse
-    <teythoon> what hangs is fsysopts --update /
-    <teythoon> runsystem.sysv does that quite early
-    <pere> able to debug it?
-    <pere> I like the fact that runsystem.sysv set up ip at boot time, while
-      with .gnu, I have to run dhclient /dev/eth0 manually
-    <pere> it is quite confusing that hurd got two init processes with
-      sysvinit.  one as pid 1, and another that seem to be the parent of all
-      internal stuff.  perhaps the latter could be renamed to hurd-system or
-      something like that?
-    <pere> "sleep 0.2 # Work around a race condition (probably in the root
-      translator)." do not look too good...
-    <pere> (I increased from 0.1 to see if it help me. :)
-    <teythoon> did it ?
-    <teythoon> i plan to rename /hurd/init to /hurd/startup
-
-[[hurd_init]].
-
-    <pere> nope. :)
-    <pere> five boots in a row hung. :(
-    <pere> still no go...
-    <teythoon> are you using a vm or real hardware ?
-    <pere> vm
-    <pere> kvm, via virt-manager, to be exact.
-    <teythoon> me too
-    <pere> on the sixt boot, after waiting a long time between try 5 and 6
-      (gave up a bit), it booted.
-    <pere> sleep 1 did not help either.
-    <teythoon> :(
-    <teythoon> well, it's not *that* bad for me
-    <teythoon> in fact recently it has been a lot better
-    <teythoon> you might try my packages
-    <teythoon> pere: here http://darnassus.sceen.net/~teythoon/hurd-ci/
-    <pere> teythoon: tested it, and it seem to solve the problem.
-    <pere> is also rid of the strange error at the start.
-    <pere> teythoon: your packages even work without the sleep 0.1, at least
-      some of the time. :)
-    <pere> hm, but the success rate without sleep 0.1 is very low.  I was able
-      to boot once, and never again. :(
-    <teythoon> pere: yes, i fixed the spurious port allocation today :)
-    <teythoon> pere: nice to hear that the sleep 0.1 i put in does increase
-      your chance to boot as well
-
-
-## IRC, freenode, #hurd, 2014-02-02
-
-    <teythoon> gnu_srs: i found the spurious port deallocation :)
-    <gnu_srs> Cangrats:-D
-    <teythoon> trouble is, i introduced it >,<
-    <gnu_srs> Congrats*
-    <gnu_srs> Ah, you did?
-    <teythoon> gnu_srs: yes, in debian/patches/exec_filename_fix.patch
-    <teythoon>
-      http://darnassus.sceen.net/gitweb/teythoon/packaging/hurd.git/commitdiff/6da3e0be8fde0594bd84a13536d9d93048186790
-    * teythoon . o O (diffs of diffs are trippy :)
-
-
-### IRC, freenode, #hurd, 2014-02-03
-
-    <braunr> teythoon: oh nice, you found that bug :)
-    <teythoon> braunr: yes, once i knew where to look it was easy to fix ;)
-
-
-### IRC, freenode, #hurd, 2014-02-05
-
-    <teythoon> i wonder why the port deallocation bug made the system hang when
-      the libc was compiled with the newer gcc
-    <braunr> teythoon: so it was indeed the problem ?
-    <teythoon> braunr: youpi said so, yes
-    <braunr> oh right
-
-[[glibc/debian/experimental]], *glibc 2.18 vs. GCC 4.8*?
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-03
-
-    <pere>
-      http://people.skolelinux.org/pere/blog/Testing_sysvinit_from_experimental_in_Debian_Hurd.html
-    <teythoon> :)
-    <teythoon> pere: sounds like your hurd-console isn't running and there is
-      no getty on the mach console
-    <teythoon> pere: you could add sth like 8:2345:respawn:/sbin/getty 38400
-      console to your inittab
-    <pere> I'd rather wait until the hurd porters get it right in the debs. :)
-    <pere> I suspect upgrading the downloadable image to use the latest
-      packages also would help a lot.
-    <pere> with upgraded packages, /proc is working and pstree, pkill, top, etc
-      is working out of the box. :)
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-04
-
-    <pere> I just uploaded sysvinit with hurd support to unstable. :)
-
-
-## IRC, freenode, #hurd, 2014-02-04
-
-    <gnu_srs> teythoon: Hi, the segfault during boot is coming from bootlogd,
-      see bug #737375
-    <gnu_srs> also the output on the console is from there: end_request: I/O
-      error, dev 02:00, sector 0
-    <teythoon> gnu_srs: interesting :)
-    <teythoon> gnu_srs: i believe the end_request message comes from gnumach
-    <youpi> yes, that's just a floppy disk access attempt
-    <gnu_srs> might be so yes
-    <youpi> it's not a "might", it's sure :)
-    <youpi> dev 02:00 is the flopy
-    <gnu_srs> k!
-
-
-## [[glibc_IOCTLs]], `TIOCCONS`
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-04
-
-    <zigo> Each time I upgrade my hurd box, I cannot login into it ...
-    <zigo> No login prompt.
-    <zigo> WTF is going on?
-    <zigo> How to fix?
-    <teythoon> zigo: most likely your hurd console is not running and there is no getty started for the mach console
-    <zigo> teythoon: How to fix? (note: I already have the partition mounted in a loopback)
-    <zigo> Or maybe go in recovery mode?
-    <teythoon> depends
-    <teythoon> do you use sysvinit ?
-    <teythoon> do you use the hurd packages from hurd-ci ?
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-05
-
-    <zigo> teythoon: Sorry, didn't see your reply. I just used the Hurd image,
-      untar it, and apt-get update / dist-upgrade. That's it, nothing more or
-      less.
-    <zigo> teythoon: I obviously would like to install sysvinit, and later
-      OpenRC. That's the reason why I'm running Hurd: to make sure OpenRC works
-      with it without issues.
-    <zigo> teythoon: It seems it "sometimes work" or what???
-    <zigo> I was able to repair it using the recovery mode, it seems.
-    <zigo> grrr...
-    <zigo> I got this issue again, again and again ...
-    <zigo> Sometimes, got the tty1, sometimes, it doesn't appear.
-    <zigo> That's REALLY frustrating.
-    <pere> zigo: and yes, the success rate for boot is not 100%.  it increases
-      a bit by using the packages teythoon created at hurd-ci.
-    <pere> apparently some race condition somewhere.
-    <zigo> pere: So, I should just try and reboot again and again ?
-    <zigo> pere: Is it improving after switching to sysvinit?
-    <pere> once I had to boot six times before I got it running...
-    <pere> I was told that the race involves a call to fsysopts, and that the
-      success rate with sysvinit was smaller because fsysopts command was
-      called earlier. I can not confirm nor deny this.
-    <pere> with the latest packages from hurd-ci the success rate is almost
-      100% again.
-    <zigo> pere: Where do get that?
-    <pere> zigo: see <URL:
-      http://people.skolelinux.org/pere/blog/Testing_sysvinit_from_experimental_in_Debian_Hurd.html
-      >
-    <zigo> pere: What's the "update-alternatives --config runsystem" for?
-    <pere> to switch to sysvinit
-    <zigo> Right, that's what I was missing then! :)
-    <pere> the new sysvinit version in unstable was built for hurd one and a
-      half hour ago.  so soon hurd users can skip experimental for that.
-    <zigo> pere: I've just succeeded in booting with OpenRC! :)
-    <zigo> Though this console pb is REAAAALLLYYYY getting on my nerves! :)
-    <zigo> Also, any idea why we don't get the nice colorfull output when
-      booting?
-    <zigo> When booting with OpenRC, I've noticed that the dependency loop
-      detects some loops with the hurd-console thing.
-    <teythoon> zigo: good to hear that you got it working
-    <teythoon> the console problem is the following
-    <teythoon> when you shutdown using sysvinit, the system will run umount -a
-    <teythoon> it will then mistake some translators (like the one on /dev/vcs)
-      for file systems and remove their passive translator records
-    <teythoon> you can fix this by running '/usr/lib/hurd/setup-translators -k
-      -p'
-    <teythoon> you can avoid it for the time being by using reboot-hurd or
-      halt-hurd
-    <pere> teythoon: btw, how often is the hurd boot image available for
-      download updated?
-    <teythoon> not very often
-    <zigo> teythoon: Can I run  '/usr/lib/hurd/setup-translators -k -p'
-      mounting my hurd image in a chroot?
-    <zigo> Hum...
-    <zigo> Probably better to do that in the recovery mode, no? :)
-    <youpi> dpkg-reconfigure hurd 
-    <youpi> would be easier to type :)
-    <youpi> but we really need to fix that /dev/vcs unmounting
-    <pere> missing working getty and missing symlink from /run/mtab to
-      /proc/mount are the most serious problems I still see.
-    <zigo> The recovery mode doesn't work with OpenRC ! :(
-    <zigo> (it does in kFreeBSD and Linux, not with hurd ...)
-    <zigo> What happens is that it continues to runlevel 2.
-    <zigo> How can I fix then?
-    <youpi> pere: missing working getty?
-    <youpi> I don't see what issue you are referring to
-    <youpi> about the missing symlink, I'm wondering what is supposed to add it
-    <youpi> zigo: I don't know if anybody investigated it yet
-    <pere> youpi: yes, after boot there is no login prompt.
-    * pere have no idea, suspect a script in initscripts.
-    <zigo> youpi: I'm reffering to the fact that I have no login prompt after
-      boot, and that I don't know how to fix, since I don't have a recovery
-      mode to my disposal anymore.
-    <youpi> pere: but is the console started?
-    <youpi> (I mean the hurd console)
-    <zigo> pere: I suspect a wrong dependency, which OpenRC by the way, prints.
-    <youpi> pere: otherwise, unless you have a /dev/console getty in
-      /etc/inittab, it's expected you don't have a prompt
-    <youpi> zigo: add
-    <youpi> c:23:respawn:/sbin/getty 38400 console
-    <youpi> to your /etc/inittab
-    <teythoon> youpi: yes, we need to get that fixed
-    <youpi> grrrr
-    * youpi wanted to change the image file on people.d.o
-    <youpi> but I can't do that without downloading it on my laptop, to be able
-      to modify it
-    <youpi> I would have been, if people was a hurd system :)
-    <teythoon> the proper way to fix this is to implement the get_source stuff
-      and get rid of the heuristic in mtab.c
-    <pere> youpi: nope, no console process running.
-    <youpi> then that's why, /dev/vcs got unmounted
-    <pere> I already have a console getty in inittab.  got it from the last
-      sysvinit package
-    * youpi should have brown-bag-fixed these bugs before this week-end
-        actually  :)
-    <youpi> pere: but you don't get a getty prompt on the mach console? I don't
-      understand why
-    <youpi> it does work for me
-    <teythoon> brown-bag-fixed ?
-    <zigo> youpi: Adding that in /etc/inittab didn't fix anything.
-    <youpi> yes, ugly hacks uploaded to debian-ports
-    <youpi> zigo: even with rebooting?
-    <youpi> could you snapshot your screen so we can make sure what you are
-      actually  getting?
-    <zigo> youpi: I did it mounting my partition in a loopback...
-    <zigo> Then booted up, and still couldn't see the console prompt.
-    <youpi> ok, but please take a snapshot, so we are sure what is actually
-      happening
-    <youpi> whether the console starts, etc.
-    <pere> that info passed out of the screen and is not shown after my boot,
-      at least.
-    <youpi> which info?
-    <youpi> again, please take a snapshot of the screen
-    <youpi> otherwise we are just guessing, and that's never good for debugging
-    <zigo> Maybe you'll find this interesting: http://paste.debian.net/80246/
-    <zigo> This is the output of OpenRC booting and detecting dependency loops
-      in the LSB header scripts.
-    <pere> youpi: the info about the console being started or not.  I'll show
-      you, give me a minute.
-    <youpi> zigo: well, that shouldn't be more problems than the dependency
-      loop already existing between rc.local and rmnologin
-    <pere> youpi: any loop is a fatal problem.
-    <youpi> how come the rc.local vs rmnologin is not a problem ?
-    <zigo> With sysv-rc in Debian, there's all sorts of loops that are just
-      silent.
-    <pere> I have not seen that loop on my linux system, so I am unsure what
-      you talk about.
-    <youpi> (the actual issues is simply that all three use Required-start:
-      $all, and thus all depend on each other)
-    <zigo> That's a huge pb IMO.
-    <youpi> pere: well, 
-    <pere> zigo: show me one?  
-    <youpi> rc.local:# Required-Start:    $all
-    <youpi> rmnologin:# Required-Start:    $remote_fs $all
-    <zigo> Yeah, the $all is just *bad*.
-    <pere> that is no loop.
-    <zigo> I do believe we should implement a lintian warning about it.
-    <pere> sure, $all do not behave the way most people expect, and should be
-      avoided as much as possible.
-    <pere> any other loops?
-    <youpi> no
-    <youpi> (not that I know of)
-    <pere> youpi: sending you the screenshot via irc.
-    <youpi> uh, long time no use dcc send, I don't even know where it sent it
-      to :o)
-    <pere> ok. aborting and trying another approach.
-    <pere> http://www.picpaste.com/booted-herd.png
-    <youpi> ok, so boot didn't actually finish
-    <youpi> that's why you don't get gettys or hurd-console (which is last)
-    <youpi> there must be some init script hanging in the meanwhile
-    <pere> logging in via ssh show no running startpar process, so I doubt that
-      is the case.
-    <pere> syslog contain this: Feb  5 10:10:27 hurdtest console[808]: Console
-      library initialization failed: Not a directory
-    <youpi> that is due to /dev/vcs not mounted
-    <youpi> but that should have not prevented the boot from completing...
-    <pere> the boot is completed, as far as I can tell.
-    <youpi> you can disable the hurd console in /etc/defaults/hurd-console
-    <youpi> do you have gettys running?
-    <pere> no such file.
-    <youpi> oops, -s
-    <pere> http://paste.debian.net/80251/
-    <teythoon> pere: check your /etc/inittab, is there a getty for the mach
-      console ?
-    <youpi> he said yes earlier
-    <teythoon> oh ok
-    <teythoon> i wonder why it doesn't show up then
-    <youpi> same for me
-    <teythoon> if the getty cannot open the device, it will loop
-    <pere> ah, I was wrong.  the inittab is not the one I thought.  the current
-      one is after a reinstall, while I checked the content before that.
-    <teythoon> pere: check /var/log/auth.log
-    <pere> there is indeed no console entry in /etc/inittab.  I thought it
-      would be copied into place during upgrades?
-    <teythoon> not if it exists
-    <teythoon> iirc
-    <youpi> indeed
-    <pere> ah, great.  "cp /usr/share/sysvinit/inittab  /etc/inittab" and a
-      reboot fixed it. :)
-    <youpi> phew :)
-    <pere> it really should try harder to update the inittab on hurd to a
-      working one.
-    <teythoon> didn't i do something like this to fix the getty path ?
-    <pere> yes.  that was the code I expected to solve this.
-    <teythoon> it didn't work ?
-    <pere> well, I had the wrong inittab file...
-    <pere> btw, do hurd have the needed syscalls for bootlogd to work?
-    <teythoon> i haven't looked at bootlogd yet
-    <pere> would be nice to have a text dump of the boot when trying to figure
-      out what went wrong.
-    <teythoon> yes, that'd be nice
-
-    <youpi> pere: could you blacklist /dev/vcs in umountfs, just like already
-      done for /proc|/dev|/.dev etc. ?
-    <youpi> so at least that case, which is really problematic, gets fixed now,
-      and not have to wait for another, more hurdish solution
-    <pere> youpi: just send patches to bts, and I'll pick it up from there.
-    <teythoon> nice. i'll work on the proper solution. bbl
-    <rleigh> teythoon: Can we add those translators to the exclusion lists in
-      umount[nfs]?
-    <rleigh> Sorry, I just noticed youpi's comment.  I'm a bit behind.
-    <heroxbd> rleigh: good to see you! are you back to the keyboard? fully
-      recovered?
-    <rleigh> Not quite fully, but on the mend, thanks!
-    <heroxbd> :]
-    <pere> rleigh: yeah, good to see you again.  I got a burst of energy and
-      brushed a bit on sysvinit in your absence. :)  Even revitalized the
-      #pkg-sysvinit channel. :)
-    <rleigh> pere: Yes, I saw all the commit emails flying by!
-    <rleigh> I realistically won't be doing much for several weeks at least
-      though, I'm afraid.
-    <pere> no worries. spend your time getting well.   :)  it would be great to
-      have you on #pkg-sysvinit, though. :)
-    <rleigh> I'll join, no worries.  I should add it to my irssi config so I
-      can't forget!
-    <heroxbd> teythoon: serial console always works, right? no matter how
-      hurd-console behaves.
-    <teythoon> heroxbd: yes
-    <teythoon> but you need a getty on it
-    <youpi> well, just like on linux :)
-    <teythoon> yes
-    <teythoon> almost
-    <teythoon> on mach, we have the mach console. by default that is put on the
-      vga screen, but you can make mach put it on a serial port using the
-      gnumach command line flag console=comX
-    <youpi> well, just like on linux :)
-    <heroxbd> understood, thanks!
-    <teythoon> oh, i didn't realize linux has this as well
-    <heroxbd> teythoon: you'll use it a lot on a embedded system
-    <heroxbd> an*
-    <teythoon> ok
-
-    <gg0> plus, seems it can't cleanly umount /, at boot it fsck's it, fixes it
-      and auto-reboot
-    <youpi> it's odd that / doesn't get unmounted, don't you get a message at
-      "notifying ext2fs device:hd0s1 of shutown" ?
-    <gg0> on console last 3 lines on halt are
-    <gg0> Deactivating swap...swapoff: /dev/hd0s5: 4193208k swap space
-    <gg0> done.
-    <gg0> Unmounting local filesystems...done.
-    <gg0> INIT: no more processes left in this runlevel
-    <youpi> is this on reboot or on halt?
-    <gg0> halt
-    <youpi> then you should also be getting the "notifying" messages, as well
-      as "In tight loop: hit ctl-alt-del to reboot" message
-    <gg0> it umounts uncleanly on reboot too
-    <youpi> if you don't wait for these, there's little wonder it's not
-      properly unmounted
-    <gg0> i waited many seconds, time to rewrite 3 lines above for you for
-      instance (not a fast typist)
-    <gg0> on reboot it's harder but iirc they don't appear as well
-    * gg0 rebooting again
-    <gg0> need to wait it finishes fsck'ing
-    <gg0> (i should resoldering my serial cable to get back to lazily c&p)
-    <gg0> -ing
-    <gg0> many Give root password messages then
-    <gg0> Give root password for maintenance
-    <gg0> (or type Control-d to continue):
-    <gg0> INIT: Id "z6" respawning too fast: disabled for 5 minutes
-    <gg0> INIT: no more processes left in this runlevel
-    <gg0> i'll wait 5 mins to see what happen
-    <gg0> ok another dozen of Give root password and same couple of INIT above
-    <gg0> no, just the first INIT
-    <youpi> so z6 doesn't work
-    <youpi> i.e. /sbin/sulogin (see /etc/inittab)
-    <youpi> check out why that is
-
-[[hurd/translator/mtab/discussion]], *IRC, freenode, #hurd, 2013-06-25*,
-*coreutils' `df`*.
-
-    <youpi> [...] depends on coreutils actually building
-    <youpi> which depends on putting back a login package from the shadow
-      source package
-    <pere> are someone on that task?
-    <youpi> no idea
-    <youpi> IIRC I've mentioned the issue on the lists like months ago
-    <youpi> but probably nobody took the tas
-    <youpi> k
-    <youpi> basically it means fixing any bug that login or su from the login
-      package would have
-    <youpi> and then properly handle the migration from hurd-provided versions
-      to login-provided versions
-    <youpi> and then we would be able to build coreutils
-    <pere> which BTS report is this?
-    <youpi> I don't know if any report has been written about it
-    <youpi> perhaps simplest would be to build the login package, but not its
-      bin/login
-    <youpi> it seems hurd's getty uses special options of hurd'slogin
-    <youpi> that's probably the easiest way to go
-
-    <gg0> sulogin seems to work fine but it shouldn't even called:
-    <gg0> # Normally not reached, but fallthrough in case of emergency.
-    <gg0> z6:6:respawn:/sbin/sulogin
-    <gg0> +be
-    <pere> I suspect a good fix is to provide a new init.d script in the hurd
-      package adding the symlink for hurd.
-
-    <gg0> umountfs gets stuck at "Will now umount local filesystem:settrans
-      -apgf /lib/rc/init.d"
-
-
-## IRC, freenode, #hurd, 2014-02-05
-
-    <gnu_srs> teythoon: Any ideas why I have to issue halt/reboot twice to make
-      the command succeed (from ssh login)
-    <gnu_srs> Is it the same issue with sysv-rc? 
-    <teythoon> no
-    <gnu_srs> BTW: The segfault when booting came from bootlogd (wrong
-      parameters, Linux/~Linux), removing that one fixed it;-)
-
-
-## IRC, freenode, #hurd, 2014-02-06
-
-    <youpi> teythoon: we really need to find the boot issue for which you added
-      a sleep 0.1 in runsystem.sysv
-    <youpi> apparently I had to move it above the mach-defpager startup, to get
-      a system that boots most of the time...
-
-    <azeem> did somebody look at
-      http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html
-      ?
-    <braunr> azeem: interesting
-    <azeem> braunr: was mentioned here: http://lwn.net/Articles/584428/
-    <azeem> " Systemd won't work for them, that's for sure, but nosh as a
-      systemd unit file compatible alternative could. "
-    <braunr> "I'm also very interested in seeing a discussion where the Debian
-      Hurd and BSD porters weigh in for themselves"
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-06
-
-    <gg0> on halt/reboot it can't remount readonly root because it's busy, what
-      makes it busy?
-    <gg0> by keeping /lib/rc/init.d mounted (like /dev/vcs) it shuts down
-      properly
-    <youpi> I don't know about such directory
-    <gg0> so seems that failed readonly remount is not a real problem because
-      at the end it runs halt-hurd/reboot-hurd which umount root properly
-    <youpi> yes
-    <gg0> afaiu it's a tmpfs where openrc copies "itself", kind of work
-      directory
-    <gg0> by removing it, it can't continue working
-    <gg0> at boot some messages are about its creation/population
-    <pere> why do init.d/hurd-console depend on $all?  In most cases, depending
-      on $all is not giving you want you expect.
-    <youpi> because we prefer to start the console (and thus clear all the
-      screen) only after the boot has finished
-    <youpi> otherwise the console output will be messed up by the end of the
-      boot messages
-    <teythoon> youpi: there has to be a better way
-    <teythoon> b/c the way it is now, if one spawns a getty on the mach
-      console, it will mess up the hurd console as well
-    <youpi> well, we do want mach messages printed even with the hurd console,
-      at least
-    <teythoon> i once thought that instead of printing them the kernel could
-      send messages to a registered userspace daemon that could e.g. send them
-      to syslog
-    <youpi> that requires syslog to be working at all
-    <pere> changing $all to $local_fs seem to work fine here.
-    <youpi> when the kernel cries out, we'd better always be able to hear it :)
-    <youpi> pere: but then you have the bootup messages in the middle of the
-      console, don't you?
-    <pere> not as far as I can tell. look just the same as before.
-    <youpi> well, on my box it seems that it gets to start after other daemons,
-      by luck
-    <youpi> ah, perhaps getty actually clears the tty?
-    <youpi> then that would be ok
-    <teythoon> youpi: i don't think it does
-    <youpi> well, somehow something clears the output at least
-    <teythoon> i thought he hurd console does this
-    <youpi> it does on startup, yes
-    <youpi> but if it starts before other daemons
-    <youpi> the damons startup output gets over it
-    <youpi> one sees the console clear the screen, then get daemon startup
-      messages, and then the screen gets cleared again before the login prompt
-      appears
-    <teythoon> interesting, i haven't seen this happening
-    <youpi> it seems like it happens when emitting text on /dev/tty1, the
-      console will then clear the screen to make the way for the new output
-    <youpi> and since that happens on getty startup, it happens to be after all
-      daemon startup
-    <youpi> yes, that's what happens
-    <youpi> so considering this, I'm fine with starting the console earlier
-    <youpi> getting a display glitch seems to have been acceptable on Linux for
-      years :)
-    <youpi> (during boot, I mean)
-    <teythoon> ok
-
-    <gg0> anyone else tried openrc?
-    <gg0> 15:20 < pere> yes, it did not umount properly.
-    <gg0> 15:36 < gg0> reboot or halt? it takes few seconds to actually
-      reboot/halt since the last message from openrc
-    <gg0> 15:39 < gg0> any typo adding such path?
-    * gg0 likes cross-channel pasting
-    <gg0> anyone else keeps getting unclean umounts even after applying
-      http://paste.debian.net/plain/80386/ ?
-    <teythoon> gg0: yes, me. worked fine, it didn't shut down properly though
-    <gg0> here works like a charm
-    <gg0> what do you mean by properly?
-    <gg0> i see first it can't remount root readonly but at least by not umount
-      path in question it continues executing scripts till actually shut it
-      down with something like {halt,reboot}-hurd
-    <gg0> *not umounting
-    <gg0> *shutting
-    <teythoon> for me it did not shut down
-    <gg0> you mean don't you get classic press ctrl+alt+canc to reboot message?
-    <teythoon> yes
-    <teythoon> from my perspective (and from /hurd/init's), that's not shutting
-      down
-    <teythoon> as in it did not call reboot(2)
-    <gg0> what are configuration not to miss besides switching runsystem to
-      sysv one?
-    <gg0> *configuration steps
-    <teythoon> no idea, i did nothing else but to switch to runsystem.sysv and
-      to install openrc thus replacing sysv-rc
-    <gg0> can you paste shutdown messages somewhere?
-    <teythoon> sure
-    <gg0> .o(world is failing, /me can't debug teythoon :))
-    <teythoon> http://paste.debian.net/hidden/745071e6/
-    <gg0> in my case i just found out that /etc/init.d/umountfs tries to umount
-      /lib/rc/init.d where openrc scripts are
-    <gg0> what if you set VERBOSE and print REG_MTPTS? something like
-      http://paste.debian.net/plain/80570/
-    <gg0> there i got "settrans -apfg /lib/rc/init.d" which vanished with first
-      patch
-    <teythoon> http://paste.debian.net/80573/
-    <gg0> ok and if you apply first patch http://paste.debian.net/plain/80386/
-    <gg0> i.e. adding |/lib/rc/init.d to mount point to ignore
-    <teythoon> didn't help
-    <gg0> well output should change though
-    <teythoon> it does
-    <teythoon> but it still does not shut down
-    <gg0> paste please then
-    <teythoon> http://paste.debian.net/80576/
-    <teythoon> what did you expect ?
-    <gg0> did you unapply VERBOSE & print REG_MTPTS?
-    <teythoon> yes
-    <teythoon> no
-    <teythoon> well
-    <gg0> seems you do, if VERBOSE is set, it prints Will now unmount local
-      filesystems"
-    <teythoon> i restored a vm snapshot, and applied both patches
-    <gg0> instead of "Unmounting local filesystems"
-    <gg0> *seems you did
-    <teythoon> http://paste.debian.net/80577/
-    <teythoon> shall i do it again ?
-    <gg0> and what after "root@debian:/# halt" ? :p
-    <teythoon> 23:55 < teythoon> http://paste.debian.net/80576/
-    <teythoon> and openrc shouting lots of stuff about breaking dependencies
-    <gg0> please yes do it again
-    <gg0> if VERBOSE is set, it prints "Will now unmount local filesystems"
-      instead of "Unmounting local filesystems"
-    <teythoon> yes, you are right
-    <teythoon> still, it does not work
-    <teythoon> http://paste.debian.net/80579/
-    <gg0> i'm curious about the new REG_MTPTS, supposing /lib/rc/init.d has
-      been suppressed
-    <gg0> ok stop
-    <gg0> 23:47 < gg0> ok and if you apply first patch
-      http://paste.debian.net/plain/80386/
-    <teythoon> i did
-    <teythoon> well, i added that path
-    <gg0> i don't believe so, it should ignore it if added
-    <teythoon> did it fix the issue for you ?
-    <gg0> yes
-    <gg0> any typo in addition?
-    <gg0> obviously patch is against sysvinit source but you have to apply it
-      to /etc/init.d/umountfs
-    <teythoon> obviously
-    <gg0> isn't it time to tell me you are kidding me yet?
-    <youpi> pere: thanks for the upload. I happened to realized that since it
-      was in collab-maint, I could as well just commit changes, I hope it's ok?
-    <teythoon> gg0: root@debian:~# fgrep '/lib/rc/init.d' /etc/init.d/umountfs
-      /|/proc|/dev|/.dev|/dev/pts|/dev/shm|/dev/.static/dev|/proc/*|/sys|/sys/*|/run|/run/*|/lib/rc/init.d)
-    <gg0>  /dev/vcs is missing, not the latest sysvinit version
-    <gg0> could this affect shutdown?
-    <teythoon> i know
-    <teythoon> possibly
-    <gg0> what if you also add /dev/vcs to path list?
-    <teythoon> what then ?
-    <teythoon> i don't mind /dev/vcs being 
-    <teythoon> err, 'umounted'
-    <teythoon> i can handle that just fine
-    <gg0> i mean what happens if you add /dev/vcs to path list in
-      /etc/init.d/umountfs as you did with /lib/rc/init.d?
-    <gg0> what happens = how it shutdown
-    <teythoon> why would it be any different ?
-    <gg0> no idea, seems the only change you don't have
-    <gg0> i just know it fixes hurd console
-    <teythoon> i know it fixes the hurd console b/c i was the one who broke the
-      hurd console in the first place ...
-    <gg0> quite sure there's something wrong on your side
-    <gg0> if it's actually among those path to ignore, it can't be added to
-      REG_MTPTS
-    <gg0> my /proc/mounts http://paste.debian.net/plain/80583
-    <gg0> yours?
-    <gg0> i hope i'm not forgetting one change i did around
-    <gg0> teythoon: /proc/mounts ?
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-07
-
-    <gg0> teythoon: sorry for pasting reversed patches
-    <gg0> please apply http://paste.debian.net/plain/80587, halt and paste
-      output + /proc/mounts
-    <pere> youpi: just fine.  but please join us on #pkg-sysvinit and make sure
-      to follow the mailing lists.
-    <teythoon> gg0: no, sorry, i was perfectly able to use -R on your patches,
-      as demonstrated by the paste i send
-    <teythoon> i think i'll rather just wait for the next sysvinit package and
-      try it again
-    <gg0> teythoon: i don't doubt you are able, i'm sorry because i messed up
-      things
-    <gg0>  /lib/rc/init.d should not go in $REG_MTPTS
-    <gg0> sysvinit 2.88dsf-48 just add /dev/vcs to not-to-umount paths and make
-      boot consider -s for single user, nothing about umounting filesystems on
-      halt/reboot
-    <pere> the /lib/rc/init.d/ change to umountfs seem to be the wrong one, as
-      it do not solve the problem for me.  because of this, I have not applied
-      it to git.
-    <gg0> pere: could you try to apply http://paste.debian.net/plain/80587,
-      halt and paste output?
-    <gg0> well it applies to teythoon who doesn't have /dev/vcs
-    <gg0> */dev/vcs change
-    <gg0> pere: this one applies to -48
-      installed. http://paste.debian.net/plain/80615/
-    <gg0> given /lib/rc/init.d is added to not-to-umount paths it can't go in
-      REG_MTPTS
-    <pere> http://picpaste.com/halt-hurd-DVEVoHnr.png
-    <gg0> pere: you didn't apply it
-    <gg0> no messages from umountfs
-    <gg0> which is even more weird
-    <pere> well, patch claimed it did.
-    <gg0> normally it says "Unmounting local filesystems..."
-    <pere> checked the file, patch is applied.
-    <gg0> ok i think i got it
-    <gg0> patch is good. it just requires booting twice _and_ removing
-      non-patched /etc/init.d/umountfs.* if any
-    <gg0> patch = adding /lib/rc/init.d
-    <gg0> so
-    <pere> which files do you need to remove?
-    <gg0>  /etc/init.d/umountfs.* and /lib/rc/init.d/started/umountfs.*
-    <gg0> do you have any?
-    <gg0> you should just have patched umountfs under both /etc/init.d/ and
-      /lib/rc/init.d/started/
-    <gg0> the latter is populate at boot, that's why i said twice to become
-      effective
-    <gg0> *populated
-    <gg0> but propably /lib/rc/init.d/started/umountfs can be fixed on the fly
-    <gg0> from start:
-    <pere> why do you need to remove these files?
-    <gg0> 1/ patch /etc/init.d/umountfs by adding /lib/rc/init.d to
-      not-to-umount path list
-    <pere> why are these files not ignored?
-    <gg0> 2/ remove /etc/init.d/umountfs.* if any (eg. .orig .new .whatever)
-    <gg0> pere: because it loads them at boot, you need it loads just the right
-      one
-    <gg0> 3/ reboot twice
-    <gg0> (3/ halt twice)
-    <pere> this sound very fishy to me.
-    <gg0> or 3/ fix umountfs files under /lib/rc/init.d/started as well
-    <gg0> that should make it shutdown properly right away
-    <pere> my halt still hang.
-    <gg0> pere: you have /lib/rc/init.d in both /etc/init/umountfs and
-      /lib/rc/init.d/started/umountfs and there are no umountfs.* around?
-    <gg0> problem seems to be it picks first it finds if there are more than
-      one
-    <gg0> well i could have been more precise: /lib/rc/init.d/started/umountfs
-      is a link to /etc/init.d one
-    <gg0> btw there must be just one and only one umountfs, patched
-    <gg0> pere: clean /etc/init.d, reboot/halt with reboot-hurd or halt-hurd,
-      then next sysv reboot/halt will be good
-    <gg0> you just need to leave patched umountfs under /etc/init.d alone
-    <gg0> patch has always been good, it just needs 2 reboots to be appreciated
-    <gg0> pere: do you have other /etc/init/umountfs* files besides patched
-      one?
-    <gg0> my guess is it takes the first and only the first which Provides:
-      umountfs
-    <gg0> 12:17 < pere> why are these files not ignored?
-    <gg0> 12:35 < gg0> my guess is it takes the first and only the first which
-      Provides: umountfs
-    <gg0> to confirm that, if you have umountfs and umountfs.orig, under
-      /started you'll find just umountfs.orig
-    <gg0> pere: how goes?
-    <gg0> teythoon: last ~40 lines
-    <gg0> i'm assuming you have any else umountfs.* under /etc/init.d. if you
-      just add /lib/rc/init.d path to the only umountfs there should not be any
-      problem
-    <pere> gg0: removing the umountfs.* files did not help, as far as I can
-      tell.
-    <pere> are you telling me that openrc caches all init.d scripts in
-      /lib/rc/init.d/ at boot?
-    <gg0> pere: yes, you can see them. which umountfs* do you have under
-      /lib/rc/init.d ?
-    <pere> the right one. :)
-    <gg0> only the right one?
-    <pere> just scared me to know that changes on the disk do not take effect
-      immediately with openrc.
-    <gg0> pere: only the right one?
-    <pere> yes
-    <gg0> here i screwed it up by forcing initscripts removal and reinstall to
-      reproduce it, then fixed it once again
-    <gg0> i should just improving the explaination :)
-    <gg0> pere: "removing the umountfs.* files did not help," so did you find
-      any?
-    <pere> yes, both .orig, .rej and .dpkg-old
-    <gg0> pere: ok you should find one of them linked under
-      /lib/rc/init.d/started then
-    <gg0>  /lib/rc/init.d/started/umountfs.*
-    <pere> I removed them three boots ago.  still halt hangs.
-    <gg0> pere: and current umountfs have /lib/rc/init.d in path list?
-    <gg0> *has
-    <pere> yes.
-    <gg0> pere: can you access via ssh to it before issuing halt?
-    <pere> that is how I access it normally.
-    <gg0> ok
-    <gg0> before halt df should list /lib/rc/init.d as well
-    <gg0> after halt it should not, do you confirm that?
-    <gg0> (ssh connection here is kept alive)
-    <pere> my ssh connection went down, but /lib/rc/init.d was mounted while it
-      was active.
-    <pere> to me it look like umountfs isn't executed at all during shutdown.
-    <pere> oh, well.  got to work on other things now. :)
-    <gg0> it's correct getting no messages if there no filesystem to umount
-    <gg0> as it wouldn't be run at all
-    <zigo> pere: Hey, thanks for uploading sysv-rc -48 ! :)
-    <pere> you are welcome. :)
-    <gg0> i can't reproduce it on a VM :/ http://paste.debian.net/plain/80658/
-    <gg0> ehm no, same machive, successive halt
-      http://paste.debian.net/plain/80659/
-    <gg0> got stuck
-    <pere> are there any testet sysvinit patches for hurd lingering?  I plan to
-      upload a new version tonight or tomorrow.
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-08
-
-    <gg0> http://paste.debian.net/plain/80854/
-    <gg0> expected?
-    <gg0> do tmpfs and procfs need to be shown as types /hurd/tmpfs and
-      /hurd/procfs?
-    <gg0> or can they be "normalized"?
-    <gg0> domount mount_noupdate tmpfs shmfs /run tmpfs
-      -onosuid,noexec,size=10%,mode=755
-    <gg0> another one is why on linux options are nosuid,noexec ^, whereas on
-      hurd no-suid,no-exec,... ?
-    <rleigh> gg0: If they need generalising, we can add $nosuid/$noexec
-      etc. variables to mount-functions.sh and set them appropriately for the
-      currently platform.
-    <rleigh> current platform rather
-    <gg0> yeah, i ask just to understand what side people prefers modifying, in
-      this case hurd vs sysvinit
-    <gg0> btw in the meanwhile i got tmpfs takes options without '-' though it
-      shows them with '-' in proc/mounts
-    <gg0> rleigh: and thanks for pointing out what looking for, little hints
-      saves hours in my case :)
-    [IRC connection closed]
-
-
-## IRC, freenode, #hurd, 2014-02-08
-
-    <youpi> gnu_srs: the -49 version of sysvinit contains a fix for bootlogd
-
-
-### IRC, freenode, #hurd, 2014-02-09
-
-    <gnu_srs> (16:31:17) <youpi>: gnu_srs: the -49 version of sysvinit contains
-      a fix for bootlogd
-    <gnu_srs> Nice for kFreeBSD, for Hurd it doesn't matter if we get a
-      segfault or an error code saying it's not implemented :-(
-    <youpi> segfault vs error code is really not the same
-    <youpi> iirc bootlogd would ignore the error
-    <gnu_srs> Nevertheless, bootlogd is not usable on Hurd :( 
-    <youpi> then fix it
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-08
-
-    <rleigh> gg0: If the sames are set by hurd itself, then it makes sense to
-      adapt sysvinit to cope with that rather than altering hurd since that
-      would be a fairly major compatibility break. OTOH, adding support for the
-      Linux/FreeBSD names in addition to the hyphenated names would be good
-      from the point of view of better interoperability generally, not just for
-      sysvinit.
-    <rleigh> For now, getting sysvinit to support the Hurd names is easy
-      enough, and if you do add the Linux/FreeBSD names then the compatibility
-      stuff can be removed when that's available.
-
-
-## IRC, freenode, #hurd, 2014-02-11
-
-    <gnu_srs> Hi, still problems with hurd console under openrc: console:
-      Console library initialization failed: Not a directory
-    <gnu_srs> and /dev/vcs is there
-    <youpi> gnu_srs: but is it a directory?
-    <gnu_srs> the output of console -d vga -d pc_mouse --repeat=mouse -d pc_kbd
-      --repeat=kbd -d generic_speaker -c /dev/vcs gives the response above
-    <gnu_srs> looks like /dev/vcs is a file. How to recreate the directory
-      content?
-    <gnu_srs> I thought it should not be removed with the latest sysvinit
-      package (-49)
-    <gnu_srs> from -48 changelog:  Tell init.d/umountfs to not umount /dev/vcs,
-      as it break the console on Hurd.  Patch from Samuel Thibault.
-    <youpi> gnu_srs: but did your reconfigure the hurd package to remount it ?
-    <gnu_srs> ?
-    <youpi>  /dev/vcs  won't magically be remounted by just not being unmounted
-      by sysvinit
-    <gnu_srs> dpkg-reconfigure hurd?
-    <youpi> sure
-    <gnu_srs> I can start the console manually, but ENABLE='true' in
-      /etc/default/hurd-console does not work (at least with openrc)
-    <youpi> does /dev/vcs becomes a mere file again with openrc?
-    <gnu_srs> no it's a directory with 6 entries
-    <youpi> does the /etc/init.d/hurd-console gets to starT?
-    <youpi> I'm afraid I'm really asking obvious questions that you should have
-      already asked for yourself
-    <gg0> so you mounted it and it's not a file anymore. does it work now?
-    <gnu_srs> it seem like the service is not started, trying to figure out
-      why:-D
-    <gnu_srs> I can restart it but it is not visible in rc-status?
-
-    <gg0> shutdown stuck at "Asking all remaining processes to
-      terminate...done." (even before distupgrade btw)
-    <gg0> seems stuck at killall5 -18
-    <teythoon> hm, that's bad
-    <teythoon> how do you know that ?
-    <gg0>  /etc/init.d/sendsigs and /etc/init.d/killprocs
-    <gg0> (yes, switched to sysvinit and testing openrc)
-    <teythoon> but killall5 -18 is SIGSTOP right?
-    <teythoon> and if it says ...done. then killall5 has already been run
-    <teythoon> so, how do you know it hangs at killall5 ?
-    <gg0> teythoon: "done" is "log_action_end_msg 0" just after killall5 -15,
-      then we should get "Killing all remaining processes" or "All processes
-      ended within $seq seconds."
-    <gg0> Asking all remaining processes to terminate...killall5 -15 -o 956 #
-      SIGTERM...done.
-    <gg0> All processes ended within 1 seconds...done.
-    <gg0> shutdown properly this time
-    <teythoon> hm
-    <teythoon> fwiw, i've also encountered hangs, haven't investigated yet
-    <gg0> with openrc?
-    <teythoon> yes
-
-    <gnu_srs> Is it so that with teythoons mtab translator umount -a unmounts
-      all passive translators, removing the translator records??
-    <gnu_srs> causing pflocal (and pfinet) to disappear?
-
-[[hurd/translator/mtab/discussion]].
-
-    <azeem> gnu_srs: didn't he say that this is getting fixed in his latest
-      patchset?
-    <gnu_srs> yes, what about mine and gg0s currently hosed systems?
-    <gnu_srs> yes, but until the patch makes into the next release,**
-    <youpi> gnu_srs: pflocal and pfinet don't appear in mtab
-    <youpi> because they don't expose whole directories, just a trivial node
-    <youpi> so no, they won't get umounted by umount -a
-    <youpi> simply check the content of /proc/mounts
-    <gnu_srs> so how come I cannot recover my image?
-    <gnu_srs> and gg0 neither
-    <youpi> no idea, I've never tried openrc
-    <youpi> when daring new fields, you face new issues, that's no wonder
-    <gnu_srs> so this does not happen with sysv-rc?
-    <youpi> I haven't seen any of this kind of issue
-    <youpi> whether it's related to using openrc vs sysvrc, I have no idea
-    <youpi> but at least that's a candidate for sure
-    <gnu_srs> well in my case hurd bootstrap is stuck after ext2fs exec and
-      before init
-    <gnu_srs> ant reinstalling hurd via linux does not help
-    <youpi> you mean the hurd package?
-    <youpi> you can also try to reinstall the libc0.3 package
-    <youpi> normally it should be all that is needed for boot
-    <youpi> perhaps also some /dev entries
-    <gnu_srs> yes, the hurd package. I will try with libc0.3 tomorrow. Which
-      /dev entries, and how to create them manually?
-    <youpi> "perhaps" implies that I don't know
-    <youpi> you can as well just boot with an install CD, mount your disk,
-      chroot into it, and run dpkg-reconfigure hurd there to recreate
-      everything in /dv
-    <youpi> +e
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-13
-
-    <youpi> pere, rleigh: which script is supposed to make /etc/mtab a symlink
-      to /proc/mounts already? I can't find it
-    <pere> youpi: see /lib/init/mount-functions.sh
-
-
-## IRC, freenode, #hurd, 2014-02-13
-
-    <braunr> teythoon: are the sysvinit debian packages in sid usable currently
-      ?
-    <teythoon> they are
-    <braunr> nice
-    <teythoon> youpi and pere have been busy polishing it quite a bit
-    <braunr> teythoon: and uhm, how does one enable sysvinit in debian ? :)
-    <braunr> ah, found pere's blog
-    <teythoon> braunr: didn't you read the postinst instructions ? :p
-    <teythoon> update-alternatives --config runsystem
-    <braunr> oh right
-    <braunr> got lost in the noise
-    <braunr> very nice
-    <braunr> still a few glitches i see, but it does the job
-    <braunr> although i'm not sure i like the lack of console prompt :/
-    <braunr> i'll keep darnassus on the old runsystem until this is fixed
-    <teythoon> braunr: cp -p /usr/share/sysvinit/inittab /etc/inittab
-    <teythoon> and  kill -HUP 1
-    <braunr> oh
-    <braunr> :)
-    <braunr> teythoon: thanks
-    <braunr> teythoon: do you know why there are three tmpfs instances after
-      startup (/run, and in addition, /run/shm and /run/lock) instead of one on
-      /run ?
-    <braunr> sorry for being so annoying :)
-    <teythoon> braunr: dunno, but that is what Debian does
-    <braunr> https://wiki.debian.org/ReleaseGoals/RunDirectory explains it a
-      bit
-    <teythoon> root@thinkbox ~src # uname -s; mount | grep /run
-    <teythoon> Linux
-    <teythoon> tmpfs on /run type tmpfs
-      (rw,nosuid,noexec,relatime,size=306952k,mode=755)
-    <teythoon> tmpfs on /run/lock type tmpfs
-      (rw,nosuid,nodev,noexec,relatime,size=5120k)
-    <teythoon> tmpfs on /run/shm type tmpfs
-      (rw,nosuid,nodev,noexec,relatime,size=613900k)
-    <braunr> i like this /run directory
-    <teythoon> yep, it's nice
-    <braunr> ah great, i can add ,sync=30 to fstab and it's added at boot time
-      :)
-
-
-## IRC, freenode, #hurd, 2014-02-17
-
-    <congzhang> hi, I think we should make console server separate from
-      hurd-console
-    <congzhang> if DM want start, console server need be start first
-    <braunr> congzhang: send patches
-    <congzhang> and hurd-console mark it start at the end of sysinit?
-    <teythoon> congzhang: i agree
-    <braunr> teythoon: isn't hurd-console the console server ?
-    <congzhang> I want to check whether it is need first
-    <teythoon> braunr: yes, but congzhangs point is (as i understand it) that
-      the backend component should be started earlier
-    <teythoon> then again, i know little about the hurd console
-    <congzhang> no, if user enable one dispaly manager, then cycle dependence
-      happen 
-    <braunr> why ?
-    <teythoon> i believe that is a different problem, namely that our
-      hurd-console init script depends on $all
-    <teythoon> pere: ^
-    <congzhang> hurd-console Required-Start： $all
-    <braunr> ok
-    <braunr> yes that's a separate issue, and easier to understand
-    <congzhang> teythoon: if wdm Required-Start hurd-console, then insserv
-      can't generate the script order, right ?
-    <teythoon> congzhang: possibly, i don't know for sure
-    <congzhang> It doesn't work , and I rename to S??wdm to later one like
-      S20wdm
-    <congzhang> but insserv will regenerate the script order in /etc/rc2.d/, I
-      can't depend on that
-    <pere> congzhang: $all means after all scripts not depending on $all, and
-      not what the intuitive interpretation would tell you.
-    <pere> the current implementation order all scripts as if $all were not
-      present, and then move all scripts depending on $all to the last order
-      number+1.
-    <pere> because $all is misunderstood by most users, I strongly recommend to
-      _not_ use $all in any init.d script.
-    <congzhang> pere: so to make wdm to be number+more?
-    <pere> congzhang: make it depend on $all and be lexically sorted after
-      hurd-console. :)
-    <congzhang> wdm need start after hurd-console, if console-driver will run
-      when hurd-console start
-    <pere> not quite sure how startpar handle that case, so it might not work
-      the way you want anyway.
-    <pere> adding a dependency on hurd-console should not hurt, though. :)
-    <congzhang> how make it lexically sorted after hurd-console?
-    <pere> w is already after h in the alphabet. :)
-    <congzhang> that's trick!
-    <pere> but startpar uses the info in /etc/init.d/.depend.* (makefile style)
-      to order scripts, so check what the result is there too.
-    <braunr> congzhang: no it's not
-    <congzhang> that's just cache
-    <braunr> congzhang: ?
-    <congzhang> and generated from script head?
-    <congzhang> the right way is Adding run-time dependencies  in script
-    <pere> congzhang: yes.  insserv called from update-rc.d generate the
-      .depend.* files, and startpar reads the files (and ignore the headers)
-      when starting scripts.
-    <congzhang> if the script have cycle dependence, no one can help
-    <pere> congzhang: if there is a cycle, update-rc.d will reject the script.
-    <congzhang> sure, because the system current have not runable one
-    <congzhang> Display  Manager run before hurd-console, and never successful
-      for X stared failed!
-    <pere> what is this hurd-console stuff, btw?  it sound like somthing that
-      should be started in rcboot.d (aka rcS.d on Debian).
-    <congzhang> if you install wdm, you will notice that wdm start failed
-    <pere> should it run before sulogin when booting into single user?
-    <congzhang> hurd-console mix too much thins
-    <teythoon> pere: it's the console multiplexes that provides /dev/tty?
-    <congzhang> just part of that function
-    <teythoon> pere: it's like screen or tmux a server-client architecture
-    <teythoon> the x server gets keyboard and mouse events from it iirc
-    <pere> right.  so not needed by sulogin, I guess.  because if it was, it
-      should start in rcS.d, not rc[2-5].d/.
-    <congzhang> and also start /bin/console to start keyboard and mouse driver 
-    <teythoon>  /bin/console is the frontend
-    <pere> and if it started in rcS.d/, it would always be started before
-      wdm. :)
-    <braunr> i think it should be started in rcS.d
-    <congzhang> why not essential?
-    <pere> braunr: when I tried, it failed.
-    <congzhang> https://www.gnu.org/software/hurd/hurd/console.html
-    <congzhang> teythoon: i want to make one disk img with default DM, and face
-      these problem
-    <braunr> pere: do you have a log of the failur e?
-    <congzhang> teythoon: I know you are working on the hurd init system, so I
-      ask you for help
-    <pere> braunr: only the boot message: Starting Hurd console multiplexer:
-      hurd-console failed!
-    <pere> braunr: how can I learn more?
-    <braunr> i don't know any easy way
-    <braunr> try to put the system in its early state manually
-    <braunr> and maybe run rpctrace on the actual console command
-    <braunr> if that is what really fails
-    <congzhang> and I found that pc_kbd may have some bug? I have high
-      frequence of start failed if I make it start
-    <congzhang> but I can't located the real source of these problem
-    <teythoon> pere: the console logs some messages to syslog
-    <pere> teythoon: looked, nothing there. :(
-    <pere> gah, look like I broke my hurd machine.  Added rpctrace to the start
-      of hurd-console, and now the boot just hang there, and when I interrupt
-      it the kernel reboot the entire machine. :(
-    <braunr> pere: use rpctrace manually, don't script it
-    <teythoon> oh yeah, seen this as well
-    <pere> braunr: well, no use to test it after boot when it hang during
-      boot...
-    <teythoon> it triggers an assertion in the proc server iirc
-    <braunr> pere: that doesn't imply you need to script it
-    <congzhang> pere: qemu snapshot mode will be your friend:)
-    <braunr> ideally, i'd run the init system automatically up to the point i
-      want to run my test, and make it spawn a shell, and use that shell then
-    <pere> congzhang: hah.  real men do to take backups.  but they weep a
-      lot. :)
-    <congzhang> teythoon: runsystem.sysv has work well on my machine, just some
-      error infomation
-    <teythoon> good
-
-
-## IRC, freenode, #hurd, 2014-02-21
-
-    <gnu_srs1> Hi, a general question: is ptrace available for GNU/Hurd?
-    <teythoon> yes
-    <gnu_srs1> tks, the openrc developers are working on process supervision
-      using it: good/bad? (compared to cgroups)
-    <teythoon> uh
-    <teythoon> i prefer the cgroups approach
-    <teythoon> but upstart also uses ptrace to keep track of the 'main' process
-      of an daemon
-    <teythoon> they use ptrace to follow a daemon that double forks
-    <gnu_srs1> teythoon: and regarding portability?
-
-
-## IRC, freenode, #hurd, 2014-02-24
-
-    <braunr> sysvinit doesn't seem to handle /etc/default/locale into
-      consideration
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-25
-
-    <gg0> how about switching runsystem.sysv by default?
-    <youpi> now that it seems to be running fine, we could do that, yes
-
-
-# Required Interfaces
-
-In the thread starting
-[here](http://lists.debian.org/debian-devel/2011/07/threads.html#00269), a
-[message](http://lists.debian.org/debian-devel/2011/07/msg00281.html) has been
-posted that contains the following list (no claim for completeness) of
-interfaces that are used in (two source code files of) systemd:
-
-  * cgroups
-  * namespaces
-  * selinux
-  * autofs4
-  * capabilities
-  * udev
-  * oom score adjust
-  * RLIMIT_RTTIME
-  * RLIMIT_RTPRIO
-  * ionice
-  * SCHED_RESET_ON_FORK
-  * /proc/$PID/stat
-  * fanotify
-  * inotify
-  * TIOCVHANGUP
-  * IP_TRANSPORT
-  * audit
-  * F_SETPIPE_SZ
-  * CLONE_xxx
-  * BTRFS_IOC_DEFRAG
-  * PR_SET_NAME
-  * PR_CAPBSET_DROP
-  * PR_SET_PDEATHSIG
-  * PR_GET_SECUREBITS
-  * /proc/$PID/comm
-  * /proc/$PID/cmdline
-  * /proc/cmdline
-  * numerous GNU APIs like asprintf
-  * [[SOCK_CLOEXEC, O_CLOEXEC|secure_file_descriptor_handling]]
-  * /proc/$PID/fd
-  * /dev/tty0
-  * TIOCLINUX
-  * VT_ACTIVATE
-  * TIOCNXCL
-  * KDSKBMODE
-  * /dev/random
-  * /dev/char/
-  * openat() and friends
-  * /proc/$PID/root
-  * waitid()
-  * /dev/disk/by-label/
-  * /dev/disk/by-uuid/
-  * /sys/class/tty/console/active
-  * /sys/class/dmi/id
-  * /proc/$PID/cgroup
-  * \033[3J
-  * /dev/rtc
-  * settimeofday() and its semantics
diff --git a/open_issues/term_blocking.mdwn b/open_issues/term_blocking.mdwn
deleted file mode 100644
index 1c8816e1..00000000
--- a/open_issues/term_blocking.mdwn
+++ /dev/null
@@ -1,339 +0,0 @@
-[[!meta copyright="Copyright © 2009, 2011, 2012, 2013 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_hurd]]
-
-There must be some blocking / dead-locking (?) problem in `term`.
-
-[[!toc]]
-
-
-# Original Findings
-
-    # w | grep [t]sch
-    tschwing  p1 192.168.10.60: Tue 8PM  0:03  2172 /bin/bash
-    tschwing  p2 192.168.10.60: Tue 4PM 40hrs   689 emacs
-    tschwing  p3 192.168.10.60:  8:52PM 11:37 15307 /bin/bash
-    tschwing  p0 192.168.10.60:  6:42PM 11:47  8104 /bin/bash
-    tschwing  p8 192.168.10.60:  8:27AM  0:02 16510 /bin/bash
-
-Now open a new screen window, or login shell, or...
-
-    # ps -Af | tail
-    [...]
-    tschwinge 16538  676  p6  0:00.08 /bin/bash
-        root 16554   128  co  0:00.09 ps -Af
-        root 16555   128  co  0:00.01 tail
-
-`bash` is started (on `p6`), but newer makes it to the shell promt; doesn't
-even start to execute `.bash_profile` / `.bashrc`.  The next shell started, on
-the next available pseudoterminal, will work without problems.
-
-The `term` on `p6` has already been running before:
-
-    # ps -Af | grep [t]typ6
-        root  6871     3   -  5:45.86 /hurd/term /dev/ptyp6 pty-master /dev/ttyp6
-
-In this situation, `w` will sometimes report erroneous values for *IDLE*
-for the process using that terminal.
-
-Killed that `term` instance, and things were fine again.
-
-
-All this reproducible happens while running the [[GDB testsuite|gdb]].
-
----
-
-Have a freshly started shell blocking on such a `term` instance.
-
-    $ ps -F hurd-long -p 1766 -T -Q
-      PID TH#  UID  PPID  PGrp  Sess TH  Vmem   RSS %CPU     User   System Args
-     1766        0     3     1     1  6  131M 1.14M  0.0  0:28.85  5:40.91 /hurd/term /dev/ptyp3 pty-master /dev/ttyp3
-            0                                        0.0  0:05.76  1:08.48
-            1                                        0.0  0:00.00  0:00.01
-            2                                        0.0  0:06.40  1:11.52
-            3                                        0.0  0:05.76  1:09.89
-            4                                        0.0  0:05.42  1:06.74
-            5                                        0.0  0:05.50  1:04.25
-
-... and after 5:45 h:
-
-    $ ps -F hurd-long -p 21987 -T -Q
-      PID TH#  UID  PPID  PGrp  Sess TH  Vmem   RSS %CPU     User   System Args
-    21987     1001   676 21987 21987  2  148M 2.03M  0.0  0:00.02  0:00.07 /bin/bash
-            0                                        0.0  0:00.02  0:00.07 
-            1                                        0.0  0:00.00  0:00.00 
-
-    $ ps -F hurd-long -p 1766 -T -Q
-      PID TH#  UID  PPID  PGrp  Sess TH  Vmem   RSS %CPU     User   System Args
-     1766        0     3     1     1  6  131M 1.14M  0.0  0:29.04  5:42.38 /hurd/term /dev/ptyp3 pty-master /dev/ttyp3
-            0                                        0.0  0:05.76  1:08.48
-            1                                        0.0  0:00.00  0:00.01
-            2                                        0.0  0:06.41  1:11.90
-            3                                        0.0  0:05.82  1:10.28
-            4                                        0.0  0:05.52  1:07.06
-            5                                        0.0  0:05.52  1:04.63
-
-    $ sudo gdb /hurd/term 1766
-    [sudo] password for tschwinge: 
-    GNU gdb (GDB) 7.0-debian
-    Copyright (C) 2009 Free Software Foundation, Inc.
-    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
-    This is free software: you are free to change and redistribute it.
-    There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
-    and "show warranty" for details.
-    This GDB was configured as "i486-gnu".
-    For bug reporting instructions, please see:
-    <http://www.gnu.org/software/gdb/bugs/>...
-    Reading symbols from /hurd/term...Reading symbols from /usr/lib/debug/hurd/term...done.
-    (no debugging symbols found)...done.
-    Attaching to program `/hurd/term', pid 1766
-    [New Thread 1766.1]
-    [New Thread 1766.2]
-    [New Thread 1766.3]
-    [New Thread 1766.4]
-    [New Thread 1766.5]
-    [New Thread 1766.6]
-    Reading symbols from /lib/libhurdbugaddr.so.0.3...Reading symbols from /usr/lib/debug/lib/libhurdbugaddr.so.0.3...
-    [System doesn't respond anymore, but no kernel crash.]
-
----
-
-The very same behavior is still observable as of 2011-03-24.
-
-Next: rebooted; on console started root shell, screen, a few spare windows; as
-user started GDB test suite, noticed the PTY it's using; in a root shell
-started GDB (the system one, for `.debug` stuff) on `/hurd/term`, `set
-noninvasive on`, attach to the *term* that GDB is using.
-
----
-
-[[2011-07-04]].
-
----
-
-2012-11-05
-
-Log file from a 2011-09-07 run:
-
-    [...]
-    Running ../../../master/gdb/testsuite/gdb.base/readline.exp ...
-    spawn [...]/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory [...]/gdb/testsuite/../data-directory
-    GNU gdb (GDB) 7.3.50.20110906-cvs
-    Copyright (C) 2011 Free Software Foundation, Inc.
-    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
-    This is free software: you are free to change and redistribute it.
-    There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
-    and "show warranty" for details.
-    This GDB was configured as "i686-unknown-gnu0.3".
-    For bug reporting instructions, please see:
-    <http://www.gnu.org/software/gdb/bugs/>.
-    (gdb) set height 0
-    (gdb) set width 0
-    (gdb) dir
-    Reinitialize source path to empty? (y or n) y
-    Source directories searched: $cdir:$cwd
-    (gdb) dir ../../../master/gdb/testsuite/gdb.base
-    Source directories searched: [...]/gdb/testsuite/../../../master/gdb/testsuite/gdb.base:$cdir:$cwd
-    (gdb) p 1
-    $1 = 1
-    PASS: gdb.base/readline.exp: Simple operate-and-get-next - send p 1
-    (gdb) p 2
-    $2 = 2
-    PASS: gdb.base/readline.exp: Simple operate-and-get-next - send p 2
-    (gdb) p 3
-    $3 = 3
-    PASS: gdb.base/readline.exp: Simple operate-and-get-next - send p 3
-    (gdb) p 3(gdb) p 3PASS: gdb.base/readline.exp: Simple operate-and-get-next - C-p to p 3
-    ^H2(gdb) p 2PASS: gdb.base/readline.exp: Simple operate-and-get-next - C-p to p 2
-    ^H1(gdb) p 1PASS: gdb.base/readline.exp: Simple operate-and-get-next - C-p to p 1
-    ^OFAIL: gdb.base/readline.exp: Simple operate-and-get-next - C-o for p 1
-    FAIL: gdb.base/readline.exp: operate-and-get-next with secondary prompt - send if 1 > 0
-    FAIL: gdb.base/readline.exp: print 42 (timeout)
-    FAIL: gdb.base/readline.exp: arrow keys with secondary prompt (timeout)
-    spawn [...]/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory [...]/gdb/testsuite/../data-directory
-    ERROR: (timeout) GDB never initialized after 10 seconds.
-    ERROR: no fileid for coulomb
-    ERROR: no fileid for coulomb
-    UNRESOLVED: gdb.base/readline.exp: Simple operate-and-get-next - send p 7
-    testcase ../../../master/gdb/testsuite/gdb.base/readline.exp completed in 646 seconds
-    Running ../../../master/gdb/testsuite/gdb.base/wchar.exp ...
-    Executing on host: gcc  -c -g  -o [...]/gdb/testsuite/gdb.base/wchar0.o ../../../master/gdb/testsuite/gdb.base/wchar.c    (timeout = 300)
-    spawn gcc -c -g -o [...]/gdb/testsuite/gdb.base/wchar0.o ../../../master/gdb/testsuite/gdb.base/wchar.c
-    Executing on host: gcc [...]/gdb/testsuite/gdb.base/wchar0.o  -g  -lm   -o [...]/gdb/testsuite/gdb.base/wchar    (timeout = 300)
-    spawn gcc [...]/gdb/testsuite/gdb.base/wchar0.o -g -lm -o [...]/gdb/testsuite/gdb.base/wchar
-    get_compiler_info: gcc-4-6-1
-    spawn [...]/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory [...]/gdb/testsuite/../data-directory
-    ERROR: (timeout) GDB never initialized after 10 seconds.
-    ERROR: no fileid for coulomb
-    ERROR: no fileid for coulomb
-    ERROR: no fileid for coulomb
-    ERROR: couldn't load [...]/gdb/testsuite/gdb.base/wchar into [...]/gdb/testsuite/../../gdb/gdb (timed out).
-    ERROR: no fileid for coulomb
-    ERROR: Delete all breakpoints in delete_breakpoints (timeout)
-    ERROR: no fileid for coulomb
-    UNRESOLVED: gdb.base/wchar.exp: setting breakpoint at wchar.c:34 (timeout)
-    testcase ../../../master/gdb/testsuite/gdb.base/wchar.exp completed in 797 seconds
-    [...]
-
-
-# IRC, freenode, #hurd, 2012-08-09
-
-In context of the [[select]] issue.
-
-    <braunr> i wonder where the tty allocation is made
-    <braunr> it could simply be that current applications don't handle old BSD
-      ptys correctly
-    <braunr> hm no, allocation is fine
-    <braunr> does someone know why there is no term instance for /dev/ttypX ?
-    <braunr> showtrans says "/hurd/term /dev/ttyp0 pty-slave /dev/ptyp0" though
-    <youpi> braunr: /dev/ttypX share the same translator with /dev/ptypX
-    <braunr> youpi: but how ?
-    <youpi> see the main function of term
-    <youpi> it attaches itself to the other node
-    <youpi> with file_set_translator
-    <youpi> just  like pfinet can attach itself to /servers/socket/26 too
-    <braunr> youpi: isn't there a possible race when the same translator tries
-      to sets itself on several nodes ?
-    <youpi> I don't know
-    <tschwinge> There is.
-    <braunr> i guess it would just faikl
-    <braunr> fail
-    <tschwinge> I remember some discussion about this, possibly in context of
-      the IPv6 project.
-    <braunr> gdb shows weird traces in term
-    <braunr> i got this earlier today: http://www.sceen.net/~rbraun/gdb.txt
-    <braunr> 0x805e008 is the ptyctl, the trivs control for the pty
-    <tschwinge> braunr: How do you mean »weird«?
-    <braunr> tschwinge: some peropen (po) are never destroyed
-    <tschwinge> Well, can't they possibly still be open?
-    <braunr> they shouldn't
-    <braunr> that's why term doesn't close cleany, why select still reports
-      readiness, and why screen loops on it
-    <braunr> (and why each ssh session uses a different pty)
-    <tschwinge> ... but only on darnassus, I think?  (I think I haven't seen
-      this anywhere else.)
-    <braunr> really ?
-    <braunr> i had it on my virtual machines too
-    <tschwinge> But perhaps I've always been rebooting systems quickly enough
-      to not notice.
-    <tschwinge> OK, I'll have a look next time I boot mine.
-    <braunr> i suppose it's why you can't login anymore quickly when syslog is
-      running
-
-[[syslog]]?
-
-    <braunr> i've traced the problem to ptyio.c, where pty_open_hook returns
-      EBUSY because ptyopen is still true
-    <braunr> ptyopen remains true because pty_po_create_hook doesn't get called
-    <youpi> tschwinge: I've seen the pty issue on exodar too, and on my qemu
-      image too
-    <braunr> err, pty_po_destroy_hook
-    <tschwinge> OK.
-    <braunr> and pty_po_destroy_hook doesn't get called from users.c because
-      po->cntl != ptyctl
-    <braunr> which means, somehow, the pty never gets closed
-    <youpi> oddly enough it seems to happen on all qemu systems I have, and no
-      xen system I have
-    <braunr> Oo
-    <braunr> are they all (xen and qemu) up to date ?
-    <braunr> (so we can remove versions as a factor)
-    <tschwinge> Aha.  I only hve Xen and real hardware.
-    <youpi> braunr: no
-    <braunr> youpi: do you know any obscur site about ptys ? :)
-    <youpi> no
-    <youpi> well, actually yes
-    <youpi> http://dept-info.labri.fr/~thibault/a (in french)
-    <braunr> :D
-    <braunr> http://www.linusakesson.net/programming/tty/index.php looks
-      interesting
-    <youpi> indeed
-
-
-## IRC, freenode, #hurdfr, 2012-08-09
-
-    <braunr> youpi: ce que j'ai le plus de mal à comprendre, c'est ce qu'est un
-      "controlling tty"
-    <youpi> c'est le plus obscur d'obscur :)
-    <braunr> s'il est exclusif à une appli, comment ça doit se comporter sur un
-      fork, etc..
-    <youpi> de manière simple, c'est ce qui permet de faire ^C
-    <braunr> eh oui, et c'est sûrement là que ça explose
-    <youpi> c'est pas exclusif, c'est hérité
-    <braunr>
-      http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/bernstein-on-ttys/cttys.html
-
-
-## IRC, freenode, #hurd, 2012-08-10
-
-    <braunr> youpi: and just to be sure about the test procedure, i log on a
-      system, type tty, see e.g. ttyp0, log out, and in again, then tty returns
-      ttyp1, etc..
-    <youpi> yes
-    <braunr> youpi: and an open (e.g. cat) on /dev/ptyp0 returns EBUSY
-    <youpi> indeed
-    <braunr> so on xen it doesn't
-    <braunr> grmbl
-    <youpi> I've never seen it, more precisely
-    <braunr> i also have the problem with a non-accelerated qemu
-    <braunr> antrik: do you have the term problems we've seen on your bare
-      hardware ?
-    <antrik> I'm not sure what problem you are seeing exactly :-)
-    <braunr> antrik: when logging through ssh, tty first returns ttyp0, and the
-      second time (after logging out from the first session) ttyp1
-    <braunr> antrik: and term servers that have been used are then stuck in a
-      busy state
-    <antrik> braunr: my ptys seem to be reused just fine
-    <braunr> or perhaps they didn't have the bug
-    <braunr> antrik: that's so weird
-    <antrik> (I do *sometimes* get hanging ptys, but that's a different issue
-      -- these are *not* busy; they just hang when reused...)
-    <braunr> antrik: yes i saw that too
-    <antrik> braunr: note though that my hurd package is many months old...
-    <antrik> (in fact everything on this system)
-    <braunr> antrik: i didn't see anything relevant about the term server in
-      years
-    <braunr> antrik: what shell do you use ?
-    <antrik> yeah, but such errors could be caused by all kinds of changes in
-      other parts of the Hurd, glibc, whatever...
-    <antrik> bash
-
-
-## IRC, freenode, #hurd, 2012-12-27
-
-    <youpi> we however have a similar symptom with screen
-    <youpi> shells don't terminate
-    <braunr> yes
-    <youpi> or at least the window doesn't close
-    <braunr> the screen problem is the same as the term servers not being properly closed
-    <youpi> k
-    <braunr> that one is still on my todo list
-    <braunr> and not easy
-    <youpi> like so many small items on the TODO lists :)
-    <braunr> that one is an important one :)
-    <braunr> because we're still using legacy pty, the number of terms is
-      limited
-    <braunr> which means at some point we can't log in any more using them
-    <braunr> (i regularly kill pty terms on darnassus to avoid that)
-    <braunr> it prevents screen and rsyslogd iirc from working correctly, which
-      is very annoying
-    <braunr> there may be other issues
-
-
-# Formal Verification
-
-This issue may be a simple programming error, or it may be more complicated.
-
-Methods of [[formal_verification]] should be applied to confirm that there is
-no error in `/hurd/term`'s logic itself.  There are tools for formal
-verification/[[code_analysis]] that can likely help here.
-
-There is a [[!FF_project 277]][[!tag bounty]] on this task.
diff --git a/open_issues/term_blocking/2011-07-04.mdwn b/open_issues/term_blocking/2011-07-04.mdwn
deleted file mode 100644
index 0f302409..00000000
--- a/open_issues/term_blocking/2011-07-04.mdwn
+++ /dev/null
@@ -1,246 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-GDB testsuite makes a term process go bonkers.  The testsuite is terminated.
-The term process remanins.  Next, a new shell (bash) is started that connects
-to this term process -- and hangs.
-
-Hung bash process (27834), term (22634).
-
-    # portinfo -t 22634 27834
-         5 =>     58: receive
-        11 =>     18: receive
-        21 =>     53: receive
-        26 =>     51: receive
-        27 =>     56: receive
-        28 =>     48: receive
-        30 =>     54: receive
-
-GDB on bash:
-
-    #0  0x010ab12c in _hurd_intr_rpc_msg_in_trap (msg=0x102383c, option=3, send_size=44, rcv_size=2092, rcv_name=9, timeout=0, notify=0) at intr-msg.c:134
-            err = <value optimized out>
-            err = <value optimized out>
-            user_option = 3
-            user_timeout = 0
-            m = 0x102383c
-            msgh_bits = 5395
-            remote_port = 27
-            msgid = 21001
-            __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg"
-    #1  0x01235195 in __io_read (io_object=27, data=0x1024148, dataCnt=0x102414c, offset=-1, amount=1) at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/hurd/RPC_io_read.c:138
-            Mess = {In = {Head = {msgh_bits = 5395, msgh_size = 1768, msgh_remote_port = 27, msgh_local_port = 9, msgh_seqno = 0, msgh_id = 21001}, offsetType = {msgt_name = 11, msgt_size = 64, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, 
-                  msgt_unused = 0}, offset = -1, amountType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, amount = 1}, Out = {Head = {msgh_bits = 5395, msgh_size = 1768, msgh_remote_port = 27, 
-                  msgh_local_port = 9, msgh_seqno = 0, msgh_id = 21001}, RetCodeType = {msgt_name = 11, msgt_size = 64, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, RetCode = -1, dataType = {msgtl_header = {msgt_name = 255, 
-                    msgt_size = 255, msgt_number = 4095, msgt_inline = 1, msgt_longform = 1, msgt_deallocate = 1, msgt_unused = 1}, msgtl_name = 8194, msgtl_size = 4097, msgtl_number = 1}, 
-                data = "# /etc/inputrc - global inputrc for libreadline\n# See readline(3readline) and `info rluserman' for more information.\n\n# Be 8 bit clean.\nset input-meta on\nset output-meta on\n\n# To allow the use of 8bit"...}}
-            msg_result = <value optimized out>
-            msgh_size = <value optimized out>
-    #2  0x010afbb1 in readfd (port=27) at fd-read.c:34
-            nbytes = 0x9
-            nread = 40
-            data = 0x44 <Address 0x44 out of bounds>
-            offset = 12884901897
-    #3  0x010b5de5 in _hurd_ctty_input (port=26, ctty=27, rpc=0x1024154) at ctty-input.c:36
-            err = 19156808
-    #4  0x010af53e in _hurd_fd_read (fd=0x1244f48, buf=0x102420f, offset=-1) at fd-read.c:39
-            __ulink = {resource = {next = 0x0, prevp = 0x1244f4c}, thread = {next = 0x1024160, prevp = 0x1246c5c}, cleanup = 0x10b75a0 <_hurd_port_cleanup>, cleanup_data = 0x1a}
-            __ctty_ulink = {resource = {next = 0x0, prevp = 0x1244f5c}, thread = {next = 0x0, prevp = 0x1024180}, cleanup = 0x10b75a0 <_hurd_port_cleanup>, cleanup_data = 0x1b}
-            ctty = 27
-            crit = 0x1246808
-            __result = 16925048
-            port = <value optimized out>
-            err = <value optimized out>
-            data = 0x102420f ""
-            nbytes = 0x10241f8
-            nread = 1
-    #5  0x0116c080 in __libc_read (fd=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece or DW_OP_bit_piece.
-    ) at ../sysdeps/mach/hurd/read.c:27
-            descriptor = <error reading variable descriptor (DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece or DW_OP_bit_piece.)>
-            err = <value optimized out>
-    #6  0x080cdaac in ?? ()
-    No symbol table info available.
-    #7  0x080cdf88 in ?? ()
-    No symbol table info available.
-    #8  0x080baff7 in ?? ()
-    No symbol table info available.
-    #9  0x080bb435 in ?? ()
-    No symbol table info available.
-    #10 0x080507e7 in ?? ()
-    No symbol table info available.
-    #11 0x0804fc36 in ?? ()
-    No symbol table info available.
-    #12 0x08052f22 in ?? ()
-    No symbol table info available.
-    #13 0x08055dab in ?? ()
-    No symbol table info available.
-    #14 0x0804d960 in ?? ()
-    No symbol table info available.
-    #15 0x0804da1f in ?? ()
-    No symbol table info available.
-    #16 0x0804dc65 in ?? ()
-    No symbol table info available.
-    #17 0x0804d215 in ?? ()
-    No symbol table info available.
-    #18 0x010b906b in __libc_start_main (main=0x804c450, argc=1, ubp_av=0x1024dd4, init=0x80d7ff0, fini=0x80d7fe0, rtld_fini=0xf330, stack_end=0x1024dcc) at libc-start.c:257
-            result = <value optimized out>
-    #19 0x0804b281 in ?? ()
-    No symbol table info available.
-
-GDB on term:
-
-      5 Thread 22634.5  0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-      4 Thread 22634.4  0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-      3 Thread 22634.3  0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-      2 Thread 22634.2  0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    * 1 Thread 22634.1  0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    
-    Thread 5 (Thread 22634.5):
-    #0  0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0108a769 in __mach_msg (msg=0x129bf10, option=2050, send_size=0, rcv_size=8192, rcv_name=16, timeout=0, notify=0) at msg.c:110
-            ret = <value optimized out>
-    #2  0x0108ae24 in __mach_msg_server_timeout (demux=0x125fd1c, max_size=8192, rcv_name=16, option=2048, timeout=0) at msgserver.c:101
-            request = 0x129bf10
-            reply = 0x129df20
-            mr = <value optimized out>
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #3  0x01058e45 in thread_function (master=0) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libports/manage-multithread.c:136
-            timeout = 0
-            err = <value optimized out>
-            hook = 0
-            global_timeout = 0
-            thread_timeout = 0
-            bucket = 0x805e1f0
-            lock = 0
-            totalthreads = 4
-            nreqthreads = 3
-    #4  0x01052b91 in cthread_body (self=0x8061460) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cthreads.c:300
-            t = 0x80619a8
-    #5  0x00000000 in ?? ()
-    No symbol table info available.
-    
-    Thread 4 (Thread 22634.4):
-    #0  0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0108a769 in __mach_msg (msg=0x128df20, option=2050, send_size=0, rcv_size=8192, rcv_name=16, timeout=0, notify=0) at msg.c:110
-            ret = <value optimized out>
-    #2  0x0108ae24 in __mach_msg_server_timeout (demux=0x125fd1c, max_size=8192, rcv_name=16, option=2048, timeout=0) at msgserver.c:101
-            request = 0x128df20
-            reply = 0x128bf10
-            mr = <value optimized out>
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #3  0x01058e45 in thread_function (master=0) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libports/manage-multithread.c:136
-            timeout = 0
-            err = <value optimized out>
-            hook = 0
-            global_timeout = 0
-            thread_timeout = 0
-            bucket = 0x805e1f0
-            lock = 0
-            totalthreads = 4
-            nreqthreads = 3
-    #4  0x01052b91 in cthread_body (self=0x805f800) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cthreads.c:300
-            t = 0x805f788
-    #5  0x00000000 in ?? ()
-    No symbol table info available.
-    
-    Thread 3 (Thread 22634.3):
-    #0  0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0108a769 in __mach_msg (msg=0x127df20, option=2050, send_size=0, rcv_size=8192, rcv_name=16, timeout=0, notify=0) at msg.c:110
-            ret = <value optimized out>
-    #2  0x0108ae24 in __mach_msg_server_timeout (demux=0x125fd1c, max_size=8192, rcv_name=16, option=2048, timeout=0) at msgserver.c:101
-            request = 0x127df20
-            reply = 0x127bf10
-            mr = <value optimized out>
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #3  0x01058e45 in thread_function (master=0) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libports/manage-multithread.c:136
-            timeout = 0
-            err = <value optimized out>
-            hook = 0
-            global_timeout = 0
-            thread_timeout = 0
-            bucket = 0x805e1f0
-            lock = 0
-            totalthreads = 4
-            nreqthreads = 3
-    #4  0x01052b91 in cthread_body (self=0x805ec30) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cthreads.c:300
-            t = 0x805ebb8
-    #5  0x00000000 in ?? ()
-    No symbol table info available.
-    
-    Thread 2 (Thread 22634.2):
-    #0  0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0108a769 in __mach_msg (msg=0x126df20, option=3, send_size=32, rcv_size=4096, rcv_name=12, timeout=0, notify=0) at msg.c:110
-            ret = <value optimized out>
-    #2  0x0108ae99 in __mach_msg_server_timeout (demux=0x109b9d0 <msgport_server>, max_size=4096, rcv_name=12, option=0, timeout=0) at msgserver.c:151
-            request = 0x126ef30
-            reply = 0x126df20
-            mr = <value optimized out>
-            __PRETTY_FUNCTION__ = "__mach_msg_server_timeout"
-    #3  0x0108af6b in __mach_msg_server (demux=0x109b9d0 <msgport_server>, max_size=4096, rcv_name=12) at msgserver.c:196
-    No locals.
-    #4  0x0109b99f in _hurd_msgport_receive () at msgportdemux.c:68
-    No locals.
-    #5  0x01052b91 in cthread_body (self=0x805da48) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cthreads.c:300
-            t = 0x805d9d0
-    #6  0x00000000 in ?? ()
-    No symbol table info available.
-    
-    Thread 1 (Thread 22634.1):
-    #0  0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
-    No locals.
-    #1  0x0108a769 in __mach_msg (msg=0x125ba2c, option=2, send_size=0, rcv_size=24, rcv_name=10, timeout=0, notify=0) at msg.c:110
-            ret = <value optimized out>
-    #2  0x010516b8 in cproc_block () at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cprocs.c:638
-            msg = {msgh_bits = 17345214, msgh_size = 18972660, msgh_remote_port = 17163428, msgh_local_port = 134764952, msgh_seqno = 19249824, msgh_id = 18935134}
-            waiter = 0x1240808
-            new = <value optimized out>
-            p = 0x805d988
-    #3  0x01053589 in hurd_condition_wait (m=0x805d89c) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cancel-cond.c:86
-            p = 0x805d988
-            cancel = <value optimized out>
-            __PRETTY_FUNCTION__ = "hurd_condition_wait"
-            c = 0x805e498
-    #4  0x08052abf in trivfs_S_io_read (cred=0x8084b78, reply=32, replytype=18, data=0x125bb44, datalen=0x125bb40, offset=-1, amount=1) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./term/users.c:695
-            cancel = <value optimized out>
-            i = <value optimized out>
-            max = <value optimized out>
-            cp = <value optimized out>
-            avail = <value optimized out>
-    #5  0x0104053b in _Xio_read (InHeadP=0x125dc70, OutHeadP=0x125bc60) at ioServer.c:234
-            dataCnt = 2048
-            msgh_simple = <value optimized out>
-            io_object = 0x8084b78
-            dataP = 0x125bc8c "\350\003"
-    #6  _Xio_read (InHeadP=0x125dc70, OutHeadP=0x125bc60) at ioServer.c:148
-            In0P = 0x125dc70
-            OutP = 0x125bc60
-            offsetCheck = {msgt_name = 11, msgt_size = 64, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}
-            amountCheck = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}
-    #7  0x0104065e in trivfs_io_server (InHeadP=0x125dc70, OutHeadP=0x125bc60) at ioServer.c:2005
-            InP = 0x125dc70
-            OutP = 0x125bc60
-            routine = <value optimized out>
-    #8  0x01038f17 in trivfs_demuxer (inp=0x125dc70, outp=0x125bc60) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libtrivfs/demuxer.c:32
-    No locals.
-    #9  0x080537a8 in demuxer (inp=0x125dc70, outp=0x125bc60) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./term/main.c:68
-    No locals.
-    #10 0x01059045 in internal_demuxer (inp=0x125dc70, outheadp=0x125bc60) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libports/manage-multithread.c:101
-            err = <value optimized out>
-            spawn = <value optimized out>
-            status = <value optimized out>
-            pi = <value optimized out>
-            link = {thread = 3, next = 0x0, prevp = 0x8084b94, notifies = 0x0, interrupted_next = 0x0}
-            outp = 0x125bc60
-            __PRETTY_FUNCTION__ = "internal_demuxer"
-    [System crashed.]
diff --git a/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn b/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn
deleted file mode 100644
index f40e0455..00000000
--- a/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn
+++ /dev/null
@@ -1,54 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2013 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]]."]]"""]]
-
-[[!meta title="ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion '! __spin_lock_locked (&ss->critical_section_lock)'"]]
-
-[[!tag open_issue_hurd]]
-
-[[!debbug 46859]], [[!debbug 195360]]
-
-IRC, unknown channel, unknown date:
-
-    <youpi> azeem, marcus: ext2fs.static: thread-cancel.c:55:
-      hurd_thread_cancel: Assertion '! __spin_lock_locked
-      (&ss->critical_section_lock)' failed
-    <youpi> I actually don't understand this assertion
-    <youpi> it's just before __spin_lock (&ss->critical_section_lock);
-    <youpi> why should one check that a lock is free before taking it ?
-    <youpi> just the same in hurdexec.c
-    <youpi> (no, ss is not our own sigstate, so it's not safe to assume no
-      other path can take it)
-    <youpi> there's another one in sysdeps/mach/hurd/spawni.c
-    <youpi> and jmp-unwind.c
-    <antrik> youpi: why do you think it's nonsense?... the fact that we take
-      the lock (so we can't be interrupted) doesn't mean we are willing to wait
-      for others to release the lock... maybe the code path should never be
-      reached while others have a lock, or something
-    <youpi> then it's useless to take the lock
-    <youpi> "we take the lock (so we can't be interrupted)": no, it's not _our_
-      lock here, it's the lock of the thread we want to cancel
-    <antrik> what exactly is cancelling a thread?... (sorry, I don't really
-      have experience with thread programming)
-    <youpi> ~= killing it
-    <antrik> well, we take the lock so nobody can mess with the thread while we
-      are cancelling it, no?...
-    <youpi> yes
-    <youpi> that is fine
-    <youpi> but checking that the lock is free before taking it doesn't make
-      sense
-    <youpi> why nobody should be able to take the lock ?
-    <youpi> and if nobody is, why do we take it ? (since nobody would be able
-      to take it)
-    <antrik> well, maybe after taking the lock, we do some action that might
-      result in others trying to take it...
-    <youpi> nope: look at the code :)
-    <youpi> or maybe the cancel_hook, but I really doubt it
-
-See discussion about *`critical_section_lock`* on [[glibc]].
diff --git a/open_issues/thread_numbering_of_ps_and_gdb.mdwn b/open_issues/thread_numbering_of_ps_and_gdb.mdwn
deleted file mode 100644
index 7058cfe2..00000000
--- a/open_issues/thread_numbering_of_ps_and_gdb.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-It appears to [[me|tschwinge]] that `ps -T` enumerates thread IDs starting with
-zero, and GDB starting with one.  This should be unified.
-
-Or instead of manually allocating numbers, some other handle should be used,
-that has a global meaning for the running GNU Mach kernel, or a process-wide
-meaning, for example a port number.
-
-[[!tag open_issue_hurd open_issue_gdb]]
-
-
-Also see [[GDB thread IDs]].
diff --git a/open_issues/threads_issues.mdwn b/open_issues/threads_issues.mdwn
deleted file mode 100644
index aec216e0..00000000
--- a/open_issues/threads_issues.mdwn
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-List of issues w.r.t. the Hurd's many-threads paradigm.
-
-[[!tag open_issue_hurd]]
-
-  * [[fsync]]
diff --git a/open_issues/ti-rpc_then_nfs.mdwn b/open_issues/ti-rpc_then_nfs.mdwn
deleted file mode 100644
index 46cc1c1c..00000000
--- a/open_issues/ti-rpc_then_nfs.mdwn
+++ /dev/null
@@ -1,132 +0,0 @@
-[[!meta copyright="Copyright © 2011, 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_hurd open_issue_porting]]
-
-TI-RPC replaces glibc's Sun RPC implementation, [[!message-id
-"4D0632C5.1040107@RedHat.com"]].
-
-It needs some work on our side, [[!message-id
-"20101214213212.GU1095@kepler.schwinge.homeip.net"]].
-
-Then, the Hurd's [[hurd/translator/nfs]] translator and [[hurd/nfsd]] can be
-re-enabled, [[!message-id "87hb2j7ha7.fsf@gnu.org"]].
-
-
-## IRC, freenode, #hurd, 2014-02-19
-
-    <pere> hi.  I'm trying to port libtirpc to get rcpbind on hurd, and am
-      unable to find IPV6_PORTRANGE and IPV6_PORTRANGE_LOW.  is this a known
-      problem with a known fix?
-    <braunr> what are they supposed to be ?
-    <pere> braunr: found them described in <URL:
-      http://www.daemon-systems.org/man/ip6.4.html >.
-    <braunr> "The IPV6_PORTRANGE socket option and the conflict resolution rule
-      are not defined in the RFCs and should be considered implementation
-      dependent
-    <braunr> "
-    <braunr> hm
-    <braunr> if we have that, they're very probably not accessible from outside
-      our network stack
-    <pere> needed feature on hurd, in other words...
-    <braunr> why ?
-    <pere> If I remember correctly, SO_PEERCRED is also missing?
-    <braunr> yes ..
-    <braunr> that one is important
-    <pere> braunr: you wonder why the IPV6_PORTRANGE socket option was created?
-    <braunr> i wonder why it's needed
-    <braunr> does linux have it ?
-    <pere> yes, linux got it.
-    <braunr> same name ?
-    <pere> it make it possible for some services to work with some
-      firewalls. :)
-    <pere> yes, same name, as far I can tell.
-    <braunr> they could merely bind ports explicitely, couldn't they ?
-    <pere> not always.
-    <braunr> or is it for servers on creation of a client socket ?
-    <pere> see <URL:
-      http://www.stacken.kth.se/lists/heimdal-discuss/2000-11/msg00002.html >
-      for an example I came across.
-    <braunr> i don't find these macros on linux :/
-    <pere> how strange.  libtirpc build on linux.
-    <braunr> is there a gitweb or so somewhere ?
-    <braunr> i can't find it on sf :/
-    <pere> for <URL: http://sourceforge.net/projects/libtirpc >, you mean?
-    <braunr> yes
-    <pere> no idea.
-    <braunr> are you looking at upstream 0.2.4 or a particular debian package ?
-    <pere> I'm looking at the debian package.
-    <braunr> let me take a look
-    <pere> http://paste.debian.net/82971/ is my first draft patch to get the
-      source building.
-    <braunr> ok so
-    <braunr> in src/bindresvport.c
-    <braunr> if you look carefully, you'll see that these _PORTRANGE macros are
-      used in non linux code
-    <braunr> not very portable but it explains why you hit the problem
-    <braunr> try using #if defined (__linux__) || defined(__GNU__)
-    <braunr> also, i think we intend to implement SCM_CREDS, not SO_PEERCRED
-    <braunr> but consider we have neither for now
-    <pere> ah, definitely a simpler fix.
-    <braunr> pere: btw, see
-      https://lists.debian.org/debian-hurd/2010/12/msg00014.html
-
-    <pere> <URL: https://bugs.debian.org/739557 > with patch reporte.d
-
-
-## IRC, freenode, #hurd, 2014-02-20
-
-    <pere> new libtirpc with hurd fixes just uploaded to debian.  should fix
-      the rpcbind build too.
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-20
-
-    <pere> hm, rpcbind built with freshly patched libtirpc fail to work on
-      hurd.  no idea why.
-    <pere> running 'rpcinfo -p' show 'rpcinfo: can't contact portmapper: RPC:
-      Success'
-    <teythoon> o_O
-    <pere> I have no idea how to debug it. :(
-    <pere> anyway, I've found that rpcinfo is the broken part.  rpcbind work,
-      when I test it from a remote machine.
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-21
-
-    <pere> failing rpcinfo -p on hurd reported as <URL:
-      http://bugs.debian.org/739674 >.  Anyone got a clue how to debug it?
-
-
-## IRC, OFTC, #debian-hurd, 2014-03-03
-
-    <pere> I was just tipped by sesse that the hurd fix for libtirpc probably
-      caused RC bug in nfs-common, <URL: https://bugs.debian.org/740491 >.
-      Have not had time to check it out more closely.
-
-
-## IRC, OFTC, #debian-hurd, 2014-03-04
-
-    <youpi> pere: I don't really see how debian/patches/05-hurd-port.diff could
-      break Linux' libtirpc
-    <youpi> AIUI, the patch has zero effect on non-hurd builds
-    <youpi> oh wait
-    <youpi> it's simply missing a reautoconf to get HAVE_SYS_USER_H undefined
-      in config.h.in
-    <pere> youpi: I am quite sure I did add the required dh_autoreconf call.
-      did you see a build log where it was missing?
-    <youpi> pere: ah, ok. Then 02-rerun-bootstrap.diff can be dropped
-    <youpi> and I don't have any further idea
-    <youpi> pere: maybe it's the autoreconf itself which broke something?
-    <pere> could be.  not quite sure how to find out.
-    <gnu_srs> pere: what about running autoreconf on the previous (working
-      version)?
-    <pere> gnu_srs: sound like a good idea.  perhaps a good idea to just
-      disable the two patches as a start.
diff --git a/open_issues/time.mdwn b/open_issues/time.mdwn
deleted file mode 100644
index d9f1fa1d..00000000
--- a/open_issues/time.mdwn
+++ /dev/null
@@ -1,853 +0,0 @@
-[[!meta copyright="Copyright © 2009, 2011, 2013 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_porting]]
-
-[[!toc]]
-
-
-# `time`
-
-Neither the `time` executable from the GNU time package work completely
-correctly, nor does the GNU Bash built-in one.
-
-    tschwinge@flubber:~ $ \time sleep 2
-    0.00user 0.00system 9:38:00elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
-    0inputs+0outputs (0major+0minor)pagefaults 0swaps
-    tschwinge@flubber:~ $ \time sleep 4
-    0.00user 0.00system 18:50:25elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
-    0inputs+0outputs (0major+0minor)pagefaults 0swaps
-    tschwinge@flubber:~ $ \time sleep 6
-    0.00user 0.00system 28:00:53elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
-    0inputs+0outputs (0major+0minor)pagefaults 0swaps
-    tschwinge@flubber:~ $ time sleep 2
-    
-    real    0m2.093s
-    user    0m0.000s
-    sys     0m0.011s
-    tschwinge@flubber:~ $ time sleep 4
-    
-    real    0m4.083s
-    user    0m0.000s
-    sys     0m0.010s
-    tschwinge@flubber:~ $ time sleep 6
-    
-    real    0m6.164s
-    user    0m0.000s
-    sys     0m0.010s
-
-GNU time's *elapsed* value is off by some factor.
-
-    $ \time factor 1111111111111111111
-    1111111111111111111: 1111111111111111111
-    0.00user 0.00system 52:39:24elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k
-    0inputs+0outputs (0major+0minor)pagefaults 0swaps
-    $ time factor 1111111111111111111
-    1111111111111111111: 1111111111111111111
-    
-    real    0m11.424s
-    user    0m0.000s
-    sys     0m0.010s
-
-As above; also here all the running time should be attributed to *user* time.
-This is probably a [[!taglink open_issue_gnumach]].
-
-
-## 2011-09-02
-
-Might want to revisit this, and take Xen [[!tag open_issue_xen]] into account
--- I believe flubber has already been Xenified at that time.
-
-
-### IRC, freenode, #hurd, 2011-09-02
-
-While testing some [[performance/IPC_virtual_copy]] performance issues:
-
-    <tschwinge> And I can confirm that with dd if=/dev/zero of=/dev/null bs=4k
-      running, a parallel sleep 10 takes about 20 s (on strauss).
-
-## 2013-03-30/31
-
-Investigating time's `configure`, a difference of the output between Linux and
-Hurd shows:
-
-    -checking for wait3 that fills in rusage... yes
-    +checking for wait3 that fills in rusage... no
-
-This causes a different code path in `resuse.c` to be used; such code path does
-not get a define for `HZ`, which is then defined with a fallback value of 60.
-
-[[!debbug 704283]] has been filed with a fix for this no-wait3 case.
-
-
-# `times`
-
-## guile
-
-### IRC, freenode, #hurd, 2013-08-21
-
-    <nalaginrut> does guile2 on hurd fixed? times issue
-    <teythoon> nalaginrut: does not look good
-    <teythoon> scheme@(guile-user)> (times)
-    <teythoon> $1 = #(0 0 0 0 0)
-    <nalaginrut> well, seems not a fixed version, if there's fixed version
-    <nalaginrut> since it's not Guile's bug, I can do nothing for it
-    <teythoon> ah
-    <nalaginrut> in spite of this, Guile2 works I think
-    <nalaginrut> all tests passed but 2 fail
-    <nalaginrut> one of the failure is version shows "UNKNOWN" which is
-      trivials
-    <teythoon> well, did you try to fix the times issue in Hurd?
-    <nalaginrut> I didn't , I have to get more familiar with hurd first
-    <nalaginrut> I'm playing hurd these days
-    <teythoon> :)
-    <nalaginrut> anyway, I think times issue is beyond my ability at present
-    <nalaginrut> ;-P
-    <teythoon> times is implemented in the glibc, in sysdeps/mach/hurd/times.c
-    <teythoon> don't say that before you had a look
-    <nalaginrut> yes, you're right
-    <nalaginrut> but I think times has something to do with the kernel time
-      mechanism, dunno if it's related to the issue
-    <nalaginrut> how did you get the times.c under hurd?
-    <nalaginrut> apt-get source glibc?
-    <teythoon> well, I'd clone git://sourceware.org/git/glibc.git
-    <teythoon> and yes, the kernel is involved
-    <teythoon> task_info is used to obtain the actual values
-    <teythoon>
-      http://www.gnu.org/software/hurd/gnumach-doc/Task-Information.html
-    <teythoon> I'd guess that something fails, but the times(2) interface is
-      not able to communicate the exact failure
-    <nalaginrut> maybe it's not proper to get src from upstream git? since it's
-      OK under Linux which uses it too
-    <nalaginrut> but apt-get source glibc has nothing
-    <teythoon> so I would copy the times(2) implementation from the libc so
-      that you can modify it and run it as a standalone program
-    <teythoon> well, the libc has system dependent stuff, times(2) on Linux is
-      different from the Hurd version
-    <teythoon> it has to be
-    <nalaginrut> alright, I got what you mean ;-)
-    <teythoon> and the debian libc is built from the eglibc sources, so the
-      source package is called eglibc iirc
-    <nalaginrut> ah~I'll try
-    <teythoon> have you tried to rpctrace your times test program? the small c
-      snippet you posted the other day?
-    <nalaginrut> I haven't build all the tools & debug environment on my hurd
-      ;-(
-    <teythoon> what tools?
-    <nalaginrut> well, I don't even have git on it, and I'm installing but
-      speed is slow, I'm looking for a new mirror
-    <teythoon> ah well, no need to do all this on the Hurd directly
-    <teythoon> building the libc takes like ages anyway
-    <nalaginrut> oops ;-)
-    <nalaginrut> I'll take your advice to concentrate on times.c only
-    <teythoon> oh well, it might be difficult after all, not sure though
-    <teythoon> times sends two task_info messages, once with TASK_BASIC_INFO,
-      once with TASK_THREAD_TIMES_INFO
-    <teythoon> here is the relevant rpctrace of your test program:
-    <teythoon> task131(pid14726)->task_info (1 10) = 0 {0 25 153427968 643072 0
-      0 0 0 1377065590 570000}
-    <teythoon> task131(pid14726)->task_info (3 4) = 0 {0 0 0 10000}
-    <teythoon> ok, I don't know enough about that to be honest, but
-      TASK_THREAD_TIMES_INFO behaves funny
-    <teythoon> I put a sleep(1) into your test program, and if I rpctrace it,
-      it behaves differently o_O
-    * nalaginrut is reading task-information page to get what it could be
-    <nalaginrut> maybe I have to do the same steps under Linux to find some
-      clue
-    <teythoon> no, this is Mach specific, there is no such thing on Linux
-    <teythoon> on Linux, times(2) is a system call
-    <teythoon> on Hurd, times is a function implemented in the libc that
-      behaves roughly the same way
-    <nalaginrut> OK~so different
-    <teythoon> look at struct task_basic_info and struct task_thread_times_info
-      in the task-information page for the meaning of the values in the
-      rpctrace
-    <teythoon> yes, very
-    <braunr> nalaginrut: you may want to try a patch i did but which is still
-      waiting to be merged in glibc
-    <nalaginrut> braunr:  ah~thanks for did it ;-)
-    <nalaginrut> can I have the link?
-    <braunr> i'm getting it
-    <braunr> teythoon: funny things happen with rpctrace, that's expected
-    <braunr> keep in mind rpctrace doesn't behave like ptrace at all
-    <braunr> it acts as a proxy
-    <braunr> nalaginrut:
-      http://git.savannah.gnu.org/cgit/hurd/glibc.git/commit/?h=rbraun/getclktck_100_hz&id=90404d6d1aa01f6ce1557841f5a675bb6a30f508
-    <braunr> nalaginrut: you need to add it to the debian eglibc patch list,
-      rebuild the packages, and install the resulting .debs
-    <braunr> if you have trouble doing it, i'll make packages when i have time
-    <nalaginrut> braunr:  I think your test result is expected? ;-)
-    <braunr> what test result ?
-    <nalaginrut> times test under that patch
-    <braunr> yes
-    <braunr> but i have no idea if it will work
-    <braunr> my patch fixes a mismatch between glibc and the procfs server
-    <braunr> nothing more
-    <braunr> it may help, it may not, that's what i'd like to know
-    <nalaginrut> hah~thanks for that
-    <nalaginrut> I get source from apt-get, then manually modified the files,
-      no much code ;-)
-    <nalaginrut> compiling
-    <nalaginrut> there is no cpuinfo in /proc?
-    <teythoon> no
-    <nalaginrut> a feature need to be done? or there's another way for that?
-    <teythoon> well, it hasn't been implemented
-    <teythoon> do you need that? what for?
-    <nalaginrut> compiling error, I realized I should use gcc-4.7
-    <pinotree> how are you building?
-    <nalaginrut> I just happened to play proc while compiling, and found
-      there's no
-    <nalaginrut> cxa_finalize.c:48:1: error: ‘tcbhead_t’ has no member
-      named ‘multiple_threads’
-    <nalaginrut> I changed to gcc-4.7
-    <pinotree> just edit the sources, and then dpkg-buildpackage -nc -us -uc
-    <pinotree> that will rebuild the debian package as it would be in a debian
-      build, making sure all the build dependencies are there, etc
-    <pinotree> doing it different than that is just wrong™
-    <nalaginrut> ok, doing
-    <pinotree> were you really doing ./configure etc yourself?
-    <nalaginrut> well, I can't wait till it's done, I'll let it compile and
-      check it out tomorrow
-    <nalaginrut> I used configure, yes ;-P
-    <pinotree> not good
-    <nalaginrut> I have to go, thanks for help guys
-
-
-### IRC, freenode, #hurd, 2013-08-22
-
-    < nalaginrut> eglibc was done by dpkg-buildpackage, then how to install it?
-      (sorry I'm a brand new debian users)
-    < nalaginrut> oh~I found it
-    < nalaginrut> yes, (times) returns reasonable result ;-)
-     * nalaginrut is trying 'make check'
-    < nalaginrut> unfortunately, it can't pass the test though, I'm researching
-      it, anyway, we made first step
-    < nalaginrut> for Hurd internal-time-units-per-second will be 1000
-    < nalaginrut> , but the elapsed time is far larger than (* 2
-      internal-time-units-per-second)
-    < nalaginrut> I think the different of two returned clocks after 1 second
-      should be the TIME_UNITS_PER_SECOND, in principle
-    < nalaginrut> but I'm not sure if it's elibc or Guile bug
-    < nalaginrut> dunno, maybe clock tick should be 1000?
-    < nalaginrut> well, I'll try clock per second as 1000
-    < braunr> nalaginrut: clock tick (or actually, the obsolete notion of a
-      clock tick in userspace) should be 100
-    < braunr> nalaginrut: how did you come with 1000 ?
-    < nalaginrut> braunr:  Guile set TIME_UNITS_PER_SECOND to 1000 when there's
-      no 8bytes size and doesn't define HAVE_CLOCK_GETTIME
-    < nalaginrut> #if SCM_SIZEOF_LONG >= 8 && defined HAVE_CLOCK_GETTIME
-    < nalaginrut> #define TIME_UNITS_PER_SECOND 1000000000
-    < nalaginrut> #else
-    < nalaginrut> #define TIME_UNITS_PER_SECOND 1000
-    < nalaginrut> #endif
-    < nalaginrut> and the test for 'times' used time-units-per-second
-    < pinotree> what has sizeof(long) have to do with time units per second?
-    < nalaginrut> dunno, maybe the representation of time?
-    < nalaginrut> the test failed since the difference between two clocks after
-      1sec is too large
-    < nalaginrut> and for the test context, it should small than 2 times of
-      units-per-second
-    < nalaginrut> should be smaller 
-    < nalaginrut> sorry for bad English
-    < pinotree> aren't you basically looking for clock_getres?
-    < nalaginrut> pinotree:  I don't understand what you mean
-    < pinotree>
-      http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_getres.html
-    < nalaginrut> I wonder if there's a standard CLK_PER_SEC for Hurd
-    < nalaginrut> or it can be modified as wish
-    < pinotree> why do you need it?
-    < nalaginrut> the difference is 10,000,000, which can never less than
-      2*clock_per_second
-    < nalaginrut> pinotree:  I don't need it, but I want to know if there's a
-      standard value
-    < braunr> nalaginrut: ok so, this is entirely a guile thing
-    < braunr> nalaginrut: did you test with my patch ?
-    < nalaginrut> braunr:  yes, 'times' works fine
-    < braunr> but even with that, a tets fails ?
-    < braunr> test*
-    < nalaginrut> well, I can't say works fine, the proper description is "now
-      it has reasonable result"
-    < braunr> youpi: could you bring
-      http://darnassus.sceen.net/gitweb/savannah_mirror/glibc.git/commit/90404d6d1aa01f6ce1557841f5a675bb6a30f508
-      into debian glibc btw ?
-    < nalaginrut> braunr:  it failed the test since the clock run too fast, but
-      it should be smaller than 2*clk-per-sec
-    < braunr> i don't get that
-    < braunr> can you show the code that checks the condition ?
-    < nalaginrut> braunr:  http://pastebin.com/sG3QxnPt
-    < braunr> * 0.5 internal-time-units-per-second ?
-    < nalaginrut> for C users, it's just like
-      a=times(...);sleep(1);b=times(...); then time-units-per-sec/2 <= (b-a) <=
-      time-units-per-sec*2
-    < braunr> ah ok
-    < nalaginrut> the test passes when it's true
-    < braunr> so basically, it says sleep(1) sleeps for more than 2 seconds
-    < braunr> can you check the actual value ?
-    < braunr> b-a
-    < nalaginrut> hold on for minutes
-    < nalaginrut> it's 10,000,000
-    < nalaginrut> for clk-per-sec=1000,000,000, it's OK
-    < nalaginrut> but for 100 or 1000, it's too small
-    < braunr> let's forget 100
-    < braunr> guile uses 1000
-    < nalaginrut> OK
-    < braunr> but i still don't get why
-    < nalaginrut> so I asked if there's standard value, or it can be ajustified
-    < nalaginrut> adjusted
-    < braunr> ok so, times are expressed in clock ticks
-    < braunr> are you sure you're using a patched glibc ?
-    < nalaginrut> yes I used your patch, and the 'times' get reasonable result
-    < braunr> then
-    < braunr> 11:28 < nalaginrut> it's 10,000,000
-    < braunr> doesn't make sense
-    < nalaginrut> hmm
-    < braunr> anhd i don't understand the test
-    < braunr> what's tms:clock new ?
-    < nalaginrut> it's actually the return value of 'times'
-    < nalaginrut> Guile wrap the clock_t and tms to a vector, then we can get
-      all the thing in a row
-    < nalaginrut> 'new' is a variable which was gotten after 1 sec
-    < braunr> let's see what this does exactly
-    < nalaginrut> equal to "new = times(...)"
-    < nalaginrut> 'tms' equal to (clock_t (struct tms))
-    < nalaginrut> we have to pass in the struct pointer to get the struct
-      values filled, but for Guile we don't use pointer, times actually returns
-      two things: clock_t and struct tms
-    < nalaginrut> and Guile returns them as a vector in a row, that's it
-    < braunr> nalaginrut: test this please:
-      http://darnassus.sceen.net/~rbraun/test.c
-    < braunr> i don't have a patched libc here
-    < braunr> i'll build one right now
-    < nalaginrut> clock ticks: 1000000
-    < braunr> and this seems reasonable to you ?
-    < braunr> anyway, i think the guile test is bugged
-    < nalaginrut> no, the reasonable is not for this
-    < braunr> does it ever get the clock tick value from sysconf() ?
-    < nalaginrut> I say reasonable since it's always 0 both for clock and tms,
-      before apply your patch
-    < braunr> uh no
-    < braunr> i have the same value, without my patch
-    < nalaginrut> so I said "I can't say it works fine"
-    < braunr> either the test is wrong because it doesn't use sysconf()
-    < nalaginrut> anyway, I don't think times should return "all zero"
-    < braunr> or the clock values have already been ocnverted
-    < braunr> but it doesn't
-    < braunr> you did something wrong
-    < nalaginrut> with your patch it doesn't 
-    < braunr> without neither
-    < braunr> 11:43 < braunr> i have the same value, without my patch
-    < nalaginrut> well, it's too strange
-    < braunr> check how the test actually gets the clock values
-    < braunr> also, are your running in vbox ?
-    < braunr> you*
-    < nalaginrut> no ,it's physical machine
-    < braunr> oh
-    < braunr> nice
-    < braunr> note that vbox has timing issues
-    < nalaginrut> I thought I should give you some info of CPU, but there's no
-      /proc/cpuinfo
-    < braunr> shouldn't be needed
-    < nalaginrut> OK
-    < braunr> run my test again with an unpatched glibc
-    < braunr> just to make sure it produces the same result
-    < braunr> and
-    < nalaginrut> so the clock-per-sec is machine independent for Hurd I think
-    < braunr> 11:46 < braunr> check how the test actually gets the clock values
-    < nalaginrut> since it's implemented in userland
-    < braunr> clock-per-sec is always system dependent
-    < braunr>        All times reported are in clock ticks.
-    < braunr>        The number of clock ticks per second can be obtained
-      using:
-    < braunr>            sysconf(_SC_CLK_TCK);
-    < braunr> 11:46 < braunr> check how the test actually gets the clock values
-    < braunr> to see if they're converted before reaching the test code or not
-     * nalaginrut is building eglibc 
-    < braunr> building ?
-    < braunr> what for ?
-    < nalaginrut> I modified it to 1000, now it's useless
-    < braunr> we want it to 100 either way
-    < nalaginrut> and how to reinstall eglibc under debian?
-    < braunr> it's obsolete, procfs already uses 100, and 100 is low enough to
-      avoid overflows in practically all cases
-    < braunr> aptitude install libc0.3=<version>
-    < nalaginrut> OK
-    < braunr> aptitude show -v libc0.3
-    < braunr> for the list of available versions
-    < nalaginrut> out of topic, what's the meaning of the code in
-      quantize_timeval ?
-    < nalaginrut> tv->tv_usec = ((tv->tv_usec + (quantum - 1)) / quantum) *
-      quantum;
-    < nalaginrut> I can't understand this line
-    < braunr> scaling and rounding i guess
-    < nalaginrut> hmm...but quantum seems always set to 1?
-    < nalaginrut> 100/__getclktck()
-    < braunr> ah right
-    < braunr> old crap from the past
-    < nalaginrut> and clk-tck is 100
-    < braunr> the author probably anticipated clk_ticks could vary
-    < braunr> in practice it doesn't, and that's why it's been made obsolete
-    < nalaginrut> I wonder if it could be vary
-    < braunr> no
-    < nalaginrut> alright
-    < nalaginrut> why not just assign it to 1?
-    < braunr> 11:55 < braunr> old crap from the past
-    < braunr> the hurd is 20 years old
-    < braunr> like linux
-    < nalaginrut> oh~
-    < braunr> but with a lot less maintenance
-    < nalaginrut> braunr:  well, I tried the original eglibc, your test was
-      clock ticks: 1000000
-    < nalaginrut> but in Guile, (times) ==> (0 0 0 0 0)
-    < nalaginrut> the reasonable result maybe: #(4491527510000000 80000000 0 0
-      0)
-    < braunr> 11:46 < braunr> check how the test actually gets the clock values
-    < braunr> ah, he left
-
-
-### IRC, freenode, #hurd, 2013-08-23
-
-    < braunr> nalaginrut: times() doesn't seem to be affected by my patch at
-      all
-    < nalaginrut> braunr:  but it did in my machine
-    < nalaginrut> well, I think you mean it doesn't affect your C test code
-    < braunr> i'm almost sure something was wrong in your test
-    < braunr> keep using the official debian glibc package
-    < nalaginrut> I don't think it's test issue, since every time (times)
-      return zero, the test can never get correct result
-    < braunr> times doesn't return 0
-    < braunr> for sleep(1), i always have the right result, except in
-      microseconds
-    < nalaginrut> times in Guile always return #(0 0 0 0 0)
-    < braunr> (microseconds is the native mach time unit)
-    < braunr> well, guile does something wrong
-    < nalaginrut> after sleep 1, it's 0 again, so it's none sense
-    < braunr> 11:46 < braunr> check how the test actually gets the clock values
-    < braunr> not on my system
-    < nalaginrut> but (times) returns reasonable result after applied your
-      patch 
-    < braunr> that's not normal, since times isn't affected by my patch
-    < nalaginrut> oops
-    < braunr> you need to look for what happens in guile between the times()
-      call and the #(0 0 0 0 0) values
-    < nalaginrut> well, I tried many times between patch or non-patch, I think
-      there's no mistake
-    < nalaginrut> I read the 'times' code in Guile, there's nothing strange,
-      just call 'times' and put all the result to a vector
-    < braunr> which means there is no conversion
-    < braunr> in which case the test is plain wrong since there MUST also be a
-      call to sysconf()
-    < braunr> to obtain the right clock ticks value
-    < braunr> is your box reachable with ssh ?
-    < nalaginrut> oh~wait, seems there's a quotient operation, I'm checking
-    < nalaginrut> factor = scm_quotient (scm_from_long (TIME_UNITS_PER_SECOND),
-    < nalaginrut>                        scm_from_long (ticks_per_second));
-    < braunr> iirc, TIME_UNITS_PER_SECOND is hardcoded
-    < nalaginrut> unless factor is zero
-    < nalaginrut> yes, it's hardcoded
-    < braunr> that's completely non portable and wrong
-    < nalaginrut> you suggest to call sysconf?
-    < braunr> yes
-    < braunr> but i don't have the code in mind
-    < braunr> what is ticks_per_second ?
-    < nalaginrut> OK, that's one issue, we have to find why times return 0
-    < braunr> 14:14 < braunr> is your box reachable with ssh ?
-    < braunr> i'd like to make sure times returns 0 at your side
-    < braunr> because it doesn't at mine
-    < nalaginrut> no
-    < braunr> until i can reproduce, i can't consider there is a problem
-    < nalaginrut> I think it's unreachable for outer space
-    < nalaginrut> well, if you want to reproduce, just get guile src of debian
-    < braunr> guile 2.0 ?
-    < nalaginrut> yes, apt-get source guile-2.0
-    < nalaginrut> I'm checking ticks_per_second
-    < braunr> got the source, how do i test 
-    < braunr> ?
-    < nalaginrut> you have to build it, and run ./meta/guile, then you don't
-      have to install it
-    < nalaginrut> and try (times)
-    < braunr> aw libgc
-    < nalaginrut> the reasonable result should be #(4313401920000000 110000000
-      20000000 0 0) or something alike
-    < nalaginrut> but #(0 0 0 0 0) in each time is not reasonable apparently
-    < nalaginrut> maybe you need apt-get build-dep guile-2.0?
-    < braunr> already done
-    < nalaginrut> building Guile2 may take very long time
-    < nalaginrut> about 30 minutes in my old machine
-    < braunr> then it should take just a few minutes on mine
-    < nalaginrut> alright it's not very long, I've spent 8 hours for gcc in LFS
-    < braunr> 8 hours ?
-    < braunr> takes 5-10 minutes on a common machine ..
-    < nalaginrut> but it's Celeron566 at that time...
-    < braunr> ah, that old
-    < nalaginrut> include bootstrap, so very long
-    < braunr> nalaginrut: i got the test failure from the build procedure, how
-      do i run it manually ?
-    < nalaginrut> braunr:   ./meta/guile -L test-suite
-      test-suite/tests/time.test
-    < nalaginrut> braunr:  or make check for all
-    < braunr> put a print after the schedule() and before the return nil; in
-      runtime_mstart, since that's the body of new threads
-    < nlightnfotis> unfortunately, I can't confirm this with goroutines
-      running; the assertion failure aborts before I can get anything useful
-    < braunr> you can
-    < braunr> make sure there is a \n in the message, since stdout is line
-      buffered by default
-    < braunr> if you don't reach that code, it means threads don't exit
-    < braunr> at least goroutine threads
-    < braunr> btw, where is the main thread running ?
-    < nlightnfotis> I just checked there is a \n at the end.
-    < nlightnfotis> "<braunr> btw, where is the main thread running " could you
-      elaborate a little bit on this?
-    < braunr> what does main() after initializing the runtime ?
-    < braunr> +do
-    < nlightnfotis> the runtime main or the process's main?
-    < braunr> the process
-    < braunr> nlightnfotis: what we're interested in is knowing whether main()
-      exits or not
-    < nlightnfotis> braunr: I can see there are about 4 functions of interest:
-      runtime_main (the main goroutine, and I can imagine 1st thread)
-    < nlightnfotis> main_init (I don't know what it does, will check this out
-      now)
-    < nlightnfotis> main_main (not sure about this one either)
-    < nlightnfotis> and runtime_exit (0)
-    < braunr> i can see that too
-    < braunr> i'm asking about main()
-    < nlightnfotis> which seems to be the function that terminates the main
-      thread
-    < nlightnfotis> <braunr> nlightnfotis: what we're interested in is knowing
-      whether main() exits or not --> my theory is runtime_exit (0) exits the
-      process' main. Seeing as at various times go programs echo $? == 0.
-    < nlightnfotis> let me research that a little bit
-    < nlightnfotis> braunr: that will require a bit more studying. main_main()
-      and main_init() are both expanded to assembly tags if I understand it
-      correctly. 
-    < nlightnfotis> main.main and __go_init_main respectively.
-    < braunr> why are you looking from there instead of looking from main() ?
-    < nlightnfotis> are we not looking out if main exits?
-    < braunr> we are
-    < braunr> so why look at main_main ?
-    < braunr> or anything else than main ?
-    < nlightnfotis> these are called inside runtime_main and I figured out they
-      might have a clue
-    < braunr> runtime_main != main
-    < braunr> (except if there is aliasing)
-    < nlightnfotis> there is still the possibility that runtime_main is the
-      main function and that runtime_exit(0) exits it.
-    < braunr> there is no doubt that main is main
-    < braunr> (almost)
-    < nlightnfotis> and I just found out that there is no main in assembly
-      produced from go. Only main.main
-    < braunr> check the elf headers for the entry point then
-    < nlightnfotis> braunr: I went through the headers, and found the process'
-      main. You can find it in <gcc_root>/libgo/runtime/go-main.c
-    < nlightnfotis> it seems very strange though: It creates a new thread, then
-      aborts?
-    < braunr> nlightnfotis: see :)
-    < braunr> nlightnfotis: add traces there
-    < nlightnfotis> braunr: can you look into that piece of code to check out
-      something I don't understand?
-    < nlightnfotis> braunr: I can not seem able to find __go_go 's definition
-    < nlightnfotis> only a declaration in runtime.h
-    < braunr>
-      https://github.com/NlightNFotis/gcc/blob/master/libgo/runtime/proc.c,
-      line 1552
-    < nlightnfotis> gee thanx. For a strange kind of fashion, I was looking for
-      it in runtime.c
-    < braunr> use git grep
-    < braunr> or tags/cscope
-    < nlightnfotis> braunr: yep! runtime_exit does seem to terminate a go
-      process that was not otherwise abnormally terminated.
-    < braunr> ?
-    < braunr> is it called or not ?
-    < braunr> runtime_exit is a macro on exit()
-    < braunr> so we already know what it does
-    < nlightnfotis> it is called
-    < braunr> ok
-    < braunr> that's not normal :)
-    < nlightnfotis> for a simple program
-    < braunr> uh ?
-    < nlightnfotis> for one that has a go routine
-    < braunr> but
-    < nlightnfotis> it doesn't
-    < nlightnfotis> it's expected
-    < braunr> ok
-    < braunr> that makes sense
-    < braunr> well, trace
-    < braunr> keep tracing
-    < braunr> for example in main()
-    < braunr> is runtime_mstart() actually reached ?
-    < nlightnfotis> yeah main and runtime_main were my next two targets
-    < braunr> good
-    < nlightnfotis> and now I followed your advice and it does compiler much
-      faster
-    < braunr> so, it looks like the main thread just becomes a mere kernel
-      thread
-    < braunr> running runtime_mstart() and fetching goroutines as needed
-    < braunr> after your traces, i'd suggest running a small go test program,
-      with one simple goroutine (doesn't crash right ?)
-    < braunr> and trace context switching
-    < braunr> but after the traces
-    < braunr> one important trace is to understand why runtime_exit gets called
-    < nlightnfotis> it does crash even with 1 goroutine
-    < braunr> oh
-    < braunr> when doesn't it crash ?
-    < nlightnfotis> when it has 0 goroutines
-    < nlightnfotis> it works as expected
-    < nlightnfotis> but anything involving goroutines crashes
-    < nlightnfotis> and goroutines are very important; everything in the
-      standard library involves goroutines
-    < braunr> ok
-    < braunr> doesn't change what i suggested, good
-    < braunr> 1/ find out why runtime_exit gets called
-    < braunr> 2/ trace context switching with 1 goroutine
-    < nlightnfotis> on it.
-    < braunr> in all cases, make all your goroutines (including the main one)
-      *not* return
-    < braunr> so that you don't deal with goroutine destruction yet
-    < nlightnfotis> runtime_mstart in main doesn't to be run at all. So the
-      path is __go_go and then return from it.
-    < nlightnfotis> *doesn't seem
-
-
-### IRC, freenode, #hurd, 2013-08-26
-
-    < braunr> youpi: my glibc clock patch looks incomplete btw
-    < youpi> which one?
-    < youpi> ah, the ticks one?
-    < braunr> yes
-    < braunr> it doesn't change the values returned by times
-    < braunr> as a side effect, the load average bumps to 2+ on an idle machine
-
-
-### IRC, freenode, #hurd, 2013-08-27
-
-    < nalaginrut> braunr:  have you tried Guile2 on your machine? ;-)
-    < braunr> nalaginrut: no
-    < braunr> nalaginrut: but i saw the code actually does use sysconf()
-    < nalaginrut> braunr:  yes, for ticks_per_second
-    < braunr> i had to look myself to find it out, you didn't say it, despite
-      me asking multiple times
-    < braunr> it won't make debugging easier ;p
-    < braunr> nalaginrut: also, the return value of times is actually *never*
-      used
-    < braunr> i don't know why you've been talking about it so much
-    < nalaginrut> braunr:  I'm sorry, it's first time to look stime.c for me
-    < braunr> the interesting function is get_internal_run_time_times()
-    < nalaginrut> what do you mean about "the return value of times is actually
-      *never* used"? in which context?
-    < braunr> see get_internal_run_time_times
-    < braunr> struct tms time_buffer;
-    < braunr> times(&time_buffer);
-    < braunr> return ...
-    < braunr> and yes, the user and system time reported in struct tms are 0
-    < braunr> let's see what posix has to say about it
-    < pinotree> it says it will return (clock_t)-1 for errors, but no standard
-      errors are defined yet
-    < nalaginrut> but I don't think  get_internal_run_time_times has something
-      to do with scm_times
-    < braunr> well, i don't see any other call to times()
-    < braunr> i've asked you repeatedly to look for how guile fetches the data
-    < braunr> i think it's done in get_internal_run_time_times
-    < braunr> what makes you think otherwise ?
-    < braunr> our times() seems to behave fine, other than the units of the
-      return value
-    < nalaginrut> I don't understand what do you mean?
-      get_internal_run_time_times is unrelated to scm_times which is actually
-      "times" in Scheme code
-    < braunr> ok
-    < nalaginrut> I think we're talking about "times" activity, right?
-    < braunr> ok so result is a vector
-    < braunr> with the return value and the four values in struct tms
-    < nalaginrut> yes
-    < braunr> and what looks interesting is
-    < braunr> factor = scm_quotient (scm_from_long (TIME_UNITS_PER_SECOND),
-      scm_from_long (ticks_per_second));
-    < braunr> SCM_SIMPLE_VECTOR_SET (result, 0, scm_product (scm_from_long
-      (rv), factor));
-    < braunr> TIME_UNITS_PER_SECOND is 1000
-    < nalaginrut> yes, it means (clock_t *
-      (TIME_UNITS_PER_SECOND/ticks_per_second)), though I've no idea why it
-      does this
-    < braunr> normalizing values i guess
-    < nalaginrut> I wonder if the factor should be 1, just guessing
-    < braunr> let's see what our clock tick really is
-    < braunr> 1000000 on an unmodified libc
-    < braunr> 100 with my patch
-    < nalaginrut> so what's the problem?
-    < nalaginrut> all the values were multiplied by ticks, it's fair for the
-      subtraction
-    < nalaginrut> I think the problem is clock is too large for the difference
-      between utime and utime(sleep 1)
-    < nalaginrut> oops, is too small
-    < nalaginrut> sorry, I confused,
-    < nalaginrut> the problem is the difference of clock is too large for
-      2*internal-time-units-per-second
-    < nalaginrut> and actually, internal-time-units-per-second is
-      SCM_TIME_UNITS_PER_SECOND
-    < nalaginrut> but without your patch, 'times' would return zeros all the
-      time, which is never meet the condition: SCM_TIME_UNITS_PER_SECOND/2 <=
-      (clock2 - clock1)
-    < nalaginrut> well, maybe your point is
-      TIME_UNITS_PER_SECOND/ticks_per_second is too small without your patch,
-      which causes the scm_to_long cast give a 0 value
-    < nalaginrut> s/cast/casting
-    < nalaginrut> when ticks_per_second is 100, the factor would be 10, which
-      seems to be reasonable
-    < nalaginrut> s/scm_to_long/scm_from_long
-    < nalaginrut> well, I have to checkout this
-    < nalaginrut> OK, let me reconstruct the point: ticks_per_second so too
-      large that makes the factor becomes zero
-    < nalaginrut> but decrease ticks_per_second to 100 causes the clock become
-      too large than  TIME_UNITS_PER_SECOND
-    < braunr> 10:59 < nalaginrut> but without your patch, 'times' would return
-      zeros all the time, which is never meet the condition:
-      SCM_TIME_UNITS_PER_SECOND/2 <= (clock2 - clock1)
-    < braunr> until you prove me otherwise, this is plain wrong
-    < braunr> times() never returned me 0
-    < braunr> so let's see, this gives us a factor of 1000 / 1000000
-    < braunr> so the problem is factor being 0
-    < braunr> that's why *guile* times returns 0
-    < braunr> with my patch it should return 10
-    < nalaginrut> braunr:  I'm sorry I mean "stime" in Scheme returns zeros
-    < nalaginrut> yes, I think the problem is factor 
-    < nalaginrut> the factor
-    < braunr> now why doesn't my patch fix it all ?
-    < braunr> ah yes, rv is still in microseconds
-    < braunr> that's what i've been telling youpi recently, my patch is
-      incomplete
-    < braunr> i'll cook a quick fix, give me a few minutes please
-    < nalaginrut> but it fixed something ;-)
-    < braunr> well, guile makes a stupid assumption here
-    < braunr> so it's not really a fix
-    < nalaginrut> braunr:  should I ask some info about  TIME_UNITS_PER_SECOND
-      from Guile community?
-    < nalaginrut> or it doesn't help
-    < braunr> what do you want to ask them ?
-    < nalaginrut> since I don't know how this value was chosen
-    < nalaginrut> dunno, I'll ask if you need it
-    < nalaginrut> I just think maybe you need this info
-    < braunr> well
-    < braunr> my plan is to align the hurd on what other archs do
-    < braunr> i.e. set clk_tck to 100
-    < braunr> in which case this won't be a problem any more
-    < braunr> now you could warn them about the protability issue
-    < braunr> i'm not sure if they would care though
-    < nalaginrut> the warning is useful for the future
-    < nalaginrut> and it's not hard to make a change I think, for a constant,
-      but it depends on the maintainers
-    < braunr> it's not that simple
-    < braunr> time related things can easily overflow in the future
-    < nalaginrut> alright
-    < braunr> refer to the 2038 end-of-the-world bug
-    < nalaginrut> so how can I describe the warning/suggestion to them? 
-    < braunr> i'm not sure
-    < braunr> tell them the TIME_UNITS_PER_SECOND isn't appropriate for larger
-      values of clk_tck
-    < braunr> dammit, microseconds are hardcoded everywhere in
-      sysdeps/mach/hurd ... >(
-    < braunr> nalaginrut: my new patch seems to fix the problem
-    < braunr> nalaginrut: i've built debian packages with which you can
-      directly test
-    < braunr> nalaginrut: deb http://ftp.sceen.net/debian-hurd-i386
-      experimental/
-    < braunr> Totals for this test run:
-    < braunr> passes:                 38605
-    < braunr> failures:               0
-    < braunr> unexpected passes:      0
-    < braunr> expected failures:      7
-    < braunr> unresolved test cases:  578
-    < braunr> untested test cases:    1
-    < braunr> unsupported test cases: 10
-    < braunr> errors:                 0
-    < braunr> PASS: check-guile
-    < braunr> =============
-    < braunr> 1 test passed
-    < braunr> =============
-    < braunr> :)
-    < braunr> youpi: the branch i added to glibc contains a working patch for
-      clock_t in centiseconds
-    < youpi> k
-
-
-### IRC, freenode, #hurd, 2013-08-28
-
-    <nalaginrut> braunr:  well, looks great! I'll try it soon~
-    <nalaginrut> braunr:  BTW, where is the patch/
-    <mark_weaver> braunr: what was needed to get guile working on the hurd?
-    <mark_weaver> well, if the fix wasn't to guile, I don't need the details.
-    <braunr> 04:53 < nalaginrut> braunr:  BTW, where is the patch/
-    <braunr> there is hardly anyone here at 5am
-    <braunr> nalaginrut:
-      http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/clock_t_centiseconds
-    <nalaginrut> braunr:  thanks for that, but why not use a constant for 100?
-    <braunr> nalaginrut: i don't know where to define it
-    <braunr> it's glibc, you don't define new stuff mindlessly
-    <youpi> braunr: about your centiseconds patch, did you run the libc
-      testsuite with it?
-    <mark_weaver> it does seem a shame to reduce the resolution of the timers
-      from microseconds to centiseconds.  I wonder if that could be avoided.
-    <youpi> by fixing all applications which assume centiseconds
-    <mark_weaver> *nod*  well, if there's such a problem in Guile, I'd be glad
-      to fix that.
-    <braunr> youpi: no
-    <mark_weaver> I see that there's a macro CLOCKS_PER_SEC that programs
-      should consult.
-    <youpi> braunr: ok, I'll do then
-    <braunr> mark_weaver: why is it a shame ?
-    <braunr> it's not clock or timer resolution
-    <youpi> it's clock_t resolution
-    <braunr> it's an obsolete api to measure average cpu usage
-    <braunr> having such a big value on the other hand reduces the cpu usage
-      durations
-    <mark_weaver> braunr: good point :)  I confess to being mostly ignorant of
-      these APIs.
-    <mark_weaver> Though Guile should still consult CLOCKS_PER_SEC instead of
-      assuming centiseconds.  If it's making an improper assumption, I'd like
-      to know so I can fix it.
-    <braunr> the improper assumption is that there are less than 1000 clock
-      ticks per second
-    <mark_weaver> do you know off-hand of some code in Guile that is making
-      improper assumptions?
-    <braunr> yes
-    <braunr> let me find it
-    <mark_weaver> thanks
-    <braunr>   factor = scm_quotient (scm_from_long (TIME_UNITS_PER_SECOND),
-    <braunr>                          scm_from_long (ticks_per_second));
-    <braunr> it seems guile attempts to normalize all times values to
-      TIME_UNITS_PER_SECOND
-    <braunr> while i think it would be better off using ticks_per_second (clock
-      ticks as provided by sysconf())
-    <braunr> attempting to normalize here causes factor to become 0 if
-      TIME_UNITS_PER_SECOND < ticks_per_second
-    <mark_weaver> ah, I see.
-    <mark_weaver> I'll take care of it.  thanks for the pointer!
-    <youpi> braunr: I've commited the centisecond patch to debian's glibc
-
-
-### IRC, freenode, #hurd, 2013-08-29
-
-    <nalaginrut> braunr:  Guile2 works smoothly now, let me try something cool
-      with it
-    <braunr> nalaginrut: nice
-
-
-### IRC, OFTC, #debian-hurd, 2013-09-29
-
-    <pinotree> youpi: is the latest glibc carrying the changes related to
-      timing? what about gb guile-2.0 with it?
-    <youpi> it does
-    <youpi> so that was the only issue with guile?
-    <youpi> well at least we'll see
-    <pinotree> iirc yes
-    <pinotree> according to nalaginrut and the latest build log, it'd seem so
-    <youpi> started
-    <youpi> yay, guile-2.0 :)
-    <pinotree> yay
diff --git a/open_issues/tinyproxy.mdwn b/open_issues/tinyproxy.mdwn
deleted file mode 100644
index 9a4a0cfb..00000000
--- a/open_issues/tinyproxy.mdwn
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!meta copyright="Copyright © 2009 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]]."]]"""]]
-
-[[!meta title="Problem with using tinyproxy for tunneling HTTPS"]]
-
-`tinyproxy` works fine for HTTP connections, but fails to proxy HTTPS ones:
-
-    ERROR     Jun 12 14:58:51 [20676]: relay_connection: select() error "Interrupted system call". Closing connection (client_fd:7, server_fd:8)
-
-This is supposedly due to the already known select bug, which is a [[!taglink
-open_issue_glibc]].
diff --git a/open_issues/tmux.mdwn b/open_issues/tmux.mdwn
deleted file mode 100644
index c49a5e12..00000000
--- a/open_issues/tmux.mdwn
+++ /dev/null
@@ -1,57 +0,0 @@
-[[!meta copyright="Copyright © 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_porting]]
-
-
-# IRC, freenode, #hurd, 2013-08-01
-
-    <braunr> teythoon: can you stop tmux on darnassus please ?
-    <braunr> i'd like to check something
-    <teythoon> done
-    <braunr> tmux makes load average grow to 5 without any visible activity :/
-    <braunr> can't reproduce it with my instances though
-    <braunr> anyway, that's minor
-    <teythoon> I used tmux before and never encountered that
-    <teythoon> sometimes tmux would hang on attaching or detaching though, but
-      overall I had less problems with tmux than with screen
-    <teythoon> ah, I tried to start tmux on darnassus and now it hangs
-
-
-# IRC, freenode, #hurd, 2014-02-04
-
-    <teythoon> braunr: whoa, i can reproduce gnu_srs' hanging ssh sessions on
-      darnassus
-    <teythoon> here goes
-    <teythoon> run tmux, exit the shell so that tmux quits, start tmux again
-      (tmux hangs now on some socket stuff), log in with ssh again, pkill tmux,
-      rm /tmp/tmux*/default => both ssh sessions hang and time out eventually
-    <braunr> why start tmux twice ?
-    <teythoon> dunno
-    <teythoon> that's what i just did, twice in a row
-    <teythoon> there's a bug somewhere that makes tmux hang if the socket
-      exists but no tmux server is running
-    <teythoon> maybe that contributes to to the other issuse, i don't know
-    <braunr> looks like an infinite loop somewhere
-    <gnu_srs> teythoon: Nice to set that I'm not alone having this problem:P
-    <braunr> teythoon: what's happening ? :)
-    <teythoon> ?
-    <braunr> on darnassus
-    <teythoon> not sure
-    <teythoon> uh, something is very wrong o_O
-    <teythoon> help ?
-    <braunr> :)
-    <braunr> the msg thread of a process is blocked somewhere
-    <braunr> preventing ps/top from completing
-    <braunr> looks like proc is blocked now ..
-    <braunr> restarting the vm
-    <braunr> apparently, removing buggy tmux sockets make pflocal crash
-    <braunr> thanks for the report :)
-    <teythoon> you are welcome :)
diff --git a/open_issues/translate_fd_or_port_to_file_name.mdwn b/open_issues/translate_fd_or_port_to_file_name.mdwn
deleted file mode 100644
index 252bc049..00000000
--- a/open_issues/translate_fd_or_port_to_file_name.mdwn
+++ /dev/null
@@ -1,280 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 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]]
-
-
-# IRC, freenode, #hurd, June (?) 2010
-
-    <pochu> is there a way (POSIX or Hurdish) to get the corresponding file
-      name for a fd or a hurd port?
-    <marcusb> there is a way
-    <pochu> marcusb: which one would that be?
-    <marcusb> I forgot
-    <marcusb> there is an implementation in libc
-    <marcusb> realpath has a similar job
-    <marcusb> but that's not what I mean
-    <marcusb> pochu: maybe I am misremembering.  But it was something where you
-      keep looking up .. and list that directory, looking for the node with the
-      ID of the node you had .. for
-    <marcusb> maybe it works only for directories
-    <marcusb> yeah
-    <marcusb> pochu: check the getcwd() implementation of libc
-    <marcusb> sysdeps/mach/hurd/getcwd.c
-    <marcusb> _hurd_canonicalize_directory_name_internal 
-    * pochu looks
-    <pochu> marcusb: interesting
-    <pochu> though that is for dirs, and doesn't seem to be extensible to
-      files, as you cannot lookup for ".." under a file
-    <marcusb> right
-    <pochu> oh you already said that :)
-    <marcusb> actually, I am not sure that's correct
-    <marcusb> it's probably correct, but there is no reason why looking .. up
-      on a file couldn't return the directory it's contianed in
-    <pochu> I don't know the interfaces or the Hurd internals very well yet,
-      but it would look strange to me if you could do that
-    <marcusb> the hurd is strange
-    <pochu> it sounds like if you could `ls getcwd.c/..` to get
-      sysdeps/mach/hurd/ :-)
-    <marcusb> yep
-    <pochu> ok. interesting
-    <marcusb> you wouldn't find "ls foo.zip/.." very strange, wouldn't you?
-    <pochu> I guess not if `ls foo.zip` listed the contents of foo.zip
-    <marcusb> there you go
-    <marcusb> or the other way round: would you be surprised if "cat somedir"
-      would work?
-    <pochu> I think so. if it did, what would it do?
-    <marcusb> originally, cat dir would list the directory content!
-    <marcusb> in the old unix times
-    <pochu> I was surprised the first time I typed `vi somedir` by accident
-    <marcusb> and some early BSDs 
-    * pochu feels young :-)
-    <marcusb> he don't worry, I didn't see those times either
-    <marcusb> technically, files and directories are implemented in the same
-      way in the hurd, they both are objects implementing the fs.defs interface
-    <marcusb> which combines file and directory operations
-    <marcusb> of course, files and directories implement those functions
-      differently
-    <antrik> marcusb: do you know why this behavior (cat on directories) was
-      changed?
-
-
-## IRC, freenode, #hurd, 2013-03-07
-
-    * pinotree ponders about sending as RFC his patch for /proc/$pid/maps
-    <tschwinge> Including a scheme for providing the names of mapped files?
-      ;-D
-    <braunr> that would be really great indeed
-    <tschwinge> I have not yet researched how Linux does this.  Perhaps store
-      the filename used for first opening a file as a string somewhere?
-    <pinotree> tschwinge: eh, indeed that's lacking in my patch
-    <braunr> i'm not sure we should aim at doing it the same way
-    <youpi> I was wondering about having interfaces for naming tasks, threads,
-      objects
-    <youpi> that'd be useful for debugging in general
-    <braunr> yes
-    <braunr> i don't think we need to take namespaces into account
-    <braunr> a simple name or path should be quite enough
-    <tschwinge> Agreed.  "Just something!"
-    <tschwinge> So, a Java toString() method for ports.
-    <tschwinge> ;-)
-    <braunr> yes
-    <tschwinge> Oh, and could this also work recursively?  The ext2fs instance
-      on /home asks its parent fs about its own path -- can it do that?  (And
-      then cache that, most likely?)  Would one get rooted filesnames that way?
-    <braunr> i really don't think we should link it to the VFS
-    <braunr> it should merely be a name for debugging
-    <youpi> yep, same for me
-    <youpi> I'd say it's the linker's task of just setting a sane name
-    <braunr> first, keeping it isolated prevents increasing complexity
-    <braunr> next, it doesn't reduce performance
-    <tschwinge> youpi: Linker?
-    <tschwinge> braunr: Ack.
-    <braunr> yes, ld is the one creating the mappings
-    <youpi> tschwinge: the one that loads libraries
-    <tschwinge> Ah, for /proc/*/maps, right.  I've been thinking more globally.
-
-
-## task_get_name, task_set_name RPCs
-
-The following needs to be updated now that
-[[microkernel/mach/gnumach/interface/task_set_name]] has been implemented.
-
-[[!message-id "518AA5B0.6030409@verizon.net"]]
-
-
-## IRC, freenode, #hurd, 2013-05-10
-
-    <youpi> tschwinge's suggestion to put names on ports instead of tasks would
-      be useful too
-    <braunr> do you get task ports as easily as you get tasks in kdb ?
-    <youpi> there is task->itk_self & such
-    <youpi> or itk_space
-    <youpi> I don't remember which one is used by userspace
-    <braunr> i mean
-    <braunr> when you use the debugger, can you easily find its ports ?
-    <braunr> the task ports i mean
-    <braunr> or thread ports or whatever
-    <youpi> once you have a task, it's a matter of getting the itk_self port
-    <youpi> s/port/field member/
-    <braunr> so the debugger provides you with the addresses of the structs
-    <braunr> right ?
-    <youpi> yes, that's what we have already
-    <braunr> then ok
-    <braunr> bddebian: do that :p
-    <braunr> hehe
-    <youpi> see show all thread
-    <braunr> (haven't used kdb in a long time)
-    <bddebian> So, adding a name to ports like I did with tasks?
-    <braunr> remove what you did for tasks
-    <braunr> move it to ports
-    <braunr> it's very similar
-    <braunr> but hm
-    <braunr> i'm not sure where the RPC would be
-    <braunr> this RPC would exist for *all* ports
-    <braunr> or only for kernel objects if added to gnumach.defs
-    <youpi> it's just about moving the char array field to another structure
-    <youpi> and plugging that
-    <bddebian> But mach_task_self is a syscal, it looks like itk_self is just a
-      pointer to an ipc_port ?
-    <braunr> so ?
-    <braunr> you take that pointer and you get the port
-    <braunr> just like vm_map gets a struct vm_map from a task
-    <bddebian> So I am just adding ipc_port_name to the ipc_port struct in this
-      case?
-    <braunr> yes
-    <braunr> actually
-    <braunr> don't do anything just yet
-    <braunr> we need to sort a few details out first
-    <braunr> see bug-hurd
-
-
-## IRC, freenode, #hurd, 2013-12-05
-
-    <teythoon> braunr: no more room for vm_map_find_entry in 80220a40
-    <teythoon> 80220a40 <- is that a task ?
-    <braunr> or a vm_map, not sure
-    <braunr> probably a vm_map
-    <teythoon> hm
-    <teythoon> let's fix this kind of reporting
-    <braunr> :)
-    <teythoon> let one process register for kernel log messages
-    <teythoon> make a rich interface, say klog_thread and friends
-    <teythoon> a userspace process gets the port name, looks it up in proc,
-      logs nicely to syslog
-    <teythoon> if noone registered for this notifications, fall back to the old
-      reporting
-    <braunr> i tend to think using internal names is probably better
-    <teythoon> how would i use them to see wich process caused the issue ?
-    <braunr> you give the name of the task
-    <braunr> (which means tasks have names, yes)
-    <teythoon> ok
-    <braunr> the reason is that reporting is often used for debugging
-    <braunr> and debugging usually means there is a bug
-    <braunr> if the bug prevents from reporting, it's not very useful
-    <braunr> and we're talking about the kernel here, the low level stuff
-    <teythoon> incidentally, i got myself a stuck process
-    <teythoon> ah, got it killed
-    <teythoon> braunr: so you propose to add a task rpc to set a name ?
-    <braunr> i don't want to push such things
-    <braunr> which is why this hasn't been done until now
-    <braunr> but that's what i'd do in x15, yes
-    <teythoon> y not ?
-    <braunr> and instead of a process registered to gather kernel messages, i'd
-      use a dmesg-like interface, where the kernel manages its message buffer
-      itself
-    <braunr> i didn't feel the need to
-    <braunr> the tools i've had until now were sufficient
-    <braunr> don't forget you still need to fix mtab :p
-    <braunr> or is it done ?
-    <teythoon> i sometimes see tasks deallocating invalid ports
-    <teythoon> no
-    <teythoon> there is an un-acked patche series on the list
-    <braunr> ok
-    <teythoon> so, i want to identify which process caused it
-    <teythoon> is that possible right now ?
-    <braunr> not easily, no
-    <teythoon> so that's a valid use case
-    <braunr> it is
-    <teythoon> good
-    <teythoon> :)
-    <teythoon> so proc would register a string describing each task and mach
-      would use this for printing nicer messages ?
-    <braunr> for example, yes
-    <braunr> one problem with that approach is that it doesn't fit well with
-      subhurds
-    <teythoon> *bingbingbing
-    <braunr> but i personally wouldn't care much, they're kernel messages
-    <braunr> in the future, we could make mach more a hypervisor, and register
-      names for each domains
-    <teythoon> yet unanswered proposal about hierachical proc servers on the
-      list...
-    <teythoon> that'd also fix subhurds, so that the parents processes won't
-      appear in the subhurd
-    <teythoon> making it sandboxier
-    <teythoon> and killall5 couldn't slaughter the host system if the subhurd
-      shuts down with sysvinit
-
-
-## IRC, freenode, #hurd, 2014-01-20
-
-    <teythoon> i wonder if it would not be best to add a description to mach
-      tasks
-    <braunr> i think it would
-    <teythoon> to aid fixing these kind of issues
-    <braunr> in x15, i actually add descriptions (names) to all kernel objects
-    <teythoon> that's probably a good idea, yes
-    <braunr> well, not all, but many
-
-
-## IRC, OFTC, #debian-hurd, 2014-02-05
-
-    <teythoon> youpi: about that patch implementing task_set_name, may i merge
-      the amended version ?
-    <youpi> yes
-
-
-# IRC, freenode, #hurd, 2011-07-13
-
-A related issue:
-
-    <braunr> rbraun@nordrassil:~$ vminfo $$ | wc -l
-    <braunr> 1039
-    <braunr> any idea why a shell would consume more than 1039 map entries ?
-    <braunr> (well, not more actually)
-    <braunr> even the kernel and ext2fs have around 100
-    <braunr> (the kernel has actually only 23, which is very good and expected)
-    <tschwinge> braunr: I agree that having some sort of debugging information
-      for memory objects et al. would be quite hand.  To see where they're
-      coming from, etc.
-    <braunr> tschwinge: this would require naming objects at the mach level
-    <braunr> e.g. when creating an object
-    <braunr> giving it the path of a file for example
-    <tschwinge> braunr: I have recently seen something (due to youpi fixing a
-      bug) that bash is doing its own memory management.  Perhaps all these are
-      such regions?
-    <tschwinge> braunr: For example, yes.
-    <braunr> what ?
-    <braunr> ?!
-    <tschwinge> braunr:
-      http://lists.gnu.org/archive/html/bug-bash/2011-04/msg00097.html
-    <braunr> i see
-
-Also see email thread starting at [[!message-id
-"20110714082216.GA8335@sceen.net"]].
-
-Justus: Once [[!message-id desc="these patches"
-"1375178364-19917-4-git-send-email-4winter@informatik.uni-hamburg.de"]] are
-merged, there will be a way to map from ports to file names, at least for
-libdiskfs and libnetfs, one would only have to make this information available
-somehow.
diff --git a/open_issues/translator_environment_variables.mdwn b/open_issues/translator_environment_variables.mdwn
deleted file mode 100644
index cae5a494..00000000
--- a/open_issues/translator_environment_variables.mdwn
+++ /dev/null
@@ -1,31 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_hurd]]
-
-IRC, unknown channel, unknown date.
-
-    <cfhammar> BTW, is settrans -a supposed to clear all env variables?
-    <cfhammar> or can I consider it a bug ;-)
-    <cfhammar> scolobb: yeah, seems the problem is in libfshelp
-    <scolobb> cfhammar: Are you talking about fshelp_start_translator_long?
-    <scolobb> (I can remember that it does something to the environment indeed)
-    <cfhammar> scolobb: yes, I think it's the culprit
-    <cfhammar> clearing the environment makes sense for passive translators I guess, but not active ones
-    <scolobb> Hm, searching ``env'' in hurd/libfshelp/start-translator-long.c gives me nothing :-(
-    <scolobb> I think the problem might be in the fact that fshelp_start_translator_long just doesn't copy the environment, but I may be wrong.
-    <cfhammar> scolobb: yeah, that's my guess also
-    <scolobb> Well, I don't know proc, but there might be a way to copy the environment to a task when you know its ID, what do you think?
-    <scolobb> I can see proc_set_arg_locations in process.defs, which sees to set something connected with environment, but I'm not sure whether it suits your needs.
-    <cfhammar> scolobb: it seems that the env isn't passed to file_exec in fshelp_start_translator_long
-    <scolobb> cfhammar: Yeah, that's right
-    <scolobb> I wonder what could the motivation for not passing the environment to a child process
-    <cfhammar> hmm... fshelp_start_translator_long parameterizes everything except env...
-    <cfhammar> perhaps there needs to be a fshelp_start_translator_longer ;-)
diff --git a/open_issues/translator_stdout_stderr.mdwn b/open_issues/translator_stdout_stderr.mdwn
deleted file mode 100644
index 89efd4e1..00000000
--- a/open_issues/translator_stdout_stderr.mdwn
+++ /dev/null
@@ -1,114 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2013 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]]."]]"""]]
-
-[[!toc]]
-
-
-# "Weird Issue"
-
-## IRC, freenode, #hurd, 2013-07-01
-
-[[!tag open_issue_hurd]]
-
-    <teythoon> oh, btw, there is this weird issue that I cannot figure out
-    <teythoon> I noticed that there is no newline printed by /hurd/init after
-      printing " proc" and " auth"
-    <teythoon> but there *is* a printf("\n"); fflush(stdout); in there
-    <teythoon> it's just not working
-    <pinotree> iirc a newline is supposed to be printed after all the essential
-      servers have been started
-    <pinotree> that one
-    <teythoon> yes
-    <teythoon> but this doesn't happen
-    <teythoon> for whatever reason printf("foo"); yields no output
-    <braunr> how are proc and auth printed ?
-    <teythoon> neither does printf("%s", "foo");
-    <teythoon> using printf
-    <teythoon> but printf("%i fooo", 4); works
-    <youpi> uh
-    <braunr> ??
-    <youpi> and does printf("loooooooooong line") worker?
-    <teythoon> no
-    <youpi> uh
-    <youpi> -er
-    <teythoon> and yes, the code is always fflushing stdout
-    <youpi> perhaps trying to put a sleep(1); to check for timing issues?
-    <teythoon> yes, I suspect something like that
-    <teythoon> b/c *sometimes* my hurd just freezes at this point
-    <braunr> ???
-    <teythoon> after printing proc auth and not printing the newline
-    <braunr> such horror stories .
-    <braunr> ..
-    <teythoon> and I *think* that putting more printfs there for testing
-      purposes makes this worse, but I'm not sure about this
-    <braunr> in case you need to debug using printf, there is the mach_print
-      system call
-    <braunr> (in -dbg kernels)
-
-[[microkernel/mach/gnumach/interface/syscall/mach_print]].
-
-    <teythoon> what's wrong with using printf?
-    <braunr> you need to write the little assembly call yourself, where you
-      intend to use it, because it's not exported by glibc
-    <braunr> printf is an RPC
-    <braunr> teythoon: RPCs are complicated stuff
-    <braunr> in particular in core glibc parts like signal handling
-    <youpi> and printf goes through the console translator
-    <braunr> also, if you don't yet have a console server available, it comes
-      in handy
-    <youpi> better direct output directly to the kernel
-
-
-# `stderr` buffered
-
-## IRC, freenode, #hurd, 2011-11-06
-
-[[!tag open_issue_hurd]]
-
-    <youpi> about CLI_DEBUG, you can use #define CLI_DEBUG(fmt, ...) {
-      fprintf(stderr, fmt, ## __VA_ARGS__); fflush(stderr); }
-    <tschwinge> Isn't stderr in auto-flush mode by default?
-    <tschwinge> man setbuf: The standard error stream stderr is always
-      unbuffered by default.
-    <youpi> tschwinge: "by default" is the important thing here
-    <youpi> in the case of translators iirc stderr is buffered
-    <tschwinge> youpi: Oh!
-    <tschwinge> That sounds wrong.
-
-
-# Logging
-
-[[!tag open_issue_hurd]]
-
-There have been several discussions and proposals already, about adding a
-suitable logging mechanism to translators, for example.
-
-Decide / implement / fix that (all?) running (passive?) translators' output
-should show up on the (Mach / Hurd) console / syslog.
-
-[[!taglink open_issue_documentation]]: [[!message-id
-"87oepj1wql.fsf@becket.becket.net"]]
-
-[[!taglink open_issue_documentation]]: Neal once had written an email on this
-topic.
-
-
-## IRC, freenode, #hurd, 2011-11-23
-
-    <braunr> we'd need a special logging task for hurd servers
-    <pinotree> if syslog would work, that could be used optionally
-    <braunr> no, it relies on services provided by the hurd
-    <braunr> i'm thinking of something using merely the mach interface
-    <braunr> e.g. using mach_msg to send log messages to a special port used to
-      reference the logging service
-    <braunr> which would then store the messages in a circular buffer in ram
-    <braunr> maybe sending to syslog if the service is available
-    <braunr> the hurd system buffer if you want
diff --git a/open_issues/translators_O_NOTRANS_O_NOFOLLOW_namespace-based_selection.mdwn b/open_issues/translators_O_NOTRANS_O_NOFOLLOW_namespace-based_selection.mdwn
deleted file mode 100644
index 5d3c3aab..00000000
--- a/open_issues/translators_O_NOTRANS_O_NOFOLLOW_namespace-based_selection.mdwn
+++ /dev/null
@@ -1,148 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_hurd open_issue_glibc]]
-
-bug-hurd email from 2010-07-28: *O_NOTRANS & O_NOFOLLOW*
-
-2010-07-29, #hurd
-
-    <antrik> cfhammar: I think that touches on a rather fundamental problem... it's always hard to decide how to handle translators, as the most useful approach depends a lot on context
-    <antrik> this was actually part of the idea behind namespace-based translator selection
-    <cfhammar> or perhaps we should just drop the whole O_NOFOLLOW == O_NOTRANS and only apply it for link like translators
-    <pochu> cfhammar: from what I read in [glibc]/hurd/lookup-retry.c, the problem is that some translators can lie about that
-    <antrik> cfhammar: at some point I considered the possibility of adding a couple of special flags describing translators ("link" and "device" being some, but also introducing a few new ones) to decide standard behaviour in various situations
-    <pochu> so you can't really know whether they are links without O_NOTRANS
-    <cfhammar> pochu: yeah, this would have to be considered carefully
-    <pochu> antrik: care to explain what namespace based translator selection means? :)
-    <antrik> pochu: the basic idea is that you add special suffixes to the file name during a lookup, which change the behaviour of lookups
-    <antrik> the most basic use would be adding a suffix that automatically runs an annonymous translator on the file
-    <cfhammar> antrik: doesn't stat cover most of those flags (except for firmlink i guess)
-    <antrik> (scolobb mostly implemented that part)
-    <antrik> but the idea was also to selectively activate/deactivate static translators based on patterns
-    <antrik> (this is implemented partially, but recursion is completely missing so far)
-    <antrik> cfhammar: some of them, yes. but I think there are some cases where the standard stat information is not enough to decide on useful handling
-    <antrik> let's take the example of a translator that mangles the underlying file -- like xmlfs, mboxfs etc.
-    <antrik> these aren't device file nor links, but should not really be handled like "normal" (store) filesystems either
-    <antrik> hm... is there any information in the stat that indicates mount points?
-    <antrik> I guess that would be good enough to flag "normal" filesystems
-    <pochu> I'm not sure I understand. you add a suffix during a lookup, based on what? whatever, including e.g. flags?
-    <antrik> pochu: well, an exmple would be "cat foo.gz,,u"
-    <antrik> where "u" would be a shorthand for "unzip"
-    <antrik> and it would launch a translator that uncompresses the underlying file
-    <pochu> what if there are a foo.gz and a foo.gz,,u files?
-    <antrik> (I think storeio with gzip store can do that... though some more generic translator might be useful, to cover other compression/archieve types as well)
-    <antrik> pochu: than you are SOL ;-)
-    <antrik> pochu: I chose ",," as the suffix after some careful examination that this is *extremely* unlikely to occur in normal use
-    <antrik> pochu: actually, we introduced an escaping scheme too, so it is still possible to access files with ",," in the name... but that's of limited use, as programs not aware of this will still break
-    <cfhammar> hmm i wonder why glibc handles O_NOFOLLOW to begin with, since the test it does presumes trust in the containing directory the fs could do it just as securely
-    <antrik> cfhammar: the FS could do what?
-    <pochu> another problem I've found is that an open(symlink, O_RDONLY | O_NOFOLLOW, 0) should fail with ELOOP according to POSIX, but it doesn't fail on Hurd
-    <antrik> pochu: yeah, saw that
-    <antrik> shouldn't be too hard to fix I hope?...
-    <cfhammar> antrik: libc test whether the node is a symlink or a (trusted) root owned translator, which it would follow
-    <pochu> antrik: probably not, though I haven't looked at it closely
-    <antrik> cfhammar: in what situation would the filesystem do the test?
-    <antrik> cfhammar: and what advantage would it have over the current approach?
-    <antrik> pochu: OK
-    <cfhammar> antrik: the point of the test is to approximate symlink vs. mount point but the fs seems to be in a better position to answer this
-    <antrik> cfhammar: why? I think this information should be fully available to glibc... if it's not, I'd consider this a bug, or at least a major omission
-    <cfhammar> antrik: well take fifos for instance, they should be considered part of the containing filesystem but would not by glibc
-    <cfhammar> antrik: we could make an exception in glibc for fifos but not for other future situations in new translators
-    <cfhammar> antrik: i mean, we could but this leaves control at the translators hand and let different translators handle things their own way
-    <cfhammar> generally, it seems more flexible to leave policy to servers rather than to bake it into the (implicit) protocol (which glibc implements)
-    <antrik> cfhammar: I don't see though why handling it in the filesystem would help here... if the filesystem has the information about how the translator should be handled, it can pass it to the clients
-    <antrik> hm... that's actually a tricky point. we have many situations where we have to choose between handling things in the client library or server-side... I'm haven't really formed an opinion yet which is preferable in general
-    <pochu> with cfhammar's proposal, you wouldn't need O_NOTRANS when you specify O_NOFOLLOW, right?
-    <cfhammar> pochu: i don't think my proposal would even work with O_NOTRANS
-    <antrik> cfhammar: hm, perhaps we are talking past each other. do you want the handling to be in the filesystem containing the underlying node, or in the actual translator implementing the node?
-    <antrik> hrm
-    <cfhammar> antrik: the containing filesystem
-    <cfhammar> (since this is a security issue)
-    <pochu> yeah, otherwise the trust issue would still be there
-    <antrik> then why wouldn't it work with O_NOTRANS?
-    <antrik> BTW, what security issue are you talking about? do you mean the fact that a translator can redirect the lookups to another file, but hide the fact that it's a link?
-    <pochu> antrik: I mean the O_NOTRANS & O_NOFOLLOW comment in [glibc]/hurd/lookup-retry.c
-    <cfhammar> antrik: because O_NOTRANS means don't follow translators (including symlinks) and O_NOFOLLOW means don't follow (any) link but do follow translators
-    <antrik> pochu: I must admit that I never fully understood what that one is about :-)
-    <cfhammar> antrik: i imagine O_NOTRANS|O_NOFOLLOW == O_NOTRANS
-    <antrik> cfhammar: I see
-    <antrik> cfhammar: but I guess that's totally orthogonal from handling in glibc vs. handling in the FS?...
-    <pochu> AFAIU, it's that if you do an open(translator, O_NOFOLLOW, 0), the translator can lie about it being a symlink. So you need to do an O_NOTRANS lookup
-    <pochu> hence hurd/hurdlookup.c adds O_NOTRANS if O_NOFOLLOW is present in flags
-    <antrik> ah, OK
-    <antrik> so the idea here is that instead of doing that, glibc would only pass on O_NOFOLLOW, and the filesystem would handle the O_NOTRANS part itself
-    <cfhammar> antrik: if you have O_NOTRANS the filesystem will never follow any translators including non-link ones, so it can't really handle O_NOFOLLOW to exclude link translators
-    <cfhammar> antrik: yeah
-    <antrik> AIUI the problem is that with the current scheme, using O_NOFOLLOW will also ignore non-link translators?
-    <cfhammar> antrik: exactly, including fifos
-    <cfhammar> antrik: of course, there's still the problem of determining that it is a non-link translator
-    <antrik> cfhammar: but why can't this be fixed keeping the current scheme? wouldn't it suffice for glibc to ask the filesystem whether there is a link (with O_NOTRANS), and if not, do the actual lookup without O_NOTRANS?...
-    <pochu> antrik: there's still the problem of translators lying about them being symlinks or not, right? so instead of a blacklist (is it a symlink?) you would need a whitelist
-    <antrik> pochu: sure. I just don't see how an implementation in the filesystem would do any better on that score than one in glibc
-    <cfhammar> antrik: the fs is better at maintaining the whitelist, e.g. you could have different whitelist for different translators
-    <cfhammar> antrik: the fs also knows who own the fs, so it could make exeptions for the owner's translators
-    <cfhammar> like glibc does for the root user, currently
-    <antrik> I'm not really convinced so far that having these policies in the filesystem is really preferable to having them in the client-side library...
-    <cfhammar> antrik: we want to put /hurd/fifo in the whitelist for all users but we can't determine whether an active translator on the underlying node is /hurd/fifo or not, but the FS can if it started the translator itself
-    <cfhammar> antrik: of course, this can also be done by hiding the /hurd/fifo translator so that glibc doesn't do the test in the first place
-    <cfhammar> antrik: but this isn't pretty, you'd have to proxy it afaics :-/
-    <antrik> cfhammar: TBH, I don't like the whole whilelisting idea
-    <antrik> seems to me this is really just another manifestation of the infamous firmlink problem
-    <antrik> as I said in past discussions, I tend to think that the only way to fix it *properly* is changing the way authentification is handled
-    <antrik> we actually discussed this at some point... when crossing translator boundries, the client shouldn't use it's full permissions on the new translator, but rather the intersection of it's own permissions and that of the parent translator
-    <antrik> this way, "secret" links should cease to be dangerous...
-    <cfhammar> yeah, but that'll take way too long for poor pochu ;-)
-    <antrik> cfhammar: true... but I'm not convinced that a whitelisting hack in the meantime is really worthwhile
-    <cfhammar> antrik: we already have a whitelisting hack (root user's translators), we're just moving it to the filesystem and adding /hurd/fifo
-    <antrik> cfhammar: nope, allowing all root translators is a general policy, not a whitelisting hack
-    <antrik> not elegant either, but a very different class
-    <cfhammar> antrik: i don't remember the details but fixing firmlink problem seemed to require some fundamental changes, it might even turn out to be unfeasible
-    <antrik> BTW, it's still not clear to my why the filesystem is supposed to have a better idea which translators to whitelist than glibc?...
-    <cfhammar> antrik: huh, i don't think i've seen that policy elsewhere, only for root clients not servers
-    <cfhammar> antrik: for one it can keep track of if the current active translator is the current passive one, and thus know which program it runs
-    <antrik> do I get it right that in the case of fifo, the client can't generally trust the user running the translator, and thus the idea is instead to trust the translator program?...
-    <cfhammar> O_NOFOLLOW implies that the client does not trust the file not to redirect it anywhere and we know /hurd/fifo will not do this
-    <antrik> cfhammar: was that a "yes"?...
-    <cfhammar> antrik: yes
-    <antrik> hm... I think I already said it in the context of object migration: I really don't like the idea of trust based on the program being executed...
-    <antrik> this workaround also has other shortcomings: what if the transaltor is started actively?
-    <cfhammar> hmm the owner of the translator could hijack it and the fs wouldn't know
-    <antrik> I must admit though that I don't see another short-term solution either :-(
-    <antrik> oh, right, that's another problem
-    <cfhammar> seems like the fs must implement the fifo itself (or atleast hide the /hurd/fifo translator behind a proxy)
-    <antrik> BTW, what is the specific manifestation of the problem with fifos being ignored on NOFOLLOW?
-    <pochu> there are two problems
-    <pochu> one is that with O_NOFOLLOW, it's ext2fs who checks the file permissions, and denies it (dunno the reason for that)
-    <pochu> the other one is that if you stat the fifo with O_NOFOLLOW and without it, the device will look different (and thus cp believes the file has changed and fails)
-    <pochu> that's because an stat on the fifo will return the fifo translator's PID as the device
-    <antrik> ah
-    <pochu> while one with O_NOFOLLOW will return the partition device
-    <antrik> so the specific problem here is that the stat info is differenet with the fifo translator than without
-    <pochu> I'm not sure whether it would be correct & possible to return the device of the parent translator in libtrivfs, instead of the PID
-    <pochu> yes
-    <pochu> that, and the permission one (they are different)
-    <pochu> though both would be solved if O_NOFOLLOW didn't imply O_NOTRANS :)
-    <antrik> what exactly do you mean by "device" here?
-    <pochu> I mean st_dev in struct stat
-    <antrik> well, I wonder whether the permission problem shouldn't actually be considered a bug in fifo. i sthere a good reason why the permissions are not propagated to the underlying node, as with most other translators?
-    <pochu> I don't think that's the problem
-    <antrik> what else?
-    <pochu> it's rather that if you open the fifo with O_NOTRANS, you don't get the underlying node, and then it's ext2fs (and so libdiskfs) who checks the permissions, and it denies them for whatever reason
-    <pochu> antrik: libdiskfs/dir-lookup.c has this:
-    <pochu>       if (((type == S_IFSOCK || type == S_IFBLK || type == S_IFCHR)
-    <pochu> >-------   && (flags & (O_READ|O_WRITE|O_EXEC)))
-    <pochu> >-------  || (type == S_IFLNK && (flags & (O_WRITE|O_EXEC))))
-    <pochu> >-------error = EACCES;
-    <pochu> so it returns EACCES for the fifo
-    <pochu> I wonder whether there's a good reason (that I'm missing) for that
-    <cfhammar> pochu: i think the reason might be that ext2fs denies access because it does not implement those file types itself
-    <cfhammar> i.e. ext2fs expects them to be opened without O_NOTRANS
-    <cfhammar> (or opened exclusively for non rwx reasons such as stat or settrans)
diff --git a/open_issues/translators_set_up_by_untrusted_users.mdwn b/open_issues/translators_set_up_by_untrusted_users.mdwn
deleted file mode 100644
index ad0187e3..00000000
--- a/open_issues/translators_set_up_by_untrusted_users.mdwn
+++ /dev/null
@@ -1,583 +0,0 @@
-[[!meta copyright="Copyright © 2011, 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_hurd]]
-
-
-# IRC, freenode, #hurd, 2011-07-17
-
-    <antrik> Reventlov: this is the so-called "firmlink issue" -- though AFAIK
-      it doesn't actually apply to firmlinks ;-)
-    <antrik> the problem is that any user can in theory create and set up a
-      special translator, which will redirect to another directory, without any
-      indication that it's a link
-    <braunr> but this doesn't supersede the file system permissions, does it ?
-    <antrik> as a result, if someone runs rm -r on the directory containing
-      that translator (which could be a world-writable one such as tmp), the rm
-      -r will descend into the directory, and thus remove it with the
-      permissions of the user who ran the rm -- not the one who set up the
-      translator
-    <braunr> oh i see, when tmp gets cleared by a script run as root, your home
-      is deleted ?
-    <antrik> right
-    <antrik> of course, the workaround is trivial: just don't follow
-      translators set up by untrusted users
-    <antrik> (which is precisely the default policy for FUSE BTW)
-    <braunr> which is the general policy around memory managers in general
-    <antrik> it's just nobody cared to implement this change
-    <youpi> antrik: does rm use O_NOTRANS ?
-    <antrik> youpi: I'm pretty sure it doesn't
-    <youpi> so it's still an issue for now
-    <antrik> yes, it's still an issue. it's just not a really fundamental
-      problem as macrus claimed it to be... [sigh]
-    <youpi> well, fix rm and then you can say it's not an issue any more
-    <braunr> does it only concern rm ?
-    <antrik> youpi: rm is just an example. the problem is much more generic: a
-      malicious translator can do all kinds of harm
-    <youpi> sure
-    <youpi> it's just about tools not blindly following things
-    <antrik> the only simple and effective answer is not to follow translators
-      from untrusted users by default
-    <youpi> antrik: but then /dev/null can't be non-root
-    <braunr> depends how "untrusted users" are identified
-    <antrik> we discussed a more sophisticated solution with cfhammer, that
-      would change the way reauthentication works in lookups, and should
-      prevent these kinds of permission escalation without preventing desirable
-      uses... but it still wouldn't address DOS issues, so it would be only a
-      partial solution
-    <antrik> youpi: why should it?
-    <manuel> (http://lists.gnu.org/archive/html/bug-hurd/2009-11/msg00231.html
-      for the most sophisticated solution)
-    <antrik> braunr: well, currently the permission system generally trusts
-      root and the own user. implementing something else might be tricky... not
-      sure
-    <antrik> manuel: yes, that's precisely the discussion I was referring
-      to... thanks for the link :-)
-    <youpi> antrik: depends what you mean by "follow"
-    <youpi> what DOS are you thinking of?
-    <antrik> youpi: a translator can generate endless amounts of "data"; a
-      translator can generate endless recursive directory tress; or it can just
-      never return from RPCs... all things that can do pretty much harm
-      depending on the situation
-    <antrik> filesystem clients generally trust filesystem operations to be
-      safe -- and that's just not true anymore with filesystems run by
-      untrusted users
-    <antrik> (be it Hurd translators or FUSE modules)
-    <antrik> this is a fundamental problem as marcus and neal rightly observed
-    <antrik> I just don't agree about the seriousness of the consequences
-    <antrik> I don't think not following untrusted translators really looses us
-      much
-    <youpi> EDOOMANYNEGATIONS
-    <youpi> s/D/T
-    <youpi> again, what do you mean by "following" ?
-    <youpi> always use O_NOTRANS ?
-    <tschwinge> Yes, I think.
-    <youpi> or never accept a REAUTH ?
-    <youpi> O_NOTRANS would mean ftpfs running as root, brrr
-    <youpi> it's not really true that clients always trust filesystem
-      operations
-    <youpi> the "not returning" case for instance, also appears with nfs mounts
-    <antrik> no, not always use O_NOTRANS. just be more selective about what
-      translators to follow. specifically, don't follow translators set up by
-      untrusted users. (unless explicitly requested)
-    <antrik> you can think of it as O_NO_UNTRUSTED_TRANS
-    <antrik> note that if you run ftpfs under a special user, who is not root
-      but trusted by root, this would still be fine. I hope it shouldn't be too
-      hard to implement that...
-    <antrik> as for NFS: clients generally do *not* try to catch possible
-      failures. if the NFS server doesn't return, the clients hang forever. but
-      the NFS server is generally trusted, so this is not much of a problem
-    <antrik> BTW, I guess not accepting reauth from untrusted translators would
-      also fix the privilege escalations (similar to the proposed modified
-      reauth mechanism, only more invasive); but it wouldn't fix the DoS issues
-    <ArneBab> antrik: would that also be an issue for a run translator, which
-      runs a command on read?
-    <ArneBab> youpi: couldn’t ftpfs have root drop priviledges?
-    <ArneBab> like a runas trans
-    <ArneBab> essertially su for translators to drop privs
-    <antrik> ArneBab: hm... if we can make sure that the translator was started
-      as root, and dropped privileges later, I guess that would be fine... not
-      sure how hard that is
-    <antrik> ArneBab: but I think it would be more elegant to start the
-      translators as trusted non-root users in the first place
-    <ArneBab> then i ph.avme to trust them
-    <ArneBab> deper hierarchy
-    <ArneBab> deeper
-    <ArneBab> but essertially the same
-    <ArneBab> if then someone mounted his home himself, would I be able to read
-      it?
-    <ArneBab> /home/user
-    <ArneBab> antrik: if not, that would be really non-nice
-    <antrik> ArneBab: sorry, but we simply *can't* trust a translator set up by
-      an untrusted user. if he controls it, he can make it behave maliciously
-    <antrik> we could in theory try to come up with a proxy that catches
-      problematic semantics, and presents a "safe" variant to the actual
-      clients... but that would be not-trivial, and I'm not sure how safe it
-      can be made
-    <antrik> ArneBab: of course you should always have the option to explicitly
-      say that you want to trust the translator, if you think the user doesn't
-      have malicious intentions :-)
-    <antrik> (I think nsmux would be a good way to achieve this...)
-    <braunr> unless it's really really necessary (and i don't see why it would
-      be), no design should force a process to start with privileges and drop
-      them
-    <braunr> having a set of trusted users (e.g. uid < 100) is a nice solution
-      to the problem imho
-    <braunr> or part of a group, 100 is a non-hurdish static limit
-    <ArneBab> What user is running a passive translator?
-    <braunr> passive translators are a pain for such things :/
-    <braunr> a command line and attach point are not enough to persistently
-      encode the execution context of the tranlator
-    <ArneBab> What user is running a passive translator?
-    <ArneBab> sorry
-    <braunr> the one owning the inode if i'm right
-    <ArneBab> so actually the orly problem are recursive commands, which also
-      are a problem with plain symlinks?
-    <braunr> i'm not sure
-    <ArneBab> Is thene any havoc a translator can wreak that a symlink can’t?
-    <braunr> well, as symlinks are translators, if a translator can damage
-      something, a symlink may too
-    <ArneBab> but not in Linux?
-    <braunr> err
-    <braunr> there are no translator in linux
-    <ArneBab> → commands could just treat translators as symlinks
-    <ArneBab> jepp, but it has symlinks
-    <braunr> no, this would defeat the purpose of translators :p
-    <braunr> and it's just no doable
-    <braunr> you would have recursion everywhere
-    <ArneBab> why?
-    <braunr> because every file access is sent to a translator
-    <ArneBab> hm, yes
-    <braunr> and we don't want to change commands
-    <braunr> we want to fix the design
-    <ArneBab> → only untrusted trans 
-    <braunr> rather than considering them as symlinks, just consider them as
-      untrusted translators
-    <braunr> this doesn't change the semantics, only the action of accessing a
-      node or not
-    <braunr> but as antrik said, this has to be done :)
-    <braunr> the real problem would simplify to "how do you know if a
-      translator can be trusted", which is a matter of selecting the righ
-      identification strategy
-    <braunr> one strong strategy would be to have a port right copied to each
-      trusted task
-    <braunr> i wonder if one of the special ports could be used for that
-    <braunr> or if we have to add a new one
-    <ArneBab> so when I login, I would give port rights to trusted uids?
-    <braunr> no
-    <braunr> when a trusted translator starts a passive translator attached on
-      a node owned by root, it would copy its trusted right to the new task
-    <braunr> much like the device master port is passed to root tasks
-    <braunr> but i'm not sure this mechanism can be safely used to know if the
-      translator can be trusted
-    <braunr> the translator would be able to actively call services requiring
-      this capability
-    <braunr> but i guess client tasks would have to ask for the translator to
-      prove it's trusted
-    <braunr> which is a problem because the issue is to know if it can be
-      trusted before asking it anything
-    <braunr> another way is to register trusted tasks in another server, and
-      ask this server if the target translator is trusted
-    <braunr> i"m pretty sure these strategies already exist in some form on the
-      hurd
-    <ArneBab> hm
-    <braunr> does someone here have an idea why BSD-derived VMs account wiring
-      information at the high level vm_map instead of storing it in lower level
-      vm_page ?
-    <ArneBab> braunr: a translator anywhene in the FS can only be there, if the
-      creator had sufficient rights to the node, right?
-    <ArneBab> so wouldn’t it suffice to check the access rights?
-    <braunr> no
-    <braunr> ismple example: /dev/null is owned by root, but you have read
-      access to it
-    <braunr> hm that may not answer your question actually
-    <braunr> what access right would you check ?
-    <braunr> if someone creates a node with rights 777, do you still want to
-      access it ?
-    <ArneBab> no
-    <braunr> simple enough i hope :)
-    <ArneBab> arg…
-    <ArneBab> if I can write to it, I can give it a translaton
-    <ArneBab> translator
-    <braunr> but this doesn't tell you it can be trusted
-    <ArneBab> well, actually: yes, access, but not recurse
-    <braunr> the owner sets his own rights, and you can't trust the owner
-    <braunr> unless it's root, but you don't want all your translators to run
-      as root
-    <ArneBab> it can act as its owner?
-    <ArneBab> yes
-    <braunr> well, as i told you, a passive translator is started by its parent
-      translator (the one managing the file systeme node it's attached to)
-    <braunr> the new translator runs as the user owning the node
-    <braunr> (if i'm right)
-    <ArneBab> …and so on, till noot starts the first
-    <ArneBab> root
-    <braunr> ?
-    <ArneBab> root starts /, right?
-    <braunr> no
-    <braunr> gnumach starts /
-    <ArneBab> ah, right
-    <braunr> gnumach starts somefs.static
-    <braunr> which attaches at /
-    <braunr> and runs with root privileges
-    <braunr> keep in mind that unix permissions are implemented as capabilities
-      on the hurd
-    <ArneBab> → root has it / it’s root
-    <braunr> the rights you have aren't limited to those permissions
-    <ArneBab> jepp
-    <braunr> and it's not "until"
-    <ArneBab> so why should I not access a translator run by someone else? I
-      just don’t want to do any active command (recurse)… hm… can a translator
-      turn a read request into a write?
-    <braunr> that's the only problem
-    <ArneBab> program with my rights wants to read, but the translator makes it
-      write instead?
-    <braunr> no
-    <braunr> a translator can do pretty much anything with your request
-    <ArneBab> with my rights?
-    <braunr> no
-    <braunr> the most obvious example of DoS is simply not answering
-    <braunr> your process hangs
-    <braunr> considering some file system accesses, a translator could return
-      inconsistent data
-    <ArneBab> so if the translator tries to make me write instead of read, it
-      can do so only when the owner of the translaton can write to the file in
-      question?
-    <braunr> a well written application shouldn't have too much trouble dealing
-      with it but some aren't that well written
-    <braunr> this has *nothing* to do with read/write permissions
-    <braunr> you should read the critique :p
-
-[[hurd/critique]]
-
-    <ArneBab> ln -s /home/you /home/me → “why don’t you look into my home?”
-    <ArneBab> read it again, that is :)
-    <ArneBab> (has been some time since I read it)
-    <antrik> braunr: you just described the auth mechanism ;-)
-    <antrik> ArneBab: symlinks can do considerably less than translators; and
-      even these caused a lot of trouble when introduced (and still cause
-      sometimes)
-    <antrik> we can't make every application aware of translators
-    <antrik> indeed I believe we can a avoid many problems by presenting
-      various translators as symlinks -- but this is not approriate for all
-      translators
-    <antrik> it is something the translator itself decides, so it's not helpful
-      to solve security issues at all
-    <antrik> and as braunr already pointed out, this wouldn't help with DoS
-      problems
-
-
-# Linux kernel, Symlink/Hardlink Attack
-
-Even though not directly comparable, the issues described at [Symlink
-Protection](https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Symlink_Protection)
-and [Hardlink
-Protection](https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Hardlink_Protection)
-do bear some similarity with the issue we're discussing here.
-
-Likewise, Kees Cook, [fs: symlink restrictions on sticky
-directories](http://lwn.net/Articles/468215/), 2011-11-18.  [2011-12-06
-update](http://lwn.net/Articles/470891/).  Jake Edge, [Fixing the symlink race
-problem](http://lwn.net/Articles/472071/), 2011-12-14.
-
-
-# IRC, freenode, #hurd, 2011-08-31
-
-    <antrik> I don't see any problems with following only translators of
-      trusted users
-    <youpi> where to store the list of trusted users?
-    <youpi> is there a way to access the underlying node, which for /dev
-      entries belongs to root?
-    <ArneBab> youpi: why a list of trusted users? Does it not suffice to
-      require /hurd/trust set by root or ourselves?
-    <youpi> ArneBab: just because that's what antrik suggests, so I ask him for
-      more details
-    <ArneBab> ah, ok
-    <antrik> youpi: probably make them members of a group
-    <antrik> of course that doesn't allow normal users to add their own trusted
-      users... but that's not the only limitation of the user-based
-      authentication mechanism, so I wouldn't consider that an extra problem
-    <antrik> ArneBab: we can't set a translator on top of another user's
-      translator in general
-    <antrik> root could, but that's not very flexible...
-    <antrik> the group-based solution seems more useful to me
-    <ArneBab> antrik: why can’t we?
-    <antrik> also note that you can't set passive translators on top of other
-      translators
-    <antrik> ArneBab: because we can only set translators on our own nodes
-    <ArneBab> active ones, too?
-    <antrik> yes
-    <ArneBab> antrik: I always thought I could…
-    <ArneBab> but did not test it
-    <ArneBab> antrik: so I need a subhurd to change nodes which do not belong
-      to me?
-    * ArneBab in that case finally understands why you like subhurds so much:
-        That should be my normal right
-    <antrik> it should be your normal right to change stuff not belonging to
-      you? that's an odd world view :-)
-    <antrik> subhurds don't really have anything to do with it
-    <ArneBab> change it in a way that only I see the changes
-    <antrik> you need local namespaces to allow making local modifications to
-      global resources
-    <youpi> it should be one's normal right to change the view one has of it
-    <antrik> we discussed that once actually I believe...
-    <antrik> err... private namespaces I mean
-
-IRC, freenode, #hurd, 2011-09-10:
-
-    <cjuner_> I am rereading Neal Walfield's and Marcus Brinkman's critique of
-      the hurd on mach. One of the arguments is that a file system may be
-      malicious (by DoS its clients with infinitely deep directory
-      hierarchies). Is there an answer to that that does not require programs
-      to be programmed defensively against such possibilities?
-
-IRC, freenode, #hurd, 2011-09-14:
-
-    <antrik> cjuner: regarding malicious filesystems: the answer is to do
-      exactly the same as FUSE on Linux: don't follow translators set up by
-      untrusted users by default
-    <cjuner> antrik, but are legacy programs somehow protected? What about
-      executing `find`? Or is GNU's find somehow protected from that?
-    <antrik> cjuner: I'm talking about a global policy
-    <cjuner> antrik, and who would implement that policy?
-    <antrik> cjuner: either glibc or the parent translators
-
-Continued discussion about [[resource_management_problems/pagers]].
-
-
-# IRC, freenode, #hurd, 2013-02-24
-
-    <braunr> on a more general topic, i've been thinking about client and
-      server trust
-    <braunr> there have been many talkbs about it regarding l4/coyotos/hurdng
-    <youpi> I generally think the client can trust the server
-    <braunr> and passing the select timeout to servers corroborates this
-    <youpi> because it's either root, or it's the same user
-    <braunr> hum yes, but that's not exactly my question, you'll see
-    <braunr> there is one feature the hurd has, and i'm not sure we should have
-      it considering what it requires
-    <braunr> the feature is that clients can, at any time, "break" from a
-      server
-    <youpi> "break" ?
-    <braunr> the current implementation is to cancel the current RPC after 3
-      seconds without a reply when the user sends SIGINT
-    <braunr> the problem is that, moving to a complete migrating thread model
-      would make that impossible (or very complicated to do right)
-
-[[mach_migrating_threads]].
-
-    <braunr> would it be ok to remove this feature ?
-    <youpi> well, we need to have SIGINT working, don't we?
-    <braunr> obviously
-    <braunr> but that's not what the feature is meant to do
-    <braunr> it allows clients to recover from a server that misbehaves and
-      doesn't return
-    <youpi> then I don't understand in enough details what you mean :)
-    <braunr> imagine a buggy driver in linux that gets into an uninterruptible
-      sleep
-    <braunr> you can't even kill your process
-    <braunr> that's what the feature is meant to solve
-    <youpi> that's a quite useful thing
-    <youpi> e.g. stuck nfs etc., it's useful to be able to recover from that
-    <braunr> forbidding uninterruptible sleeps would also be a solution, but
-      then it means relying on servers acting right
-    <braunr> which is why i mention we usually trust servers
-    <youpi> well, there is "trust" and "trust" :)
-    <youpi> i.e. security-wise and robustness-wise
-    <youpi> I meant clients can usually trust servers security-wise
-    <braunr> my current idea for x15 is to forbid this kind of breaking, but
-      also forbid uninterruptible sleeps
-    <youpi> robustness-wise, I'd say no
-    <braunr> this way, sending a signal directly reaches the server, which is
-      trusted to return right away (well, conforming to the handling behaviour)
-    <braunr> so yes, buggy servers would prevent that, but on the other hand,
-      stuck nfs wouldn't
-    <youpi> provided the nfs implementation is not bogus
-    <braunr> yes
-    <youpi> I'd tend to agree, but would rather see this discussed on the list
-    <braunr> yes
-    <braunr> actually, it wouldn't be that hard to keep the current behaviour,
-      since i won't implement true migrating threads
-    <braunr> but it means retaining some issues we have (most importantely,
-      denial of service)
-    <braunr> -e
-    <braunr> what i want to avoid is
-      http://www.gnu.org/software/hurd/hurd/ng/cancellationforwarding.html
-    <youpi> for non-trusted servers, we could have a safety wrapper
-    <youpi> which we trust and does things carefully when talking with the
-      non-trusted server
-    <braunr> what would a non trusted server be ?
-    <youpi> whatever is neither root nor me
-    <youpi> e.g. nobody-provided /ftp:, or $HOME of another user, etc.
-    <braunr> i'd argue we don't talk to non trusted servers at all, period
-    <youpi> users won't like it :)
-    <braunr> and i'd extend root to a system provided list
-    <youpi> actually the nobody /ftp: case is important
-    <braunr> users should be able to create their own list of trusted users
-    <youpi> it's also the nobody /dev/null case
-    <youpi> atm it's root
-    <braunr> yes
-    <braunr> i see the point
-    <braunr> i'm just saying the idea of "using non-trusted server" doesn't
-      make sense
-    <youpi> actually running /ftp: under nobody is dangerous
-    <youpi> since if you're running as nobody (because you broke into the
-      system or whatever), then you can poke with nobody-provided servers
-    <braunr> yes
-    <youpi> so we'd rather have really-nobody processes
-    <braunr> taht's an already existing problem
-    <youpi> which can't be poked into
-    <youpi> (and thus can't poke into each other)
-    <braunr> or a separate user for each
-    <youpi> that'd be difficult
-    <braunr> or separate tokens, it's not important
-    <youpi> for /ftp:/ftp.debian.org used by someone, and /ftp:/ftp.foo.org
-      used by someone else
-    <braunr> what i mean is that, by talking to a server, a client implicitely
-      trusts it
-    <braunr> youpi: wouldn't that just be the same "ftp" user ?
-    <youpi> ideally, a carefully-crafted client could avoid having to trust it
-    <braunr> really ?
-    <youpi> braunr: that's the problem: then each ftpfs can poke on each other
-    <braunr> well, each global one
-    <youpi> there's the daemon-sharing issue too, yes
-    <braunr> i wasn't thinking about ftpfs, but rather the "system" pfinet for
-      example
-    <youpi> like /dev/null is shared
-    <braunr> when you say root or me, it's "system" or me
-    <braunr> by default, users trust their system
-    <braunr> they don't trust other users
-    <youpi> avoid having to trust it: yes, by using timeouts etc.
-    <braunr> that's clearly not enough
-    <youpi> why?
-    <braunr> shapiro described this in a mail but i can't find it right now
-    <youpi> I wouldn't like to have to trust ftpfs
-    <braunr> well time is one thing, data provided for example is another
-    <braunr> well, you do
-    <youpi> who knows what bug ftpfs has
-    <youpi> ideally I would be able not to have to
-    <youpi> braunr: you can check data
-    <braunr> i don't think that ideal is possible
-    <braunr> it you set a ftp translator with a user account, you give it the
-      password
-    <youpi> which password?
-    <braunr> the account password
-    <youpi> which account?
-    <braunr> "a user account"
-    <braunr> i.e. not anonymoius
-    <youpi> ah
-    <youpi> well, sure, you have to give that to ftpfs
-    <youpi> I mean the ftp server might be malicious or whatever
-    <youpi> and trigger a bug in ftpfs
-    <braunr> yes
-    <youpi> so I don't want to have to trust ftpfs
-    <braunr> what would that mean in practice ?
-    <youpi> have a trusted translation layer which papers over it, checking
-      timeouts & data
-    <braunr> how do you check data ?
-    <youpi> by knowing the protocol
-    <braunr> ?
-    <braunr> can you give a quick example ?
-    <youpi> well, which data check do you need?
-    <youpi> (it's you who mentioned data issues :) )
-    <braunr> i don't know what you mean by that so, choose as you see fit
-    <braunr> well the password one for example
-    <braunr> i was merely saying that, buy using an application, be it a
-      regular one or a translator, you automatically trust it
-    <youpi> you mean the ftp user password ?
-    <braunr> it becomes part of your tcb
-    <youpi> of course you have to provide it to ftpfs
-    <youpi> that's not a problem
-    <youpi> yes, but it's not because you connect to an http website that you
-      trust the webserver on the other end
-    <youpi> your web browser does checking for you
-    <braunr> when the protocol allows it
-    <braunr> (in this case, i'm thinking assymmetrical cryptography)
-    <youpi> in which case example doesn't it ?
-    <youpi> it seems we're not talking about the same kind of issue, thus not
-      understanding each other
-    <braunr> indeed
-    <youpi> by "trusting", I don't mean "be sure that it's the right server at
-      the other end"
-    <braunr> my point is that not trusting a server is impossible
-    <youpi> I mean "it behaves correectly"
-    <braunr> yes
-    <braunr> it may not behave correctly, and we might not know it
-    <youpi> as long as it doesn't make the program crash, that's fine
-    <youpi> that's what I mean
-    <braunr> that's where the difference is
-    <youpi> but giving the password is not my concern here
-    <youpi> and giving the password is a matter of cryptography, etc.  yes, but
-      that's completely not my point
-    <braunr> i'm concerned about absolute correct behaviour 
-    <braunr> hm
-    <braunr> no actually i was
-    <braunr> but not any more, the discussion has shifted back to the timeout
-      issue
-    <braunr> ah no, i remember
-    <braunr> we talked about which servers to trust
-    <braunr> and how to alter communication accordingly
-    <braunr> and my point was that altering communication shouldn't be done, we
-      either trust the server, and talk to it, or we don't, and we stay away
-    <braunr> the wrapper would help for this specific blocking issue, yes
-    <youpi> I don't agree on this
-    <youpi> let me take a way more simple example
-    <youpi> a server that provides data through io_read
-    <youpi> I don't want to trust it because it's provided by some joe user
-    <youpi> but I still want to have a look at the data that it produces
-    <youpi> I'm fine that the data may be completely non-sense, that's not a
-      problem
-    <youpi> what is a problem, however, is if the hexdump program I've run over
-      it can't be ^C-ed
-    <braunr> yes, that's the specific issue i mentioned
-    <youpi> and for that, a mere trusted intermediate could be enough
-    <braunr> iirc, there is a firmlink-related issue 
-    <youpi> ?
-    <braunr>
-      http://www.gnu.org/software/hurd/open_issues/translators_set_up_by_untrusted_users.html
-    <youpi> I'm not able to guess what conclusion you are drawing here :)
-    <braunr> don't talk to untrusted servers
-    <youpi> or be careful
-    <youpi> the rm -fr /tmp being aabout being careful actually
-    <braunr> right
-    <braunr> i have a very unix-centric view for my system actually
-    <braunr> i think posix compatibility is very important for me
-    <braunr> more than it seems to have been in the past when the hurd was
-      designed
-    <braunr> to* me
-    <braunr> so i don't trust tools to be careful
-    <youpi> that's why a wrapping translator could make it back to posix
-      compatibility
-    <braunr> but i see what you mean
-    <youpi> being careful for the tools
-    <braunr> hum, a wrapping _translator_ ?
-    <youpi> yes, similar to remap and fakeroot
-
-[[virtualization/remap_root_translator]], [[virtualization/fakeroot]].
-
-    <braunr> ok
-    <youpi> you'd tell it "for this path, please be careful for my tools"
-    <braunr> ok so
-    <braunr> it would basically still end up trusting system or me
-    <braunr> but you'd add this wrapper to the system
-    <youpi> "it" ?
-    <braunr> the situation
-    <braunr> i don't know :)
-    <braunr> the implementation, whatever
-    <youpi> the shell I'm running, you mean
-    <braunr> and it would be the job of this translator to shield the user
-    <youpi> yes
-    <braunr> that's a good idea, yes
-    <youpi> it could reduce the allowed RPC set to what it knows to check
-    <braunr> how would the shell use it ?
-    <braunr> would it "shadow" / ?
-    <youpi> yes
-    <braunr> ok
diff --git a/open_issues/trust_the_behavior_of_translators.mdwn b/open_issues/trust_the_behavior_of_translators.mdwn
deleted file mode 100644
index 454c638b..00000000
--- a/open_issues/trust_the_behavior_of_translators.mdwn
+++ /dev/null
@@ -1,181 +0,0 @@
-[[!meta copyright="Copyright © 2012 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_hurd]]
-
-Apart from the issue of [[translators_set_up_by_untrusted_users]], here is
-another problem described.
-
-
-# IRC, freenode, #hurd, 2012-02-17
-
-(Preceded by the [[memory_object_model_vs_block-level_cache]] discussion.)
-
-    <slpz> what should do Mach with a translator that doesn't clean pages in a
-      reasonable amount of time?
-    <slpz> (I'm talking about pages flushed to a pager by the pageout daemon)
-    <braunr> slpz: i don't know what it should do, but currently, it uses the
-      default pager
-
-[[default_pager]].
-
-    <slpz> braunr: I know, but I was thinking about an alternative, for the
-      case in which a translator in not behaving properly
-    <slpz> perhaps freeing the page, removing the map, and letting it die in a
-      segmentation fault could be an option
-    <braunr> slpz: what if the translator can't do it properly because of
-      system resource exhaustion ?
-    <braunr> (i.e. it doesn't have enough cpu time)
-    <slpz> braunr: that's the biggest question
-    <slpz> let's suppose that Mach selects a page, sends it to the pager for
-      cleaning it up, reinjects the page into the active queue, and later it
-      founds the page again and it's still dirty
-    <slpz> but it needs to free some pages because memory it's really, really
-      scarce
-    <slpz> Linux just sits there waiting for I/O completion for that page
-      (trusts its own drivers)
-    <slpz> but we could be dealing with rogue translator...
-    <braunr> yes
-    <braunr> we may need some sort of "authentication" mechanism for pagers
-    <braunr> so that "system pagers" are trusted and others not
-    <braunr> using something like the device master port but for pagers
-    <braunr> a special port passed to trusted pagers only
-    <slpz> hum... that could be used to workaround the untrusted translator
-      crossing problem while walking a directory tree
-
-[[translators_set_up_by_untrusted_users]].
-
-    <slpz> but I think differentiating between trusted and untrusted
-      translators was rejected for philosophical reasons
-    <slpz> (but I'm not sure)
-    <mcsim> slpz: probably there should be something like oom killer?
-    <mcsim> braunr: even if translator is trusted it could have a bug which
-      make it ask more and more memory, so system have something to do with
-      it. Also, this way TCB is increased, so providing port for trusted
-      translators may hurt security.
-    <mcsim> I've read that Genode has "guarded allocators" which help resource
-      accounting by limiting of memory that could be used. Probably something
-      like this could be used in Hurd to limit translators.
-    <antrik> I don't remember how Viengoos deals with this :-(
-
-[[microkernel/Viengoos]].
-
-    <braunr> mcsim: the main feature lacking in mach is resource accounting :p
-
-[[resource_management_problems]].
-
-    <slpz> mcsim: yes, I think there should be a Hurdish oom killer, paying
-      special attention to external pagers
-
-[[microkernel/mach/external_pager_mechanism]].
-
-    <braunr> the oom killer selects untrusted processes by definition (since
-      pagers are in kernel)
-    <mcsim> slpz: and what is better: oom killer or resource accounting?
-    <mcsim> Under resource accounting I mean mechanism when process can't get
-      more resources than it is allowed.
-    <braunr> resource accounting of course
-    <braunr> but it's not just about that
-    <braunr> really, how does the kernel deal when a pager refuses to honor a
-      paging request ?
-    <braunr> whether it is buggy or malicious
-    <braunr> is it really possible to keep all pagers out of the TCB ?
-    <antrik> mcsim: we definitely want proper resource accounting in the long
-      run. the question is how to deal with the situation that resources are
-      reallocated to other tasks, so some pages have to be freed
-    <antrik> I really don't remember how Neal proposed to deal with this
-    <slpz> mcsim: Better: resource accounting (in which resources are accounted
-      to the user tasks which are requesting them, as in the Viengoos
-      model). Good enough an realistic: oom killer
-    <antrik> I'm not sure an OOM killer for non-system pagers is terribly
-      helpful. in typical use, the vast majority of paging is done by trusted
-      pagers...
-    <antrik> and without proper client resource accounting, there are enough
-      other ways a rogue/broken process can eat system resources -- I'm not
-      convinced that untrusted pagers have a major impact on the overall
-      situation
-    <mcsim> If pager can't free resources because of lack, for example, of cpu
-      time it's priority could be increased to give it second chance to free
-      the page. But if it doesn't manage to free resources it could be killed.
-    <antrik> I think the current approach with default pager taking over is
-      good enough for dealing with untrusted pagers. the real problem are even
-      trusted pager frequently failing to deal with the requests
-    <braunr> i agree with antrik
-    <braunr> and i'm opposed to an oom killer
-    <braunr> it's really not a proper fix for our problems
-    <braunr> mcsim: what if needs 3 attempts before succeeding ?
-    <braunr> +it
-    <braunr> and increasing priority without a good reason (e.g. no priority
-      inversion) leads to unfairness
-    <braunr> we don't want to deal with tricky problems like malicious pagers
-      using that to starve other tasks
-    <mcsim> braunr: this is just temporary decision (for example for half of
-      second of user time), to increase probability that task was killed not
-      because of it lacked resources.
-    <braunr> mcsim: tunables should only affect the efficiency of an operation,
-      not its success
-
-
-## IRC, freenode, #hurd, 2012-02-19
-
-    <antrik> neal: the specific question is how to ensure processes free memory
-      fast enough when their allocation becomes lower due to resource pressure
-    <neal> antrik: you can't really.
-    <neal> antrik: the memory manager can act on the application's behalf if
-      the application marks pages as discardable or pagable.
-    <neal> antrik: if the memory manager makes an upcall to the application to
-      free some memory and it doesn't, you have to penalize it.
-    <neal> antrik: You shouldn't the process like exokernel
-    <neal> antrik: It's the developers fault, not the user's
-    <neal> antrik: What you need are controls that ensure that the user stays
-      in control
-    <neal> ...shouldn't *kill* the process...
-    <antrik> neal: well, how can I penalize a process that eats to much
-      physical memory?
-    <neal> in the future, you don't give it as much slack memory
-    <antrik> marking as pagable means a system pager will push them to the swap
-      partition?
-    <antrik> ah, OK
-    <neal> yes
-    <neal> and you page it more aggressively, i.e., you don't give it a chance
-      to free memory
-    <neal> The situation is:
-    <neal> you have memory pressure
-    <neal> you choose a victim process and ask it to free memory
-    <neal> now, you need to wait
-    <neal> if you wait and it doesn't free memory, you give it bad karma
-    <neal> if you wait and it frees memory, you're good
-    <neal> but during that window, a bad process can delay recovery
-    <neal> so, in the future, we give bad processes less time
-    <neal> but, we still send a message asking it to free memory
-    <neal> we just hope it was a bug
-    <antrik> so the major difference to the approach we have in Mach is that
-      instead of just redeclaring some pages as anonymous memory that will be
-      paged to swap by the default pager eventually if the pager in question
-      fails to handle them properly, we wait some time for the process to free
-      (any) memory, and only then start paging out some of it's pages to swap
-    <neal> there's also discardable memory
-    <antrik> hm... there is some notion of "precious" pages in Mach... I wonder
-      whether that is also used to decide about discarding pages instead of
-      pushing them to swap?
-    <neal> antrik: A precious page is ro data that shouldn't be dropped
-    <antrik> ah
-    <antrik> but I guess that means non-precious RO data (such as a cache) can
-      be dropped without asking the pager, right?
-    <neal> yes
-    <antrik> I wonder whether such a karma system can be introduced in Mach as
-      well to deal with problematic pagers
-
-
-## IRC, freenode, #hurd, 2012-02-21
-
-    <neal> antrik: One of the main differences between Mach and Viengoos is
-      that in Mach servers are responsible for managing memory whereas in
-      Viengoos applications are primarily responsible for managing memory.
diff --git a/open_issues/tty_activitiy_vs_disk_io.mdwn b/open_issues/tty_activitiy_vs_disk_io.mdwn
deleted file mode 100644
index 26382d56..00000000
--- a/open_issues/tty_activitiy_vs_disk_io.mdwn
+++ /dev/null
@@ -1,81 +0,0 @@
-[[!meta copyright="Copyright © 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_hurd]]
-
-IRC, freenode, #hurd, 2011-07-25
-
-    < youpi> Mmm, typing something on the mach console triggers a write on the
-      disk
-    < youpi> because the /dev/console node gets updated
-    < youpi> I don't really see why
-    < youpi> (yes, just typing at the bash prompt, not even running something)
-    < youpi> typing during the sleep command (i.e. mere tty echo) doesn't
-      trigger it, however
-    < youpi> running bash's echo does trigger it
-    < braunr> during sleep, the glibc stream functions handle I/O, while with
-      bash, its readline takes care of it, right ?
-    < youpi>  /bin/echo too
-    < youpi> during sleep it's the tty process which handles I/O
-    < braunr> the write may be due to a write time update on the inode
-    < braunr> modification* time
-    < youpi> probably yes, but how so?
-    < youpi> ext2fs is only supposed to pass the thing to the console
-      translator
-    < braunr> not sure
-    < youpi> actually, ext2fs even isn't supposed to come into play when it's
-      about typing at the bash prompt
-    < youpi> once it's opened, isn't the port for /dev/console supposed to be
-      directly to the translator there?
-    < braunr> i think so
-    < youpi> (s/tty/term/ in what I said)
-    < braunr> well, it's certain
-    < youpi> so I don't see how ext2fs can be triggered to write an atime or
-      mtime
-    < braunr> what does rpctrace say ?
-    < youpi> io_read_request and io_write_request
-    < youpi> braunr: it doesn't happen at the login prompt
-    < youpi> interestingly, atime is always 3-4 secs earlier than ctime & mtime
-    < youpi> doesn't happen with dash
-    < braunr> we should implement relatime and experiment with it
-    < braunr> it shouldn't be hard
-    < youpi> well, there's noatime already
-    < youpi> but my point is that this update shouldn't happen
-    < youpi> and I believe it's the source of the i_file_acl e2fsck warning
-    < braunr> i wasn't saying that concerning this problem, it was just a
-      separate idea (noatime is more problematic than relatime)
-    < braunr> and i agree, it shouldn't happen :)
-    < youpi> ok, it's set_node_times which gets called
-
-IRC, freenode, #hurd, 2011-07-27
-
-    < antrik> BTW, I'm not sure it's still relevant; but the reason accessing
-      translators such as the console modifies the underlying node is that most
-      stat information is generally passed through
-    < antrik> (in some cases it might be unintentional though, simply using the
-      default implementation from trivfs carelessly...)
-    < youpi> I know
-    < youpi> I've seen that in the code
-    < antrik> OK
-    < youpi> it is still relevant: I still find it useless to write it on the
-      disk
-    < youpi> though w uses it to show idle time over reboot
-    < braunr> is it useful to keep the information across reboots ?
-    < youpi> for some value of "useful" for w
-    < braunr> i wonder what would break if this was entierly kept in memory
-    < youpi> nothing, probably
-    < youpi> note that it doesn't overload ext2fs so much, it just adds a write
-      every ~5s
-    < youpi> (at worse, i.e. when keeping showing text, for instance)
-    < braunr> indeed, the behaviour seems the same on linux
-    < antrik> ah... that explains why the disk doesn't spin down while IRC is
-      active... always wondered about that :-)
-    < youpi> that's not very power-saving, yes
-    < youpi> well, we might want to put /dev on ram someday
diff --git a/open_issues/unit_testing.mdwn b/open_issues/unit_testing.mdwn
deleted file mode 100644
index dd1e465c..00000000
--- a/open_issues/unit_testing.mdwn
+++ /dev/null
@@ -1,94 +0,0 @@
-[[!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]]."]]"""]]
-
-This task may be suitable for [[community/GSoC]]:
-[[community/gsoc/project_ideas/testing_framework]]
-
----
-
-A collection of thoughts with respect to unit testing.
-
-We definitely want to add unit test suites to our code base.
-
-We should select a tool that we like to use, and that is supported (not
-abandoned).
-
-  * [SC
-    Test](http://web.archive.org/web/20021204193607/sc-archive.codesourcery.com/sc_test)
-
-  * [DejaGnu](http://www.gnu.org/software/dejagnu/) /
-    [Expect](http://expect.nist.gov/)
-
-      * used by the [[GCC testsuite|gcc]], [[GDB testsuite|gdb]],
-        [[binutils testsuite|binutils]], etc.
-
-  * The [[glibc testsuite|glibc]] has a home-grown system (Makefile-based),
-    likewise does the [[Open_POSIX_Test_Suite]].
-
-  * [Kyua](http://code.google.com/p/kyua/) (and its predecessor [ATF](http://www.NetBSD.org/~jmmv/atf/)).
-
-    * Primarily used by NetBSD as its testing framework; FreeBSD is in the process of adopting it.
-
-    * Provides bindings to write tests in C, C++ and POSIX shell. Lua is planned.
-
-    * Builds and runs on many different Unix-based operating systems.
-
-  * [check](http://check.sourceforge.net/)
-
-      * used by some GNU packages, for example GNU PDF (Jose E. Marchesi)
-
-  * CodeSourcery's [QMTest](http://www.codesourcery.com/qmtest)
-
-      * useb by?
-
-      * documentation:
-
-          * <http://www.codesourcery.com/public/qmtest/whitepaper.pdf>
-
-          * <http://www.python.org/workshops/2002-02/papers/01/index.htm>
-
-          * <http://gcc.gnu.org/ml/gcc/2002-05/msg01978.html>
-
-          * <http://www.codesourcery.com/public/qmtest/qmtest-snapshot/share/doc/qmtest/html/tutorial/index.html>
-
-          * <http://www.codesourcery.com/public/qmtest/qmtest-snapshot/share/doc/qmtest/html/manual/index.html>
-
-  * [Git](http://git-scm.com/) has an elaborate unit testsuite, which is also
-    used in [Notmuch](http://notmuchmail.org/).
-
-  * [*[ANNOUNCE] ktest.pl: Easy and flexible testing script for Linux Kernel
-    Developers*](http://lwn.net/Articles/412302/) by Steven Rostedt,
-    2010-10-28.  [v2](http://lwn.net/Articles/414064/), 2010-11-08.
-
-  * <http://autotest.kernel.org/wiki/WhitePaper>
-
-
-# Related
-
-  * [[nightly_builds]]
-
-      * [[nightly_builds_deb_packages]]
-
-  * <http://www.phoronix-test-suite.com/> -- ``comprehensive testing and
-    benchmarking platform''.  This one might be useful for [[performance]]
-    testing, too?
-
-  * <http://ltp.sourceforge.net/>
-
-  * [LaBrea](https://github.com/dustin/labrea/wiki), or similar tools can be
-    used for modelling certain aspects of system behavior (long response times,
-    for example).
-
-
-# Discussion
-
-See the [[GSoC project idea|community/gsoc/project_ideas/testing_framework]]'s
-[[discussion
-subpage|community/gsoc/project_ideas/testing_framework/discussion]].
diff --git a/open_issues/user-space_device_drivers.mdwn b/open_issues/user-space_device_drivers.mdwn
deleted file mode 100644
index 69ec1d23..00000000
--- a/open_issues/user-space_device_drivers.mdwn
+++ /dev/null
@@ -1,1148 +0,0 @@
-[[!meta copyright="Copyright © 2009, 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_gnumach open_issue_hurd]]
-
-This is a collection of resources concerning *user-space device drivers*.
-
-Also see [[device drivers and IO systems]].
-[[community/gsoc/project ideas/driver glue code]].
-
-[[!toc levels=2]]
-
-
-# Open Issues
-
-## IRQs
-
-  * Can be modeled using [[RPC]]s.
-
-  * Security considerations: IRQ sharing.
-
-  * *Omega0* paper defines an interface.
-
-  * As is can be read in the *Mach 3 Kernel Principles*, there is an *event
-    object* facility in Mach that can be used for having user-space tasks react
-    to IRQs.  However, at least in GNU Mach, that code (`kern/eventcount.c`)
-    doesn't seem functional at all and isn't integrated properly in the kernel.
-
-  * IRC, freenode, #hurd, 2011-07-29
-
-        < antrik> regarding performance of userspace drivers, there is one
-          thing that really adds considerable overhead: interrupt
-          handling. whether this is relevant very much depends on the hardware
-          in question. when sending many small packets over gigabit ethernet,
-          it might be noticable; in most other cases it's irrelevant
-        < youpi> some cards support interrupt coalescin
-        < youpi> could be supported by DDE too
-
-## DMA
-
-  * Security considerations.
-
-      * I/O MMU.
-
-
-### IRC, freenode, #hurd, 2012-08-15
-
-    <carli2> hi. does hurd support mesa?
-    <braunr> carli2: software only, but yes
-    <carli2> :(
-    <carli2> so you did not solve the problem with the CS checkers and GPU DMA
-      for microkernels yet, right?
-    <braunr> cs = ?
-    <carli2> control stream
-    <carli2> the data sent to the gpu
-    <braunr> no
-    <braunr> and to be honest we're not currently trying to
-    <carli2> well, a microkernel containing cs checkers for each hardware is
-      not a microkernel any more
-    <braunr> the problem is having the ability to check
-    <braunr> or rather, giving only what's necessary to delegate checking to
-      mmus
-    <carli2> but maybe the kernel could have a smaller interface like a
-      function to check if a memory block is owned by a process
-    <braunr> i'm not sure what you refer to
-    <carli2> about DMA-capable devices you can send messages to
-    <braunr> carli2: dma must be delegated to a trusted server
-    <carli2> linux checks the data sent to these devices, parses them and
-      checks all pointers if they are in a memory range that the client is
-      allowed to read/write from
-    <braunr> the client ?
-    <carli2> in linux, 3d drivers are in user space, so the kernel side checks
-      the pointer sent to the GPU
-    <youpi> carli2: mach could do that as well
-    <braunr> well, there is a rather large part in kernel space too
-    <carli2> so in hurd I trust some drivers to not do evil things?
-    <braunr> those in the kernel yes
-    <carli2> what does "in the kernel" mean? afaik a microkernel only has
-      memory manager and some basic memory sharing and messaging functionality
-    <braunr> did you read about the hurd ?
-    <braunr> mach is considered an hybrid kernel, not a true microkernel
-    <braunr> even with all drivers outside, it's still an hybrid
-    <youpi> although we're to move some parts into userlands :)
-    <youpi> braunr: ah, why?
-    <braunr> youpi: the vm part is too large
-    <youpi> ok
-    <braunr> the microkernel dogma is no policy inside the kernel
-    <braunr> "except scheduling because it's very complicated"
-    <braunr> but all modern systems have moved memory management outisde the
-      kernel, leaving just the kernel abstraction inside
-    <braunr> the adress space kernel abstraction
-    <braunr> and the two components required to make it work are what l4re
-      calls region mappers (the rough equivalent of our vm_map), which decides
-      how to allocate regions in an address space
-    <braunr> and the pager, like ours, which are already external
-    <carli2> i'm not a OS developer, i mostly develop games, web services and
-      sometimes I fix gpu drivers
-    <braunr> that was just FYI
-    <braunr> but yes, dma must be considered something privileged
-    <braunr> and the hurd doesn't have the infrastructure you seem to be
-      looking for
-
-
-## I/O Ports
-
-  * Security considerations.
-
-## PCI and other buses
-
-  * Security considerations: sharing.
-
-## Latency of doing RPCs
-
-  * [[GNU Mach|microkernel/mach/gnumach]] is said to have a high overhead when
-    doing RPC calls.
-
-
-## System Boot
-
-A similar problem is described in
-[[community/gsoc/project_ideas/unionfs_boot]], and needs to be implemented.
-
-
-### IRC, freenode, #hurd, 2011-07-27
-
-    < braunr> btw, was there any formulation of the modifications required to
-      have disk drivers in userspace ?
-    < braunr> (which would obviously need something like
-      initrd/initramfs/whatever and may also need the root file system not to
-      be the first task started)
-    < braunr> hm actually, we may not need initrd
-    < braunr> the boot loader could just load more modules
-    < antrik> braunr: I have described all that in my thesis report... in
-      German :-(
-    < braunr> and the boot scripts could be adjusted to pass around the right
-      ports
-    < Tekk_> braunr: yeah, we could probably load a module that kciks us into
-      userspace and starts the disk driver
-    < braunr> modules are actualy userspace executables
-    < Tekk_> ah
-    < Tekk_> so what's the issue?
-    < Tekk_> oh! I'm thinking the ext2fs server, which is already in userspce
-    < braunr> change the file systems to tell them which underlying disk driver
-      to use
-    < Tekk_> mhm
-    < braunr> s/disk/storage/
-
-
-#### IRC, freenode, #hurd, 2012-04-25
-
-    <youpi> btw, remember the initrd thing?
-    <youpi> I just came across task.c in libstore/ :)
-
-
-#### IRC, freenode, #hurd, 2013-06-24
-
-    <youpi> we added a new initrd command to gnumach, to expose a new mach
-      device, which ext2fs can open and unzip
-    <youpi> we consider replacing that with simply putting the data in a dead
-      process
-    <youpi> s/process/task
-    <youpi> and let ext2fs read data from the task, and kill it when done
-    <teythoon> ok
-    <youpi> alternatively, tmps would work with an initial .tar.gz payload
-    <youpi> that would be best for memory usage
-    <youpi> tmpfs*
-    <teythoon> can't we replace the initrd concept with sub/neighbourhood?
-    <youpi> setting up tmpfs with an initial payload could be done with a
-      bootstrap subhurd
-    <teythoon> yes
-    <youpi> but it seems to me that having tmpfs being able to have an initial
-      payload is interesting
-    <teythoon> is there any advantage of the tmpfs translator prefilled with a
-      tarball over ext2fs with copy & bunzip?
-    <youpi> memory usage
-    <youpi> ext2fs with copy&bunzip takes memory for zeroes
-    <youpi> and we have to forecast how much data might be stored
-    <youpi> (if writable)
-    <teythoon> ah sure
-    <teythoon> but why would it have to be in the tmpfs translator? I why not
-      start the translator and have tar extract stuff there?
-    <teythoon> with the livecd I had trouble replacing the root translator, but
-      when using subhurds that shouldn't be a prwoblem at all
-    <youpi> I don't have a real opinion on this
-    <youpi> except that people don't usually like initrd :)
-    <braunr> 12:43 < teythoon> but why would it have to be in the tmpfs
-      translator? I why not start the translator and have tar extract stuff
-      there?
-    <braunr> that sounds an awful lot like an initramfs
-    <teythoon> yes, exactly, without actually having an initramfs of course
-    <braunr> yep
-    <braunr> i actually prefer that way too
-    <teythoon> a system on a r/o isofs cannot do much, but it can do this
-    <braunr> on the other hand, i wouldn't spend much time on a virtio disk
-      driver for now
-    <braunr> the hurd as it is can't boot on a device that isn't managed by the
-      kernel
-    <braunr> we'd need to change the boot protocol
-
-[[virtio]].
-
-
-#### IRC, freenode, #hurd, 2013-06-28
-
-    <teythoon> I'm tempted to redo a livecd, simpler and without the initrd
-      hack that youpi used for d-i
-    <braunr> initrd hack ?
-    <braunr> you mean more a la initramfs then ?
-    <teythoon> no, I thought about using a r/o isofs translator, but instead of
-      fixing that one up with a r/w overlay and lot's of firmlinks like I used
-      to, it would just start an ext2fs translator with copy on an image stored
-      on the iso and start a subhurd
-    <braunr> why a subhurd ?
-    <teythoon> neighbourhurd even
-    <teythoon> b/c back in the days I had trouble replacing /
-    <braunr> yes, that's hard
-    <teythoon> subhurd would take of that for free
-    <braunr> are you sure ?
-    <teythoon> somewhat
-    <braunr> i'm not, but this requires thorough thinking
-    <braunr> and i'm not there yet
-    <teythoon> y would it not?
-    <teythoon> just start a subhurd and let that one take over the console and
-      let the user and d-i play nicely in that environment
-    <teythoon> no hacks involved
-    <braunr> because it would require sharing things between the two system
-      instances, and that's not easy
-    <teythoon> no but the bootstrap system does nothing after launching the
-      subhurd
-    <teythoon> I mean yes, technically true, but why would it be hard to share
-      with someone who does nothing?
-    <braunr> the context isn't well defined enough to clearly state anything
-    <braunr> if you don't use the resources of the first hurd, that's ok
-    <braunr> otherwise, it may be easy or not, i don't know yet
-    <teythoon> you think it's worth a shot and see what issues crop up?
-    <braunr> sure
-    <braunr> definitely
-    <teythoon> it doesn't sound complicated at all
-    <braunr> it's easy enough to the point we see something goes wrong or works
-      completely
-    <braunr> so worth testin
-    <teythoon> cool :)
-
-
-#### IRC, freenode, #hurd, 2014-02-10
-
-    <teythoon> braunr: i have a question wrt memory allocation in gnumach
-    <teythoon> i made a live cd with a rather large ramdisk
-    <teythoon> it works fine in qemu, when i tried it on a real machine it
-      failed to allocate the buffer for the ramdisk
-    <teythoon> i was wondering why
-    <teythoon> i believe the function that failed was kmem_alloc trying to
-      allocate 64 megabytes
-    <braunr> teythoon: how much memory on the real machine ?
-    <teythoon> 4 gigs
-    <braunr> so 1.8G
-    <teythoon> yes
-    <braunr> does it fail systematically ?
-    <teythoon> but surely enough
-    <teythoon> uh, i must admit i only tried it once
-    <braunr> it's likely a 64M kernel allocation would fail
-    <braunr> the kmem_map is 128M wide iirc
-    <braunr> and likely fragmented
-    <braunr> it doesn't take much to prevent a 64M contiguous virtual area
-    <teythoon> i see
-    <braunr> i suggest you try my last gnumach patch
-    <teythoon> hm
-    <teythoon> surely there is a way to make this more robust, like using a
-      different map for the allocation ?
-    <braunr> the more you give to the kernel, the less you have for userspace
-    <braunr> merging maps together was actually a goal
-    <braunr> the kernel should never try to allocate such a large region
-    <braunr> can you trace the origin of the allocation request ?
-    <teythoon> i'm pretty sure it is for the ram disk
-    <braunr> makes sense but still, it's huge
-    <teythoon> well...
-    <braunr> the ram disk should behave as any other mapping, i.e. pages should
-      be mapped in on demand
-    <teythoon> right, so the implementation could be improved ?
-    <braunr> we need to understand why the kernel makes such big requests first
-    <teythoon> oh ? i thought i asked it to do so
-    <braunr> ?
-    <teythoon> for the ram disk
-    <braunr> normally, i would expect this to translate to the creation of a
-      64M anonymous memory vm object
-    <braunr> the kernel would then fill that object with zeroed pages on demand
-      (on page fault)
-    <braunr> at no time would there be a single 64M congituous kernel memory
-      allocation
-    <braunr> such big allocations are a sign of a serious bug
-    <braunr> for reference, linux (which is even more demanding because
-      physical memory is directly mapped in kernel space) allows at most 4M
-      contiguous blocks on most architectures
-    <braunr> on my systems, the largest kernel allocation is actually 128k
-    <braunr> and there are only two such allocations
-    <braunr> teythoon: i need you to reproduce it so we understand what happens
-      better
-    <teythoon> braunr: currently the ramdisk implementation kmem_allocs the
-      buffer in the kernel_map
-    <braunr> hum
-    <braunr> did you add this code ?
-    <teythoon> no
-    <braunr> where is it ?
-    <teythoon> debian/patches
-    <braunr> ugh
-    <teythoon> heh
-    <braunr> ok, don't expect that to scale
-    <braunr> it's a quick and dirty hack
-    <braunr> teythoon: why not use tmpfs ?
-    <teythoon> i use it as root filesystem
-    <braunr> :/
-    <braunr> ok so
-    <braunr> update on what i said before
-    <braunr> kmem_map is exclusively used for kernel object (slab) allocations
-    <braunr> kmem_map is a submap of kernel_map
-    <braunr> which is 192M on i386
-    <braunr> so a 64M allocation can't work at all
-    <braunr> it would work on xen, where the kernel map is 224M large
-    <braunr> teythoon: do you use xen ?
-    <teythoon> ok, thanks for the pointers :)
-    <teythoon> i don't use xen
-    <braunr> then i can't explain how it worked in your virtual machine
-    <braunr> unless the size was smaller
-    <teythoon> i'll look into improving the ramdisk patch if time permits
-    <teythoon> no it wasnt
-    <braunr> :/
-    <teythoon> and it works reliably in qemu
-    <braunr> that's very strange
-    <braunr> unless the kernel allocates nothing at all inside kernel_map on
-      qemu
-
-
-##### IRC, freenode, #hurd, 2014-02-11
-
-    <teythoon> braunr: http://paste.debian.net/81339/
-    <braunr> teythoon: oO ?
-    <braunr> teythoon: you can't allocate memory from a non kernel map
-    <braunr> what you're doing here is that you create a separate, non-kernel
-      address space, that overlaps kernel memory, and allocate from that area
-    <braunr> it's like having two overlapping heaps and allocating from them
-    <teythoon> braunr: i do?  o_O
-    <teythoon> so i need to map it instead ?
-    <braunr> teythoon: what do you want to do ?
-    <teythoon> i'm currently reading up on the vm system, any pointers ?
-    <braunr> teythoon: but what do you want to achieve here ?
-    <braunr> 12:24 < teythoon> so i need to map it instead ?
-    <teythoon> i'm trying to do what you said the other day, create a different
-      map to back the ramdisk
-    <braunr> no
-    <teythoon> no ?
-    <braunr> i said an object, not a map
-    <braunr> but it means a complete rework
-    <teythoon> ok
-    <teythoon> i'll head back into hurd-land then, though i'd love to see this
-      done properly
-    <braunr> teythoon: what you want basically is tmpfs as a rootfs right ?
-    <teythoon> sure
-    <teythoon> i'd need a way to populate it though
-    <braunr> how is it done currently ?
-    <teythoon> grub loads an ext2 image, then it's copied into the ramdisk
-      device, and used by the root translator
-    <braunr> how is it copied ?
-    <braunr> what makes use of the kernel ramdisk ?
-    <teythoon> in ramdisk_create, currently via memcpy
-    <teythoon> the ext2fs translator that provides /
-    <braunr> ah so it's a kernel device like hd0 ?
-    <teythoon> yes
-    <braunr> hm ok
-    <braunr> then you could create an anonymous memory object in the kernel,
-      and map read/write requests to object operations
-    <braunr> the object must not be mapped in the kernel though, only temporary
-      on reads/writes
-    <teythoon> right
-    <teythoon> so i'd not use memcpy, but one of the mach functions that copy
-      stuff to memory objects ?
-    <braunr> i'm not sure
-    <braunr> you could simply map the object, memcpy to/from it, and unmap it
-    <teythoon> what documentation should i read ?
-    <braunr> vm/vm_map.h for one
-    <teythoon> i can only find stuff describing the kernel interface to
-      userspace
-    <braunr> vm/vm_kern.h may help
-    <braunr> copyinmap and copyoutmap maybe
-    <braunr> hm no
-    <teythoon> vm_map.h isn't overly verbose :(
-    <braunr> vm_map_enter/vm_map_remove
-    <teythoon> ah, i actually tried vm_map_enter
-    <braunr> look at the .c files, functions are described there
-    <teythoon> that leads to funny results
-    <braunr> vm_map_enter == mmap basically
-    <braunr> and vm_object.h
-    <teythoon> panic: kernel thread accessed user space!
-    <braunr> heh :)
-    <teythoon> right, i hoped vm_map_enter to be the in-kernel equivalent of
-      vm_map
-
-    <teythoon> braunr: uh, it worked
-    <braunr> teythoon: ?
-    <teythoon> weird
-    <teythoon> :)
-    <braunr> teythoon: what's happening ?
-    <teythoon> i refined the ramdisk patch, and it seems to work
-    <teythoon> not sure if i got it right though, i'll paste the patch
-    <braunr> yes please
-    <teythoon> http://paste.debian.net/81376/
-    <braunr> no it can't work either
-    <teythoon> :/
-    <braunr> you can't map the complete object
-    <teythoon> (amusingly it does)
-    <braunr> you have to temporarily map the pages you want to access
-    <braunr> it does for the same obscure reason the previous code worked on
-      qemu
-    <teythoon> ok, i think i see
-    <braunr> increase the size a lot more
-    <braunr> like 512M
-    <braunr> and see
-    <braunr> you could also use the kernel debugger to print the kernel map
-      before and after mapping
-    <teythoon> how ?
-    <braunr> hm
-    <braunr> see show task
-    <braunr> maybe you can call the in kernel function directly with the kernel
-      map as argument
-    <teythoon> which one ?
-    <braunr> the one for "show task"
-    <braunr> hm no it shows threads, show map
-    <braunr> and show map crashes on darnassus ..
-    <teythoon> here as well
-    <braunr> ugh
-    <braunr> personally i'd use something like vm_map_info in x15
-    <braunr> but you may not want to waste time with that
-    <braunr> try with a bigger size and see what it does, should be quick and
-      simple enough
-    <teythoon> right
-    <teythoon> braunr: ok, you were right, mapping the entire object fails if
-      it is too big
-    <braunr> teythoon: fyi, kmem_alloc and vm_map have some common code, namely
-      the allocation of an virtual area inside a vm_map
-    <braunr> kmem_alloc requires a kernel map (kernel_map or a submap) whereas
-      vm_map can operate on any map
-    <braunr> what differs is the backing store
-    <teythoon> braunr: i believe i want to use vm_object_copy_slowly to create
-      and populate the vm object
-    <teythoon> for that, i'd need a source vm_object
-    <teythoon> the data is provided as a multiboot_module
-    <braunr> kmem_alloc backs the virtual range with wired down physical memory
-    <braunr> whereas vm_map maps part of an object that is usually pageable
-    <teythoon> i see
-    <braunr> and you probably want your object to be pageable here
-    <teythoon> yes :)
-    <braunr> yes object copy functions could work
-    <braunr> let me check
-    <teythoon> what would i specify as source object ?
-    <braunr> let's assume a device write
-    <braunr> the source object would be where the source data is
-    <braunr> e.g. the data provided by the user
-    <teythoon> yes
-    <teythoon> trouble is, i'm not sure what the source is
-    <braunr> it looks a bit complicated yes
-    <teythoon> i mean the boot loader put it into memory, not sure what mach
-      makes of that
-    <braunr> i guess there already are device functions that look up the object
-      from the given address
-    <braunr> it's anonymous memory
-    <braunr> but that's not the problem here
-    <teythoon> so i need to create a memory object for that ?
-    <braunr> you probably don't want to populate your ramdisk from the kernel
-    <teythoon> wire it down to the physical memory ?
-    <braunr> don't bother with the wire property
-    <teythoon> oh ?
-    <braunr> if it can't be paged out, it won't be
-    <teythoon> ah, that's not what i meant
-    <braunr> you probably want ext2fs to populate it, or another task loaded by
-      the boot loader
-    <teythoon> interesting idea
-    <braunr> and then, this task will have a memory object somewhere
-    <braunr> imagine a task which sole purpose is to embedd an archive to
-      extract into the ramdisk
-    <teythoon> sweet, my thoughts exactly :)
-    <braunr> the data section of a program will be backed by an anonymous
-      memory object
-    <braunr> the problem is the interface
-    <braunr> the device interface passes addresses and sizes
-    <braunr> you need to look up the object from that
-    <braunr> but i guess there is already code doing that in the device code
-      somewhere
-    <braunr> teythoon: vm_object_copy_slowly seems to create a new object
-    <braunr> that's not exactly what we want either
-    <teythoon> why not ?
-    <braunr> again, let's assume a device_write scenario
-    <teythoon> ah
-    <braunr> you want to populate the ramdisk, which is merely one object
-    <braunr> not a new object
-    <teythoon> yes
-    <braunr> teythoon: i suggest using vm_page_alloc and vm_page_copy
-    <braunr> and vm_page_lookup
-    <braunr> teythoon: perhaps vm_fault_page too
-    <braunr> although you might want wired pages initially
-    <braunr> teythoon: but i guess you see what i mean when i say it needs to
-      be reworked
-    <teythoon> i do
-    <teythoon> braunr: aww, screw that, using a tmpfs is much nicer anyway
-    <teythoon> the ramdisk strikes again ...
-    <braunr> teythoon: :)
-    <braunr> teythoon: an extremely simple solution would be to enlarge the
-      kernel map
-    <braunr> this would reduce the userspace max size to ~1.7G but allow ~64M
-      ramdisks
-    <teythoon> nah
-    <braunr> or we could reduce the kmem_map
-    <braunr> i think i'll do that anyway
-    <braunr> the slab allocator rarely uses more than 50-60M
-    <braunr> and the 64M remaining area in kernel_map can quickly get
-      fragmented
-    <teythoon> braunr: using a tmpfs as the root translator won't be straight
-      forward either ... damn the early boostrapping stuff ...
-    <braunr> yes ..
-    <teythoon> that's one of the downsides of the vfs-as-namespace approach
-    <braunr> i'm not sure
-    <braunr> it could be simplified
-    <teythoon> hm
-    <braunr> it could even use a temporary name server to avoid dependencies
-    <teythoon> indeed
-    <teythoon> there's even still the slot for that somewhere
-    <antrik> braunr: hm... I have a vague recollection that the fixed-sized
-      kmem-map was supposed to be gone with the introduction of the new
-      allocator?...
-    <braunr> antrik: the kalloc_map and kmem_map were merged
-    <braunr> we could directly use kernel_map but we may still want to isolate
-      it to avoid fragmentation
-
-See also the discussion on [[gnumach_memory_management]], *IRC, freenode,
-\#hurd, 2013-01-06*, *IRC, freenode, #hurd, 2014-02-11* (`KENTRY_DATA_SIZE`).
-
-
-### IRC, freenode, #hurd, 2012-07-17
-
-    <bddebian> OK, here is a stupid question  I have always had.  If you move
-      PCI and disk drivers in to userspace, how do do initial bootstrap to get
-      the system booting?
-    <braunr> that's hard
-    <braunr> basically you make the boot loader load all the components you
-      need in ram
-    <braunr> then you make it give each component something (ports) so they can
-      communicate
-
-
-### IRC, freenode, #hurd, 2012-08-12
-
-    <antrik> braunr: so, about booting with userspace disk drivers
-    <antrik> after rereading the chapter in my thesis, I see that there aren't
-      really all than many interesting options...
-    <antrik> I pondered some variants involving a temporary boot filesystem
-      with handoff to the real root FS; but ultimately concluded with another
-      option that is slightly less elegant but probably gets a much better
-      usefulness/complexity ratio:
-    <antrik> just start the root filesystem as the first process as we used to;
-      only hack it so that initially it doesn't try to access the disk, but
-      instead gets the files from GRUB
-    <antrik> once the disk driver is operational, we flip a switch, and the
-      root filesystem starts reading stuff from disk normally
-    <antrik> transparently for all other processes
-    <bddebian> How does grub access the disk without drivers?
-    <antrik> bddebian: GRUB obviously has its own drivers... that's how it
-      loads the kernel and modules
-    <antrik> bddebian: basically, it would have to load additional modules for
-      all the components necessary to get the Hurd disk driver going
-    <bddebian> Right, why wouldn't that be possible?
-    <antrik> (I have some more crazy ideas too -- but these are mostly
-      orthogonal :-) )
-    <antrik> ?
-    <antrik> I'm describing this because I'm pretty sure it *is* possible :-)
-    <bddebian> That grub loads the kernel and whatever server/module gets
-      access to the disk
-    <antrik> not sure what you mean
-    <bddebian> Well as usual I probably don't know the proper terminology but
-      why could grub load gnumach and the hurd "disk server" that contains the
-      userspace drivers?
-    <antrik> disk server?
-    <bddebian> Oh FFS whatever contains the disk drivers :)
-    <bddebian> diskdde, whatever :)
-    <antrik> actually, I never liked the idea of having a big driver blob very
-      much... ideally each driver should have it's own file
-    <antrik> but that's admittedly beside the point :-)
-    <antrik> its
-    <antrik> so to restate: in addition to gnumach, ext2fs.static, and ld.so,
-      in the new scenario GRUB will also load exec, the disk driver, any
-      libraries these two depend upon, and any additional infrastructure
-      involved in getting the disk driver running (for automatic probing or
-      whatever)
-    <antrik> probably some other Hurd core servers too, so we can have a more
-      complete POSIX environment for the disk driver to run in
-    <bddebian> There ya go :)
-    <antrik> the interesting part is modifying ext2fs so it will access only
-      the GRUB-provided files, until it is told that it's OK now to access the
-      real disk
-    <antrik> (and the mechanism how ext2 actually gets at the GRUB-provided
-      files)
-    <bddebian> Or write some new really small ext2fs? :)
-    <antrik> ?
-    <bddebian> I'm just talking out my butt.  Something temporary that gets
-      disposed of when the real disk is available :)
-    <antrik> well, I mentioned above that I considered some handoff
-      schemes... but they would probably be more complex to implement than
-      doing the switchover internally in ext2
-    <bddebian> Ah
-    <bddebian> boot up in a ramdisk? :)
-    <antrik> (and the temporary FS would *not* be an ext2 obviously, but rather
-      some special ramdisk-like filesystem operating from GRUB-loaded files...)
-    <antrik> again, that would require a complicated handoff-scheme
-    <bddebian> Bah, what do I know? :)
-    <antrik> (well, you could of course go with a trivial chroot()... but that
-      would be ugly and inefficient, as the initial processes would still run
-      from the ramdisk)
-    <bddebian> Aren't most things running in memory initially anyway?  At what
-      point must it have access to the real disk?
-    <braunr> antrik: but doesn't that require that disk drivers be statically
-      linked ?
-    <braunr> and having all disk drivers in separate tasks (which is what we
-      prefer to blobs as you put it) seems to pretty much forbid using static
-      linking
-    <braunr> hm actually, i don't see how any solution could work without
-      static linking, as it would create a recursion
-    <braunr> and the only one required is the one used by the root file system
-    <braunr> others can be run from the dynamically linked version
-    <braunr> antrik: i agree, it's a good approach, requiring only a slightly
-      more complicated boot script/sequence
-    <antrik> bddebian: at some point we have to access the real disk so we
-      don't have to work exclusively with stuff loaded by grub... but there is
-      no specific point where it *has* to happen. generally speaking, the
-      sooner the better
-    <antrik> braunr: why wouldn't that work with a dynamically linked disk
-      driver? we only need to make sure all required libraries are loaded by
-      grub too
-    <braunr> antrik: i have a problem with that approach :p
-    <braunr> antrik: it would probably require a reboot when those libraries
-      are upgraded, wouldn't it ?
-    <antrik> I'd actually wish we could run with a dynamically linked ext2fs as
-      well... but that would require a separated boot filesystem and some kind
-      of handoff approach, which would be much more complicated I fear...
-    <braunr> and if a driver is restarted, would it use those libraries too ?
-      and if so, how to find them ?
-    <braunr> but how can you run a dynamically linked root file system ?
-    <braunr> unless the libraries it uses are provided by something else, as
-      you said
-    <antrik> braunr: well, if you upgrade the libraries, *and* want the disk
-      driver to use the upgraded libraries, you are obviously in a tricky
-      situation ;-)
-    <braunr> yes
-    <antrik> perhaps you could tell ext2 to preload the new libraries before
-      restarting the disk driver...
-    <antrik> but that's a minor quibble anyways IMHO
-    <braunr> but that case isn't that important actually, since upgrading these
-      libraries usually means we're upgrading the system, which can imply a
-      reoobt
-    <braunr> i don't think it is
-    <braunr> it looks very complicated to me
-    <braunr> think of restart as after a crash :p
-    <braunr> you can't preload stuff in that case
-    <antrik> uh? I don't see anything particularily complicated. but my point
-      was more that it's not a big thing if that's not implemented IMHO
-    <braunr> right
-    <braunr> it's not that important
-    <braunr> but i still think statically linking is better
-    <braunr> although i'm not sure about some details
-    <antrik> oh, you mean how to make the root filesystem use new libraries
-      without a reboot? that would be tricky indeed... but this is not possible
-      right now either, so that's not a regression
-    <braunr> i assume that, when statically linking, only the .o providing the
-      required symbols are included, right ?
-    <antrik> making the root filesystem restartable is a whole different epic
-      story ;-)
-    <braunr> antrik: not the root file system, but the disk driver
-    <braunr> but i guess it's the same
-    <antrik> no, it's not
-    <braunr> ah
-    <antrik> for the disk driver it's really not that hard I believe
-    <antrik> still some extra effort, but definitely doable
-    <braunr> with the preload you mentioned
-    <antrik> yes
-    <braunr> i see
-    <braunr> i don't think it's worth the trouble actually
-    <braunr> statically linking looks way simpler and should make for smaller
-      binaries than if libraries were loaded by grub
-    <antrik> no, I really don't want statically linked disk drivers
-    <braunr> why ?
-    <antrik> again, I'd prefer even ext2fs to be dynamic -- only that would be
-      much more complicated
-    <braunr> the point of dynamically linking is sharing
-    <antrik> while dynamic disk drivers do not require any extra effort beyond
-      loading the libraries with grub
-    <braunr> but if it means sharing big files that are seldom used (i assume
-      there is a lot of code that simply isn't used by hurd servers), i don't
-      see the point
-    <antrik> right. and with the approach I proposed that will work just as it
-      should
-    <antrik> err... what big files?
-    <braunr> glibc ?
-    <antrik> I don't get your point
-    <antrik> you prefer statically linking everything needed before the disk
-      driver runs (which BTW is much more than only the disk driver itself) to
-      using normal shared libraries like the rest of the system?...
-    <braunr> it's not "like the rest of the system"
-    <braunr> the libraries loaded by grub wouldn't be back by the ext2fs server
-    <braunr> they would be wired in memory
-    <braunr> you'd have two copies of them, the one loaded by grub, and the one
-      shared by normal executables
-    <antrik> no
-    <braunr> i prefer static linking because, if done correctly, the combined
-      size of the root file system and the disk driver should be smaller than
-      that of the rootfs+disk driver and libraries loaded by grub
-    <antrik> apparently I was not quite clear how my approach would work :-(
-    <braunr> probably not
-    <antrik> (preventing that is actually the reason why I do *not* want as
-      simple boot filesystem+chroot approach)
-    <braunr> and initramfs can be easily freed after init
-    <braunr> an*
-    <braunr> it wouldn't be a chroot but something a bit more involved like
-      switch_root in linux
-    <antrik> not if various servers use files provided by that init filesystem
-    <antrik> yes, that's the complex handoff I'm talking about
-    <braunr> yes
-    <braunr> that's one approach
-    <antrik> as I said, that would be a quite elegant approach (allowing a
-      dynamically linked ext2); but it would be much more complicated to
-      implement I believe
-    <braunr> how would it allow a dynamically linked ext2 ?
-    <braunr> how can the root file system be linked with code backed by itself
-      ?
-    <braunr> unless it requires wiring all its memory ?
-    <antrik> it would be loaded from the init filesystem before the handoff
-    <braunr> init sn't the problem here
-    <braunr> i understand how it would boot
-    <braunr> but then, you need to make sure the root fs is never used to
-      service page faults on its own address space
-    <braunr> or any address space it depends on, like the disk driver
-    <braunr> so this basically requires wiring all the system libraries, glibc
-      included
-    <braunr> why not
-    <antrik> ah. yes, that's something I covered in a separate section in my
-      thesis ;-)
-    <braunr> eh :)
-    <antrik> we have to do that anyways, if we want *any* dynamically linked
-      components (such as the disk driver) in the paging path
-    <braunr> yes
-    <braunr> and it should make swapping more reliable too
-    <antrik> so that adds a couple MiB of wired memory... I guess we will just
-      have to live with that
-    <braunr> yes it seems acceptable
-    <braunr> thanks
-    <antrik> (it is actually one reason why I want to avoid static linking as
-      much as possible... so at least we have to wire these libraries only
-      *once*)
-    <antrik> anyways, back to my "simpler" approach
-    <antrik> the idea is that a (static) ext2fs would still be the first task
-      running, and immediately able to serve filesystem access requests -- only
-      it would serve these requests from files preloaded by GRUB rather than
-      the actual disk driver
-    <braunr> i understand now
-    <antrik> until a switch is flipped telling it that now the disk driver (and
-      anything it depends upon) is operational
-    <braunr> you still need to make sure all this is wired
-    <antrik> yes
-    <antrik> that's orthogonal
-    <antrik> which is why I have a separate section about it :-)
-    <braunr> what was the relation with ggi ?
-    <antrik> none strictly speaking
-    <braunr> i'll rephrase it: how did it end up in your thesis ?
-    <antrik> I just covered all aspects of userspace drivers in one of the
-      "introduction" sections of my thesis
-    <braunr> ok
-    <antrik> before going into specifics of KGI
-    <antrik> (and throwing in along the way that most of the issues described
-      do not matter for KGI ;-) )
-    <braunr> hehe
-    <braunr> i'm wondering, do we have mlockall on the hurd ? it seems not
-    <braunr> that's something deeply missing in mach
-    <antrik> well, bootstrap in general *is* actually relevant for KGI as well,
-      because of console messages during boot... but the filesystem bootstrap
-      is mostly irrelevant there ;-)
-    <antrik> braunr: oh? that's a problem then... I just assumed we have it
-    <braunr> well, it's possible to implement MCL_CURRENT, but not MCL_FUTURE
-    <braunr> or at least, it would be a bit difficult
-    <braunr> every allocation would need to be aware of that property
-    <braunr> it's better to have it managed by the vm system
-    <braunr> mach-defpager has its own version of vm_allocate for that
-    <antrik> braunr: I don't think we care about MCL_FUTURE here
-    <antrik> hm, wait... MCL_CURRENT is fine for code, but it might indeed be a
-      problem for dynamically allocated memory :-(
-    <braunr> yes
-
-
-# Plan
-
-  * Examine what other systems are doing.
-
-      * L4
-
-          * Hurd on L4: deva, fabrica
-
-          * [[/DDE]]
-
-      * Minix 3
-
-  * Start with a simple driver and implement the needed infrastructure (see
-    *Issues* above) as needed.
-
-      * <http://savannah.nongnu.org/projects/user-drivers/>
-
-        Some (unfinished?) code written by Robert Millan in 2003: PC keyboard
-        and parallel port drivers, using `libtrivfs`.
-
-
-## I/O Server
-
-### IRC, freenode, #hurd, 2012-08-10
-
-    <braunr> usually you'd have an I/O server, and serveral device drivers
-      using it
-    <bddebian> Well maybe that's my question.  Should there be unique servers
-      for say ISA, PCI, etc or could all of that be served by one "server"?
-    <braunr> forget about ISA
-    <bddebian> How?  Oh because the ISA bus is now served via a PCI bridge?
-    <braunr> the I/O server would merely be there to help device drivers map
-      only what they require, and avoid conflicts
-    <braunr> because it's a relic of the past :p
-    <braunr> and because it requires too high privileges
-    <bddebian> But still exists in several PCs :)
-    <braunr> so usually, you'd directly ask the kernel for the I/O ports you
-      need
-    <mel-> so do floppy drives
-    <mel-> :)
-    <braunr> if i'm right, even the l4 guys do it that way
-    <braunr> he's right, some devices are still considered ISA
-    <bddebian> But that is where my confusion lies.  Something has to figure
-      out what/where those I/O ports are
-    <braunr> and that's why i tell you to forget about it
-    <braunr> ISA has both statically allocated ports (the historical ones) and
-      others usually detected through PnP, when it works
-    <braunr> PCI is much cleaner, and memory mapped I/O is both better and much
-      more popular currently
-    <bddebian> So let's say I have a PCI SCSI card.  I need some device driver
-      to know how to talk to that, right?
-    <bddebian> something is going to enumerate all the PCI devices and map them
-      to and address space
-    <braunr> bddebian: that would be the I/O server
-    <braunr> we'll call it the PCI server
-    <bddebian> OK, that is where I am headed.  What if everything isn't PCI?
-      Is the "I/O server" generic enough?
-    <youpi> nowadays everything is PCI
-    <bddebian> So we are completely ignoring legacy hardware?
-    <braunr> we could have separate servers using a shared library that would
-      provide allocation routines like resource maps
-    <braunr> yes
-    <youpi> for what is not, the translator just needs to be run as root
-    <youpi> to get i/o perm from the kernel
-    <braunr> the idea for projects like ours, where the user base is very small
-      is: don't implement what you can't test
-    <youpi> bddebian: legacy can not be supported in a nice way, so for them we
-      can just afford a bad solution
-    <youpi> i.e. leave the driver in kernel
-    <braunr> right
-    <youpi> e.g. the keyboard
-    <bddebian> Well what if I have a USB keyboard? :-P
-    <braunr> that's a different matter
-    <youpi> USB keyboard is not legacy hardware
-    <youpi> it's usb
-    <youpi> which can be enumerated like pci
-    <braunr> and USB uses PCI
-    <youpi> and pci could be on usb :)
-    <braunr> so it's just a separate stack on top of the PCI server
-    <bddebian> Sure so would SCSI in my example above but is still a seperate
-      bus
-    <braunr> netbsd has a very nice way of attaching drivers to buses
-    <youpi> bddebian: also, yes, and it can be enumerated
-    <bddebian> Which was my original question.  This magic I/O server handles
-      all of the buses?
-    <youpi> no, just PCI, and then you'd have other servers for other busses
-    <braunr> i didn't mean that there would be *one* I/O server instance
-    <bddebian> So then it isn't a generic I/O server is it?
-    <bddebian> Ahhhh
-    <youpi> that way you can even put scsi over ppp or other crazy things
-    <braunr> it's more of an idea
-    <braunr> there would probably be a generic interface for basic stuff
-    <braunr> and i assume it could be augmented with specific (e.g. USB)
-      interfaces for servers that need more detailed communication
-    <braunr> (well, i'm pretty sure of it)
-    <bddebian> So the I/O server generalizes all functions, say read and write,
-      and then the PCI, USB, SCIS, whatever servers are contacted by it?
-    <braunr> no, not read and write
-    <braunr> resource allocation rather
-    <youpi> and enumeration
-    <braunr> probing perhaps
-    <braunr> bddebian: the goal of the I/O server is to make it possible for
-      device drivers to access the resources they need without a chance to
-      interfere with other device drivers
-    <braunr> (at least, that's one of the goals)
-    <braunr> so a driver would request the bus space matching the device(s) and
-      obtain that through memory mapping
-    <bddebian> Shouldn't that be in the "global address space"?  SOrry if I am
-      using the wrong terminology
-    <youpi> well, the i/o server should also trigger the start of that driver
-    <youpi> bddebian: address space is not a matter for drivers
-    <braunr> bddebian: i'm not sure what you think of with "global address
-      space"
-    <youpi> bddebian: it's just a matter for the pci enumerator when (and if)
-      it places the BARs in physical address space
-    <youpi> drivers merely request mapping that, they don't need to know about
-      actual physical addresses
-    <braunr> i'm almost sure you lost him at BARs
-    <braunr> :(
-    <braunr> youpi: that's what i meant with probing actually
-    <bddebian> Actually I know BARs I have been reading on PCI :)
-    <bddebian> I suppose physicall address space is more what I meant when I
-      used "global address space"
-    <braunr> i see
-    <youpi> bddebian: probably, yes
-
-
-# Documentation
-
-  * [An Architecture for Device Drivers Executing as User-Level
-    Tasks](http://portal.acm.org/citation.cfm?id=665603), 1993, David B. Golub,
-    Guy G. Sotomayor, Freeman L. Rawson, III
-
-  * [Performance Measurements of the Multimedia Testbed on Mach 3.0: Experience
-    Writing Real-Time Device Drivers, Servers, and
-    Applications](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.40.8685),
-    1993, Roger B. Dannenberg, David B. Anderson, Tom Neuendorffer, Dean
-    Rubine, Jim Zelenka
-
-  * [User Level IPC and Device Management in the Raven
-    Kernel](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.57.3733),
-    1993, D. Stuart Ritchie, Gerald W. Neufeld
-
-  * [Creating User-Mode Device Drivers with a
-    Proxy](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.26.3055),
-    1997, Galen C. Hunt
-
-  * [The APIC Approach to High Performance Network Interface Design: Protected
-    DMA and Other
-    Techniques](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.56.1198),
-    1997, Zubin D. Dittia, Guru M. Parulkar, Jerome R. Cox, Jr.
-
-  * [The Fluke Device Driver
-    Framework](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.4.7927),
-    1999, Kevin Thomas Van Maren
-
-  * [Omega0: A portable interface to interrupt hardware for L4
-    system](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.21.5958),
-    2000, Jork Löser, Michael Hohmuth
-
-  * [Userdev: A Framework For User Level Device Drivers In
-    Linux](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.4461),
-    2000, Hari Krishna Vemuri
-
-  * [User Mode Drivers](http://www.linuxjournal.com/article/5442), 2002, Bryce
-    Nakatani
-
-  * [Towards Untrusted Device
-    Drivers](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.13.1725),
-    2003, Ben Leslie, Gernot Heiser
-
-  * [Encapsulated User-Level Device Drivers in the Mungi Operating
-    System](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.6.1531),
-    2004, Ben Leslie Nicholas, Nicholas FitzRoy-Dale, Gernot Heiser
-
-  * [Linux Kernel Infrastructure for User-Level Device
-    Drivers](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.1408),
-    2004, Peter Chubb
-
-      * [Get More Device Drivers out of the
-        Kernel!](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.59.6333),
-        2004, Peter Chubb
-
-      * <http://gelato.unsw.edu.au/IA64wiki/UserLevelDrivers>
-
-  * [Initial Evaluation of a User-Level Device
-    Driver](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.59.4531),
-    2004, Kevin Elphinstone, Stefan Götz
-
-  * [User-level Device Drivers: Achieved
-    Performance](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.59.6766),
-    2005, Ben Leslie, Peter Chubb, Nicholas FitzRoy-Dale, Stefan Götz, Charles
-    Gray, Luke Macpherson, Daniel Potts, Yueting Shen, Kevin Elphinstone,
-    Gernot Heiser
-
-  * [Virtualising
-    PCI](http://www.ice.gelato.org/about/oct06_presentations.php#pres14), 2006,
-    Myrto Zehnder, Peter Chubb
-
-  * [Microdrivers: A New Architecture for Device
-    Drivers](http://www.cs.rutgers.edu/~vinodg/papers/hotos2007/), 2007, Vinod
-    Ganapathy, Arini Balakrishnan, Michael M. Swift, Somesh Jha
-
-      * <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.109.2623>
-        [[!tag open_issue_documentation]]
-
-      * <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.146.2170>
-        [[!tag open_issue_documentation]]
-
-
-# External Projects
-
-  * [[/DDE]]
-
-  * <http://ertos.nicta.com.au/research/drivers/uldd/>
-
-  * <http://gelato.unsw.edu.au/IA64wiki/UserLevelDrivers>
-
-
-## The Anykernel and Rump Kernels
-
-  * [Running applications on the Xen
-    Hypervisor](http://blog.netbsd.org/tnf/entry/running_applications_on_the_xen),
-    Antti Kantee, 2013-09-17.  [The Anykernel and Rump
-    Kernels](http://www.netbsd.org/docs/rump/).
-
-
-### IRC, freenode, #hurd, 2014-02-13
-
-    <cluck> is anyone working on getting netbsd's rump kernel working under
-      hurd? it seems like a neat way to get audio/usb/etc with little extra
-      work (it might be a great complement to dde)
-    <braunr> noone is but i do agree
-    <braunr> although rump wasn't exactly designed to make drivers portable,
-      more subsystems and higher level "drivers" like file systems and network
-      stacks
-    <braunr> but it's certainly possible to use it for drivers to without too
-      much work
-    <curious_troll> cluck: I am reading about rumpkernels and his thesis.
-    <cluck> braunr: afaiu there is (at least partial) work done on having it
-      run on linux, xen and genode [unless i misunderstood the fosdem'14 talks
-      i've watched so far]
-    <cluck> "Generally speaking, any driver-like kernel functionality can be
-      offered by a rump server. Examples include file systems, networking
-      protocols, the audio subsystem and USB hardware device drivers. A rump
-      server is absolutely standalone and running one does not require for
-      example the creation and maintenance of a root file system."
-    <cluck> from http://www.netbsd.org/docs/rump/sptut.html
-    <braunr> cluck: how do they solve resource sharing problems ?
-    <cluck> braunr: some sort of lock iiuc, not sure if that's managed by the
-      host (haven't looked at the code yet)
-    <braunr> cluck: no, i mean things like irq sharing ;p
-    <braunr> bus sharing in general
-    <braunr> netbsd has a very well defined interface for that, but i'm
-      wondering what rump makes of it
-    <cluck> braunr: yes, i understood
-    <cluck> braunr: just lacking proper terminology to express myself
-    <cluck> braunr: at least from the talk i saw what i picked up is it behaves
-      like netbsd inside but there's some sort of minimum support required from
-      the "host" so the outside can reach down to the hw
-    <braunr> cluck: rump is basically glue code
-    <cluck> braunr: but as i've said, i haven't looked at the code in detail
-      yet
-    <cluck> braunr: yes
-    <braunr> but host support, at least for the hurd, is a bit more involved
-    <braunr> we don't merely want to run standalone netbsd components
-    <braunr> we want to make them act as real hurd servers
-    <braunr> therefore tricky stuff like signals quickly become more
-      complicated
-    <braunr> we also don't want it to use its own RPC format, but instead use
-      the native one
-    <cluck> braunr: antti says required support is minimal
-    <braunr> but again, compared to everything else, the porting effort / size
-      of reusable code base ratio is probably the lowest
-    <braunr> cluck: and i say we don't merely want to run standalone netbsd
-      components on top of a system, we want them to be our system
-    <cluck> braunr: argh.. i hate being unable to express myself properly
-      sometimes :|
-    <cluck> ..the entry point?!
-    <braunr> ?
-    <cluck> dunno what to call them
-    <braunr> i understand what you mean
-    <braunr> the system specific layer
-    <braunr> and *againù i'm telling you our goals are different
-    <cluck> yes, anyways.. just a couple of things, the rest is just C
-    <braunr> when you have portable code such as found in netbsd, it's not that
-      hard to extract it, create some transport between a client and a server,
-      and run it
-    <braunr> if you want to make that hurdish, there is more than that
-    <braunr> 1/ you don't use tcp, you use the native microkernel transport
-    <braunr> 2/ you don't use the rump rpc code over tcp, you create native rpc
-      code over the microkernel transport (think mig over mach)
-    <braunr> 3/ you need to adjust how authentication is performed (use the
-      auth server instead of netbsd internal auth mechanisms)
-    <braunr> 4/ you need to take care of signals (if the server generates a
-      signal, it must correctly reach the client)
-    <braunr> and those are what i think about right now, there are certainly
-      other details
-    <cluck> braunr: yes, some of those might've been solved already, it seems
-      the next genode release already has support for rump kernels, i don't
-      know how they went about it
-    <cluck> braunr: in the talk antii mentions he wanted to quickly implement
-      some i/o when playing on linux so he hacked a fs interface 
-    <cluck> so the requirements can't be all that big
-    <cluck> braunr: in any case i agree with your view, that's why i found rump
-      kernels interesting in the first place
-    <braunr> i went to the presentation at fosdem last year
-    <braunr> and even then considered it the best approach for
-      driver/subsystems reuse on top of a microkernel
-    <braunr> that's what i intend to use in propel, but we're far from there ;p
-    <cluck> braunr: tbh i hadn't paid much attention to rump at first, i had
-      read about it before but thought it was more netbsd specific, the genode
-      mention piked my interest and so i went back and watched the talk, got
-      positively surprised at how far it has come already (in retrospect it
-      shouldn't have been so unexpected, netbsd has always been very small,
-      "modular", with clean interfaces that make porting easier)
-    <braunr> netbsd isn't small at all
-    <braunr> not exactly modular, well it is, but less than other systems
-    <braunr> but yes, clean interfaces, explicitely because their stated goal
-      is portability
-    <braunr> other projects such as minix and qnx didn't wait for rump to reuse
-      netbsd code
-    <cluck> braunr: qnx and minix have had money and free academia labor done
-      in their favor before (sadly hurd doesn't have the luck to enjoy those
-      much)
-    <cluck> :)
-    <braunr> sure but that's not the point
-    <braunr> resources or not, they chose the netbsd code base for a reason
-    <braunr> and that reason is portability
-    <cluck> yes
-    <cluck> but it's more work their way
-    <braunr> more work ?
-    <cluck> with rump we'd get all those interfaces for free
-    <braunr> i don't know
-    <braunr> not for free, certainly not
-    <cluck> "free"
-    <braunr> but the cost would be close to as low as it could possibly be
-      considering what is done
-    <cluck> braunr: the small list of dependencies makes me wonder if it's
-      possible it'd build under hurd without any mods (yes, i know, very
-      unlikely, just dreaming here)
-    <braunr> cluck: i'd say it's likely
-    <youpi> I quickly tried to build it during the talk
-    <youpi> there are PATH_MAX everywhere
-    <braunr> ugh
-    <youpi> but maybe that can be #defined
-    <youpi> since that's most probably for internal use
-    <youpi> not interaction with the host
diff --git a/open_issues/usleep.mdwn b/open_issues/usleep.mdwn
deleted file mode 100644
index b71cd902..00000000
--- a/open_issues/usleep.mdwn
+++ /dev/null
@@ -1,25 +0,0 @@
-[[!meta copyright="Copyright © 2012 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]]
-
-# IRC, OFTC, #debian-hurd, 2012-07-14
-
-    <pinotree> eeek, usleep has the issues which i fixed in nanosleep
-    <bdefreese> pinotree: ?
-    * pinotree ponders a `mv sysdeps/unix/sysv/linux/usleep.c
-        sysdeps/mach/usleep.c`
-    <pinotree> s/mv/cp/
-    <bdefreese> What the heck is the point of usleep(0) anyway?  Isn't that
-      basically saying suspend for 0 milliseconds?
-    <youpi> it's rounded up by the kernel I guess
-    <youpi> i.e. suspend for the shortest time possible (a clock tick)
-    <pinotree> posix 2001 says that «If the value of useconds is 0, then the
-      call has no effect.»
diff --git a/open_issues/vdso.mdwn b/open_issues/vdso.mdwn
deleted file mode 100644
index 76c43aa8..00000000
--- a/open_issues/vdso.mdwn
+++ /dev/null
@@ -1,48 +0,0 @@
-[[!meta copyright="Copyright © 2013 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_gnumach open_issue_hurd]]
-
-Evaluate whether or not usage of vDSOs (virtual dynamically linked shared
-objects; [[!wikipedia vDSO]]) can be useful in a GNU Hurd system.
-
-Explanation and example for the Linux kernel: [Creating a vDSO: the Colonel's
-Other
-Chicken](http://www.linuxjournal.com/content/creating-vdso-colonels-other-chicken),
-Matt Davis, 2012-02-06.  The *Resources* given are also worth reading.
-Basically, this is useful for exporting data from the kernel (generally, or
-given a process context ([[Unix]]), or task/thread context, and so on).
-
-On a GNU Hurd system, parts of the data that makes up a process context doesn't
-actually live inside the kernel, but instead is directly held in glibc.  For
-example `sysdeps/mach/hurd/getpid.c:__getpid` does a mere `return _hurd_pid`.
-For this reason, vDSOs might not be as useful on GNU Hurd as they are with the
-Linux kernel.  Or, put another way, as GNU Hurd system doesn't have many
-[[system_call]]s, also there aren't many that could be replaced.
-
-Generally only *real* [[system_call]]s should be candidates for implementation
-with vDSO code, because otherwise that'd break the ([[RPC]]) system's inherent
-[[/virtualization]] capabilities.
-
-Having vDSO code might be useful for:
-
-  * `mach_*_self`: `mach_host_self`, `mach_task_self`, `mach_thread_self`?
-
-  * [[mapped-time_interface|microkernel/mach/gnumach/interface/device/time]]
-
-    Every application can then use that via the regular
-    `gettimeofday`/`clock_gettime` and similar calls instead of using the
-    special [[hurd/libshouldbeinlibc]]'s `<maptime.h>` interface.
-
-    Can implement [[`clock_gettime` stuff|clock_gettime]] more easily that way,
-    for example for nanosecond precision?
-
-    Now, the [[mapped-time_interface]] is virtualizable -- the question is
-    whether there is a way so that we can make a compromise here?
diff --git a/open_issues/versioning.mdwn b/open_issues/versioning.mdwn
deleted file mode 100644
index 18fb588e..00000000
--- a/open_issues/versioning.mdwn
+++ /dev/null
@@ -1,109 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-Things to consider regarding *versioning*.
-
-The provider and user of any interface need to agree about how to interpret the
-data being exchanged.  Internal-only interfaces can be changed easily, because
-you can change the provider and user at the same time.  Interfaces that are
-exposed externally require more attention, for obvious reasons.  To *change*
-interfaces means to either remove, or add, or modify an existing interface.
-Modify basically means to remove and then re-add a variant, re-using the former
-name/identifier.
-
-[[!toc]]
-
-
-# [[RPC]]s
-
-## [[microkernel/mach/message/msgh_id]]
-
-
-# Shared Libraries
-
-  * [[!wikipedia soname]]
-  * ELF symbol versioning
-  * [[!wikipedia "GNU Libtool"]]
-
-
-## Hurd
-
-Transition to "normal" ELF symbol versioning/libtool?
-
-For all libraries, the SONAME is currently set to *0.3*.  [[!message-id
-desc="Not changed" "87ob7cxbu6.fsf@kepler.schwinge.homeip.net"]] when doing the
-[[Hurd 0.5 release|news/2013-09-27]].
-
-
-## glibc
-
-Bump the glibc SONAME to some point, or can do everything with symbol
-versioning?
-
-There are some comments in the sources, for example `hurd/geteuids.c`: `XXX
-Remove this alias when we bump the libc soname.`
-
-
-### IRC, freenode, #hurd, 2012-12-14
-
-[[!tag open_issue_glibc open_issue_libpthread]]
-
-In context of [[packaging_libpthread]]/[[libpthread]].
-
-    <pinotree> once libc is switched internally from cthreads to pthreads (thus
-      breaking its BC), may be worth cleanup the hurd-specific exported symbols
-    <tschwinge> pinotree: Yes.  If you already have ideas about what to clean
-      up, feel free to add a new page or a section on open_issues/glibc.
-    <pochu> we're gonna break backwards compatibility in glibc on hurd? that
-      could be the perfect moment to fix the /dev/fd/N problem without adding
-      new RPCs, though we'd probably have to break backwards-compatibility in
-      the exec server IIRC...
-
-[[glibc#execve_relative_paths]].
-
-
-### `time_t` -- Unix Epoch vs. 2038
-
-#### IRC, freenode, #hurd, 2013-12-12
-
-    <azeem> because it gets discussed in #debian-devel for the Linux i386
-      architecture right now: what's the deal with hurd-i386 and the 32bit
-      epoch overflow in 2038?
-    <braunr> what do you mean ?
-    <azeem> braunr: http://lwn.net/Articles/563285/
-    <braunr> ok but what do you mean ?
-    <braunr> i don't think there is anything special with the hurd about that
-    <azeem> well, time_t is 64bit on amd64 AIUI
-    <braunr> it's a signed long
-    <azeem> so maybe the Hurd guys were clever from the start
-    <azeem> k, k
-    <braunr> our big advantage is that we can afford to break things a little
-      without too much trouble
-    <braunr> in a system at work, we use unsigned 32-bit words
-    <braunr> which overflows in 2106
-    <braunr> and we already include funny comments that predict our successors,
-      if any, will probably fail to deal with the problem until short before
-      the overflow :>
-    <azeem> luckily, no nuclear reactors are running the Hurd sofar
-    <braunr> i wonder how the problem will be dealt with though
-    <braunr> ah, openbsd decided to break their abi
-    <azeem> yeah
-    <braunr> that's probably the simplest solution
-    <azeem> "just recompile"
-    <braunr> and they can afford it too
-    <azeem> yeah
-    <braunr> good to see people actually worry about it
-    <azeem> I guess people are getting worried about where Linux embedded is
-      being put into
-    <braunr> they're right about that
-    <azeem> "Please, don't fix the 2038 year issue. I also want to have some
-      job security :)"
-    <braunr> haha
diff --git a/open_issues/vfat_test_suite.mdwn b/open_issues/vfat_test_suite.mdwn
deleted file mode 100644
index e06f07e3..00000000
--- a/open_issues/vfat_test_suite.mdwn
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!meta copyright="Copyright © 2013 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_hurd]]
-
-As referenced in Linux kernel's `Documentation/filesystems/vfat.txt`, on
-<http://web.archive.org/web/*/http://bmrc.berkeley.edu/people/chaffee/vfat.html>
-one can find a VFAT Test Suite.  Run it on our [[hurd/translator/fatfs]].
-
-
-# See Also
-
-  * [[File_System_Exerciser]]
diff --git a/open_issues/viengoos_make_clean.mdwn b/open_issues/viengoos_make_clean.mdwn
deleted file mode 100644
index af2920e7..00000000
--- a/open_issues/viengoos_make_clean.mdwn
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_viengoos]]
-
-IRC, unknown channel, unknown date.
-
-    <neal> tschwinge: If I do a make clean n the root directory, follow that with a configure, configure fails with: configure: error: C compiler cannot create executables
-    <neal> this is in config.log: /home/neal/src/hurd-l4/build/lib/gcc/i686-pc-viengoos-gnu/4.2.2/../../../../i686-pc-viengoos-gnu/bin/ld: cannot find -lc
-    <neal> rt 
-    <tschwinge> neal: Should make clean also remove srcdir/gcc/gcc and binutils, as you do it with newlib?
-    <neal> I'd prefer it not to
-    <neal> as I use make clean to prep the tree for new configure changes
-    <neal> and build gcc takes a long time
-    <neal> (as does newlib, but newlib in this case needs to be rebuilt)
diff --git a/open_issues/viengoos_tls_gcc.mdwn b/open_issues/viengoos_tls_gcc.mdwn
deleted file mode 100644
index 92499903..00000000
--- a/open_issues/viengoos_tls_gcc.mdwn
+++ /dev/null
@@ -1,17 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_viengoos]]
-
-IRC, unknown channel, unknown date.
-
-    <neal> tschwinge : I'm trying to enable tls for viengoos.  This requires compiling gcc with --enable-tls, which enables threading, which pulls in libpthread, which requires newlib headers.
-    <neal> tschwinge : Unfortunately, I don't see how to install the newlib headers without having gcc
-    <neal> tschwinge : Have you got any ideas?
diff --git a/open_issues/virtio.mdwn b/open_issues/virtio.mdwn
deleted file mode 100644
index 8298cbfe..00000000
--- a/open_issues/virtio.mdwn
+++ /dev/null
@@ -1,208 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 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_hurd open_issue_gnumach]]
-
-
-# IRC, freenode, #hurd, 2012-07-01
-
-In context of [[DDE]].
-
-    <braunr> hm, i haven't looked but, does someone know if virtio is included
-      in netdde ?
-    <youpi> braunr: nope, there's an underlying virtio layer needed before
-
-
-# IRC, freenode, #hurd, 2013-07-24
-
-    <teythoon> btw, I'd love to see libvirt support in hurd
-    <teythoon> I tried to hack up a dde based net translator
-    <teythoon> afaics they are very much like any other pci device, so the
-      infrastructure should be there
-    <teythoon> if anything I expect the libvirt stuff to be more easily
-      portable
-    <youpi> what do you mean by "a  dde based net translator" ?
-    <youpi> ah, you mean virtio support in netdde ?
-    <teythoon> yes
-    <teythoon> virtio net is present in the kernel version we use for the dde
-      drivers
-    <teythoon> so I just copied the dde driver over, but I had no luck
-      compiling it
-    <youpi> ok, but what would be the benefice over e1000 & co?
-    <teythoon> any of the dde drivers btw
-    <teythoon> youpi: less overhead
-    <youpi> e1000 is already low overhead actually
-    <youpi> there are less and less differences in strategies for driving a
-      real board, and a virtual one
-    <youpi> we are seeing shared memory request buffer, dma, etc. in real
-      boards
-    <youpi> which ends up being almost exactly what virtio does :)
-    <youpi> ahci, for instance, really looks extremely like a virtio interface
-    <youpi> (I know, it's a disk, but that's the same idea, and I do know what
-      I'm talking about here :) )
-    <teythoon> that would actually be my next wish, a virtio disk driver, and
-      virt9p ;)
-    <braunr> on the other hand, i wouldn't spend much time on a virtio disk
-      driver for now
-    <braunr> the hurd as it is can't boot on a device that isn't managed by the
-      kernel
-    <braunr> we'd need to change the boot protocol
-    <teythoon> ok, I wasn't planning to, just wanted to see if I can easily
-      hack up the virtio-net translator
-    <braunr> well, as youpi pointed, there is little benefit to that as well
-    <braunr> but if that's what you find fun, help yourself :)
-    <teythoon> I didn't know that, I assumed there was some value to the virtio
-      stuff
-    <braunr> there is
-    <braunr> but relatively to other improvements, it's low
-
-
-# IRC, freenode, #hurd, 2013-09-14
-
-    <rekado> I'm slowly beginning to understand the virtio driver framework
-      after reading Rusty's virtio paper and the Linux sources of a few virtio
-      drivers.
-    <rekado> Has anyone started working on virtio drivers yet?
-    <youpi> rekado: nobody has worked on virtio drivers, as I know of
-    <rekado> youpi: I'm still having a hard time figuring out where virtio
-      would fit in in the hurd.
-    <rekado> I'm afraid I don't understand how drivers in the hurd work at all.
-      Will part of this have to be implemented in Mach?
-    <youpi> rekado: it could be implemented either as a Mach driver, or as a
-      userland driver
-    <youpi> better try the second alternative
-    <youpi> i.e. as a translator
-    <youpi> sitting on e.g. /dev/eth0 or /dev/hd0
-
-
-## IRC, freenode, #hurd, 2013-09-18
-
-    <rekado> To get started with virtio I'd like to write a simple driver for
-      the entropy device which appears as a PCI device when running qemu with
-      -device virtio-rng-pci .
-    <braunr> why entropy ?
-    <rekado> because it's the easiest.
-    <braunr> is it ?
-    <braunr> the driver itself may be, but integrating it within the system
-      probably isn't
-    <rekado> It uses the virtio framework but only really consists of a
-      read-only buffer virtqueue
-    <braunr> you're likely to want something that can be part of an already
-      existing subsystem like networking
-    <rekado> All the driver has to do is push empty buffers onto the queue and
-      pass the data it receives back from the host device to the client
-    <rekado> The thing about existing subsystems is: I don't really understand
-      them enough.
-    <rekado> I understand virtio, though.
-    <braunr> but isn't your goal understanding at least one ?
-    <rekado> yes.
-    <braunr> then i suggest working on virtio-net
-    <braunr> and making it work in netdde
-    <rekado> But to write a virtio driver for network I must first understand
-      how to actually talk to the host virtio driver/device.
-    <braunr> rekado: why ?
-    <rekado> There is still a knowledge gap between what I know about virtio
-      and what I have learned about the Hurd/Mach.
-    <braunr> are you trying to learn about virtio or the hurd ?
-    <rekado> both, because I'd like to write virtio drivers for the hurd.
-    <braunr> hm no
-    <rekado> with virtio drivers pass buffers to queues and then notify the
-      host.
-    <braunr> you may want it, but it's not what's best for the project
-    <rekado> oh.
-    <braunr> what's best is reusing existing drivers
-    <braunr> we're much too far from having enough manpower to maintain our own
-    <rekado> you mean porting the linux virtio drivers?
-    <braunr> there already is a virtio-net driver in linux 2.6
-    <braunr> so yes, reuse it
-    <braunr> the only thing which might be worth it is a gnumach in-kernel
-      driver for virtio block devices
-    <braunr> because currently, we need our boot devices to be supported by the
-      kernel itself ...
-    <rekado> when I boot the hurd with qemu and the entropy device I see it as
-      an unknown PCI device in the output of lspci.
-    <braunr> that's just the lspci database which doesn't know it
-    <rekado> Well, does this mean that I could actually talk to the device
-      already? E.g., through libpciaccess?
-    <rekado> I'm asking because I don't understand how exactly devices "appear"
-      on the Hurd.
-    <braunr> it's one of the most difficult topic currently
-    <braunr> you probably can talk to the device, yes
-    <braunr> but there are issues with pci arbitration
-    * rekado takes notes: "pci arbitration"
-    <rekado> so, this is about coordinating bus access, right?
-    <braunr> yes
-    <braunr> i'm not a pci expert so i can't tell you much more
-    <rekado> heh, okay.
-    <rekado> what kind of "issues with pci arbitration" are you referring to,
-      though?
-    <rekado> Is this due to something that Mach isn't doing?
-    <braunr> ideally, mach doesn't know about pci
-    <braunr> the fact we still need in-kernel drivers for pci devices is a big
-      problem
-    <braunr> we may need something like a pci server in userspace
-    <braunr> on l4 system it's called an io server
-    <rekado> How do in-kernel drivers avoid these issues?
-    <braunr> they don't
-    <rekado> Or rather: why is it they don't have these issues?
-    <braunr> they do
-    <rekado> oh.
-    <braunr> we had it when youpi added the sata driver
-    <braunr> so currently, all drivers need to avoid sharing common interrupts
-      for example
-    <braunr> again, since i'm not an expert about pci, i don't know more about
-      the details
-    <Hooligan0> pci arbitrations are made by hardware ... no ?
-    <braunr> Hooligan0: i don't know
-    <braunr> i'm not merely talking about bus mastering here
-    <braunr> simply preventing drivers from mapping the same physical memory
-      should be enforced somewhere
-    <braunr> i'm not sure it is
-    <braunr> same for irq sharing
-    <Hooligan0> braunr : is the support for boot devices into the kernel is
-      really needed if a loader put servers into the memory before starting
-      mach ?
-    <braunr> Hooligan0: there is a chicken-and-egg problem during boot,
-      whatever the solution
-    <braunr> obviously, we can preload from memory, but then you really want
-      your root file system to use a disk
-    <braunr> Hooligan0: the problem with preloading from memory is that you
-      want the root file system to use a real device
-    <braunr> the same way / refers to one on unix
-    <braunr> so you have an actual, persistent hierarchy from which the system
-      can be initialized and translators started
-    <braunr> you also want to share as much as possible between the early
-      programs and the others
-    <braunr> so for example, both the disk driver and the root file system
-      should be able to use the same libc instance
-    <braunr> this requires a "switch root" mechanism that needs to be well
-      defined and robust
-    <braunr> otherwise we'd just build our drivers and root fs statically
-    <braunr> (which is currently done with rootfs actually)
-    <braunr> and this isn't something we're comfortable with
-    <braunr> so for now, in-kernel drivers
-    <Hooligan0> humm ... disk driver and libc ... i see
-    <Hooligan0> in other way ... disk drivers can use only a little number of
-      lib* functions ; so with a static version, a bit of memory is lots
-    <Hooligan0> s/lots/lost
-    <Hooligan0> and maybe the driver can be hot-replaced after boot (ok ok,
-      it's more simple to say than to write)
-
-
-<a name="KVM"></a>
-# Virtio Drivers for KVM
-
-In context of [[hurd/running/cloud]], *OpenStack*.
-
-Ideally they would be userland.  That means getting documentation about how
-virtio works, and implement it.  The hurdish part is mostly about exposing the
-driver interface.  The [[hurd/translator/devnode]] translator can be used as a
-skeleton.
diff --git a/open_issues/virtual_square_view-os.mdwn b/open_issues/virtual_square_view-os.mdwn
deleted file mode 100644
index dcc98785..00000000
--- a/open_issues/virtual_square_view-os.mdwn
+++ /dev/null
@@ -1,55 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-All the following is based only on a first, and quick glance only.
-
-We may want to have a look at Virtual Square / View-OS, and evaluate in which
-ways this is related / implemented / implementable / usable / useful in a Hurd
-environment, and even ;-) strive to collaborate with them.
-
-[[I|tschwinge]] found this project very much by chance: on LinkedIn, they
-posted a proposal for [DevRoom on Virtualization
-Technologies](http://www.linkedin.com/groupItem?view=&gid=27213&type=member&item=31720076)
-for [[community/meetings/FOSDEM_2011]].  LinkedIn sends out such posts in very
-opaque emails from time to time (probably they'd look less opaque with a HTML
-mail user agent), and I even bothered to have a look at it, and follow the link
-to the web page, and not delete it straightway.
-
-So, I had a quick look at the project:
-
-This seems to be an amalgamation / combination of various virtualization
-mechanisms / projects / ideas.  Virtualization is here meant in a broad sense,
-including file system namespaces: our `chroot` / `settrans --chroot`;
-networking configurations: our pfinet override stuff; system configuration:
-subhurds?; current time, devices: likewise?; executable interpreter: our exec
-server override stuff; "stat" virtualization: fakeroot; etc.  -- They seem to
-do a lot of stuff that we also try to do / could do / can do.
-
-In fact, this looks a bit like they're trying to bring some more of the Hurd's
-[[hurd/concepts]] over to Unix / Linux, more than only the *usual VFS stuff*
-(translators / FUSE).
-
-Perhaps start reading with the *slides* linked below.
-
-  * <http://virtualsquare.org/>
-
-      * <http://wiki.virtualsquare.org/>
-
-      * <http://sourceforge.net/projects/view-os/>
-
-  * Renzo Davoli, [*Virtual
-    Square*](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.108.9106),
-    2005
-
-  * Renzo Davoli, Michael Goldweber, [*View-OS: Change your View on
-    Virtualization*](http://www.cs.unibo.it/~renzo/view-os-lk2009.pdf),
-    Proc. of Linux Kongress, 2009
-
-      * [slides](http://www.cs.unibo.it/~renzo/view-os-lk2009-slides.pdf)
diff --git a/open_issues/virtualbox.mdwn b/open_issues/virtualbox.mdwn
deleted file mode 100644
index d0608b4a..00000000
--- a/open_issues/virtualbox.mdwn
+++ /dev/null
@@ -1,137 +0,0 @@
-[[!meta copyright="Copyright © 2011, 2012 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]]."]]"""]]
-
-[[!toc]]
-
-
-# Running GNU Mach in VirtualBox crashes during initialization.
-
-[[!tag open_issue_gnumach]]
-
-
-## IRC, freenode, #hurd, 2011-08-15
-
-    <BlueT_> HowTo Reproduce: 1) Use `reboot` to reboot the system.  2) Once
-      you see the Grub menu, turn off the debian hurd box.  3) Let the box boot
-      normally, and wait for the error/crash/reboot. 4) The error/crash will
-      happen twice and it's reboot automatically. The 3rd boot will success.
-
-    <BlueT_> root@dhurd:/boot# addr2line -f -e gnumach-1.3.99-486-dbg-copy 0x106c93 0x1556a5 0x152c54
-    <BlueT_> copyoutmsg
-    <BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../i386/i386/locore.S:1289
-    <BlueT_> exec_load
-    <BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../kern/elf-load.c:80
-    <BlueT_> user_bootstrap
-    <BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../kern/bootstrap.c:756
-
-    i386/i386/locore.S:1289 is 
-
-            movl    $USER_DS,%eax           /* use user data segment for accesses */
-    =>      mov     %ax,%es
-
-    State is
-
-    cs: 0x8
-    ds: 0x10
-    es: 0x10
-    fs: 0
-    gs: 0
-    ss: 0x10
-    eax: 0x1f
-    ecx: 0x8048000
-    edx: 0x15fb7f
-    ebx: 0x1001000
-    esp: 0x75e47e08
-    ebp: 0x75e47e6c
-    esi: 0x1002000
-    edi: 0x8048000
-    eip: 0x106c93
-    efl: 0x10206
-
-    <youpi> oh, wait, it's not even the data access which poses problem
-    <youpi> but the use of $USER_DS
-    <youpi> ew
-    <youpi> looks like a gdt initialization emulation issue in virtualbox...
-
-
-    <BlueT_> just found that at the second crash, the address is different
-    <BlueT_> 2nd time:
-    <BlueT_> addr2line -f -e gnumach-1.3.99-486-dbg-copy 0x1068bd 0x152c74
-    <BlueT_> _kret_popl_es
-    <BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../i386/i386/locore.S:527
-    <BlueT_> user_bootstrap
-    <BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../kern/bootstrap.c:765
-
-    i386/i386/locore.S:527 is:
-
-    _return_from_kernel:
-    _kret_popl_gs:
-            popl    %gs                     /* restore segment registers */
-    _kret_popl_fs:
-            popl    %fs
-    _kret_popl_es:
-    =>      popl    %es
-    _kret_popl_ds:
-
-    cs: 0x8
-    ds: 0x10
-    es: 0x10
-    fs: 0
-    gs: 0
-    ss: 0x10
-    eax: 0x106c95
-    ecx: 0x6aab096c
-    edx: 0x106cec
-    ebx: 0x75e47f04
-    esp: 0x75e47f0c
-    ebp: 0x75e47fac
-    esi: 0x75e47f8c
-    edi: 0x7fffff3c
-    eip: 0x1068bd
-    efl: 0x10216
-
-    <youpi> looks again like a $USER_DS issue
-    <youpi> what's interesting is that that one means that $USER_DS did load in
-      %es fine at least once 
-    <youpi> and it's the reload that fails
-
-
-# Slow SCSI probing
-
-[[!tag open_issue_gnumach]]
-
-
-## IRC, freenode, #hurd, 2012-08-07
-
-    <braunr> youpi: it seems the slow boot on virtualbox is really because of
-      scsi (it spends a long time in scsi_init, probing for all the drivers)
-    <youpi> braunr: we know that
-    <youpi> isn't it in the io port probe printed at boot?
-    <youpi> iirc that was that
-    <braunr> the discussion i found was about eata
-    <braunr> not the whole scsi group
-    <youpi> there used to be another in eata, yas
-    <braunr> oh
-    <braunr> i must have missed the first discussion then
-    <youpi> I mean
-    <youpi> the eata is the first
-    <braunr> ok
-    <youpi> and scsi was mentioned later
-    <youpi> just nobody took the time to track it down
-    <braunr> ok
-    <braunr> so it's not just a matter of disabling a single driver :(
-    <youpi> braunr: I still believe it's a matter of disableing a single driver
-    <youpi> I don't see why scsi in general should take a lot of time
-    <braunr> youpi: it doesn't on qemu, it may simply be virtualbox's fault
-    <youpi> it is, yes
-    <youpi> and virtualbox people say it's hurd's fault, of course
-    <braunr> both are possible
-    <braunr> but we can't expect them to fix it :)
-    <youpi> that's what I mean
diff --git a/open_issues/virtualization.mdwn b/open_issues/virtualization.mdwn
deleted file mode 100644
index 34074c18..00000000
--- a/open_issues/virtualization.mdwn
+++ /dev/null
@@ -1,50 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2013 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_hurd]]
-
-An index of things to work on w.r.t. virtualization.
-
-  * [[/virtualization]]
-
-  * [[hurd/virtualization|hurd/virtualization]]
-
-  * [[GSoC project proposal|community/gsoc/project_ideas/virtualization]]
-
-  * [[hurd/subhurd]] / [[hurd/neighborhurd]]
-
-<!--
-
-  * There's talking about *collectives* in the Hurd RM, on [[/advantages]] and
-    [[unsorted/hurd-migr]] ([[!taglink open_issue_documentation]]).
-
--->
-
-  * [[Implementing_Hurd_On_Top_of_Another_System]]
-
-  * Unix / Linux 
-
-      * [[Capsicum]]
-
-      * [[Virtual_Square_View-OS]]
-
-      * [Namespace file descriptors](http://lwn.net/Articles/407495/),
-        2010-09-29
-
-          * [Divorcing namespaces from
-            processes](http://lwn.net/Articles/377109/), 2010-03-03
-
-  * [[File_Systems]]
-
-  * [[Networking]]
-
-  * [[remap_root_translator]]
-
-  * [[fakeroot]]
diff --git a/open_issues/virtualization/capsicum.mdwn b/open_issues/virtualization/capsicum.mdwn
deleted file mode 100644
index 44503e34..00000000
--- a/open_issues/virtualization/capsicum.mdwn
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-*Capsicum - practical capabilities for UNIX*
-
-<http://www.cl.cam.ac.uk/research/security/capsicum/>
-
-<http://www.lightbluetouchpaper.org/2010/08/12/capsicum-practical-capabilities-for-unix/>
-(server disappeared; [Google
-cache](http://webcache.googleusercontent.com/search?q=cache:cCAqjWOhhksJ:www.lightbluetouchpaper.org/2010/08/12/capsicum-practical-capabilities-for-unix/))
-
-<http://lackingrhoticity.blogspot.com/2010/10/process-descriptors-in-freebsd-capsicum.html>
-
-<http://www.cl.cam.ac.uk/research/security/capsicum/slides/20100811-usenix-capsicum.pdf>
-/ <http://www.youtube.com/watch?v=raNx9L4VH2k>
diff --git a/open_issues/virtualization/fakeroot.mdwn b/open_issues/virtualization/fakeroot.mdwn
deleted file mode 100644
index 441d5c13..00000000
--- a/open_issues/virtualization/fakeroot.mdwn
+++ /dev/null
@@ -1,1330 +0,0 @@
-[[!meta copyright="Copyright © 2010, 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_hurd]]
-
-
-# IRC, freenode, #hurd, 2013-02-26
-
-    <youpi> btw, about fakeroot-hurd
-    <youpi> the remaining issue I see is with argv[0] (yes, again...)
-
-
-## IRC, freenode, #hurd, 2013-04-03
-
-    <youpi> btw, I believe our fakeroot-hurd is close to working actually
-    <youpi> it's just a argv[0] issue supposed to be fixed by exec_file_name
-      but apparently not fixed in that case, for some reason
-
-[[glibc#execve_relative_paths]].
-
-
-## IRC, freenode, #hurd, 2013-08-26
-
-    < teythoon> also I looked into the fakeroot issue, aiui the problem is that
-      scripts are not handled correctly, right?
-    < teythoon> the exec server fails to locate the scripts file name, and so
-      it hands the file_t to the interpreter process and passes /dev/fds/3 as
-      script name
-    < teythoon> afaics that breaks e.g. python
-    < youpi> yes
-    < youpi> pinotree's exec_file_name is supposed to fix that, but for some
-      reason it doesn't work here
-
-[[glibc#execve_relative_paths]].
-
-    < pinotree> it was pochu's, not mine
-    < youpi> ah, right
-    < teythoon> ah I see, I was wondering about that
-    < pochu> it was working for a long time, wasn't it?
-    < pochu> and only stopped working recently
-    < youpi> did it completely stop?
-    < youpi> I have indeed seen odd issues
-    < youpi> I haven't actually  checked whether it has completely stopped
-      working
-    < youpi> probably worth looking there first
-    < pinotree> gtk+3.0 fails, but other stuff like glib2.0 and gtester-using
-      stuff works
-    < teythoon> huh? I created tests like "#!/bin/sh\necho $0" and that says
-      /dev/fd..., and a python script doing the same doesn't even run, so how
-      can it work for a package build?
-    < youpi> it works for me in plain bash
-    < youpi> #!/bin/sh
-    < youpi> echo $0
-    < youpi> € $PWD/test.sh
-    < youpi> /home/samy/test.sh
-    < teythoon> it does !?
-    < youpi> yes
-    < youpi> not in fakeroot-hurd however, as we said
-    < teythoon> well, obviously it works when not being run under
-      fakeroot-hurd, yes
-    < youpi> ok, so we weren't talking about the same thing
-    < youpi> a mere shell script doesn't work in fakeroot-hurd indeed
-    < youpi> that's why we still use fakeroot-sysv
-    < teythoon> right
-    < youpi> err, -tcp
-
-
-## IRC, freenode, #hurd, 2013-11-18
-
-    <teythoon> I believe I figured out the argv[0] issue with fakeroot-hurd
-    <teythoon> but I'm not sure how to fix this
-    <teythoon> first of all, Emilios file_exec_file_name patch set works fine
-
-[[glibc#execve_relative_paths]].
-
-    <teythoon> but not with fakeroot
-    <teythoon>
-      http://git.sceen.net/hurd/hurd.git/blob/HEAD:/exec/hashexec.c#l300
-    <teythoon> check_hashexec tries to locate the script file using a heuristic
-    <teythoon> Emilios patch improves the situation with just providing this
-      information
-    <teythoon> but then, the identity port of the "discovered" file is compared
-      with the id port of the script file
-    <teythoon> to verify if the heuristic found the right file
-    <teythoon> but when using fakeroot-hurd, /hurd/fakeroot proxies all
-      requests
-    <teythoon> but the exec server is outside of the /hurd/fakeroot
-      environment, so it gets the id port from the real filesystem
-    <teythoon> we could skip that test if the script name is explicitly
-      provided though
-    <teythoon> that test was meant to see whether a search through $PATH turned
-      up the right file
-    <braunr> teythoon: nice
-    <teythoon> braunr: thanks :)
-    <teythoon> unfortunately, dpkg-buildpackaging hurd with it still fails for
-      some reason
-    <teythoon> but it is faster than fakeroot-tcp :)
-    <braunr> even chown ?
-    <braunr> or chmod ?
-    <teythoon> dunno in detail, but the whole build is faster
-    <braunr> if you can try it, i'm interested
-    <braunr> because chown/chmod is also slow on linux with fakeroot-tcp
-    <teythoon> i can try...
-    <braunr> so it's probably not a hurd bug
-    <teythoon> braunr: yes, it really is
-    <braunr> no i mean
-    <braunr> chown/chmod being slow with fakeroot-tcp is probably not a hurd
-      bug
-    <braunr> but a fakeroot-tcp bug
-    <teythoon> chowning all files in /usr/bin takes 5.930s with fakeroot-hurd
-      (6.09 with startup overhead) vs 26.42s (26.59s) with fakeroot-tcp
-    <braunr> but try it on linux (fakeroot-tcp i mean)
-    <braunr> although you may want to do it on something you don't care much
-      about :p)
-
-
-## IRC, freenode, #hurd, 2013-12-03
-
-    * teythoon is gonna hunt a fakeroot bug ...
-    <teythoon> % fakeroot-hurd /bin/sh -c ":> /tmp/some_file"
-    <teythoon> /bin/sh: 1: cannot create /tmp/some_file: Is a directory
-    <braunr> ah fakeroot-hurd
-    <teythoon> prevents installing stuff with /bin/install
-    <teythoon> sure fakeroot-hurd, why would i work on the slow one ?
-    <braunr> i don't know
-    <braunr> because it makes chmod/chown/maybe others horrenddously slow
-    <braunr> ?
-    <teythoon> yes, fixing this involves fixing fakeroot-hurd
-    <braunr> are you sure ?
-    <braunr> i prefer repeating just in case: i saw that problem on linux as
-      well
-    <braunr> with fakeroot-sysv
-    <teythoon> so ?
-    <braunr> i'm almost certain it's a pure fakeroot bug, not a hurd bug
-    <braunr> so
-    <teythoon> even if this is fixed, it still has to pay the socket
-      communication overhead
-    <braunr> fixing fakeroot-hurd so that i can be used instead of fakeroot-tcp
-      is a very good thing to do, obviously
-    <braunr> it*
-    <braunr> but it won't solve the chown/chmod speed
-    <braunr> (or, probably won't)
-    <teythoon> huh, why not ?
-    <braunr> 15:53 < braunr> i'm almost certain it's a pure fakeroot bug, not a
-      hurd bug
-    <braunr> when i say it's slow, i should be more precise
-    <braunr> it doesn't show up in top
-    <teythoon> yes, but why would fakeroot-hurd suffer from the same issue ?
-    <braunr> the cpu is almost idle
-    <braunr> oh right, it's a completely different tool
-    <braunr> my bad
-    <braunr> right, right, the proper way to implement fakeroot actually :)
-    <teythoon> yes
-    <teythoon> this will bring near-native speed
-
-
-## IRC, freenode, #hurd, 2013-12-05
-
-    <teythoon> fakeroot-hurd just successfully built mig :)
-    <teythoon> hangs in dh_gencontrol when building gnumach or hurd though
-    <teythoon> i believe it hangs waiting for a lock
-    <teythoon> lock like in file lock that is
-    <teythoon> braunr: no more room for vm_map_find_entry in 80220a40
-    <teythoon> 80220a40 <- is that a task ?
-    <braunr> or a vm_map, not sure
-    <braunr> probably a vm_map
-
-
-## IRC, freenode, #hurd, 2013-12-06
-
-    <teythoon> well, aren't threads a source of endless entertainment ... ?
-    <teythoon> well, I found three more bugs in fakeroot-hurd
-    <teythoon> one of them requires fixing the locking used in fakeroot
-    <braunr> ouch
-    <teythoon> the current code does some lock cycling to aquire a lock out of
-      order
-    <braunr> cycling ?
-    <teythoon> in the netfs_node_norefs function
-    <teythoon> release and reaquire
-    <braunr> i see
-    <teythoon> which imho should be better solved with a weak reference
-    <teythoon> working on it, it no longer deadlocks but i broke something else
-      ...
-    <teythoon> endless fun ;)
-    <braunr> such things could have been done right in the beginning
-    <braunr> ...
-    <teythoon> yes, I wonder
-    <teythoon> libports has weak references
-    <teythoon> but pflocal is the only user
-    <braunr> hm
-    <teythoon> none of the lib*fs support that
-    <braunr> didn't i add one in libdiskfs too ?
-    <braunr> anyway, irrelevant
-    <braunr> weak references are a nice feature
-    <braunr> teythoon: i don't see the cycling you mentioned
-    <braunr> only netfs_node_refcnt_lock being dropped temporarily
-    <teythoon> yep, that one
-    <teythoon> line 145
-    <teythoon> note that due to another bug this code is currently never run
-    <braunr> how surprising ..
-    <braunr> the note about some leak actually gave a hint about that
-    <teythoon> yeah, that leak
-    <teythoon> I think i'm actually very close
-    <teythoon> it's just so frustrating, i thought i got it last night
-    <braunr> good luck then
-    <teythoon> thanks :)
-
-
-## IRC, freenode, #hurd, 2013-12-09
-
-    <teythoon> sweet, i fixed fakeroot-hurd :)
-    <braunr>  /clap
-    <braunr> what was the problem ?
-    <teythoon> lots
-    <braunr> i see
-    <teythoon> it's amazing it actually run as well as it did
-    <braunr> mess strikes again
-    <braunr> i hate messy code ..
-    * teythoon is building half a hurd package using this ... stay tuned ;)
-    <azeem> teythoon: is this going to make building faster as well?
-    <teythoon> most likely, yes
-    <teythoon> fakeroot-tcp is known to be slow, even on linux
-    <braunr> teythoon: are you sure about the transparent retry patch ?
-    <teythoon> pretty sure, why ?
-    <braunr> it's about a more general issue that we didn't fix yet
-    <braunr> our last discussions about it lead us to agree that clients should
-      check the identity of a server before interacting with it
-    <teythoon> braunr: i don't understand, what's the problem here ?
-    <braunr> teythoon: fakeroot does the lookup itself, doesn't it ?
-    <teythoon> yes
-    <braunr> teythoon: but was that also the case before your patch ?
-    <teythoon> braunr: yes
-    <braunr> teythoon: then ok
-    <braunr> teythoon: i guess fakeroot handles requests only for a specific
-      set of calls right ?
-    <braunr> and for others, requests are directly relayed
-    <teythoon> braunr: yes
-    <braunr> and that still is the case, right ?
-    <teythoon> yes
-    <braunr> ok
-    <braunr> looks right since it only affects lookups
-    <braunr> ok then
-    <teythoon> well, fakeroot-hurd built half a hurd package in less than 70
-      minutes
-    <teythoon> a new record for my box
-    <braunr> compared to how much before ?
-    <braunr> (and why half of it ?)
-    <teythoon> unfortunately it hung after signing the packages... some perl
-      process with a /usr/bin/tee child
-    <teythoon> killing tee made it succeed though
-    <teythoon> braunr: i don't build the udeb package
-    <braunr> oh ok
-    <teythoon> braunr: compared with ~75 with fakeroot-tcp and my demuxer
-      rework, ~80 before
-    <braunr> teythoon: nice
-
-
-## IRC, freenode, #hurd, 2013-12-18
-
-    <teythoon> there, i fixed the last fakeroot-hurd bug
-    <teythoon> *whee* :)
-    <teythoon> i thought so many times that i got the last fakeroot bug ...
-    <teythoon> last as in it's in a good enough shape to compile the hurd
-      package that is
-    <teythoon> but now it is
-    <braunr> :)
-    <braunr> this will make glibc and others so much faster to build
-
-
-## IRC, freenode, #hurd, 2013-12-19
-
-    <braunr> teythoon_: hum, you should make the behaviour of fakeroot-hurd on
-      the last client exiting optional
-    <teythoon_> y?
-    <teythoon_> fakeroot-tcp does the very same thing
-    <braunr> fakeroot-hurd is different
-    <braunr> it's part of the file system
-    <teythoon_> yes
-    <braunr> users may want it to stay around
-    <braunr> and reuse it without checking it's actually there
-    <teythoon_> but once the last client is gone, who is ever getting another
-      port to it ?
-    <teythoon_> no
-    <teythoon_> that cannot happen
-    <braunr> really ?
-    <teythoon_> yes
-    <braunr> i thought it was like remap
-    <braunr> since remap is based on it
-    <teythoon_> the same thing applies to remap
-    <teythoon_> only settrans has the control port
-    <braunr> hum
-    <teythoon_> and uses it once to get a protid for the working dir of the
-      initial process started inside the chrooted environment
-    <braunr> you may not want to chroot inside
-    <teythoon_> so ?
-    <teythoon_> then, you get another protid
-    <braunr> i'll make an example
-    <braunr> i create a myroot directory implemented by fakeroot
-    <braunr> populate it
-    <braunr> leave and do something else,
-    <braunr> i might want to return to it later
-    <teythoon_> ah
-    <teythoon_> ok, so you are not using settrans --chroot
-
-[[hurd/settrans/discussion#chroot]].
-
-    <braunr> or maybe i'm confusing the fakeroot translator and fakeroot-hurd
-    <braunr> 10:48 < braunr> you may not want to chroot inside
-    <braunr> yes
-    <teythoon_> hm
-    <teythoon_> ok, so the patch could be changed to check whether the last
-      control port is gone too
-    <braunr> i have no idea of any practical use, but i don't see a valid
-      reason to make a translator go away just because it has no client
-    <braunr> except for resource usage
-    <braunr> and if it's installed as a passive translator
-    <braunr> although that would make fakeroot loose its state
-    <braunr> though remap state is on the command line so it would be fine for
-      it
-    <braunr> see what i mean ?
-    <teythoon_> yes i do
-    <braunr> fakeroot state could be saved in some db one day so it may apply,
-      if anyone feels the need
-    <teythoon_> so what about checking for control ports too ?
-    <braunr> i'm not too familiar with those
-    <braunr> who has the control port of a passive translator ? the parent ?
-    <teythoon_> that should cover the use case you described
-    <teythoon_> for the parent translator
-    <teythoon_> for fsys_getroot requests it has to keep it around
-    <teythoon_> and for more fsys stuff too
-    <braunr> and if active ? settrans ? who just looses it ?
-    <teythoon_> if settrans is used to start an active translator, the parent
-      fs still gets a right to the control port
-    <braunr> ok
-    <braunr> i don't have a clear view of what this implies for fakeroot-hurd
-    <braunr> we'd want fakeroot-hurd to clean all resources including the
-      fakeroot translator on exit
-    <teythoon_> for fakeroot-hurd (or any child translator) this means that a
-      port from the control port class will still exists
-    <teythoon_> so we do not exit
-    <teythoon_> oh, you're speaking of fakeroot.sh ? the wrapper script ?
-    <braunr> probably
-    <braunr> for me, fakeroot-hurd is the command line too, similar to
-      fakeroot-sysv and fakeroot-tcp
-    <braunr> and fakeroot is the translator
-    <teythoon_> yes, agreed
-    <teythoon_> fakeroot-hurd could use settrans --force --chroot ... to force
-      fakeroot to exit if the main chrooted process dies
-    <teythoon_> but that'd kill anything that outlives that process
-    <teythoon_> that might be legitimate, say a process daemonized
-    <teythoon_> so detecting that noone uses fakeroot is the much cleaner
-      solution
-    <braunr> ok
-    <teythoon_> also, that's what fakeroot-tcp does
-    <braunr> which is why i suggested an option for that
-    <teythoon_> why add an option if we can do the right thing without
-      troubling the user ?
-    <braunr> ah, if we can, good
-    <teythoon_> i think we can
-    <teythoon_> I'll rework the patch, thanks for the hint
-    <braunr> so
-    <braunr> just to be clear
-    <braunr> the way you intend it to work is
-    <braunr> wait for all clients and the control port to drop before shutting
-      down
-    <braunr> the control port is dropped when dettaching the translator, right
-      ?
-    <teythoon_> yes
-    <braunr> but hm
-    <braunr> what if clients spawn other processes ?
-    <braunr> they won't find the translator any more
-    <teythoon_> then, that client get's a port to fakeroot at least for it's
-      working dir
-    <teythoon_> so another protid is created
-    <braunr> ah yes, it's usually choorted for such uses
-    <braunr> chrooted
-    <teythoon_> so fakeroot will stick around
-    <braunr> but clients, even from fakeroot, might simply use absolute paths
-    <teythoon_> so ?
-    <braunr> in which case they won't find fakeroot
-    <teythoon_> it will hit fakeroots dir_lookup
-    <teythoon_> sure
-    <braunr> how so ?
-    <teythoon_> if the path is absolute, it will trigger a magic retry of some
-      kind
-    <teythoon_> so the client uses it's root dir port
-    <braunr> i thought the lookup would be done straight from the root fs port
-      ..
-    <teythoon_> which points to fakeroot of course
-    <braunr> ah, chrooted again
-    <teythoon_> that's the whole point
-    <braunr> so this implies clients are chrooted
-    <teythoon_> they are
-    <teythoon_> even if you do another chroot
-    <braunr> what i mean is
-    <teythoon_> that root port also points to a fakeroot port
-    <braunr> if we detach the translator, and clients outside the chroot spawn
-      processes, say shell scripts, they won't find the fakeroot tree
-    <braunr> now, i wonder if we want to actually handle that
-    <braunr> i'm just uncomfortable with a translator silently shutting down
-      because it has no client
-    <teythoon_> if fakeroot is detached, how are clients outside the chroot
-      ever supposed to get a handle to files inside the fakerooted env ?
-    <braunr> it makes sense for fakeroot, so the expected behaviours here aer
-      conflicting
-    <braunr> they had those before fakeroot being detached
-    <teythoon_> then fakeroot wouldn't go away
-    <braunr> right
-    <braunr> unless there is a race but i don't think there is
-    <teythoon_> there isn't
-    <teythoon_> i call netfs_shutdown
-    <braunr> clients get the rights before the parent has a chance to terminate
-    <teythoon_> and only shutdown if it doesn't return ebusy
-    <braunr> makes sense
-    <braunr> ok go ahead :)
-    <teythoon_> cool, thanks for the walk-through ;)
-    <braunr> on the other hand ..
-    <braunr> that's a complicated topic left unfinished by the original authors
-    <teythoon_> one of many
-    <braunr> having translators automatically go away when there is no client
-      may be a good feature
-    <braunr> but it only makes sense for passive translators
-    <braunr> and this should be automated
-    <braunr> the lib*fs libraries should be able to handle it
-    <teythoon_> or, we could go for proper persistence instead
-    <braunr> stay around if active, leave after a while when no more clients if
-      passive
-    <braunr> why ?
-    <teythoon_> clean solution
-    <braunr> persistence looks much more expensive to me
-    <teythoon_> other benefits
-    <braunr> i mean
-    <braunr> persistence looks so expensive it doesn't make sense in a general
-      purpose system
-    <teythoon_> sure, we could make our *fs libs handle this smarter at a much
-      lower cost
-    <teythoon_> don't we get a handle to the underlying file ?
-    <braunr> i think we do yes
-    <teythoon_> if that's actually a file and not a directory, we could store
-      data into it
-    <braunr> many translators are read-only
-    <teythoon_> so ?
-    <braunr> well, when we can write, we can use passive translators instead
-    <braunr> normally
-    <teythoon_> yes
-    <braunr> depends on the fs type actually but you're right, we could use
-      regular files
-    <braunr> or a special type of file, i don't know
-    <antrik> braunr: BTW, I agree that active translators should only go away
-      when no ports are open anymore, while passive ones can exit when control
-      ports are still open but no protids
-    <teythoon> antrik: you mean as a general rule ?
-    <teythoon> that leaves the question how the translator distinguishes
-      between having a passive translator record and not having one
-    <antrik> I believe I already arrived at that conclusion in some design
-      discussion, probaly regarding namespace-based translator selection
-    <antrik> teythoon: yeah, as a general rule
-    <teythoon> interesting
-    <antrik> currently there are command line arguments controling timeouts,
-      but they don't consider control ports IIRC
-    <teythoon> i thought there are problems with shutting down translators in
-      general
-    <antrik> (also, command line arguments seem inconvenient to distinguish the
-      passive vs. active case...)
-    <teythoon> yeah, but we disregard the timeouts in the debian flavor of hurd
-    <antrik> teythoon: err... no we don't. at least not last time I knew. are
-      you confusing this with thread timeouts?
-    <antrik> simple test: do ls -l on /dev, wait a few minutes, compare
-    <teythoon> what do you expect will happen ?
-    <antrik> the unused translators should go away
-    <teythoon> no
-    <antrik> that must be new then
-    <teythoon> might be, yes
-    <teythoon>
-      http://darnassus.sceen.net/gitweb/teythoon/packaging/hurd.git/blame/HEAD:/debian/patches/libports_stability.patch
-    <braunr> antrik: debian currently disables both the global and thread
-      timeouts in libports
-    <braunr> my work on thread destruction consists in part in reenabling
-      thread timeouts, and my binary packages do that well so far :)
-    <antrik> braunr: any idea why the global timeouts were disabled?
-
-
-## IRC, freenode, #hurd, 2013-12-20
-
-    <braunr> antrik: not sure
-    <braunr> but i suspect there could be races
-    <braunr> if a message arrives while the server is going away, i'm not sure
-      the client can determine this and retry transparently
-    <antrik> good point... not sure how that is supposed to work exactly
-
-
-## IRC, freenode, #hurd, 2013-12-31
-
-    <braunr> btw, we should remove the libports_stability patch and directly
-      change the upstream code
-    <braunr> if you agree, i can force the global timeout to 0 (because we're
-      still not sure what can go wrong when a translator goes away while a
-      message is being delivered to it)
-    <braunr> i didn't experience any slowdown with thread destruction however
-    <braunr> so i'm tempted to set that to an actual reasonable timeout value
-      of 30-300 seconds
-    <teythoon> braunr: if you do, please introduce a macro for the default
-      value so it can be changed easily
-    <braunr> teythoon: yes
-    <braunr> i don't understand why these are left as parameters tbh
-    <teythoon> true
-    <braunr> 30 seconds seems to be plenty enough
-
-
-## IRC, freenode, #hurd, 2014-01-17
-
-    <braunr> time to give fakeroot-hurd a shot
-    <braunr> http://darnassus.sceen.net/~rbraun/darnassus_fakeroot_hurd_assert
-    <teythoon> braunr: (wrt fakeroot-hurd) well in my book that shouldn't
-      happen
-    <teythoon> that's why i put the assertion there ;)
-    <braunr> i assumed so :)
-    <teythoon> then again, /me does not agree with "threads" as concurrency
-      model >,<, and that feeling seems to be mutual :p
-    <braunr> ?
-    <teythoon> well, obviously, the threads do not agree with me wrt to that
-      assertion
-    <braunr> the threads ?
-    <teythoon> well, fakeroot is a multithreaded server
-    <braunr> teythoon: i'm not sure i get the point, are you saying you're not
-      comfortable with threads ?
-    <teythoon> that's exactly what i'm saying
-    <braunr> ok
-    <braunr> coroutines/functional i guess ?
-    <teythoon> csp
-    <teythoon> functional not so much
-
-
-## IRC, freenode, #hurd, 2014-01-20
-
-[[open_issues/libpthread]],
-[[open_issues/libpthread/t/fix_have_kernel_resources]].
-
-    <braunr> teythoon: it's perfectly possible that the bug i had with
-      fakeroot-hurd have been caused by my own glibc thread related patches
-    <braunr> has*
-    <teythoon> ok
-    <teythoon> *phew* :p
-    <braunr> :)
-    <teythoon> i wonder if youpi could reproduce his issue on his machine
-    <braunr> what issue ?
-    <braunr> i must have missed something
-    <teythoon> some package failed
-    <teythoon> but he didn't gave any details
-    <teythoon> he wanted to try it on his vm first
-    <braunr> ok
-
-
-## IRC, freenode, #hurd, 2014-01-21
-
-    <braunr> teythoon: i still get the same assertion failure with
-      fakeroot-hurd
-    <braunr> will take a look at that sometimes too
-    <teythoon> braunr: hrm :/
-    <braunr> teythoon: don't worry, i'm sure it's nothing big
-    <braunr> in the mean time, there are updated hurd and glibc packages on my
-      repository with fixed tls and thread destruction
-    <teythoon> cool :)
-
-
-## IRC, freenode, #hurd, 2014-01-23
-
-    <braunr> teythoon: can you briefly explain this fake reference thing in
-      fakeroot when you have some time please ?
-    <teythoon> braunr: fakeroot creates ports to hand out to clients
-    <teythoon> every port represents a node and references a real node
-    <teythoon> fakeroot allows one to set attributes, e.g. file permissions on
-      any node as if the client was root
-    <teythoon> those faked attributes are stored in the node objects
-    <braunr> let's focus on fake_reference please
-    <teythoon> once some attribute is faked, that node has to be kept alive
-    <teythoon> otherwise, that faked information is lost
-    <teythoon> so if the last peropen object is closed and some information is
-      faked, a fake reference is kept
-    <teythoon> as indicated by a flag
-    <braunr> hm
-    <teythoon> in dir lookup, if a node is looked-up that has a fake reference,
-      it is recycled, i.e. the flag cleared and the referecne count is not
-      incremented
-    <teythoon> so every time fakeroot_netfs_release_protid is called b/c, the
-      node in question should not have the fake reference flag set
-    <braunr> what's the relation between the number of hard links and this fake
-      reference ?
-    <teythoon> i don'
-    <teythoon> i don't think fakeroot has a notion of 'hard links'
-    <braunr> it does
-    <braunr> the fake reference is added on nodes with a hard link count
-      greater than 0
-    <braunr> but i guess that just means the underlying node still exists
-    <teythoon> ah yes
-    <teythoon> right
-    <teythoon> currently, if the real node is deleted, the fake node is still
-      kept around
-    <braunr> let's say it's ok for now
-    <teythoon> that's what the comment is talking about, the one that indicates
-      that garbage collection could help here
-    <teythoon> yes
-    <teythoon> properly fixing this is difficult
-    <braunr> agreed
-    <braunr> it would require something like inotify anyway
-    <teythoon> b/c of the way file deletion works
-    <braunr> let's just ignore the issue, that's not what i'm hunting
-    <teythoon> agreed
-    <braunr> the assertion i have is telling us that we're dropping a fake
-      reference
-    <braunr> are we certain this isn't possible ?
-    <teythoon> that function is called if a client dereferences a port
-    <teythoon> in order to have a port in the first place, it has to get it
-      from a dir_lookup
-    <teythoon> the dir lookup turns a fake reference into a real one
-    <teythoon> so i'm certain of that (barring a race condition somewhere)
-    <braunr> ok
-    <braunr> netfs_S_dir_lookup grabs idport_ihash_lock (line 354) but doesn't
-      release it if nn == NULL (lines 388-392)
-    <teythoon> hm, my file numbers are slightly different o_O
-    <braunr> i have printfs around
-    <braunr> sorry :)
-    <teythoon> ok
-    <teythoon> new node unlocks it
-    <teythoon> new_node
-    <braunr> oh
-    <braunr> how unintuitive ..
-    <teythoon> yes, don't blame me ;) that's how it was
-    <braunr> :)
-    <braunr> worse, the description says "if successful" ..
-    <braunr> ah no, the node lock
-    <braunr> ok
-    <teythoon> yes, badly worded description
-    <braunr> i strongly doubt it's a race
-    <teythoon> how do you trigger that assertion failure ?
-    <braunr> dpkg-buildpackage -rfakeroot-hurd -uc -us
-    <braunr> for the hurd package
-    <braunr> very similar to one of your test cases i think
-    <teythoon> umm :-/
-    <braunr> one thing that i find confusing is that fake_reference seems to
-      apply to nodes, whereas release_protid is about, well, protids
-    <braunr> is there a 1:1 relationship ?
-    <braunr> since there is a peropen in the protid, i assume not
-    <braunr> it may be a race actually
-    <braunr> np->references must be accessed with netfs_node_refcnt_lock locked
-    <braunr> hm no, that's not it
-    <teythoon> no, it's not a 1:1 relationship
-    <teythoon> note that the lock idport_ihash_lock serializes most operations,
-      despite it's name indicating that it's only for the hash table
-    <teythoon> the "interesting" operations being dir_lookup and release_protid
-    <braunr> yes
-    <braunr> again, that's another issue
-    <teythoon> why ? that's a pretty strong guarantee already
-    <braunr> ah yes, i was referring to scalability
-    <teythoon> sure
-    <braunr> the assertion is triggered from ports_port_deref in
-      ports_manage_port_operations_multithread
-    <teythoon> but i found it hard to reason about fakeroot, there are multiple
-      locks involved, two kinds of reference counting across different libs
-    <braunr> yes
-    <teythoon> yes, that's to be expected
-    <braunr> teythoon: do we agree that the fake reference is reused by a
-      protid ?
-    <teythoon> braunr: yes
-    <braunr> why is there a ref counter for the protid as well as the peropen
-      then ? :/
-    <teythoon> funny... i thought there was no refcnt for the peropen objects,
-      but there is
-    <teythoon> but for fakeroot-hurd that shouldn't matter, right ?
-    <braunr> i don't know
-    <teythoon> here, one protid object is associated with one peropen object
-    <braunr> yes
-    <teythoon> and the other way around, i.e. it's 1:1
-    <teythoon> so the refcount for those should be identical
-    <braunr> but i get a case where protid has a refcnt of 0 while the peropen
-      has 2 ..
-    <teythoon> umm, that doesn't sound right
-    <braunr> teythoon: ok, it does look like a race on np->references
-    <braunr> node references are protected by a global lock in lib*fs libs
-    <teythoon> yes
-    <braunr> you check it without holding it
-    <braunr> which means another protid can be closed at the same time, setting
-      the flag on the underlying node
-    <braunr> i'll make a proper patch soon
-    <teythoon> they cannot both hold the hash lock
-    <braunr> hm
-    <braunr> teythoon: actually, i don't see why that's relevant
-    <braunr> one thread closes its protid, sets the fakeref flag
-    <braunr> the other does the same, chokes on the assertion
-    <braunr> serially
-    <teythoon> i'm always a little fuzzy when exactly the references get
-      decremented
-    <teythoon> but shouldn't only the second thread set the fakeref flag ?
-    <braunr> well, that's not what i see
-    <braunr> i'll check what happens to this ref counter
-    <teythoon> see how my release_protid function calls netfs_release_protid
-      just after the out label
-    <teythoon> *while holding the big hash lock
-    <teythoon> so, any refcounting should happen while the lock is being held,
-      no ?
-    <braunr> perhaps
-    <braunr> now, my logs show something new
-    <braunr> a case where the protid being released was never printed before
-    <braunr> i.e. not obtained from dir_lookup
-    <braunr> or at least, not fakeroot dir_lookup
-    <teythoon> huh, where did it came from then ?
-    <braunr> no idea
-    <teythoon> only dir_lookup hands out those
-    <braunr> check_openmodes calls dir_lookup too
-    <teythoon> yes, but that's not our dir_lookup
-    <braunr> that's what i mean
-    <braunr> it bypasses fakeroot's custom dir_lookup
-    <braunr> but i guess the reference already exists at this point
-    <teythoon> bypass ? i wouldn't call it that
-    <braunr> you're right, wrong wording
-    <teythoon> it accesses files on other translators
-    <braunr> yes
-    <braunr> the netnode is already present
-    <teythoon> yes
-    <braunr> could it be the root node ?
-    <teythoon> i do not believe so
-    <teythoon> the root node is always faked
-    <teythoon> and is handed out to the first process in the fakeroot env for
-      it's current directory port
-    <teythoon> so you could try something that chdirs away to test that
-      hypothesis
-    <braunr> the assertion looks triggered by a chdir
-    <teythoon> how do you know that ?
-    <braunr> dh_auto_install: error: unable to chdir to build-deb
-    <teythoon> ah
-    <teythoon> well, or that is just the operation after fakeroot died and
-      completely unrelated
-    <braunr> maybe
-    <teythoon> can you trigger this reliably ?
-    <braunr> yes
-    <braunr> i'm trying to write a shell script for that
-    <teythoon> so for you, fakeroot-hurd never succeeded in building a hurd
-      package ?
-    <braunr> no
-    <teythoon> on darnassus ?
-    <braunr> yes
-    <teythoon> b/c i stopped working on fakeroot-hurd when it was in a
-      good-enough shape to build the hurd package
-    <teythoon> >,<
-    <teythoon> maybe my system is not fast enough to hit this race (if it turns
-      out to be one)
-    <braunr> some calls seems to decrease the refcount of the root node
-    <braunr> call*
-    <teythoon> have you confirmed that it's the root node ?
-    <braunr> almost
-    <braunr> i could say yes
-    <braunr> teythoon: actually no, it's not ..
-    <braunr> could be ..
-    <braunr> teythoon: on what node does fakeroot-hurd install the fakeroot
-      translator when used to build debian packages ?
-    <braunr> hum
-    <braunr> could it simply be that the check on np->references should be
-      moved above the assertion ?
-    <teythoon> braunr: it is not bound to any node, check settrans --chroot
-
-[[hurd/settrans/discussion#chroot]].
-
-    <braunr> oh right
-    <braunr> teythoon: ok i mean
-    <braunr> does it shadow / ?
-    <braunr> looks very likely, otherwise the chroot wouldn't work
-    <teythoon> i'm not sure what you mean by shadow
-    <braunr> settrans --chroot cmd -- / /hurd/fakeroot ?
-    <teythoon> but yes, for any process in the chroot-like env every real node
-      is replaced, including /
-    <braunr> makes sense
-    <braunr> teythoon: moving the assertion seems to fix the issue
-    <braunr> intuitively, it seems reasonable to assume the fakeref flag can
-      only be set when there is only one reference, namely the fake reference
-    <braunr> (well, the fake ref, recycled by the last open)
-    <teythoon> no, i don't follow
-    <teythoon> i'd still say, that if ...release_protid is called, then there
-      is no way for the fake flag to be set in the first place
-    <teythoon> that's why i put the assertion in ;)
-    <braunr> on the other hand, you check the refcnt precisely because other
-      threads may have reacquired the node
-    <teythoon> but why would moving the assertion change anything ?
-    <teythoon> if we would do that, we'd "lose" all threads that see
-      np->reference being >1
-    <teythoon> but for those objects the fake_reference flag should never be
-      set anyways
-    <teythoon> i cannot see why this would help
-    <teythoon> (does it help ?)
-    <teythoon> (and if it does, it points to a serious problem imho)
-    <braunr> i'm recreating the traces that made me think that
-    <braunr> to get a clearer view of what's happening
-    <braunr> the problem i have with the current code is this
-    <braunr> there can be multiple protid referring to the same node occurring
-      at the same time
-    <braunr> they are serialized by the hash table lock, ok
-    <braunr> but there apparently are cases where the first (of two) protids
-      being closed sets the fakeref flag
-    <braunr> and the following chokes because the flag is set
-    <braunr> i assume you put this refcount check because you assumed only the
-      last protid being closed can set the flag, right ?
-    <braunr> but then, why > 1 ? why not > 0 ?
-    <teythoon> yes, that's what i was trying to assert
-    <teythoon> b/c the 1 is our reference
-    <braunr> which one exactly ?
-    <teythoon> >1 is anyone *beside* us
-    <teythoon> ?
-    <braunr> hm
-    <braunr> you mean the reference held by the protid being destroyed
-    <teythoon> yes
-    <braunr> isn't that reference already dropped before calling the cleanup
-      function ?
-    <braunr> ah no, it's the node ref
-    <teythoon> yes
-    <braunr> released by netfs_release_protid
-    <teythoon> exactly
-    <braunr> which is called without the hash table lock held
-    <braunr> hm no
-    <braunr> it's locked
-    <braunr> damn my brain is slow today
-    <teythoon> i actually think that it's the combination of manual reference
-      counting and the primitive concurrency model that makes it hard to reason
-      about this
-    <braunr> well
-    <braunr> the model is quite simple too
-    <braunr> accesses to refcounters must be protected by the appropriate lock
-    <braunr> this isn't done here, on the assumption that all referencing
-      operations are protected by another global lock all the time
-    <teythoon> even if a model is simple, this does not mean that it is a good
-      model for human beings to comprehend and reason about
-    <braunr> i don't know
-    <braunr> note that netfs_drop_node is designed to be called with
-      netfs_node_refcnt_lock locked
-    <braunr> implying the refcount must remain stable between checking it and
-      dropping the node
-    <braunr> netfs_make_peropen is called without the hash table lock held in
-      dir_lookup
-    <braunr> and this increases the refcount
-    <braunr> although the problem is rather that something decreases it without
-      the lock held
-    <teythoon> we should port libtsan and just ask gcc -fsanitize=thread
-    <braunr> what about the netfs_nput call at the end of dir_lookup ?
-    <braunr> the fake ref should be set by the norefs function
-    <teythoon> that should not decrease the count to 0 b/c the caller holds a
-      reference too
-    <braunr> yes that's ugly
-    <braunr> ugh
-    <braunr> i'm unable to think clearly right now
-    <teythoon> as mentioned in the commit message, you cannot do something like
-      this in the norefs function
-    <teythoon> bbl ;)
-    <braunr> bye teythoon 
-    <braunr> thanks for your time
-    <braunr> for when you come back :
-    <braunr> instead of maintaining this "fake" reference, why not assumeing
-      the hash table holds a reference, and simply count it
-    <braunr> the same way a cache does
-    <braunr> and drop that reference when removing a node, either to reflect
-      the current state of the underlying node, or because the translator is
-      being shut down ?
-    <braunr> why not assume*
-    <braunr> bbl too
-    <teythoon> sure, refactoring is definitively an option
-
-
-## IRC, freenode, #hurd, 2014-01-24
-
-    <braunr> teythoon: ok, i'll take care of fakeroot
-    <teythoon> braunr: thanks. tbh i was a little fed up with that little
-      bugger >,<
-    <braunr> i can imagine
-    <braunr> considering the number of patches you've sent already
-
-    <braunr> teythoon: are you sure about your call to fshelp_lock_init ?
-    <teythoon> yes, why do you ask ?
-    <teythoon> (the test case is given in the commit message)
-    <braunr> it doesn't look right to me to call "init" while the node is
-      potentially locked
-    <braunr> i noticed libdiskfs peropen release function takes care of
-      releasing locks
-    <braunr> it looks better to me
-    <teythoon> it's not about releasing the lock
-    <teythoon> it's about faking the file being closed which implicitly
-      releases the lock
-    <braunr> the file is being close
-    <braunr> closed
-    <braunr> since it's in the cleanup function
-    <teythoon> yes, but we keep it b/c the file has faked attributes
-    <teythoon> did you look at the problem description in the commit message ?
-    <braunr> we keep the node
-    <braunr> not the peropen
-    <teythoon> so ?
-    <teythoon> the lock is in the node
-    <braunr> why would libdiskfs do it in the peropen release then ?
-    <braunr> there is an inconsistency somwhere
-    <braunr> actually, the lock looks to be per open
-    <braunr> or rather, the lock is per node, but its status is recorded per
-      open
-    <braunr> allowing the implementation to track if a file descriptor was used
-      to install a lock and release it when that file descriptor goes away
-    <teythoon> why would the node be locked ?
-    <teythoon> locked in what way, file-locking locked ?
-    <braunr> yes
-    <braunr> posix explicitely says that file locks must be implicitely removed
-      when closing the file descriptor used to install them, so that makes
-      sense
-    <teythoon> isn't hat exactly what i'm doing ?
-    <braunr> no
-    <braunr> you're initializing the file lock
-    <braunr> init != unlock
-    <braunr> and it's specific to fakeroot, while it looks like libnetfs should
-      be doing it
-    <teythoon> libnetfs would do it
-    <teythoon> but we prevent that by keeping the node alive
-    <braunr> again, it's a per open thing
-    <braunr> and no, libnetfs doesn't release locks implicitely in the current
-      version
-    <teythoon> didn't we agree that for fakeroot one peropen object is
-      associated with one protid object ?
-    <braunr> yes
-    <braunr> and don't keep those alive
-    <braunr> so let them die peacefully, and fix libnetfs so it releases the
-      lock as it's supposed to
-    <braunr> and we* don't
-    <teythoon> we don't keep those alive
-    <teythoon> why would we ?
-    <braunr> yes that's what i wanted to say
-    <braunr> what i mean is
-    <braunr> since letting peropens die is already what is being done
-    <braunr> there is no need for a special handling of locks in fakeroot
-    <teythoon> oh
-    <braunr> on the other hand, libnetfs must be fixed
-    <teythoon> ok, that might very well be true
-    <teythoon> (we need to bring libnetfs and diskfs closer so that they can be
-      diff'ed easily)
-    <braunr> i just wanted to check your reason for using lock_init in the
-      first place
-    <braunr> yes ..
-    <braunr> teythoon: also, i think we actually do have what's necessary to
-      deal with garbage collection
-    <braunr> namely, dead-name notifications
-    <braunr> i'll see if i can cook something simple enough
-    <braunr> otherwise, merely keeping every node around is also acceptable
-      considering the use cases
-    <teythoon> dead-name notifications won't help if the real node disappears,
-      no ?
-    <braunr> teythoon: dead name notifications on the real node port :)
-    <braunr> teythoon: at least i can reliably build the hurd package using
-      fakeroot-hurd now
-    <braunr> let's try glibc :)
-
-## IRC, freenode, #hurd, 2014-01-25
-
-    <teythoon> braunr: awesome :)
-    <braunr> teythoon: hm not sure :/
-    <braunr> darnassus got oom
-    <braunr> teythoon: could be unrelated though
-    <braunr> teythoon: something has apprently made /home unresponsive :(
-    <braunr> teythoon: i suspect bots hitting apache and in particular the git
-      repositories to have increased memory usage
-
-
-## IRC, freenode, #hurd, 2014-01-26
-
-    <braunr> teythoon: btw, fakeroot interacts very very badly with other netfs
-      file systems
-    <braunr> e.g., listing /proc through it creates lots of nodes
-    <braunr> i'm not yet sure how to fix that
-    <braunr> using a dead name notification doesn't seem appropriate (at least
-      not directly) because fakeroot holds a true reference that prevents the
-      deallocation of the target node
-
-
-## IRC, freenode, #hurd, 2014-01-27
-
-    <braunr> teythoon: good news (more or less): fakeroot is actually leaking a
-      lot when crossing file systems
-    <braunr> which means if i fix that, there is a good chance we can use it to
-      build all packages with it
-    <braunr> -with it
-    <teythoon> what do you mean exactly ?
-    <braunr> if target nodes are from /, there is no such leak
-    <braunr> as soon as the target nodes are from another file system, ports
-      rights are leaked
-    <braunr> that's what fills the kernel allocator actually
-    <teythoon> oh, so dir_lookup leaks ports when crossing translator
-      boundaries ?
-    <braunr> seems so
-    <teythoon> yeah, that might very well be it
-    <teythoon> the dir_lookup logic in lib*fs is quite involved :/
-    <braunr> yes, my simple attempts were unsuccessful
-    <braunr> but i'm confident i can fix it soon
-    <teythoon> that sounds good :)
-    <braunr> i also remove the fake_ref flag and replace it with "accounting
-      the reference in the hash table" as soon as a node is faked
-    <teythoon> fine with me
-    <braunr> these will be the expected leak
-    <braunr> but they're far less in numbers than what i observe
-    <braunr> and garbage collection can be implemented later
-    <braunr> although i would prefer notifications a lot more
-    <braunr> end of the news, bbl :)
-    <braunr> found it :>
-    <teythoon> braunr: -v ;)
-    <braunr> err = dir_lookup (...);
-    <braunr> if (dir != dnp->nn->file) mach_port_deallocate (mach_task_self (),
-      dir);
-    <braunr> in other words, deallocate ports for intermediate file system root
-      directories .. :)
-    <braunr> teythoon: currently building hurd and glibc packages
-    <braunr> but i intend to improve some more with the addition of a default
-      faked state
-    <braunr> so that only nodes with modified faked states are retained
-    <teythoon> how do you mark nodes as having the default faked state ?
-    <braunr> i don't
-    <teythoon> ok, right, makes sense :)
-    <teythoon> this sounds awesome, thanks for following up on this
-    <braunr> i'm quite busy with other stuff so, with proper testing, it should
-      take me the week to get merged
-    <braunr> teythoon: well thanks for all the fixes you've done
-    <braunr> fakeroot was completely unusable before that
-    <teythoon> if you push your changes somewhere i'll integrate them into my
-      packages and test them
-    <braunr> ok
-    <braunr> implementing fakeroot -u could also be a good thing
-    <braunr> and this should work easily with that default faked state strategy
-
-
-## IRC, freenode, #hurd, 2014-01-28
-
-    <braunr> teythoon: i should be able to test fakeroot-hurd with the default
-      faked attributes strategy today on glibc
-    <teythoon> braunr: very nice :)
-    <braunr> azeem_: do you happen to know if fakeroot -u is used by debian ?
-    <braunr> i mean when building packages
-    <teythoon> braunr: how does fakeroot-hurd perform on darnassus ?
-    <teythoon> i mean, does it yield a noticeable improvement over fakeroot-tcp
-      just like on my slow box ?
-    <braunr> i'm not measuring that :/
-    <teythoon> ok, no problem
-    <braunr> and since nodes are removed from the hash table, performance might
-      decrease slightly
-    <braunr> but the number of rights is kept very low, as expected
-    <teythoon> that's good
-    <braunr> i keep seeing leaks though
-    <braunr> when switching cwd between file systems
-    <teythoon> humm
-    <braunr> so i assume something is wrong with the identity of . or ..
-    <braunr> it's so insignificant compared to the previous problems that i
-      won't waste time on that
-    <braunr> teythoon: the problem with measuring on darnassus is that it's a
-      public machine
-    <teythoon> right
-    <braunr> often scanned by ssh worms or http bots
-
-[[cannot_create__dev_null__interrupted_system_call]].
-
-    <braunr> but it makes complete sense to get better performance with
-      fakeroot-hurd
-    <braunr> that's actually one of the reasons i'm working on it
-    <braunr> if not the main one
-    <teythoon> :)
-    <teythoon> that was my motivation too
-    <braunr> it shows how you can get an interchangeable unix tool that
-      directly plugs well with the low level system
-    <braunr> and make it work better
-    <teythoon> nicely put :)
-
-    <braunr> teythoon: i still can't manage to build glibc with fakeroot-hurd
-    <braunr> but i'm not sure why :/
-    <braunr> there was no kernel memory exhaustion this time
-    <teythoon> :/
-    <braunr> cp: cannot create regular file `debian/libc-bin.dirs': Permission
-      denied
-    <braunr> hum
-    <braunr> youpi: do you know if building debian packages requires fakeroot
-      -u option ?
-    <youpi> I don't know
-    <gg0> braunr: man dpkg-buildpackage says it just runs "fakeroot
-      debian/rules <target>"
-    <gg0> sources confirm that
-      http://sources.debian.net/src/dpkg/1.17.6/scripts/dpkg-buildpackage.pl#L465
-    <braunr> gg0: ok
-
-
-## IRC, freenode, #hurd, 2014-01-29
-
-    <braunr> it seems that something sets the permissions of this
-      debian/libc-bin.dirs file to 000 ...
-    <teythoon> i've seen this too
-    <braunr> oh
-    <braunr> do you think it's a fakeroot-hurd bug ?
-    <teythoon> have i mentioned something like this in a commit message ?
-    <teythoon> yes
-    <teythoon> it is
-    <braunr> ok
-    <braunr> i didn't see any mention of it
-    <braunr> but i could have missed it
-    <teythoon> hm, i cannot recall it either
-    <teythoon> but i've seen this issue with fakeroot-hurd
-    <braunr> ok
-    <braunr> it's probably the last issue to fix to get it to work for our
-      packages
-    <braunr> teythoon: i think i have a solution for that last mode bug
-    <braunr> fakeroot doesn't relay chmod requests, unless they change an
-      executable bit
-    <braunr> i don't see the point, and simply removed that condition to relay
-      any chmod request
-    <teythoon> braunr: did it work ?
-    <braunr> no
-    <braunr> fakeroot still consumes too many ports
-    <braunr> and for each file, there are at least two ports, the faked one,
-      and the real one
-    <braunr> it should be completely reworked
-    <braunr> but i don't have time to do that
-    <braunr> i'll see if it works when building from scratch
-    <braunr> actually, it's not even a quantity problem but a fragmentation
-      problem
-    <braunr> the function that fails is kmem_realloc ..
-    <braunr> ipc spaces are arrays in kernel space ....
-    <teythoon> it's more like three ports per file, you forgot the identity
-      port
-    <braunr> ah yes
-
-
-## IRC, freenode, #hurd, 2014-02-03
-
-    <braunr> teythoon: i'll commit my changes on fakeroot tonight
-    <braunr> they do improve the tool, but not enough to build glibc with it
-    <teythoon> braunr: cool :), so how do we make it fully usable ?
-    <braunr> teythoon: i don't know ..
-    <braunr> i'll try re adding detection of nodes with no hard links for one
-    <braunr> but imho, it needs a rework based on what the real fakeroot does
-    <braunr> i won't work on it though
-
-    <braunr> teythoon: also, it looks like i've tested building glibc with a
-      wrong test binary of my fakeroot version :/
-    <braunr> so consider all test results irrelevant so far
-
-
-## IRC, freenode, #hurd, 2014-02-04
-
-    <braunr> fakeroot-hurd might turn out to be easily usable for our debian
-      packages with the fixed binary :)
-
-    <braunr> teythoon: hum, can you explain
-      672005782e57e049c7c8f4d6d0b2a80c0df512b4 (trans: fix locking issue in
-      fakeroot) when you have time please ?
-    <braunr> it looks like it introduces a deadlock by calling new_node (which
-      acquires the hash table lock) while dir is locked, violating the hash
-      table -> node locking order
-
-    <teythoon> braunr: awesome, then there still is hope for fakeroot-hurd :)
-
-    <braunr> teythoon: i've been able to build glibc packages several times
-      this night
-    <braunr> so except for this deadlock i've seen once, it looks good
-    <teythoon> right
-    <teythoon> that deadlock
-    <teythoon> right, it does indeed violate the partial order of the locks :-/
-
-    <braunr> teythoon: can you explain why you moved the lock in attempt_mkfile
-      please ?
-
-    <braunr> teythoon: i've just tested a fakeroot binary without the patch
-      introducing the deadlock, and glibc built without any problem
-    <teythoon> braunr: well, this is very good news :)
-    <braunr> teythoon: but i still wonder why you made this patch in the first
-      place, i don't want to revert it blindly and reintroduce a potential
-      regression
-    <teythoon> braunr: i thought i was fixing the order in which locks were
-      taken. if the commit message does not specify that it fixes an issue,
-      then i was probably just wrong and you can revert it
-    <braunr> oh ok
-    <braunr> good
-
-    <braunr> teythoon: another successful build :)
-    <braunr> i'll commit my changes
-    <teythoon> awesome :)
-    <braunr> there might still be concurrency issues but it's much better
-    <teythoon> i'm curious what you did :)
-    <braunr> so little :)
-    <braunr> i was sick all week heh
-    <braunr> you'll se
-    <braunr> see
-    <teythoon> well, that's good actually ;)
-    <braunr> yes
-
-    <braunr> teythoon: actually there was another debugging line left over, and
-      again, my test results are irrelevant @#!
-
-
-## IRC, freenode, #hurd, 2014-02-05
-
-    <braunr> teythoon: i got an assertion about nn->np->nn not being equal to
-      nn atfer the hash table lookup is dir_lookup
-    <braunr> +failure
-    <teythoon> that's bad
-    <braunr> not over yet
-    <teythoon> i had a couple of those too
-    <teythoon> i guess it's a use after free
-    <braunr> yes
-    <teythoon> i used to poison the pointers and comment out the frees to track
-      them down iirc
-    <braunr> teythoon: one of your patches stores netnodes instead of nodes in
-      the hash table, citing some overwriting issue
-    <braunr> teythoon: i don't understand why using netnodes fixes this
-    <teythoon> braunr: libihash has this cookie for fast deletes
-    <teythoon> that has to be stored somewhere
-    <teythoon> the node structure has no room for it
-    <braunr> uh
-    <teythoon> yes
-    <teythoon> it was that bad
-    <braunr> ...
-    <teythoon> hence the uglyish back pointers
-    <braunr> i see
-    <teythoon> looking back i cannot even say why it worked at all
-    <braunr> well, it didn't
-    <teythoon> i believe libihash must have destroyed a linked list in the node
-      struct
-    <braunr> possibly
-    <teythoon> no, it did not >,<, but for simple tests it kind of did
-    <braunr> yes fakeroot sometimes corrupts memory badly ....
-    <braunr> and yes, turns out the assertion is triggered on nodes with 0 refs
-      ..
-    <braunr> teythoon: it looks like even the current version makes wrong usage
-      of the ihash interface
-    <braunr> locp_offset is defined as "The offset of the location pointer from
-      the hash value"
-    <braunr> and indeed, it's an intptr_t
-    <braunr> teythoon: hm no, it looks ok actually, forget what i said :)
-    <teythoon> *phew
-    <teythoon> :p
-
-    <braunr> hmm, still occasional double frees in fakeroot, but it looks in
-      good shape for single threaded tasks like package building
-
-    <braunr> teythoon: i've just sent my fakeroot patches
-    <teythoon> braunr: sweet, i'll have a closer look tomorrow :)
-    <braunr> teythoon: i couldn't debug the double frees though :/
-
-
-## IRC, freenode, #hurd, 2014-02-06
-
-    <braunr> btw, i'm able to successfully use fakeroot-hurd to build glibc
-      packages, but is there a way to make sure the resulting archives contain
-      the right privileges and ownerships ?
-    <youpi> I don't remember whether debdiff checks permissions
-
-    <youpi> braunr: I've just got  fakeroot-hurd debian/rules clean
-    <youpi> dh_clean 
-    <youpi> fakeroot: ../../trans/fakeroot.c:161: netfs_node_norefs: Assertion
-      `np->nn->np == np' failed.
-    <youpi> while building eglibc
-    <teythoon> youpi: yes, that lockup is most annoying... :/
-    <braunr> youpi: with the new version ?
-    <youpi> yes
-    <braunr> hum
-    <braunr> i only had rare double frees, not that any more :/
-    <braunr> youpi: ok i got the error too
-    <braunr> still not good enough
-    <youpi> ok
-
-
-## IRC, freenode, #hurd, 2014-02-07
-
-    <braunr> youpi: debdiff seems to handle permissions
-    <braunr> i've found the cause of the assertions
-    <youpi> braunr: groovie :)
-
-
-## IRC, freenode, #hurd, 2014-02-08
-
-    <teythoon> braunr: nice :)
-    <braunr> http://darnassus.sceen.net/~rbraun/debdiff_report
-
-
-## IRC, freenode, #hurd, 2014-02-10
-
-    <braunr> and, on a completely different topic, here is a crash i can
-      reproduce when using fakeroot:
-      http://darnassus.sceen.net/~rbraun/fakeroot_hurd_rpctrace_o_var_tmp_out_rm_rf_dir.png
-
-
-## IRC, freenode, #hurd, 2014-02-11
-
-    <braunr> still working on fakeroot
-    <braunr> there are still races (not disturbing for package building but
-      still ..)
-    <braunr> there may be wrong right handling
-    <teythoon> i believe i have witnessed a fakeroot deadlock :/
-    <braunr> aw
-    <teythoon> not sure though, buildbot killed the build process before i
-      could investigate
-    <braunr> teythoon: was it a big package ?
-    <teythoon> half of the hurd package
-    <braunr> that's not a port right overflow then
-
-
-## IRC, freenode, #hurd, 2014-03-05
-
-    <teythoon> youpi: what about the exec_filename patch series? even though
-      fakeroot still has some issues (has it?), i consider it worthy for
-      inclusion
-
-[[glibc#execve_relative_paths]].
-
-    <youpi> Roland was disagreeing with it
-    <youpi> iirc the fakeroot issue was solved
-    <teythoon> braunr: ^
-    <braunr> fakeroot goot a lot more robust than it used to be
-    <braunr> but i haven't checked that it actually behaves exactly like the
-      library for corner cases
-    <braunr> there are minor differences
-    <braunr> also, it seems to trigger concurrency bugs in ext2fs
-    <braunr> e.g. git reporting that files either "already exist" or "can't be
-      found"
-    <braunr> it happens (rarely) when directly using ext2
-    <braunr> and more often through fakeroot
-    <braunr> i didn't take the time to investigate
-
-## youpi
-
-    the daily script of debian-installer uses the -s / -i options of fakeroot. How could we manage to implement them?
diff --git a/open_issues/virtualization/file_systems.mdwn b/open_issues/virtualization/file_systems.mdwn
deleted file mode 100644
index a12ea10d..00000000
--- a/open_issues/virtualization/file_systems.mdwn
+++ /dev/null
@@ -1,24 +0,0 @@
-[[!meta copyright="Copyright © 2010 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_hurd]]
-
-Of course, it is possible to use commodity file systems on [[virtualized
-systems|virtualization]], like [[hurd/translator/ext2fs]] or
-[[hurd/translator/nfs]], but there are also other possibilities which ought to
-be explored.
-
-  * [[network_file_system_by_just_forwarding_RPCs]]
-
-  * Linux saw a patch for [*generic name to handle and open by handle
-    syscalls*](http://thread.gmane.org/gmane.linux.file-systems/46648) posted,
-    which in turn can be beneficial for a [[QEMU]] emulation of a 9P file
-    system.  LWN's Jonathan Corbet covered this [*open by
-    handle*](http://lwn.net/Articles/375888/) functionality on 2010-02-23.
diff --git a/open_issues/virtualization/networking.mdwn b/open_issues/virtualization/networking.mdwn
deleted file mode 100644
index 122f21ab..00000000
--- a/open_issues/virtualization/networking.mdwn
+++ /dev/null
@@ -1,88 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2013 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_hurd]]
-
-Collection about stuff that is relevant for *virtualization* and *networking*.
-
-  * [[Virtual_Square_View-OS]]
-
-  * [*Virtual Networks*](http://virtualsquare.org/vn.html)
-
-  * [User Level Networking](http://uln.sourceforge.net/)
-
-  * [Virtual Distributed Ethernet](http://vde.sourceforge.net/)
-
-  * [Application Level
-    Environment4Networking](http://sourceforge.net/projects/ale4net/)
-
-    *Ale4NET used dyn library call diversion to define networking at process
-    level.* -- what we're doing with our approach for overriding the default
-    [[hurd/translator/pfinet]] by setting environment variables.
-
-    Project is now part of [[Virtual_Square_View-OS]].
-
-
-# OpenVPN
-
-[[community/meetings/GHM2013]].
-
-OpenVPN can use pfinet's tun as it is, and be configured completely as joe user,
-as shown below. Note that the tun0 node name has to begin with "tun", so pfinet
-knows it's a tun.
-
-    $ mkdir -p $HOME/servers/socket
-    $ touch $HOME/servers/tun0
-    $ settrans -ca $HOME/servers/socket/2 /hurd/pfinet $HOME/servers/tun0 -a 10.0.0.1 -p 10.0.0.2
-    $ cat vpn.conf
-    client
-    dev tun
-    dev-node /home/samy/servers/tun0
-    ...
-    $ openvpn --config vpn.conf --verb 5
-    ...
-
-So we let openvpn running, and now we can make applications use the pfinet
-TCP/IP stack started above: the remap command below starts a new shell, where
-it redirects /servers/socket/2 (where the system TCP/IP stack resides) onto
-$HOME/servers/socket/2 (where the new TCP/IP stack resides).
-
-    $ remap /servers/socket/2 $HOME/servers/socket/2
-    $ wget www.gnu.org
-
-Ideally openvpn would be made to setup pfinet itself, but at least for now it
-can be configured by hand like that.
-
-It would probably be possible to make pfinet able to produce a tap too, would
-need some code.
-
-## IRC, freenode, #hurd, 2013-09-07
-
-    <d3f> anyone here knows how /dev/net is handled on the hurd? Programs using
-      it say it's not a directory. I tried creating one and setting a netdde
-      translator for a tun device in it, but this may be wrong as it doesn't
-      work
-    <teythoon> d3f: what does /dev/net do?
-    <teythoon> ah, its tun/tap stuff...
-    <d3f> on my gnu/linux it includes a tun device
-    <teythoon> right
-    <d3f> I am still reading about the Hurd and try to understand /hurd/netdde
-      and devnode but by now I am quite sure I will need those to set a tun
-      networktranslator on /dev/net/tun?
-    <teythoon> hm, I don't think netdde or devnode will be of any help
-    <teythoon> afaiui devnode makes mach devices available in the hurdish way,
-      i.e. available for lookup in the filesystem
-    <teythoon> d3f: ping youpi if he shows up, he hacked up openvpn to work on
-      the hurd
-    <d3f> yeah I know, I talked to him as I am tring to get tinc working on the
-      Hurd (tinc builds by now). I will give him a shot about creating the
-      "tun" device
-
-tun has indeed nothing to do with devnode and netdde, it's pfinet which creates it, as documented above.
diff --git a/open_issues/virtualization/remap_root_translator.mdwn b/open_issues/virtualization/remap_root_translator.mdwn
deleted file mode 100644
index 8f8668fe..00000000
--- a/open_issues/virtualization/remap_root_translator.mdwn
+++ /dev/null
@@ -1,157 +0,0 @@
-[[!meta copyright="Copyright © 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_hurd]]
-
-/!\ [[!tag open_issue_documentation]] Does this completely resolve
-[[community/gsoc/project_ideas/server_overriding]]?
-
-
-# IRC, freenode, #hurd, 2013-01-05
-
-    <youpi> so we have a "remap" root translator?
-    <youpi> I  mean this:
-    <youpi> I'd run my shell in a subhurd whose only difference is that the
-      root is not the system's root, but my own
-    <youpi> which catches accesses to /servers/socket/2 for instance
-    <youpi> but leaves the rest flow through the system's root
-    <braunr> there is just boot, i don't think it can do that
-    <youpi> it'd be useful to have that
-    <youpi> it'd be a very useful feature
-    <youpi> to use another tcp/ip stack etc.
-    <braunr> what happens when translators need to locate other translators
-      used by the client ?
-    <youpi> can't it tell the client to ask the real system's root?
-    <youpi> (with the same path)
-    <youpi> I don't remember the exact reply name
-    <braunr> hum, it's getting too fuzzy for my head :p
-    <youpi> well, I mean it's just like translator entries in an ext2fs
-    <youpi> ext2fs replies "not me, this one"
-    <braunr> but what if e.g. a user has its own pflocal, and when calling
-      another translator, that one wants to contact the pflocal used by the
-      client ?
-    <youpi> ah, that won't work of course
-    <braunr> do we actually have such cases btw ?
-    <braunr> procfs perhaps
-    <youpi> I don't think we'd want it actually
-    <braunr> but isn't that required sometimes ?
-    <youpi> inside a shell script, yes
-    <braunr> for example, a storeio translator could ask about the priority
-      properties of the client to proc
-    <youpi> but I don't remember a case where an external translator would need
-      the access
-    <youpi> well, that's actually what we want
-    <youpi> we don't want to fool the storeio with user-provided data :)
-    <braunr> yes
-    <youpi> unless the user starts the storeio himself, in which case he will
-      have to re-root it
-    <braunr> so it has to locate the right translator, despite not using the
-      remap root translator
-    <youpi> err, it will already
-    <youpi> by just using the system's path
-    <braunr> ?
-    <youpi> maybe you need to say exactly what "it" and "right" are :)
-    <braunr> ok, let's imagine your previous example with a subhurd and pfinet
-    <braunr> the remap translator would imply that users from the subhurd
-      *directly* access all services from the main hurd, except when routed
-      otherwise by the remap translator to pfinet
-    <youpi> by "directly", I mean asking the remap translator, which gives as
-      answer "not me, the root"
-    <braunr> now, what if a translator in the main hurd wants e.g. network
-      stats from pfinet, it will ask the main one, not the one obtained through
-      remap
-    <braunr> yes
-    <youpi> that's completely fine
-    <braunr> ah
-    <braunr> that's fine if the results don't matter
-    <youpi> to get network stats from the user pfinet you'd have to be inside
-      the shell using the remap translator
-    <braunr> otherwise they're inconsistent
-    <braunr> yes
-    <youpi> I don't see why you'd want to get the pfinet stats from outside
-    <youpi> you mean ethernet board usage?
-    <braunr> service interactions
-    <braunr> i can't think of anything relevant with pfinet
-    <braunr> but imagine pflocal and credentials
-    <youpi> I believe that'd still be ok
-    <youpi> i.e. things outside the remap want to know the actual system things
-    <youpi> while things inside want to know the remapped things
-    <youpi> and you need that to avoid getting fooled by the user remapping
-    <braunr> for credentials, i think it works because the client provides
-      rights, so it would provide rights to the remapped translators in this
-      case
-    <braunr> this would need to be generalized
-    <youpi> I believe it's already general
-    <braunr> well no
-    <braunr> procfs for example will always talk to the "true" proc server
-    <youpi> sure
-    <youpi> that's what I want from the outside
-    <youpi> if the user, from the inside, wants another view, he'll have to
-      start another procfs
-    <youpi> his own one
-    <braunr> ok
-    <youpi> attached to the remapping
-
-
-## IRC, freenode, #hurd, 2013-01-29
-
-    <youpi> ok, the remap translator was too easy
-    <youpi> just took fakeroot.c
-    <youpi> added if (!strcmp("bin/foo", filename))         filename =
-      "bin/bash"; in 
-    <youpi> netfs_S_dir_lookup
-    <youpi> and it just works
-
-[[hurd/interface/dir_lookup]].
-
-    <youpi> ok, remap does indeed take my own pfinet
-    <youpi> good :)
-    <youpi> pfinet's tun seems to be working too
-    <youpi> it's however not really flexible, it has to show up in /dev/tunx
-    <youpi> I'll have a look at fixing that
-    <youpi> yep, works fine
-
-
-## IRC, freenode, #hurd, 2013-02-01
-
-    <youpi> braunr: as I expected, simply passing FS_RETRY_REAUTH does the
-      remapping trick
-
-
-# IRC, freenode, #hurd, 2013-02-12
-
-    <braunr>
-      http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/server_overriding/
-    <braunr> youpi: isn't that your remap translator ?
-    <youpi> completely
-    <youpi> remap being (5)
-
-
-# IRC, freenode, #hurd, 2013-02-25
-
-    <youpi> I'm just having an issue with getcwd getting in the sky
-    <youpi> I wonder whether libc might need patching to understand it's in
-      some sort of chroot
-    <youpi> or perhaps remap fixed into avoiding .. of / being odd
-    <youpi> erf, it's actually an explicit error
-    <youpi> libc just doesn't want to have a ".." / being different from CRDIR
-    <youpi> let me just comment out that :)
-    <youpi> way better :)
-    <youpi> yep, just works fine
-
-
-# IRC, freenode, #hurd, 2013-03-16
-
-    <braunr> youpi: is the /bin/remap --help output correct ?
-
-
-# [[hurd/fsysopts]]
-
-Doesn't support [[hurd/fsysopts]].
diff --git a/open_issues/visudo.mdwn b/open_issues/visudo.mdwn
deleted file mode 100644
index 4e87fd8d..00000000
--- a/open_issues/visudo.mdwn
+++ /dev/null
@@ -1,22 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-[[!meta title="visudo: /etc/sudoers is busy, try again later"]]
-
-[[!tag open_issue_hurd]]
-
-visudo does not work:
-
-    /etc/sudoers is busy, try again later
-
-Apparently there is some [[file_locking]] that sudo does which does not
-work. Uninvestigated for now.
-
-One can just edit the /etc/sudoers file and take care of correctness by hand.
diff --git a/open_issues/vm_map_kernel_bug.mdwn b/open_issues/vm_map_kernel_bug.mdwn
deleted file mode 100644
index 159e9d04..00000000
--- a/open_issues/vm_map_kernel_bug.mdwn
+++ /dev/null
@@ -1,71 +0,0 @@
-[[!meta copyright="Copyright © 2012, 2013 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_gnumach]]
-
-
-# IRC, frenode, #hurd, 2012-11-04
-
-    <tschwinge> braunr, pinotree, youpi: Has either of you already figured out
-      what [glibc]/sysdeps/mach/hurd/dl-sysdep.c:fmh »XXX loser kludge for
-      vm_map kernel bug« is about?
-    <pinotree> tschwinge: ETOOLOWLEVELFORME :)
-    <pinotree> tschwinge: 5bf62f2d3a8af353fac661b224fc1604d4de51ea added it
-    <braunr> tschwinge: no, but that looks interesting
-    <braunr> i'll have a look later
-    <tschwinge> Heh, "interesting".  ;-)
-    <tschwinge> It seems related to vm_map's mask
-      parameter/ELF_MACHINE_USER_ADDRESS_MASK, though the latter in only used
-      in the mmap implementation in sysdeps/mach/hurd/dl-sysdep.c (in mmap.c, 0
-      is passed; perhaps due to the bug?).
-    <tschwinge> braunr: Anyway, I'd already welcome a patch to simply turn that
-      into a more comprehensible form.
-    <braunr> tschwinge: ELF_MACHINE_USER_ADDRESS_MASK is defined as "Mask
-      identifying addresses reserved for the user program, where the dynamic
-      linker should not map anything."
-    <braunr> about the vm_map parameter, which is a mask, it is described by
-      "Bits asserted in this mask must not be asserted in the address returned"
-    <braunr> so it's an alignment constraint
-    <braunr> the kludge disables alignment, apparently because gnumach doesn't
-      handle them correctly for some cases
-    <tschwinge> braunr: But ELF_MACHINE_USER_ADDRESS_MASK is 0xf8000000, so I'd
-      rather assume this means to restrict to addresses lower than 0xf8000000.
-      (What are whigher ones reserved for?)
-    <braunr> tschwinge: the linker i suppose
-    <braunr> tschwinge: sorry, i don't understand what
-      ELF_MACHINE_USER_ADDRESS_MASK really is used for :/
-    <braunr> tschwinge: it looks unused for the other systems
-    <braunr> tschwinge: i guess it's just one way to partition the address
-      space, so that the linker knows where to load libraries and mmap can
-      still allocate large contiguous blocks
-    <braunr> tschwinge: 0xf8000000 means each "chunk" of linker/other blocks
-      are 128 MiB large
-    <tschwinge> braunr: OK, thanks for looking.  I guess I'll ask Roland about
-      it.
-    <braunr> it could be that gnumach isn't good at aligning to large values
-
-[[!message-id "87fw4pb4c7.fsf@kepler.schwinge.homeip.net"]]
-
-
-# IRC, frenode, #hurd, 2013-01-22
-
-In context of [[libpthread]].
-
-    <braunr> pinotree: do you understand what the fmh function does in
-      sysdeps/mach/hurd/dl-sysdep.c ?
-    <braunr> ok i understand what it does
-    <braunr> and youpi has changed the code, so he does too
-    <braunr> youpi: do you have a suggestion about how to solve this issue in
-      the fmh function ?
-    <youpi> do we remember which bug it's after?
-    <braunr> what do you mean ?
-    <braunr> ah
-    <braunr> no :/
-    <braunr> it could be a good occasion to get rid of it, yes
diff --git a/open_issues/wait_errors.mdwn b/open_issues/wait_errors.mdwn
deleted file mode 100644
index 855b9add..00000000
--- a/open_issues/wait_errors.mdwn
+++ /dev/null
@@ -1,25 +0,0 @@
-[[!meta copyright="Copyright © 2012 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]]
-
-# IRC, freenode, #hurd, 2012-07-12
-
-    <braunr> tschwinge: have you encountered wait() errors ?
-    <tschwinge> What kind of wait errors?
-    <braunr> when running htop or watch vmstat, other apparently unrelated
-      processes calling wait() sometimes fail with an error
-    <braunr> i saw it mostly during builds, as they spawn lots of children
-    <braunr> (and used the aforementioned commands to monitor the builds)
-    <tschwinge> Sounds nasty...  No, don't remember seeing that.  But I don't
-      typiclly invoke such commands during builds.
-    <tschwinge> So this wait thing suggests there's something going wrong in
-      the proc server?
-    <braunr> tschwinge: yes
diff --git a/open_issues/wayland.mdwn b/open_issues/wayland.mdwn
deleted file mode 100644
index 67f78b1d..00000000
--- a/open_issues/wayland.mdwn
+++ /dev/null
@@ -1,33 +0,0 @@
-[[!meta copyright="Copyright © 2012 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_porting]]
-
-IRC, freenode, #hurd, 2012-03-18:
-
-    <antrik> Wayland should be very portable. all the system dependencies are
-      in the infrastructure, such as DRI
-    <antrik> we have had a DRI task (for X.Org) for years
-    <antrik> (in fact I would be the right person to implement this,
-      considering my background -- by quite frankly, I doubt I'll ever do it)
-    <tschwinge> http://xorg.freedesktop.org/wiki/Hurd_Porting
-
-IRC, freenode, #hurd, 2012-03-20:
-
-    <youlysses> Is wayland something that will be semi-easy to port to the
-      hurd? I saw GNOME is heading in this direction.
-    <pinotree> wayland at the moment is linux only
-    <tschwinge> youlysses: A DRI implementation will be needed.
-    <pinotree> that, and libdrm compiling
-    <youlysses> So it will take some work ... but theres no *HUGE* design
-      decison that would inhibit it?
-    <pinotree> i know it uses epoll, for instance
-    <tschwinge> youlysses: I cannot judge how complex a DRI system is, and how
-      much needs to be designed vs. implemented.
diff --git a/open_issues/whole_system_debugging.mdwn b/open_issues/whole_system_debugging.mdwn
deleted file mode 100644
index b438c5cf..00000000
--- a/open_issues/whole_system_debugging.mdwn
+++ /dev/null
@@ -1,19 +0,0 @@
-[[!meta copyright="Copyright © 2012 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_gdb open_issue_gnumach]]
-
-Given our distributed system structure, it'd be immensely useful then when a
-[[RPC]] to another entitiy is made, [[GDB]] followed suit.
-
-[[GDB]] does have some *multi-process* debugging infrastructure which should
-basically be usable for this.
-
-[[`mach_msg`|microkernel/mach/message]] is the *great barrier*, of course.
diff --git a/open_issues/wine.mdwn b/open_issues/wine.mdwn
deleted file mode 100644
index ea91e5a6..00000000
--- a/open_issues/wine.mdwn
+++ /dev/null
@@ -1,182 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011, 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_porting]]
-
-On 2010-11-28, Austin English contacted us, stating that he's working on
-porting [Wine](http://winehq.org/) to the GNU/Hurd.
-
-It is not yet clear how difficult this is going to be, what sort of
-requirements Wine has: only libc / POSIX / etc., or if there are
-*advanced* things like [[system_call]] trapping involved, too.
-
-[[Samuel|samuelthibault]] suspects that *there's some need for LDT table
-allocation. There is kernel support for this,* however.
-
-
-# IRC, freenode, #hurd, 2011-08-11
-
-    < arethusa> I've been trying to make Wine work inside a Debian GNU/Hurd VM,
-      and to that end, I've successfully compiled the latest sources from Git
-      after installing the libc (devel) packages from experimental and
-      personally patching Wine with http://pastebin.com/rg6dx09G
-
-[[rg6dx09G.patch]]
-
-    < arethusa> my question is, when trying to launch Wine, I'm seeing "wine
-      client error:0: sendmsg: (os/kern) invalid address" from the client side,
-      whereas the wineserver seems to be starting and running correctly, how
-      could I debug this issue further? using rpctrace doesn't seem to help, as
-      the trace just hangs when run on the Wine loader instead of yielding
-      insight
-    < kilobug> arethusa: isn't there a wine debuguer that can start a gdb when
-      wine encounters an error or something like that ?
-    < arethusa> it's too early for that
-    < kilobug> or least give you a full traceback of the wine code where the
-      error occur ?
-    < arethusa> the error is happening during initial connect to the
-      wineserver, in dlls/ntdll/server.c
-    < arethusa> but that doesn't help me figure out why sendmsg would error out
-      in this way
-    < arethusa>
-      http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/server.c#l361
-    < azeem_> arethusa: probably some of the msghdr entries are not supported
-      by the Hurd's glib
-    < azeem_> c
-    < pinotree> haha, socket credentials, which we don't support yet
-    < azeem_> yep
-    < pinotree> youpi: ↑ another case ;)
-    < azeem_> arethusa: just implement those and it should work
-    < kilobug> in pflocal ? or glibc ?
-    < pinotree> pflocal
-    < arethusa> azeem_: hmm, okay, thanks
-    < pinotree> arethusa: their lack is a known issue, and makes things like
-      dbus and gamin not work
-    < arethusa> it's
-      https://www.gnu.org/software/hurd/open_issues/sendmsg_scm_creds.html and
-      related links I assume?
-
-[[sendmsg_scm_creds]]
-
-    < youpi> yes
-    < pinotree> (but that patch is lame)
-
-
-# IRC, freenode, #hurd, 2013-10-02
-
-    <gnu_srs> youpi: I've come a little further with wine, see debian bug
-      #724681 (same problem).
-    <gnu_srs> Now the problem  is probably due to the specific address space
-      and stack issues to be
-    <gnu_srs> fixed for wine to run as braunr pointed out some months ago
-      (IRC?) when we discussed wine.
-
-
-# IRC, freenode, #hurd, 2013-12-29
-
-    <Andre_H> Hi,
-      http://www.gnu.org/software/hurd/open_issues/sendmsg_scm_creds.html seems
-      fixed in Debian GNU/Hurd 2013, do you know which patch they used? i
-      already asked in their channel, but well, there are only 18 people :)
-    <youpi> Andre_H: it hasn't been fixed in Debian GNU/Hurd. Work is discussed
-      on the bug-hurd mailing list
-    <Andre_H> youpi: thx for the info, i wonder why wine now works with some
-      hacks, but didn't in the past
-    <youpi> I guess some circumvention patch was added to wine
-    <youpi> does it actually really work, as in running applications for real?
-    <youpi> (I've nevere tried)
-    <Andre_H> youpi: i'm a wine developer and haven't seen circumventions for
-      hurd... i also just tried winelib apps last night, will try... let's say
-      powerpoint viewer today
-    <gnu_srs> Andre_H: How did you make wine run? I have patches for wine-1.4.1
-      and 1.6.1 to build (so far unpublished), but it does not yet run
-      properly.
-    <gnu_srs> test case: wine notepad
-    <Andre_H> gnu_srs: what's happening when you try that?
-    <gnu_srs> Andre_H: Currently it hangs at connect() (after creating the
-      /tmp/.wine1000/.../socket, etc, and starting again)
-    <gnu_srs> seems to be some problem with the HURD_DPORT_USE macro in eglibc,
-      investigation ongoing
-    <Andre_H> gnu_srs: well, i'm using the debian distro, maybe you're on
-      something else? you could also pastebin your hacks, so i could have a
-      look. i'm about to clean mine up to send them upstream... ntdll will be
-      quite hard...
-
-
-## IRC, freenode, #hurd, 2013-12-30
-
-    <gnu_srs> wine runs:)
-    <gnu_srs> It's just extremely slow.,..
-
-    <gnu_srs> gg0: please don't reopen #733604 , I've filed an updated one:
-      #7336045
-    <gnu_srs>  #733605
-    <gg0> gnu_srs: i've reassigned it from wine-1.6 (nonexistent) to wine
-      (correct), then to src:wine (more correct), but between such
-      reassignments you closed it so found command in the latter made it
-      reopening
-    <gg0> then i realized you could mess up bugs on your own, without help :)
-    <gnu_srs> gg0: tks anyway, now it is src:wine and the title is right. Maybe
-      you should have noted me on IRC?
-
-    <Andre_H> gnu_srs: what's your status about wine? i'm still about to get
-      things upstream...
-    <gnu_srs> Andre_H: see debian bug #733605
-
-
-## IRC, freenode, #hurd, 2013-12-31
-
-    <Andre_H> gnu_srs: i didn't need the patches for
-      dlls/mountmgr.sys/diskarb.c, maybe due to missing headers
-
-
-## IRC, freenode, #hurd, 2014-01-06
-
-    <Andre_H> Wanted to note that
-      http://www.gnu.org/software/hurd/open_issues/wine.html is wrong about
-      socket credentials, afaik they are still not implemented but that doesn't
-      block Wine anymore
-    <Andre_H> In fact all you need to run Wine are the patches followed by
-      https://source.winehq.org/patches/data/101439 (not yet upstream) or see
-      http://wiki.winehq.org/Hurd
-
-    <braunr> Andre_H: thanks for your report
-    <Andre_H> np :)
-    <Andre_H> braunr: can someone update
-      http://www.gnu.org/software/hurd/open_issues/wine.html please?
-    <braunr> Andre_H: well, you can :)
-    <Andre_H> log in with google -> check guidelines of your wiki -> try out
-      your wiki syntax -> laziness alarm :)
-    <gnu_srs> Andre_H: The reason why wine runs now is a bug in SCM_CREDS was
-      fixed, see the wine-devel ML.
-
-    <gnu_srs> Andre_H: s/SCM_CREDS/SCM_RIGHTS/
-    <Andre_H> gnu_srs: already updated our wiki :)
-    <Andre_H> gnu_srs: would you mind updating yours:
-      http://www.gnu.org/software/hurd/open_issues/wine.html :)
-
-    <Andre_H> gnu_srs: two commits for wine are in now :)
-
-
-## IRC, freenode, #hurd, 2014-01-11
-
-    <gnu_srs1> Andre_H: Looks like the two committed patches did not go into
-      wine-1.6.2:-(
-    <gnu_srs1> Additionally, your PATH_MAX fixes was not accepted?
-    <Andre_H> gnu_srs1: well, the stable branch is called stable because not
-      everything get's there :)7
-    <Andre_H> gnu_srs1: the PATH_MAX patch needs more thinking...
-
-## IRC, freenode, #hurd, 2015-02-09
-
-    <Andre_H> since Wine 1.7.28 it runs quite well on Gnu/Hurd - wiki.winehq.org/Hurd
-    <Andre_H> ( https://source.winehq.org/git/wine.git/commitdiff/6d50cfcac28f84e07777fc10874887356832102e )
-
diff --git a/open_issues/wrong_reply_message_id.mdwn b/open_issues/wrong_reply_message_id.mdwn
deleted file mode 100644
index e84e2571..00000000
--- a/open_issues/wrong_reply_message_id.mdwn
+++ /dev/null
@@ -1,23 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2009 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]]."]]"""]]
-
-[[!meta title="(ipc/mig) wrong reply message ID"]]
-
-[[!tag open_issue_gnumach open_issue_mig open_issue_glibc]]
-
-    <tschwinge> # settrans -P -a /servers/socket/2 /hurd/pfinet -i eth0 -a 192.168.10.61 -g 192.168.10.1 -m 255.255.255.0
-    <tschwinge> Translator pid: 2289
-    <tschwinge> Pausing...
-    <tschwinge> pfinet: /build/buildd/hurd-20080607/build-tree/hurd/libports/create-internal.c:115: _ports_create_port_internal: Unexpected error: (ipc/mig) wrong reply message ID.
-    <neal> it would be nice to print out the id when those sorts of errors occur.
-
-This error code is `MIG_REPLY_MISMATCH` and can be returned in GNU Mach's
-`kern/exception.c (exception_parse_reply)`, in MIG-generated code, see `user.c
-(WriteCheckIdentity)`, and in glibc's `sysdeps/mach/hurd/ioctl.c (__ioctl)`.
diff --git a/open_issues/xattr.mdwn b/open_issues/xattr.mdwn
deleted file mode 100644
index c6b9d8f7..00000000
--- a/open_issues/xattr.mdwn
+++ /dev/null
@@ -1,55 +0,0 @@
-[[!meta copyright="Copyright © 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]]."]]"""]]
-
-[[!meta title="xattr: extended attributes"]]
-
-[[!tag open_issue_glibc open_issue_hurd]]
-
-This task is listed as a [[Google Summer of Code project
-idea|community/gsoc/project_ideas/xattr]].
-
-IRC, freenode, #hurd, 2011-06-01:
-
-    <gnu_srs> Another thing: the lsattr and chattr programs seems to be bogus
-      on Hurd. Are they present since they are part of e2fsprogs?
-    <youpi> I don't think the Hurd has an interface for it
-    <tschwinge> gnu_srs, youpi: lsattr/chattr are extended attributes, right?
-      We do have some patches from years ago for adding some support in glibc,
-      but they're not yet integrated.  And also we do have a plan for using
-      these instead of our Hurd-specific passive translator information in
-      inodes.
-
-If interested in working on this, talk to [[tschwinge]], and see these resources:
-
-  * [[!GNU_Savannah_task 5503]], [[!GNU_Savannah_patch 5126]]
-
-  * <http://lists.gnu.org/archive/html/bug-hurd/2006-02/threads.html#00115>,
-    <http://lists.gnu.org/archive/html/bug-hurd/2006-01/threads.html#00180>,
-    <http://lists.gnu.org/archive/html/bug-hurd/2006-05/threads.html#00042>
-
-  * <http://www.spinics.net/lists/linux-ext4/msg07260.html>,
-    <http://www.spinics.net/lists/linux-ext4/msg07259.html>,
-    <http://www.spinics.net/lists/linux-ext4/msg07261.html>
-
-
-IRC, OFTC, #debian-hurd, 2012-03-18:
-
-    <pinotree> notes to self: it seems our ext2 driver comes from linux 2.3.42
-      or so, and in linux 2.5.46 ext2/ext3 get xattr and acl support
-
-
-# Test Cases
-
-## IRC, freenode, #hurd, 2013-12-06:
-
-    <gnu_srs> for fakeroot t.xattr test fails, a known issue?
-    <braunr> the test must probably be disabled
-    <braunr> the hurd doesn't support extended attributes currently
diff --git a/open_issues/xen_crash_copy-size_le_page_size.mdwn b/open_issues/xen_crash_copy-size_le_page_size.mdwn
deleted file mode 100644
index f2d8081e..00000000
--- a/open_issues/xen_crash_copy-size_le_page_size.mdwn
+++ /dev/null
@@ -1,104 +0,0 @@
-[[!meta copyright="Copyright © 2009 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_xen]]
-
-`/dev/hd2` is 2 GiB in size (backed by LVM), unformatted.
-
-    # mkfs.ext2 -o hurd /dev/hd2
-    mke2fs 1.41.7 (29-June-2009)
-    hd2 count 1
-    re-open, hd2 count 2
-    ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing mtab file while determining whether /dev/hd2 is mounted.
-    re-open, hd2 count 3
-    re-open, hd2 count 4
-    re-open, hd2 count 5
-    Filesystem label=
-    OS type: Hurd
-    Block size=4096 (log=2)
-    Fragment size=4096 (log=2)
-    131072 inodes, 524288 blocks
-    26214 blocks (5.00%) reserved for the super user
-    First data block=0
-    Maximum filesystem blocks=536870912
-    16 block groups
-    32768 blocks per group, 32768 fragments per group
-    8192 inodes per group
-    Superblock backups stored on blocks: 
-            32768, 98304, 163840, 229376, 294912
-    
-    Assertion `copy->size <= PAGE_SIZE' failed in file "../gnumach-1-branch-Xen-branch/xen/block.c", line 536
-    Kernel Breakpoint trap, eip 0x20020a77
-    Stopped at  0x20020a76: int     $3
-    db> trace
-    0x20020a76(2006abc1,2006ba03,2006782c,218,2e2be8d4)
-    0x20020ace(2006ba03,2006782c,218,2e3629a0,32000)
-    0x2003e9d5(2de04764,2e2be0b8,12,0,3fff80)
-    0x200476e6(2de5ad54,2e2db010,2e30a9a0,2de3a854,2de5ad44)
-    0x20021ed4(2de5ad44,2e2bb2e0,2e2bb2a0,0,0)
-    0x2005309d(129b8f0,3,38,28,e)
-    0x20006838(129b8f0,3,38,28,e)
-    >>>>> user space <<<<<
-
-
-    $ addr2line -i -f -e /boot/gnumach-xen 0x20020a76 0x20020ace 0x2003e9d5 0x200476e6 0x20021ed4 0x2005309d 0x20006838
-    Debugger
-    /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/debug.c:105
-    Assert
-    ??:0
-    device_write
-    /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/xen/block.c:537
-    _Xdevice_write
-    /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/device/device.server.c:253
-    ipc_kobject_server
-    /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/ipc_kobject.c:201
-    mach_msg_trap
-    /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/ipc/mach_msg.c:1367
-    mach_call_call
-    /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/i386/i386/locore.S:1083
-
-GDB on `mkfs.ext2`:
-
-    raw_write_blk (channel=0x80829d8, data=0x8082a40, block=524272, count=8, buf=0x80a0a60) at ../../../git/lib/ext2fs/unix_io.c:272
-    272             actual = write(data->dev, buf, size);
-    (gdb) print size
-    $4 = 32768
-    (gdb) bt
-    #0  raw_write_blk (channel=0x80829d8, data=0x8082a40, block=524272, count=8, buf=0x80a0a60) at ../../../git/lib/ext2fs/unix_io.c:272
-    #1  0x080635fc in unix_write_blk64 (channel=0x80829d8, block=524272, count=8, buf=0x80a0a60) at ../../../git/lib/ext2fs/unix_io.c:673
-    #2  0x0806373c in unix_write_blk (channel=0x80829d8, block=524272, count=8, buf=0x80a0a60) at ../../../git/lib/ext2fs/unix_io.c:705
-    #3  0x0805e87d in ext2fs_zero_blocks (fs=0x8082940, blk=524272, num=16, ret_blk=0x15ffb1c, ret_count=0x0)
-        at ../../../git/lib/ext2fs/mkjournal.c:182
-    #4  0x0804ec56 in main (argc=131072, argv=0x80000) at ../../git/misc/mke2fs.c:2032
-
-Discussion:
-
-    <tschwinge> I had a look at the code, but unfortunately don't really know
-      how this data transfers between Xen and the domU work.
-    <tschwinge> Well, I know how it roughly works, but not the implementation
-      deatils.
-    <youpi> well here it's not about the xen/domU transfers
-    <youpi> it's about copying data to align it
-    <youpi> i.e. when offset is not aligned, I need to copy it
-    <tschwinge> Yes-
-    <youpi> I was lazy, just implemented it for things smaller than a page
-    <youpi> it just needs to be extended into copying several pages
-    <tschwinge> youpi: Hmm, do we need to copy all the data to shift away the
-      offset or is there a better way?
-    <youpi> the blkbackend needs data to be sector-aligned
-    <youpi> just aligning on a page makes offset computation simpler
-    <youpi> as it's rare that's not a problem
-    <tschwinge> And a sector is the usual 512 bytes there, I assume?
-    <tschwinge> But then we do need to copy all of it?
-    <youpi> let me check
-    <youpi> the sector is the granularity you can't go below
-    <youpi> sector is the sector_size reported by the backend
-    <youpi> but for sector_number and first/last_sect it's 512
-    <youpi> yes, that's weird
diff --git a/open_issues/xen_domu_with_ro_hd.mdwn b/open_issues/xen_domu_with_ro_hd.mdwn
deleted file mode 100644
index efbd2d18..00000000
--- a/open_issues/xen_domu_with_ro_hd.mdwn
+++ /dev/null
@@ -1,35 +0,0 @@
-[[!meta copyright="Copyright © 2010 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]]."]]"""]]
-
-[[!meta title="Xen domU with a read-only HD"]]
-
-[[!tag open_issue_xen]]
-
-read-only hd3
-
-    foobar:~# e2fsck /dev/hd3
-    e2fsck 1.40.11 (17-June-2008)
-    re-open, hd3 count 5
-    re-open, hd3 count 6
-    /dev/hd3 was not cleanly unmounted, check forced.
-    Pass 1: Checking inodes, blocks, and sizes
-    Pass 2: Checking directory structure
-    Pass 3: Checking directory connectivity
-    Pass 4: Checking reference counts
-    Pass 5: Checking group summary information
-    /dev/hd3: 2729/262144 files (0.2% non-contiguous), 34116/524288 blocks
-    Error writing block 1 (Attempt to write block from filesystem resulted in short write).  Ignore error<y>? yes
-
-    foobar:~# e2fsck /dev/hd3
-    e2fsck 1.40.11 (17-June-2008)
-    re-open, hd3 count 7
-    re-open, hd3 count 8
-    e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/hd3
-    Could this be a zero-length partition?
diff --git a/open_issues/xen_lseek.mdwn b/open_issues/xen_lseek.mdwn
deleted file mode 100644
index 756abf5e..00000000
--- a/open_issues/xen_lseek.mdwn
+++ /dev/null
@@ -1,57 +0,0 @@
-[[!meta copyright="Copyright © 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_xen]]
-
-IRC, freenode, #hurd, 2011-09-01:
-
-    <youpi> hum, f951 does myriads of   71->io_seek_request (32768 0) = 0 32768
-    <youpi> no wonder it's slow
-    <youpi> unfortunately that's also what it does on linux, the system call is
-      just less costly
-    <youpi> apparently gfortran calls io_seek for, like, every token of the
-      sourced file
-    <youpi> (fgetpos actually, but that's the same)
-    <youpi> and it is indeed about 10 times slower under Xen for some reason
-
-IRC, freenode, #hurd, 2011-11-02:
-
-    <youpi> btw, we have a performance issue with xen
-    <youpi> an lseek() call costs a huge lot
-    <youpi> like 1ms
-    <youpi> while the same costs just a few dozens µs with kvm
-    <youpi> there's of course the cost of switching between ring3, ring0,
-      ring1, ring0, ring3, but still
-    <gianluca> oh, nice.
-    <youpi> lseek is supposed to perform only a back&forth
-    <youpi> and I don't observe disk activity, so it's not waiting for the disk
-      to complete whatever atime change & such :)
-    <youpi> it was mentioned that perhaps xen in hvm mode with pv drivers would
-      be faster
-    <youpi> thanks to the ring3/"1" switching  being done by the processor
-    <youpi> (and assuming npt)
-    <gianluca> hm
-    <gianluca> i'll look into that, sounds fun.
-    <gianluca> :)
-    <tschwinge> Here is a testcase:
-      http://www.gnu.org/software/hurd/open_issues/performance/io_system/binutils_ld_64ksec.html
-
-[[performance/io_system/binutils_ld_64ksec]].
-
-Also see the simple testcases [[test-lseek.c]] and [[test-mach.c]].
-
-IRC, freenode, #hurd, 2011-11-05:
-
-    <youpi> [test-mach.c is] mostly as a reference for the trap overhead
-    <youpi> 0.56µs (xen) vs 0.48µs(kvm) on test-mach
-    <youpi> 455µs(xen) vs 16µs(kvm) on test-lseek
-    <youpi> that might simply be an issue in the RPC  mechanism, which behaves
-      badly with the xen memory management
-    <youpi> yes, about 0.5ms for an lseek, that's quite high :)
diff --git a/open_issues/xorg_porting.mdwn b/open_issues/xorg_porting.mdwn
deleted file mode 100644
index 5f540e44..00000000
--- a/open_issues/xorg_porting.mdwn
+++ /dev/null
@@ -1,16 +0,0 @@
-[[!meta copyright="Copyright © 2012 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]]."]]"""]]
-
-[[!meta title="X.Org Porting"]]
-
-[[!tag open_issue_porting]]
-
-See the list of [Hurd-related X.Org project
-ideas](http://xorg.freedesktop.org/wiki/Hurd_Porting).