fix merge

13 files changed, 1068 insertions, 980 deletions

diff --git a/hurd/running/debian/after_install.mdwn b/hurd/running/debian/after_install.mdwn
index 15ca9c83..62fd3574 100644
--- a/hurd/running/debian/after_install.mdwn
+++ b/hurd/running/debian/after_install.mdwn
@@ -29,7 +29,8 @@ If the NIC was detected:
 
     # settrans -fgap /servers/socket/2 /hurd/pfinet -i eth0 -a 192.168.1.3 -g 192.168.1.1 -m 255.255.255.0
 
-In order to use DHCP, you need to install the `dhcp-client` package and run `dhclient eth0` etc.
+Or read about how to configure [[DHCP]].
+
 
 # Setup GRUB
 
diff --git a/hurd/running/debian/dhcp.mdwn b/hurd/running/debian/dhcp.mdwn
new file mode 100644
index 00000000..f316981d
--- /dev/null
+++ b/hurd/running/debian/dhcp.mdwn
@@ -0,0 +1,24 @@
+[[!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_porting]]
+
+In order to use DHCP, you need to install the `ifup` and `isc-dhcp-client`
+packages, and manually create the following two symbolic links:
+
+    # ln -s ../rcS.d/S06ifupdown-clean ../rcS.d/S11networking /etc/rc.boot/
+
+During execution at boot time, the `S11networking` script will emit some error
+messages while trying to configure the loopback interface.  These are not
+fatal.
+
+Debian GNU/Hurd doesn't currently execute's Debian standard `/etc/rcS.d/*` boot
+scripts, but has its own `/libexec/rc` script -- which integrates scripts from
+`/etc/rc.boot/` instead.
diff --git a/hurd/running/debian/faq/df.mdwn b/hurd/running/debian/faq/df.mdwn
index 4de232da..bbd3a7b9 100644
--- a/hurd/running/debian/faq/df.mdwn
+++ b/hurd/running/debian/faq/df.mdwn
@@ -8,6 +8,12 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
 is included in the section entitled
 [[GNU Free Documentation License|/fdl]]."]]"""]]
 
-There is no `/etc/mtab`, so just running `df` will yield an error.  Pass `df` a
-path like `df /` or `df ./` to see the disk usage of that particular file
-system.
+There is no `/etc/mtab` (due to dynamic translator startup, its content is hard
+to define actually, see
+[[the mtab GSoC project idea|community/gsoc/project_ideas/mtab]]),
+so just running `df` will yield the following error.
+
+    df: cannot read table of mounted file systems
+
+Pass `df` a path like `df /` or `df ./` to see the disk usage of that particular
+file system.
diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn
index aea20ae8..4766b2be 100644
--- a/hurd/running/qemu.mdwn
+++ b/hurd/running/qemu.mdwn
@@ -58,6 +58,8 @@ Check if your CPU supports kvm:
 #### If you don't have hardware support (slow):
     $ apt-get install qemu
 
+Do not enable kernel-kqemu, as that assumes some particular behavior from the guest kernel, which we are reluctant to artificially add to gnumach.
+
 #### If you have hardware support (recommended):
     $ apt-get install qemu-kvm
     $ modprobe kvm
@@ -228,9 +230,7 @@ If you just want to access the internet from within QEMU, you can setup pfinet f
     # settrans -afgp /servers/socket/2 /hurd/pfinet -i eth0 -a 10.0.2.15 -g 10.0.2.2 -m 255.255.255.0
     # echo "nameserver 10.0.2.3" > /etc/resolv.conf
 
-Alternately DHCP does work now:
-
-    # dhclient eth0
+If you are on [[Debian GNU/Hurd|debian]], you can even use [[debian/DHCP]].
 
 To get ssh working:
 
diff --git a/hurd/translator/pfinet.mdwn b/hurd/translator/pfinet.mdwn
index cbe50b48..f6f69ea4 100644
--- a/hurd/translator/pfinet.mdwn
+++ b/hurd/translator/pfinet.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2002, 2004, 2005, 2007, 2008 Free Software
+[[!meta copyright="Copyright © 2002, 2004, 2005, 2007, 2008, 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]]."]]"""]]
 
 To configure Internet connectivity, the `pfinet` (*Protocol Family Internet*)
 [[translator]] must be configured.  This is done using the
@@ -31,5 +31,8 @@ installation.
 
 ---
 
+  * [[DHCP]].
+
   * [[Implementation]].
+
   * [[IPv6]].
diff --git a/unsorted/DhcpClient.mdwn b/hurd/translator/pfinet/dhcp.mdwn
index 442f4781..17776fa5 100644
--- a/unsorted/DhcpClient.mdwn
+++ b/hurd/translator/pfinet/dhcp.mdwn
@@ -1,4 +1,4 @@
-# <a name="DHCP_and_the_Hurd"> </a> DHCP and the Hurd
+[[!tag open_issue_hurd]]
 
 According to the following thread, no port should be needed since all the patches that have been applied, including the one concerning the thread. In fact, the thread finishes without concluding whether the patch has been applied or not. You can grab it in the thread, anyway.
 
@@ -40,3 +40,8 @@ Neal Walfield on bug-hurd replies:
     We need to be able to send to the DHCP server with ip address 0.0.0.0.
 
 -- [[Main/JoachimNilsson]] - 12 Nov 2002
+
+---
+
+[[Debian GNU/Hurd|running/debian]] has some script hackery to get
+[[running/debian/DHCP]] going.
diff --git a/unsorted/KnownHurdLimits.mdwn b/unsorted/KnownHurdLimits.mdwn
index 51d66b50..4e7b7620 100644
--- a/unsorted/KnownHurdLimits.mdwn
+++ b/unsorted/KnownHurdLimits.mdwn
@@ -9,10 +9,6 @@
   There are needed by OpenSSH.
   * In progress, see [[translator/random]]
 
-* No DHCP client
-  * promising information [Jan 2005](http://lists.gnu.org/archive/html/bug-hurd/2005-01/msg00025.html), needs an update
-  * See [[DhcpClient]] - need to update TCP/IP server.
-
 * Missing bits of POSIX
   * See [[Distrib/SystemAPILimits]]
 
diff --git a/user/El_Dream_Machine.mdwn b/user/El_Dream_Machine.mdwn
index ac3a0cfc..f6f03779 100644
--- a/user/El_Dream_Machine.mdwn
+++ b/user/El_Dream_Machine.mdwn
@@ -8,6 +8,9 @@ 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]]."]]"""]]
 
+**May 19, 2011** - Very difficult to do my comic on the Hurd I encountered problems of inspiration... I missed the second page but I started again [http://art9libre.tuxfamily.org/gaetan-02.php](http://art9libre.tuxfamily.org/gaetan-02.php)
+I project to share the scenario (CC-BY-SA/Licence Art Libre).
+
 **January 13, 2011** - My story comics on the Hurd continues. I think I can introduce you to page 2 in a month.
 
 **January 11, 2011** - The goal was to install the Hurd in VirtualBox...
diff --git a/user/jkoenig.mdwn b/user/jkoenig.mdwn
index 0b9f9f7d..d135e0e5 100644
--- a/user/jkoenig.mdwn
+++ b/user/jkoenig.mdwn
@@ -8,351 +8,29 @@ 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]]."]]"""]]
 
-## Hurd Debian-Installer
+## Jérémie Koenig
 
