[Top][All Lists]

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

Re: Confusion about where to go in Hurd

From: Anders Breindahl
Subject: Re: Confusion about where to go in Hurd
Date: Thu, 26 Jul 2007 13:33:12 +0200
User-agent: Mutt/1.5.16 (2007-06-11)

On 200707252117, Michael Casadevall wrote:
> First, I think its very important to clarify the terms Hurd and mach
> Mach - the underlying microkernel used by all versions of Hurd
> Hurd - the userland translators which snap into the kernel providing 
> userland services, and (in theory) are microkernel independent
> Hurdng - the project of porting hurd translators to another microkernel 
> beside mach such as L4.

Thanks for clarifying. For myself, those terms weren't a problem,
though. The clarification about userland drivers being nothing like
userland translators was however needed.

> 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.

I recall something about fork()s being expensive on the Hurd/Mach, and
that someone ran tests that showed 500forks per second versus a somewhat
larger figure on Linux. Is that speed also a question of optimization,
or does it have anything to do with inherent problems of the microkernel

> > I have come to understand that key individuals within the Hurd community
> > are less than satisfied with patching up Mach. And with good reason. But
> > also that there is a despair of heirs to Mach. Nothing adequate with a
> > usable license seems available, right?
> 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.

That's saying Mach is adequate, right?

If so, what actually is the problem with Mach being a first-generation

[Embedded systems:]
> and writing a kernel is not an easy task (I've never tried it; the most I 
> did was write single-use programs for use on said board).

Coincidentally, me too.

> > This should also lessen fear of performance issues with the Hurd. Linux
> > already is big enough to have a certain umph in hardware design, and if
> > stability-, scalability- and maintainability-oriented users start to use
> > Hurd, support from the chip vendors will probably catch up. (Like it
> > does with hardware virtualization technologies, these days).
> >
> It took many, many years for this to happen to Linux. I doubt we'll be 
> seeing this for hurd anytime soon. 

But that doesn't influence that it could happen (and by business logic

> I'm not sure how to help the issues, but on these lists, everyone 
> are equals to me (which hopefully I prove by spending over 2 hours 
> drafting this response :-)).

Thanks for taking the time.

Regards, skrewz.

Attachment: signature.asc
Description: Digital signature

reply via email to

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