Comment by nicce
10 months ago
That is not what the maintainer said. The maintainer said that for Rust code in the area he is currently maintaining. I think the main issue was, the he was not accepting second maintainer to take care the Rust part on the same area.
About the Rust code itself; the primary issue was code duplication rather than preventing the use of Rust altogether. Since the suggested code is not merged, every driver needs to write the same code over and over again. That was also something that the maintainer suggested himself (?). There is of course a big downside, but I am not sure if this justifies all the hate.
>That is not what the maintainer said. The maintainer said that for Rust code in the area he is currently maintaining. I think the main issue was, the he was not accepting second maintainer to take care the Rust part on the same area.
The Rust code is not in the area he was currently maintaining. Christoph didn't even look at the patches before objecting to them. Once it was pointed out that they were not in his area, he rejected them anyway.
Note that, because they are not in his area, he does not actually have the authority to do this. He was CC'd in an advisory sense, it's not really his call to accept them or not, and as a longtime kernel maintainer he surely knows this.
The issue is it creates a downstream dependency on his code, even if it is 100% separate and separately maintained.
Once the wrapper is written, any breaking changes he makes in the DMA subsystem will, by their very nature, percolate downstream to the Rust wrapper and then to any Rust code that relies on it.
So basically from that point forth, he will always have to consider the ramifications of his changes on another group of developers, and deal with any backlash those may cause.
Is he being unreasonable? I tend to lean on the side of "yes," but I can certainly empathize with his point of view (not necessarily his approach, however).
He does not need to consider those ramifications because it is up to the rust for Linux people to fix the issues. He does not need to care about them at all.
They reiterated that in the thread too.
15 replies →
If that is true, why he was the one that was asked to review/ or why his opinion even matters here? The must be some sort of correlation to his code or this does not make sense at all..
He wasn't asked, he was CC'd on the patchset because it wraps his subsystem. If he was interested in doing a driveby review in good faith, or taking interest in what was going on, then he could have done so.
"The common ground is that I have absolutely no interest in helping to spread a multi-language code base. I absolutely support using Rust in new codebase, but I do not at all in Linux." https://lwn.net/ml/all/20250204052916.GA28741@lst.de/
That doesn't sound like he's only talking about in his area to me
It's just in his area where he has the power to say no, and it's important enough to be a big impediment to the whole project.
is this just weird religious adherence to the belief that a multi-language codebase will be harder to maintain? what's the rationale, exactly?
I'm just parsing the thread but it seems that changes to the C api can break the Rust bindings.
This leads to two situations: the C maintainer has to also update the Rust binding, or the patch has to wait for a Rust capable maintainer to fix them up.
For the first solution, the C maintainer is claiming he has enough work on his plate just keeping up with the C code that he doesn't want to work on Rust. He also believes it is unfair to force every C maintainer to learn enough Rust to keep their integration points working.
For the second solution, the C maintainer is pointing out that Linus has a history of refusing to merge C patches that break Rust builds. So even though the Rust advocates promise they will handle all of the Rust stuff and they are OK with their stuff being broken after C changes until they get around to fixing it, Linus doesn't seem to actually allow for this in practice.
I can see the maintainers point. Sooner or later Rust bindings on critical systems will be essential and changes to the C code will be gated on changes to the Rust code. It is a fantasy of the Rust maintainers that they will have to shoulder that entire burden. But even if they did, it would give them some pretty hefty leverage over the C maintainers in those essential cases. And it also introduces a requirement that someone with enough Rust and subsystem knowledge is even available for the job. People making promises today may disappear tomorrow, leaving the maintainer with an essential binding to a language he doesn't want to support.
edit: as has been said elsewhere, Linus could make some of this go away by committing to let the Rust builds break. I don't know if that could be done in a way that wouldn't be a de facto fork.
15 replies →
Maintainers come and go, languages come and go. C will never go away and everyone working on kernels knows C, so there's a certain labour pool and skillset that will always be available that doesn't necessarily apply to Rust. That's even setting aside any technical issues, like bugs creeping up in the language interoperability layer, which obviously doesn't really happen if you're only using one compiler.
4 replies →
It’s adherence dictated by lived experience, if anything.
Much like the “don’t rewrite from scratch” mantra was written in blood and tears.