I strongly disagree with your viewpoint. If you need to support plugging in new hardware to a very niche embedded architecture, you will still have many option

I strongly disagree with your viewpoint. If you need to support plugging in new hardware to a very niche embedded architecture, you will still have many options. These range the gamut from writing a driver based on the reference driver for your environment, to requesting/funding the development of such C driver from the vendor, to funding support for your hardware architecture in Rust/LLVM. Yes, all of these cost time/money. Maintenance of software ports to various architectures is very much not zero-cost, and assuming it is will eventually bite you or your business hard. As another thought experiment: let's say the development of drivers in Rust is less expensive (either in $$$ spent on engineer time, in $$$ lost to bugs and security issues, or any other valuation you choose. If you/your community of people who desire new hardware to be supported by your embedded architecture can not cover this difference in cost (to make it worthwhile for drivers to be written for you), nor can afford to develop and maintain support for your architecture in Rust (so that you can benefit from the development work done by the vendor), nor can afford to upgrade to a newer hardware platform (which solves the problem completely), then your business is already screwed and you just don't realize it yet. That said, this is the responsible way to introduce Rust code to the kernel - if this had be done by limiting future releases of Linux to only those supported by Rust, I'd be out with my pitchfork too, because that's something that really needs to be planned very carefully. As long as stable kernel releases continue to exist that support the full set of architectures, everyone's existing code will keep working, receive security fixes, etc. This is fine.