Merge commit 'bdb5476b45b43e1753514fe28d1be9436dd572bd'

42 files changed, 1401 insertions, 118 deletions

diff --git a/community/gsoc.mdwn b/community/gsoc.mdwn
index 6eece956..efd29841 100644
--- a/community/gsoc.mdwn
+++ b/community/gsoc.mdwn
@@ -57,13 +57,27 @@ subprojects.
 -->
 
 
-# Applying for a Task
+Applications for 2012 are closed.
 
-<!--
+# Accepted projects
 
-Applications for 2011 are closed.
+## Disk I/O Performance Tuning
 
--->
+by Maksym Planeta
+
+See the project's
+[public page](http://www.google-melange.com/gsoc/project/google/gsoc2012/mcsim/46002).
+
+## Virtualization Using Hurd Mechanisms
+
+by Pierre Thierry
+
+See the project's
+[public page](http://www.google-melange.com/gsoc/project/google/gsoc2012/nowhereman/36001)
+and [[complete proposal|gsoc/2012/virt/proposal]].
+
+
+# Possible projects
 
 We have a list of [[project_ideas]], and students are likewise encouraged to
 submit their own project proposals.  Please follow our
@@ -86,7 +100,6 @@ with Hurd development, even outside of the GSoC context.  Please don't hesitate
 to contact us regarding mentoring even if it's not GSoC time at the moment, or
 if you aren't a student anyway.
 
-
 # History
 
 In 2006 and [[2007]], we participated in GSoC under the umbrella of the GNU
diff --git a/community/gsoc/2012/virt/proposal.mdwn b/community/gsoc/2012/virt/proposal.mdwn
new file mode 100644
index 00000000..d89f45d5
--- /dev/null
+++ b/community/gsoc/2012/virt/proposal.mdwn
@@ -0,0 +1,95 @@
+[[!meta title="Original proposal"]]
+
+*This is the proposal as it has been submitted to Google Summer of
+Code.*
+
+# The name of the project
+
+Virtualization Using Hurd Mechanisms
+
+# Summary
+
+The goal is to create tools that let a user create a set of servers
+that implement a Hurd environment and the necessary resources, with
+the possibility of relying on existing servers in the parent Hurd for
+some of them, instead of creating them.
+
+# Benefits
+
+This project will permit to create isolated systems but with far more
+flexibility than traditional virtualization tools, because the degree
+of isolation can be changed and possibly not only at creation time,
+and communication and sharing of subsystems can be arranged between
+isolated systems.
+
+# Deliverables
+
+D1 — User stories for the toolset, that will later serve as examples
+for the documentation
+
+D2 — Exhaustive but concise documentation of the set of needed servers
+making a working Hurd system (as much for me as for future users of
+the tool, building and linking to existing Hurd documentation)
+
+D3 — Low-level tool to create a working Hurd environment (possibly
+with strong limitations on the shape of the resources used by the
+environment, most probably on the underlying filesystem)
+
+D4 — Fake or noop servers for the documented set of needed servers, to
+be provided instead of working ones, where a feature is to be denied
+to a Hurd environnement
+
+D5 — Proxy servers, where desirable, to provide access to servers
+outside the environment (in ocaps terminology, caretakers)
+
+D6 — Extension of the low-level tool from D3 to remove its
+unreasonable limitations
+
+D7 — High-level tools to easily create environments and run programs
+in them (akin respectively to debootstrap and schroot)
+
+D8 — If possible, extensions to the D5 and D7 tools to enable dynamic
+modifications of the features and authority granted to environments
+and creation of multiple interconnected environments
+
+# Plan
+
+I intend to develop using the Scrum method, with sprints of two weeks,
+which mean that each two weeks, I will present at least one new
+working feature, working incrementally towards the full deliverable. I
+will also push my code at least once a day to a public Git hosting,
+including topic branches, so my progress can be followed easily.
+
+I intend to start from crosshurd and see how I can hook in its process
+of creation to allow being provided alternatives. Depending on how
+crosshurd is malleable to those changes, a modified crosshurd will
+either be a learning-stage prototype or the base of the
+implementation.
+
+To reuse Git terminology, once plumbing tools (i.e. tools that take
+detailed invocation information for each server) are working fine,
+I'll move on to porcelain tools, the final UI (i.e. tools that provide
+sensible default options, aliases mechanisms, etc.).
+
+# Communication
+
+I'm usually easy to reach through both email and jabber, so those and
+IRC will be my main way to inform my mentor and ask questions. I'll
+setup an ikiwiki to have a summary of the exchanges and the temporary
+documentation of the project (i.e. documentation that doesn't fit with
+the code yet).
+
+# Qualification
+
+Thansk to or because of my participation to the Hurd mailing lists,
+I've been utterly contaminated by the concept of POLA a few years
+ago. Since then, I've been longing, almost in a painful way, for a
+object-capability flavour of Debian. Having to deal in my previous day
+jobs with virtualization tools like Xen and VMWare when I knew there
+would be no need for paravirtualization or emulation to isolate
+systems in an object-capability OS only made it worst.
+
+Now most of the code I produce naturally becomes capability oriented,
+even if my underlying platform, programming language or OS, doesn't
+provide true capabilities. And creating true POLA systems and making
+it possible for others to benefit from POLA is now one of my dreams.
diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn
index 5d42b5c6..8ce10ffa 100644
--- a/community/gsoc/project_ideas.mdwn
+++ b/community/gsoc/project_ideas.mdwn
@@ -98,7 +98,6 @@ other: language_bindings, gnat, gccgo, perl_python.  -->
 [[!inline pages="community/gsoc/project_ideas/secure_chroot" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/package_manager" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/download_backends" show=0 feeds=no actions=yes]]
-[[!inline pages="community/gsoc/project_ideas/libgtop" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/maxpath" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/gnat" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/gccgo" show=0 feeds=no actions=yes]]
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/community/weblogs/ArneBab/how-i-write-a-qoth.mdwn b/community/weblogs/ArneBab/how-i-write-a-qoth.mdwn
new file mode 100644
index 00000000..87b1f07d
--- /dev/null
+++ b/community/weblogs/ArneBab/how-i-write-a-qoth.mdwn
@@ -0,0 +1,44 @@
+I just read on the hurd IRC channel (chat: #hurd at irc.freenode.net), that people consider my work valuable (I knew that, and I think that myself, but it is still nice to hear), so I want to dispell any possible myth about it :)
+
+What I do is not hard - at least not anymore, since I created a simple structure for it (But it still takes time).
+
+First I open up the relevant mailing lists for the quarter. I get them from [[contributing/web_pages/news/writing_the_qoth]]. Normally I just use the following:
+
+* <http://lists.gnu.org/archive/html/bug-hurd/YYYY-MM/threads.html>
+* <http://lists.debian.org/debian-hurd/YYYY/MM/>
+
+Then I copy them 3 times and use M-x replace-string (in emacs) to adjust them to the correct months.
+
+Additionally I open the Arch Hurd news:
+
+* <http://www.archhurd.org/news.php>
+* <http://planet.archhurd.org/>
+
+Having all those news at hand, I read every thread-starter and every news-item. For each of them I first check if I understand them (no use trying to explain something I don’t get myself) and if they provide a way for people to test what they improved (however complex that might be), then I 
+
+* note the name of the main contributor(-s), 
+* write a line of text what it does (often partly copied from the news-item),
+* add a link to the news-item, a code-repo or a patch and
+* a note how that new development helps achieve the goals_of_the_Hurd (see [[contributing/web_pages/news/writing_the_qoth]] for details).
+
+With that list of short news I go into [[contributing/web_pages/news/qoth_next]]. 
+
+Now I identify 2 to 4 main news items by some kind of “helps the Hurd most when more people know it”, “biggest change” and similar fudgery :)
+
+Finally I sort all the news items by intuition, crude logic I develop on-the-fly writing and the goal of making the qoth read somewhat like nice prose. 
+
+On the way to that I commit every little to medium step. I never know when I have to abort due to an interruption (I’m sure tschwinge loves my super-non-atomic horrible-to-review commits :-) - but better that than losing work == time, and I try to prefix the commit-messages with “news:” so he knows that it’s useless to review them as in-flight-patches…).
+
+Having finished the text (usually after 3 to 6 hours of overall work), I send it by mail to bug-hurd: <http://lists.gnu.org/archive/html/bug-hurd/>
+
+After about a week I incorporate the comments from there and publish the qoth as described in [[contributing/web_pages/news/writing_the_qoth]].
+
+Then tschwinge reviews it, does some last-minute changes and pushes it from the staging wiki to the website.
+
+And that’s it.
+
+I hope this small insight was interesting to you. Happy hacking and have fun with the Hurd!
+
+-- Arne Babenhauserheide
+
+PS: Writing this blog entry took about 20 minutes. The raw text is longer than a qoth, but it is much faster to write, because it avoids the main time-eater: Gathering the info with the necessary references to make sure that people can test what’s in here.
diff --git a/contributing/web_pages/news/writing_the_qoth.mdwn b/contributing/web_pages/news/writing_the_qoth.mdwn
index 6aea5f4d..88542255 100644
--- a/contributing/web_pages/news/writing_the_qoth.mdwn
+++ b/contributing/web_pages/news/writing_the_qoth.mdwn
@@ -11,6 +11,7 @@ License|/fdl]]."]]"""]]
 
 # Short Guide for Writing the QotH
 
