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...
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.
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.
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.
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.
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.
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 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.s; it was not to simply provide a Mach on top of L4. When I left Karlsruhe, I no longer had access to as I was unwilling to sign an NDA. Although the specification was available, the Karlsruhe group only
Development of Hurd/L4 was done in the CVS module
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.
As of 2005, development of Hurd/L4 has stopped.
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.)
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.
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.