Well, think microkernels as the bare minimum. They give you just enough to write your own OS on top of that: only the bare essentials run in kernel space, whilst everything else runs in user space and has to communicate with the kernel. Compare this to a monolithic kernel, like the Linux kernel: here, the whole operating system is run in kernel space, which means that data doesn’t need to be moved between user and kernel space: this makes the OS faster, but at the cost of modularity. Redox doesn’t use the Linux kernel, it uses its own microkernel written in Rust.
Edit: A good example would be driver. In a microkernel, these run separately from the kernel and interact with it when needed. In a monolithic kernel, these drivers would be included in the kernel itself. They both have their pros and cons: if you’re interested, feel free to look it up.
Does that mean on a microkernel you’d essentially have double the amount of code execution for a driver (i.e. driver makes a call to the kernel, kernel verifies and then executes rather than the driver just executing the call) meaning double the latency? Seems like it would cause a lot of problems.
Well, think microkernels as the bare minimum. They give you just enough to write your own OS on top of that: only the bare essentials run in kernel space, whilst everything else runs in user space and has to communicate with the kernel. Compare this to a monolithic kernel, like the Linux kernel: here, the whole operating system is run in kernel space, which means that data doesn’t need to be moved between user and kernel space: this makes the OS faster, but at the cost of modularity. Redox doesn’t use the Linux kernel, it uses its own microkernel written in Rust.
Edit: A good example would be driver. In a microkernel, these run separately from the kernel and interact with it when needed. In a monolithic kernel, these drivers would be included in the kernel itself. They both have their pros and cons: if you’re interested, feel free to look it up.
Does that mean on a microkernel you’d essentially have double the amount of code execution for a driver (i.e. driver makes a call to the kernel, kernel verifies and then executes rather than the driver just executing the call) meaning double the latency? Seems like it would cause a lot of problems.
Nowhere near double, the kernel can be extremely sparse on it’s side, but there is a small latency hit