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.

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.