fix merge

4 files changed, 996 insertions, 624 deletions

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