bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A niche for the Hurd - multi-core systems


From: olafBuddenhagen
Subject: Re: A niche for the Hurd - multi-core systems
Date: Wed, 12 Nov 2008 14:18:21 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

Hi,

On Sun, Nov 02, 2008 at 03:05:07PM +0000, Matthew Ayres wrote:

> No doubt this shows my naivety, but why has GNU never built its own
> replacement for Mach?

Well, I'm not sure what you are asking exactly here. This question can
be answered in several ways...

First of all, you may not be aware that Mach was originally chosen not
because it seemed the best kernel for the intended design; but rather,
first there was the decision to build something on top of Mach, and the
Hurd design was a result of an attempt to make the best use of it.

(The decision to build on top of Mach was made in the hope that it would
be easier than creating a new kernel from scratch -- a tremendous
misjudgment as we know today. Little was know at the time about the
shortcomings of Mach specifically, or the enormous difficulty of
building general-purpose multiserver microkernel operating systems in
general -- still posing open research questions today...)

Now perhaps your question is why we do not implement our own variant of
Mach. In this case it is important to point out that we use a variant
called GNU Mach, which is essentially a fork of the original Mach. In
the beginning, when Mach was still an active research project, changes
were kept minimal, to ease merging new official Mach releases. But as
Mach is not developed upstream anymore, there is no point in that, and
bigger changes have been made over the past years.

Of course we could write our own Mach variant from scratch, but that
would be pointless really. A clean slate is alluring -- but it's always
easier in the end to start from an existing code base, no matter how old
an ugly, than starting from scratch.

(Having said that, one Hurd developer actually started x15mach as a
totally new Mach implementation from scratch -- but stopped in the
middle of it due to lack of time...)

I on my part am inclined to think that the best approach towards
modernizing Mach actually would be retracking the original Mach genesis:
Take a modern BSD kernel, throw out all UNIX stuff, and put in the Mach
stuff (IPC, external pager interface etc.) instead.

Last but not least, the question might be: why not drop Mach alltogether
and instead create a dedicated microkernel for the Hurd? Indeed after
several failed attempts with porting to existing modern microkernels
(L4, Coyotos), most of the Hurd developers seem to have arrived at the
conclusion that having a microkernel specifically tailored for the
Hurd's needs is the only viable option really. The experimental Viengoos
kernel, which Neal created in the course of his current research work,
is precisely that: an attempt to address the problems found while trying
to implement the Hurd on various existing microkernels.

I'm not sure whether it is better to introduce radical changes in
gnumach, turning it into a completely different kernel step by step; or
just move over to something entirely different in one go.

In any case, IMHO we have much more pressing issues than Mach's
shortcomings presently, and thus I don't consider work on new
microkernels the highest priority right now... (Definitely interesting
though.)

-antrik-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]