Merge branch 'master' of flubber:~hurd-web/hurd-web

23 files changed, 702 insertions, 210 deletions

diff --git a/hurd.mdwn b/hurd.mdwn
index 18987760..010e9100 100644
--- a/hurd.mdwn
+++ b/hurd.mdwn
@@ -10,7 +10,7 @@ is included in the section entitled
 [[GNU Free Documentation License|/fdl]]."]]"""]]
 
 The GNU Hurd is under active development.  Because of that, there is no
-*stable* version.  We distribute the Hurd sources only through CVS at present.
+*stable* version.  We distribute the Hurd sources only through [[Git|source_repositories]] at present.
 
 Although it is possible to bootstrap the GNU/Hurd system from the sources by
 cross-compiling and installing the system software and the basic applications,
diff --git a/hurd/running/gnu/discussion.mdwn b/hurd/running/gnu/discussion.mdwn
deleted file mode 100644
index 7a96803b..00000000
--- a/hurd/running/gnu/discussion.mdwn
+++ /dev/null
@@ -1,19 +0,0 @@
-## <a name="GNU_Web_Meta_Discussion"> </a> GNU Web Meta Discussion
-
-Where did you get that logo? Maybe it's the color but it looks very elegant compared to <http://www.gnu.org>
-
--- [[Main/GrantBow]] - 23 Oct 2002
-
-I did it myself. Somewhat inspired by another GNU artwork, but completely hand made in the Gimp.
-
-I'm working on a cool Mach logo as well. Inspiration is the old Atari arcade game M.A.C.H. 3. :-)
-
--- [[Main/JoachimNilsson]] - 29 Oct 2002
-
-What do you feel about the new copyright notice at the bottom of this web?
-
-I'm afraid that I will have to add another page to the edit process to actually enforce this stuff. Perhaps I can combine the old Preview with this copyright assignment, what do you think?
-
-Oh, btw. It seems RMS is right. At least according to Swedish law (as far as I've checked) transfer/assignment of copyright can be made the way he describes. The user has to select a checkbox or press a button to accept the copyright assignment each time. But as long as that is done we don't have to have any other form of "legal contract" between the users and the FSF.
-
--- [[Main/JoachimNilsson]] - 29 Oct 2002
diff --git a/hurd/running/vmware/discussion.mdwn b/hurd/running/vmware/discussion.mdwn
deleted file mode 100644
index 2db08654..00000000
--- a/hurd/running/vmware/discussion.mdwn
+++ /dev/null
@@ -1,18 +0,0 @@
-[[!meta copyright="Copyright © 2007, 2008 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]]."]]"""]]
-
-I find that this is all quite quick to try and that I can run through the
-./native-install and reboot cycle twice OK.  However, at that point the
-installed Hurd boots up but fails to display a login prompt.  This is the case
-for both K10 and K14 using VMware Workstation 5.0.0 under Windows XP.  Maybe
-I'm doing something wrong but it is hard to see what.  I'd be interested to
-know more precisely what other people find does work.
-
---IanMiller - 01 Apr 2007
diff --git a/microkernel/for_beginners/discussion.mdwn b/microkernel/for_beginners/discussion.mdwn
deleted file mode 100644
index 9831796b..00000000
--- a/microkernel/for_beginners/discussion.mdwn
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled [[GNU Free Documentation
-License|/fdl]]."]]"""]]
-
-Good day.
-
-I am a developer, have some c knowledge, and in perspective hope to be able to make a contribution in Hurd kernel. At the moment I consider myself as a beginner.
-
-My question is about the second exercise.
-
->Implement your own pager. Write a server that synthesizes content on the fly and have a client map the object into its address space and print out the file.
-
-* The second sentence "Write a server that..." is too long and too difficult for me to understand perhaps because English is not my native language. Could you please explain it in a little bit easier phrases?
-* Am I write that in a given context "pager" means just "memory manager"?
diff --git a/microkernel/mach/discussion.mdwn b/microkernel/mach/discussion.mdwn
deleted file mode 100644
index 589e302d..00000000
--- a/microkernel/mach/discussion.mdwn
+++ /dev/null
@@ -1,23 +0,0 @@
-## <a name="Maintenance_of_the_Mach_web"> Maintenance of the Mach web </a>
-
-**_Old discussions:_** [[WIKIHOMEURLMachTOPICrev13]]
-
-Interesting, for consistency sake I'll think about making your changes you made on the right hand side to the other web WebHome pages. I guess it's not critical that they are identical, but I was trying to keep them identical if possible. I also wanted it to be "light" enough feature wise that it doesn't overpower the page. You've added back a few of the features, so we obviously differ in how important you and I think these features are. That's OK, I'll think about it some more and we'll see what happens.
-
-Oh, I see you added back [[WebTopicList]] and [[WebPreferences]]. I purposely removed [[WebPreferences]] from the lists on the right because it has nothing to do with navigation. I also didn't think that people actually use topic names to navigate. If they do they could search for them. Keeping the number to four items instead of six and keeping the descriptions concise makes a big difference when I view the page.
-
-(goes off to think more...)
-
-and eat... ;-)
-
--- [[Main/GrantBow]] - 29 Dec 2002
-
-**_Reasons for my change:_**
-
-1. [[WebTopicList]] is a lot quicker than the [[WebIndex]] - brings down the load times and the load of the server
-2. [[WebPreferences]] - users might be curious to see what can be modified. Changes should of course only be made in their home topics, like in %WIKIUSERNAME%. However, the [[WebPreferences]] can serve as an inspiration. Therefore we should perhaps make sure only the [[Main/TWikiAdminGroup]] members can alter the \*Preferences topics.
-3. If you look closely I've also reordered the links. Shorter names first and long ones last, I tried to keep the descriptions brief and in proportional length as well.
-
-I don't know about you, but keeping the number of items to four rather than six doesn't really matter to me. The text is quite small and if it's the space we're after the [[WebStatistics]] does take up more than the navigation links.
-
--- [[Main/JoachimNilsson]] - 29 Dec 2002
diff --git a/microkernel/mach/external_pager_mechanism.mdwn b/microkernel/mach/external_pager_mechanism.mdwn
index d9b6c2c8..05a6cc56 100644
--- a/microkernel/mach/external_pager_mechanism.mdwn
+++ b/microkernel/mach/external_pager_mechanism.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2002, 2007, 2008, 2010 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2002, 2007, 2008, 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
@@ -181,3 +181,15 @@ fashion.  The server is not required to send a response to the kernel.
 (D) The manager then transfers the data to the storeio server which
 eventually sends it to disk.  The device driver consumes the memory
 doing the equivalent of a `vm_deallocate`.
