Well, what are we missing if networking, file systems and human IO are now run as user space servers? Process management? Graphics (ignoring X)? What low-level hardware interaction can't be done microkernel style?
It's a bad analogy unless the button makes the bus change Transformers style into a completely different car.
Your "userspace filesystem implementation" is still entirely dependent on the giant VFS layer of the kernel. The situation is similar for networking. And a large portion of human I/O still depends on a very large kernel surface as well. That's not even beginning to touch on pretty much all things related to virtual memory.
Just because you've delegated some small parts into userspace, does not mean that you don't still have a massive monolithic kernel with metric tons of infrastructure and subsystems all running in the same kernel address space, oftentimes not even as dedicated threads.
A monolithic kernel is a tiny kernel that does not do much more than message passing. Linux is very far away from that, your "userspace servers" for FUSE and similar things are better called "delegates" for subsystems that still reside in the kernel itself.
> It's a bad analogy unless the button makes the bus change Transformers style into a completely different car.
> Just because you've delegated some small parts into userspace, does not mean that you don't still have a massive monolithic kernel with metric tons of infrastructure and subsystems all running in the same kernel address space, oftentimes not even as dedicated threads.
That's up to you to keep around. No need to compile in subsystems and drivers you don't need. HID is pushed userspace by HID-BPF and it works great. USB, I2C, SPI can all be handled by direct messages to the device.
These objections are pedantry around what exactly is micro about a microkernel. UIO lets you drive any hardware via userspace memory maps, it's just usually easier to slap it into a pre-built kernel subsystem more than any need for code to be in kernel mode.
> A monolithic [sic] kernel is a tiny kernel that does not do much more than message passing. Linux is very far away from that, your "userspace servers" for FUSE and similar things are better called "delegates" for subsystems that still reside in the kernel itself.
Your message passing is my delegation through, say, netlink. Perhaps you are describing an exokernel concept where only the barest minimum is run in kernel mode? Mach runs a lot more in kernel mode than necessary, even L4 isn't a "true" microkernel if you are ultra-pedantic and run on processors with, say, userspace interrupts.
I am not familiar with this project. It looks to be a VFS-like framework for userspace? If so, I don't see how that changes the nature of a kernel. I can implement any amount of kernel-like features on top of any operating system, provided I have Turing completeness.
By that argument, I can take pre-NT enhanced mode Windows, arguably one of the least microkernel kernels there is (AFAIK it even has large part of its UI system running in kernel space), run an L4 kernel within it as a userspace application, and declare that "Windows 3.11 is now a microkernel"?
As long as this SPDK thing does not rid me of VFS, it's just adding stuff in userspace?
> That's up to you to keep around. No need to compile in subsystems and drivers you don't need.
I genuinely did not follow Linux kernel development for quite a long time (as opposed to other OSes, like OpenBSD for example). Are you saying that nowadays (or maybe back then even), I can compile out VFS, the POSIX layer, the VM layer, kernel memory allocators?
If so, that's indeed a big step towards microkernel-ness!
> These objections are pedantry around what exactly is micro about a microkernel.
You're saying I'm pedantic about what is a microkernel, I'm saying your definition of "microkernel" seems surprisingly broad, and question the merit of the term under that definition.
According to you, where does a microkernel stop, and a monolithic kernel start, then?
> Your message passing is my delegation through, say, netlink.
netlink is not only one of many communication paths in Linux, it isn't even a raw message passing mechanism in the microkernel sense! It's built on top of POSIX and the socket layer, which are surfaced through many individual system calls into the kernel, and whose implementation is a pretty thick sandwich to get down to the actual mechanism that passes the message, i.e. that implements how the actual data is made available from one address space to another (zero-copy or not).
This is the actual low level mechanism, on top of which POSIX and pretty much everything else is built, outside of the microkernel. So it's actually quite the opposite of netlink!
> Perhaps you are describing an exokernel concept where only the barest minimum is run in kernel mode?
Liedtke's Minimality Principle states: "A concept is tolerated inside the microkernel only if moving it outside the kernel, i.e., permitting competing implementations, would prevent the implementation of the system's required functionality."
So it seems that your "exokernel" definition matches my "microkernel" definition.
Now, that definition represents an ideal that may not always be achieved in practive, but even then, the word "micro" in "microkernel" alone indicates that what should run in kernel mode should, at the very least, be extremely small. For my senses, I don't think "all of POSIX and VFS" is cutting it for that.
> even L4 isn't a "true" microkernel if you are ultra-pedantic and run on processors with, say, userspace interrupts.
I am actually open on what the "proper" definition of a microkernel is, but if the current state of the Linux kernel is included in that, and again if my present understanding of Linux is accurate and up to date (i.e. POSIX, VFS, allocators, all of the vm layer, and many many more things are still integral and inseparable parts running in kernel mode), i.e. if the term "microkernel" is not sufficient to separate such a kernel from QNX's Nucleus, or L4, then that term strikes me as rather useless.
FWIW, I don't think I have ever seen any Linux kernel maintainer, including Linus, referring to their kernel as a microkernel. I have seen the exact opposite in the famous debate with Tanenbaum, but that was decades ago, so I have to be open to the possibility that the shape of the Linux kernel may have changed significantly since then.
It's a bad analogy unless the button makes the bus change Transformers style into a completely different car.