Evidence to the contrary need not be presented. At least, not until someone comes up with a reason for microkernels being bad/wrong/sucky.
Good point! The biggest problem for microkernels is that they have to switch contexts far more frequently than a monokernel (in general).
For a simple example, a user app making a single system call. In a monokernel, The call is made. The process transitions from the user to the kernel ring (ring 3 to ring 0 for x86). The kernel copys any data and parameters (other than what would fit into registers) from userspace, handles the call, possably copies results back to userspace, and transitions back to ring3 (returns).
In a microkernel, the app makes a call, switch to ring 0, copy data, change contexts, copy data to daemon, transition to ring3 in server daemon's context, server daemon handles call, transitions to ring 0, data copied to kernelspace, change contexts back to user process, copy results into user space, transition back to ring3 (return).
Those extra transitions and context switches have a definite cost. A CPU designed with that in mind can help (a lot!), but on current hardware, it can be a nightmare. That's why a monokernel tends to perform better in practice.
Kernel modules in Linux are nothing like microkernel. They are just bits of a monokernel that are dynamically linked at runtime. In order to be a microkernel, each module would be a process and would reside in some ring other than 0 (possably 3, but not necessarily). In order to fully realise the microkernel module, users would be able to do the equivilant of insmod and get a private interface. Other users might or might not choose to access that module, and might insmod a different version with the same interface. This would not present a security problem.
There may well be places where the overhead is a worthwhile trade off for the features (clustered systems might be a good example). Cray takes an approach like that (not exactly that, just like that) in mkUnicos for the T3E (possably others, but I've not used those).
Some microkernels do a better job at efficiency than Mach (L3 for example). At some point, the hardware might actually get fast enough that the trade-off is nearly always worth while. Even then, monokernels will still have a place for situations where every cycle counts I don't anticipate those situations ever going away.
Re:Envy? (Score:5)
Evidence to the contrary need not be presented. At least, not until someone comes up with a reason for microkernels being bad/wrong/sucky.
Good point! The biggest problem for microkernels is that they have to switch contexts far more frequently than a monokernel (in general).
For a simple example, a user app making a single system call. In a monokernel, The call is made. The process transitions from the user to the kernel ring (ring 3 to ring 0 for x86). The kernel copys any data and parameters (other than what would fit into registers) from userspace, handles the call, possably copies results back to userspace, and transitions back to ring3 (returns).
In a microkernel, the app makes a call, switch to ring 0, copy data, change contexts, copy data to daemon, transition to ring3 in server daemon's context, server daemon handles call, transitions to ring 0, data copied to kernelspace, change contexts back to user process, copy results into user space, transition back to ring3 (return).
Those extra transitions and context switches have a definite cost. A CPU designed with that in mind can help (a lot!), but on current hardware, it can be a nightmare. That's why a monokernel tends to perform better in practice.
Kernel modules in Linux are nothing like microkernel. They are just bits of a monokernel that are dynamically linked at runtime. In order to be a microkernel, each module would be a process and would reside in some ring other than 0 (possably 3, but not necessarily). In order to fully realise the microkernel module, users would be able to do the equivilant of insmod and get a private interface. Other users might or might not choose to access that module, and might insmod a different version with the same interface. This would not present a security problem.
There may well be places where the overhead is a worthwhile trade off for the features (clustered systems might be a good example). Cray takes an approach like that (not exactly that, just like that) in mkUnicos for the T3E (possably others, but I've not used those).
Some microkernels do a better job at efficiency than Mach (L3 for example). At some point, the hardware might actually get fast enough that the trade-off is nearly always worth while. Even then, monokernels will still have a place for situations where every cycle counts I don't anticipate those situations ever going away.