[Top][All Lists]

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

Re: Confusion about where to go in Hurd

From: olafBuddenhagen
Subject: Re: Confusion about where to go in Hurd
Date: Wed, 1 Aug 2007 18:30:20 +0200
User-agent: Mutt/1.5.16 (2007-06-11)


On Wed, Jul 25, 2007 at 09:17:49PM -0400, Michael Casadevall wrote:

> Hurdng - the project of porting hurd translators to another
> microkernel beside mach such as L4.

That is not fully correct. The original port to L4 was simply named
Hurd/L4 -- which is exactly what it was: A port of the existing Hurd
design to a different microkernel.

Later, when the original Hurd/L4 architects embraced Coyotos and
suggested a total departure from the original Hurd design (and in fact,
also from its goals...), still calling it "Hurd" no longer seemed
appropriate -- so someone came up with ngHurd. (Oddly, most others
picked that up as "Hurdng", which is ugly IMHO, and doesn't make any
sense if you spell out the "Hurd" acronym...)

Althogh it got muddled down later on, I think it is important to
distinguish between the traditional Hurd, be it on Mach or ported to
some other microkernel; or some kind of ngHurd, with a fundamentally
different design.

> Mach itself is actually pretty much feature complete and fairly
> stable. An older version (mach3 vs. mach4) provides the kernel of Mac
> OS X. The main reason parts of Hurd are slow and such is that code in
> the translators (such as the pager code in ext2fs) haven't been
> optimized.

Well, that is only partially true: Nobody has ever really profiled it;
but my guess is that the slowness of disk I/O is indeed caused by lack
of optimisation in some Hurd components. Yet once these worst problems
are fixed, I'm pretty sure that slowness of Mach IPC would immediately
take the place as the main source of system slowness...

> (I've only had one true kernel panic in serveral months of running
> Hurd in a VM (on an experimental kernel); When the system seems to
> freeze completely, it usually is a deadlock or translator issue

Indeed, most hangs nowadays seem to be caused by some locking issues in
ext2 or diskfs. (Though personally I haven't experienced any in a

> That being said, device drivers are handled by the microkernel under
> Hurd. The best way to explain this is that Hurd ran on L4 and mach,
> and L4 supported device A and mach supported A and B, the translators
> would be able to use whatever the underlying kernel supported.

That's not true. While Mach has all the drivers in kernel space, and
it's not clear whether trying to change that would result in any
success, L4 is clearly designed for user space drivers; putting them in
the kernel is totally out of question here.

> The problem with mach is that it is a first-generation microkernel.
> mach3 had problems with translators taking a very long time due to
> performance and IPC issues, but mach4 (which was the basis of GNU
> mach) worked around the issue with providing co-location (a mechanism
> where translators go right into kernel space) and shuffling which,
> while not completely solving the problem, they reduce it considerably
> to the point its more or less a non-issue in current releases.

Well, co-location basically means putting everything back in kernel
space -- the components are only formally separated, but they all run in
the same protection domain. While this might be OK for NeXTstep/MacOS X,
which aren't true microkernel systems anyways, it's not an option for a
true microkernel system like the Hurd, which actually relies on the

Also, I don't think co-location buys that much performance. The time
used for actually switching between user space and kernel space is
neglectible compared to the overhead of the IPC code in Mach.

>> By the way, from the name, a microkernel seems to be something easy
>> to write. Could somebody please outline to me (and others with my
>> knowledge of the field) why this isn't the case? I suspect that it
>> isn't so much about actually writing the thing, but more about
>> knowing what it is that one wants to write?
> The problem steams from the fact that very few programmers have the
> low level knowledge to write a program that can run from boot to
> provide a real userland.

No, that's not really the problem. While the knowledge about these
things is not very widespread, the actual implementation is pretty
straightforward stuff. What is not straightforward are the fundamental
design decisions.

>> Which Alfred also mentioned in that the ams-branch -- in his opinion
>> -- didn't get any effect upstream.
> That is in regards to glibc;

No, ams-branch is in the main Hurd repository.


reply via email to

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