No it wouldn't. People have been trying that for decades, the performance is always awful.

>>107741408
I don't see any reason why performance should be worse than on a monolithic kernel other than the fact that they tend to receive less development and support.

>>107740569
Windows will be fully Rust before Redox is complete.

>>107741514
Okay but my interest is more in the microkernel and security features than Rust. I'd extend it to GNU Hurd if I had any faith in it ever being useable.

>>107741499
That's because monolithic kernels have never been tried. No, not even Linux. It's a hybrid LARPing as a monokernel, but it's not. The Finnish retard copied the API from a self-admitted microkernel (Minix), whose explicit purpose was to keep complicated shit out of kernelspace.

A true monokernel wouldn't block on open and reads. A true monokernel would allow you to create sockets and FDs in batches. A true monokernel would have compound functions (open + mmap + close) for the most common patterns.

>>107742231
Also, a true monokernel would've probably used something like shared mappings between user and kernel to properly utilize memory layout and out-of-order execution, and write-lock the plot upon submission to make sure that the thread cannot modify the data in mid-flight. *And our current hardware doesn't support that very well* because the page table is a process-wide resource, not a thread-local one - meaning that, if you write-lock pages, you end up with per-core TLB shootdowns that can easily take much longer to complete than just copying all parameters from userspace to kernelspace, even if it's an in-order copy.

Oh, and speaking of TLB shootdowns:
>batched mmap