Hi, 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 while...) > 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 separation. 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. -antrik- _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
