HelenOS: portable microkernel-based multiserver operating system

https://utcc.utoronto.ca/~cks/space/blog/tech/AcademicMicrok...

> microkernels are small in both scope and (hopefully) code size. Small projects are achievable projects in academic research.

> a microkernel is naturally limited in functionality, so you have an excellent reason to not implement a lot of things. This drastically reduces the scope of your work and gives you a great excuse for not coding a lot of boring, routine infrastructure that's necessary for a usable system.

> (Note that in academic research you basically cannot afford to implement things that will not result in papers, because papers are your primary and in fact only important output.)

> microkernels are (strongly) modular, which makes it easier to farm out work among a bunch of students, postdocs, and research assistants. A strong division of labour is important not just for the obvious reason but because it increases the number of papers that all of the people working on the project can collectively generate. If everyone is involved in everything you probably get one monster paper with a monster author list, but if people are working mostly independently you can get a whole bunch of papers, each with a small number of authors.

> (And if someone wants to get a MSc or PhD thesis out of their work, they have to be working on their own.)

> microkernels have a minimal set of primitives, which makes it easy to write papers about them. You don't have to try to describe a large, complex OS and what makes it interesting; you can simply write a paper about the microkernel primitives you chose (and perhaps some clever way that you implemented them and made them acceptably fast).

> there are lots of choices for viable primitives and thus lots of different microkernel designs, which means that it's easy to do new work in the field; all you have to do is pick a set of primitives that no one has used yet.

> there is a strong liking for elegant minimalism in basically all parts of academic computer science. The minimalism of microkernels plays right into this overall attitude.

> the whole 'normal kernel on microkernel' idea of porting an existing OS kernel to live on top of your microkernel gives you at least the hope of creating a usable environment on your microkernel with a minimum amount of work (ie, without implementing all of a POSIX+ layer and TCP/IP networking and so on). Plus some grad student can probably get a paper out of it, which is a double win.

> the drawbacks of microkernels are mostly at the pragmatic levels of actual performance, which academics mostly don't care about and don't get called on. You can excuse relative performance figures against something like Linux or FreeBSD by saying that your microkernel has not had the kind of optimization that those OSes have had, or that the performance loss is worth it for some benefit that microkernels are supposed to give you.

> in academic computer science you do not have to actually prove any claims that your microkernel is more reliable, easier to write software for, or the like than traditional kernels. In fact it's not clear how you would prove such claims; productivity and reliability claims are notoriously hard to validate because there are so many variables involved.

Note one of these doesn't belong (hurd), as unlike everything else, it is first gen and effectively dead.

The current Minix source tree (after integrating NetBSD) doesn't resemble what's in the book much. Even Tanenbaum has commented that they perhaps went too far in pulling in so much of NetBSD.

X11 has IPC, this has performance overhead, but nobody seriously suggests that all X11 applications run in the same process.

I work regularly with a microkernel that allows threads (including device driver threads) either in their own separate address space, or in the supervisor address space. The difference in debugability between "there was memory corruption in the kernel" and "there was memory corruptoin in this specific device driver" is huge.

The throughput overhead of message passing versus not on a data-heavy driver tends to be ~20%, though just like IPC in userspace multiprocessing systems you can reduce that somewhat with shared memory, batching and other tricks if needed.

But seriously when people worry about message-passing overhead, I feel like it's 1990 again and we are debating whether the context switch overhead of processes on UNIX is worth it. I'm not sure why the userspace battle was decided so long ago while the kernel debate still goes on.

[edit]

Also sometimes the natural design for a microkernel yields better performance than the natural design for a monlithic kernel. When you are pushing the envelope for performance, sometimes some very counterintuitive things can give you benefits. I have seen cases where a single copy was faster than zero-copy, and cases where the safety of no-shared memory allowed easier parallelization of the work.

Aside from that not-entirely-reassuring "eh, it's fast enough" argument, I've seen arguments that microkernels could actually leapfrog monolithic kernels on multi-core systems, if they moved on from their obsession with single-core message passing latency. They'd no longer use the sequential dance of "enter kernel; switch processes; exit kernel; do work; enter kernel; switch back; exit kernel." Instead, they'd use "enter kernel; write message for the cache hierarchy to pass; schedule and exit kernel."

No idea how that'd turn out in practice, and it would probably involve some tradeoffs, but the idea of just entirely bypassing the whole "syscall vs message round trip" thing is appealing. Exokernels are similarly appealing, by rearranging their protection mechanisms so that things can be moved to libraries rather than server processes.