-My [proposal](http://wiki.debian.org/SummerOfCode2010/HurdDebianInstaller/JeremieKoenig)
-to work on porting d-i on Hurd
-as a [Google Summer of Code](http://code.google.com/soc/) student
-has been accepted by the Debian project.
+Homepage: [[http://jk.fr.eu.org/]]<br/>
+E-mail: [jk@jk.fr.eu.org](mailto:jk@jk.fr.eu.org)
 
-I will be keeping track of my progress on this page.
+I am a Hurd enthusiast and occasional contributor,
+currently a M.Sc. student at University of Strasbourg.
+Among other things I am interested in formal methods,
+languages and operating system design.
+(Shameless plug:
+I'll be looking for an internship in a research lab from January to June 2012
+and for a position as a Ph.D. student afterwards.)
 
-### Links
+Contributions include:
 
-  * [Modified packages](http://jk.fr.eu.org/debian/unstable)
-  * [Latest images](http://jk.fr.eu.org/debian/hurd-installer)
-  * [Debian bugs](http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=jk@jk.fr.eu.org&tag=gsoc2010)
-  * [BusyBox port](http://lists.debian.org/debian-bsd/2010/05/msg00048.html)
-  * [GNU Mach initrd](http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00047.html)
+  * Help [[port debian-installer|d-i]],
+    as a GSoC student for the Debian project during the summer of 2010.
+  * Rewrite the procfs translator
+    ([bug-hurd](http://lists.gnu.org/archive/html/bug-hurd/2010-08/msg00165.html)
+     [thread](http://lists.gnu.org/archive/html/bug-hurd/2010-09/msg00001.html)).
 
-### Roadmap
+I am working as a GSoC student this summer again,
+for the GNU project,
+on [[Java for Hurd|java]].
 
-* **mach**: initrd support
-    * (./) preliminary patch posted and self-built (2010-06-12)
-    * adjustments will be needed (postponed)
-    * consider the alternatives discussed on bug-hurd (postponed)
-
-* **glibc**: fix `mkdir("/")` which returned `EINVAL`
-    * (./) eglibc 2.11.2-1 includes a quick fix by youpi (2010-06-15)
-    * (./) more complete patch posted to bug-hurd,
-      since other calls return incorrect errors under some circumstances
-      (2010-06-16)
-    * more work on it will be needed to make it fix the whole thing
-      (postponed)
-
-* (./) **partman** (2010-06-23)
-    * (./) add hurd-i386 to
-      `partman-partitioning/lib/disk-label.sh`
-      (2010-06-16, commited by youpi on 2010-06-23)
-    * (./) short-circuit
-      `partman-basicfilesystems/init.d/kernelmodules_basicfilesystems`
-      (2010-06-16)
-    * (./) partman-auto recipes:
-      make the default filesystem os-dependent
-      when it has not been preseeded (ie. the *seen* flag is clear)
-    * (./) force 4k blocks and 128 bytes inodes
-    * (./) submit patches to bugs.debian.org
-      ([[!debbug 586870]] and [[!debbug 586871]])
-    * (./) rebuild with responsible version numbers and upload to my repository
-
-* (./) **libparted** (2010-06-23)
-    * (./) fix device paths ([[!debbug 586696]])
-    * (./) fix crash on exit for part:* stores ([[!debbug 586682]])
-
-* **hurd-udeb** (2010-06-23)
-    * (./) rebuild with the hack suggested by youpi for qemu network configuration
-    * (./) fix mount to accept `-o defaults`
-    * cleanup, ask youpi to commit
-
-* reloading the partition table (2010-06-25)
-    * User-space part stores
-        * (./) hurd-udeb now uses `part:N:device:X` for partition devices
-          (2010-06-23)
-        * (./) it also provides /lib/partman/commit.d/??hurd\_reloadpart,
-          which basically does `settrans -ag /dev/[hs]d*`.
-          (2010-06-24)
-    * Kernel-based partition devices
-        * (./) Mach's drivers from Linux support reloading partitions.
-          With help from youpi this has been made available through a
-          device\_set\_status() call.
-        * (./) make libparted use it
-        * Reminder:
-          I should file a bug against libparted with the patch sometime.
-
-* (./) The `/servers/exec` issue (2010-06-26)
-    * Due to /servers being inexistant,
-      the bootstrap ext2fs could not register the initial exec server,
-      meaning that non-bootstrap filesystems used a different one
-      (started from the passive translator),
-      which for some reason died on shell scripts, making them stall.
-    * Adding the `/servers` directory to hurd-udeb fixed it,
-      as well as the /hurd/proc issue
-      (failed to be run by init the first time around).
-    * Reminder: report the non-bootstrap exec servers failure on scripts.
-
-* (./) **base-installer**: (2010-06-26)
-    * Work around non-existant /proc/mounts.
-    * Firmlink /servers into /target after debootstrap
-      to make the network available.
-
-* (./) **grub-installer**
-    * (./) add hurd support (2010-06-27)
-    * /!\ grub-legacy still needs to be tested
-    * submit changes as a Debian bug
-
-**Milestone (2010-06-28):
-installer kindof works, with documented manual intervention required**
-
-* (./) Sort out the situation with dev node creation (2010-07-07):
-    * Devices and servers used to be set up by debootstrap;
-      the hurd package would add some missing nodes.
-    * New strategy implemented in hurd and debootstrap:
-        * debootstrap uses active firmlinks into the host system
-          for the target system's /dev and /servers.
-        * the hurd package now include a `setup-translators` script,
-          which is used to register the passive translators by the installer's
-          `/libexec/runsystem` and hurd's postinst script.
-
-* **busybox**: submit upstream and to [[!debbug 323670]]
-  (waiting for upstream to review)
-    * (./) I have mentioned my work on the upstream mailing list,
-    * (./) merge the recent changes from upstream,
-      notably to the build system.
-      (2010-06-23)
-    * (./) ask upstream for review and merge
-      (2010-06-25)
-    * (./) sent as patches as requested
-      (2010-07-08)
-    * (./) backport any additional changes onto the debian branch
-    * (./) hijack [[!debbug 323670]] and submit my patches
-
-* **aptitude**:
-    * Currently broken on hurd-i386:
-      [[!debpkg gtest]] fails to build because of a segfault in one of the test
-      cases, [[!debpkg google-mock]] and hence [[!debpkg aptitude]] are missing
-      it as a build-dep.
-      The older package is not installable anymore because it's linked against
-      an older version of libept, which has been removed.
-    * (./) I bypassed the tests and uploaded the 3 packages to my repository
-      (2010-07-08)
-    * The segfault will have to be sorted out. (postponed)
-
-* (./) "Fix" the swap situation. (2010-07-08)
-    * The device\_close() libstore patch
-      had the unfortunate effect of making swapon fail,
-      since the device it activates has to be kept open.
-    * add options for MAKEDEV and setup-devices
-      to use the libparted stores
-    * disable youpi's patch
-    * make partman-basicfilesystems re-create the device
-      as a kernel partition, which is needed for swapon
-
-* (./) netcfg-static: port to hurd (2010-07-09)
-    * There was some amount of hurd support already
-      (namely, activating the interface by replacing the socket translator)
-    * However, this code started an active translator with
-      di\_exec\_shell\_log("settrans -a ...),
-      which stalled as a consequence of it capturing libdi's pipe
-      as its standard output.
-    * Network devices must be probed by trying to open Mach devices
-      with predetermined names (currently eth%d, wl%d),
-      because getifaddrs() does not seem to work on Hurd.
-    * /!\ netcfg, and configuring the installed system, postponed.
-
-* **procps** 3.2.7-11 (current hurd-i386 version) has [[!debbug 546888]]
-    * (./) Submit [[!debbug 588677]] and upload the result to my repository.
-      (2010-07-11)
-
-* (./) Set up a Debian mirror with modified packages for installation
-    * the [mirror](http://jk.fr.eu.org/debian/hurd-install/mirror)
-      is now up and running (2010-07-06)
-    * hacked the image build script to include its public key in
-      debian-archive-keyring at image build time (2010-07-08)
-    * Apparently debootstrap does not handle multiple versions very well.
-      Fix by using dpkg-scan{package,sources} rather than apt-ftparchive
-      to create index files.
-      (2010-07-10)
-    * Use the override files from ftp.debian.org,
-      to avoid debootstrap grabbing inappropriate packages.
-    * Changed them to make [[!debpkg ifupdown]],
-      [[!debpkg dhcp3-client]] and [[!debpkg dhcp3-client]] priority extra,
-      because they're uninstallable at the moment.
-      (2010-07-12)
-
-* (./) Put together a "jk-archive-keyring" package,
-  so that the mirror is authenticated in the target system as well.
-  (2010-07-12)
-
-* (./) Fix grub for user-space partitions (2010-07-16)
-    * grub-probe detects the whole device rather than the partition
-      as the device behind /boot/grub.
-      Consequently, grub-install fails.
-    * One approach would be to replace /dev/hd* by kernel devices
-      for file systems as well as for swap partitions.
-      > {X} this makes the installer crash,
-      > possibly due to cache coherency issue between hdX and hdXsY.
-
-    * (./) GRUB2 kern/emu/getroot.c
-      [patched](http://lists.gnu.org/archive/html/bug-hurd/2010-07/msg00059.html)
-      to support part stores.
-
-* (./) Fix finish-install to skip `finish-install.d/90console` on Hurd
-  (2010-07-17)
-
-* (./) Avoid starting unnecessary /dev translators in a burst (2010-07-20)
-  * Use debootstrap use the extracted /usr/lib/hurd/setup-translators
-    to create device and server nodes in /target,
-    then firmlink the whole /target/dev and /target/servers
-    to the outer system.
-  * Make hurd.postinst not touch them on initial install.
-
-* (./) Fix mach-defpager for file and part stores on larger devices
-  * Use DEVICE\_GET\_RECORDS instead of DEVICE\_GET\_SIZE, which overflows an int
-    (2010-07-22)
-
-**Milestone (2010-07-22):
-installer works but it's still somewhat ugly and broken**
-
-* (./) Ship the UTF-8 font for the hurd console
-  (2010-07-22)
-  * Upload a version of bogl with youpi's patch for Hurd.
-    (see [[!debbug 589987]])
-  * Fix the hurd console for fonts with 16 pixels wide glyphs
-    (ie. handle the 8-wide glyph in there correclty)
-  * Support double-width glyphs (2010-07-24)
-  * (./) However the reduced font can't be loaded yet,
-    so make installer/build/Makefile
-    ship the whole `/usr/src/unifont.bgf`
-    as `/usr/share/hurd/vga-system.bgf`.
-
-* (./) Make the installer used the extended capabilities of the Hurd console
-  (2010-07-23)
-  * Set an UTF-8 locale in `/lib/debian-installer.d/S41term-hurd`.
-  * localechooser: set the language display level to 3
-    when using the hurd console.
-
-* (./) **busybox**: cross-platform package uploaded to experimental
-  (2010-08-03?)
-  * Aurelien Jarno updated the packaging to busybox 1.17.1,
-    fixed a whole lot of bugs,
-    and uploaded a new package with both our changes;
-  * most patches adopted upstream, and included in the new package;
-  * (u)mount/swaponoff ported to kFreeBSD;
-  * per-OS configuration overrides.
-
-* (./) Update custom packages to the latest versions
-  and send updated patches to the BTS
-  (2010-08-11)
-    * updated partman-base to choose a default filesystem in debian/rules
-      rather than at runtime,
-      as suggested by Aurelien Jarno in [[!debbug 586870]]
-    * patch submitted for debian-installer-utils
-      ([[!debbug 592684]]).
-    * patch submitted for locale-chooser
-      ([[!debbug 592690]]).
-    * debootstrap, grub-installer and finish-install not yet submitted,
-      since the details may still change.
-
-* (./) **partman-target**: fix fstab creation
-  (2010-08-11)
-  * See [[!debbug 592671]]
-  * debian/rules: set `partman/mount_style` to `traditional` on Hurd.
-  * finish.d/create\_fstab\_header: add a Hurd case.
-
-* (./) **rootskel**: FTBFS on Hurd and other quirks
-  (to be fixed very soon)
-
-* **d-i/installer/build**: (expected soon)
-    * publish the patch I use
-    * sort out the changes suitable for inclusion
-      and ask youpi and/or debian-boot@l.d.o to commit them
-
-* call for testing and fix the bugs
-
-* Bug in setup-translators/MAKEDEV:
-  permissions are broken for nodes re-created through `MAKEDEV -k`,
-  because MAKEDEV's chmod/chown reaches the pre-existing translator
-    * Maybe settrans could be made to accept -o/--owner and
-      -p/--perm, to set the permissions for the underlying node?
-
-* (./) Silence the "no kernel" warning somehow.
-
-* Investigate the wget/libc/pfinet/whatever bug which corrupts Packages.gz,
-  see the IRC log for 2010-07-23, around 1am UTC+0200 
-
-* Try to resolve problems with udebs which are uninstallable on hurd-i386,
-  such as installation-locale and partman-whatever.
-
-* Provide `/proc/cmdline -> 2/cmdline`, or something.
-
-* Prepare a NMU for genext2fs (which is orphaned),
-  and ask youpi to sponsor the upload.
-
-* **busybox**: port 
-    * fix stty/stat/ipcs on kFreeBSD,
-    * generally port more stuff,
-    * *ip* is needed (maybe) for network configuration,
-    * *mount*, *swaponoff* can be from hurd-udeb for now,
-      though the kFreeBSD people will need them
-
-* **partman**: further adjustments
-    * partman-base: handle /dev/hd?s* in lib/base.h
-    * hide irrelevant mount options? (sync, relatime)
-
-* Network configuration on the installed system.
-  This includes porting ifupdown and isc-dhcp-client,
-  which are currently uninstallable on hurd-i386.
-* Also, better DHCP support during and after installation
-
-* improve the [initrd situation](FIXME: link to bug-hurd post):
-  ajust the ramdisk support in Mach,
-  use tmpfs if possible.
-
-* mklibs{,-copy}:
-  test library reduction,
-  make it copy the ld.so -> ld.so.1 symlink.
-
-* (./) hurd console fonts
-
-**Milestone (expected 2010-07-19):
-it works great and it's beautiful**
-
-* test, fix, document
-* support more types of installation images
-* give a shot at the graphical installer if time permits
-* integrate wireless drivers with netcfg
-* see how [[zhengda]]'s work on DDE could be integrated
-* etc..
-
-### Mostly done
-
-#### Week 1 (2010-05-24)
-
-* genext2fs: patches submitted, [[!debbug 562999]]
-  which add support for all block sizes and choosing them at runtime.
-* busybox: started porting the upstream and Debian package to Hurd and FreeBSD
-* rebuilding hurd-udeb from the pkg-hurd version
-  and adding a ld.so link to the initrd
-  fixes the exec translator crashing on startup.
-  (BTW would there be a mean to detect this from the libdiskfs bootstrap code
-  and report it ?)
-
-#### Week 2 (2010-05-31 to 2010-06-06)
-
-* *busybox*: patches [posted](http://lists.debian.org/debian-bsd/2010/05/msg00048.html).
-* *libdebian-installer4*: [[!debbug 584538]]
-* started working on mach initrd support
-* the installation images could boot into the main-menu
-  with the following changes:
-      * rebuild hurd-udeb from with the latest pkg-hurd patches
-      * use busybox from my osports-debian branch (see link above)
-      * tweak the d-i image build scripts
-      * the symlink /lib/ld.so -> ld.so.1 needs to be created somehow
-        (youpi mentionned it being the job of libc0.3-udeb I think)
-      * fix the poll() issue in libdebian-installer
-        (patch to be submitted soon),
-        also there is some hurd doxygen short-circuiting stuff
-        there which does not apply any more and prevents is to build.
-      * feed the initrd as a hard drive in qemu
-        (with some more space added to avoid it from becoming full)
 
diff --git a/user/jkoenig/d-i.mdwn b/user/jkoenig/d-i.mdwn
new file mode 100644
index 00000000..0b9f9f7d
--- /dev/null
+++ b/user/jkoenig/d-i.mdwn
@@ -0,0 +1,358 @@
+[[!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]]."]]"""]]
+
+## Hurd Debian-Installer
+
+My [proposal](http://wiki.debian.org/SummerOfCode2010/HurdDebianInstaller/JeremieKoenig)
+to work on porting d-i on Hurd
+as a [Google Summer of Code](http://code.google.com/soc/) student
+has been accepted by the Debian project.
+
+I will be keeping track of my progress on this page.
+
+### Links
+
+  * [Modified packages](http://jk.fr.eu.org/debian/unstable)
+  * [Latest images](http://jk.fr.eu.org/debian/hurd-installer)
+  * [Debian bugs](http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=jk@jk.fr.eu.org&tag=gsoc2010)
+  * [BusyBox port](http://lists.debian.org/debian-bsd/2010/05/msg00048.html)
+  * [GNU Mach initrd](http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00047.html)
+
+### Roadmap
+
+* **mach**: initrd support
+    * (./) preliminary patch posted and self-built (2010-06-12)
+    * adjustments will be needed (postponed)
+    * consider the alternatives discussed on bug-hurd (postponed)
+
+* **glibc**: fix `mkdir("/")` which returned `EINVAL`
+    * (./) eglibc 2.11.2-1 includes a quick fix by youpi (2010-06-15)
+    * (./) more complete patch posted to bug-hurd,
+      since other calls return incorrect errors under some circumstances
+      (2010-06-16)
+    * more work on it will be needed to make it fix the whole thing
+      (postponed)
+
+* (./) **partman** (2010-06-23)
+    * (./) add hurd-i386 to
+      `partman-partitioning/lib/disk-label.sh`
+      (2010-06-16, commited by youpi on 2010-06-23)
+    * (./) short-circuit
+      `partman-basicfilesystems/init.d/kernelmodules_basicfilesystems`
+      (2010-06-16)
+    * (./) partman-auto recipes:
+      make the default filesystem os-dependent
+      when it has not been preseeded (ie. the *seen* flag is clear)
+    * (./) force 4k blocks and 128 bytes inodes
+    * (./) submit patches to bugs.debian.org
+      ([[!debbug 586870]] and [[!debbug 586871]])
+    * (./) rebuild with responsible version numbers and upload to my repository
+
+* (./) **libparted** (2010-06-23)
+    * (./) fix device paths ([[!debbug 586696]])
+    * (./) fix crash on exit for part:* stores ([[!debbug 586682]])
+
+* **hurd-udeb** (2010-06-23)
+    * (./) rebuild with the hack suggested by youpi for qemu network configuration
+    * (./) fix mount to accept `-o defaults`
+    * cleanup, ask youpi to commit
+
+* reloading the partition table (2010-06-25)
+    * User-space part stores
+        * (./) hurd-udeb now uses `part:N:device:X` for partition devices
+          (2010-06-23)
+        * (./) it also provides /lib/partman/commit.d/??hurd\_reloadpart,
+          which basically does `settrans -ag /dev/[hs]d*`.
+          (2010-06-24)
+    * Kernel-based partition devices
+        * (./) Mach's drivers from Linux support reloading partitions.
+          With help from youpi this has been made available through a
+          device\_set\_status() call.
+        * (./) make libparted use it
+        * Reminder:
+          I should file a bug against libparted with the patch sometime.
+
+* (./) The `/servers/exec` issue (2010-06-26)
+    * Due to /servers being inexistant,
+      the bootstrap ext2fs could not register the initial exec server,
+      meaning that non-bootstrap filesystems used a different one
+      (started from the passive translator),
+      which for some reason died on shell scripts, making them stall.
+    * Adding the `/servers` directory to hurd-udeb fixed it,
+      as well as the /hurd/proc issue
+      (failed to be run by init the first time around).
+    * Reminder: report the non-bootstrap exec servers failure on scripts.
+
+* (./) **base-installer**: (2010-06-26)
+    * Work around non-existant /proc/mounts.
+    * Firmlink /servers into /target after debootstrap
+      to make the network available.
+
+* (./) **grub-installer**
+    * (./) add hurd support (2010-06-27)
+    * /!\ grub-legacy still needs to be tested
+    * submit changes as a Debian bug
+
+**Milestone (2010-06-28):
+installer kindof works, with documented manual intervention required**
+
+* (./) Sort out the situation with dev node creation (2010-07-07):
+    * Devices and servers used to be set up by debootstrap;
+      the hurd package would add some missing nodes.
+    * New strategy implemented in hurd and debootstrap:
+        * debootstrap uses active firmlinks into the host system
+          for the target system's /dev and /servers.
+        * the hurd package now include a `setup-translators` script,
+          which is used to register the passive translators by the installer's
+          `/libexec/runsystem` and hurd's postinst script.
+
+* **busybox**: submit upstream and to [[!debbug 323670]]
+  (waiting for upstream to review)
+    * (./) I have mentioned my work on the upstream mailing list,
+    * (./) merge the recent changes from upstream,
+      notably to the build system.
+      (2010-06-23)
+    * (./) ask upstream for review and merge
+      (2010-06-25)
+    * (./) sent as patches as requested
+      (2010-07-08)
+    * (./) backport any additional changes onto the debian branch
+    * (./) hijack [[!debbug 323670]] and submit my patches
+
+* **aptitude**:
+    * Currently broken on hurd-i386:
+      [[!debpkg gtest]] fails to build because of a segfault in one of the test
+      cases, [[!debpkg google-mock]] and hence [[!debpkg aptitude]] are missing
+      it as a build-dep.
+      The older package is not installable anymore because it's linked against
+      an older version of libept, which has been removed.
+    * (./) I bypassed the tests and uploaded the 3 packages to my repository
+      (2010-07-08)
+    * The segfault will have to be sorted out. (postponed)
+
+* (./) "Fix" the swap situation. (2010-07-08)
+    * The device\_close() libstore patch
+      had the unfortunate effect of making swapon fail,
+      since the device it activates has to be kept open.
+    * add options for MAKEDEV and setup-devices
+      to use the libparted stores
+    * disable youpi's patch
+    * make partman-basicfilesystems re-create the device
+      as a kernel partition, which is needed for swapon
+
+* (./) netcfg-static: port to hurd (2010-07-09)
+    * There was some amount of hurd support already
+      (namely, activating the interface by replacing the socket translator)
+    * However, this code started an active translator with
+      di\_exec\_shell\_log("settrans -a ...),
+      which stalled as a consequence of it capturing libdi's pipe
+      as its standard output.
+    * Network devices must be probed by trying to open Mach devices
+      with predetermined names (currently eth%d, wl%d),
+      because getifaddrs() does not seem to work on Hurd.
+    * /!\ netcfg, and configuring the installed system, postponed.
+
+* **procps** 3.2.7-11 (current hurd-i386 version) has [[!debbug 546888]]
+    * (./) Submit [[!debbug 588677]] and upload the result to my repository.
+      (2010-07-11)
+
+* (./) Set up a Debian mirror with modified packages for installation
+    * the [mirror](http://jk.fr.eu.org/debian/hurd-install/mirror)
+      is now up and running (2010-07-06)
+    * hacked the image build script to include its public key in
+      debian-archive-keyring at image build time (2010-07-08)
+    * Apparently debootstrap does not handle multiple versions very well.
+      Fix by using dpkg-scan{package,sources} rather than apt-ftparchive
+      to create index files.
+      (2010-07-10)
+    * Use the override files from ftp.debian.org,
+      to avoid debootstrap grabbing inappropriate packages.
+    * Changed them to make [[!debpkg ifupdown]],
+      [[!debpkg dhcp3-client]] and [[!debpkg dhcp3-client]] priority extra,
+      because they're uninstallable at the moment.
+      (2010-07-12)
+
+* (./) Put together a "jk-archive-keyring" package,
+  so that the mirror is authenticated in the target system as well.
+  (2010-07-12)
+
+* (./) Fix grub for user-space partitions (2010-07-16)
+    * grub-probe detects the whole device rather than the partition
+      as the device behind /boot/grub.
+      Consequently, grub-install fails.
+    * One approach would be to replace /dev/hd* by kernel devices
+      for file systems as well as for swap partitions.
+      > {X} this makes the installer crash,
+      > possibly due to cache coherency issue between hdX and hdXsY.
+
+    * (./) GRUB2 kern/emu/getroot.c
+      [patched](http://lists.gnu.org/archive/html/bug-hurd/2010-07/msg00059.html)
+      to support part stores.
+
+* (./) Fix finish-install to skip `finish-install.d/90console` on Hurd
+  (2010-07-17)
+
+* (./) Avoid starting unnecessary /dev translators in a burst (2010-07-20)
+  * Use debootstrap use the extracted /usr/lib/hurd/setup-translators
+    to create device and server nodes in /target,
+    then firmlink the whole /target/dev and /target/servers
+    to the outer system.
+  * Make hurd.postinst not touch them on initial install.
+
+* (./) Fix mach-defpager for file and part stores on larger devices
+  * Use DEVICE\_GET\_RECORDS instead of DEVICE\_GET\_SIZE, which overflows an int
+    (2010-07-22)
+
+**Milestone (2010-07-22):
+installer works but it's still somewhat ugly and broken**
+
+* (./) Ship the UTF-8 font for the hurd console
+  (2010-07-22)
+  * Upload a version of bogl with youpi's patch for Hurd.
+    (see [[!debbug 589987]])
+  * Fix the hurd console for fonts with 16 pixels wide glyphs
+    (ie. handle the 8-wide glyph in there correclty)
+  * Support double-width glyphs (2010-07-24)
+  * (./) However the reduced font can't be loaded yet,
+    so make installer/build/Makefile
+    ship the whole `/usr/src/unifont.bgf`
+    as `/usr/share/hurd/vga-system.bgf`.
+
+* (./) Make the installer used the extended capabilities of the Hurd console
+  (2010-07-23)
+  * Set an UTF-8 locale in `/lib/debian-installer.d/S41term-hurd`.
+  * localechooser: set the language display level to 3
+    when using the hurd console.
+
+* (./) **busybox**: cross-platform package uploaded to experimental
+  (2010-08-03?)
+  * Aurelien Jarno updated the packaging to busybox 1.17.1,
+    fixed a whole lot of bugs,
+    and uploaded a new package with both our changes;
+  * most patches adopted upstream, and included in the new package;
+  * (u)mount/swaponoff ported to kFreeBSD;
+  * per-OS configuration overrides.
+
+* (./) Update custom packages to the latest versions
+  and send updated patches to the BTS
+  (2010-08-11)
+    * updated partman-base to choose a default filesystem in debian/rules
+      rather than at runtime,
+      as suggested by Aurelien Jarno in [[!debbug 586870]]
+    * patch submitted for debian-installer-utils
+      ([[!debbug 592684]]).
+    * patch submitted for locale-chooser
+      ([[!debbug 592690]]).
+    * debootstrap, grub-installer and finish-install not yet submitted,
+      since the details may still change.
+
+* (./) **partman-target**: fix fstab creation
+  (2010-08-11)
+  * See [[!debbug 592671]]
+  * debian/rules: set `partman/mount_style` to `traditional` on Hurd.
+  * finish.d/create\_fstab\_header: add a Hurd case.
+
+* (./) **rootskel**: FTBFS on Hurd and other quirks
+  (to be fixed very soon)
+
+* **d-i/installer/build**: (expected soon)
+    * publish the patch I use
+    * sort out the changes suitable for inclusion
+      and ask youpi and/or debian-boot@l.d.o to commit them
+
+* call for testing and fix the bugs
+
+* Bug in setup-translators/MAKEDEV:
+  permissions are broken for nodes re-created through `MAKEDEV -k`,
+  because MAKEDEV's chmod/chown reaches the pre-existing translator
+    * Maybe settrans could be made to accept -o/--owner and
+      -p/--perm, to set the permissions for the underlying node?
+
+* (./) Silence the "no kernel" warning somehow.
+
+* Investigate the wget/libc/pfinet/whatever bug which corrupts Packages.gz,
+  see the IRC log for 2010-07-23, around 1am UTC+0200 
+
+* Try to resolve problems with udebs which are uninstallable on hurd-i386,
+  such as installation-locale and partman-whatever.
+
+* Provide `/proc/cmdline -> 2/cmdline`, or something.
+
+* Prepare a NMU for genext2fs (which is orphaned),
+  and ask youpi to sponsor the upload.
+
+* **busybox**: port 
+    * fix stty/stat/ipcs on kFreeBSD,
+    * generally port more stuff,
+    * *ip* is needed (maybe) for network configuration,
+    * *mount*, *swaponoff* can be from hurd-udeb for now,
+      though the kFreeBSD people will need them
+
+* **partman**: further adjustments
+    * partman-base: handle /dev/hd?s* in lib/base.h
+    * hide irrelevant mount options? (sync, relatime)
+
+* Network configuration on the installed system.
+  This includes porting ifupdown and isc-dhcp-client,
+  which are currently uninstallable on hurd-i386.
+* Also, better DHCP support during and after installation
+
+* improve the [initrd situation](FIXME: link to bug-hurd post):
+  ajust the ramdisk support in Mach,
+  use tmpfs if possible.
+
+* mklibs{,-copy}:
+  test library reduction,
+  make it copy the ld.so -> ld.so.1 symlink.
+
+* (./) hurd console fonts
+
+**Milestone (expected 2010-07-19):
+it works great and it's beautiful**
+
+* test, fix, document
+* support more types of installation images
+* give a shot at the graphical installer if time permits
+* integrate wireless drivers with netcfg
+* see how [[zhengda]]'s work on DDE could be integrated
+* etc..
+
+### Mostly done
+
+#### Week 1 (2010-05-24)
+
+* genext2fs: patches submitted, [[!debbug 562999]]
+  which add support for all block sizes and choosing them at runtime.
+* busybox: started porting the upstream and Debian package to Hurd and FreeBSD
+* rebuilding hurd-udeb from the pkg-hurd version
+  and adding a ld.so link to the initrd
+  fixes the exec translator crashing on startup.
+  (BTW would there be a mean to detect this from the libdiskfs bootstrap code
+  and report it ?)
+
+#### Week 2 (2010-05-31 to 2010-06-06)
+
+* *busybox*: patches [posted](http://lists.debian.org/debian-bsd/2010/05/msg00048.html).
+* *libdebian-installer4*: [[!debbug 584538]]
+* started working on mach initrd support
+* the installation images could boot into the main-menu
+  with the following changes:
+      * rebuild hurd-udeb from with the latest pkg-hurd patches
+      * use busybox from my osports-debian branch (see link above)
+      * tweak the d-i image build scripts
+      * the symlink /lib/ld.so -> ld.so.1 needs to be created somehow
+        (youpi mentionned it being the job of libc0.3-udeb I think)
+      * fix the poll() issue in libdebian-installer
+        (patch to be submitted soon),
+        also there is some hurd doxygen short-circuiting stuff
+        there which does not apply any more and prevents is to build.
+      * feed the initrd as a hard drive in qemu
+        (with some more space added to avoid it from becoming full)
+
diff --git a/user/jkoenig/gsoc2011_proposal.mdwn b/user/jkoenig/gsoc2011_proposal.mdwn
index 4052f455..ccdde659 100644
--- a/user/jkoenig/gsoc2011_proposal.mdwn
+++ b/user/jkoenig/gsoc2011_proposal.mdwn
@@ -1,628 +1,14 @@
+[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
 
-# Java for Hurd (and vice versa)
+[[!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]]."]]"""]]
 
-Contact information:
+## Hurd Debian-Installer
 
-  * Full name: Jérémie Koenig
-  * Email: jk@jk.fr.eu.org
-  * IRC: jkoenig on Freenode and OFTC
-
-## Introductions
-
-I am a first year M.Sc. student
-in Computer Science at University of Strasbourg (France).
-My interests include capability-based security,
-programming languages and formal methods
-(in particular, object-capability languages and proof-carrying code).
-
-### Proposal summary
-
-This project would consist in improving Java support on Hurd.
-The first part would consist in
-fixing bugs and porting Java-related packages.
-The second part would consist in
-creating low-level Java bindings for the Hurd interfaces,
-as well as libraries to make translator development easier.
-
-### Previous involvement
-
-I started contributing to Hurd last summer,
-during which I participated to Google Summer of Code
-as a student for the Debian project.
-I worked on porting Debian-Installer to Hurd.
-This project was mostly a success,
-although we still have to use a special mirror for installation
-with a few modified packages
-and tweaked priorities
-to work around some uninstallable packages
-with Priority: standard.
-
-Shortly afterwards,
-I rewrote the procfs translator
-to fix some issues with memory leaks,
-make it more reliable,
-and improve compatibility with Linux-based tools
-such as `procps` or `htop`.
-
-Although I have not had as much time
-as I would have liked to dedicate to the Hurd
-since that time,
-I have continued to maintain the mirror in question,
-and I have started to work
-on implementing POSIX threads signal semantics in glibc.
-
-### Project-related skills and interests
-
-I have used Java mostly for university assignments.
-This includes non-trivial projects
-using threads and distributed programming frameworks
-such as Java RMI or CORBA.
-I have also used it to experiment with
-Google App Engine
-(web applications)
-and Google Web Toolkit
-(a compiler from Java to Javascript which helps with AJAX code),
-and I have some limited experience with JNI
-(the Java Native Interface, to link Java with C code).
-
-My knowledge of the Hurd and Debian GNU/Hurd is reasonable,
-as the Debian-Installer and procfs projects
-gave me the opportunity to fiddle with many parts of the system.
-
-Initially,
-I started working on this project because I wanted to use
-[Joe-E](http://code.google.com/p/joe-e/)
-(a subset of Java)
-to investigate the potential
-[[applications of object-capability languages|objcap]]
-in a Hurd context.
-I also believe that improving Java support on Hurd
-would be an important milestone.
-
-### Organisational matters
-
-I am subscribed to bug-hurd@g.o and
-I do have a permanent internet connexion.
-
-I would be able to attend the regular IRC meetings,
-and otherwise communicate with my mentor
-through any means they would prefer
-(though I expect email and IRC would be the most practical).
-Since I'm already familiar with the Hurd,
-I don't expect I would require too much time from them.
-
-My exams end on May 20 so I would be able to start coding
-right at the beginning of the GSoC period.
-Next year's term would probably begin around September 15,
-so that would not be an issue either.
-I expect I would work around 40 hours per week,
-and my waking hours would be flexible.
-
-I don't have any other plans for the summer
-and would not make any if my project were to be accepted.
-
-Full disclosure:
-I also submitted a proposal to the Jikes RVM project
-(which is a research-oriented Java Virtual Machine,
-itself written in Java)
-for implementing a new garbage collector into the MMTk subsystem.
-
-## Improve Java support
-
-### Justification
-
-Java is a popular language and platform used by many desktop and web
-applications (mostly on the server side). As a consequence, competitive Java
-support is important for any general-purpose operating system.
-Better Java support would also be a prerequisite
-for the second part of my proposal.
-
-### Current situation
-
-Java is currently supported on Hurd with the GNU Java suite:
-
-   * [GCJ](http://gcc.gnu.org/java/),
-     the GNU Compiler for Java, is part of GCC and can compile Java
-     source code to Java bytecode, and both source code and bytecode to
-     native code;
-   * libgcj is the implementation of the Java runtime which GCJ uses.
-     It is based on [GNU Classpath](http://www.gnu.org/software/classpath/).
-     It includes a bytecode interpreter which enables
-     Java applications compiled to native code to dynamically load and execute
-     Java bytecode from class files.
-   * The gij command is a wrapper around the above-mentioned virtual machine
-     functionality of libgcj and can be used as a replacement for the java
-     command.
-
-However, GCJ does not work flawlessly on Hurd.r
-For instance, some parts of libgcj relies on
-the POSIX threads signal semantics, which are not yet implemented.
-In particular, this makes ant hang waiting for child processes,
-which makes some packages fail to build on Hurd
-(“ant” is the “make” of the Java world).
-
-### Tasks
-
-   * **Finish implementing POSIX thread semantics** in glibc (high priority).
-     According to POSIX, signal dispositions should be global to a process,
-     while signal blocking masks should be thread-specific. Signals sent to the
-     process as a whole are to be delivered to any thread which does not block
-     them. By contrast, Hurd has per-thread signal dispositions and signals
-     sent to a process are delivered to the main thread only. I have been
-     working on refactoring the glibc signal code and implementing the POSIX
-     semantics as a per-thread option. However, due to lack of time I have not
-     yet been able to test and debug my code properly. Finishing this work
-     would be my first task.
-   * **Fix further problems with GCJ on Hurd** (high priority). While I’m not
-     aware of any other problems with GCJ at the moment, I suspect some might
-     turn up as I progress with the other tasks. Fixing these problems would
-     also be a high-priority task.
-   * **Port OpenJDK 6** (medium priority). While GCJ is fine, it is not yet
-     100% complete. It is also slower than OpenJDK on architectures where a
-     just-in-time compiler is available. Porting OpenJDK would therefore
-     improve Java support on Hurd in scope and quality. Besides, it would also
-     be a good way to test GCJ, which is used for bootstrapping by the Debian
-     OpenJDK packages. Also note that OpenJDK 6 is now the default Java
-     Runtime Environment on all released Linux-based Debian architectures;
-     bringing Hurd in line with this would probably be a good thing.
-   * **Port Eclipse and other Java applications** (low priority). Eclipse is a
-     popular, state-of-the-art IDE and tool suite used for Java and other
-     languages. It is a dependency of the Joe-E verifier (see part 3 of this
-     proposal). Porting Eclipse would be a good opportunity to test GCJ and
-     OpenJDK.
-
-### Deliverables
-
-  * The glibc pthreads patch and any other fixes on the Hurd side
-    would be submitted upstream
-  * Patches against Debian source packages
-    required to make them build on Hurd would be submitted
-    to the [Debian bug tracking system](http://bugs.debian.org/).
-
-
-## Create Java bindings for the Hurd interfaces
-
-### Justification
-
-Java is used for many applications and often taught to
-introduce object-oriented programming. The fact that Java is a
-garbage-collected language makes it easier to use, especially for the less
-experienced programmers. Besides, its object-oriented nature is a
-natural fit for the capability-based design of Hurd.
-The JVM is also used as a target for many other languages,
-all of which would benefit from the access provided by these bindings.
-
-Advantages over other garbage-collected, object-oriented languages include
-performance, type safety and the possibility to compile a Java translator to
-native code and
-[link it statically](http://gcc.gnu.org/wiki/Statically_linking_libgcj)
-using GCJ, should anyone want to use a
-translator written in Java for booting.
-Note that Java is
-[being](http://www.linuxjournal.com/article/8757)
-[used](http://oss.readytalk.com/avian/)
-in this manner for embedded development.
-Since GCJ can take bytecode as its input,
-this expect this possibility would apply to any JVM-based language.
-
-Java bindings would lower the bar for newcomers
-to begin experimenting with what makes Hurd unique
-without being faced right away with the complexity of
-low-level systems programming.
-
-### Tasks summary
-
-  * Implement Java bindings for Mach
-  * Implement a libports-like library for Java
-  * Modify MIG to output Java code
-  * Implement libfoofs-like Java libraries
-
-### Design principles
-
-The principles I would use to guide the design
-of these Java bindings would be the following ones:
-
-  * The system should be hooked into at a low level,
-    to ensure that Java is a "first class citizen"
-    as far as the access to the Hurd's interfaces is concerned.
-  * At the same time, the memory safety of Java should be maintained
-    and extended to Mach primitives such as port names and
-    out-of-line memory regions.
-  * Higher-level interfaces should be provided as well
-    in order to make translator development
-    as easy as possible.
-  * A minimum amount of JNI code (ie. C code) should be used.
-    Most of the system should be built using Java itself
-    on top of a few low-level primitives.
-  * Hurd objects would map to Java objects.
-  * Using the same interfaces,
-    objects corresponding to local ports would be accessed directly,
-    and remote objects would be accessed over IPC.
-
-One approach used previously to interface programming languages with the Hurd
-has been to create bindings for helper libraries such as libtrivfs. Instead,
-for Java I would like to take a lower-level approach by providing access to
-Mach primitives and extending MIG to generate Java code from the interface
-description files.
-
-This approach would be initially more involved, and would introduces several
-issues related to overcoming the "impedance mismatch" between Java and Mach.
-However, once an initial implementation is done it would be easier to maintain
-in the long run and we would be able to provide Java bindings for a large
-percentage of the Hurd’s interfaces.
-
-### Bindings for Mach system calls
-
-In this low-level approach, my intention is to enable Java code to use Mach
-system calls (in particular, mach_msg) more or less directly. This would
-ensure full access to the system from Java code, but it raises a number of
-issues:
-
-  * the Java code must be able to manipulate Mach-level entities, such as port
-    rights or page-aligned buffers mapped outside of the garbage-collected
-    heap (for out-of-line transfers);
-  * putting together IPC messages requires control of the low-level
-    representation of data.
-
-In order to address these concerns, classes would be encapsulating these
-low-level entities so that they can be referenced through normal, safe objects
-from standard Java code. Bindings for Mach system calls can then be provided
-in terms of these classes. Their implementation would use C code through the
-Java Native Interface (JNI).
-
-More specifically, this functionality would be provided by the `org.gnu.mach`
-package, which would contain at least the following classes:
-
-  * `MachPort` would encapsulate a `mach_port_t`. (Some of) its constructors
-    would act as an interface for the `mach_port_allocate()` system call.
-    `MachPort` objects would also be instantiated from other parts of the JNI
-    C code to represent port rights received through IPC. The `deallocate()`
-    method would call `mach_port_deallocate()` and replace the encapsulated
-    port name with `MACH_PORT_DEAD`. We would recommend that users call it
-    when a port is no longer used, but the finalizer would also deallocate the
-    port when the `MachPort` object is garbage collected.
-  * `Buffer` would represent a page-aligned buffer allocated outside of the
-    Java heap, to be transferred (or having been received) as out-of-line
-    memory. The JNI code would would provide methods to read and write data at
-    an arbitrary offset (but within bounds) and would use `vm_allocate()` and
-    `vm_deallocate()` in the same spirit as for `MachPort` objects.
-  * `Message` would allow Java code to put together Mach messages. The
-    constructor would allocate a `byte[]` member array of a given size.
-    Additional methods would be provided to fill in or query the information
-    in the message header and additional data items, including `MachPort` and
-    `Buffer` objects which would be translated to the corresponding port names
-    and out-of-line pointers.
-    A global map from port names to the corresponding `MachPort` object
-    would probably be needed to ensure that there is a one-to-one
-    correspondence.
-  * `Syscall` would provide static JNI methods for performing system calls not
-    covered by the above classes, such as `mach_msg()` or
-    `mach_thread_self()`.  These methods would accept or return `MachPort`,
-    `Buffer` and `Message` objects when appropriate. The associated C code
-    would access the contents of such objects directly in order to perform the
-    required unsafe operations, such as constructing `MachPort` and `Buffer`
-    objects directly from port names and C pointers.
-
-Note that careful consideration should be given to the interfaces of these
-classes to avoid “safety leaks” which would compromise the safety guarantees
-provided by Java. Potential problematic scenarios include the following
-examples:
-
-  * It must not be possible to write an integer at some position in a
-    `Message` object, and to read it back as a `MachPort` or `Buffer` object,
-    since this would allow unsafe access to arbitrary memory addresses and
-    mach port names.
-  * Providing the `mach_task_self()` system call would also provide access to
-    arbitrary addresses and ports by using the `vm_*` family of RPC operations
-    with the returned `MachPort` object. This means that the relevant task
-    operations should be provided by the `Syscall` class instead.
-
-Finally, access should be provided to the initial ports and file descriptors
-in `_hurd_ports` and provided by the `getdport()` function,
-for instance through static methods such as
-`getCRDir()`, `getCWDir()`, `getProc()`, ... in a dedicated class such as
-`org.gnu.hurd.InitPorts`.
-
-A realistic example of code based on such interfaces would be:
-
-    import org.gnu.mach.MsgType;
-    import org.gnu.mach.MachPort;
-    import org.gnu.mach.Buffer;
-    import org.gnu.mach.Message;
-    import org.gnu.mach.Syscall;
-    import org.gnu.hurd.InitPorts;
-
-    public class Hello
-    {   
-       public static main(String argv[])
-           /* Parent class for all Mach-related exceptions */
-           throws org.gnu.mach.MachException
-       {   
-           /* Allocate a reply port */
-           MachPort reply = new MachPort();
-
-           /* Allocate an out-of-line buffer */
-           Buffer data = new Buffer(MsgType.CHAR, 13);
-           data.writeString(0, "Hello, World!");
-
-           /* Craft an io_write message */
-           Message msg = new Message(1024);
-           msg.setRemotePort(InitPorts.getdport(1));
-           msg.setLocalPort(reply, Message.Type.MAKE_SEND_ONCE);
-           msg.setId(21000);
-           msg.addBuffer(data);
-
-           /* Make the call, MACH_MSG_SEND | MACH_MSG_RECEIVE */
-           Syscall.machMsg(msg, true, true, reply);
-
-           /* Extract the returned value */
-           msg.assertId(21100);
-           int retCode = msg.readInt(0);
-           int amount = msg.readInt(1);
-       }
-    }
-
-Should this paradigm prove insufficient,
-more ideas could be borrowed from the
-[`org.vmmagic`](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.151.5253&rep=rep1&type=pdf)
-package used by [Jikes RVM](http://jikesrvm.org/),
-a research Java virtual machine itself written in Java.
-
-### Generating Java stubs with MIG
-
-Once the basic machinery is in place to interface with Mach, Java programs
-have more or less equal access to the system functionality without resorting
-to more JNI code. However, as illustrated above, this access is far from
-convenient.
-
-As a solution I would modify MIG to add the option to output Java code. MIG
-would emit a Java interface, a client class able to implement the interface
-given a Mach port send right, an a server class which would be able to handle
-incoming messages. The class diagram below, although it is by no means
-complete or exempt of any problem, illustrates the general idea:
-
-[[gsoc2011_classes.png]]
-
-This structure is somewhat reminiscent of
-[Java RMI](http://en.wikipedia.org/wiki/Java_remote_method_invocation)
-or similar systems,
-which aim to provide more or less transparent access to remote objects.
-The exact way the Java code would be generated still needs to be determined,
-but basically:
-
-  * An interface, corresponding to the header files generated by MIG, would
-    enumerate the operations listed in a given .defs files. Method names would
-    be transformed to adhere to Java conventions (for instance,
-    `some_random_identifier` would become `someRandomIdentifier`).
-  * A user class, corresponding to the `*User.c` files,
-    would implement this interface by doing RPC over a given MachPort object.
-  * A server class, corresponding to `*Server.c`, would be able to handle
-    incoming messages using a user-provided implementation of the interface.
-    (Possibly, a skeleton class providing methods which would raise
-    `NotImplementedException`s would be provided as well.
-    Users would derive from this class and override the relevant methods.
-    This would allow them not to implement some operations,
-    and would avoid pre-existing code from breaking when new operations are
-    introduced.)
-
-In order to help with the implementation of servers, some kind of library
-would be needed to associate Mach receive rights with server objects and to
-handle incoming messages on dedicated threads, in the spirit of libports.
-This would probably require support for port sets at the level of the Mach
-primitives described in the previous section.
-
-When possible, operations involving the transmission of send rights
-of some kind would be expressed in terms of the MIG-generated interfaces
-instead of `MachPort` objects.
-Upon reception of a send right,
-a `FooUser` object would be created
-and associated with the corresponding `MachPort` object.
-If the received send right corresponds to a local port
-to which a server object has been associated,
-this object would be used instead.
-This way,
-subsequent operations on the received send right
-would be handled as direct method calls
-instead of going through RPC mechanisms.
-
-Some issues will still need to be solved regarding how MIG will convert
-interface description files to Java interfaces. For instance:
-
-  * `.defs` files are not explicitly associated with a type. For instance in
-    the example above, MIG would have to somehow infer that io_t corresponds
-    to `this` in the `Io` interface.
-  * More generally, a correspondence between MIG and Java types would have
-    to be determined. Ideally this would be automated and not hardcoded
-    too much.
-  * Initially, reply port parameters would be ignored. However they may be
-    needed for some applications.
-
-So the details would need to be flushed out during the community bonding
-period and as the implementation progresses. However I’m confident that a
-satisfactory solution can be designed.
-
-Using these new features, the example above could be rewritten as:
-
-    import org.gnu.hurd.InitPorts;
-    import org.gnu.hurd.Io;
-    import org.gnu.hurd.IoUser;
-
-    class Hello {
-       static void main(String argv[]) throws ...
-       {
-           Io stdout = new IoUser(InitPorts.getdport(1));
-           String hello = “Hello, World!\n”;
-
-           int amount = stdout.write(hello.getBytes(), -1);
-
-           /* (A retCode corresponding to an error
-               would be signalled as an exception.) */
-       }
-    }
-
-An example of server implementation would be:
-
-    import org.gnu.hurd.Io;
-    import java.util.Arrays;
-
-    class HelloIo implements Io {
-       final byte[] contents = “Hello, World!\n”.getBytes();
-
-       int write(byte[] data, int offset) {
-           return SOME_ERROR_CODE;
-       }
-
-       byte[] read(int offset, int amount) {
-           return Arrays.copyOfRange(contents, offset,
-                                     offset + amount - 1);
-       }
-
-       /* ... */
-    }
-
-A new server object could then be created with `new IoServer(new HelloIo())`,
-and associated with some receive right at the level of the ports management
-library.
-
-### Base classes for common types of translators
-
-Once MIG can target Java code, and a libports equivalent is available,
-creating new translators in Java would be greatly facilitated. However,
-we would probably want to introduce basic implementations of file system
-translators in the spirit of libtrivfs or libnetfs. They could take the form
-of base classes implementing the relevant MIG-generated interfaces which
-would then be derived by users,
-or could define a simpler interface
-which would then be used by adapter classes
-to implement the required ones.
-
-I would draw inspiration from libtrivfs and libnetfs
-to design and implement similar solutions for Java.
-
-### Deliverables
-
-  * A hurd-java package would contain the Java code developed
-    in the context of this project.
-  * The Java code would be documented using javadoc
-    and a tutorial for writing translators would be written as well.
-  * Modifications to MIG would be submitted upstream,
-    or a patched MIG package would be made available.
-
-The Java libraries resulting from this work,
-including any MIG support classes
-as well as the class files built from the MIG-generated code
-for the Mach and Hurd interface definition files,
-would be provided as single `hurd-java` package for
-Debian GNU/Hurd.
-This package would be separate from both Hurd and Mach,
-so as not to impose unreasonable build dependencies on them.
-
-I expect I would be able to act as its maintainer in the foreseeable future, 
-either as an individual or as a part of the Hurd team.
-Hopefully,
-my code would be claimed by the Hurd project as their own,
-and consequently the modifications to MIG
-(which would at least conceptually depend on the Mach Java package)
-could be integrated upstream.
-
-Since by design,
-the Java code would use only a small number of stable interfaces,
-it would not be subject to excessive amounts of bitrot.
-Consequently,
-maintenance would primarily consist in
-fixing bugs as they are reported,
-and adding new features as they are requested.
-A large number of such requests
-would mean the package is useful,
-so I expect that the overall amount of work
-would be correlated with the willingness of more people
-to help with maintenance
-should I become overwhelmed or get hit by a bus.
-
-
-## Timeline
-
-The dates listed are deadlines for the associated tasks.
-
-  * *Community bonding period.*
-    Discuss, refine and complete the design of the Java bindings
-    (in particular the MIG and "libports" parts)
-  * *May 23.*
-    Coding starts.
-  * *May 30.*
-    Finish implementing pthread signal semantics.
-  * *June 5.*
-    Port OpenJDK
-  * *June 12.*
-    Fix the remaining problems with GCJ and/or OpenJDK,
-    possibly port Eclipse or other big Java packages.
-  * *June 19.*
-    Create the bindings for Mach.
-  * *June 26.*
-    Work on some kind of basic Java libports
-    to handle receive rights.
-  * *July 3.*
-    Test, write some documentation and examples.
-  * *July 17 (two weeks).*
-    Add the Java target to MIG.
-  * *July 24.*
-    Test, write some documentation and examples.
-  * *August 7 (two weeks).*
-    Implement a modular libfoofs to help with translator development.
-    Try to write a basic but non-trivial translator
-    to evaluate the performance and ease of use of the result,
-    rectify any rough edges this would uncover.
-  * *August 22. (last two weeks)*
-    Polish the code and packaging,
-    finish writing the documentation.
-
-
-## Conclusion
-
-This project is arguably ambitious.
-However, I have been thinking about it for some time now
-and I'm confident I would be able to accomplish most of it.
-
-In the event multiple language bindings projects
-would be accepted,
-some work could probably be done in common.
-In particular,
-[ArneBab](http://www.bddebian.com/~hurd-web/community/weblogs/ArneBab/2011-04-06-application-pyhurd/)
-seems to favor a low-level approach for his Python bindings as I do for Java,
-and I would be happy to discuss API design and coordinate MIG changes with him.
-I would also have an extra month after the end of the GSoC period
-before I go back to school,
-which I would be able to use to finish the project
-if there is some remaining work.
-(Last year's rewrite of procfs was done during this period.)
-
-As for the project's benefits,
-I believe that good support for Java
-is a must-have for the Hurd.
-Java bindings would also further the Hurd's agenda
-of user freedom by extending this freedom to more people:
-I expect the set of developers
-who would be able to write Java code against a well-written libfoofs
-is much larger than
-those who master the intricacies of low-level systems C programming.
-From a more strategic point of view,
-this would also help recruit new contributors
-by providing an easier path to learning the inner workings of the Hurd.
-
-Further developments
-which would build on the results of this project
-include my planned [[experiment with Joe-E|objcap]]
-(which I would possibly take on as a university project next year).
-Another possibility would be to reimplement some parts
-of the Java standard library
-directly in terms of the Hurd interfaces
-instead of using the POSIX ones through glibc.
-This would possibly improve the performance
-of some Java applications (though probably not by much),
-and would otherwise be a good project
-for someone trying to get acquainted with Hurd.
-
-Overall, I believe this project would be fun, interesting and useful.
-I hope that you will share this sentiment
-and give me the opportunity to spend another summer working on Hurd.
+This page has moved [[here|java]].
 
diff --git a/user/jkoenig/java.mdwn b/user/jkoenig/java.mdwn
new file mode 100644
index 00000000..4052f455
--- /dev/null
+++ b/user/jkoenig/java.mdwn
@@ -0,0 +1,628 @@
+
+# Java for Hurd (and vice versa)
+
+Contact information:
+
+  * Full name: Jérémie Koenig
+  * Email: jk@jk.fr.eu.org
+  * IRC: jkoenig on Freenode and OFTC
+
+## Introductions
+
+I am a first year M.Sc. student
+in Computer Science at University of Strasbourg (France).
+My interests include capability-based security,
+programming languages and formal methods
+(in particular, object-capability languages and proof-carrying code).
+
+### Proposal summary
+
+This project would consist in improving Java support on Hurd.
+The first part would consist in
+fixing bugs and porting Java-related packages.
+The second part would consist in
+creating low-level Java bindings for the Hurd interfaces,
+as well as libraries to make translator development easier.
+
+### Previous involvement
+
+I started contributing to Hurd last summer,
+during which I participated to Google Summer of Code
+as a student for the Debian project.
+I worked on porting Debian-Installer to Hurd.
+This project was mostly a success,
+although we still have to use a special mirror for installation
+with a few modified packages
+and tweaked priorities
+to work around some uninstallable packages
+with Priority: standard.
+
+Shortly afterwards,
+I rewrote the procfs translator
+to fix some issues with memory leaks,
+make it more reliable,
+and improve compatibility with Linux-based tools
+such as `procps` or `htop`.
+
+Although I have not had as much time
+as I would have liked to dedicate to the Hurd
+since that time,
+I have continued to maintain the mirror in question,
+and I have started to work
+on implementing POSIX threads signal semantics in glibc.
+
+### Project-related skills and interests
+
+I have used Java mostly for university assignments.
+This includes non-trivial projects
+using threads and distributed programming frameworks
+such as Java RMI or CORBA.
+I have also used it to experiment with
+Google App Engine
+(web applications)
+and Google Web Toolkit
+(a compiler from Java to Javascript which helps with AJAX code),
+and I have some limited experience with JNI
+(the Java Native Interface, to link Java with C code).
+
+My knowledge of the Hurd and Debian GNU/Hurd is reasonable,
+as the Debian-Installer and procfs projects
+gave me the opportunity to fiddle with many parts of the system.
+
+Initially,
+I started working on this project because I wanted to use
+[Joe-E](http://code.google.com/p/joe-e/)
+(a subset of Java)
+to investigate the potential
+[[applications of object-capability languages|objcap]]
+in a Hurd context.
+I also believe that improving Java support on Hurd
+would be an important milestone.
+
+### Organisational matters
+
+I am subscribed to bug-hurd@g.o and
+I do have a permanent internet connexion.
+
+I would be able to attend the regular IRC meetings,
+and otherwise communicate with my mentor
+through any means they would prefer
+(though I expect email and IRC would be the most practical).
+Since I'm already familiar with the Hurd,
+I don't expect I would require too much time from them.
+
+My exams end on May 20 so I would be able to start coding
+right at the beginning of the GSoC period.
+Next year's term would probably begin around September 15,
+so that would not be an issue either.
+I expect I would work around 40 hours per week,
+and my waking hours would be flexible.
+
+I don't have any other plans for the summer
+and would not make any if my project were to be accepted.
+
+Full disclosure:
+I also submitted a proposal to the Jikes RVM project
+(which is a research-oriented Java Virtual Machine,
+itself written in Java)
+for implementing a new garbage collector into the MMTk subsystem.
+
+## Improve Java support
+
+### Justification
+
+Java is a popular language and platform used by many desktop and web
+applications (mostly on the server side). As a consequence, competitive Java
+support is important for any general-purpose operating system.
+Better Java support would also be a prerequisite
+for the second part of my proposal.
+
+### Current situation
+
+Java is currently supported on Hurd with the GNU Java suite:
+
+   * [GCJ](http://gcc.gnu.org/java/),
+     the GNU Compiler for Java, is part of GCC and can compile Java
+     source code to Java bytecode, and both source code and bytecode to
+     native code;
+   * libgcj is the implementation of the Java runtime which GCJ uses.
+     It is based on [GNU Classpath](http://www.gnu.org/software/classpath/).
+     It includes a bytecode interpreter which enables
+     Java applications compiled to native code to dynamically load and execute
+     Java bytecode from class files.
+   * The gij command is a wrapper around the above-mentioned virtual machine
+     functionality of libgcj and can be used as a replacement for the java
+     command.
+
+However, GCJ does not work flawlessly on Hurd.r
+For instance, some parts of libgcj relies on
+the POSIX threads signal semantics, which are not yet implemented.
+In particular, this makes ant hang waiting for child processes,
+which makes some packages fail to build on Hurd
+(“ant” is the “make” of the Java world).
+
+### Tasks
+
+   * **Finish implementing POSIX thread semantics** in glibc (high priority).
+     According to POSIX, signal dispositions should be global to a process,
+     while signal blocking masks should be thread-specific. Signals sent to the
+     process as a whole are to be delivered to any thread which does not block
+     them. By contrast, Hurd has per-thread signal dispositions and signals
+     sent to a process are delivered to the main thread only. I have been
+     working on refactoring the glibc signal code and implementing the POSIX
+     semantics as a per-thread option. However, due to lack of time I have not
+     yet been able to test and debug my code properly. Finishing this work
+     would be my first task.
+   * **Fix further problems with GCJ on Hurd** (high priority). While I’m not
+     aware of any other problems with GCJ at the moment, I suspect some might
+     turn up as I progress with the other tasks. Fixing these problems would
+     also be a high-priority task.
+   * **Port OpenJDK 6** (medium priority). While GCJ is fine, it is not yet
+     100% complete. It is also slower than OpenJDK on architectures where a
+     just-in-time compiler is available. Porting OpenJDK would therefore
+     improve Java support on Hurd in scope and quality. Besides, it would also
+     be a good way to test GCJ, which is used for bootstrapping by the Debian
+     OpenJDK packages. Also note that OpenJDK 6 is now the default Java
+     Runtime Environment on all released Linux-based Debian architectures;
+     bringing Hurd in line with this would probably be a good thing.
+   * **Port Eclipse and other Java applications** (low priority). Eclipse is a
+     popular, state-of-the-art IDE and tool suite used for Java and other
+     languages. It is a dependency of the Joe-E verifier (see part 3 of this
+     proposal). Porting Eclipse would be a good opportunity to test GCJ and
+     OpenJDK.
+
+### Deliverables
+
+  * The glibc pthreads patch and any other fixes on the Hurd side
+    would be submitted upstream
+  * Patches against Debian source packages
+    required to make them build on Hurd would be submitted
+    to the [Debian bug tracking system](http://bugs.debian.org/).
+
+
+## Create Java bindings for the Hurd interfaces
+
+### Justification
+
+Java is used for many applications and often taught to
+introduce object-oriented programming. The fact that Java is a
+garbage-collected language makes it easier to use, especially for the less
+experienced programmers. Besides, its object-oriented nature is a
+natural fit for the capability-based design of Hurd.
+The JVM is also used as a target for many other languages,
+all of which would benefit from the access provided by these bindings.
+
+Advantages over other garbage-collected, object-oriented languages include
+performance, type safety and the possibility to compile a Java translator to
+native code and
+[link it statically](http://gcc.gnu.org/wiki/Statically_linking_libgcj)
+using GCJ, should anyone want to use a
+translator written in Java for booting.
+Note that Java is
+[being](http://www.linuxjournal.com/article/8757)
+[used](http://oss.readytalk.com/avian/)
+in this manner for embedded development.
+Since GCJ can take bytecode as its input,
+this expect this possibility would apply to any JVM-based language.
+
+Java bindings would lower the bar for newcomers
+to begin experimenting with what makes Hurd unique
+without being faced right away with the complexity of
+low-level systems programming.
+
+### Tasks summary
+
+  * Implement Java bindings for Mach
+  * Implement a libports-like library for Java
+  * Modify MIG to output Java code
+  * Implement libfoofs-like Java libraries
+
+### Design principles
+
+The principles I would use to guide the design
+of these Java bindings would be the following ones:
+
+  * The system should be hooked into at a low level,
+    to ensure that Java is a "first class citizen"
+    as far as the access to the Hurd's interfaces is concerned.
+  * At the same time, the memory safety of Java should be maintained
+    and extended to Mach primitives such as port names and
+    out-of-line memory regions.
+  * Higher-level interfaces should be provided as well
+    in order to make translator development
+    as easy as possible.
+  * A minimum amount of JNI code (ie. C code) should be used.
+    Most of the system should be built using Java itself
+    on top of a few low-level primitives.
+  * Hurd objects would map to Java objects.
+  * Using the same interfaces,
+    objects corresponding to local ports would be accessed directly,
+    and remote objects would be accessed over IPC.
+
+One approach used previously to interface programming languages with the Hurd
+has been to create bindings for helper libraries such as libtrivfs. Instead,
+for Java I would like to take a lower-level approach by providing access to
+Mach primitives and extending MIG to generate Java code from the interface
+description files.
+
+This approach would be initially more involved, and would introduces several
+issues related to overcoming the "impedance mismatch" between Java and Mach.
+However, once an initial implementation is done it would be easier to maintain
+in the long run and we would be able to provide Java bindings for a large
+percentage of the Hurd’s interfaces.
+
+### Bindings for Mach system calls
+
+In this low-level approach, my intention is to enable Java code to use Mach
+system calls (in particular, mach_msg) more or less directly. This would
+ensure full access to the system from Java code, but it raises a number of
+issues:
+
+  * the Java code must be able to manipulate Mach-level entities, such as port
+    rights or page-aligned buffers mapped outside of the garbage-collected
+    heap (for out-of-line transfers);
+  * putting together IPC messages requires control of the low-level
+    representation of data.
+
+In order to address these concerns, classes would be encapsulating these
+low-level entities so that they can be referenced through normal, safe objects
+from standard Java code. Bindings for Mach system calls can then be provided
+in terms of these classes. Their implementation would use C code through the
+Java Native Interface (JNI).
+
+More specifically, this functionality would be provided by the `org.gnu.mach`
+package, which would contain at least the following classes:
+
+  * `MachPort` would encapsulate a `mach_port_t`. (Some of) its constructors
+    would act as an interface for the `mach_port_allocate()` system call.
+    `MachPort` objects would also be instantiated from other parts of the JNI
+    C code to represent port rights received through IPC. The `deallocate()`
+    method would call `mach_port_deallocate()` and replace the encapsulated
+    port name with `MACH_PORT_DEAD`. We would recommend that users call it
+    when a port is no longer used, but the finalizer would also deallocate the
+    port when the `MachPort` object is garbage collected.
+  * `Buffer` would represent a page-aligned buffer allocated outside of the
+    Java heap, to be transferred (or having been received) as out-of-line
+    memory. The JNI code would would provide methods to read and write data at
+    an arbitrary offset (but within bounds) and would use `vm_allocate()` and
+    `vm_deallocate()` in the same spirit as for `MachPort` objects.
+  * `Message` would allow Java code to put together Mach messages. The
+    constructor would allocate a `byte[]` member array of a given size.
+    Additional methods would be provided to fill in or query the information
+    in the message header and additional data items, including `MachPort` and
+    `Buffer` objects which would be translated to the corresponding port names
+    and out-of-line pointers.
+    A global map from port names to the corresponding `MachPort` object
+    would probably be needed to ensure that there is a one-to-one
+    correspondence.
+  * `Syscall` would provide static JNI methods for performing system calls not
+    covered by the above classes, such as `mach_msg()` or
+    `mach_thread_self()`.  These methods would accept or return `MachPort`,
+    `Buffer` and `Message` objects when appropriate. The associated C code
+    would access the contents of such objects directly in order to perform the
+    required unsafe operations, such as constructing `MachPort` and `Buffer`
+    objects directly from port names and C pointers.
+
+Note that careful consideration should be given to the interfaces of these
+classes to avoid “safety leaks” which would compromise the safety guarantees
+provided by Java. Potential problematic scenarios include the following
+examples:
+
+  * It must not be possible to write an integer at some position in a
+    `Message` object, and to read it back as a `MachPort` or `Buffer` object,
+    since this would allow unsafe access to arbitrary memory addresses and
+    mach port names.
+  * Providing the `mach_task_self()` system call would also provide access to
+    arbitrary addresses and ports by using the `vm_*` family of RPC operations
+    with the returned `MachPort` object. This means that the relevant task
+    operations should be provided by the `Syscall` class instead.
+
+Finally, access should be provided to the initial ports and file descriptors
+in `_hurd_ports` and provided by the `getdport()` function,
+for instance through static methods such as
+`getCRDir()`, `getCWDir()`, `getProc()`, ... in a dedicated class such as
+`org.gnu.hurd.InitPorts`.
+
+A realistic example of code based on such interfaces would be:
+
+    import org.gnu.mach.MsgType;
+    import org.gnu.mach.MachPort;
+    import org.gnu.mach.Buffer;
+    import org.gnu.mach.Message;
+    import org.gnu.mach.Syscall;
+    import org.gnu.hurd.InitPorts;
+
+    public class Hello
+    {   
+       public static main(String argv[])
+           /* Parent class for all Mach-related exceptions */
+           throws org.gnu.mach.MachException
+       {   
+           /* Allocate a reply port */
+           MachPort reply = new MachPort();
+
+           /* Allocate an out-of-line buffer */
+           Buffer data = new Buffer(MsgType.CHAR, 13);
+           data.writeString(0, "Hello, World!");
+
+           /* Craft an io_write message */
+           Message msg = new Message(1024);
+           msg.setRemotePort(InitPorts.getdport(1));
+           msg.setLocalPort(reply, Message.Type.MAKE_SEND_ONCE);
+           msg.setId(21000);
+           msg.addBuffer(data);
+
+           /* Make the call, MACH_MSG_SEND | MACH_MSG_RECEIVE */
+           Syscall.machMsg(msg, true, true, reply);
+
+           /* Extract the returned value */
+           msg.assertId(21100);
+           int retCode = msg.readInt(0);
+           int amount = msg.readInt(1);
+       }
+    }
+
+Should this paradigm prove insufficient,
+more ideas could be borrowed from the
+[`org.vmmagic`](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.151.5253&rep=rep1&type=pdf)
+package used by [Jikes RVM](http://jikesrvm.org/),
+a research Java virtual machine itself written in Java.
+
+### Generating Java stubs with MIG
+
+Once the basic machinery is in place to interface with Mach, Java programs
+have more or less equal access to the system functionality without resorting
+to more JNI code. However, as illustrated above, this access is far from
+convenient.
+
+As a solution I would modify MIG to add the option to output Java code. MIG
+would emit a Java interface, a client class able to implement the interface
+given a Mach port send right, an a server class which would be able to handle
+incoming messages. The class diagram below, although it is by no means
+complete or exempt of any problem, illustrates the general idea:
+
+[[gsoc2011_classes.png]]
+
+This structure is somewhat reminiscent of
+[Java RMI](http://en.wikipedia.org/wiki/Java_remote_method_invocation)
+or similar systems,
+which aim to provide more or less transparent access to remote objects.
+The exact way the Java code would be generated still needs to be determined,
+but basically:
+
+  * An interface, corresponding to the header files generated by MIG, would
+    enumerate the operations listed in a given .defs files. Method names would
+    be transformed to adhere to Java conventions (for instance,
+    `some_random_identifier` would become `someRandomIdentifier`).
+  * A user class, corresponding to the `*User.c` files,
+    would implement this interface by doing RPC over a given MachPort object.
+  * A server class, corresponding to `*Server.c`, would be able to handle
+    incoming messages using a user-provided implementation of the interface.
+    (Possibly, a skeleton class providing methods which would raise
+    `NotImplementedException`s would be provided as well.
+    Users would derive from this class and override the relevant methods.
+    This would allow them not to implement some operations,
+    and would avoid pre-existing code from breaking when new operations are
+    introduced.)
+
+In order to help with the implementation of servers, some kind of library
+would be needed to associate Mach receive rights with server objects and to
+handle incoming messages on dedicated threads, in the spirit of libports.
+This would probably require support for port sets at the level of the Mach
+primitives described in the previous section.
+
+When possible, operations involving the transmission of send rights
+of some kind would be expressed in terms of the MIG-generated interfaces
+instead of `MachPort` objects.
+Upon reception of a send right,
+a `FooUser` object would be created
+and associated with the corresponding `MachPort` object.
+If the received send right corresponds to a local port
+to which a server object has been associated,
+this object would be used instead.
+This way,
+subsequent operations on the received send right
+would be handled as direct method calls
+instead of going through RPC mechanisms.
+
+Some issues will still need to be solved regarding how MIG will convert
+interface description files to Java interfaces. For instance:
+
+  * `.defs` files are not explicitly associated with a type. For instance in
+    the example above, MIG would have to somehow infer that io_t corresponds
+    to `this` in the `Io` interface.
+  * More generally, a correspondence between MIG and Java types would have
+    to be determined. Ideally this would be automated and not hardcoded
+    too much.
+  * Initially, reply port parameters would be ignored. However they may be
+    needed for some applications.
+
+So the details would need to be flushed out during the community bonding
+period and as the implementation progresses. However I’m confident that a
+satisfactory solution can be designed.
+
+Using these new features, the example above could be rewritten as:
+
+    import org.gnu.hurd.InitPorts;
+    import org.gnu.hurd.Io;
+    import org.gnu.hurd.IoUser;
+
+    class Hello {
+       static void main(String argv[]) throws ...
+       {
+           Io stdout = new IoUser(InitPorts.getdport(1));
+           String hello = “Hello, World!\n”;
+
+           int amount = stdout.write(hello.getBytes(), -1);
+
+           /* (A retCode corresponding to an error
+               would be signalled as an exception.) */
+       }
+    }
+
+An example of server implementation would be:
+
+    import org.gnu.hurd.Io;
+    import java.util.Arrays;
+
+    class HelloIo implements Io {
+       final byte[] contents = “Hello, World!\n”.getBytes();
+
+       int write(byte[] data, int offset) {
+           return SOME_ERROR_CODE;
+       }
+
+       byte[] read(int offset, int amount) {
+           return Arrays.copyOfRange(contents, offset,
+                                     offset + amount - 1);
+       }
+
+       /* ... */
+    }
+
+A new server object could then be created with `new IoServer(new HelloIo())`,
+and associated with some receive right at the level of the ports management
+library.
+
+### Base classes for common types of translators
+
+Once MIG can target Java code, and a libports equivalent is available,
+creating new translators in Java would be greatly facilitated. However,
+we would probably want to introduce basic implementations of file system
+translators in the spirit of libtrivfs or libnetfs. They could take the form
+of base classes implementing the relevant MIG-generated interfaces which
+would then be derived by users,
+or could define a simpler interface
+which would then be used by adapter classes
+to implement the required ones.
+
+I would draw inspiration from libtrivfs and libnetfs
+to design and implement similar solutions for Java.
+
+### Deliverables
+
+  * A hurd-java package would contain the Java code developed
+    in the context of this project.
+  * The Java code would be documented using javadoc
+    and a tutorial for writing translators would be written as well.
+  * Modifications to MIG would be submitted upstream,
+    or a patched MIG package would be made available.
+
+The Java libraries resulting from this work,
+including any MIG support classes
+as well as the class files built from the MIG-generated code
+for the Mach and Hurd interface definition files,
+would be provided as single `hurd-java` package for
+Debian GNU/Hurd.
+This package would be separate from both Hurd and Mach,
+so as not to impose unreasonable build dependencies on them.
+
+I expect I would be able to act as its maintainer in the foreseeable future, 
+either as an individual or as a part of the Hurd team.
+Hopefully,
+my code would be claimed by the Hurd project as their own,
+and consequently the modifications to MIG
+(which would at least conceptually depend on the Mach Java package)
+could be integrated upstream.
+
+Since by design,
+the Java code would use only a small number of stable interfaces,
+it would not be subject to excessive amounts of bitrot.
+Consequently,
+maintenance would primarily consist in
+fixing bugs as they are reported,
+and adding new features as they are requested.
+A large number of such requests
+would mean the package is useful,
+so I expect that the overall amount of work
+would be correlated with the willingness of more people
+to help with maintenance
+should I become overwhelmed or get hit by a bus.
+
+
+## Timeline
+
+The dates listed are deadlines for the associated tasks.
+
+  * *Community bonding period.*
+    Discuss, refine and complete the design of the Java bindings
+    (in particular the MIG and "libports" parts)
+  * *May 23.*
+    Coding starts.
+  * *May 30.*
+    Finish implementing pthread signal semantics.
+  * *June 5.*
+    Port OpenJDK
+  * *June 12.*
+    Fix the remaining problems with GCJ and/or OpenJDK,
+    possibly port Eclipse or other big Java packages.
+  * *June 19.*
+    Create the bindings for Mach.
+  * *June 26.*
+    Work on some kind of basic Java libports
+    to handle receive rights.
+  * *July 3.*
+    Test, write some documentation and examples.
+  * *July 17 (two weeks).*
+    Add the Java target to MIG.
+  * *July 24.*
+    Test, write some documentation and examples.
+  * *August 7 (two weeks).*
+    Implement a modular libfoofs to help with translator development.
+    Try to write a basic but non-trivial translator
+    to evaluate the performance and ease of use of the result,
+    rectify any rough edges this would uncover.
+  * *August 22. (last two weeks)*
+    Polish the code and packaging,
+    finish writing the documentation.
+
+
+## Conclusion
+
+This project is arguably ambitious.
+However, I have been thinking about it for some time now
+and I'm confident I would be able to accomplish most of it.
+
+In the event multiple language bindings projects
+would be accepted,
+some work could probably be done in common.
+In particular,
+[ArneBab](http://www.bddebian.com/~hurd-web/community/weblogs/ArneBab/2011-04-06-application-pyhurd/)
+seems to favor a low-level approach for his Python bindings as I do for Java,
+and I would be happy to discuss API design and coordinate MIG changes with him.
+I would also have an extra month after the end of the GSoC period
+before I go back to school,
+which I would be able to use to finish the project
+if there is some remaining work.
+(Last year's rewrite of procfs was done during this period.)
+
+As for the project's benefits,
+I believe that good support for Java
+is a must-have for the Hurd.
+Java bindings would also further the Hurd's agenda
+of user freedom by extending this freedom to more people:
+I expect the set of developers
+who would be able to write Java code against a well-written libfoofs
+is much larger than
+those who master the intricacies of low-level systems C programming.
+From a more strategic point of view,
+this would also help recruit new contributors
+by providing an easier path to learning the inner workings of the Hurd.
+
+Further developments
+which would build on the results of this project
+include my planned [[experiment with Joe-E|objcap]]
+(which I would possibly take on as a university project next year).
+Another possibility would be to reimplement some parts
+of the Java standard library
+directly in terms of the Hurd interfaces
+instead of using the POSIX ones through glibc.
+This would possibly improve the performance
+of some Java applications (though probably not by much),
+and would otherwise be a good project
+for someone trying to get acquainted with Hurd.
+
+Overall, I believe this project would be fun, interesting and useful.
+I hope that you will share this sentiment
+and give me the opportunity to spend another summer working on Hurd.
+
diff --git a/user/jkoenig/gsoc2011_proposal/discussion.mdwn b/user/jkoenig/java/discussion.mdwn
index 0131d8d5..0131d8d5 100644
--- a/user/jkoenig/gsoc2011_proposal/discussion.mdwn
+++ b/user/jkoenig/java/discussion.mdwn