GSoC report: GNU/Hurd translators

[Marek Dopiera <siersciu%gmail.com@localhost>]

Hi,
as the first half of the GSoC has passed, I present you the status of my 
project:

I have reached the stable state of the following parts:
- additional syscalls and VOPs for managing translators
- support for passive translators in ext2fs
- changes in newfs_ext2fs allowing to specify the Hurd creator OS
- changes in fsck_ext2fs to respect translators during the check and be able 
to fix potential problems related to them
- userland tools (showtrans and settrans) to manage the translators, coherent 
with the Hurd's counterparts; there are also man pages for them

This works (excluding the active translators) in the same way it works in the 
Hurd (hopefully).

The original plan included also support for ffs, but it turned out, that it 
isn't currently working in the Hurd according to this short mail exchange:
http://lists.gnu.org/archive/html/help-hurd/2008-07/msg00003.html
, so at present I've abandoned writing the support as I have no reference 
implementation.

What is left: 
- figure out how exactly the communication between relevant servers looks like 
in Hurd to be able to provide that to the translators being run on NetBSD
- find out what has to be done to be able to launch Mach binaries
- write the relevant code for the above
- if there will be enough time, write some NetBSD specific translator using 
puffs

I am planning to work on the first two points from the list simultaneously. 
The first step to achieve is to run a simple Hurd binary which doesn't use 
any IPC. The next step is to make programs able to use ports. Having done 
this and the research which servers should be emulated, I will start 
implementing the next parts of the translator API.

Various problems met so far:
- time; until 27 June I had my exam session. Fortunatelly, this problem 
doesn't exist anymore
- time consuming bugs I have made. The worst was using too much memory on the 
kernel stack during a syscall execution. It was hard, because the uvm faults 
appeared after an undefined amount of time and no reasonable stack trace was 
available
- dealing with the Hurd; administrative tasks related to it are often very 
time consuming, as it is not so mature and widely used; one example was 
forcing the Hurd to work with disklabels and ufs; finally it turned out that 
it is currently broken
- rump; launching a new process from the kernel adds some extra references in 
the code, which resulted in rump not linking. I've temporarilly overcome it 
by providing some stubs, which will have to be filled in the future 
(hopefully it won't be very hard)

You can read more about the work done so far on the web page:
http://netbsd-soc.sourceforge.net/projects/hurdt/

Regards

-- 
Marek Dopiera
marek%dopiera.pl@localhost, http://marek.dopiera.pl
JID: siersciu%jabberpl.org@localhost, GG:219418