Rust in the kernel is starting with drivers, so if there's a Rust driver for something, it's presumably for hardware that's on a supported platform. Regardless,

Rust in the kernel is starting with drivers, so if there's a Rust driver for something, it's presumably for hardware that's on a supported platform. Regardless, if you only want C-written work, you're no worse off. The gccrs and rust_gcc_backend projects both are progressing well and would presumably help enable support for other targets only supported by gcc. As far as its affect on Rust, the last year or two, a significant amount of development and affordance has gone into features for "no-std" and its likely that will only accelerate now that Rust is going to be in Linux (and have an opportunity to prove itself there) along with the number of Rust developers that are interested in kernel development. The performance of the NVMe Rust driver in Linux persuaded some of the skeptical kernel devs. With Rust's greater static analysis (and a lot of work around formal methods), in the long run, there will be optimizations that are at least easier if not impossible in C-based codebases. The main advantage is, as you said, the static analysis that radically reduces pointer-related bugs and security vulnerabilities. Another advantage that I'm personally a little skeptical about, but has been expressed by more than one kernel developer, is attracting new talent to becoming kernel developers as the current group is aging.