Redesigning the Hurd form scartch? (was: Re: Mach emulation)

[Farid Hajji]

> If this is to make sense, hurd needs to be retargeted directly to L4,
> not some encapsulation of L4. Essentially, hurd will have to be
> directed towards L4 abstractions, rather then Mach abstractions.
Why not redesign/reimplement the Hurd from scratch in a bottom up
manner, building the new libmom along the way? I'm basically suggesting
that we forget about the current implementation/code and rethink the
basic Hurd interfaces and -functions. Most of them _are_ generic
enough to run on top of a new libmon-{l4,mach,guestos,...} and they
could IMO be reimplemented (mostly) independently of each other.
The modular nature of the Hurd is also an advantage here.

[Please don't misunderstand me: I'm _not_ writing against the Hurd
 hackers here. Their code was necessary to implement the Hurd on top
 of Mach and they've done a great job at it. I'm just suggesting to
 generalize it by way of a complete rewrite.]

We could start with some simple servers (say auth, proc) and their
associated libraries. Such servers should be able to run on a non-mach
environment without much hassle. They basically require IPC and threads,
the rest being relatively easy to provide. Other servers that come to
mind are filesystem translators like ext2fs and ufs. They too could run on
top of an existing guestos, using raw partitions through generic
read(2)/write(2)/... posix calls (that will have to be added to libmom).
Their associated libraries could also be mostly rewritten in a vastly
mach-independent way.

This approach is IMHO promising for at least the following reasons:

 * We will indentify the most important parts of the new libmom interface
   along the way, without risking much. Porting only auth and proc
   will teach us most of what we need to know about libmom requirements.

 * Each server and associated library can be tested independently
   of the others in a guest-os (and may even be _used_ for real work
   that was never intended for the Hurd), as well as with a partial
   port of libmom-{l4,mach,whatever}. We don't have to port everything
   before seeing any results. The more servers we reimplement, the
   better they can be tested together.

 * The design of the basic servers could be optimized w.r.t. the number
   of needed threads. If we drop the current code, we're free to
   experiment with whatever design we choose, as long as we stick
   to the external interfaces [which should btw. also be cleaned from
   mach specifics]. I'd even suggest to use a pool of threads for
   most servers, the size of which could be passed at the command-line.
   This way, such servers would be able to run with many LWPs on Mach
   and with a limited number of LWPs on L4 (they'd use the libmom
   notion of threads anyway, which is free to multiplex on specific
   platforms).

 * We could get rid of unnecessary complex parts like libports, that
   may be needed (and useful) in a Mach environment, but that really
   belongs in the bottom-half of libmon-mach. If we really want to get
   most out of L4, we should keep the IPC overhead to a bare minimum.
   If this requires redesigning the servers/libraries (just an idea:
   let's think about a generic state-keeper and capabilities server),
   the better (IMO).

 * We can get more portability for the Hurd, if we recode everything
   independently of glibc. Why not restrict ourselves to POSIX libc,
   leaving more specific parts to specialized libraries? This way, we
   would be able to
    1) _port_ the Hurd without having to port glibc at the same time,
    2) _use_ the Hurd on POSIX compatible systems (by using a portable
       libmom-posix library), be they using glibc or some other POSIX
       compliant libc,
    3) use whatever development environment we want.

> If this project is getting serious I might be able to get one or two
> of my students to help...
Help is always welcome! We are currently brainstorming about ways
how to do a port in a very general way, hoping to better understand
what is needed for this. The more feed-back and help we get, the
better!

Porting or reimplementing the Hurd on top of a yet to be defined
libmom-{l4,mach,guest-os,...} requires thinking about general
design and portability issues in general and would be of great
instructional value (not only) to students.

> Gernot Heiser                ,--_|\   School of Computer Sci. & Engin.
> Phone:  +61 2 9385 5156     /      \  The University of NSW
> Fax:    +61 2 9385 5533     \_,--._*  UNSW SYDNEY NSW 2052, Australia
> E-mail: address@hidden        v   http://www.cse.unsw.edu.au/~gernot

Regards,

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.