In practice, the Linux community is the wild wild west, and sweeping changes are infamously difficult to achieve consensus on, and this is by far the broadest sweeping change ever proposed for the project. Every subsystem is a private fiefdom, subject to the whims of each one of Linux’s 1,700+ maintainers, almost all of whom have a dog in this race. It’s herding cats: introducing Rust effectively is one part coding work and ninety-nine parts political work – and it’s a lot of coding work. Every subsystem has its own unique culture and its own strongly held beliefs and values.
The consequences of these factors is that Rust-for-Linux has become a burnout machine. My heart goes out to the developers who have been burned in this project. It’s not fair. Free software is about putting in the work, it’s a classical do-ocracy… until it isn’t, and people get hurt. In spite of my critiques of the project, I recognize the talent and humanity of everyone involved, and wouldn’t have wished these outcomes on them. I also have sympathy for many of the established Linux developers who didn’t exactly want this on their plate… but that’s neither here nor there for the purpose of this post, and any of those developers and their fiefdoms who went out of their way to make life difficult for the Rust developers above and beyond what was needed to ensure technical excellence are accountable for these shitty outcomes.
…
Here’s the pitch: a motivated group of talented Rust OS developers could build a Linux-compatible kernel, from scratch, very quickly, with no need to engage in LKML politics. You would be astonished by how quickly you can make meaningful gains in this kind of environment; I think if the amount of effort being put into Rust-for-Linux were applied to a new Linux-compatible OS we could have something production ready for some use-cases within a few years.
…
Having a clear, well-proven goal in mind can also help to attract the same people who want to make an impact in a way that a speculative research project might not. Freeing yourselves of the LKML political battles would probably be a big win for the ambitions of bringing Rust into kernel space. Such an effort would also be a great way to mentor a new generation of kernel hackers who are comfortable with Rust in kernel space and ready to deploy their skillset to the research projects that will build a next-generation OS like Redox. The labor pool of serious OS developers badly needs a project like this to make that happen.
Follow up to: One Of The Rust Linux Kernel Maintainers Steps Down - Cites “Nontechnical Nonsense”, On Rust, Linux, developers, maintainers, and Asahi Lina’s experience about working on Rust code in the kernel
There’s a Pareto effect when it comes to them, in that you can cover a large proportion of use cases with a small amount of work, but the more special cases consume proportionately more effort. For a MVP, you could restrict support to standard USB and SATA devices, and get a device you can run headless, tethered to the network through a USB Ethernet adapter. For desktop support, you’d need to add video display support, and support for the wired/wireless networking capabilities of common chipsets would be useful. And assuming that you’re aiming only for current hardware (i.e. Intel/AMD boards and ARM/RISC-V SOCs), there are a lot of legacy drivers in Linux that you don’t need to bring along, from floppy drives to the framebuffers of old UNIX workstations. (I mean, if a hobbyist wants to get the kernel running on their vintage Sun SPARCstation, they can do so, but it won’t be a mainstream feature. A new Linux-compatible kernel can leave a lot of legacy devices behind and still be useful.)
I think we’re kind of saying the same thing: making something that boots as an MVP isn’t the most difficult thing but is still a much different and simpler project than making a replacement kernel for Linux.
If you really wanted to be a legitimate actual replaces-Linux-for-all-the-things-you-use-Linux-for kernel, you’d be biting off years and years and years of work on drivers. I mean, just look how long it took Noveau to go from ‘kinda works’ to ‘actually viable’ and that’s just a subset of GPUs from one vendor.
I’d also add that if you cared about server hardware, you’ve got a much larger driver footprint with a lot more weird behavior shit than on desktops which are, honestly, just a couple dozen combinations of chipset, sound, ethernet, and usb controller in any given generation.
And sure, you could lean on the work that’s already been done at this point and probably do it faster, but it’s still a massive undertaking.
ReactOS is probably a good indicator how far you can get with some limited generic drivers.