Comment by linsomniac
11 hours ago
I feel like there's a potentially large audience for a kernel that targets running in a VM. For a lot of workloads, a simple VM kernel could be a win.
11 hours ago
I feel like there's a potentially large audience for a kernel that targets running in a VM. For a lot of workloads, a simple VM kernel could be a win.
Those workloads would probably be better off as unikernels that can run directly on the VM, avoiding the question of which kernel to use entirely.
There's a difference between "want to run an application with as little extra move parts on a VM" and "want to take an existing system and swap out for a kernel with some better properties, even if it means needing to run it in a VM"
How is that different from Linux with all virtio drivers? (You can just not compile real hardware drivers)
If it's written in rust, you might expect less security vulnerabilities (especially if the codebase is also smaller: NB this is potentially counterbalanced by the many eyes on linux). Maybe there would be some extra features you find useful.
The point is it would be better than Linux in whatever way that was the reason you were writing it, but you don't have to write hundreds of different device drivers to make your cool new kernel usable.
I would imagine that virtualized device drivers would have a well-defined api and vastly simplified logic.
Shouldn't we start building hardware that have a builtin translation layer that makes them driveable by virtio drivers themselves? At least for the most capabilities?
I imagine they do. But given that Linux has those simple drivers, why not use them?
This is already the reality today with native cloud computing, managed runtimes.
It doesn't matter how the language gets deployed, if the runtime is on a container, a distroless container, or directly running on an hypervisor.
The runtime provides enough OS like services for the programming language purposes.
this x1000
Provided you have virtio support you are ticking a lot of boxes already.