> 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.
I mean, I didn't mean it that bad. It might be useful to actually try to implement something on an uncomplete system; and many useful things started as a research projects....
But well, on MFF UK, everyone kind of knows HelenOS is mostly a thesis-making toy OS. It exists for 15 years now and it's still that - a toy OS
(I don't know much about its internals, I was in a different section of the faculty)
edit: just look at all the theses that were made out of it. :)
http://webcache.googleusercontent.com/search?q=cache:geWe63M...