Merge branch 'master' of http://git.savannah.gnu.org/cgit/hurd/web

14 files changed, 306 insertions, 155 deletions

diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn
index fd24f081..df6290f7 100644
--- a/hurd/debugging/rpctrace.mdwn
+++ b/hurd/debugging/rpctrace.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011 Free Software
+[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012 Free Software
 Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -89,6 +89,84 @@ See `rpctrace --help` about how to use it.
         <pinotree> braunr: the output of rpctrace --help should tell the
           default dir for msgids
 
+* IRC, freenode, #hurd, 2012-06-30
+
+        <mcsim> hello. Has anyone faced with problem when translator works
+          fine, but when it is started via rpctrace it hangs? Probably you know
+          what can cause this?
+        <antrik> mcsim: rpctrace itself is quite buggy
+        <antrik> zhengda once did a number of improvements, but they never went
+          upstream...
+        <youpi> well, he never explained how his fixes worked :)
+        <youpi> GNU/Hurd is no different from other projects in that regard: if
+          you don't explain how your patches work, there's low chance that they
+          are applied
+        <youpi> unless the maintainer has time to dive himself, which we don't
+        <pinotree> "it compiles, ship it!"
+        <braunr> pinotree: i guess the hurd is different in that particular
+          regard :p
+        <youpi> not different from linux
+        <braunr> eh, they include staging drivers now :)
+        <youpi> we have a sort-of staging tree as well, with netdde
+        <youpi> we don't really care about stability there
+        <antrik> youpi: actually, I think by now (and not to a small part
+          because of this episode) that we are too strict about patch
+          submission
+        <youpi> well, review really is needed, otherwise source gets into a bad
+          shape
+        <antrik> while zhengda's variant might not have been ideal (nobody of
+          us understands the workings of rpctrace enough to tell), I have
+          little doubt that it would be an improvement...
+        <youpi> it happened quite a few times that a fix revealed to be
+          actually bogus
+        <youpi> in that particular case, I agree
+        <youpi> the problem is that usually what happens is that questions are
+          asked
+        <youpi> and the answers never happen
+        <youpi> and thus the patch gets lost
+        <antrik> after all, when he when he submitted that patch, he had a much
+          better understanding of rpctrace than any of us...
+        <youpi> sure
+        <antrik> Linus is actually quite pragmatic about that. from what I've
+          seen, if he can be convinced that something is *probably* an
+          improvement over the previous status, he will usually merge it, even
+          if he has some qualms
+        <youpi> when there is a maintainer, he usually requires his approval,
+          doesn't he?
+        <antrik> in particular, for code that is new or has been in a very bad
+          shape before, standards shouldn't be as high as for changes to known
+          good code. and quite frankly, large parts of the Hurd code base
+          aren't all that good to begin with...
+        <youpi> sure
+        <antrik> well, sure. in this case, we should have just appointed
+          zhengda to be the rpctrace maintainer :-)
+        <antrik> BTW, as his version is quite fundamentally different, perhaps
+          instead of merging the very large patch, perhaps we should just ship
+          both versions, and perhaps drop the old one at some point if the new
+          one turns out to work well...
+        <antrik> (and perhaps I overused the word perhaps in that sentence
+          perhaps ;-) )
+        <youpi> about that particular patch, you had needed raised a few bits
+        <youpi> and there was no answers
+        <youpi> the patch is still in my mbox, far away
+        <youpi> so it was *not* technically lost
+        <youpi> it's just that as usual we lack manpower
+        <antrik> yeah, I know. but many of the things I raised were mostly
+          formalisms, which might be helpful for maintaining high-quality code,
+          but probably were just a waste of time and effort in this case... I'm
+          not surprised that zhengda lost motivation to pursue this further :-(
+        <braunr> it would help a lot to get the ton of patches in the debian
+          packages upstream :)
+        <youpi> braunr: there  aren't many, and usually for a good reason
+        <youpi> some of them are in debian for testing, and can probably be
+          commited at some point
+        <pinotree> youpi: we could mark (with dep3 headers) the ones which are
+          meant to be debian-specific
+        <youpi> sure
+        <antrik> well, there are also a few patches that are not exactly
+          Debian-specific, but not ready for upstream either...
+        <youpi> antrik: yes
+
 
 # See Also
 
