The problem it tries to bring up is that there is a subset of processes running in the Linux Kernel as either baked in functionality or KOs that can avoid context switches and IPC calls by being baked into the same executable.
In practice, you can share memory. In practice, a code base as large as Linux actually ends up having a lot of TLB flushing whenever it alternates between the very different sections of binary that dictate behaviors of the core kernel and devices.
It doesn't help that the self fulfilling prophecy is that by fine tuning a baked in service into Linux means that a lot less effort is made trying to make it an efficient interface.
I am obviously biased, I think microkernels are a good idea. I don't know if its unix or not, but I don't like having one binary that will inject itself with extra linkables when needed that manages every device, the network stack, the sound API, manages the filesystem, manages memory, and manages processor scheduling. Most of this stuff doesn't need the kernel mode special processor registers, in practice a well designed system shouldn't require anything more than a fixed memory page reference to the device that the kernel will handle mapping (I can't think of a way to build a kernel without virtual memory, virtual files, and virtual processing baked in at the ground level, and 2/3 of those really do require special processor permissions).
You might not be biased. It's hard to ignore Wombat demonstrating context-switching costs that are up to 30 times lower than native Linux.
The status quo of kernels is reminiscent of the status quo of programming languages in the 90s. Where people programmed in faster, static languages and looked down on dynamic ones. I wonder what we will think of monolithic kernels in 50 years from now.
EDIT: A binary injecting itself with multiple code (linkables) might not be bad. It's much like what a macro does to a program. You turn one flag on and the source gets populated with the appropriate code.
It is lack of a dynamic way of injecting it that can bite you. The inability to easily change what was injected.
The problem it tries to bring up is that there is a subset of processes running in the Linux Kernel as either baked in functionality or KOs that can avoid context switches and IPC calls by being baked into the same executable.
In practice, you can share memory. In practice, a code base as large as Linux actually ends up having a lot of TLB flushing whenever it alternates between the very different sections of binary that dictate behaviors of the core kernel and devices.
It doesn't help that the self fulfilling prophecy is that by fine tuning a baked in service into Linux means that a lot less effort is made trying to make it an efficient interface.
I am obviously biased, I think microkernels are a good idea. I don't know if its unix or not, but I don't like having one binary that will inject itself with extra linkables when needed that manages every device, the network stack, the sound API, manages the filesystem, manages memory, and manages processor scheduling. Most of this stuff doesn't need the kernel mode special processor registers, in practice a well designed system shouldn't require anything more than a fixed memory page reference to the device that the kernel will handle mapping (I can't think of a way to build a kernel without virtual memory, virtual files, and virtual processing baked in at the ground level, and 2/3 of those really do require special processor permissions).