Yeah this, really. For the most part even monolithic kernels have kind of reversed trend in the last decade or so and there's a lot of push to move critical code out of the kernel. A lot of new kernel apis are built to avoid context switching, and part of that usually involves moving to a more asynchronous kind of communication between process and kernel.

Often these APIs even look an awful lot like late generation microkernel shared memory buffer protocols. DRI and uring in linux for example.

A lot of the "microkernels are inherently slow" meme is built on how earlier port-based message passing kernels like mach worked.

I'm really not understanding what you're saying here.

What the hell is a microkernel here? What kind of security are you talking about?

User space filesystem and network implementations still need access to the hardware. Multiplexing that access is a kernels job. The more you want to separate and hide that between clients the higher the cost.

As far as i understand your argument you are saying "If an application has a dedicated hard drive there will be little overhead"

People think a monolithic kernel can be faster because of high-level abstractions that make many calls within the kernel, for example if I write to a TCP socket and everything else is handled for me, in the kernel, by function calls only. People believe this is faster than having an isolated network stack that has to pass messages to an isolated network driver and all that.

But increasingly people realize that the performance of writing to a TCP socket in a unikernel also pretty much sucks and you get a much better result as you move more and more of it into user space. For example you decide, correctly, that TCP is obsolete and you switch to QUIC. Now the existence of the Linux TCP stack is of no value to you. You furthermore discover that Linux firewall, traffic control, and routing also kinda sucks, so you start using raw networking. Then you discover that trying to get your frames processed on the right core at the right moment isn't great in Linux, so you just take over the whole net device with DPDK.

Now, nothing in the whole Linux network stack is of any use to you at all.

The same thing can happen with storage. Maybe you started with files on XFS but then eventually you were using disaggregated storage where a service takes over the whole device with SPDK, and all the storage users are talking to the service instead of the kernel.

Of course, although you may be able to go very much faster, you also now took on all this extra responsibility, and so complexity, and so likely bugs.

Chances are the weird corner case where the TCP implementation blows up was seen in a dozen other Linux applications and fixed, but the same case inside your entirely userspace QUIC implementation gets to explode while the boss is doing the live $100M pitch demo. Awkward.

Code that is competing with Linux for performance is likely to be highly concurrent (a big risk factor for bugs) and doing fancy gymnastics with memory (another risk factor) so we're not talking about a landscape where bugs are rare or one where they're very easy to track down.

I believe this sort of thing is one reason Linux is putting more emphasis on safety. As usual for HN this bug already has people saying both "Rust wouldn't catch this" and "actually Rust would catch this", but even if you're quite sure Rust isn't the answer a safer Linux by whatever means makes this argument better for Linux than it is today.

The QUIC implementation was written in Rust, so the live $100M pitch demo is safe.

> User space filesystem and network implementations still need access to the hardware.

No, they don't. Filesystems don't need access to the hardware, that part is handled by the block device driver. Network stacks (e.g., TCP/IP) also don't need access to the hardware, that part is handled by the network interface driver.