Prepare toolchain/logs/master branch.

15 files changed, 0 insertions, 579 deletions

diff --git a/glibc/debugging.mdwn b/glibc/debugging.mdwn
deleted file mode 100644
index 6b035c12..00000000
--- a/glibc/debugging.mdwn
+++ /dev/null
@@ -1,11 +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]]."]]"""]]
-
-  * [[ld_so_console]]
diff --git a/glibc/debugging/ld_so_console.mdwn b/glibc/debugging/ld_so_console.mdwn
deleted file mode 100644
index b3d1762f..00000000
--- a/glibc/debugging/ld_so_console.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]]."]]"""]]
-
-If you need to debug something in the early `ld.so` startup, and can't refrain
-from good old `printf` debugging, there is a caveat: the available API in
-`ld.so` is rather limited.  See the few functions is `dl-sysdep.c`.  For
-example, there's a private `__libc_write`, which you should be able to use for
-writing to FD stderr -- but, at early `ld.so` startup, this isn't usable as
-`_hurd_init_dtable` is still all zeros, etc.  To get you started, here is a
-simple [[dl-sysdep.c.patch]] to get access to the Mach console.
-
-Can this be integrated with the other debugging printf functions from
-`elf/dl-misc.c` (`_dl_debug_vdprintf`) ([[!taglink open_issue_glibc]])?
diff --git a/glibc/debugging/ld_so_console/dl-sysdep.c.patch b/glibc/debugging/ld_so_console/dl-sysdep.c.patch
deleted file mode 100644
index eec8d7c6..00000000
--- a/glibc/debugging/ld_so_console/dl-sysdep.c.patch
+++ /dev/null
@@ -1,63 +0,0 @@
-diff --git a/sysdeps/mach/hurd/dl-sysdep.c b/sysdeps/mach/hurd/dl-sysdep.c
-index ff37add..7e6d352 100644
---- a/sysdeps/mach/hurd/dl-sysdep.c
-+++ b/sysdeps/mach/hurd/dl-sysdep.c
-@@ -44,6 +44,8 @@
- #include <dl-machine.h>
- #include <dl-procinfo.h>
- 
-+#include <device/device.h>
-+
- extern void __mach_init (void);
- 
- extern int _dl_argc;
-@@ -116,6 +118,29 @@ static void fmh(void) {
- /* XXX loser kludge for vm_map kernel bug */
- #endif
- 
-+/* Return a port to the Mach console.  */
-+static mach_port_t
-+get_console (void)
-+{
-+  mach_port_t device_master, console;
-+  /* We cannot use __get_privileged_ports (from hurd/privports.c), as this
-+     drags in too much other libc stuff.  */
-+#if 0
-+  error_t err = __get_privileged_ports (0, &device_master);
-+
-+  if (err)
-+    return MACH_PORT_NULL;
-+#else
-+  error_t err = 0;
-+  device_master = 2;
-+#endif
-+
-+  err = __device_open (device_master, D_WRITE | D_READ, "console", &console);
-+  if (err)
-+    return MACH_PORT_NULL;
-+
-+  return console;
-+}
- 
- ElfW(Addr)
- _dl_sysdep_start (void **start_argptr,
-@@ -256,6 +279,20 @@ unfmh();			/* XXX */
-   /* Set up so we can do RPCs.  */
-   __mach_init ();
- 
-+  /* Open the Mach console so that any message can actually be seen.  This is
-+     particularly useful at boot time, when started by the bootstrap file
-+     system.  */
-+  mach_port_t console = get_console ();
-+  if (console != MACH_PORT_NULL)
-+    {
-+      /* stdout = mach_open_devstream (console, "w"); */
-+      /* stderr = stdout; */
-+      /* if (stdout != NULL) */
-+      /* 	printf ("Hello, world!\n"); */
-+      int written;
-+      __device_write_inband (console, 0, 0, "hello, world!\n", 14, &written);
-+    }
-+
-   /* Initialize frequently used global variable.  */
-   GLRO(dl_pagesize) = __getpagesize ();
\ No newline at end of file
diff --git a/glibc/discussion.mdwn b/glibc/discussion.mdwn
deleted file mode 100644
index fac300ea..00000000
--- a/glibc/discussion.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]]."]]"""]]
-
-
-# TLS
-
-
-## IRC, freenode, #hurd, 2011-06-11
-
-[[!tag open_issue_documentation open_issue_glibc]]
-
-    <civodul> youpi: local-tls-support.diff removes libc-tsd.h; what's the
-      rationale?
-    <youpi> it's completely replaced by __thread variables
-    <civodul> ok, but apparently there are still libc headers that #include it
-    <civodul> like malloc-machine.h
-    <youpi> they'll include bits/libc-tsd.h instead
-    <civodul> oh, ok
diff --git a/glibc/environment_variable.mdwn b/glibc/environment_variable.mdwn
deleted file mode 100644
index 76c1371e..00000000
--- a/glibc/environment_variable.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]]."]]"""]]
-
-
-# External
-
-  * [*putenv() and setenv()*](http://www.greenend.org.uk/rjk/2008/putenv.html)
-    by Richard Kettlewell.
diff --git a/glibc/fallocate.mdwn b/glibc/fallocate.mdwn
deleted file mode 100644
index 3aecf16b..00000000
--- a/glibc/fallocate.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]]."]]"""]]
-
-Not yet implemented for the GNU Hurd in [[glibc]].
-
-
-# External
-
-  * [*Punching holes in files*](http://lwn.net/Articles/415889/), Jonathan
-    Corbet, 2010-11-17.
diff --git a/glibc/file_descriptor.mdwn b/glibc/file_descriptor.mdwn
deleted file mode 100644
index 2c56d070..00000000
--- a/glibc/file_descriptor.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]]."]]"""]]
-
-A [[UNIX file descriptor|unix/file_descriptor]] is implemented in [[glibc]] by
-using operations on objects referred to by [[Mach
-ports|microkernel/mach/port]]).
diff --git a/glibc/fork.mdwn b/glibc/fork.mdwn
deleted file mode 100644
index 12ca2d19..00000000
--- a/glibc/fork.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]]."]]"""]]
-
-On [[Unix]] systems, `fork` is a rather simple [[system call]].
-
-Our implementation in [[glibc]] is and needs to be rather bulky.
-
-For example, it has to duplicate all port rights for the new [[Mach
-task|microkernel/mach/task]].  The address space can simply be duplicated by
-standard means of the [[microkernel/Mach]], but as [[unix/file_descriptor]]s
-(for example) are a concept that is implemented inside [[glibc]] (based on
-[[Mach port|microkernel/mach/port]]s), these have to be duplicated from
-userspace, which requires a small number of [[RPC]]s for each of them, and in
-the sum, [[this affects performance|open_issues/performance/fork]] when new
-processes are continuously being spawned from the shell, for example.
-
-Often, a `fork` call will eventually be followed by an `exec`, which [[may in
-turn close|open_issues/secure_file_descriptor_handling]] (most of) the
-duplicated port rights.  Unfortunately, this cannot be known at the time the
-`fork` executing, so in order to optimize this, the code calling `fork` has to
-be modified instead, and the `fork`, `exec` combo be replaced by a
-`posix_spawn` call, for example, to avoid this work of duplicating each port
-right, then closing each again.
-
-As far as we know, Cygwin has the same problem of `fork` being a nontrivial
-operation.  Perhaps we can learn from what they're been doing?  Also, perhaps
-they have patches for software packages, to avoid using `fork` followed by
-`exec`, for example.
-
-
-# TODO
-
-  * [[fork: mach_port_mod_refs:
-    EKERN_UREFS_OWERFLOW|open_issues/fork_mach_port_mod_refs_ekern_urefs_owerflow]]
-    ([[!taglink open_issue_glibc]]).
-
-  * Include de-duplicate information from elsewhere: [[hurd-paper]],
-    [[hurd-talk]], [[hurd/ng/trivialconfinementvsconstructorvsfork]],
-    [[open_issues/resource_management_problems/zalloc_panics]] ([[!taglink
-    open_issue_glibc open_issue_documentation]]).
-
-  * We no longer support `MACH_IPC_COMPAT`, thus we can get rid of the `err =
-    __mach_port_allocate_name ([...]); if (err == KERN_NAME_EXISTS)` code
-    ([[!taglink open_issue_glibc]]).
-
-  * Can we/why can't we use the concept of *inherited ports
-    array*s/`mach_ports_register` ([[!taglink open_issue_glibc]])?
-
-  * GNUnet `vfork` signal race issue: [[!message-id
-    "87r50ww6m4.fsf@kepler.schwinge.homeip.net"]].
-
-
-## Related
-
-  * [[open_issues/secure_file_descriptor_handling]].
-
-
-# External
-
-  * {{$unix#djb_self-pipe}}.
-
-  * {{$unix#rjk_fork}}.
diff --git a/glibc/ioctl.mdwn b/glibc/ioctl.mdwn
deleted file mode 100644
index e1a86f32..00000000
--- a/glibc/ioctl.mdwn
+++ /dev/null
@@ -1,52 +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-31:
-
-    <pinotree> is there some example of translator replying to custom ioctl's?
-    <pinotree> let's say you define some ioctl (those which can be represented)
-      using the _IOW etc macros; how would a translator (or something else)
-      "register" and reply to them?
-    <youpi> it's not an easy thing
-    <youpi> see hurd/hurd/tioctl.defs for instance
-    <youpi> that's where the 't' ioctls end up
-    <youpi> ('t' being the group in the _IOW macro)
-    <braunr> it's not that hard either
-    <pinotree> youpi: so you "roll" the ioctl to an ipc call with proper
-      parameters?
-    <braunr> yes
-    <pinotree> ah ok, i thought there was some way to hook new ioctl's, and
-      have libc send the whole stuff at once
-    <braunr> and the proper number (with a clear name)
-    <braunr> hm
-    <braunr> for many ioctls, you don't have to change libc
-    <youpi> yes, there's a script which produces the .defs from _IOW calls,
-      iirc
-    <youpi> or something like this
-    <youpi> there's also a hook thing in glibc, but for "sane" ioctls, that's
-      not needed
-    <youpi> (_hurd_lookup_ioctl_handler called by ioctl())
-    <youpi> yes, see the rules in hurd/hurd/Makefile
-    <youpi> "The following rules assist in creating an `Xioctl.defs' file  to
-      define RPCs that are sent primarily by ioctl commands."
-    <antrik> well, you can have perfectly sane ioctl()s that still can't be
-      expressed within the constraints of the IO* macros... but admittedly
-      that's rather uncommon
-    <antrik> (unless you consider passing of structs generally insane...)
-    <youpi> I didn't want to spend time on finding an appropriate adjective
-      instaed of "sane"
-    <youpi> while I knew he would understand what I meant (and you did)
-    <youpi> (though  maybe not actually)
-    <youpi> by "sane", I mean, which use _IOW properly
-    <youpi> i.e. with a group, proper numbers, etc.
-    <youpi> (the imposed contraints on the parameters is obviously a flaw in
-      the hurdish ioctl design, and not insanity from structures)
diff --git a/glibc/mmap.mdwn b/glibc/mmap.mdwn
deleted file mode 100644
index 09b0b65d..00000000
--- a/glibc/mmap.mdwn
+++ /dev/null
@@ -1,98 +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]]."]]"""]]
-
-There are two implementations of `mmap` for GNU Hurd:
-`sysdeps/mach/hurd/mmap.c` (main implementation) and
-`sysdeps/mach/hurd/dl-sysdep.c` (*Minimal mmap implementation sufficient for
-initial loading of shared libraries.*).
-
-  * `MAP_COPY`
-
-    What exactly is that?  `elf/dl-load.c` has some explanation.
-    <http://lkml.indiana.edu/hypermail/linux/kernel/0110.1/1506.html>
-
-    It is only handled in `dl-sysdep.c`, when `flags & (MAP_COPY|MAP_PRIVATE)`
-    is used for `vm_map`'s `copy` parameter, and `mmap.c` uses `! (flags &
-    MAP_SHARED)` instead, which seems inconsistent?
-
-
-# `io_map` Failure
-
-This is the [[libnetfs: `io_map`|open_issues/libnetfs_io_map]] issue.
-
-[[!tag open_issue_glibc]]
-
-Review of `mmap` usage in generic bits of glibc, based on
-a1bcbd4035ac2483dc10da150d4db46f3e1744f8 (2012-03-11), listing these cases
-where failure (due to `io_map` failing; that is, invocations where a `fd` is
-passed) is not properly handled.
-
-`catgets/open_catalog.c`, `iconv/gconv_cache.c`, `intl/loadmsgcat.c`,
-`locale/loadlocale.c` have fallback code for the `MAP_FAILED` case.
-
-[[tschwinge]]'s current plan is to make the following cases do the same (if
-that is possible); probably by introducing a generic `mmap_or_read` function,
-that first tries `mmap` (and that will succeed on Linux-based systems and also
-on Hurd-based, if it's backed by [[hurd/libdiskfs]]), and if that fails tries
-`mmap` on anonymous memory and then fills it by `read`ing the required data.
-This is also what the [[hurd/exec]] server is doing (and is the reason that the
-`./true` invocation on [[libnetfs: `io_map`|open_issues/libnetfs_io_map]]
-works, to my understanding): see `exec.c:prepare`, if `io_map` fails,
-`e->filemap == MACH_PORT_NULL`; then `exec.c:map` (as invoked from
-`exec.c:load_section`, `exec.c:check_elf`, `exec.c:do_exec`, or
-`hashexec.c:check_hashbang`) will use `io_read` instead.
-
-Doing so potentially means reading in a lot of unused data -- but we probably
-can't do any better?
-
-In parallel (or even alternatively?), it should be researched how Linux (or any
-other kernel) implements `mmap` on NFS and similar file systems, and then
-implement the same in [[hurd/libnetfs]] and/or [[hurd/translator/nfs]], etc.
-
-Here, also probably the whole mapping region [has to be
-read](http://lists.gnu.org/archive/html/bug-hurd/2001-10/msg00306.html) at
-`mmap` time.
-
-List of files without fallback code for the *`MAP_FAILED` due to `io_map`
-failed* case:
-
-  * `elf/cache.c`
-
-  * `elf/dl-load.c`
-
-  * `elf/dl-misc.c`
-
-  * `elf/dl-profile.c`
-
-  * `elf/readlib.c`
-
-  * `elf/sprof.c`
-
-  * `locale/loadarchive.c`
-
-  * `locale/programs/locale.c`
-
-  * `locale/programs/locarchive.c`
-
-  * `nscd/connections.c`
-
-  * `nscd/nscd_helper.c`
-
-  * `nss/makedb.c`
-
-  * `nss/nss_db/db-open.c`
-
-  * Omitted:
-
-      * `nptl/`
-
-      * `sysdeps/unix/sparc/`
-
-      * `sysdepts/unix/sysv/linux/`
diff --git a/glibc/poll.mdwn b/glibc/poll.mdwn
deleted file mode 100644
index d96f27a5..00000000
--- a/glibc/poll.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]]."]]"""]]
-
-
-# External
-
-  * [*poll() and EOF*](http://www.greenend.org.uk/rjk/2001/06/poll.html) by
-    Richard Kettlewell.
diff --git a/glibc/process.mdwn b/glibc/process.mdwn
deleted file mode 100644
index 9b2ec251..00000000
--- a/glibc/process.mdwn
+++ /dev/null
@@ -1,26 +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]]."]]"""]]
-
-The GNU Hurd uses a similar concept to [[UNIX processes|unix/process]].
-
-As a [[Mach task|microkernel/mach/task]] only implements a part of a UNIX
-process, there is additional work to be done, for example for [[signal]]s,
-[[environment_variable]]s, [[file_descriptor]]s.
-
-
-# Controlling TTY
-
-Hurd controlling tty behavior is generally consistent with BSD's, including
-`TIOCSCTTY`.  Linux also has `TIOCSCTTY` and it is harmless to use it there.
-But BSD and Hurd never do an implicit `TIOCSCTTY` (hence our `O_NOCTTY` is
-zero).
-
-C.f. <http://lists.gnu.org/archive/html/bug-hurd/2009-10/msg00030.html> and the
-following messages.
diff --git a/glibc/signal.mdwn b/glibc/signal.mdwn
deleted file mode 100644
index 727247ac..00000000
--- a/glibc/signal.mdwn
+++ /dev/null
@@ -1,35 +0,0 @@
-[[!meta copyright="Copyright © 2009, 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]]."]]"""]]
-
-The [[*UNIX signalling mechanism*|unix/signal]] is implemented for the GNU Hurd
-by means of a separate *[[signal_thread]]* that is part of every user-space
-[[process]].  This makes handling of signals a separate thread of control.
-[[GNU Mach|microkernel/mach/gnumach]] itself has no idea what a signal is and
-`kill` is not a [[system_call]] (as it typically is in a [[UNIX]] system): it's
-implemented in [[glibc]].
-
-  * [[SA_SIGINFO, SA_SIGACTION|open_issues/sa_siginfo_sa_sigaction]]
-
-  * Why does `kill` hang sometimes?
-
-        <youpi> kill send the signal to the process
-        <youpi> if the process is hung, killing waits
-        <youpi> signals should be just asynchronous, but apparently for some
-          reason Roland & co wanted some synchronization
-
-    [[!taglink open_issue_glibc]]
-
-
-# Further Reading
-
-  * {{$unix#djb_self-pipe}}.
-
-  * {{$unix#rjk_fork}}.
diff --git a/glibc/signal/signal_thread.mdwn b/glibc/signal/signal_thread.mdwn
deleted file mode 100644
index 5341b1ab..00000000
--- a/glibc/signal/signal_thread.mdwn
+++ /dev/null
@@ -1,100 +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]]."]]"""]]
-
-For delivering a signal, Mach forwards an `msg_sig_post` message from the
-invoker of `kill` to the target process.  The target process' [[signal_thread]]
-job is it to listen to such messages and to set up signal handler contexts in
-other threads.
-
----
-
-[[!tag open_issue_documentation]]
-
-    <braunr> bugs around signals are very tricky
-    <braunr> signals are actually the most hairy part of the hurd
-    <braunr> and the reason they're aynchronous is that they're handled by a
-      second thread
-    <braunr> (so yes, every process on the hurd has at least two threads)
-    <svante_> braunr: How to solve the asynch problem then if every process has
-      two threads?
-    <braunr> the easiest method would be to align ourselves on what most other
-      Unices do
-    <braunr> establish a "signal protocol" between kernel and userspace
-    <braunr> with a set of signal info in a table, most likely at the top of
-      the stack
-    <braunr> but this is explicitely what the original Mach developers didn't
-      want, and they were right IMO
-    <braunr> having two threads is very clean, but it creates incompatibilites
-      with what POSIX requires
-    <braunr> so there might be a radical choice to make here
-    <braunr> and i doubt we have the resources to make it happen
-    <svante_> What is the advantage of having two threads per process, a per
-      the original design?
-    <braunr> it's clean
-    <braunr> you don't have to define async-signal-safe functions
-    <braunr> it's like using sigwait() yourself in a separate thread, or
-      multiplexing them through signalfd()
-    <svante_> Regardless of the advantages, isn't two threads per process a
-      waste of resources?
-    <braunr> sure it is
-    <braunr> but does it really matter ?
-    <braunr> mach and the hurd were intended to be "hyperthreaded"
-    <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
-    <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> svante_: that's a whole computer science domain of its own
-    <braunr> yes
-    <braunr> LWPs are another names for kernel threads usually
-    <braunr> continuations are a facility which allows a thread to store its
-      state, yield the processor to another thread, and when it's dispatched
-      again by the scheduler, it can resume with its saved state
-    <braunr> most current kernels support kernel preemption though
-    <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.
diff --git a/glibc/startup.mdwn b/glibc/startup.mdwn
deleted file mode 100644
index b7ab9d96..00000000
--- a/glibc/startup.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]]."]]"""]]
-
-Be it statically or dynamically linked, the *startup* of glibc-based programs
-is quite hairy on GNU Hurd systems.
-
-[[!taglink open_issue_documentation open_issue_glibc]]
-
-  * [[!message-id "200103081944.f28JiDk00232@delius.kettenis.local"]]
-
-  * [[!message-id "3B7BF2B1.1417CD84@alcor.concordia.ca"]]
-
-  * [[!message-id "871xc9qv6y.wl@ulysses.g10code.de"]]