It's more a matter of culture

This is only true for safety requirements that cannot be easily checked fully automatically -- in Rust's case, this means: safety requirements that cannot be expressed as Rust types. Most safety requirements *can* be expressed as Rust types, and then nothing needs to change in the lower layer.

For safety requirements that are so complicated that they cannot be expressed as Rust types, an argument can be made that they are so complicated that higher layers programmed in C are also at significant risk of getting them wrong.

So the culture difference here is more about, how much risk of accidental misuse by higher layers are you willing to accept? Even with no Rust involved, one has to pick a reasonable trade-off. So far, there is no hard line here that would clearly mark an API as "too complicated" -- it's up to negotiation between driver authors and subsystem maintainers. With Rust, a hard line is introduced here: if things cannot be put into Rust types, that is deemed a hard "too complicated". The DRM scheduler is such a case, and now the challenge is to convince the maintainer of that system that it is indeed "too complicated".

> Changing any of this means replacing almost everything.

No, that's just not true. As Asahi Lina said multiple times in this thread: the vast majority of C APIs are perfectly fine! No change is needed to expose them in Rust in a reasonable way. It is a rare exception that a C API has a safety contract that is so complicated that it cannot be expressed in Rust types. So far, at least Asahi Lina hit exactly one such case: the DRM scheduler.

So it's just not correct to claim that everything has to change. Most APIs are already robust enough for a good Rust API.

---

All that said, I wonder if it would help for some of these changes to use a different communication strategy. I noticed the argument "this is needed for a safe Rust API" is used to try and change a C API, and I can see how that can be a hard sell for a C maintainer. So maybe it would help to focus on "this makes the API easier to use for everyone, C and Rust consumers alike" -- trying to argue for the change entirely on its own merit, without involving Rust much. That argument *has* been made, but it often came as a secondary argument after "Rust needs this", and such subtle distinctions can make a big difference in how a proposed change is perceived. Of course I am an outsider here, so feel free to ignore this advice if it isn't helpful. :)