diff options
Diffstat (limited to 'glibc')
| -rw-r--r-- | glibc/debugging.mdwn | 11 | ||||
| -rw-r--r-- | glibc/debugging/ld_so_console.mdwn | 20 | ||||
| -rw-r--r-- | glibc/debugging/ld_so_console/dl-sysdep.c.patch | 63 | ||||
| -rw-r--r-- | glibc/discussion.mdwn | 25 | ||||
| -rw-r--r-- | glibc/environment_variable.mdwn | 15 | ||||
| -rw-r--r-- | glibc/fallocate.mdwn | 17 | ||||
| -rw-r--r-- | glibc/file_descriptor.mdwn | 13 | ||||
| -rw-r--r-- | glibc/fork.mdwn | 69 | ||||
| -rw-r--r-- | glibc/ioctl.mdwn | 52 | ||||
| -rw-r--r-- | glibc/mmap.mdwn | 98 | ||||
| -rw-r--r-- | glibc/poll.mdwn | 15 | ||||
| -rw-r--r-- | glibc/process.mdwn | 26 | ||||
| -rw-r--r-- | glibc/signal.mdwn | 35 | ||||
| -rw-r--r-- | glibc/signal/signal_thread.mdwn | 100 | ||||
| -rw-r--r-- | glibc/startup.mdwn | 20 |
15 files changed, 579 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/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/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"]] |