It is a frequently asked question, which microkernel the Hurd should be based upon assuming that Mach is no longer considered state of the art, and it is well known that there has been a lot of discussion about this topic, and also some code produced, but then, years later, the Hurd is still based on GNU Mach.

At first, there was an effort to directly port the Hurd to the L4 microkernel family. Then the story continued...

L4

Initial Idea

Encountering a number of fundamental design issues with the Mach microkernel (mostly regarding resource management), some of the Hurd developers began experimenting with using other microkernels for the Hurd around the turn of the millenium.

The idea of using L4 as a microkernel for a Hurd system was initially voiced in the community by Okuji Yoshinori, who, for discussing this purpose, created the l4-hurd mailing list in November 2000.

Over the years, a lot of discussion have been held on this mailing list, which today is still the right place for next-generation Hurd discussions.

Why?

Even though that said resource management issues constitute a broad research topic, there was no hope that the original Mach project would work on these: Mach wasn't maintained by its original authors anymore. Mach had served its purpose as a research vehicle, and has been retired by its stakeholders.

Thus, switching to a well-maintained current microkernel was expected to yield a more solid foundation for a Hurd system than the decaying Mach design and implementation was able to.

At that time, the L4 microkernel family was one obvious choice. Being a second-generation microkernel, it was deemed to provide for a faster system kernel implementation, especially in the time-critical IPC paths. Also, as L4 was already implemented for a bunch of different architectures (x86, Alpha, MIPS; also including SMP support), and the Hurd itself being rather archtecture-agnostic, it was expected to be able to easily support more platforms than with the existing system.

Steps and Goals

At the same time, the idea was -- while mucking with the system's core anyway -- to improve on some fundamental design issues, too -- like the resource management problems, for example.

One goal of porting the Hurd to L4 was to make the Hurd independent of Mach interfaces, to make it somewhat microkernel-agnostic.

One idea was to first introduce a Mach-on-L4 emulation layer, to easily get a usable (though slow) Hurd-using-Mach-interfaces-on-L4 system, and then gradually move the Hurd servers to use L4 intefaces rather than Mach ones.

A design upon the lean L4 kernel would finally have made it feasible to move devices drivers out of the kernel's TCB.

Implementation

The project itself then was mostly lead by Marcus Brinkmann and Neal Walfield. Neal started the original Hurd/L4 port while visiting Karlsruhe university in 2002. He explains:

My intention was to adapt the Hurd to exploit L4's concepts and intended ?design patterns; it was not to simply provide a Mach ?compatibility layer on top of L4. When I left Karlsruhe, I no longer had access to ?Pistachio as I was unwilling to sign an NDA. Although the specification was available, the Karlsruhe group only released their code in May 2003. Around this time, Marcus began hacking on Pistachio. He created a relatively complete run-time. I didn't really become involved again until the second half of 2004, after I complete by Bachelors degree.

Development of Hurd/L4 was done in the CVS module hurd-l4. The doc directory contains a design document that is worth reading for anyone who wishes to learn more about Hurd/L4.

Even though there was progress -- see, for example, the QEMU image for L4 -- this port never reached a releasable state. Simple POSIX programs, such as banner could run, but for more complex system interfaces, a lot more work was needed.

Eventually, a straight-forward port of the original Hurd's design wasn't deemed feasible anymore by the developers, partly due to them not cosidering L4 suitable for implementing a general-purpose operating system on top of it, and because of deficiencies in the original Hurd's design, which they discovered along their way. Neal goes on:

Before Marcus and I considered Coyotos, we had already rejected some parts of the Hurd's design. The resource management problems were what prompted me to look at L4. Also, some of the problems with translators were already well-known to us. (For a more detailed description of the problems we have identified, see our critique in the 2007 July's SIGOPS OSR. We have also written a forward-looking position paper.)

We visited Jonathan Shapiro at Hopkins in January 2006. This resulted in a number of discussions, some quite influential, and not always in a way which aligned our position with that of Jonathan's. This was particularly true of a number of security issues.

A lange number of discussion threads can be found in the archives of the l4-hurd mailing list.

Hurd-NG, as we originally called it, was an attempt to articulate the system that we had come to envision in terms of interfaces and description of the system's structure. The new name was selected, if I recall correctly, as it clearly wasn't the Hurd nor the Hurd based on L4.

Termination

As of 2005, development of Hurd/L4 has stopped.

Coyotos

Following that, an attempt was started to use the kernel of the Coyotos system. As Coyotos is an object-capability system througout, the microkernel would obviously be more suitable for this purpose; and it looked pretty promising in the beginning. However, further investigations found that there are some very fundamental philosophical differences between the Coyotos and Hurd designs; and thus this this attempt was also abandonned, around 2006 / 2007. (This time before producing any actual code.)

Viengoos

By now (that is, after 2006), there were some new L4 variants available, which added protected IPC paths and other features necessary for object-capability systems; so it might be possible to implement the Hurd on top of these. However, by that time the developers concluded that microkernel design and system design are interconnected in very intricate ways, and thus trying to use a third-party microkernel will always result in trouble. So Neal Walfield created the experimental Viengoos kernel instead -- based on the experience from the previous experiments with L4 and Coyotos -- for his research on resource management. Currently he works in another research area though, and thus Viengoos is on hold.

Intermediate Results

Note that while none of the microkernel work is active now, the previous experiments already yielded a lot of experience, which will be very useful in the further development / improvement of the mainline (Mach-based) Hurd implementation.