> 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)
[0] Minix 3: still around, great resource for learning, especially since there is a great book about it by Tanenbaum himself. Btw: it utilizes NetBSD's pkgsrc infrastructure, so quite a lot of applications should run
[1] RedoxOS: effort to create a unix-like microkernel OS using the Rust programming language, pretty interesting. Hope it win gain some traction, the idea itself is neat
[2] QNX: RIM/Blackberry's proprietary RTOS used in embedded systems (for example cars), also BlackberryOS is based on QNX
[3] GNU/Hurd: not sure how much software runs on it, the "most usable" form is probably trying to run the Debian GNU/Hurd distribution
It has about 0 developers on any given time, with the occassional work being done. There's been no real (fundamental) progress on it for over a decade. The issues in the hurd critique paper haven't been addressed. The L4 port failed.
Without knowing much, GNU Hurd has been in development for ages, yet is pretty far behind everything else out there in terms of usability. I think it is still active (remember a recent HN post), but it's progress is seen as being slow.
> Minix 3: still around, great resource for learning, especially since there is a great book about it by Tanenbaum himself. Btw: it utilizes NetBSD's pkgsrc infrastructure, so quite a lot of applications should run
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.
There are, and always will be, performance disadvantages to a microkernel. However, for many many tasks the difference is negligible.
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.
+1 on single-copy frequently being faster than zero-copy. See https://lwn.net/Articles/580194/ for a real-world example from the Linux kernel.
On the topic at large, I think microkernel vs monolithic is not actually the important distinction in kernel design; robustness could improved vastly if the business logic of a kernel were implemented in a memory-safe language instead of C or C++. Register bashing and system setup won't ever be effectively captured by a typesystem (knowing what the semantics of hardware are is the hard problem, and GIGO applies to typesystems as much as anything), but most vulnerabilities are in code that doesn't directly interact with hardware (even if they're in a driver for some obscure hardware, it's generally the syscall-facing side that gets exploited).
I'd like to see more OS development look at non-UNIX designs, rather than trying a million different ways to implementa UNIX-like interface.
Also, as a note, high-reliability microkernels disallow direct access to DMA registers (as, absent an I/O MMU, being able to write to a DMA register is the same as being able to write to any physical memory), and instead provide an API for programming them that can be verified on its own. This is often just dozens of lines of code, so can be as correct as the hardware.
So the separation of register-bashing vs. the rest of the software already exists, but it solves the memory safety problem by just moving the unsafe code out of the kernel.
I agree that memory-safe languages need to come into low-level systems programming, but garbage-collection is a non-starter for many many reasons, and the various academic languages (e.g. cyclone) have not made any inroads to industry that I'm aware of.
Rust is very interesting to me in this field because the simple fact that it originated outside of academia may make it more palatable to many people; time will tell.
[edit]
I still think a microkernel is a good idea even with a memory-safe language just for defense in depth if nothing else (memory-safe runtimes tend to be complicated, and complicated code tends to have bugs).
> I agree that memory-safe languages need to come into low-level systems programming, but garbage-collection is a non-starter for many many reasons, and the various academic languages (e.g. cyclone) have not made any inroads to industry that I'm aware of.
Yet it was proven to work with:
- Mesa/Cedar at Xerox PARC
- Oberon, Oberon-2, Active Oberon at ETHZ
- Modula-2+, Modula-3 at DEC/Olivetti
- Sing# and System C# at MSR
Apparently we can only get it properly done if a big company bullies the developers to adopt such an approach.
Which is why I see as positive Apple, Google, Microsoft bullying devs to use mostly Swift, Java/Kotlin/Dart and .NET on their platforms, with C and C++'s role reduced to a few use cases.
It really annoys me when I need to use the NDK on Google's case, but somehow it makes sense from security point of view.
> Which is why I see as positive Apple, Google, Microsoft bullying devs to use mostly Swift, Java/Kotlin/Dart and .NET on their platforms, with C and C++'s role reduced to a few use cases.
Microsoft is actively encouraging developers to use C++ for development on Windows. The phase when Microsoft was trying to push (or as you call it "bully") developers into ".net for everything" is long gone.
Since October 2016 there is radio silence on the actual state of C++/WinRT, including the status of feature parity with C++/CX for XAML, Blend and creation of UWP components.
VS 2017 already had two releases since those presentations.
The only Microsoft talk at CppCon 2017 are about VS Code support for C++ and ANSI C++ compliance, nothing relevant to actual Windows 10 application development.
Any long time Windows developer is recognising the signs that UWP is turning into what Longhorn aspired to be, just remains to be seen how willing Microsoft is to keep pushing it.
So while Swift might not be yet there, if Apple tomorrow releases a system that according to those statements, the only available SDK language is Swift, anyone that wants to be on that system will use Swift, regardless how serious challenger it might be.
As another example, are you aware that Brillo was supposed to be a pure C++ based variant of Android, before they pivoted it into Android Things? Now you can even write user space device drivers in Java.
Microsoft has also adding been adding low level features of System C# into C# roadmap, and UWP model (which they really want to be the future) only uses .NET Native. How far they will push it, who knows.
Windows 10 has a new UI composition engine, naturally it is programmed in DirectX with C++, however all the APIs are exposed as UWP projections and so far, every single demo I have seen used C#.
The big difference between OS companies and the FOSS world regarding systems programming, is that regardless how we think a given language is fitted for a given purpose, they can make it into the only door to the system.
But you are right they are clearly not yet there, and it remains to be seen how far they would actually bully devs into using only those languages.
I'm guessing those are uncontended timings. I haven't been able to think of a good way to do it, but I'd like to see contended timings compared as well. Having a fast fast-path is great for many reasons (a fast fast-path will reduce contention all on its own, and systems can be designed to minimize contention), but the contended case can be much slower on some microkernels, and I have no idea what the overhead is on linux.
This is interesting. I wonder what's keeping this kind of work from being mainlined.
The present (as shown in the slides) Linux context switch times are painfully long.
Unless I'm mistaken, Google isn't interested in upstreaming these changes. A quick search of lmkl.org doesn't show any hits for the switchto_... APIs.
I'd love to hear otherwise or in more detail from someone at Google. It's frustrating to have to do archaeology just to guess what the state of the art is. Isn't sharing your findings part of "organizing the world's information"?
wow; that's a good example of why GLP v3 has value to end users of free software: the GPL2 allows them not to share improvements. The GPL3 requires the source code to be available, if those machines are used to serve results to users.
Bernard Blackham, Yao Shi, Sudipta Chattopadhyay, Abhik Roychoudhury and Gernot Heiser
Timing analysis of a protected operating system kernel
IEEE Real-Time Systems Symposium, pp. 339-348, Vienna, Austria, November, 2011
---
TL;DR: They assume worst case for cache misses.
e.g.: "The latency of a read or write to physical memory on this platform was measured to be 80–100 cycles; in the static analysis we assume a 100-cycle penalty for all cache misses."
Message passing performance is a bit of a red herring. Performance has been within a few percent of monolithic kernels for a long time. More importantly, message passing is already in widespread use for things like virtualization or userspace IPC anyway.
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.
> It strikes me that anti-microkernel sentiment most vocally originates as a sort of tribal affiliation mechanism by Linux users to ward off insecurity.
I think the post would be a better reference and stand a greater chance of correcting common misconceptions if it didn't include so many ad-hominem attacks against those who don't agree with the post's author. As-is, it just appears to be a continuation of a long-running flame-war.
It seems pretty trivial: every hypervisor and/or virtualized system is running a type of microkernel. If it's fast enough for the cloud, it's fast enough period.
The first PowerPC linux for the Power Mac ran under the Mach microkernel [1].
Then there was also L4Linux, which I believe was the first low-overhead virtualization of Linux using the L4 microkernel. Papers demonstrated < 10% overhead I believe, where previous virtualization efforts were somewhat higher. I'd say it kicked off the whole paravirtualization/virtualization craze.
Slightly OT, general microkernel question: Is it possible to viably do zero-copy message-passing?
As in, the kernel lets you know you have a new message, but the message buffer is the same one the calling/sending process built.
The main thing I wonder about is security. Maybe the memory manager could allow only the sending process to write to the memory region containing the message! Or maybe that would be really hard to get right.
Once refcounting declares that only the sender has an active lock on the message, it could be deleted.
Sure see e.g pony-lang. Reference capabilities guarantee all three safeties, even with shared memory. You just aren't allowed to do much with it, depending on ownership.
Sure. They're not really called Beowulf clusters anymore, but even at the beginning there wasn't any particular defining characteristic other than a cluster of commodity servers running some kind of software that made them work together. You could consider the clusters at LHC, the render farms at Weta and Pixar, and (if you squint) the non-web clusters at Google and Facebook to all be spiritual descendants of the original Beowulf cluster.
Huh. I always thought that Beowulf was an actual piece of software. But apparently it's only a capability set, and by its definition every Mesos and Kubernetes installation counts. Cool.
>"... the non-web clusters at Google and Facebook to all be spiritual descendants of the original Beowulf cluster."
I was intrigued by this comment. Could you elaborate on this? Are there specific concepts from Beowulf that FB's Tupperware and Google's Borg borrowed?
The entirety of the Beowulf concept is a cluster of commodity machines networked together that can work together to perform some kind of task. It's pretty general. The original Beowulf-style clusters ran things like mosix to present a single system image for applications but as far as I can tell that was never a defining characteristic.
This shows a pet peeve of mine: the Raspberry Pi does not have USB available in a way which would allow a HAT to interface with it in a more sensible way than wrapping around a cable from the "external" ports.
I wonder if there is a pair of 90 degree USB connectors which would height-match a standard .1" header.
I'd love to see a revision/extension of the Pi connector adding the Ethernet signalling. This would make it easy to build clusters using any board compatible with the ecosystem. The SOPINE (a Pine A64 cousin https://www.pine64.org/?page_id=1491) seems to have the Ethernet signals on the edge connector, making a cluster much easier to build out of a single backplane. The Rock64, an A64 successor, has the Ethernet on pins, but the position is a bit awkward.
But yes. At least the USB should be available on the expansion bus.
edit: just look at all the theses that were made out of it. :)
http://webcache.googleusercontent.com/search?q=cache:geWe63M...