Hacker News Reader

Comment by zouhair | Hacker News Reader

Now micro kernel doesn't seem that stupid after all?

How would it reduce the bloat mentioned in the article? Would there be somehow less code to implement the same features in a microkernel architecture?

Mot less code to implement, but it modularizes logic such that it's (theoretically) trivial to disable unneeded features. I'm sure the majority of that Linux kernel logic is never executed; if that code were instead placed in user-level processes, they would have no performance hit.

There are a lot of other side benefits. As stable as Linux is, it still has a great deal of code executing in kernel mode, which is error-prone; microkernels can restart crashed processes on-the-fly without compromising the stability of the system rather easily. Also, some of the newer microkernels have formal proofs of their security properties, which is pretty damn fascinating! (albeit they assume the underlying proof system itself is error-free, which might not be true)

As anyone who has ever run Kconfig knows, linux is already very well modularized, and disabling unneeded logic at compile time is already easy, and most of the kernel actually resides in dynloaded modules these days.

> I'm sure the majority of that Linux kernel logic is never executed; if that code were instead placed in user-level processes, they would have no performance hit.

Such code doesn't matter. Most of it is in a dynloaded module, so it doesn't even eat ram, and even the stuff baked in the kernel hardly matters for performance -- the < 5 megabytes of ram doesn't even hurt in cellphones anymore, and the thing that hurts most is L1i cache use, where only code that is actually executed goes.

The bloat we are talking about is not the increase in the total size of the kernel, but the increase of the size of the commonly executed code paths. Linux being a microkernel would not help there, in fact it would hurt.

An increase of the size of commonly executed code paths could mean two things. First, it could mean that a lot of special casing has accumulated due to lack of modularisation or cleanup work.

Or it could mean that these cases do in fact have to be considered on that code path every time and that any "outsourcing" to user mode processes would in fact increase the size of the code path.

If it's the former, then the argument that a micro kernel design encourages more fine grained modularisation and leads to fewer special cases is not completely spurious in my opinion.

But all of this is impossible to judge without looking at the code itself.

Said in a simpler way: either Linux is poorly designed, or that amount of code is necessary for a general purpose kernel.

This assumes that someone needs and actively maintains every feature in the code.

> either Linux is poorly designed

I take offense at the statement "Linux is designed" :)

Of course it is not optimal. Nothing else is either. How can we make it better?

As anyone who has ever run Kconfig knows, linux is already very well modularized, and disabling unneeded logic at compile time is already easy

Yet in the interview, Linus says the kernel is getting bigger and slower because of new features, which presumably not everybody needs. "[W]e are definitely not the streamlined, small, hyper-efficient kernel that I envisioned 15 years ago...The kernel is huge and bloated, and our icache footprint is scary. I mean, there is no question about that. And whenever we add a new feature, it only gets worse." He isn't talking about code that can be compiled out or left unloaded if you don't need it. He's talking about code that ends up in your instruction cache whether you need the features or not.

Microkernels are not superior from a technical perspective, but from a software engineering perspective.

-Monolithic kernels do not enforce modular implementations, inevitably leading to unnecessary dependencies

-Monolithic kernels need to be developed by a single party, who could not possibly manage such a large code base. The result is poorly maintained code.

-Monolithic kernels need to be recompiled to turn off features (and I have better things to do)

-Microkernels can tolerate more bugs (may be good or bad)

-probably a couple more

The Linux kernel is monolithic, yet it provably does not "need to be developed by a single party" given the Linux development model - a lot of features are added in isolation by third parties and only added to mainline when they are mature and have a userbase.

Nor does the Linux kernel need to be recompiled to turn on/off features - most features can be turned on/off via /proc or sysctl or by loading / unloading modules.

As for the unnecessary dependencies, is this a problem in real life for Linux? No. Modules tend to depend on well defined kernel interfaces.

Despite the snarky tone of your comment, you hint at an interesting point:

Unix is NOT the be-all, end-all definitive operating system. Linux is NOT even the be-all, end-all Unix (or Unix-like). There is A LOT of research left to be done in operating systems / kernels and many many years of evolution to come.

It's a shame that it is SO HARD to build the ecosystem required to launch a kernel. New ideas are hard pressed to gain traction.

You realize that OS X uses a micro-kernel, right? And that GNU Hurd is a micro-kernel too?

I wouldn't say OS X is a microkernel. Much of its codebase was built off of Mach, but much was also built off of BSD. For example, its network stack logic resides in the kernel, which is certainly not microkernel-esque. See http://en.wikipedia.org/wiki/Darwin_(operating_system)#Kerne...

"Mac OS X is sort of microkernelish. Inside, it consists of Berkeley UNIX riding on top of a modified version of the Mach microkernel. Since all of it runs in kernel mode (to get that little extra bit of performance) it is not a true microkernel, but Carnegie Mellon University had Berkeley UNIX running on Mach in user space years ago, so it probably could be done again, albeit with a small amount of performance loss, as with L4Linux. Work is underway to port the Apple BSD code (Darwin) to L4 to make it a true microkernel system." - Andy Tanenbaum

reference - http://www.cs.vu.nl/~ast/reliable-os/

I realize that. On the same note, GNU HURD isn't technically a 'micro-kernel' because GNU Mach is the micro-kernel, but my point was that 'micro-kernel' instead of 'monolithic kernal' isn't some unexplored territory that only exists as theory in CompSci textbooks.

I'm not talking about just micro- vs macro- kernel. I'm talking about general OS-level research. Just look at what MSR is doing with Singularity: http://research.microsoft.com/en-us/projects/singularity/

OS X is not a microkernel and hasn't been one since 10.0. It is a hybrid kernel called the XNU kernel. It's Mach microkernel based with some low layer BSD smothered on top.

It would be interesting to see how the original Mach microkernel runs on modern hardware. At the time, the context switching of the Mach kernel was making performance poor. But this was on 300/400 MHz machines.

Is it really so hard to gain traction? Just write a UNIX micro kernel and add a compatibility layer for Linux device drivers, then you are set.

Define "linux device driver". Doing what you ask could easily require including most of linux.

Isn't that what l4linux does? ( http://l4linux.org/ )

The exo-kernel guys tried to go a route that radically eases evolution. Normally an operating system tries to abstract and protect/multiplex.

They were writing a sort of microkernel, that only multiplexes/protects users from each other, but exported the raw hardware interface to userland. The abstracting part of the OS would be implemented as (possibly shared) shared libraries.

I'm actually (well, my friends are doing most of the work now) still writing one: http://www.xomb.org/

Interesting. I visited the wiki and will have a deeper look into it later.

Let me know if you have any questions, or feel free to jump on #xomb on freenode. We usually have a few people idling.

Launching a kernel is easy.

Making people want to use it is hard, as most apps people want are boring to write and/or trapped in the poor design decisions of the past (e.g. POSIX).

A micro kernel doesn't necessarily mean that there will be less bloat. It just means that different parts of the functionality of the kernel are split up into different programs.

But those programs have to talk to each other, and this message passing overhead increases with increased functionality (more programs). So it seems likely that there would be a definite performance drop as the functionality of a micro kernel increased.

Reply on news.ycombinator.com