Comment by weinzierl

Sometimes, we do such things because it’s hard. We enjoy the challenge. Those that succeed are glad to make it, too.

You jest, but I believe @tptacek is using an LLM (ChatGPT?) to understand the details of various Linux kernel subsystem and has said it works quite well for the task.

It's not a great jump from that to "port Linux device driver for XYZ to this new OS in Rust". Won't be perfect but a lot less hassle than doing it from scratch.

Some future VC-funded company will unironically have this same requirement

Claude Sonnet 3.5 seemed happy enough to do it, and the start looked promising

     Absolutely! Let's dive into writing a device driver for the Intel i350 4 Port Gigabit Ethernet Controller using Rust. This is an exciting project that combines low-level hardware interaction with the safety and performance benefits of Rust. I'll create a basic structure for our driver, focusing on the key components needed to interact with the device.

    #![no_std]
    #![feature(abi_x86_interrupt)]    
    ...

but I'm not qualified to judge the quality from eyeballing and I'm certainly not going to go to the trouble of trying to test it.

LLMs are notoriously bad at improvising device drivers in no-std Rust.

Why would you want to support multiple? New versions should always be backwards compatible with older ones, so you'll always have the largest amount of compatibility by targeting the latest upstream. The real challenge comes with supporting applications that want features only available in forked kernels, which I guess could prompt wanting multiple kernels targeting the distinct ABIs.

It’s about to turn up inside Android running in a VM [1] but it was less clear exactly for what purpose.

My theory is that this is essentially a long term project to bring the core of Chrome OS and Android to rely on Fuschia for its core which gives them syscall level compatibility with what they both use at the moment and that they would both essentially sit as products on top of that.

This is essentially the exact strategy they used if I remember correctly with the Nest devices where they swapped out the core and left the product on top entirely unchanged. Beyond that in a longer term scenario we might also just see a Fuchsia OS as a combined mobile / desktop workstation setup and I think part of that is also why we are seeing ChromeOS starting to take a dependency on Android’s networking stack as well right now.

[1] https://www.androidauthority.com/microfuchsia-on-android-345...

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.

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.

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"