Drivers are hardware specific, and so it's not a problem that Rust has support for a subset of the platforms that the kernel does. If you want to write a driver for a platform Rust doesn't support, just write it in C.
Drivers are usually hardware specific but are not always platform specific. For example all the usb device drivers (but not host drivers) from x86 work just fine on arm and risc. And kernel isn’t just device drivers, but also stuff like network — higher level abstractions are decoupled from platform quite good.
I don’t think there is practical intersection of platforms not supporting rust and running USB host, but by the time rust will creep into something line network subsystem code you will either not have network (which was working before) or you make yourself a rust compiler.
This can mean dropping platform support. Maybe those are dead platforms, but somebody will make the argument that adding rust made things objectively worse.
Sure. The point is, this is for new code where you know Rust supports the platform. It “creeping in” to something Rust can’t support won’t happen, because then the rust-less build will break.
You are right that there are other policies that could work in a different way, but these policies were chosen specifically so that Rust doesn’t make the kernel sacrifice old platforms.
'It “creeping in” to something Rust can’t support won’t happen'
The exact same argument could be made for future architectural changes, as OpenBSD/FreeBSD/NetBSD build requirements will now beat Polyglot Linux in every metric of porting complexity moving forwards.