+The not yet published next Quarter of Hurd the can found at [[contributing/web_pages/news/qoth_next]]. 
 
 ## Individual News Items
 
diff --git a/hurd.mdwn b/hurd.mdwn
index 11995c87..1723c8b7 100644
--- a/hurd.mdwn
+++ b/hurd.mdwn
@@ -47,6 +47,7 @@ in the *unstable* branch of the Debian archive.
 * Introductory Material
   * [[Documentation]]
   * [Gaël Le Mignot](http://kilobug.free.fr/hurd/pres-en/slides/slides.html)
+  * [Neal Walfield](http://kerneltrap.org/node/5)
 * Architecture
   * [[Towards_a_New_Strategy_of_OS_Design|hurd-paper]] by Thomas Bushnell, BSG.
       * Marcus Brinkmann's [revisit](http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00651.html)
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/dde/guide.mdwn b/hurd/dde/guide.mdwn
index bf41dd79..132b36ae 100644
--- a/hurd/dde/guide.mdwn
+++ b/hurd/dde/guide.mdwn
@@ -14,6 +14,10 @@ with Debian GNU/Hurd,
 if your (wired) network card
 is not supported by the old in-kernel drivers shipped with gnumach.
 
+NOTE: As of hurd package 20120520-1, all that is already done for you, do *not*
+do anything mentioned below, and you just need to configure your TCP/IP stack by
+using settrans on /servers/socket/2, or dhclient /dev/eth0.
+
 This guide assumes that you have
 an installation of Debian GNU/Linux on the same machine,
 which helps in fetching the required packages
diff --git a/hurd/running/debian/qemu_image.mdwn b/hurd/running/debian/qemu_image.mdwn
index 809bf7b1..19b371c1 100644
--- a/hurd/running/debian/qemu_image.mdwn
+++ b/hurd/running/debian/qemu_image.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
@@ -15,7 +15,7 @@ Usage:
 
     $ wget http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz
     $ tar -xz < debian-hurd.img.tar.gz
-    $ qemu -net nic,model=rtl8139 -net user -hda debian-hurd-*.img
+    $ qemu -m 512 -net nic,model=rtl8139 -net user -hda debian-hurd-*.img
 
 Just in case you were wondering: the *root* password is *root*.
 
diff --git a/hurd/running/gnu/create_an_image.mdwn b/hurd/running/gnu/create_an_image.mdwn
index c7a97a4e..8784a826 100644
--- a/hurd/running/gnu/create_an_image.mdwn
+++ b/hurd/running/gnu/create_an_image.mdwn
@@ -1,12 +1,13 @@
-[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2007, 2008, 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]]."]]"""]]
 
 Creating a bootable qemu image from a root filesystem and bootloader
 
