HelenOS Micro-Kernel OS Still Marching On

[phoronix]

Phoronix: HelenOS Micro-Kernel OS Still Marching On

While not one of the most well known multi-server micro-kernel operating systems compared to GNU Hurd and others, HelenOS continues to move forward as a general purpose BSD-licensed operating system that dances to its own beat...

http://www.phoronix.com/vr.php?view=MTI5ODk

[Delgarde]

So what are the Hurd people doing wrong? They've been working on their project for a couple of decades now, and have very little to show for it. While HelenOS has basically evolved from a university teaching project, yet in a fraction of the time, they've produced something far more capable than the GNU effort.

[rvalles]

So what are the Hurd people doing wrong? They've been working on their project for a couple of decades now, and have very little to show for it. While HelenOS has basically evolved from a university teaching project, yet in a fraction of the time, they've produced something far more capable than the GNU effort.

I actually do not have a clue, but I do suspect it's got to do with lack of direction. HelenOS, Genode and Minix3 do have roadmaps and goals and they do follow them. In contrast, HURD seems totally lost without direction and that's lead it to being stuck, hard.

They did work on porting it to L4, which was a very correct thing to do but that work stagnated, because somebody randomly decided to go with Coyotos instead and the end result is that they're not on L4 or Coyotos, they're still on Mach, which is an anchaic academic microkernel with very bad performance by design.

If the HURD wanted to resurrect, deciding on a microkernel to adopt (either something from the L4 family or a homegrown one would be sane options) and focusing their efforts on rebasing on that would be the direction to go. They would also have to abandon the silliness of the hybrid system approach and adopt a proper pure multiserver microkernel approach, with isolation for drivers.

They don't seem to be doing any of that, so their future looks bleak. Thankfully, it doesn't matter. The three systems I listed are orders of magnitude more actively developed, are on a roadmap, use the pure microkernel approach, multiserver and with driver isolation, they mostly have support for AHCI and USB, they're not x86 only nor 32bit only and, on top of that, they are free software projects.

[Delgarde]

I actually do not have a clue, but I do suspect it's got to do with lack of direction. HelenOS, Genode and Minix3 do have roadmaps and goals and they do follow them.

True, and that's probably one big benefit from the university background - it's very project focused. Rather than developers wandering in and out working on whatever they want, you look at weak areas, and turn them into student projects.

[zanny]

I like the premise - a microkernel that only handles the processor and memory. Everything else is your problem™. You can easily provide much better security when your usb, sata, pci etc controllers are all running in userspace.

I googled around, but couldn't find any good benchmarks on how the Helen kernel with userspace drivers performance compares to a monolithic kernel. Anyone got some?

[mdecky]

I googled around, but couldn't find any good benchmarks on how the Helen kernel with userspace drivers performance compares to a monolithic kernel. Anyone got some?

We haven't done any serious performance benchmarks so far. Frankly, I believe that the results would be pretty poor (not only compared to monolithic systems, but also compared to some of the highly optimized microkernels from the L4 family). Simply because we do not focus on performance so far, we try to focus our limited manpower on the overall design and broad functionality of HelenOS.

Certainly, performance is important and we will need to focus it sooner or later. But not at this time, the day has only 24 hours

[zanny]

We haven't done any serious performance benchmarks so far. Frankly, I believe that the results would be pretty poor (not only compared to monolithic systems, but also compared to some of the highly optimized microkernels from the L4 family). Simply because we do not focus on performance so far, we try to focus our limited manpower on the overall design and broad functionality of HelenOS.

Certainly, performance is important and we will need to focus it sooner or later. But not at this time, the day has only 24 hours

I just like more fuel to fire when someone thinks you need a monolithic kernel for performance. Especially if you enable shared memory with your IPC implementation, there should be barely any long run performance degradation having userspace drivers, but the security benefits of not running arbitrary code in kernel space are massive.

[mdecky]

I just like more fuel to fire when someone thinks you need a monolithic kernel for performance. Especially if you enable shared memory with your IPC implementation, there should be barely any long run performance degradation having userspace drivers, but the security benefits of not running arbitrary code in kernel space are massive.

OK, by having said that I would expect the performance of the HelenOS IPC to be pretty poor at this very moment I never meant that the performance should be poor in principle. Quite on the contrary, I really believe that after careful optimization and with proper use the overhead can be quite minimal and act only as a reasonable price offsetting the perfect functional isolation of the user space servers in the system (compared to a "ball of mud" in a monolithic kernel). There is no free lunch

The HelenOS IPC mechanism does have an inherent support for shared memory (but if the communicating tasks don't use it properly and revert to memory copying, there is a performance hit). The HelenOS IPC mechanism is inherently asynchronous, thus providing a natural way how to empower parallelism in the code (but if the tasks revert to synchronous communication, they cannot benefit from the parallelism). There are no obvious bottlenecks in the kernel implementation of the HelenOS IPC, but there might be some hot code paths that might still benefit from some optimization tweaks.

To sum up, I am indeed strongly confident that performance should be no major issue of HelenOS once we really focus on it. But the truth is that we do not focus on it right now, respecting the motto "design first, optimize later". I have also spoken about this topic at FOSDEM 2012.

[oleid]

HelenOS indeed sounds very interesting! I'm just wondering why they don't bother to support the POSIX API. That way they'd get tons of applications for free. Together with a port of Wayland (remember - you don't need KMS to support Wayland) it would probably make a decent desktop OS.

[mdecky]

HelenOS indeed sounds very interesting! I'm just wondering why they don't bother to support the POSIX API. That way they'd get tons of applications for free. Together with a port of Wayland (remember - you don't need KMS to support Wayland) it would probably make a decent desktop OS.

We do support a subset of the POSIX API where we see it fitting. But our goal is not to be a "yet another UNIX variant" -- there are other microkernel OSes that have this goal (e.g. MINIX 3). The goal of HelenOS is to design a state-of-the-art operating system from scratch without the burden of legacy backward compatibility. There is no point (for us, the authors of HelenOS) in being a better UNIX than UNIX or a better Linux than Linux ...