How is that different from Linux with all virtio drivers? (You can just not compile real hardware drivers)

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 might be misremembering but I recall that Nvidia's BlueField DPUs use virtio when communicating with the host machine. From what I gather searching around it's virtio-net in specific

I imagine they do. But given that Linux has those simple drivers, why not use them?

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.

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"

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.

This is a very large rationale for what we are building with https://nanos.org .