aboutsummaryrefslogtreecommitdiff
path: root/glibc
diff options
context:
space:
mode:
Diffstat (limited to 'glibc')
-rw-r--r--glibc/debugging.mdwn11
-rw-r--r--glibc/debugging/ld_so_console.mdwn20
-rw-r--r--glibc/debugging/ld_so_console/dl-sysdep.c.patch63
-rw-r--r--glibc/discussion.mdwn25
-rw-r--r--glibc/environment_variable.mdwn15
-rw-r--r--glibc/fallocate.mdwn17
-rw-r--r--glibc/file_descriptor.mdwn13
-rw-r--r--glibc/fork.mdwn69
-rw-r--r--glibc/ioctl.mdwn52
-rw-r--r--glibc/mmap.mdwn98
-rw-r--r--glibc/poll.mdwn15
-rw-r--r--glibc/process.mdwn26
-rw-r--r--glibc/select.mdwn25
-rw-r--r--glibc/signal.mdwn35
-rw-r--r--glibc/signal/discussion.mdwn18
-rw-r--r--glibc/signal/signal_thread.mdwn100
-rw-r--r--glibc/startup.mdwn20
17 files changed, 622 insertions, 0 deletions
diff --git a/glibc/debugging.mdwn b/glibc/debugging.mdwn
new file mode 100644
index 00000000..6b035c12
--- /dev/null
+++ b/glibc/debugging.mdwn
@@ -0,0 +1,11 @@
+[[!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
new file mode 100644
index 00000000..b3d1762f
--- /dev/null
+++ b/glibc/debugging/ld_so_console.mdwn
@@ -0,0 +1,20 @@
+[[!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
new file mode 100644
index 00000000..eec8d7c6
--- /dev/null
+++ b/glibc/debugging/ld_so_console/dl-sysdep.c.patch
@@ -0,0 +1,63 @@
+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
new file mode 100644
index 00000000..fac300ea
--- /dev/null
+++ b/glibc/discussion.mdwn
@@ -0,0 +1,25 @@
+[[!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
new file mode 100644
index 00000000..76c1371e
--- /dev/null
+++ b/glibc/environment_variable.mdwn
@@ -0,0 +1,15 @@
+[[!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
new file mode 100644
index 00000000..3aecf16b
--- /dev/null
+++ b/glibc/fallocate.mdwn
@@ -0,0 +1,17 @@
+[[!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
new file mode 100644
index 00000000..2c56d070
--- /dev/null
+++ b/glibc/file_descriptor.mdwn
@@ -0,0 +1,13 @@
+[[!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
new file mode 100644
index 00000000..12ca2d19
--- /dev/null
+++ b/glibc/fork.mdwn
@@ -0,0 +1,69 @@
+[[!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
new file mode 100644
index 00000000..e1a86f32
--- /dev/null
+++ b/glibc/ioctl.mdwn
@@ -0,0 +1,52 @@
+[[!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
new file mode 100644
index 00000000..09b0b65d
--- /dev/null
+++ b/glibc/mmap.mdwn
@@ -0,0 +1,98 @@
+[[!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
new file mode 100644
index 00000000..d96f27a5
--- /dev/null
+++ b/glibc/poll.mdwn
@@ -0,0 +1,15 @@
+[[!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
new file mode 100644
index 00000000..9b2ec251
--- /dev/null
+++ b/glibc/process.mdwn
@@ -0,0 +1,26 @@
+[[!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/select.mdwn b/glibc/select.mdwn
new file mode 100644
index 00000000..bafda141
--- /dev/null
+++ b/glibc/select.mdwn
@@ -0,0 +1,25 @@
+[[!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-10
+
+ <afleck> what is the use of having a port set name that can receive from
+ multiple ports?
+ <youpi> think of select()
+ <afleck> I haven't really gotten into it yet, I was just reading the Mach
+ Kernel Guide and I didn't understand the difference between having a port
+ set and multiple ports, since you can't choose which port receives in a
+ port set.
+ <youpi> with multiple ports, you'd have to have as many threads to block in
+ reception
+ <youpi> or poll in turn
diff --git a/glibc/signal.mdwn b/glibc/signal.mdwn
new file mode 100644
index 00000000..727247ac
--- /dev/null
+++ b/glibc/signal.mdwn
@@ -0,0 +1,35 @@
+[[!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/discussion.mdwn b/glibc/signal/discussion.mdwn
new file mode 100644
index 00000000..064c1c5b
--- /dev/null
+++ b/glibc/signal/discussion.mdwn
@@ -0,0 +1,18 @@
+[[!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]]."]]"""]]
+
+
+# `_hurd_sigstates`
+
+In an [[hurd/translator/ext2fs]] instance with 1068 threads, `_hurd_sigstates`
+was a linked with with 1067 entries, in one with 351 threads, 351 entries. Is
+this noticeable already? Perhaps a different data structure is needed?
+Though, a linked list is perfect for the common case of processes with only a
+handful of threads.
diff --git a/glibc/signal/signal_thread.mdwn b/glibc/signal/signal_thread.mdwn
new file mode 100644
index 00000000..5341b1ab
--- /dev/null
+++ b/glibc/signal/signal_thread.mdwn
@@ -0,0 +1,100 @@
+[[!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
new file mode 100644
index 00000000..b7ab9d96
--- /dev/null
+++ b/glibc/startup.mdwn
@@ -0,0 +1,20 @@
+[[!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"]]