@@ -17,7 +18,7 @@ Creating a bootable qemu image from a root filesystem and bootloader
 2. Use a live CD (better to have a lighter OS like system rescue CD to make the
     process faster) and the image created to boot.
 
-        qemu -cdrom /dev/cdrom -hda <imagename.img> -boot d
+        qemu -m 512 -cdrom /dev/cdrom -hda <imagename.img> -boot d
 
 3. Once system is booted use a partition editing tool (like fdisk, cfdisk,
     parted, gparted, qtparted ...) to partition the image.
@@ -64,7 +65,7 @@ Creating a bootable qemu image from a root filesystem and bootloader
 
 11. Run qemu to boot into your brand new system 
 
-        qemu -hda <hard disk image.img> -fda grub.img -boot a
+        qemu -m 512 -hda <hard disk image.img> -fda grub.img -boot a
 
 Happy Hacking !!
 
diff --git a/hurd/running/live_cd.mdwn b/hurd/running/live_cd.mdwn
index c9360594..1eb9b8e0 100644
--- a/hurd/running/live_cd.mdwn
+++ b/hurd/running/live_cd.mdwn
@@ -8,7 +8,7 @@ MiB: <http://www.superunprivileged.org/hurd/tiny-cd/>
 
 Use it like this:
 
-    $ qemu -cdrom hurd-tiny-cd-20060722.iso
+    $ qemu -m 512 -cdrom hurd-tiny-cd-20060722.iso
 
 A more recent Live CD can be found at <http://teythoon.cryptobitch.de/hurd/livecd/hurd-live-install-1273300101.iso.xz>. 
 
@@ -16,7 +16,7 @@ It can be run with qemu via
 
     $ wget http://teythoon.cryptobitch.de/hurd/livecd/hurd-live-install-1273300101.iso.xz
     $ xz -d hurd-live-install-1273300101.iso.xz
-    $ qemu -cdrom hurd-live-install-1273300101.iso
+    $ qemu -m 512 -cdrom hurd-live-install-1273300101.iso
 
 These [[!wikipedia LiveCD]]s should be useful for those who want to try out the
 Hurd before they commit to installing it on their hard disks.  In addition to
diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn
index fcf58d8a..b64c576f 100644
--- a/hurd/running/qemu.mdwn
+++ b/hurd/running/qemu.mdwn
@@ -28,7 +28,8 @@ Note that the following images are unofficial ones: they have been prepared by
 volunteers and may not have been tested extensively.
 
 * [Disk image](http://draketo.de/dateien/hurd/bab-hurd-qemu-2008-10-29.img.tar.bz2) 
-  with a short intro on translators. Just start it with 'qemu *disk_image.img*'. 
+  with a short intro on translators.  Just start it with `qemu -m 512
+  disk_image.img`.
   It should work without any of the configuration below. If you want to know what you can do 
   with it, please have a look at [[its_wikipage|hurd/running/qemu/babhurd_image]]. And when 
   you use it, please [tell me your experience with it](http://draketo.de/contact)! - [[community/weblogs/ArneBab]]
@@ -272,7 +273,7 @@ This is the recommended way to work with a Command Line Interface (CLI) since al
 
 a) with ssh (assuming you have installed openssh-server)
 
-    $ kvm -m 1024 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -hda hd0.img &
+    $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -hda hd0.img &
 
 Logging in to the running Hurd:
 
@@ -289,7 +290,7 @@ Copying files:
 
 b) with telnet (assuming you have installed a telnet server, like telnetd)
 
-    $ kvm -m 1024 -net nic,model=rtl8139 -net user,hostfwd=tcp::5556-:23 -hda hurd-install.qemu &
+    $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5556-:23 -hda hurd-install.qemu &
 
 Logging in to the running Hurd:
 
@@ -330,7 +331,7 @@ Now it is time to start-up your QEMU Hurd system and get networking going in the
 
 **Important:** Remember you may need to use the `-M isapc` or `-isa` flag if using an older version of the gnumach package.
 
-    $ qemu -hda hd0.img -cdrom debian-K9-hurd-i386-CD1.iso -fda floppy.img -boot a -net nic -net tap
+    $ qemu -m 512 -hda hd0.img -cdrom debian-K9-hurd-i386-CD1.iso -fda floppy.img -boot a -net nic -net tap
 
 Once you have logged in as `root` run the `pfinet` translator with values that apply to your network. Think of your QEMU client as another computer in your network.
 
diff --git a/hurd/running/qemu/babhurd_image.mdwn b/hurd/running/qemu/babhurd_image.mdwn
index c0952fcf..855e8f51 100644
--- a/hurd/running/qemu/babhurd_image.mdwn
+++ b/hurd/running/qemu/babhurd_image.mdwn
@@ -5,8 +5,8 @@ What this little Hurd image can do
 
 This is the README file accompanying a 
 [disk\_image](http://draketo.de/dateien/hurd/bab-hurd-qemu-2008-10-29.img.tar.bz2) for 
-[[running_the_GNU/Hurd_via_qemu|hurd/running/qemu]]. To run the disk image, just use *'qemu 
-disk_image.img'*. 
+[[running the GNU/Hurd via qemu|hurd/running/qemu]].  To run the disk image,
+just use `qemu -m 512 disk_image.img`.
 
 You can find the custom *.bashrc* used to tell the user about it as well as this text itself 
 in the Mercurial repository [hurd_intro](http://bitbucket.org/ArneBab/hurd_intro). 
diff --git a/hurd/subhurd.mdwn b/hurd/subhurd.mdwn
index b8e595d3..f2117ead 100644
--- a/hurd/subhurd.mdwn
+++ b/hurd/subhurd.mdwn
@@ -31,7 +31,7 @@ flexible.)  Vice versa, it is also possible to use a subhurd to debug the
 To run a subhurd, you need an additional partition with an installed Hurd
 system.  In principle, you can also use your main partition in read-only mode;
 but this obviously will create severe limitations.  Usually, you will want a
-complete independant system.
+complete independent system.
 
 The system for the subhurd is a normal Hurd installation, which could just as
 well run standalone.  You can use any of the various possible installation
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/microkernel/mach/gnumach/debugging.mdwn b/microkernel/mach/gnumach/debugging.mdwn
index b57f0393..71e92459 100644
--- a/microkernel/mach/gnumach/debugging.mdwn
+++ b/microkernel/mach/gnumach/debugging.mdwn
@@ -29,7 +29,11 @@ To get the register values, type
 
     show registers
 
-To get a backtrace, type trace, which will print both function return addresses and function parameters, such as
+To get a backtrace, type
+
+    trace
+    
+, which will print both function return addresses and function parameters, such as
 
     0x107cf1(8088488,5e,40000008,2aa008,0)
     0x1071bc(0,0,0,0,0)
diff --git a/news/2010-04-30.mdwn b/news/2010-04-30.mdwn
index da4c0183..0b50122d 100644
--- a/news/2010-04-30.mdwn
+++ b/news/2010-04-30.mdwn
@@ -43,7 +43,7 @@ else="[[!paste id=full_news]]"]]
 
 > Mainly thanks to *Jose Luis Alarcon Sanchez*, we now have a [new QEMU
 > image](http://lists.debian.org/debian-hurd/2010/04/msg00098.html).  It can be
-> run with a simple `qemu -hda debian-hurd-17042010-qemu.img`.
+> run with a simple `qemu -m 512 -hda debian-hurd-17042010-qemu.img`.
 
 > *Thomas Schwinge* updated [our glibc maintenance
 > repository](http://git.savannah.gnu.org/cgit/hurd/glibc.git/?h=tschwinge/Roger_Whittaker)
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/file_system_exerciser.mdwn b/open_issues/file_system_exerciser.mdwn
index 4277e5e7..c51863b9 100644
--- a/open_issues/file_system_exerciser.mdwn
+++ b/open_issues/file_system_exerciser.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
@@ -13,3 +13,17 @@ License|/fdl]]."]]"""]]
 Test our file system implementations with the File System Exerciser.
 
   * <http://codemonkey.org.uk/projects/fsx/>