+
+
+# Issues
+
+  * [[open_issues/performance/io_system/read-ahead]]
+
+  * [[open_issues/performance/io_system/clustered_page_faults]]
+
+
+# GNU Hurd Usage
+
+Read about the [[Hurd's I/O path|hurd/io_path]].
diff --git a/microkernel/mach/gnumach.mdwn b/microkernel/mach/gnumach.mdwn
index f3d6d5f9..b385ca09 100644
--- a/microkernel/mach/gnumach.mdwn
+++ b/microkernel/mach/gnumach.mdwn
@@ -1,13 +1,13 @@
-[[!meta copyright="Copyright © 2001, 2002, 2007, 2008 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2001, 2002, 2007, 2008, 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
 
 GNU Mach is the microkernel that the [[GNU_Hurd|hurd]] system is based on.
 
@@ -75,6 +75,7 @@ GNU/Hurd.
   * [[Building]]
   * [[Debugging]]
   * [[Boot_Trace]]
+  * [[Memory_Management]]
   * [[Projects]]
       * [[Rules]]
       * [[Open Issues|tag/open_issue_gnumach]]
diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn
index 9c075600..99e566bb 100644
--- a/microkernel/mach/gnumach/building.mdwn
+++ b/microkernel/mach/gnumach/building.mdwn
@@ -1,6 +1,3 @@
-Additional to the following text, a further [[example]] has be posted.
-
-
 # Building [[GNU_Mach|gnumach]] from Source
 
 If you want to build the [[GNU_Mach|gnumach]] kernel yourself instead of just using a
diff --git a/microkernel/mach/gnumach/building/example.mdwn b/microkernel/mach/gnumach/building/example.mdwn
deleted file mode 100644
index 7db98547..00000000
--- a/microkernel/mach/gnumach/building/example.mdwn
+++ /dev/null
@@ -1,54 +0,0 @@
-[[!meta copyright="Copyright © 2007, 2008 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]]."]]"""]]
-
-## Compiling GNU Mach microkernel
-
-Host development system is IBM T41 running Debian Sarge 3.1r0a GNU/Linux.
-
-* gcc version: 3.3.5
-* GNU sed version: 4.1.2
-* GNU make version: 3.8
-* mig version: 1.3-4
-
-Obtained gnumach-1-branch sources from cvs:
-
-    export CVS_RSH="ssh"
-    cvs -z3 -d:ext:anoncvs@ savannah.gnu.org:/cvsroot/hurd co -r gnumach-1-branch gnumach
-
-Obtained mig_1.3-4_i386.deb from
-http://www.hadrons.org/~guillem/debian/pool/main/mig/. Installed it using dpkg:
-
-    dpkg -i mig_1.3-4_i386.deb
-
-Entered into the gnumach sources and did the following for compilation:
-
-    mkdir build
-    cd build
-    ../configure --host=i386-unknown-gnu0.2 --build=i586-pc-linux-gnu \
-      --enable-kdb --enable-ide
-    make
-
-The kernel file is created in the build directory.  Move it to /boot on the
-testing x86 system Hurd partition.  Rename it as gnumach1 and compress it:
-
-    mv kernel gnumach1
-    gzip gnumach1
-
-Add a new entry on the testing machine /boot/grub/menu.lst to boot the new
-kernel.
-
-    title GNU Hurd K10 Compiled gnumach
-    kernel (hd0,3)/boot/gnumach1.gz root=device:hd2s4 -s
-    module (hd0,3)/hurd/ext2fs.static--multiboot-command-line=${kernel-command-line} \\
-      --host-priv-port=${host-port} --device-master-port=${device-port} \\
-      --exec-server-task=${exec-task} -T typed ${root} $(task-create)$(task-resume)
-    module (hd0,3)/lib/ld.so.1 /hurd/exec $(exec-task=task-create)
-
-Reboot into the new compiled mygnumach1.gz kernel!
diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn
new file mode 100644
index 00000000..17dbe46f
--- /dev/null
+++ b/microkernel/mach/gnumach/memory_management.mdwn
@@ -0,0 +1,50 @@
+[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+IRC, freenode, #hurd, 2011-02-15
+
+    <braunr> etenil: originally, mach had its own virtual space (the kernel
+      space)
+    <braunr> etenil: in order to use linux 2.0 drivers, it now directly maps
+      physical memory, as linux does
+    <braunr> etenil: but there is nothing similar to kmap() or vmalloc() in
+      mach, so the kernel is limited to its 1 GiB
+    <braunr> (3 GiB userspace / 1 GiB kernelspace)
+    <braunr> that's the short version, there is a vmalloc() in mach, but this
+      trick made it behave almost like a kmalloc()
+    <antrik> braunr: the direct mapping is *only* for the benefit of Linux
+      drivers?...
+    <braunr> also, the configuration of segments limits the kernel space
+    <braunr> antrik: i'm not sure, as i said, this is the short version
+    <braunr> antrik: but there is a paper which describes the integration of
+      those drivers in mach
+    <etenil> you mean the linux 2.0 drivers?
+    <antrik> braunr: I read it once, but I don't remember anything about the
+      physical mapping in there...
+    <antrik> etenil: well, originally it was 1.3, but essentially that's the
+      same...
+    <braunr> i don't see any other reason why there would be a direct mapping
+    <braunr> except for performance (because you can use larger - even very
+      lage - pages without resetting the mmu often thanks to global pages, but
+      that didn't exist at the time)
+
+IRC, freenode, #hurd, 2011-02-15
+
+    <antrik> however, the kernel won't work in 64 bit mode without some changes
+      to physical memory management
+    <braunr> and mmu management
+    <braunr> (but maybe that's what you meant by physical memory)
+
+IRC, freenode, #hurd, 2011-02-16
+
+    <braunr> antrik: youpi added it for xen, yes
+    <braunr> antrik: but you're right, since mach uses a direct mapped kernel
+      space, the true problem is the lack of linux-like highmem support
+    <braunr> which isn't required if the kernel space is really virtual
diff --git a/microkernel/mach/gnumach/projects.mdwn b/microkernel/mach/gnumach/projects.mdwn
index 47a2756c..f4ef192a 100644
--- a/microkernel/mach/gnumach/projects.mdwn
+++ b/microkernel/mach/gnumach/projects.mdwn
@@ -1,13 +1,13 @@
-[[!meta copyright="Copyright © 2005, 2006, 2007, 2008 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
 
 This page is a place to keep track of ideas about things that may be improved
 in GNU Mach, so that it'll evolve to a reliable microkernel for The Hurd, both
@@ -58,7 +58,8 @@ so that no duplicate efforts end up.
 
   * Improve the external pagers interface
 
-      * Implement read-ahead (huge I/O improvements expected).
+      * Implement [[open_issues/performance/io_system/read-ahead]] (huge I/O
+        improvements expected).
 
       * Making this interface synchronous should improve I/O performance
         significantly, without (almost) any drawbacks (we also get some
diff --git a/microkernel/mach/memory_object.mdwn b/microkernel/mach/memory_object.mdwn
index 2342145c..f32fe778 100644
--- a/microkernel/mach/memory_object.mdwn
+++ b/microkernel/mach/memory_object.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2002, 2003, 2010 Free Software Foundation,
+[[!meta copyright="Copyright © 2002, 2003, 2010, 2011 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -29,3 +29,5 @@ last one tried is the *default memory manager* that resides in the microkernel,
 in contrast to most of the others.  The default memory manager is needed
 because the microkernel can't wait infinitely for someone else to free the
 memory cache: it just calls the next memory manager hoping it to succeed.
+
+Read about [[GNU Mach's memory management|gnumach/memory_management]].
diff --git a/open_issues/binutils.mdwn b/open_issues/binutils.mdwn
index 81fafaca..ca7496f0 100644
--- a/open_issues/binutils.mdwn
+++ b/open_issues/binutils.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation,
+[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -9,7 +9,7 @@ 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_binutils]]
+[[!tag stable_URL open_issue_binutils]]
 
 Here's what's to be done for maintaining GNU Binutils.
 
@@ -30,15 +30,14 @@ though, as explained below.
 
 # Configuration
 
-Last reviewed up to the [[Git mirror's e347ef3b343fc42ed312d5125047d59ae15df795
-(2010-12-20) sources|source_repositories/binutils]].
+Last reviewed up to the [[Git mirror's a446ef2f3862fb5f89c669b34a2b6a2ab943ff96
+(2011-02-10) sources|source_repositories/binutils]].
 
   * Globally
 
       * a.out, COFF, PE image support and 64 bit support are not interesting.
 
-      * In the [[testsuite]]s, `.exp` and `.d` files very likely should not
-        only
+      * In the testsuites, `.exp` and `.d` files very likely should not only
         care for `*-*-linux*`, but also `*-*-gnu*`.  (If the need to be
         conditionalized like this at all.)
 
@@ -96,7 +95,7 @@ Last reviewed up to the [[Git mirror's e347ef3b343fc42ed312d5125047d59ae15df795
          * `*-*-gnu*`
 
             TODO: resolve `crt0.o` vs. `crt1.o` issue.  [[Testsuite
-            failures|testsuite#static]].
+            failures|binutils#static]].
 
       * `configure.tgt`
 
@@ -109,7 +108,7 @@ Last reviewed up to the [[Git mirror's e347ef3b343fc42ed312d5125047d59ae15df795
 # Build
 
 Here's a log of a binutils build run; this is from our [[Git
-repository's 245f62b817ee31135a190793dddb340f04ac95e6 (2010-12-20)
+repository's e8052e7548e0d5523f1764b7d3896ca000bfaed7 (2011-02-10)
 sources|source_repositories/binutils]], run on kepler.SCHWINGE and grubber.
 
     $ export LC_ALL=C
@@ -121,7 +120,7 @@ sources|source_repositories/binutils]], run on kepler.SCHWINGE and grubber.
 (kepler.SCHWINGE defaults to using /bin/sh for libtool, grubber to /bin/bash;
 thus harmonized.)
 
-On grubber, this takes roughly one hour.
+On grubber, this needs roughly one hour, and takes up around 100 MiB.
 
 
 ## Analysis
@@ -145,7 +144,7 @@ GNU/Linux defining `-DTRAD_CORE`, `-DHAVE_i386linux_vec`
 (kepler.SCHWINGE defaults to using /bin/sh, grubber to /bin/bash; thus
 harmonized.)
 
-On grubber, this needs roughly 15 minutes, and takes up around 0.7 GiB.
+On grubber, this needs roughly 5 minutes, and takes up around 60 MiB.
 
 
 ## Analysis
@@ -170,12 +169,12 @@ On grubber, this takes roughly one hour.
 Comparing the results files, [[sum_linux]] to [[sum_hurd]]:
 
     $ diff -u -F ^Running open_issues/binutils/sum_linux open_issues/binutils/sum_hurd
-    --- open_issues/binutils/sum_linux      2010-12-20 19:01:06.000000000 +0100
-    +++ open_issues/binutils/sum_hurd       2010-12-20 19:01:20.000000000 +0100
+    --- open_issues/binutils/sum_linux      2011-02-10 19:01:56.000000000 +0100
+    +++ open_issues/binutils/sum_hurd       2011-02-10 20:27:17.000000000 +0100
     @@ -1,5 +1,5 @@
-    -Test Run By thomas on Mon Dec 20 11:34:53 2010
+    -Test Run By thomas on Thu Feb 10 18:57:42 2011
     -Native configuration is i686-pc-linux-gnu
-    +Test Run By tschwinge on Mon Dec 20 11:35:47 2010
+    +Test Run By tschwinge on Thu Feb 10 18:58:16 2011
     +Native configuration is i686-unknown-gnu0.3
      
                     === binutils tests ===
@@ -184,9 +183,9 @@ Comparing the results files, [[sum_linux]] to [[sum_hurd]]:
      
      # of expected passes           83
      # of unsupported tests         2
-    -Test Run By thomas on Mon Dec 20 11:35:19 2010
+    -Test Run By thomas on Thu Feb 10 18:58:10 2011
     -Native configuration is i686-pc-linux-gnu
-    +Test Run By tschwinge on Mon Dec 20 11:44:29 2010
+    +Test Run By tschwinge on Thu Feb 10 19:06:15 2011
     +Native configuration is i686-unknown-gnu0.3
      
                     === ld tests ===
@@ -232,21 +231,21 @@ Comparing the results files, [[sum_linux]] to [[sum_hurd]]:
      PASS: ELF DSO small bar (size)
      PASS: ELF DSO foo with small bar (size)
      PASS: ELF DSO big bar (size)
-    @@ -873,13 +873,14 @@ Running [...]/hurd/master/ld/testsuite/l
+    @@ -882,13 +882,14 @@ Running [...]/hurd/master/ld/testsuite/l
      
                     === ld Summary ===
      
-    -# of expected passes           618
+    -# of expected passes           626
     -# of expected failures         8
-    +# of expected passes           608
+    +# of expected passes           616
     +# of unexpected successes      1
     +# of expected failures         17
      # of untested testcases                6
-     /media/data[...]/hurd/master.build/ld/ld-new 2.21.51.20101220
+     /media/data[...]/hurd/master.build/ld/ld-new 2.21.51.20110210
      
-    -Test Run By thomas on Mon Dec 20 11:34:59 2010
+    -Test Run By thomas on Thu Feb 10 18:57:49 2011
     -Native configuration is i686-pc-linux-gnu
-    +Test Run By tschwinge on Mon Dec 20 11:38:03 2010
+    +Test Run By tschwinge on Thu Feb 10 19:00:16 2011
     +Native configuration is i686-unknown-gnu0.3
      
                     === gas tests ===
@@ -255,7 +254,7 @@ Comparing the results files, [[sum_linux]] to [[sum_hurd]]:
 
 ## Analysis
 
-  * <a name="static">`FAIL: static [...]`</a>
+  * <a name="static"><!-- stable_URL -->`FAIL: static [...]`</a>
 
     The testsuite isn't prepared for using `crt0.o` instead of `crt1.o`
     depending on whether a static or dynamic executable is created.  Documented
@@ -269,7 +268,7 @@ Comparing the results files, [[sum_linux]] to [[sum_hurd]]:
     weakness|performance/io_system/binutils_ld_64ksec]]), so assuming some
     system load variation, the testsuite's timeout may trigger.
 
-  * <a name="weak">`FAIL: ELF weak [...]`</a>
+  * <a name="weak"><!-- stable_URL -->`FAIL: ELF weak [...]`</a>
 
     [[I|tschwinge]] suppose this is due to us having an override w.r.t. weak
     symbol handling in glibc, needed for our external [[/libpthread]].  TODO:
diff --git a/open_issues/binutils/log_build-diff b/open_issues/binutils/log_build-diff
index 802d510c..3408d97d 100644
--- a/open_issues/binutils/log_build-diff
+++ b/open_issues/binutils/log_build-diff
@@ -1,5 +1,5 @@
---- /dev/fd/63	2010-12-20 11:34:03.204493002 +0100
-+++ /dev/fd/62	2010-12-20 11:34:03.208493002 +0100
+--- /dev/fd/63	2011-02-10 17:33:04.738225001 +0100
++++ /dev/fd/62	2011-02-10 17:33:04.738225001 +0100
 @@ -1,6 +1,6 @@
 -checking build system type... i686-pc-linux-gnu
 -checking host system type... i686-pc-linux-gnu
@@ -530,7 +530,7 @@
  checking whether we are using the GNU C compiler... (cached) yes
  checking whether gcc accepts -g... (cached) yes
  checking for gcc option to accept ISO C89... (cached) none needed
-@@ -2450,28 +2429,28 @@
+@@ -2453,28 +2432,28 @@
  checking for BSD- or MS-compatible name lister (nm)... nm
  checking the name lister (nm) interface... BSD nm
  checking whether ln -s works... yes
@@ -566,23 +566,37 @@
  checking how to hardcode library paths into programs... immediate
  checking whether stripping libraries is possible... yes
  checking if libtool supports shared libraries... yes
-@@ -2555,13 +2534,13 @@
+@@ -2486,11 +2465,11 @@
+ checking whether the g++ linker (ld) supports shared libraries... yes
+ checking for g++ option to produce PIC... -fPIC -DPIC
+ checking if g++ PIC flag -fPIC -DPIC works... yes
+-checking if g++ static flag -static works... yes
++checking if g++ static flag -static works... no
+ checking if g++ supports -c -o file.o... yes
+ checking if g++ supports -c -o file.o... (cached) yes
+ checking whether the g++ linker (ld) supports shared libraries... yes
+-checking dynamic linker characteristics... (cached) GNU/Linux ld.so
++checking dynamic linker characteristics... gnu0.3 ld.so
+ checking how to hardcode library paths into programs... immediate
+ checking whether NLS is requested... yes
+ checking for catalogs to be installed...  bg da es fi fr ga id ja sv tr vi zh_CN zh_TW
+@@ -2570,13 +2549,13 @@
  /bin/bash ../../master/ld/../ylwrap ../../master/ld/ldgram.y y.tab.c ldgram.c y.tab.h ldgram.h y.output ldgram.output -- bison -y -d 
  updating ldgram.h
  (echo "/* This file is automatically generated.  DO NOT EDIT! */";\
--	for f in `echo " " eelf_i386.o ei386linux.o "" \
+-	for f in `echo " " eelf_i386.o ei386linux.o eelf32_x86_64.o "" \
 +	for f in `echo " " eelf_i386.o "" \
  	 | sed -e 's/ e/ ld/g' -e 's/ ld/ /g' -e 's/[.]o//g'`; do \
  	    echo "extern ld_emulation_xfer_type ld_${f}_emulation;"; \
  	done;\
  	echo "";\
  	echo "#define EMULATION_LIST \\";\
--	for f in `echo " " eelf_i386.o ei386linux.o "" \
+-	for f in `echo " " eelf_i386.o ei386linux.o eelf32_x86_64.o "" \
 +	for f in `echo " " eelf_i386.o "" \
  	 | sed -e 's/ e/ ld/g' -e 's/ ld/ /g' -e 's/[.]o//g'`; do \
  	    echo "  &ld_${f}_emulation, \\"; \
  	done;\
-@@ -2650,8 +2629,8 @@
+@@ -2665,8 +2644,8 @@
  mv -f .deps/ldctor.Tpo .deps/ldctor.Po
  gcc -DHAVE_CONFIG_H -I. -I../../master/ld  -I. -I../../master/ld -I../bfd -I../../master/ld/../bfd -I../../master/ld/../include  -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"[...]/hurd/master.build.install/share/locale\""  -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT ldmain.o -MD -MP -MF .deps/ldmain.Tpo -c -o ldmain.o \
  	  -DDEFAULT_EMULATION='"elf_i386"' \
@@ -593,7 +607,7 @@
  	  ../../master/ld/ldmain.c
  mv -f .deps/ldmain.Tpo .deps/ldmain.Po
  gcc -DHAVE_CONFIG_H -I. -I../../master/ld  -I. -I../../master/ld -I../bfd -I../../master/ld/../bfd -I../../master/ld/../include  -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"[...]/hurd/master.build.install/share/locale\""  -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT ldwrite.o -MD -MP -MF .deps/ldwrite.Tpo -c -o ldwrite.o ../../master/ld/ldwrite.c
-@@ -2665,7 +2644,7 @@
+@@ -2680,7 +2659,7 @@
  gcc -DHAVE_CONFIG_H -I. -I../../master/ld  -I. -I../../master/ld -I../bfd -I../../master/ld/../bfd -I../../master/ld/../include  -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"[...]/hurd/master.build.install/share/locale\""  -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT ldmisc.o -MD -MP -MF .deps/ldmisc.Tpo -c -o ldmisc.o ../../master/ld/ldmisc.c
  mv -f .deps/ldmisc.Tpo .deps/ldmisc.Po
  gcc -DHAVE_CONFIG_H -I. -I../../master/ld  -I. -I../../master/ld -I../bfd -I../../master/ld/../bfd -I../../master/ld/../include  -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"[...]/hurd/master.build.install/share/locale\""  -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT ldfile.o -MD -MP -MF .deps/ldfile.Tpo -c -o ldfile.o \
@@ -602,19 +616,22 @@
  	 ../../master/ld/ldfile.c
  mv -f .deps/ldfile.Tpo .deps/ldfile.Po
  gcc -DHAVE_CONFIG_H -I. -I../../master/ld  -I. -I../../master/ld -I../bfd -I../../master/ld/../bfd -I../../master/ld/../include  -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"[...]/hurd/master.build.install/share/locale\""  -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT ldcref.o -MD -MP -MF .deps/ldcref.Tpo -c -o ldcref.o ../../master/ld/ldcref.c
-@@ -2673,14 +2652,11 @@
+@@ -2688,17 +2667,11 @@
  gcc -DHAVE_CONFIG_H -I. -I../../master/ld  -I. -I../../master/ld -I../bfd -I../../master/ld/../bfd -I../../master/ld/../include  -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"[...]/hurd/master.build.install/share/locale\""  -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT plugin.o -MD -MP -MF .deps/plugin.Tpo -c -o plugin.o ../../master/ld/plugin.c
  mv -f .deps/plugin.Tpo .deps/plugin.Po
  cp ../../master/ld/emultempl/astring.sed stringify.sed
--LIB_PATH='' /bin/bash ../../master/ld/genscripts.sh "../../master/ld" "[...]/hurd/master.build.install/lib" "[...]/hurd/master.build.install" "[...]/hurd/master.build.install" i686-pc-linux-gnu i686-pc-linux-gnu i686-pc-linux-gnu "elf_i386" "/usr/local/lib /lib /usr/lib" no yes elf_i386 "i686-pc-linux-gnu"
+-LIB_PATH='' /bin/bash ../../master/ld/genscripts.sh "../../master/ld" "[...]/hurd/master.build.install/lib" "[...]/hurd/master.build.install" "[...]/hurd/master.build.install" i686-pc-linux-gnu i686-pc-linux-gnu i686-pc-linux-gnu "elf_i386 elf32_x86_64" "/usr/local/lib /lib /usr/lib" no yes elf_i386 "i686-pc-linux-gnu"
 +LIB_PATH='' /bin/bash ../../master/ld/genscripts.sh "../../master/ld" "[...]/hurd/master.build.install/lib" "[...]/hurd/master.build.install" "[...]/hurd/master.build.install" i686-unknown-gnu0.3 i686-unknown-gnu0.3 i686-unknown-gnu0.3 "elf_i386" "/usr/local/lib /lib /usr/lib" no yes elf_i386 "i686-unknown-gnu0.3"
  gcc -DHAVE_CONFIG_H -I. -I../../master/ld  -I. -I../../master/ld -I../bfd -I../../master/ld/../bfd -I../../master/ld/../include  -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"[...]/hurd/master.build.install/share/locale\""  -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT eelf_i386.o -MD -MP -MF .deps/eelf_i386.Tpo -c -o eelf_i386.o eelf_i386.c
  mv -f .deps/eelf_i386.Tpo .deps/eelf_i386.Po
--LIB_PATH='' /bin/bash ../../master/ld/genscripts.sh "../../master/ld" "[...]/hurd/master.build.install/lib" "[...]/hurd/master.build.install" "[...]/hurd/master.build.install" i686-pc-linux-gnu i686-pc-linux-gnu i686-pc-linux-gnu "elf_i386" "/usr/local/lib /lib /usr/lib" no yes i386linux "i686-pc-linux-gnuaout"
+-LIB_PATH='' /bin/bash ../../master/ld/genscripts.sh "../../master/ld" "[...]/hurd/master.build.install/lib" "[...]/hurd/master.build.install" "[...]/hurd/master.build.install" i686-pc-linux-gnu i686-pc-linux-gnu i686-pc-linux-gnu "elf_i386 elf32_x86_64" "/usr/local/lib /lib /usr/lib" no yes i386linux "i686-pc-linux-gnuaout"
 -gcc -DHAVE_CONFIG_H -I. -I../../master/ld  -I. -I../../master/ld -I../bfd -I../../master/ld/../bfd -I../../master/ld/../include  -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"[...]/hurd/master.build.install/share/locale\""  -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT ei386linux.o -MD -MP -MF .deps/ei386linux.Tpo -c -o ei386linux.o ei386linux.c
 -mv -f .deps/ei386linux.Tpo .deps/ei386linux.Po
--/bin/bash ./libtool --tag=CC   --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2   -o ld-new ldgram.o ldlex-wrapper.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o ldwrite.o ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o plugin.o eelf_i386.o ei386linux.o  ../bfd/libbfd.la ../libiberty/libiberty.a  -lz -ldl 
--libtool: link: gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -o ld-new ldgram.o ldlex-wrapper.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o ldwrite.o ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o plugin.o eelf_i386.o ei386linux.o  ../bfd/.libs/libbfd.a ../libiberty/libiberty.a -lz -ldl
+-LIB_PATH='' /bin/bash ../../master/ld/genscripts.sh "../../master/ld" "[...]/hurd/master.build.install/lib" "[...]/hurd/master.build.install" "[...]/hurd/master.build.install" i686-pc-linux-gnu i686-pc-linux-gnu i686-pc-linux-gnu "elf_i386 elf32_x86_64" "/usr/local/lib /lib /usr/lib" no yes elf32_x86_64 "i686-pc-linux-gnu"
+-gcc -DHAVE_CONFIG_H -I. -I../../master/ld  -I. -I../../master/ld -I../bfd -I../../master/ld/../bfd -I../../master/ld/../include  -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"[...]/hurd/master.build.install/share/locale\""  -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT eelf32_x86_64.o -MD -MP -MF .deps/eelf32_x86_64.Tpo -c -o eelf32_x86_64.o eelf32_x86_64.c
+-mv -f .deps/eelf32_x86_64.Tpo .deps/eelf32_x86_64.Po
+-/bin/bash ./libtool --tag=CC   --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2   -o ld-new ldgram.o ldlex-wrapper.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o ldwrite.o ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o plugin.o eelf_i386.o ei386linux.o eelf32_x86_64.o  ../bfd/libbfd.la ../libiberty/libiberty.a  -lz -ldl 
+-libtool: link: gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -o ld-new ldgram.o ldlex-wrapper.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o ldwrite.o ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o plugin.o eelf_i386.o ei386linux.o eelf32_x86_64.o  ../bfd/.libs/libbfd.a ../libiberty/libiberty.a -lz -ldl
 +/bin/bash ./libtool --tag=CC   --mode=link gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2   -o ld-new ldgram.o ldlex-wrapper.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o ldwrite.o ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o plugin.o eelf_i386.o  ../bfd/libbfd.la ../libiberty/libiberty.a  -lz -ldl 
 +libtool: link: gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -o ld-new ldgram.o ldlex-wrapper.o lexsup.o ldlang.o mri.o ldctor.o ldmain.o ldwrite.o ldexp.o ldemul.o ldver.o ldmisc.o ldfile.o ldcref.o plugin.o eelf_i386.o  ../bfd/.libs/libbfd.a ../libiberty/libiberty.a -lz -ldl
  touch ld.1
diff --git a/open_issues/binutils/log_install-diff b/open_issues/binutils/log_install-diff
index 83c8d7b6..00496f8b 100644
--- a/open_issues/binutils/log_install-diff
+++ b/open_issues/binutils/log_install-diff
@@ -1,5 +1,5 @@
---- /dev/fd/63	2010-12-20 19:00:16.368493004 +0100
-+++ /dev/fd/62	2010-12-20 19:00:16.368493004 +0100
+--- /dev/fd/63	2011-02-10 18:56:20.086225001 +0100
++++ /dev/fd/62	2011-02-10 18:56:20.086225001 +0100
 @@ -68,7 +68,6 @@
  libtool: install: /usr/bin/install -c .libs/libbfd.a [...]/hurd/master.build.install/lib/libbfd.a
  libtool: install: chmod 644 [...]/hurd/master.build.install/lib/libbfd.a
diff --git a/open_issues/binutils/sum_hurd b/open_issues/binutils/sum_hurd
index 96dd0cb2..15d225f9 100644
--- a/open_issues/binutils/sum_hurd
+++ b/open_issues/binutils/sum_hurd
@@ -1,4 +1,4 @@
-Test Run By tschwinge on Mon Dec 20 11:35:47 2010
+Test Run By tschwinge on Thu Feb 10 18:58:16 2011
 Native configuration is i686-unknown-gnu0.3
 
 		=== binutils tests ===
@@ -114,7 +114,7 @@ Running [...]/hurd/master/binutils/testsuite/binutils-all/x86-64/x86-64.exp ...
 
 # of expected passes		83
 # of unsupported tests		2
-Test Run By tschwinge on Mon Dec 20 11:44:29 2010
+Test Run By tschwinge on Thu Feb 10 19:06:15 2011
 Native configuration is i686-unknown-gnu0.3
 
 		=== ld tests ===
@@ -640,6 +640,8 @@ PASS: ld-ifunc/ifunc-1-local-x86
 PASS: ld-ifunc/ifunc-1-x86
 PASS: ld-ifunc/ifunc-10-i386
 PASS: ld-ifunc/ifunc-11-i386
+PASS: ld-ifunc/ifunc-12-i386
+PASS: ld-ifunc/ifunc-13-i386
 PASS: ld-ifunc/ifunc-2-i386
 PASS: ld-ifunc/ifunc-2-local-i386
 PASS: ld-ifunc/ifunc-3a-x86
@@ -669,6 +671,8 @@ Running [...]/hurd/master/ld/testsuite/ld-m68k/m68k.exp ...
 Running [...]/hurd/master/ld/testsuite/ld-mep/mep.exp ...
 Running [...]/hurd/master/ld/testsuite/ld-mips-elf/mips-elf-flags.exp ...
 Running [...]/hurd/master/ld/testsuite/ld-mips-elf/mips-elf.exp ...
+Running [...]/hurd/master/ld/testsuite/ld-misc/defsym.exp ...
+PASS: ld-misc/defsym1
 Running [...]/hurd/master/ld/testsuite/ld-mmix/mmix.exp ...
 Running [...]/hurd/master/ld/testsuite/ld-mn10300/mn10300.exp ...
 Running [...]/hurd/master/ld/testsuite/ld-pe/pe-compile.exp ...
@@ -705,6 +709,7 @@ Running [...]/hurd/master/ld/testsuite/ld-scripts/alignof.exp ...
 PASS: ALIGNOF
 Running [...]/hurd/master/ld/testsuite/ld-scripts/assert.exp ...
 PASS: ASSERT
+PASS: ld-scripts/assert2
 Running [...]/hurd/master/ld/testsuite/ld-scripts/crossref.exp ...
 PASS: NOCROSSREFS 1
 PASS: NOCROSSREFS 2
@@ -720,6 +725,8 @@ Running [...]/hurd/master/ld/testsuite/ld-scripts/defined.exp ...
 PASS: DEFINED (PRMS 5699)
 PASS: ld-scripts/defined2
 PASS: ld-scripts/defined3
+PASS: ld-scripts/defined4
+PASS: ld-scripts/defined5
 Running [...]/hurd/master/ld/testsuite/ld-scripts/dynamic-sections.exp ...
 PASS: dynamic sections
 Running [...]/hurd/master/ld/testsuite/ld-scripts/empty-address.exp ...
@@ -735,6 +742,8 @@ Running [...]/hurd/master/ld/testsuite/ld-scripts/empty-orphan.exp ...
 PASS: ld-scripts/empty-orphan
 Running [...]/hurd/master/ld/testsuite/ld-scripts/expr.exp ...
 PASS: ld-scripts/expr1
+PASS: ld-scripts/expr2
+PASS: ld-scripts/sane1
 Running [...]/hurd/master/ld/testsuite/ld-scripts/extern.exp ...
 PASS: EXTERN
 Running [...]/hurd/master/ld/testsuite/ld-scripts/include.exp ...
@@ -873,13 +882,13 @@ Running [...]/hurd/master/ld/testsuite/ld-xtensa/xtensa.exp ...
 
 		=== ld Summary ===
 
-# of expected passes		608
+# of expected passes		616
 # of unexpected successes	1
 # of expected failures		17
 # of untested testcases		6
-/media/data[...]/hurd/master.build/ld/ld-new 2.21.51.20101220
+/media/data[...]/hurd/master.build/ld/ld-new 2.21.51.20110210
 
-Test Run By tschwinge on Mon Dec 20 11:38:03 2010
+Test Run By tschwinge on Thu Feb 10 19:00:16 2011
 Native configuration is i686-unknown-gnu0.3
 
 		=== gas tests ===
@@ -961,8 +970,8 @@ PASS: CFI common 2
 PASS: CFI common 3
 PASS: CFI common 4
 PASS: CFI common 5
-PASS: CFI common 7
 PASS: CFI common 6
+PASS: CFI common 7
 Running [...]/hurd/master/gas/testsuite/gas/cr16/cr16.exp ...
 Running [...]/hurd/master/gas/testsuite/gas/cr16/pic.exp ...
 Running [...]/hurd/master/gas/testsuite/gas/cris/cris.exp ...
@@ -1001,6 +1010,7 @@ PASS: section flags
 PASS: DWARF2 1
 PASS: DWARF2 2
 PASS: DWARF2 3
+PASS: DWARF2 4
 PASS: Check bad section flag
 Running [...]/hurd/master/gas/testsuite/gas/fr30/allinsn.exp ...
 Running [...]/hurd/master/gas/testsuite/gas/fr30/fr30.exp ...
@@ -1094,8 +1104,10 @@ PASS: i386 -mtune=i686 nops 3
 PASS: i386 nops 4
 PASS: i386 nops -mtune=i386 4
 PASS: i386 -mtune=i686 nops 4
+PASS: i386 -march=i686+nop nops 4a
 PASS: i386 nops 5
 PASS: i386 -march=i686 nops 5
+PASS: i386 nops 6
 PASS: i386 16-bit addressing in 32-bit mode.
 PASS: i386 32-bit addressing in 16-bit mode.
 PASS: i386 SSE4.1
@@ -1176,6 +1188,10 @@ PASS: i386 FMA scalar insns (Intel disassembly)
 PASS: i386 FMA4
 PASS: i386 LWP
 PASS: i386 XOP
+PASS: i386 BMI insns
+PASS: i386 BMI insns (Intel disassembly)
+PASS: i386 TBM
+PASS: i386 TBM insns (Intel disassembly)
 PASS: i386 F16C
 PASS: i386 F16C (Intel disassembly)
 PASS: i386 FSGSBase
@@ -1217,6 +1233,10 @@ PASS: i386 list-1
 PASS: i386 list-2
 PASS: i386 list-3
 PASS: DWARF2 debugging information 1
+Running [...]/hurd/master/gas/testsuite/gas/i386/ilp32/cfi/ilp32.exp ...
+Running [...]/hurd/master/gas/testsuite/gas/i386/ilp32/elf/ilp32.exp ...
+Running [...]/hurd/master/gas/testsuite/gas/i386/ilp32/ilp32.exp ...
+Running [...]/hurd/master/gas/testsuite/gas/i386/ilp32/lns/ilp32.exp ...
 Running [...]/hurd/master/gas/testsuite/gas/i860/i860.exp ...
 Running [...]/hurd/master/gas/testsuite/gas/ia64/ia64.exp ...
 Running [...]/hurd/master/gas/testsuite/gas/ieee-fp/x930509a.exp ...
@@ -1317,6 +1337,6 @@ Running [...]/hurd/master/gas/testsuite/gas/z8k/z8k.exp ...
 
 		=== gas Summary ===
 
-# of expected passes		319
-../as-new 2.21.51.20101220
+# of expected passes		326
+../as-new 2.21.51.20110210
 
diff --git a/open_issues/binutils/sum_linux b/open_issues/binutils/sum_linux
index c2dae925..49cf53fb 100644
--- a/open_issues/binutils/sum_linux
+++ b/open_issues/binutils/sum_linux
@@ -1,4 +1,4 @@
-Test Run By thomas on Mon Dec 20 11:34:53 2010
+Test Run By thomas on Thu Feb 10 18:57:42 2011
 Native configuration is i686-pc-linux-gnu
 
 		=== binutils tests ===
@@ -114,7 +114,7 @@ Running [...]/hurd/master/binutils/testsuite/binutils-all/x86-64/x86-64.exp ...
 
 # of expected passes		83
 # of unsupported tests		2
-Test Run By thomas on Mon Dec 20 11:35:19 2010
+Test Run By thomas on Thu Feb 10 18:58:10 2011
 Native configuration is i686-pc-linux-gnu
 
 		=== ld tests ===
@@ -640,6 +640,8 @@ PASS: ld-ifunc/ifunc-1-local-x86
 PASS: ld-ifunc/ifunc-1-x86
 PASS: ld-ifunc/ifunc-10-i386
 PASS: ld-ifunc/ifunc-11-i386
+PASS: ld-ifunc/ifunc-12-i386
+PASS: ld-ifunc/ifunc-13-i386
 PASS: ld-ifunc/ifunc-2-i386
 PASS: ld-ifunc/ifunc-2-local-i386
 PASS: ld-ifunc/ifunc-3a-x86
@@ -669,6 +671,8 @@ Running [...]/hurd/master/ld/testsuite/ld-m68k/m68k.exp ...
 Running [...]/hurd/master/ld/testsuite/ld-mep/mep.exp ...
 Running [...]/hurd/master/ld/testsuite/ld-mips-elf/mips-elf-flags.exp ...
 Running [...]/hurd/master/ld/testsuite/ld-mips-elf/mips-elf.exp ...
+Running [...]/hurd/master/ld/testsuite/ld-misc/defsym.exp ...
+PASS: ld-misc/defsym1
 Running [...]/hurd/master/ld/testsuite/ld-mmix/mmix.exp ...
 Running [...]/hurd/master/ld/testsuite/ld-mn10300/mn10300.exp ...
 Running [...]/hurd/master/ld/testsuite/ld-pe/pe-compile.exp ...
@@ -705,6 +709,7 @@ Running [...]/hurd/master/ld/testsuite/ld-scripts/alignof.exp ...
 PASS: ALIGNOF
 Running [...]/hurd/master/ld/testsuite/ld-scripts/assert.exp ...
 PASS: ASSERT
+PASS: ld-scripts/assert2
 Running [...]/hurd/master/ld/testsuite/ld-scripts/crossref.exp ...
 PASS: NOCROSSREFS 1
 PASS: NOCROSSREFS 2
@@ -720,6 +725,8 @@ Running [...]/hurd/master/ld/testsuite/ld-scripts/defined.exp ...
 PASS: DEFINED (PRMS 5699)
 PASS: ld-scripts/defined2
 PASS: ld-scripts/defined3
+PASS: ld-scripts/defined4
+PASS: ld-scripts/defined5
 Running [...]/hurd/master/ld/testsuite/ld-scripts/dynamic-sections.exp ...
 PASS: dynamic sections
 Running [...]/hurd/master/ld/testsuite/ld-scripts/empty-address.exp ...
@@ -735,6 +742,8 @@ Running [...]/hurd/master/ld/testsuite/ld-scripts/empty-orphan.exp ...
 PASS: ld-scripts/empty-orphan
 Running [...]/hurd/master/ld/testsuite/ld-scripts/expr.exp ...
 PASS: ld-scripts/expr1
+PASS: ld-scripts/expr2
+PASS: ld-scripts/sane1
 Running [...]/hurd/master/ld/testsuite/ld-scripts/extern.exp ...
 PASS: EXTERN
 Running [...]/hurd/master/ld/testsuite/ld-scripts/include.exp ...
@@ -873,12 +882,12 @@ Running [...]/hurd/master/ld/testsuite/ld-xtensa/xtensa.exp ...
 
 		=== ld Summary ===
 
-# of expected passes		618
+# of expected passes		626
 # of expected failures		8
 # of untested testcases		6
-/media/data[...]/hurd/master.build/ld/ld-new 2.21.51.20101220
+/media/data[...]/hurd/master.build/ld/ld-new 2.21.51.20110210
 
-Test Run By thomas on Mon Dec 20 11:34:59 2010
+Test Run By thomas on Thu Feb 10 18:57:49 2011
 Native configuration is i686-pc-linux-gnu
 
 		=== gas tests ===
@@ -960,8 +969,8 @@ PASS: CFI common 2
 PASS: CFI common 3
 PASS: CFI common 4
 PASS: CFI common 5
-PASS: CFI common 7
 PASS: CFI common 6
+PASS: CFI common 7
 Running [...]/hurd/master/gas/testsuite/gas/cr16/cr16.exp ...
 Running [...]/hurd/master/gas/testsuite/gas/cr16/pic.exp ...
 Running [...]/hurd/master/gas/testsuite/gas/cris/cris.exp ...
@@ -1000,6 +1009,7 @@ PASS: section flags
 PASS: DWARF2 1
 PASS: DWARF2 2
 PASS: DWARF2 3
+PASS: DWARF2 4
 PASS: Check bad section flag
 Running [...]/hurd/master/gas/testsuite/gas/fr30/allinsn.exp ...
 Running [...]/hurd/master/gas/testsuite/gas/fr30/fr30.exp ...
@@ -1093,8 +1103,10 @@ PASS: i386 -mtune=i686 nops 3
 PASS: i386 nops 4
 PASS: i386 nops -mtune=i386 4
 PASS: i386 -mtune=i686 nops 4
+PASS: i386 -march=i686+nop nops 4a
 PASS: i386 nops 5
 PASS: i386 -march=i686 nops 5
+PASS: i386 nops 6
 PASS: i386 16-bit addressing in 32-bit mode.
 PASS: i386 32-bit addressing in 16-bit mode.
 PASS: i386 SSE4.1
@@ -1175,6 +1187,10 @@ PASS: i386 FMA scalar insns (Intel disassembly)
 PASS: i386 FMA4
 PASS: i386 LWP
 PASS: i386 XOP
+PASS: i386 BMI insns
+PASS: i386 BMI insns (Intel disassembly)
+PASS: i386 TBM
+PASS: i386 TBM insns (Intel disassembly)
 PASS: i386 F16C
 PASS: i386 F16C (Intel disassembly)
 PASS: i386 FSGSBase
@@ -1216,6 +1232,10 @@ PASS: i386 list-1
 PASS: i386 list-2
 PASS: i386 list-3
 PASS: DWARF2 debugging information 1
+Running [...]/hurd/master/gas/testsuite/gas/i386/ilp32/cfi/ilp32.exp ...
+Running [...]/hurd/master/gas/testsuite/gas/i386/ilp32/elf/ilp32.exp ...
+Running [...]/hurd/master/gas/testsuite/gas/i386/ilp32/ilp32.exp ...
+Running [...]/hurd/master/gas/testsuite/gas/i386/ilp32/lns/ilp32.exp ...
 Running [...]/hurd/master/gas/testsuite/gas/i860/i860.exp ...
 Running [...]/hurd/master/gas/testsuite/gas/ia64/ia64.exp ...
 Running [...]/hurd/master/gas/testsuite/gas/ieee-fp/x930509a.exp ...
@@ -1316,6 +1336,6 @@ Running [...]/hurd/master/gas/testsuite/gas/z8k/z8k.exp ...
 
 		=== gas Summary ===
 
-# of expected passes		319
-../as-new 2.21.51.20101220
+# of expected passes		326
+../as-new 2.21.51.20110210
 
diff --git a/open_issues/gnumach_console_timestamp.mdwn b/open_issues/gnumach_console_timestamp.mdwn
new file mode 100644
index 00000000..b36b47b9
--- /dev/null
+++ b/open_issues/gnumach_console_timestamp.mdwn
@@ -0,0 +1,27 @@
+[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_gnumach]]
+
+IRC, freenode, #hurd, 2011-02-17
+
+    <azeem> task 39011c10 deallocating an invalid port 349, most probably a
+      bug.
+    <azeem> kernel: Page fault (14), code=6
+    <azeem> Stopped at  0x28b9c7:   orb     %bh,0(%ecx,%edi,2)
+    <azeem> db> 
+    [...]
+    <antrik> tschwinge: I doubt the deallocating warning is related to the
+      later fault
+    <tschwinge> antrik: YOu may be right.
+    <tschwinge> Perhaps it'd be a good idea to add some sort of timestamp to
+      Mach messages.
+    <tschwinge> Like in Linux' dmesg.
+    <tschwinge> Or just RDTSC (internal processor counter).
diff --git a/open_issues/implementing_hurd_on_top_of_another_system.mdwn b/open_issues/implementing_hurd_on_top_of_another_system.mdwn
index 23512aa9..95b71ebb 100644
--- a/open_issues/implementing_hurd_on_top_of_another_system.mdwn
+++ b/open_issues/implementing_hurd_on_top_of_another_system.mdwn
@@ -78,3 +78,40 @@ IRC, #hurd, 2010-12-28
     <antrik> though I must say that I'm more and more convinced running the
       Hurd on top of a monolithic kernel would actually be a useful approach
       for the time being...
+
+---
+
+IRC, #hurd, 2011-02-11
+
+    <neal> marcus and I were discussing how to add Mach to Linux
+    <neal> one could write a module to implement Mach IPC
+    <neal> and another to implement Mach VM
+    <neal> the big thing missing with Mach VM is the ability for a tracing
+      process to easily map or unmap an inferior process's memory
+    <antrik> neal: why would a tracing process need to map the inferior's
+      memory?
+    <neal> the simple answer is that is how it is done on Mach
+    <antrik> neal: is it? not sure we are talking about the same thing
+      here. GDB uses vm_read()/vm_write() to access the inferior's memory AFAIK
+    <neal> on linux?
+    <neal> I think it use /proc/pid/mem
+    <antrik> on Hurd
+    <neal> I'm talking about adding Mach to Linux
+    <neal> by adding some functionality to Linux
+    <neal> and then implementing a bunch in user space
+    <antrik> yeah, but I don't understand the point about mapping inferior's
+      memory :-(
+    <antrik> what would be in user space?
+    <neal> there are a number of different cut points
+    <neal> one could imagine just using Linux's device drivers, CPU scheduler,
+      memory management, etc.
+    <neal> another possibility would be something higher where Hurd processes
+      just use some Hurdish servers
+    <antrik> neal: yeah, these are all options I have been considering... too
+      bad I wasn't able to come to FOSDEM -- I'd love to have participated in
+      this discussion :-(
+    <antrik> neal: BTW, were you just discussing this as a hypothetical idea,
+      or something you are seriously considering?
+    <neal> I'm unlikely to work on it, sorry
+    <antrik> didn't really expect that :-)
+    <antrik> would be nice though if you could write up your conclusions...
diff --git a/open_issues/performance/io_system.mdwn b/open_issues/performance/io_system.mdwn
index 0d41d3c7..4af093ba 100644
--- a/open_issues/performance/io_system.mdwn
+++ b/open_issues/performance/io_system.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation,
+[[!meta copyright="Copyright © 2008, 2009, 2010, 2011 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]]."]]"""]]
 
 [[!meta title="I/O System"]]
 
@@ -20,7 +20,8 @@ slow hard disk access.
 The reason for this slowness is lack and/or bad implementation of common
 optimization techniques, like scheduling reads and writes to minimize head
 movement; effective block caching; effective reads/writes to partial blocks;
-reading/writing multiple blocks at once; and read-ahead.  The
+[[reading/writing multiple blocks at once|clustered_page_faults]]; and
+[[read-ahead]].  The
 [[ext2_filesystem_server|hurd/translator/ext2fs]] might also need some
 optimizations at a higher logical level.
 
@@ -30,7 +31,7 @@ requires understanding the data flow through the various layers involved in
 disk access on the Hurd ([[filesystem|hurd/virtual_file_system]],
 [[pager|hurd/libpager]], driver), and general experience with
 optimizing complex systems.  That said, the killing feature we are definitely
-missing is the read-ahead, and even a very simple implementation would bring
+missing is the [[read-ahead]], and even a very simple implementation would bring
 very big performance speedups.
 
 Here are some real testcases:
diff --git a/open_issues/performance/io_system/clustered_page_faults.mdwn b/open_issues/performance/io_system/clustered_page_faults.mdwn
new file mode 100644
index 00000000..3a187523
--- /dev/null
+++ b/open_issues/performance/io_system/clustered_page_faults.mdwn
@@ -0,0 +1,103 @@
+[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_gnumach open_issue_hurd]]
+
+IRC, freenode, #hurd, 2011-02-16
+
+    <braunr> exceptfor the kernel, everything in an address space is
+      represented with a VM object
+    <braunr> those objects can represent anonymous memory (from malloc() or
+      because of a copy-on-write)
+    <braunr> or files
+    <braunr> on classic Unix systems, these are files
+    <braunr> on the Hurd, these are memory objects, backed by external pagers
+      (like ext2fs)
+    <braunr> so when you read a file
+    <braunr> the kernel maps it from ext2fs in your address space
+    <braunr> and when you access the memory, a fault occurs
+    <braunr> the kernel determines it's a region backed by ext2fs
+    <braunr> so it asks ext2fs to provide the data
+    <braunr> when the fault is resolved, your process goes on
+    <etenil> does the faul occur because Mach doesn't know how to access the
+      memory?
+    <braunr> it occurs because Mach intentionnaly didn't back the region with
+      physical memory
+    <braunr> the MMU is programmed not to know what is present in the memory
+      region
+    <braunr> or because it's read only
+    <braunr> (which is the case for COW faults)
+    <etenil> so that means this bit of memory is a buffer that ext2fs loads the
+      file into and then it is remapped to the application that asked for it
+    <braunr> more or less, yes
+    <braunr> ideally, it's directly written into the right pages
+    <braunr> there is no intermediate buffer
+    <etenil> I see
+    <etenil> and as you told me before, currently the page faults are handled
+      one at a time
+    <etenil> which wastes a lot of time
+    <braunr> a certain amount of time
+    <etenil> enough to bother the user :)
+    <etenil> I've seen pages have a fixed size
+    <braunr> yes
+    <braunr> use the PAGE_SIZE macro
+    <etenil> and when allocating memory, the size that's asked for is rounded
+      up to the page size
+    <etenil> so if I have this correctly, it means that a file ext2fs provides
+      could be split into a lot of pages
+    <braunr> yes
+    <braunr> once in memory, it is managed by the page cache
+    <braunr> so that pages more actively used are kept longer than others
+    <braunr> in order to minimize I/O
+    <etenil> ok
+    <braunr> so a better page cache code would also improve overall performance
+    <braunr> and more RAM would help a lot, since we are strongly limited by
+      the 768 MiB limit
+    <braunr> which reduces the page cache size a lot
+    <etenil> but the problem is that reading a whole file in means trigerring
+      many page faults just for one file
+    <braunr> if you want to stick to the page clustering thing, yes
+    <braunr> you want less page faults, so that there are less IPC between the
+      kernel and the pager
+    <etenil> so either I make pages bigger
+    <etenil> or I modify Mach so it can check up on a range of pages for faults
+      before actually processing
+    <braunr> you *don't* change the page size
+    <etenil> ah
+    <etenil> that's hardware isn't it?
+    <braunr> in Mach, yes
+    <etenil> ok
+    <braunr> and usually, you want the page size to be the CPU page size
+    <etenil> I see
+    <braunr> current CPU can support multiple page sizes, but it becomes quite
+      hard to correctly handle
+    <braunr> and bigger page sizes mean more fragmentation, so it only suits
+      machines with large amounts of RAM, which isn't the case for us
+    <etenil> ok
+    <etenil> so I'll try the second approach then
+    <braunr> that's what i'd recommand
+    <braunr> recommend*
+    <etenil> ok
+
+---
+
+IRC, freenode, #hurd, 2011-02-16
+
+    <antrik> etenil: OSF Mach does have clustered paging BTW; so that's one
+      place to start looking...
+    <antrik> (KAM ported the OSF code to gnumach IIRC)
+    <antrik> there is also an existing patch for clustered paging in libpager,
+      which needs some adaptation
+    <antrik> the biggest part of the task is probably modifying the Hurd
+      servers to use the new interface
+    <antrik> but as I said, KAM's code should be available through google, and
+      can serve as a starting point
+
+<http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00023.html>
diff --git a/open_issues/performance/io_system/read-ahead.mdwn b/open_issues/performance/io_system/read-ahead.mdwn
new file mode 100644
index 00000000..3ee30b5d
--- /dev/null
+++ b/open_issues/performance/io_system/read-ahead.mdwn
@@ -0,0 +1,299 @@
+[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_gnumach open_issue_hurd]]
+
+IRC, #hurd, freenode, 2011-02-13:
+
+    <etenil> youpi: Would libdiskfs/diskfs.h be in the right place to make
+      readahead functions?
+    <youpi> etenil: no, it'd rather be at the memory management layer,
+      i.e. mach, unfortunately
+    <youpi> because that's where you see the page faults
+    <etenil> youpi: Linux also provides a readahead() function for higher level
+      applications. I'll probably have to add the same thing in a place that's
+      higher level than mach
+    <youpi> well, that should just be hooked to the same common implementation
+    <etenil> the man page for readahead() also states that portable
+      applications should avoid it, but it could be benefic to have it for
+      portability
+    <youpi> it's not in posix indeed
+
+---
+
+IRC, #hurd, freenode, 2011-02-14:
+
+    <etenil> youpi: I've investigated prefetching (readahead) techniques. One
+      called DiskSeen seems really efficient. I can't tell yet if it's patented
+      etc. but I'll keep you informed
+    <youpi> don't bother with complicated techniques, even the most simple ones
+      will be plenty :)
+    <etenil> it's not complicated really
+    <youpi> the matter is more about how to plug it into mach
+    <etenil> ok
+    <youpi> then don't bother with potential pattents
+    <antrik> etenil: please take a look at the work KAM did for last year's
+      GSoC
+    <youpi> just use a trivial technique :)
+    <etenil> ok, i'll just go the easy way then
+
+    <braunr> antrik: what was etenil referring to when talking about
+      prefetching ?
+    <braunr> oh, madvise() stuff
+    <braunr> i could help him with that
+
+---
+
+[[Etenil]] is now working in this area.
+
+---
+
+IRC, freenode, #hurd, 2011-02-15
+
+    <etenil> oh, I'm looking into prefetching/readahead to improve I/O
+      performance
+    <braunr> etenil: ok
+    <braunr> etenil: that's actually a VM improvement, like samuel told you
+    <etenil> yes
+    <braunr> a true I/O improvement would be I/O scheduling
+    <braunr> and how to implement it in a hurdish way
+    <braunr> (or if it makes sense to have it in the kernel)
+    <etenil> that's what I've been wondering too lately
+    <braunr> concerning the VM, you should look at madvise()
+    <etenil> my understanding is that Mach considers devices without really
+      knowing what they are
+    <braunr> that's roughly the interface used both at the syscall() and the
+      kernel levels in BSD, which made it in many other unix systems
+    <etenil> whereas I/O optimisations are often hard disk drives specific
+    <braunr> that's true for almost any kernel
+    <braunr> the device knowledge is at the driver level
+    <etenil> yes
+    <braunr> (here, I separate kernels from their drivers ofc)
+    <etenil> but Mach also contains some drivers, so I'm going through the code
+      to find the apropriate place for these improvements
+    <braunr> you shouldn't tough the drivers at all
+    <braunr> touch
+    <etenil> true, but I need to understand how it works before fiddling around
+    <braunr> hm
+    <braunr> not at all
+    <braunr> the VM improvement is about pagein clustering
+    <braunr> you don't need to know how pages are fetched
+    <braunr> well, not at the device level
+    <braunr> you need to know about the protocol between the kernel and
+      external pagers
+    <etenil> ok
+    <braunr> you could also implement pageout clustering
+    <etenil> if I understand you well, you say that what I'd need to do is a
+      queuing system for the paging in the VM?
+    <braunr> no
+    <braunr> i'm saying that, when a page fault occurs, the kernel should
+      (depending on what was configured through madvise()) transfer pages in
+      multiple blocks rather than one at a time
+    <braunr> communication with external pagers is already async, made through
+      regular ports
+    <braunr> which already implement message queuing
+    <braunr> you would just need to make the mapped regions larger
+    <braunr> and maybe change the interface so that this size is passed
+    <etenil> mmh
+    <braunr> (also don't forget that page clustering can include pages *before*
+      the page which caused the fault, so you may have to pass the start of
+      that region too)
+    <etenil> I'm not sure I understand the page fault thing
+    <etenil> is it like a segmentation error?
+    <etenil> I can't find a clear definition in Mach's manual
+    <braunr> ah
+    <braunr> it's a fundamental operating system concept
+    <braunr> http://en.wikipedia.org/wiki/Page_fault
+    <etenil> ah ok
+    <etenil> I understand now
+    <etenil> so what's currently happening is that when a page fault occurs,
+      Mach is transfering pages one at a time and wastes time 
+    <braunr> sometimes, transferring just one page is what you want
+    <braunr> it depends on the application, which is why there is madvise()
+    <braunr> our rootfs, on the other hand, would benefit much from such an
+      improvement
+    <braunr> in UVM, this optimization is account for around 10% global
+      performance improvement
+    <braunr> accounted*
+    <etenil> not bad
+    <braunr> well, with an improved page cache, I'm sure I/O would matter less
+      on systems with more RAM
+    <braunr> (and another improvement would make mach support more RAM in the
+      first place !)
+    <braunr> an I/O scheduler outside the kernel would be a very good project
+      IMO
+    <braunr> in e.g. libstore/storeio
+    <etenil> yes
+    <braunr> but as i stated in my thesis, a resource scheduler should be as
+      close to its resource as it can
+    <braunr> and since mach can host several operating systems, I/O schedulers
+      should reside near device drivers
+    <braunr> and since current drivers are in the kernel, it makes sens to have
+      it in the kernel too
+    <braunr> so there must be some discussion about this
+    <etenil> doesn't this mean that we'll have to get some optimizations in
+      Mach and have the same outside of Mach for translators that access the
+      hardware directly?
+    <braunr> etenil: why ?
+    <etenil> well as you said Mach contains some drivers, but in principle, it
+      shouldn't, translators should do disk access etc, yes?
+    <braunr> etenil: ok
+    <braunr> etenil: so ?
+    <etenil> well, let's say if one were to introduce SATA support in Hurd,
+      nothing would stop him/her to do so with a translator rather than in Mach
+    <braunr> you should avoid the term translator here
+    <braunr> it's really hurd specific
+    <braunr> let's just say a user space task would be responsible for that
+      job, maybe multiple instances of it, yes
+    <etenil> ok, so in this case, let's say we have some I/O optimization
+      techniques like readahead and I/O scheduling within Mach, would these
+      also apply to the user-space task, or would they need to be
+      reimplemented?
+    <braunr> if you have user space drivers, there is no point having I/O
+      scheduling in the kernel
+    <etenil> but we also have drivers within the kernel
+    <braunr> what you call readahead, and I call pagein/out clustering, is
+      really tied to the VM, so it must be in Mach in any case
+    <braunr> well
+    <braunr> you either have one or the other
+    <braunr> currently we have them in the kernel
+    <braunr> if we switch to DDE, we should have all of them outside
+    <braunr> that's why such things must be discussed
+    <etenil> ok so if I follow you, then future I/O device drivers will need to
+      be implemented for Mach
+    <braunr> currently, yes
+    <braunr> but preferrably, someone should continue the work that has been
+      done on DDe so that drivers are outside the kernel
+    <etenil> so for the time being, I will try and improve I/O in Mach, and if
+      drivers ever get out, then some of the I/O optimizations will need to be
+      moved out of Mach
+    <braunr> let me remind you one of the things i said
+    <braunr> i said I/O scheduling should be close to their resource, because
+      we can host several operating systems
+    <braunr> now, the Hurd is the only system running on top of Mach
+    <braunr> so we could just have I/O scheduling outside too
+    <braunr> then you should consider neighbor hurds
+    <braunr> which can use different partitions, but on the same device
+    <braunr> currently, partitions are managed in the kernel, so file systems
+      (and storeio) can't make good scheduling decisions if it remains that way
+    <braunr> but that can change too
+    <braunr> a single storeio representing a whole disk could be shared by
+      several hurd instances, just as if it were a high level driver
+    <braunr> then you could implement I/O scheduling in storeio, which would be
+      an improvement for the current implementation, and reusable for future
+      work
+    <etenil> yes, that was my first instinct
+    <braunr> and you would be mostly free of the kernel internals that make it
+      a nightmare
+    <etenil> but youpi said that it would be better to modify Mach instead
+    <braunr> he mentioned the page clustering thing
+    <braunr> not I/O scheduling
+    <braunr> theseare really two different things
+    <etenil> ok
+    <braunr> you *can't* implement page clustering outside Mach because Mach
+      implements virtual memory
+    <braunr> both policies and mechanisms
+    <etenil> well, I'd rather think of one thing at a time if that's alright
+    <etenil> so what I'm busy with right now is setting up clustered page-in
+    <etenil> which need to be done within Mach
+    <braunr> keep clustered page-outs in mind too
+    <braunr> although there are more constraints on those
+    <etenil> yes
+    <etenil> I've looked up madvise(). There's a lot of documentation about it
+      in Linux but I couldn't find references to it in Mach (nor Hurd), does it
+      exist?
+    <braunr> well, if it did, you wouldn't be caring about clustered page
+      transfers, would you ?
+    <braunr> be careful about linux specific stuff
+    <etenil> I suppose not
+    <braunr> you should implement at least posix options, and if there are
+      more, consider the bsd variants
+    <braunr> (the Mach VM is the ancestor of all modern BSD VMs)
+    <etenil> madvise() seems to be posix
+    <braunr> there are system specific extensions
+    <braunr> be careful
+    <braunr> CONFORMING TO POSIX.1b.   POSIX.1-2001 describes posix_madvise(3)
+      with constants POSIX_MADV_NORMAL, etc., with a behav‐ ior close to that
+      described here.  There is a similar posix_fadvise(2) for file access.
+    <braunr> MADV_REMOVE, MADV_DONTFORK, MADV_DOFORK, MADV_HWPOISON,
+      MADV_MERGEABLE, and MADV_UNMERGEABLE  are  Linux- specific.
+    <etenil> I was about to post these
+    <etenil> ok, so basically madvise() allows tasks etc. to specify a usage
+      type for a chunk of memory, then I could apply the relevant I/O
+      optimization based on this
+    <braunr> that's it
+    <etenil> cool, then I don't need to worry about knowing what the I/O is
+      operating on, I just need to apply the optimizations as advised
+    <etenil> that's convenient
+    <etenil> ok I'll start working on this tonight
+    <etenil> making a basic readahead shouldn't be too hard
+    <braunr> readahead is a misleading name
+    <etenil> is pagein better?
+    <braunr> applies to too many things, doesn't include the case where
+      previous elements could be prefetched
+    <braunr> clustered page transfers is what i would use
+    <braunr> page prefetching maybe
+    <etenil> ok
+    <braunr> you should stick to something that's already used in the
+      literature since you're not inventing something new
+    <etenil> yes I've read a paper about prefetching
+    <etenil> ok
+    <etenil> thanks for your help braunr
+    <braunr> sure
+    <braunr> you're welcome
+    <antrik> braunr: madvise() is really the least important part of the
+      picture...
+    <antrik> very few applications actually use it. but pretty much all
+      applications will profit from clustered paging
+    <antrik> I would consider madvise() an optional goody, not an integral part
+      of the implementation
+    <antrik> etenil: you can find some stuff about KAM's work on
+      http://www.gnu.org/software/hurd/user/kam.html
+    <antrik> not much specific though
+    <etenil> thanks
+    <antrik> I don't remember exactly, but I guess there is also some
+      information on the mailing list. check the archives for last summer
+    <antrik> look for Karim Allah Ahmed
+    <etenil> antrik: I disagree, madvise gives me a good starting point, even
+      if eventually the optimisations should run even without it
+    <antrik> the code he wrote should be available from Google's summer of code
+      page somewhere...
+    <braunr> antrik: right, i was mentioning madvise() because the kernel (VM)
+      interface is pretty similar to the syscall
+    <braunr> but even a default policy would be nice
+    <antrik> etenil: I fear that many bits were discussed only on IRC... so
+      you'd better look through the IRC logs from last April onwards...
+    <etenil> ok
+
+    <etenil> at the beginning I thought I could put that into libstore
+    <etenil> which would have been fine
+
+    <antrik> BTW, I remembered now that KAM's GSoC application should have a
+      pretty good description of the necessary changes... unfortunately, these
+      are not publicly visible IIRC :-(
+
+---
+
+IRC, freenode, #hurd, 2011-02-16
+
+    <etenil> braunr: I've looked in the kernel to see where prefetching would
+      fit best. We talked of the VM yesterday, but I'm not sure about it. It
+      seems to me that the device part of the kernel makes more sense since
+      it's logically what manages devices, am I wrong?
+    <braunr> etenil: you are
+    <braunr> etenil: well
+    <braunr> etenil: drivers should already support clustered sector
+      read/writes
+    <etenil> ah
+    <braunr> but yes, there must be support in the drivers too
+    <braunr> what would really benefit the Hurd mostly concerns page faults, so
+      the right place is the VM subsystem
+
+[[clustered_page_faults]]
diff --git a/user/Etenil.mdwn b/user/Etenil.mdwn
new file mode 100644
index 00000000..a1a3373b
--- /dev/null
+++ b/user/Etenil.mdwn
@@ -0,0 +1,40 @@
+[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!toc]]
+
+## Current task
+
+Implement clustered paging in GNU Mach
+
+- - -
+
+## What the problem is
+In Mach, memory access is ensured by the VM, an abstraction in the kernel. The VM is mapped by pages, which size is arbitrary and defined based on hardware specs. A single block of memory can then span over many pages, i.e. a file on a file system can represent a lot of pages.
+
+When a process attempts to access pages that don't reside in the physical memory (RAM), the MMU detects this and triggers a page fault. Page faults are then handled and the kernel calls down the process associated with the memory pages on a *one by one basis*.
+
+This is where the problem lies. Hard disks are inherently efficient at sequentially writing large chunks of data whereas they cope badly with random access, plus the kernel wastes time writing/reading a page and handling the next page. All of these make for slow I/O in Mach.
+
+## Solutions
+There are a couple of ways I could think of to solve this problem. Pages could be enlarged, but that would cause a lot more problems. Or pages must be handled by groups instead of one by one. This means the changes will also need to be applied in the way user-space processes talk to Mach.
+
+## What's already been done
+[[user/KAM]] has already made a patch that provides basic page clustering. I have yet to understand it completely, but there are troubling changes in the patch, most notably the removal of continuations in *vm_fault* and *vm_fault_page*.
+
+So far, what I can tell is that KAM seems to have modified the memory objects in Mach so that they handle clusters of pages.
+
+## What I intend to do
+Starting from KAM's work, I'll try and at least proxy the current behaviour in the kernel so as to keep backwards compatibility, at least until all user-space processes are converted (maybe some sort of deprecation warning would help porting). I'll also need to modify ext2fs to make it use the clustered paging feature, hopefully it'll improve performance quite a bit.
+
+## Problems
+As *braunr* and *antrik* pointed out on IRC, I seriously lack knowledge about kernel programming, and this is quite a big task. I also don't fully understand the inner workings of the kernel yet, even though *braunr* helped me a lot to understand the VM and page handling.
+
+I'll do what I can and keep maintaining this page so others may pickup where I left if I were to give up.