Re: about GNU Hurd

[Alfred M. Szmidt]

   >     If we are sure we need HURD-NG, it is no-sense to work in
   >     Hurd on gnumach anymore. To ask people to work in Hurd on
   >     gnumach is then to ask hackers to work in something that wont
   >     be useful.
   >
   > That's too strong a statement.  To work on a short-term version
   > and a long-term version in parallel is not absurd.  I think that
   > people do lots of work on the stable version of Linux while
   > others do work on preparing the next one.

   I don't think that is an adequate parallel, but your point is
   right. Since Hurd servers should work everywhere where Hurd does,
   there is no (or little) problem in porting existing servers from
   Hurd on GNUMach to Hurd on L4, Coyotos, SomeOtherKernel.

Both L4 and Coyotos use synchrony message passing, while Mach uses
asynchronous message passing.  The Hurd servers depend on the
functionality of async. message passing so just rewriting them to
become synchronous would be quite a big problem.  There are many other
differences between Mach, L4, Coyotos, ...  So it is not at all
trivial, and will require huge changes.

   > But the Mach-based version of the Hurd is not stable, and not
   > much in use.  If we can make it good to use, in the next year or
   > so, that will be worth while.  But perhaps not easy or not
   > feasible.

   100% agreed. That should be the first goal - to port recent Linux
   or BSD drivers to Hurd/Mach and to make GNUMach work on all (or
   most) x86-based processors.

This might work today, since Linux should have a stable API/ABI that
can be used.  Before this wasn't as easy, since one would have to
maintain a horribly glue layer for Linux (which we still do in GNU
Mach for some Linux 2.2 and 2.0 drivers).