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.

[–] [email protected] 3 points 10 months ago (1 children)

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.

[–] [email protected] 3 points 10 months ago

Nowhere near double, the kernel can be extremely sparse on it’s side, but there is a small latency hit

[–] [email protected] 1 points 10 months ago (1 children)

thanks for the explanation! I was thought it had something to do with linux since the lead dev works for System76.

[–] dukk 1 points 10 months ago (1 children)

No problem! Actually, System76 is currently working on rewriting the COSMIC desktop in Rust (or really, just writing a new DE in Rust). It’s a pretty ambitious project that should hopefully get released some time this year. I wouldn’t be surprised if the lead redox dev was working on it too: low-level Rust knowledge is exactly what they need.

[–] [email protected] 1 points 10 months ago

Yeah, I am waiting for a new blog post from them of that.