So, you are interested in contributing to the GNU Hurd project? Welcome! Every single contribution is very much encouraged.

There are various ways to contribute; read up on contributing to...

If someone of you is lurking around here and would like to contribute, but feels she / he could do so better under formal mentoring: please contact us, or just speak up at one of the regular IRC meetings!

We also have a list of open issues and one for more elaborate project ideas - the latter originally written for the Google Summer of Code, but not exclusively. Even just investigating open issues, without being able to fix them, can be useful, because a issue that has been tracked down often becomes obvious to address for people who know the stuff -- but these people typically don't have the time that is needed to track down the issues.

Improve GNU Hurd Running on GNU Mach

The GNU Hurd running on the GNU Mach microkernel is what is commonly meant when people are talking about GNU/Hurd systems.

This system has mostly been designed and implemented in the '90s. It works and is usable. For example, these web pages have been rendered on a GNU/Hurd system.

You can try it out for yourself: for getting access, installing Debian GNU/Hurd will probably be the easiest and most feature-complete solution. If you don't have spare hardware to use for doing so, you can also get a shell account on a public Hurd machine. Depending on the things you're going to work on (and on your internet connection), this may be an easy way of getting used to Hurd systems. Installing in a virtual machine is another possibility, see the page about running a Hurd system for the full story. In particular, running a Debian GNU/Hurd QEMU image may be a viable alternative.

Then you can either play around and eventually strive to do something useful or -- if you want -- ask us to assign something to you, depending on the skills you have and the resources you intend to invest.

Please spend some time with thinking about the items in this questionnaire.

Before you can significantly contribute to the operating system itself, you'll need to take some time to learn about the system, for example: microkernels for beginners, Mach's concepts, Hurd's concepts, the critique. Until you can understand and do the basic exercises listed there, you won't be able to significantly contribute to the Hurd.

You can also have a look at the starting guide talk.

In terms of building and hacking on software, the easiest way to avoid having to understand the whole picture from the start is install the Debian distribution, and patch over the Debian source code. Installing from upstream source is much more complexe since you would need to know which piece fits where. Building and installing patched packages is much more simple.

For more reading resources, please see these web pages, for example, Hurd documentation and Mach documentation for links to a bunch of documents.

Small hack entries

Here is a list of small hacks, which can serve as entries into the Hurd code for people who would like to dive into the code but just lack a "somewhere to begin with".

• Add UTIME_NOW and UTIME_OMIT. It is a matter of taking the BSD values, add the #defines to the proper header, and implement the support in *_S_file_utimes functions. Flávio Cruz is having a look. See also Debian bug #762677.
• cat /dev/null/ should fail with ENOTDIR, i.e. make libdiskfs's diskfs_S_dir_lookup properly pass the trailing / to translators (so that libtrivfs (which null is based on) trivfs_S_dir_lookup returns ENOTDIR). See also Debian bug #785404
• Some translators do not support fsysopts, i.e. support for the file_get_fs_options and fsys_set_options RPCs.
• Extend device_read/device_write into supporting > 2TiB disk sizes.
• Make the Hurd console's configuration use xkb layout/variant instead of keymap.
• Add a futex kernel trap to GNU Mach. This can be useful for nicer locking primitives, including inter-process primitives. vm_allocate can be used as an example in the gnumach source tree for how to add a kernel trap. GNU Savannah task #6231
• Add NX protection support to GNU Mach.
• Write a partfs translator, to which one gives a disk image, and which exposes the partitions of the disk image, using parted, and the parted-based storeio (settrans -c foos1 /hurd/storeio -T typed part:1:file:/home/samy/tmp/foo). This would be libnetfs-based.
• Write virtio drivers for KVM.
• Move the mount/umount logic from utils/{,u}mount.c into glibc.
• Fix /proc/self. Look at [glibc]/hurd/lookup-retry.c for how FS RETRY MAGICAL lookups work.
• Add a tool to trace system calls, by using gnumach's Syscall-Emulation, see http://www.gnu.org/software/hurd/gnumach-doc/Syscall-Emulation.html
• Improve our FUSE library.
• Add a relatime or lazytime option to ext2fs.
• Fix our symlink translator.
• Fix chmod on fifos: mkfifo foo ; sudo chmod g+w foo

Porting Packages

Please contact us before spending a lot of time on the following porting tasks: some work may already have been done that you can base your work upon.