diff --git a/hurd/libihash.mdwn b/hurd/libihash.mdwn
index 03ebae82..d6b8e8b6 100644
--- a/hurd/libihash.mdwn
+++ b/hurd/libihash.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2009, 2010, 2011 Free Software Foundation,
+[[!meta copyright="Copyright © 2009, 2010, 2011, 2012 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -6,8 +6,8 @@ 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]]."]]"""]]
 
 [[!tag open_issue_hurd]]
 
@@ -48,6 +48,8 @@ is included in the section entitled
 
   * libstdc++: `unordered_map`, `tr1/unordered_map`, `ext/hash_map`
 
+  * libiberty: `hashtab.c`
+
   * <http://cmph.sourceforge.net/>
 
   * <http://libhashish.sourceforge.net/>
diff --git a/hurd/running/debian/qemu_image.mdwn b/hurd/running/debian/qemu_image.mdwn
index 19b371c1..de1027b7 100644
--- a/hurd/running/debian/qemu_image.mdwn
+++ b/hurd/running/debian/qemu_image.mdwn
@@ -15,7 +15,9 @@ Usage:
 
     $ wget http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz
     $ tar -xz < debian-hurd.img.tar.gz
-    $ qemu -m 512 -net nic,model=rtl8139 -net user -hda debian-hurd-*.img
+    $ qemu -m 512 -net nic,model=rtl8139 -net user -drive cache=writeback,index=0,media=disk,file=$(echo debian-hurd-*.img)
+
+See the discussion about [[hurd/running/qemu/writeback_caching]].
 
 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 8784a826..98af99eb 100644
--- a/hurd/running/gnu/create_an_image.mdwn
+++ b/hurd/running/gnu/create_an_image.mdwn
@@ -18,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 -m 512 -cdrom /dev/cdrom -hda <imagename.img> -boot d
+        qemu -m 512 -cdrom /dev/cdrom -drive cache=writeback,index=0,media=disk,file=<imagename.img> -boot d
 
 3. Once system is booted use a partition editing tool (like fdisk, cfdisk,
     parted, gparted, qtparted ...) to partition the image.
@@ -65,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 -m 512 -hda <hard disk image.img> -fda grub.img -boot a
+        qemu -m 512 -drive cache=writeback,index=0,media=disk,file=<hard disk image.img> -fda grub.img -boot a
 
 Happy Hacking !!
 
diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn
index b64c576f..512ea602 100644
--- a/hurd/running/qemu.mdwn
+++ b/hurd/running/qemu.mdwn
@@ -12,6 +12,8 @@ License|/fdl]]."]]"""]]
 This page discusses things for [[Unix]] systems, there is a separate page for
 [[Microsoft_Windows]] systems.
 
+See the discussion about [[hurd/running/qemu/writeback_caching]].
+
 # Readily Available Images
 
 You can use the following images to give the GNU/Hurd a try.
