Comment by bjord
10 months ago
is this just weird religious adherence to the belief that a multi-language codebase will be harder to maintain? what's the rationale, exactly?
10 months ago
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.
> Linus could make some of this go away by committing to let the Rust builds break.
Linus already did that. This is the state of things today. C code is allowed to break the Rust, and it's the Rust for Linux people's responsibility to get it working again, not the C folks.
I'm just an interloper and only going on the linked thread, but there are specific patches that missed merge windows due to Rust build breaks. The patches referenced are claimed to be exceptions but I can understand the fear. Linus is saying one thing but making exceptions in some cases. As Rust becomes more and more integrated into core Linux systems those exceptions may become more frequent and may eventually become the rule.
To be fair, I think another valid solution to this problem is just to bite the bullet and tell the grumpy C developers to deal with it. At some point the fallout from an exodus of grey beard Linux maintainers will actually be less than fighting this battle. As many point out, they are going to exit the project one way or another eventually.
2 replies →
Thanks.
No, the point is nonsense. Rust is a consumer of the APIs just like every other driver / subsystem is. Any change to the C APIs would likely require collaboration with those other maintainers no different than Rust. And CH would be immediately shut down if he tried to roadblock some random driver that needs DMA purely because he doesn't want the existence of that driver to "increase his workload".
I think you are using inflammatory language by calling the point nonsense.
As an outside observer, literally no skin in this game, I can see his point. If his C code changes breaks other C code then he is at an advantage compared to if his C code breaks a Rust binding or Rust drivers. The degree to which this adds to his burden of maintenance is up to him to decide.
7 replies →
> some random driver that needs DMA purely because he doesn't want the existence of that driver to "increase his workload".
This isn’t blocking any drivers. Just adds duplicate code.
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.
I think both arguments have credibility.
The R4L says they will make sure the Rust code is fixed when the C code is, and that's admirable, but the concern it means a developer now has to wait for that, holding up their work for release/submission. The bus factor is now on the R4L team.
Meanwhile, everyone involved in development for Linux already knows C.
> the concern it means a developer now has to wait for that, holding up their work for release/submission.
They do not have to wait.
1 reply →
The linux kernel project specifically cares about the labor pool of maintainers.
My assumption is that it's easier to train someone on rust then to train someone to be a kernel subsystem maintainer
It’s adherence dictated by lived experience, if anything.
Much like the “don’t rewrite from scratch” mantra was written in blood and tears.