+
+
+# Alternatives
+
+
+## fs_mark
+
+
+### IRC, freenode, #hurd, 2012-04-30
+
+    <pinotree> mcsim: http://sourceforge.net/projects/fsmark/
+    <pinotree> mcsim: just saw it in debian's NEW queue and from the
+      description it seemed like something it could be helpful for you
+    <pinotree> (and in general to test fs'es)
diff --git a/open_issues/fork_deadlock.mdwn b/open_issues/fork_deadlock.mdwn
new file mode 100644
index 00000000..6b90aa0a
--- /dev/null
+++ b/open_issues/fork_deadlock.mdwn
@@ -0,0 +1,65 @@
+[[!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]]
+
+This started appearing when Jérémie's [[glibc]] signal patches were integrated:
+very sporadically, but still now and then, `fork` will hang, as follows, and
+typically in `/bin/sh`.
+
+From a `libtool` invocation:
+
+    #0  0x0107b13c in swtch_pri () at /build/eglibc-Q9jlik/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2
+    No locals.
+    #1  0x0107c9c4 in __spin_lock_solid (lock=0x125080c) at spin-solid.c:27
+    No locals.
+    #2  0x01091427 in __spin_lock (__lock=<optimized out>) at ../mach/lock-intern.h:55
+    No locals.
+    #3  _hurd_sigstate_lock (ss=0x1250008) at hurdsig.c:172
+    No locals.
+    #4  0x011261ec in _hurd_critical_section_unlock (our_lock=<optimized out>) at ../hurd/hurd/signal.h:235
+    No locals.
+    #5  __fork () at ../sysdeps/mach/hurd/fork.c:706
+            env = {{__jmpbuf = {18784244, 19197896, 1, 16925832, 16925460, 17980399}, __mask_was_saved = 0, __saved_mask = 33}}
+            pid = 0
+            err = <optimized out>
+            __PRETTY_FUNCTION__ = "__fork"
+            ss = 0x1250008
+            threads = 0x0
+            nthreads = 0
+            stopped = 1
+            i = 6
+    [...]
+
+
+Another one in `dash`:
+
+    #0  0x0105927c in swtch_pri () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2
+    No locals.
+    #1  0x0105ac44 in __spin_lock_solid (lock=0x123580c) at spin-solid.c:27
+    No locals.
+    #2  0x010701c7 in __spin_lock (__lock=<optimized out>) at ../mach/lock-intern.h:55
+    No locals.
+    #3  _hurd_sigstate_lock (ss=0x1235008) at hurdsig.c:172
+    No locals.
+    #4  0x011048f0 in _hurd_critical_section_unlock (our_lock=0x1235008) at ../hurd/hurd/signal.h:235
+            ss = 0x1235008
+            pending = <optimized out>
+    #5  __fork () at ../sysdeps/mach/hurd/fork.c:706
+            env = {{__jmpbuf = {18780148, 19087304, 134621988, 0, 16938700, 17842902}, __mask_was_saved = 0, __saved_mask = 4294967295}}
+            pid = 0
+            err = 0
+            __PRETTY_FUNCTION__ = "__fork"
+            ss = 0x1235008
+            threads = 0x0
+            nthreads = 0
+            stopped = 1
+            i = 6
+    [...]
diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn
index b15c880a..1ce47560 100644
--- a/open_issues/glibc.mdwn
+++ b/open_issues/glibc.mdwn
@@ -39,29 +39,12 @@ git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -p -C --cc ..sourcewa
 Last reviewed up to the [[Git mirror's d40c5d54cb551acba4ef1617464760c5b3d41a14
 (2012-02-28) sources|source_repositories/glibc]].
 
-  * t/dup3
-
-    [[tschwinge]] is not convinced that
-    22542dcc89805af8d9bd9209129259d2737372b5 (and then also
-    ff3f3a789ba08b656dbaa3901091b6410bb883f8) are correct.
-
-      * 94b7cc3711b0b74c1d3ae18b9a2e019e51a8e0bf -- dup3 changes; relevant for
-        `t/dup3`: hidden def.  ed690b2f24bbc4d9c541fc81a7c67e6dc5678a96 -- why
-        not for dup3, too?  Because it is a syscall (that is always inlined)?
-
   * `t/hurdsig-fixes`
 
         hurdsig.c: In function '_hurd_internal_post_signal':
         hurdsig.c:1188:26: warning: 'pending' may be used uninitialized in this function [-Wmaybe-uninitialized]
         hurdsig.c:1168:12: note: 'pending' was declared here
 
-  * `t/init-first.c`
-
-    Follow up here: [[!message-id "20070722171859.GN25744@fencepost.gnu.org"]]
-    or [[!message-id "87mxe4kwws.fsf@gnu.org"]].  Close [[!GNU_Savannah_bug
-    17647]].  Debian: [[!message-id "E1Qup1U-0006Zc-39@vasks.debian.org"]]
-    (part of Ludo's patch; the part that is not harmful to GCC 4.4).
-
   * `t/kernel-features.h_includes`
 
     Before running `tg update`, review for additional changes:
@@ -202,11 +185,88 @@ 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`
 
+      * `chflags`
+
+        IRC, OFTC, #debian-hurd, 2012-04-27:
+
+            <Steap> Does anyone have any idea why int main(void) { return
+              chflags(); } will compile with gcc but not with g++ ? It says
+              that "chflags" was not declared in this scope.
+            <Steap> I get the same error on FreeBSD, but including sys/stat.h
+              makes it work
+            <Steap> Can't find a solution on Hurd though :/
+            <youpi> the Hurd doesn't have chflags
+            <youpi> apparently linux neither
+            <youpi> what does it do?
+            <Steap> change flags :)
+            <Steap> Are you sure the Hurd does not have chflags ? Because gcc
+              does not complain
+            <youpi> there is no chflags function in /usr/include
+            <youpi> but what flags does it change?
+            <Steap> According to the FreeBSD manpage, it can set flags such as
+              UF_NODUMP, UF_IMMUTABLE etc.
+            <youpi> Hum, there is actually a chflags() definition
+            <youpi> but no declaration
+            <youpi> so actually chflags is supported, but the declaration was
+              forgotten
+            <youpi> probably because since linux doens't have it, it has never
+              been a problem up to now
+            <youpi> so I'd say ignore the error for now, we'll add the
+              declaration
+
+      * `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 +324,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_rpc_timeouts.mdwn b/open_issues/gnumach_rpc_timeouts.mdwn
new file mode 100644
index 00000000..68cfcb5a
--- /dev/null
+++ b/open_issues/gnumach_rpc_timeouts.mdwn
@@ -0,0 +1,19 @@
+[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_gnumach]]
+
+
+# IRC, freenode, #hurd, 2012-04-28
+
+    <pinotree> uhm, apparently mach cannot handle timeouts for rpc's of more
+      than (2^(sizeof(mach_msg_timeout_t) * 8) - 1) / HZ
+    <pinotree> it seems that how ticks are calculated in mach, it becomes 0
+    <pinotree> +because of
diff --git a/open_issues/gnumach_vm_map_red-black_trees.mdwn b/open_issues/gnumach_vm_map_red-black_trees.mdwn
new file mode 100644
index 00000000..17263099
--- /dev/null
+++ b/open_issues/gnumach_vm_map_red-black_trees.mdwn
@@ -0,0 +1,154 @@
+[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_gnumach]]
+
+
+# IRC, freenode, #hurd, 2012-04-23
+
+    <braunr> btw, i'm running a gnumach version using red-black trees for vm
+      map entries
+    <antrik> braunr: sounds fashionable ;-)
+    <youpi> braunr: with some perf improvement?
+    <braunr> looks promising for our ext2fs instances showing several thousands
+      of map entries
+    <braunr> youpi: i'm not using it for lookups yet
+    <braunr> but the tree is there, maintained, used for both regular and copy
+      maps, and it doesn't crash
+    <youpi> good :)
+    <braunr> antrik: isn't it ? :)
+    <braunr> youpi: and the diff stat is like 50/15
+    <antrik> braunr: what's the goal of using the fashionable trees?
+    <braunr> antrik: speeding up lookups in address spaces
+    <antrik> braunr: so the idea is that if we have a heavily fragmented
+      address space, the performance penalty is smaller?
+    <braunr> yes
+    <antrik> OK
+    <antrik> I take it you gave up on attempts to actually decrease
+      fragmentation?...
+    <braunr> it's not as good as reducing fragmentation, which requires
+      implementing a powerful merge, but it's still better
+    <braunr> yes
+    <braunr> it's too messy for my brain :/
+    <antrik> I see
+    <antrik> oh
+    <braunr> it will add some overhead though
+    <youpi> I guess log(n) ?
+    <braunr> but if there is a significant performance gain, it'll be worth it
+    <braunr> yes
+    <braunr> i was more thinking about the memory overhead
+    <antrik> right now it's a linear list?
+    <youpi> I don't think we care nowadays :)
+    <braunr> antrik: yes
+    <antrik> ouch
+    <braunr> antrik: yes ... :>
+    <braunr> the original authors expected vm maps to have like 30 entries
+    <braunr> so they used a list for the maps, and a hash table for the
+      object/offset to physical page lookups
+    <braunr> there is a small lookup cache though, which is a nice optimization
+    <braunr> my code now uses it first, and falls back to the RB tree if the
+      hint didn't help
+    <antrik> braunr: well, don't forget to check whether it actually *is* still
+      an optimisation, when using fashionable trees ;-)
+    <braunr> antrik: i checked that already :)
+    <braunr> i did the same in x15
+    <antrik> I see
+    <braunr> both bsd and linux uses a similar technique
+    <braunr> use*
+    <braunr> (well, bsd actually use what is done in mach :)
+    <antrik> (or perhaps the other way around... ;-) )
+    <braunr> i don't think so, as the bsd vm is really the mach vm
+    <braunr> but we don't care much
+    <antrik> oh, right... that part actually went full circle
+    <braunr> youpi: i have a patch ready for test on machines with significant
+      amounts of map entries (e.g. the buildds ..)
+    <braunr> youpi: i won't have time for tests tonight, are you interested ?
+    <braunr> (i've been running it for 15 minutes without any issue for now)
+    <youpi> I'd say post to the list
+    <braunr> ok
+    <youpi> braunr: your patch uses the rb tree for lookups, right?
+    <youpi> braunr: the buildd using rbtree seems swift
+    <youpi> but maybe it's just a psychologic effect :)
+    <youpi> the chroot ext2fs already has 1392 lines in vminfo
+    <youpi> an rbtree can't hurt  there :)
+    <youpi> braunr: it really seems faster
+    <youpi> the reboot might have helped too
+    <youpi> benchmarks shall say
+    <youpi> for now, I'll just let ironforge use it
+    <antrik> youpi: it's always fast after a reboot ;-)
+    <youpi> sure
+    <youpi> but still
+    <youpi> I mean
+    <youpi> *obviously* the reboot has helped
+    <youpi> but it might not be all
+    <youpi> at least it feels so
+    <youpi> and obviously only benchmarks can say
+    <antrik> the major benefit AIUI is rather that the slowdown happening over
+      time will be less noticable
+
+[[performance/degradation]].
+
+    <youpi> "over time" is actually quite fast
+    <youpi> ext2 fills up very quickly when you build a package
+    <youpi> it went up to 1700 lines very quickly
+    <youpi> and stabilized around there
+    <antrik> yeah, it can be very fast under heavy load
+    <youpi> that's why I say reboot seems not all
+    <youpi> it's already not so fresh
+    <youpi> with 1700 lines in vminfo
+    <antrik> well, I don't know how much of the slowdown I'm experiencing
+      (after doing stuff under memory pressure) is actually related to VM map
+      fragmentation...
+    <antrik> might be all, might be none, might be something in between
+    <youpi> then try his patch
+    <antrik> guess I should play a bit with vminfo...
+    <antrik> well, currently I actually experience pretty little slowdown, as
+      for certain reasons (only indirectly related to the Hurd) I'm not running
+      mutt on this machine, so I don't really have memory pressure...
+
+
+## IRC, freenode, #hurd, 2012-04-24
+
+    <braunr> youpi: yes, it uses bst lookups
+    <braunr> youpi: FYI, the last time i checked, one ext2fs instance had 4k+
+      map entries, and another around 7.5k
+    <braunr> (on ironforge)
+
+
+## IRC, freenode, #hurd, 2012-04-24
+
+    <youpi> braunr: $ sudo vminfo  624 | wc -l
+    <youpi> 22957
+    <youpi> there's no way it can not help :)
+    <braunr> youpi: 23k, that's really huge
+
+
+## IRC, freenode, #hurd, 2012-04-26
+
+    <braunr> youpi: any new numbers wrt the rbtree patch ?
+    <youpi> well, buildd times are not really accurate :)
+    <youpi> but what I can tell is that it managed to build qtwebkit fine
+    <braunr> ok
+    <youpi> so the patch is probably safe :)
+    <braunr> i'll commit it soon then
+    <youpi> I'd say feel free to, yes
+    <braunr> thanks
+
+
+## IRC, freenode, #hurd, 2012-04-27
+
+    <braunr> elmig: don't expect anything grand though, this patch is mostly
+      useful when address spaces get really fragmented, which mainly happens on
+      buildds
+    <braunr> (and it only speeds lookups, which isn't as good as reducing
+      fragmentation; things like fork still have to copy thousands of map
+      entries)
+
+[[glibc/fork]].
diff --git a/open_issues/largefile.mdwn b/open_issues/largefile.mdwn
new file mode 100644
index 00000000..a6f76a0e
--- /dev/null
+++ b/open_issues/largefile.mdwn
@@ -0,0 +1,21 @@
+[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_hurd]]
+
+
+# IRC, freenode, #hurd, 2012-04-26
+
+    <pinotree> i kind of understood why (at least in some parts) largefile doesn't seem to work properly
+    <pinotree> libdiskfs/io-seek.c, SEEK_SET case: cred->po->filepointer = offset;
+    <pinotree> offset is off_t, which becomes off64_t when compiled with largefile, but filepointer seems to be... int
+    <pinotree> at least in libdiskfs/diskfs.h, while in libnetfs/netfs.h seems ok (loff_t)
+    <pinotree> diskfs.h is a public header though :/
+    <youpi> well, we can change the soname to mark ABI change
diff --git a/open_issues/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..d243aaaa 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,114 @@ 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
+
+
+## IRC, freenode, #hurd, 2012-04-27
+
+    <pinotree> youpi: wouldn't be the case to rename ia32 subdirs to i386 in
+      libpthread?
+    <pinotree> after all, Makefile hardcodes it, Makefile.am sets the variable
+      for it, and glibc expects i386
+    <youpi> I know, I've asked tschwinge about it
+    <youpi> it's not urging anyway
+    <pinotree> right
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
 
