IRC.

21 files changed, 1025 insertions, 75 deletions

diff --git a/community/gsoc/project_ideas/namespace-based_translator_selection/discussion.mdwn b/community/gsoc/project_ideas/namespace-based_translator_selection/discussion.mdwn
new file mode 100644
index 00000000..befd680a
--- /dev/null
+++ b/community/gsoc/project_ideas/namespace-based_translator_selection/discussion.mdwn
@@ -0,0 +1,64 @@
+[[!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-22
+
+    <youpi> btw, I was wondering, when working on namespace mangling, did they
+      think about automatitioning ?
+    <youpi> autopartitioning, I meant
+    <youpi> i.e. with a foo.img file, open foo.img,,part1
+    <braunr> what are you referring to with namespace mangling
+    <youpi> and voila
+    <youpi> I don't remember the exact term they used
+    <braunr> you mean there is a hurd library that parses names and can direct
+      to different services depending on part of the name ?
+    <youpi> namespace-based_translator_selection
+    <youpi> yes
+    <braunr> i thought it only handled directories
+    <braunr> well, the classical path representation
+    * civodul finds it ugly
+    <youpi> civodul: because of potential conflict, and the not-too-nice ",,"
+      part?
+    <youpi> actually I wonder whether using directory access would be nicer
+    <youpi> i.e. you have a foo.gz, just open foo.gz/gunzip to get the unzipped
+      content
+    <youpi> and for foo.img.gz, open foo.img.gz/gunzip/part/1
+    <civodul> youpi: because of the interpretation of special chars in file
+      names
+    <civodul> users should be free to use any character they like in file names
+    <civodul> foo.gz/gunzip looks nicer to me
+    <youpi> ok, so we agree
+    <youpi> that said, the user could choose the separator
+    <youpi> the namespace can be not run by root for everybody, but just for
+      your shell, run by yourself
+    <antrik> civodul: the user can't use any character anyways... '/' and '\0'
+      are reserved :-P
+    <civodul> antrik: '/' isn't quite reserved on the Hurd :-)
+    <civodul> you could implement dir_lookup such that it does something
+      special about it
+    <civodul> (server-side)
+    <antrik> civodul: as for overloading '/', although I haven't thought it
+      through entirely, I guess that would work for nodes that present as files
+      normally. however, it would *not* work for directory nodes
+    <antrik> which would be quite a serious limitation IMHO
+    <antrik> I can think of various kinds of useful directory translators
+    <antrik> what's more, one of the main use cases I originally had in mind is
+      a policy filter
+    <antrik> you could pass a directory name with a appropriate filter applied
+      to tar for example, so it wouldn't try to follow any translators
+    <antrik> I don't see why taking an obscure prefix like ,, would be much of
+      a problem in practice anyways
+    <antrik> (also, it doesn't strictly prevent the user from having such file
+      names... you just need to escape it if accessing such files through the
+      namespace multiplexer. though admittedly that would need some special
+      handling in *some* programs to work properly)
diff --git a/hurd/console.mdwn b/hurd/console.mdwn
index f7230011..55581870 100644
--- a/hurd/console.mdwn
+++ b/hurd/console.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2009, 2011
-Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2009, 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
@@ -9,6 +9,11 @@ Sections, no 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]]
+
+
+# Architecture: client and server
+
 The Hurd console's implementation is broken into two pieces each running on
 it's own process, the console client and server.
 
@@ -79,9 +84,9 @@ blocking operations and a blocked `input_dequeue` necessarily needs an
 `ports_manage_multithreaded` API.
 
 
----
+# Old stuff
 
-/!\ old content; [[!taglink open_issue_documentation]]: cleanup needed.
+[[!taglink open_issue_documentation]]: cleanup needed.
 
 The below is a reworked version of Marcus Brinkmann's [letter to the debian-hurd list](http://lists.debian.org/debian-hurd/2002/debian-hurd-200209/msg00054.html). It describes how to setup the new console server for the Hurd. I am testing this right now, so this document is a work in progress.
 
