4 ms·

"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

"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/ https://lwn.net/ml/all/20250204052916.GA28741@lst.de/ That doesn't sound like he's only talking about in his area to me

bjord 2y 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?
- naasking 2y ago
  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.
  - ChocolateGod 2y ago
    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.
    - steveklabnik 2y ago
      > 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.
      - ChocolateGod 2y ago
        That's apparently still unclear according to the LKML.
  - somanyphotons 2y ago
    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
- zoogeny 2y ago
  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.
  - dralley 2y ago
    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".
    - zoogeny 2y ago
      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.
- WesolyKubeczek 2y ago
  It’s adherence dictated by lived experience, if anything. Much like the “don’t rewrite from scratch” mantra was written in blood and tears.
rcxdude 2y ago
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.

bjord 2y 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?

naasking 2y ago
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.
- ChocolateGod 2y ago
  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.
  - steveklabnik 2y ago
    > 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.
    - ChocolateGod 2y ago
      That's apparently still unclear according to the LKML.
- somanyphotons 2y ago
  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
zoogeny 2y ago
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.
- dralley 2y ago
  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".
  - zoogeny 2y ago
    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.
WesolyKubeczek 2y ago
It’s adherence dictated by lived experience, if anything. Much like the “don’t rewrite from scratch” mantra was written in blood and tears.

rcxdude 2y ago

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.