In my mind, introducing Rust would only make sense if:
There was a serious lack of current kernel developers (which I don't think there is)
New hardware and tech was evolving at a rate that the Linux Kernel could not keep up (again, I don't think this is am issue)
The end goal is to migrate the entire Kernel to Rust.
Regarding point 3, having both C and Rust really only makes sense as a transition phase (measured in years) - as it would require kernel developers to be savvy in both C and Rust, or would force developers to stay within whatever domains were implemented in C or Rust.
There was a serious lack of current kernel developers (which I don't think there is)
Maybe not at the moment, but my understanding is that the pool of qualified C programmers is shrinking rapidly, because the old guard is all ageing out and there simply are not enough intermediate developers coding in C at the level that Kernel development requires.
Having a larger (and growing) pool of upcoming developers interested in systems programming and software excellence is one of the explicit stated reasons that Linus et al. considered Rust in the first place.
Oh absolutely, but you could argue the same for learning lisp or mastering any functional programming language (list comprehensions, etc). It will improve your design patterns when you go back to an object oriented language with some elements of functional programming.
Nah it's a different axis. Rust doesn't have a GC, you do need to think about memory, it's just that the compiler generally enforces things for you. You learn to think like borrowck thinks because you don't want to get yelled at. Going back to C then you suddenly mistrust a lot of code a lot more, and rightly so.
Rust isn't a "silver bullet" that will solve all of our problems, but it sure will help in a huge number of places, so for new stuff going forward, why wouldn't we want that?
...
Yes, I understand our overworked maintainer problem (being one of these
people myself), but here we have people actually doing the work!
To add something to this: linux has avoided internal SPIs for a long time. It's often lauded as one of the reasons it hasn't ossified.
However, some subsystems have a huge amount of complexity and hidden constraint in how you correctly use them. Some of that may be inherent, but more of it will be accidental.
Wrapping type-erased shims around this that attempt to capture (some of) those semantics shines a light onto the problem. The effort raises good technical questions around whether the C layer can be improved. Where maintainers have approached that with an open mind, the results are positive for both C and Rust consumers. Difficult interfaces are a source of bugs; it's always worth asking whether that difficulty is inherent or accidental.