If you're a device manufacturer trying to manage common code for a variety of hardware platforms with subtle differences in toolchains / kernels, dealing with a

If you're a device manufacturer trying to manage common code for a variety of hardware platforms with subtle differences in toolchains / kernels, dealing with all that complexity can be pretty tough. If Rust drivers start popping up in the kernel, you now need to start dealing with twice as many toolchains and twice as much complexity. One of those toolchains is used to build the bootloader, kernel and majority of userspace software for the devices. The other toolchain is used to build an I2C temperature sensor driver that was rewritten in Rust so someone could put Rust driver experience on their resume. Dismissing this and saying "suck it up, this is the price of progress" is fine. But it doesn't change the fact that this could be a giant PITA for people making devices and developing the BSPs for them while providing almost no value. I'm not trying to argue that appeasing this group is important enough to totally reject Rust from the kernel, but as a maintainer, making life difficult for a huge number of kernel users is probably something you'd like to avoid. I think a lot of this will come down to how Rust patches are reviewed and accepted. If Amazon or Facebook want to upstream some new Rust driver they wrote for their own hardware, there's probably no negative impact to anyone by merging it. But I'd expect maintainers will be very hesitant to accept patches that touch existing drivers. I guess time will tell.