Comment by gkbrk
10 months ago
Yes, "breakage should be fixed as soon as possible". Not "Rust for Linux team will fix the breakage as soon as possible".
The exception is allowing the subsystem to break Rust code temporarily. If you accept a patch in C that breaks Rust code, and the Rust for Linux team doesn't fix it quickly enough, you either need to fix the Rust code yourself, remove it, or re-write it in C. All of this would take time and energy from all the non-R4L kernel devs.
This is why people are reluctant to accept too much mixing of the C and Rust codebases, because even the Rust for Linux team isn't promising to fix breakages in Rust for Linux code.
Just to be clear, this is the situation. A rando submits a C patch that breaks Rust code, a maintainer accepts this patch and then demands that the R4L devs fix the breakage introduced by someone else and reviewed by themselves. The rando who broke the thing isn't around, and the person who reviewed the change takes no responsibility.
Have I gotten that right?
And then you're presenting this situation as "the Rust for Linux team isn't promising to fix breakages in Rust for Linux code". Somewhat disingenuous.
To say Rust won't cause extra work for C developers, this is exactly what people are claiming. This is from the comment I originally replied to.
> The Rust maintainers have committed to handling all maintenance of Rust code, and handling all breakage of their code by changes on the C side. The only "burden" the C maintainers have to carry is to CC a couple of extra people on commits when APIs change.
But this is not actually true it seems. Even the Rust for Linux policy doesn't say this. But because of the incorrect statement that keeps getting repeated, people are calling Kernel devs unreasonable for being reluctant to Rust patches.
> A rando submits a C patch that breaks Rust code, a maintainer accepts this patch and then demands that the R4L devs fix the breakage introduced by someone else and reviewed by themselves. The rando who broke the thing isn't around, and the person who reviewed the change takes no responsibility.
Well, firstly, "randos" aren't getting their patches easily accepted anyway.
And secondly, what's the problem with this? You want one of the following options:
1. Everyone who wants to submit a patch also be proficient in Rust,
Or
2. You want the reviewer to also be proficient in Rust
You don't think that's an unnecessary burden for the existing maintainers?
The burden should be on the people who want to introduce the second language.
Why? You seem to describe one potential scenarios where Rust creates additional work.
You just proved the C devs point..