For guidelines, please have a look at the dedicated porting page.

Debian GNU/Hurd

Along with the official Debian "jessie" release (but not as an official Debian release), in April 2015 the Debian GNU/Hurd team released Debian GNU/Hurd 2015. There is a goal of getting Debian GNU/Hurd into shape for a technology preview for integration as a proper Debian release candidate.

The to do list is on http://wiki.debian.org/Debian_GNU/Hurd.

The following missing packages/missing functionality block a lot of other packages, and are thus good candidates for porting, in order to increase archive coverage:

• umount functionality in busybox

Here is a list of packages that need porting.

You can also just install Debian GNU/Hurd and find what doesn't work or suit you and try to improve that.

Or, you can pick one from the list of failing packages.

Open Issues

There is a list of open issues. This list includes everything from bug reports to open-ended research questions.

Instant Development Environment

This is a very brief guide to get your development environment set up. Pester ArneBab @ irc.freenode.net on IRC if something does not work (open issue documentation)

• Install qemu-kvm via your distros packages.
• Download the qemu image: wget http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz
• Unpack it: tar xf debian-hurd.img.tar.gz
• Run it: qemu-kvm -m 512 -no-kvm-irqchip -drive cache=writeback,file=debian-hurd.img # …irq… is a currently necessary fix due to some changes in Linux. Optionally use --curses to keep your keyboard layout. If need be modprobe kvm_amd, kvm intel and kvm to get kvm support (which is much, much faster). See also: kvm FAQ.
• login as root
• apt-get update
• apt-get install -y git mercurial emacs vim
• apt-get build-dep -y hurd gnumach
• git clone git://git.sv.gnu.org/hurd/hurd.git
• git clone git://git.sv.gnu.org/hurd/gnumach.git
• git clone git://git.sv.gnu.org/hurd/incubator.git
• Get more from the repo list.
• Read the docs on these pages.
• Start hacking.
• For shutting down, use reboot, then press c in grub and issue halt (to avoid filesystem corruption). Adding --no-reboot to the qemu line should help, too.

Design / Research: GNU Hurd on a Modern Microkernel

Developers have identified a number of problem with the Hurd on Mach system. Problems, that can not easily be fixed by bug-fixing the existing code base, but which require design changes -- deep going ones actually.

As such systems (as the desired one) are not in common use, but are -- if at all -- research projects, this new Hurd on a modern microkernel project itself is more a research project than a sit down and implement/code/hack project.

If you're interested in contributing in this area, knowing the Hurd on Mach system (see above) nevertheless is a prerequisite. At least have a deep look at the documentation pointers. Also read through the HurdNG section.

Please send email to the l4-hurd mailing list for discussing this post-Mach system design.

Documentation

Technical Writer

Our hackers (programmers) typically do what their kind always does: they code. What they don't like too much is documenting their wonderful achievements. On the other hand, there are people (you?) who enjoy documenting technical matters, so don't hesitate to contact us if technical documentation shall be your contribution to GNU Hurd development.

A good start is probably to just start using the Hurd, and play with the translators. In the process you will probably find that some of the documentations are missing some details, are outdated, etc. That is were you can start contributing for instance.

As an advice: do not start yet another documentation from scratch. There are already a lot of tutorials in the wilds, and they are almost all completely outdated. Rather contribute to the existing official documentation: this wiki, the documentation in the Hurd source, the Debian Hurd port pages.

Web Pages

Please read about how to contribute to these web pages.

Final Words -- Difficulties

Please note that doing substantial contributions to a project as big and as encompassing as the GNU Hurd is not a trivial task. For working on the GNU Hurd's inner guts and getting useful work done, you have to plan for a many-months learning experience which will need sufficient self-motivation. Working on an advanced operating system kernel isn't something you can do in a few free minutes -- even less so without any previous kernel hacking experience.

Likewise, the Linux kernel maintainers are stating the exactly same difficulties, which is well presented by Jonathan Corbet in his 2010 Linux Kernel Summit report for the opening sessions about welcoming of newcomers.

But of course, none of this is meant to be dismissive, or to scare you away -- on the contrary: just start using the GNU Hurd, and either notice yourself what's not working as expected, or have a look at one of the Open Issues, and we shall see if you'll evolve to be the next core Hurd hacker! You'll just have to get excited about it!