@@ -357,3 +362,101 @@ An [experimental plugin to load XKB keymaps](http://kilobug.free.fr/hurd/xkb-0.3
 Added examples that use repeaters needed by X.
 
 -- [[Main/OgnyanKulev]] - 18 Sep 2004
+
+
+# IRC, freenode #hurd, 2012-04-23
+
+    <Tekk_> is there any way to get copy/paste in hurd?
+    <Tekk_> with the console server
+    <Tekk_> like you get with gpm
+    <youpi> Tekk_: by implementing it
+    <antrik> Tekk_: that's something for the console client, not the server
+    <antrik> (or perhaps both? not entirely sure)
+    <Tekk_> antrik: I'm not entirely sure how the client works
+    <Tekk_> does it start a new client with each tty?
+    <Tekk_> or one client handles all of them?
+    <youpi> the client only should be enough
+    <youpi> it handles all input already anyway
+    <youpi> the client handles all ttys
+    <youpi> it just hops over them according to alt-Fx shortcuts
+    <antrik> Tekk_: there is only one client for all, but a separate console
+      *server* for each tty
+    <Tekk_> antrik: ah, the ever confusing X scheme
+    <antrik> no
+    <antrik> the client handles multiplexing and actual terminal I/O
+    <antrik> the servers handle the state of the virtual terminals, and provide
+      the device nodes
+    <antrik> this doesn't fit with the X scheme in any way
+    <antrik> (where everything is basically in one big monolithic server
+      process)
+    <Tekk_> antrik: I mean that you're running multiple servers and there's one
+      big client running on the other end
+    <Tekk_> which always pretty well confuses everyone to start with
+    <antrik> I totally fail to see the connection
+    <antrik> there is usually one X server, with potentially many clients
+    <Tekk_> nevermind
+    <Tekk_> doesn't really matter to anything
+    <Tekk_> so yeah, copy/paste would be in the client?
+    <antrik> unless you mean a termial server, running actual client programs,
+      connected to various terminals, running X servers... which is where it
+      gets confusing in a way ;-)
+    <antrik> but there is really no relation at all here
+    <Tekk_> antrik: exactly ;)
+    <Tekk_> I meant in the traditional sense, where you're on a thin client
+      running an X server and the remote server is running X clients
+    <Tekk_> copy/paste probably isn't really too bad
+    <antrik> applications are also clients of the terminal server processes;
+      but having a completely different role (and using completely different
+      requests) than the console client
+    <Tekk_> you have a buffer, when something is highlighted you strncpy the
+      highlighted text into the buffer. when middle click happens you send the
+      text to the right virtual terminal
+    <antrik> right. what I was considering is whether the pasting (and possibly
+      also grabbing) the text might be done through some separate protocol
+      implemented in the console server, rather than the ordinary console
+      client interfaces... but probably no need for that
+    <Tekk_> nah, as long as you have a way of getting a highlighted area and
+      then the text contained in it
+    <Tekk_> and then of course a way to insert text where the cursor is, but
+      I'm pretty sure you can safely assume that one :P
+    <antrik> well, the client has a way to send keystrokes to the server,
+      obviously. the question here is whether pretending the pasting is
+      keystrokes is good enough, or whether it might be useful to have an
+      explicit way to push the pasted stuff to the server
+    <antrik> (the cursor position is relevant only for echo)
+    <Tekk_> antrik: I'll try to grab the console source some time this week and
+      take a look
+    <Tekk_> maybe I can try to get it working
+    <antrik> good luck :-)
+    <antrik> it's probably not too hard
+    <Tekk_> I'm sure I'll need it :)
+    <antrik> the whole console machinery is quite hard to grasp (and I still
+      find myself confused sometimes, although I gained a pretty good
+      understanding I think when writing my thesis)
+    <antrik> but for this specific task, not much knowlegde should be needed
+      about the various confusing aspects
+    <Tekk_> hmm. looks like copy/paste won
+    <Tekk_> 't be a quick thing, actually
+    <Tekk_> wait, no. there must be a way to get mouse events
+    <Tekk_> how else could you move the mouse..
+    <Tekk_> (with by moving your mouse, not cons_mouse_move)
+    <Tekk_> by moving your mouse*
+    <Tekk_> started typing something different
+
+
+# Graphics/Higher Resolution
+
+## IRC, freenode #hurd, 2012-04-24
+
+    <Tekk_> does the console support higher resolutions yet?
+    <youpi> no
+    <youpi> it's just textonly
+    <antrik> Tekk_: the main reason why I originally started on the KGI work
+      was to get a graphical console... but I never finished that part
+    <antrik> (since KGI is obsolete anyways)
+    <antrik> BTW, there is a KMS-based userspace console now for Linux... I
+      guess it should be easy to adapt to other systems having KMS support
+    <antrik> I don't think it actually makes much sense for Linux, as it's one
+      of the hardest and least profitable things to move out of a monolithic
+      kernel...
+    <antrik> well, not hardest I guess; but most problematic
diff --git a/hurd/translator/devfs.mdwn b/hurd/translator/devfs.mdwn
index 8784e998..a9cc307f 100644
--- a/hurd/translator/devfs.mdwn
+++ b/hurd/translator/devfs.mdwn
@@ -12,7 +12,7 @@ License|/fdl]]."]]"""]]
 in there in a dynamic fashion -- as compared to static passive translator
 settings as they're used now.
 
