Good to see multiserver microkernels back on HN. Have significant advances been made to make message passing better in modern CPUs?
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.
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.
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).
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.
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.
Check how many C++ samples exist on the Windows 10 SDK samples.
See the blog about the new Windows UI Composition engine and which languages are being used on the demos.
Then let us know where is this active encouragement you are speaking about.
C++ is being driven down the stack as the implementation language for the UWP COM layer, kernel programming, graphics and audio.
Everything else is .NET Native.
See the talks at CppCon 2016:
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.
It's those "few use cases" you are talking about that interest me.
Cedar had a GC-free, type-safe subset that used the typesystem for memory safety.
"Swift is intended as a replacement for C-based languages (C, C++, and Objective-C)."
"Swift is a successor to both the C and Objective-C languages."
https://developer.apple.com/swift/
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.
Worth noting are modern (gen2/3, L4 onwards) microkernel context switch costs.
This article has a neat table in it. Third page.
http://sigops.org/sosp/sosp13/papers/p133-elphinstone.pdf
In contrast, Linux takes whole microseconds. This should be carefully considered when thinking about multiserver architecture overhead.
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"?
It's the bit on the end that sounds a lot less noble.
In the case of seL4, they are WCET (Worst Case Execution Time). That's as "contended" as it can possibly get.
They do provide formal proof of WCET, so these numbers are solid.
[edit]
Also formal WCET analysis for various IPCs is really great and not something you can "bolt on" to a kernel not designed for it.
Specifically:
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."
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.
Unfortunately, I am not aware of a compilation of misconceptions on microkernels article that's more valuable than this one.
http://www.yodaiken.com/papers/BarabanovThesis.pdf [1997]
Well, that's not exactly a microkernel, but took lots of inspiration from microkernels.
I take it that you may be alluding to the debate between Torvalds and Tannenbaum regarding microkernels.
https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb...
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.