The Hurd: GNU's quest for the perfect kernel [LWN.net]

The Hurd: GNU's quest for the perfect kernel

Posted Jul 10, 2010 20:32 UTC (Sat) by marcH (subscriber, #57642)
Parent article: The Hurd: GNU's quest for the perfect kernel

Very informative article, thanks.

So Hurd is not vaporware but runs. Does it actually demonstrate the benefits of a micro-kernel approach? First and foremost, can you crash a driver under development without rebooting the whole system?

Does it also demonstrate this IPC overhead micro-kernels are often blamed for?

(Log in to post comments)

The Hurd: GNU's quest for the perfect kernel

Posted Jul 13, 2010 23:14 UTC (Tue) by DOT (subscriber, #58786) [Link]

"Does it also demonstrate this IPC overhead micro-kernels are often blamed for?"

That's what I'd like to know too. During a class on operating systems, the lecturer told us that IPC overhead is not much of an issue on hardware that's not utterly ancient. I'd like to see proof of that though, because IPC overhead is always brought up in articles about microkernels. With a functional Hurd, Minix and Symbian, there are enough free competitors for a nice comparison with Linux.

The Hurd: GNU's quest for the perfect kernel

Posted Jul 18, 2010 10:17 UTC (Sun) by oak (subscriber, #2786) [Link]

> can you crash a driver under development without rebooting the whole system?

Are you asking in theory or in practice? Latter depends a lot on the implementation and whether it's a HW driver or just a pure SW driver. :-)

The Hurd distro page had at least this comment:
"You can run several instances of the Hurd in parallel, and debug even critical servers in one Hurd instance with gdb running on another Hurd instance."

(Debugging doesn't succeed if you're single stepping through critical system service, therefore debugger needs to run elsewhere.)

> Does it also demonstrate this IPC overhead micro-kernels are often blamed for?

There was this comment from user (in 2009):
"while X does work, it works very poorly -- it's not only slow and jerky all the time, but also tends to lock up completely."

But I assume the slowness is partly because of missing shared memory:
"Although the POSIX interface is provided, some additional interfaces like POSIX shared memory or semaphores are still under development."

And of course it being a development kernel; not a finished, mature and well optimized one.

Based on the referenced Hurd article and e.g. these Wikipedia articles on Mach + L4 and its derivatives which take into account things not taken into account in Mach design (perforamance, resource handling, security):
http://en.wikipedia.org/wiki/Mach_(kernel)#Second-generation_microkernels
http://en.wikipedia.org/wiki/L4_microkernel_family#History

I would say that Mach derived stuff seems better to move to newer microkernel generation to be able to be relevant to real users (or researchers).

OSX is also partially Mach based, but it's a hybrid, not a pure microkernel:
http://en.wikipedia.org/wiki/XNU