> It doesn't have to be Linux. It isn't the end-all in operating systems. It's just what happens to be most popular -right now-.

That's part of the problem, I think: The Rust group's primary goal appears to be increasing the usage and/or popularity of Rust, not merely hardening the Linux kernel.

After all, both the kernel devs as well as the Rust group knows very well that the Rust group can maintain out-of-tree patches indefinitely. By using a out-of-tree patch, they can slowly and effectively replace almost all of the drivers. Many people actually would download and use their `rustix` kernel.

But that doesn't allow them to achieve their goal of spreading the movement, hence their resistance to prove the concept out-of-tree and the pushback from kernel devs who see this purely as a popularity-booster.

There is no good argument against the Rust group proceeding with an out-of-tree development effort; all the ones around "it's too much work" reflects the fear that the kernel devs have that the Rust group would push Rush code into the kernel, and then not be around to maintain it when some C code breaks it.

Lack of internal APIs is not the problem if the putative Rust-based clone doesn't aim to be compatible with Linux drivers written in C, which I think it wouldn't. The real problem is that the Linux kernel ABis to user-land are merely stable, myriad, and poorly documented. Keeping up is not possible. The BSDs, Solaris/Illumos, and Windows all had at least one (sometimes two) attempts at being compatible with Linux kernel user-land ABIs, and all failed due to being woefully incomplete in spite of being huge.