@@ -29,7 +31,7 @@ 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 -m 512
-  disk_image.img`.
+  -drive cache=writeback,index=0,media=disk,file=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]]
@@ -125,7 +127,7 @@ First off you will need to create a disk image using `qemu-img`. I have set mine
 
 Next you will want to start up QEMU and begin the installation process.
 
-    $ qemu -m 512 -hda hd0.img -cdrom mini.iso -net nic,model=rtl8139 -net user
+    $ qemu -m 512 -drive cache=writeback,index=0,media=disk,file=hd0.img -cdrom mini.iso -net nic,model=rtl8139 -net user
 
 Now at his point do the regular install using `hd0` as your harddrive. Partition it and install the base system.
 
@@ -175,7 +177,7 @@ Also see another text about how to [[gnu/create_an_image]] for the
 
 Starting qemu/qemu-kvm:
 
-    $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -hda hd0.img -vga vmware
+    $ kvm -m 512 -net nic,model=rtl8139 -net user,hostfwd=tcp::5555-:22 -drive cache=writeback,index=0,media=disk,file=hd0.img -vga vmware
     vmsvga_value_write: guest runs Linux.
 
 Note: See below on port forwarding in the networking section.
@@ -273,7 +275,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 512 -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 -drive cache=writeback,index=0,media=disk,file=hd0.img &
 
 Logging in to the running Hurd:
 
@@ -290,7 +292,7 @@ Copying files:
 
 b) with telnet (assuming you have installed a telnet server, like telnetd)
 
-    $ kvm -m 512 -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 -drive cache=writeback,index=0,media=disk,file=hurd-install.qemu &
 
 Logging in to the running Hurd:
 
@@ -331,7 +333,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 -m 512 -hda hd0.img -cdrom debian-K9-hurd-i386-CD1.iso -fda floppy.img -boot a -net nic -net tap
+    $ qemu -m 512 -drive cache=writeback,index=0,media=disk,file=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 855e8f51..6a3bb30e 100644
--- a/hurd/running/qemu/babhurd_image.mdwn
+++ b/hurd/running/qemu/babhurd_image.mdwn
@@ -6,7 +6,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 -m 512 disk_image.img`.
+just use `qemu -m 512 -drive
+cache=writeback,index=0,media=disk,file=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/running/qemu/discussion.mdwn b/hurd/running/qemu/discussion.mdwn
index 1ce14b01..facb8a31 100644
--- a/hurd/running/qemu/discussion.mdwn
+++ b/hurd/running/qemu/discussion.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011 Free
-Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 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
@@ -50,95 +50,3 @@ The problem is actually that the linux block cache doesn't make any consistency
 between /dev/hda and /dev/hda6, so if you give /dev/hda to qemu, qemu writings
 won't be consistent with mounting /dev/hda6 in linux. You can give /dev/hda6
 directly to qemu and it will be fine.
-
-
-# Host-side Writeback Caching
-
-IRC, freenode, #hurd, 2011-06-07
-
-    <braunr> hm, i guess i should have used cache=writeback with kvm before
-      starting the debian installer :/
-    <braunr> ah yes, much better
-    <braunr> this shows how poor the state of our I/O drivers and subsystem is
-      :/
-    <antrik> indeed... still no clustered pageout :-(
-    <braunr> and no I/O scheduler either
-    <braunr> although an I/O scheduler has limited value without clustered
-      pageouts
-    <braunr> since one of its goals is to pack related I/O requests together eh
-    <braunr> i wonder if the wiki mentions using cache=writeback to speed up
-      qemu performances
-    <braunr> it would help those unable to use kvm a lot
-    <braunr> and even those running kvm too
-    <braunr> kvm -m $RAM \ -monitor stdio \ -drive
-      cache=writeback,index=0,media=disk,file=hd0.img \
-    <braunr> etc..
-    <braunr> the idea is that qemu doesn't open its disk file synchronously
-    <braunr> changes are queued in the host page cache before being flushed to
-      the disk image
-    <braunr> but if you brutally close your qemu instance, you're likely to
-      loose file system consistency
-    <braunr> ext2fs will think it has committed its metadata to the disk, but
-      the disk image won't be updated synchronously
-    <braunr> on my machine (which is quite fast), my kvm has installed debian
-      like 10 times faster than without the option
-    <antrik> braunr: I don't think killing qemu should hurt in this
-      case... probably only matters when the host machine dies
-    <braunr> antrik: ah yes, right
-    <braunr> it really makes everything faster, even downloading, since I/O
-      requests aren't interleaved between networking RPCs
-    <antrik> regarding I/O sheduler... this discussion came up before, but I
-      don't remember the outcome -- doesn't the glued Linux driver actually
-      come with one?
-    <braunr> i don't remember either
-    <antrik> braunr: err... I don't think interleaving has anything to do with
-      it... I guess it's simply the fact that downloading writes the result to
-      disk, which suffers from lacking clustered pageout like everything else
-    <antrik> (my internet connection is too slow though to notice :-) )
-    <braunr> well, if there is no I/O during downloading, downloading is faster
-      :)
-
-IRC, freenode, #hurd, 2011-06-08
-
-    <braunr> youpi: does xen provide disk caching options ?
-    <youpi> through a blktap, probably
-    <braunr> ok
-
-([[microkernel/mach/gnumach/ports/Xen]], *Host-side Writeback Caching*.)
-
-    <braunr> we should find the pages mentioning qemu on the wiki and add the
-      options to enable disk image caching
-    <braunr> it really makes the hurd run a lot faster
-    <braunr> as a workaround for emulators until I/O is reworked, ofc
-
-IRC, freenode, #hurd, 2011-06-09
-
-    <gnu_srs> braunr recommends to use writeback caching with kvm. Is this
-      really recommended with the frequent crashes I experience?
-    <youpi> provided that you terminate your kvm normaly (i.e. quitting it, not
-      killing it), there should be no difference
-    <jkoenig> I think the host's stability is what matters
-    <jkoenig> the data presumably sits in linux's cache even if qemu dies
-      violently
-    <gnu_srs> But the freezes I see force me to kill kvm :-(
-    <youpi> maybe kvm doesn't even do caching indeed, I don't know
-    <youpi> gnu_srs: you can quit even when frozen
-    <youpi> use the console
-    <youpi> (the kvm console)
-    <jkoenig> gnu_srs, "Writeback caching will report data writes as completed
-      as soon as the data is present in the host page cache.  This is safe as
-      long as you trust your host.  If your host crashes or loses power, then
-      the guest may experience data corruption." (from the qemu manpage)
-
-IRC, freenode, #hurd, 2011-06-11
-
-    <gnu_srs> braunr: If you are online. For me setting the parameters -drive
-      cache=writeback,index=0,media=disk,file=hd0.img does not show any speed
-      improvement at all compared to the default.
-    <braunr> gnu_srs: what's your complete qemu command line ?
-    <gnu_srs> kvm -m 1024 -net nic,model=rtl8139 -net
-      user,hostfwd=tcp::5556-:22 -drive
-      cache=writeback,index=0,media=disk,file=hd0.img -cdrom netinst.iso
-    <braunr> what qemu version ?
-    <gnu_srs>  qemu-kvm  0.14.1+dfsg-1: Sorry, I cannot be online until
-      tomorrow again.
diff --git a/hurd/running/qemu/microsoft_windows.mdwn b/hurd/running/qemu/microsoft_windows.mdwn
index 832b4bef..e2c8636c 100644
--- a/hurd/running/qemu/microsoft_windows.mdwn
+++ b/hurd/running/qemu/microsoft_windows.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]]."]]"""]]
 
 Welcome, This document is for getting you started in a few minutes.
 
@@ -46,7 +47,5 @@ Welcome, This document is for getting you started in a few minutes.
 ## QEmu Image Hangs on Boot
 The Debian GNU/Hurd K16 QEmu image hangs during the boot process. You may have better luck by converting the image to qcow format
 
-    ..\qemu-0.9.0-x86\qemu-img.exe convert debian-hurd-k16-qemu.img -O
-    qcow debian-hurd-k16-qemu.qcow
-    ..\qemu-0.9.0-x86\qemu.exe -L ..\qemu-0.9.0-x86 -m 512 -hda
-    debian-hurd-k16-qemu.qcow -localtime -M pc
+    ..\qemu-0.9.0-x86\qemu-img.exe convert debian-hurd-k16-qemu.img -O qcow debian-hurd-k16-qemu.qcow
+    ..\qemu-0.9.0-x86\qemu.exe -L ..\qemu-0.9.0-x86 -m 512 -drive cache=writeback,index=0,media=disk,file=debian-hurd-k16-qemu.qcow -localtime -M pc
diff --git a/hurd/running/qemu/writeback_caching.mdwn b/hurd/running/qemu/writeback_caching.mdwn
new file mode 100644
index 00000000..c9c53e3e
--- /dev/null
+++ b/hurd/running/qemu/writeback_caching.mdwn
@@ -0,0 +1,90 @@
+[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 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]]."]]"""]]
+
+[[!meta title="Host-side Writeback Caching"]]
+
+[[!tag open_issue_documentation]]
+
+IRC, freenode, #hurd, 2011-06-07
+
+    <braunr> hm, i guess i should have used cache=writeback with kvm before
+      starting the debian installer :/
+    <braunr> ah yes, much better
+    <braunr> this shows how poor the state of our I/O drivers and subsystem is
+      :/
+    <antrik> indeed... still no clustered pageout :-(
+    <braunr> and no I/O scheduler either
+    <braunr> although an I/O scheduler has limited value without clustered
+      pageouts
+    <braunr> since one of its goals is to pack related I/O requests together eh
+    <braunr> i wonder if the wiki mentions using cache=writeback to speed up
+      qemu performances
+    <braunr> it would help those unable to use kvm a lot
+    <braunr> and even those running kvm too
+    <braunr> kvm -m $RAM \ -monitor stdio \ -drive
+      cache=writeback,index=0,media=disk,file=hd0.img \
+    <braunr> etc..
+    <braunr> the idea is that qemu doesn't open its disk file synchronously
+    <braunr> changes are queued in the host page cache before being flushed to
+      the disk image
+    <braunr> but if you brutally close your qemu instance, you're likely to
+      loose file system consistency
+    <braunr> ext2fs will think it has committed its metadata to the disk, but
+      the disk image won't be updated synchronously
+    <braunr> on my machine (which is quite fast), my kvm has installed debian
+      like 10 times faster than without the option
+    <antrik> braunr: I don't think killing qemu should hurt in this
+      case... probably only matters when the host machine dies
+    <braunr> antrik: ah yes, right
+    <braunr> it really makes everything faster, even downloading, since I/O
+      requests aren't interleaved between networking RPCs
+    <antrik> regarding I/O sheduler... this discussion came up before, but I
+      don't remember the outcome -- doesn't the glued Linux driver actually
+      come with one?
+    <braunr> i don't remember either
+    <antrik> braunr: err... I don't think interleaving has anything to do with
+      it... I guess it's simply the fact that downloading writes the result to
+      disk, which suffers from lacking clustered pageout like everything else
+    <antrik> (my internet connection is too slow though to notice :-) )
+    <braunr> well, if there is no I/O during downloading, downloading is faster
+      :)
+
+IRC, freenode, #hurd, 2011-06-08
+
+    <braunr> youpi: does xen provide disk caching options ?
+    <youpi> through a blktap, probably
+    <braunr> ok
+
+([[microkernel/mach/gnumach/ports/Xen]], *Host-side Writeback Caching*.)
+
+    <braunr> we should find the pages mentioning qemu on the wiki and add the
+      options to enable disk image caching
+    <braunr> it really makes the hurd run a lot faster
+    <braunr> as a workaround for emulators until I/O is reworked, ofc
+
+IRC, freenode, #hurd, 2011-06-09
+
+    <gnu_srs> braunr recommends to use writeback caching with kvm. Is this
+      really recommended with the frequent crashes I experience?
+    <youpi> provided that you terminate your kvm normaly (i.e. quitting it, not
+      killing it), there should be no difference
+    <jkoenig> I think the host's stability is what matters
+    <jkoenig> the data presumably sits in linux's cache even if qemu dies
+      violently
+    <gnu_srs> But the freezes I see force me to kill kvm :-(
+    <youpi> maybe kvm doesn't even do caching indeed, I don't know
+    <youpi> gnu_srs: you can quit even when frozen
+    <youpi> use the console
+    <youpi> (the kvm console)
+    <jkoenig> gnu_srs, "Writeback caching will report data writes as completed
+      as soon as the data is present in the host page cache.  This is safe as
+      long as you trust your host.  If your host crashes or loses power, then
+      the guest may experience data corruption." (from the qemu manpage)
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index ad79c7b9..8e15d1c7 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -18,6 +18,8 @@ License|/fdl]]."]]"""]]
 
   * [[Page_cache]]
 
+  * [[metadata_caching]]
+
 
 ## Large Stores
 
@@ -43,6 +45,48 @@ Smaller block sizes are commonly automatically selected by `mke2fs` when using
 small backend stores, like floppy devices.
 
 
+#### IRC, freenode, #hurd, 2012-06-30
+
+    <braunr> at least having the same api in the debian package and the git
+      source would be great (in reference to the large store patch ofc)
+    <youpi> braunr: the api part could be merged perhaps
+    <youpi> it's very small apparently
+    <antrik> braunr: the large store patch is a sad story. when it was first
+      submitted, one of the maintainers raised some concerns. the other didn't
+      share these (don't remember who is who), but the concerned one never
+      followed up with details. so it has been in limbo ever since. tschwinge
+      once promised to take it up, but didn't get around to it so far. plus,
+      the original author himself mentioned once that he didn't consider it
+      finished...
+    <youpi> antrik: it's clearly not finished
+    <youpi> there are XXXs here and there
+    <braunr> it's called an RC1 and RC2 is mentioned in the release notes
+    <antrik> youpi: well, that doesn't stop most other projects from commiting
+      stuff... including most emphatically the original Hurd code :-)
+    <youpi> what do you refer to my "that" ? :)
+    <braunr> "XXX"
+    <youpi> right
+    <youpi> at the time it made sense to delay applying
+    <youpi> but I guess by nowadays standard we should just as well commit it
+    <youpi> it works enough for Debian, already
+    <youpi> there is just one bug I nkow about
+    <youpi> the apt database file keeps haveing the wrong size, fixed by e2fsck
+    <pinotree> youpi: remember that patch should be fixed in the offset
+      declaration in diskfs.h
+    <youpi> I don't remember about that
+    <youpi> did we fix it in the debian package?
+    <pinotree> nope
+    <youpi> you had issues when fixing it, didn't you?
+    <youpi> (I don't remember where I can find the details about this)
+    <pinotree> i changed it, recompiled hurd and installed it, started a perl
+      rebuild and when running one of the two lfs tests it hard locked the vm
+      after ext2fs was taking 100% cpu for a bit
+    <pinotree> i don't exclude i could have done something stupid on my side
+      though
+    <youpi> or there could just be actual issues, uncovered here
+    <youpi> which can be quite probable
+
+
 # Documentation
 
   * <http://e2fsprogs.sourceforge.net/ext2.html>
diff --git a/hurd/translator/procfs.mdwn b/hurd/translator/procfs.mdwn
index 70448e94..cccce0b7 100644
--- a/hurd/translator/procfs.mdwn
+++ b/hurd/translator/procfs.mdwn
@@ -1,13 +1,13 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2008, 2009, 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]]."]]"""]]
 
 Although there is no standard (POSIX or other) for the layout of the `/proc`
 pseudo-filesystem, it turned out a very useful facility in GNU/Linux and other
@@ -23,13 +23,23 @@ management tools to work.  (On Linux, the `/proc` filesystem is used also for
 debugging purposes; but this is highly system-specific anyways, so there is
 probably no point in trying to duplicate this functionality as well...)
 
-*Status*: Madhusudan.C.S has implemented a new, fully functional [[procfs|madhusudancs]] for
-[[GSoC 2008|community/gsoc/2008]].
+Ther was an implementation in [[open_issues/HurdExtras]],
+<http://www.nongnu.org/hurdextras/#procfs>.
 
+Madhusudan.C.S has implemented a new, fully functional [[procfs|madhusudancs]] for
+[[GSoC 2008|community/gsoc/2008]].
 
-# [[New Implementation by Jérémie Koenig|jkoenig]]
+In August 2010, Jérémie Koenig [published another, new
+version](http://lists.gnu.org/archive/html/bug-hurd/2010-08/msg00165.html).
+This can be found in <http://git.savannah.gnu.org/cgit/hurd/procfs.git/>.
 
+Testing it is as simple as this:
 
-# Old Implementation from [[open_issues/HurdExtras]]
+    $ git clone git://git.savannah.gnu.org/hurd/procfs.git
+    $ cd procfs/
+    $ git checkout master
+    $ make
+    $ settrans -ca proc procfs --compatible
+    $ ls -l proc/
 
-<http://www.nongnu.org/hurdextras/#procfs>
+[[Open issues|jkoenig/discussion]].
diff --git a/hurd/translator/procfs/jkoenig.mdwn b/hurd/translator/procfs/jkoenig.mdwn
deleted file mode 100644
index 9543b658..00000000
--- a/hurd/translator/procfs/jkoenig.mdwn
+++ /dev/null
@@ -1,23 +0,0 @@
-[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-In August 2010, Jérémie Koenig [published another, new
-version](http://lists.gnu.org/archive/html/bug-hurd/2010-08/msg00165.html).
-This can be found in <http://git.savannah.gnu.org/cgit/hurd/procfs.git/>,
-branch *jkoenig/master*.
-
-Testing it is as simple as this:
-
-    $ git clone git://git.savannah.gnu.org/hurd/procfs.git
-    $ cd procfs/
-    $ git checkout jkoenig/master
-    $ make
-    $ settrans -ca proc procfs --compatible
-    $ ls -l proc/
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn
index e7fdf46e..4f6492ed 100644
--- a/hurd/translator/procfs/jkoenig/discussion.mdwn
+++ b/hurd/translator/procfs/jkoenig/discussion.mdwn
@@ -18,9 +18,6 @@ License|/fdl]]."]]"""]]
 
 IRC, #hurd, around September 2010
 
-    <youpi> jkoenig: from a quick read, your procfs implementation seems quite
-      simple, probably much more what I was expecting from Madhusudan (who
-      probably now hates you :) )
     <youpi> jkoenig: is it not possible to provide a /proc/self which points at
       the client's pid?
     <pinotree> (also, shouldn't /proc/version say something else than "Linux"?)
@@ -68,7 +65,7 @@ IRC, #hurd, around October 2010
       owner, but always with root group
 
 
-# `/proc/$pid/stat` being 400 and not 444, and some more
+# `/proc/[PID]/stat` being 400 and not 444, and some more
 
 IRC, freenode, #hurd, 2011-03-27
 
@@ -187,7 +184,7 @@ IRC, freenode, #hurd, 2011-07-22
       server anyway, I think.
 
 
-# `/proc/mounts`, `/proc/$pid/mounts`
+# `/proc/mounts`, `/proc/[PID]/mounts`
 
 IRC, freenode, #hurd, 2011-07-25
 
@@ -277,3 +274,42 @@ Needed by glibc's `pldd` tool (commit
     <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...
+
+
+# `/proc/[PID]/maps`
+
+## IRC, OFTC, #debian-hurd, 2012-06-20
+
+    <pinotree> bdefreese: the two elfutils tests fail because there are no
+      /proc/$pid/maps files
+    <pinotree> that code is quite relying on linux features, like locating the
+      linux kernel executables and their modules, etc
+    <pinotree> (see eg libdwfl/linux-kernel-modules.c)
+    <pinotree> refactor elfutils to have the linux parts executed only on linux
+      :D
+    <bdefreese> Oh yeah, the maintainer already seems really thrilled about
+      Hurd..  Did you see
+      http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662041 ?
+    <pinotree> kurt is generally helpful with us (= hurd)
+    <pinotree> most probably there he is complaining that we let elfutils build
+      with nocheck (ie skipping the test suite run) instead of investigate and
+      report why the test suite failed
+
+
+# IRC, freenode, #hurd, 2011-06-19
+
+    <pinotree> jkoenig: procfs question: in process.c, process_lookup_pid, why
+      is the entries[2].hook line repeated twice?
+    <jkoenig> pinotree, let me check
+    <jkoenig> pinotree, it's probably just a mistake, there's no way the second
+      one has any effect
+    <pinotree> jkoenig: i see, it looked like you c&p'd that code accidentally
+    <jkoenig> pinotree, it's probably what happened, yes.
+
+
+# `/proc/[PID]/cwd`
+
+## IRC, freenode, #hurd, 2012-06-30
+
+    * pinotree has a local work to add the /proc/$pid/cwd symlink, but relying
+        on "internal" (but exported) glibc functions
diff --git a/hurd/translator/short-circuiting.mdwn b/hurd/translator/short-circuiting.mdwn
index 9de9f7b8..6f608fb2 100644
--- a/hurd/translator/short-circuiting.mdwn
+++ b/hurd/translator/short-circuiting.mdwn
@@ -1,12 +1,12 @@
-[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 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]]."]]"""]]
 
 In traditional [[Unix]], file systems contain special files.  These are:
 symbolic links, character devices, block devices, named pipes, and
@@ -60,6 +60,8 @@ To make sure that you use one of these translators, there by bypassing the
 short-circuiting mechanism, you can either start it as
 an active translator, or use a different path from the one in
 `hurd/path.h`, e.g. `settrans bar /hurd/./symlink foo`.
+There is also a `FS_TRANS_FORCE` flag defined for the `file_set_translator`
+RPCs, but it currently isn't set from anywhere.
 
 The best example of how short-circuiting is implemented can be found
 in [[`libdiskfs`|libdiskfs]].  Notice how it detects if a translator to store