Comment by rincebrain
2 days ago
The argument being made was that the nominal rule is that the Rust side has to fix their things if the C side breaks them, but in practice it doesn't work that way, allegedly because Linus has NAKed patchsets that didn't have fixes for Rust being broken in them.
I would imagine the hopefully straightforward path would be to make sure the Rust code gets build tested, and then if that fails, have a route to reach out to the people who want to do R4L work and tell them "this is breaking because of what I changed, can you help when you get a chance", for the maintainers who don't want to learn Rust.
...of course, one reason the maintainers loathe this idea, is that the personality archetype who works on Linux generally is the kind of person who would go fix it themselves because they're impatient, so with that framing, it's pretty clear why they think "wait on other people to fix it" is a nonstarter de facto...
> allegedly because Linus has NAKed patchsets that didn't have fixes for Rust being broken in them
He NAKed one patch. One single patch. And the reasoning for that patch was that everyone was in the holidays. Otherwise he was willing to ship a broken rust kernel.
That's standard specially when a subsystem break other, you Cc them
Sure, sorry, I should have described that better.
I understand that's standard if you know you broke them, I was imagining a solution to the problem "this is broken and needs to be fixed, preferably quickly, to unblock me, but I don't want to go down the Rust rabbit hole", since by nature, I would not expect most of the R4L maintainers to want to volunteer to do that kind of turnaround time on a consistent basis.
(This might be an unnecessary optimization if they're already planning for that, but speaking personally, I would think a lot of the fixes involved would probably be somewhat mechanical on the R4L side for that kind of breakage, and I also think it would provide something of a "happy path" for maintainers, in terms of perception, to know that they have an "in case of Rust do X" ramp even if in practice it rarely if ever gets exercised...)
> "this is broken and needs to be fixed, preferably quickly, to unblock me
How would Rust breakage block someone who only writes C?
> I would not expect most of the R4L maintainers to want to volunteer to do that kind of turnaround time on a consistent basis.
There's at least six people who are being paid full time to work on Rust for Linux, across a few different companies. I would imagine fixing any breakage is a high priority for them, and since it's part of their job, I'd imagine they'll get it done.