-`devfs` has not yet been written.
+`devfs` has not yet been written.  [[!tag open_issue_hurd]]
 
 ---
 
@@ -23,6 +23,8 @@ path is resident at all times.
 
 # IRC, freenode, #hurd, 2012-01-29
 
+[[!tag open_issue_documentation]]
+
     <pinotree> what would be an hurdish way to achieve something like the
       various system (udev, devfs, devd, etc) for populating devices files
       automatically according to the found system devices?
@@ -37,3 +39,35 @@ path is resident at all times.
       /dev directory with unique device names... probably need some
       unionfs-like translator that collects the individual driver nodes in an
       intelligent manner
+
+
+# IRC, freenode, #hurd, 2012-04-22
+
+    <antrik> braunr: I don't think it's a problem that translators are invoked
+      when listing /dev
+    <antrik> the problem is that they linger around although they are very
+      unlikely to be needed again any time soon
+    <youpi> for now it's not too much a problem because there aren't too many
+    <youpi> but that can become problematic
+    <pinotree> a devfs on /dev could also fill it with new devices
+    <youpi> but only with the ones that actually exist
+    <pinotree> yeah
+    <braunr> antrik: i mean, the hurd may lack a feature allowing the same
+      translator to be used for several nodes not hierarically related
+    <braunr> antrik: or rather, it's a special case that we should implement
+      differently
+    <braunr> (with e.g. a devfs that can route requests for different nodes to
+      a same translator
+    <braunr> )
+    <antrik> I agree BTW that some intermediary for /dev would be helpful --
+      but I don't think it should actually take over any RPC handling; rather,
+      only redirect the requests as appropriate (with the actual device nodes
+      in a hierarchical bus-centric layout)
+    <braunr> right
+    <antrik> braunr: actually, the Hurd *does* have a feature allowing the same
+      translator to be attached to several unrelated nodes
+    <braunr> i keep getting surprised :)
+    <antrik> though it's only used in very few places right now
+    <youpi> pfinet and ptys at least ?
+    <antrik> yeah, and console client IIRC
+
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index fff2e74b..ad79c7b9 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -1,18 +1,23 @@
-[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2007, 2008, 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
 
 # Implementation
 
   * [[filetype]] option
 
+  * [[Hurd-specific_extensions]]
+
+  * [[Page_cache]]
+
 
 ## Large Stores
 
diff --git a/hurd/translator/ext2fs/hurd-specific_extensions.mdwn b/hurd/translator/ext2fs/hurd-specific_extensions.mdwn
new file mode 100644
index 00000000..774f1cf3
--- /dev/null
+++ b/hurd/translator/ext2fs/hurd-specific_extensions.mdwn
@@ -0,0 +1,23 @@
+[[!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-04-20
+
+    <Tekk_> what are the extensions to ext2?
+    <Tekk_> that hurd uses
+    <braunr> tha ability to store passive translator command lines in the
+      inodes
+    <braunr> the*
+    <antrik> well, also a fourth set of permission bits, and an "author" field
+    <braunr> right
+    <antrik> both very obscure features that better never existed...
diff --git a/hurd/translator/ext2fs/page_cache.mdwn b/hurd/translator/ext2fs/page_cache.mdwn
new file mode 100644
index 00000000..e8a964ed
--- /dev/null
+++ b/hurd/translator/ext2fs/page_cache.mdwn
@@ -0,0 +1,31 @@
+[[!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]]
+
+This is not at all specific to ext2fs, so should be integrated elsewhere.
+
+
+# IRC, freenode, #hurd, 2012-04-22
+
+    <Tekk_> is there any particular reason ext2fs takes so much memory?
+    <Tekk_> it beats everything on my system hands down at 100 MB
+    <youpi> ext2fs contains the page cache
+    <youpi> so it's no wonder it takes memory
+    <youpi> it's all the mapped files
+    <Tekk_> any way I can cut down on that?
+    <Tekk_> my system only has 512 meg :/
+    <youpi> gnumach is supposed to automatically cut it down as needed
+    <youpi> what is the actual symptom that you see?
+    <Tekk_> youpi: 360 MB of memory usage when I'm doing nothing
+    <Tekk_> oh, is it just intelligent enough to cut down when I'm using more
+      memory?
+    <youpi> Tekk_: yes
+    <Tekk_> awesome. I was worried :)
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn
index 339fab50..e7fdf46e 100644
--- a/hurd/translator/procfs/jkoenig/discussion.mdwn
+++ b/hurd/translator/procfs/jkoenig/discussion.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]]
+[[!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
@@ -218,3 +219,61 @@ Needed by glibc's `pldd` tool (commit
 # `/proc/self/exe`
 
 [[!message-id "alpine.LFD.2.02.1110111111260.2016@akari"]]
+
+
+# `/proc/[PID]/fd/`
+
+## IRC, freenode, #hurd, 2012-04-24
+
+    <antrik> braunr: /proc/*/fd can be implemented in several ways. none of
+      them would require undue centralisation
+    <antrik> braunr: the easiest would be adding one more type of magic lookup
+      to the existing magic lookup mechanism
+    <antrik> wait, I mean /proc/self... for /proc/*/fd it's even more
+      straighforward -- we might even have a magic lookup for that already
+    <pinotree> i guess the ideal thing would be implement that fd logic in
+      libps
+    <antrik> pinotree: nope. it doesn't need to ask proc (or any other server)
+      at all. it's local information. that's what we have the magic lookups for
+    <antrik> one option we were considering at some point would be using the
+      object migration mechanism, so the actual handling would still happen
+      client-side, but the server could supply the code doing it. this would
+      allow servers to add arbitrary magic lookup methods without any global
+      modifications... but has other downsides :-)
+    <gnu_srs> youpi: How much info for /proc/*/fd is possible to get from
+      libps? Re: d-h@
+    <youpi> see my mail
+    <youpi> I don't think there is an interface for that
+    <youpi> processes handle fds themselves
+    <youpi> so libps would have to peek in there
+    <youpi> and I don't remember having seen any code like that
+    <gnu_srs> 10:17:17< antrik> wait, I mean /proc/self... for /proc/*/fd it's
+      even more straighforward -- we might even have a magic lookup for that
+      already
+    <gnu_srs> pinotree: For me that does not ring a bell on RPCs. Don't know
+      what magic means,,
+    <youpi> for /proc/self/fd we have a magic lookup
+    <youpi> for /proc/pid/fd, I don't think we have
+    <gnu_srs> magic lookup*
+    <gnu_srs> magic lookup == RPC?
+    <youpi> magic lookup is a kind of answer to the lookup RPC
+    <youpi> that basically says "it's somewhere else, see there"
+    <youpi> the magic FD lookup tells the process "it's your FD number x"
+    <youpi> which works for /proc/self/fd, but not /proc/pid/fd
+    <civodul> youpi, gnu_srs: regarding FDs, there the msg_get_fd RPC that
+      could be used
+    <civodul> `msgport' should have --get-fd, actually
+    <youpi> civodul: I assumed that the reason why msgport doesn't have it is
+      that it didn't exist
+    <youpi> so we can get a port on the fd
+    <youpi> but then how to know what it is?
+    <civodul> youpi: ah, you mean for the /proc/X/fd symlinks?
+    <civodul> good question
+    <civodul> it's not designed to be mapped back to names, indeed :-)
+    <antrik> youpi: yeah, I realized myself that only /proc/self/fd is trivial
+    <antrik> BTW, in Linux it's nor real symlinks. it's magic, with some very
+      strange (but useful in certain situations) semantics
+    <antrik> not real symlinks
+    <antrik> it's very weird for example for fd connected to files that have
+      been unlinked. it looks like a broken symlink, but when dereferencing
+      (e.g. with cp), you get the actual file contents...
diff --git a/open_issues/bpf.mdwn b/open_issues/bpf.mdwn
index 2a8c897a..e24d761b 100644
--- a/open_issues/bpf.mdwn
+++ b/open_issues/bpf.mdwn
@@ -562,3 +562,26 @@ This is a collection of resources concerning *Berkeley Packet Filter*s.
       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 ..
diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn
index b15c880a..26fa6012 100644
--- a/open_issues/glibc.mdwn
+++ b/open_issues/glibc.mdwn
@@ -202,11 +202,59 @@ Last reviewed up to the [[Git mirror's d40c5d54cb551acba4ef1617464760c5b3d41a14
     `CLOCK_REALTIME_ALARM`, `O_PATH`,
     `PTRACE_*` (for example, cbff0d9689c4d68578b6a4f0a17807232506ea27),
     `RLIMIT_RTTIME`, `SEEK_DATA` (`unistd.h`), `SEEK_HOLE` (`unistd.h`)
-    `clock_adjtime`, `fallocate`, `fallocate64`, `getcontext` (and
-    `setcontext`), `name_to_handle_at`, `open_by_handle_at`,
-    `process_vm_readv`, `process_vm_writev`, `sendmmsg`,
+    `clock_adjtime`, `fallocate`, `fallocate64`, `name_to_handle_at`,
+    `open_by_handle_at`, `process_vm_readv`, `process_vm_writev`, `sendmmsg`,
     `setns`, `sync_file_range`
 
+      * `getcontext`/`setcontext`
+
+        Needed for [[gccgo]].
+
+        IRC, freenode, #hurd, 2012-04-19:
+
+            <gnu_srs> How much work/knowledge is needed to implement
+              getcontext/setcontext?
+            <gnu_srs> Any already implemented alternatives available?
+            <youpi> x86 registers knowledge, as well as unix signal masks
+            <youpi> there's the linux implementation that can be taken as an
+              exxample, but the signal part has to be rewritten
+            <gnu_srs> Well, it's a pity they are not implemented. That's the
+              remaining hurdle to get gccgo working :-( 
+            <youpi> uh :/
+            <gnu_srs> Everything builds, but the testsuite fails due to these
+              missing functions.
+            <gnu_srs> Regarding getcontext/setcontext they seem to be written
+              in assembly for linux but the code is not very long. 
+            <gnu_srs> How much effort would it be to write something similar
+              for Hurd? Anybody fluent in asm?
+            <gnu_srs> And registers and signals.
+            <tschwinge> gnu_srs: Signals is the key thing -- everything else we
+              can probably just copy.  I have never/not yet looked at it,
+              though.
+            <gnu_srs> For kfreebsd it is written in C: kern_context.c, 3/4 in
+              one file: getcontext, setcontext,  swapcontext, not makecontext.
+            <gnu_srs> Dunno how much assembly calls used though.
+            <gnu_srs> Hi, any preferences about implementing get/setcontext in
+              C or Asm?
+            <tschwinge> gnu_srs: I think these will have to be implemented in
+              assembly.  Based on the Linux x86 variants.
+
+        IRC, freenode, #hurd, 2012-04-20:
+
+            <tschwinge> youpi: Your understanding of that is better than mine
+              -- the *context stuff can't be very useful at the moment, because
+              when the user changes uc_stack.ss_sp (which the glibc tests are
+              doing), we're losing access to the _hurd_threadvars.  Correct?
+            <tschwinge> At least the getcontext test works, the other get a
+              SIGILL.
+            <tschwinge> others
+            <tschwinge> _hurd_threadvars issue is just guessing.
+            <youpi> tschwinge: yes, threadvars are on the stack
+            <youpi> threadvars is not much code, it should just work, but care
+              has to be taken on the libpthread/libthread side, which does some
+              initialization
+            <tschwinge> OK, that at least matches my understanding.
+
       * `syncfs`
 
         We should be easily able to implement that one.
@@ -264,6 +312,35 @@ Last reviewed up to the [[Git mirror's d40c5d54cb551acba4ef1617464760c5b3d41a14
 
       * `timespec_get` (74033a2507841cf077e31221de2481ff30b43d51)
 
+      * `waitflags.h` (`WEXITED`, `WNOWAIT`, `WSTOPPED`, `WCONTINUED`)
+
+        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
+
+    For specific packages:
+
+      * [[octave]]
+
   * Create `t/cleanup_kernel-features.h`.
 
   * Add tests from Linux kernel commit messages for `t/dup3` et al.
diff --git a/open_issues/glibc/getlogin_r.mdwn b/open_issues/glibc/getlogin_r.mdwn
new file mode 100644
index 00000000..9980ea1f
--- /dev/null
+++ b/open_issues/glibc/getlogin_r.mdwn
@@ -0,0 +1,45 @@
+[[!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="getlogin_r"]]
+
+[[!tag open_issue_glibc]]
+
+
+# IRC, freenode, #hurd, 2012-04-23
+
+    * pinotree spots how our getlogin_r() implementation uses a static
+        buffer...
+    <braunr> oO
+    <pinotree> braunr: yeah, the _r means "reentrantbutnotreally" xD
+    <braunr> pinotree: that's amazing ..
+    <antrik> pinotree: without having checked the actual implementation, that
+      doesn't sound like a problem...
+    <antrik> caching doesn't break reentrancy. the problem with the plain
+      getlogin() is that a static buffer is *returned to the user*
+    <pinotree> antrik: http://paste.debian.net/164727/
+    <braunr> ah, caching
+    <pinotree> i don't think this is caching at all
+    <antrik> pinotree: OK, not actually caching... but same effect as far as I
+      can tell
+    <antrik> pinotree: or is it the fixed size of the temporary variable you
+      are concerned about?
+    <pinotree> antrik: my concern was about the "static" of the buffer used for
+      the get_login rpc
+    <antrik> pinotree: I'm not sure that's a problem. can the login actually
+      ever change for a running process?
+    <pinotree> dunno
+    <pinotree> but if so, it would be pointless to do the rpc every time
+      instead of just once
+    <antrik> pinotree: true
+    * pinotree would just make it non-static and be safe
+    <antrik> pinotree: well, one might argue that allocating a KiB of stack
+      space is not very friendly, especially in a low-level library...
+    <antrik> not sure what the general policy is about such things in libc
diff --git a/open_issues/glibc/octave.mdwn b/open_issues/glibc/octave.mdwn
new file mode 100644
index 00000000..b12b7558
--- /dev/null
+++ b/open_issues/glibc/octave.mdwn
@@ -0,0 +1,35 @@
+[[!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/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn
index f8e27e62..9feb30c8 100644
--- a/open_issues/gnumach_memory_management.mdwn
+++ b/open_issues/gnumach_memory_management.mdwn
@@ -2116,3 +2116,20 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task.
       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
diff --git a/open_issues/gnumach_page_cache_policy.mdwn b/open_issues/gnumach_page_cache_policy.mdwn
new file mode 100644
index 00000000..75fcdd88
--- /dev/null
+++ b/open_issues/gnumach_page_cache_policy.mdwn
@@ -0,0 +1,35 @@
+[[!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-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
diff --git a/open_issues/gnumach_vm_map_red-black_trees.mdwn b/open_issues/gnumach_vm_map_red-black_trees.mdwn
new file mode 100644
index 00000000..d77bea32
--- /dev/null
+++ b/open_issues/gnumach_vm_map_red-black_trees.mdwn
@@ -0,0 +1,142 @@
+[[!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
diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn
index 614f1271..c5054b7f 100644
--- a/open_issues/libpthread.mdwn
+++ b/open_issues/libpthread.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]]
+[[!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
@@ -25,43 +26,19 @@ There is a [[!FF_project 275]][[!tag bounty]] on this task.
 [[!inline pages=community/gsoc/project_ideas/pthreads feeds=no]]
 
 
+## IRC, freenode, #hurd, 2012-04-26
 
-# pthread/stubs issue w/ dlopen'ed libraries
+    <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?
 
-IRC, freenode, #hurd, 2010-01-24
+[[Packaging_libpthread]].
 
-    <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
-    <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
+    <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 :)
diff --git a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn
new file mode 100644
index 00000000..f9195540
--- /dev/null
+++ b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn
@@ -0,0 +1,58 @@
+[[!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="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
+    <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
diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn
index fb665c67..05a07ef2 100644
--- a/open_issues/libpthread_dlopen.mdwn
+++ b/open_issues/libpthread_dlopen.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!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
@@ -10,7 +10,52 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_libpthread]]
 
-IRC, OFTC, #debian-hurd, 2011-07-21.
+[[!toc]]
+
+
+# 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
diff --git a/open_issues/o_exec.mdwn b/open_issues/o_exec.mdwn
new file mode 100644
index 00000000..3f77a0f2
--- /dev/null
+++ b/open_issues/o_exec.mdwn
@@ -0,0 +1,54 @@
+[[!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/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn
index fa3d4312..f8ef4ae7 100644
--- a/open_issues/packaging_libpthread.mdwn
+++ b/open_issues/packaging_libpthread.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]]
+[[!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
@@ -10,9 +11,13 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_libpthread open_issue_glibc]]
 
-IRC, #hurd, 2010-07-31
+[[!toc]]
 
-    <tschwinge> My idea was to have a separate libpthread package.  What do you think about that?
+
+# 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
 
@@ -21,30 +26,103 @@ IRC, #hurd, 2010-07-31
     <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> 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> 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
+    <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?
+    <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> 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
+    <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?
+    <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)
+    <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> also, any reason for using ia32 and not i386? glibc uses the latter
+    <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/ia32/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
diff --git a/open_issues/system_call_mechanism.mdwn b/open_issues/system_call_mechanism.mdwn
index 5598148c..68418097 100644
--- a/open_issues/system_call_mechanism.mdwn
+++ b/open_issues/system_call_mechanism.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!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
@@ -10,8 +10,47 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_gnumach]]
 
-IRC, freenode, #hurd, 2011-05-07
+[[!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/user-space_device_drivers.mdwn b/open_issues/user-space_device_drivers.mdwn
index 70c3c6dc..25168fce 100644
--- a/open_issues/user-space_device_drivers.mdwn
+++ b/open_issues/user-space_device_drivers.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2009, 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 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
@@ -64,7 +65,7 @@ Also see [[device drivers and IO systems]].
 
 ## System Boot
 
-IRC, freenode, #hurd, 2011-07-27
+### IRC, freenode, #hurd, 2011-07-27
 
     < braunr> btw, was there any formulation of the modifications required to
       have disk drivers in userspace ?
@@ -88,6 +89,11 @@ IRC, freenode, #hurd, 2011-07-27
     < 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/ :)
+
 
 # Plan