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.
Attachment:
signature.asc
Description: Digital signature