diff --git a/unsorted/MakeImage.mdwn b/unsorted/MakeImage.mdwn
index 95b928c4..b3485771 100644
--- a/unsorted/MakeImage.mdwn
+++ b/unsorted/MakeImage.mdwn
@@ -53,7 +53,7 @@ I use this for testing OSKit...
 
 ## <a name="Booting_Qemu"> Booting Qemu </a>
 
-    qemu -user-net -isa -boot d -cdrom grub.iso -hda gnu.img
+    qemu -m 512 -user-net -isa -boot d -cdrom grub.iso -hda gnu.img
 
 The switch `-isa` is for current gnumach.gz on hda.
 
diff --git a/user/Maksym_Planeta.mdwn b/user/Maksym_Planeta.mdwn
index a0a9c788..fccf3840 100644
--- a/user/Maksym_Planeta.mdwn
+++ b/user/Maksym_Planeta.mdwn
@@ -9,10 +9,26 @@ is included in the section entitled [[GNU Free Documentation
 License|/fdl]]."]]"""]]
  
 [[!toc]]
+#GSoC 2012 - Disk I/O Performance Tuning 
+
+15.06.12
+
+Explored gnumach code. First I was reimplementing vm_fault_page as coroutine that returns before executing of mo_data_{unlock,request} calls to vm_fault. vm_fault had to analyse state of vm_fault_page for every page in loop and make a decision regarding further behavior (call mo_data_*, go to next page, etc.). But than I've got that this way is much worse, than doing everything in vm_fault_page (like in OSF mach), so I made a back-off and started working on clustered paging from the beginning (at least now I see clearer how things should be). At the moment I review kam's patch one more time and looked through mklinux code attentively.
+
+8.06.12
+
+Applied Neal's patch that reworks libpager, changed libdiskfs, tmpfs and ext2fs according to new interface. ext2fs isn't finished yet and should be reworked, but looks like I brought some bug to existing implementation and i want first to fix it and than finish rest of ext2fs. Also I pushed some code changes to hurd git repository into my branch mplaneta/gsoc12/working. Now I start working on gnumach implementation of clustered page reading. After this I'm going to implement madvise, than finish ext2fs and start porting of other translators.
+
+14.05.12
+
+First of all I'm going to do 2 programs. First will work as server, it will create an object and share it with second. Second will try to access to this object. This will cause page fault and kernel will refer to first program (server). This way I will be able to track how page faults are resolved and this will help me in debugging of readahead. IFR: server probably can use some of hurd's libraries, but it has to handle m_o_* RPC's on it's own. TODO: Find out how supply second program (client) with new object. NB: be sure that client will cause page fault, so that server always will be called (probably any caching should be disabled).
+
 #Notes on tmpfs
 
 ## Current state
 
+Finished
+
 26.01.12
 
 Infinite fsx on ext2fs: