[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
design?
> > 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
microkernel?
[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
should).
> 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.
signature.asc
Description: Digital signature