4 ms·

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 c

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).

steveklabnik 2y ago
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.
- adrian_b 2y ago
  This works only if you trust the Rust people to do their job. Obviously the maintainer does not trust the Rust people, but they also did nothing to gain his trust, but the opposite. Just saying "Trust me, or else I will shame you" is not a viable strategy. The default position of any code maintainer who sees some people coming and saying that they would maintain from now on some parts of the code and that there should be no worries about that, is to not trust them immediately, but only after enough time passes during which they demonstrate that they are really competent and not just claiming to be so.
  - xmgplays 2y ago
    No it does not require trust. If the RfL people don't do their job, well then Linux releases with the Rust parts marked broken and that's that.
  - intelfx 2y ago
    Saying "I do not trust you, so I'm going to stonewall your entire work with which you could have built that trust" is not viable either. Besides, none of this was said. Hellwig did not say "I do not trust you enough". He said "you are cancer, go away". First is harsh, but at least somewhat reasonable (in the sense that it _can be reasoned with_); second is not reasonable at all. Your interpretation is excessively charitable to an obvious bad-faith actor.
    - veidr 2y ago
      Why do you guys keep saying he said this?? He did not say that, and you (and everybody else) can see it for yourselves: > If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade). https://lore.kernel.org/rust-for-linux/20250128092334.GA28548@lst.de/ https://lore.kernel.org/rust-for-linux/20250128092334.GA2854... That's totally, utterly different than your characterization of it. (So many other people were also falsely claiming that he said it like that, I initially assumed it was true, so I'm a little irritated.)
      - steveklabnik 2y ago
        His reply after that: https://lore.kernel.org/rust-for-linux/20250131075751.GA16720@lst.de/ https://lore.kernel.org/rust-for-linux/20250131075751.GA1672... > You might not like my answer, but I will do everything I can do to stop this.
        rc00 2y ago
        In the face of Coccinelle for Rust still being unreliable, can you blame him or any maintainer? The codebase is too large to suggest that manual intervention every time something breaks is acceptable, especially when the same automated tool has been in place for C for nearly two decades. And worse yet, much of the code that is generated for Rust is in the form of macros which are quite possibly some of the most unmaintainable and difficult to parse parts of Rust. You might not like the response for being strongly worded but it is indeed backed by a technical stance and not a political or social one as has been repeatedly suggested. Already overworked maintainers are not willing to sign up for additional maintenance to what has been a solved problem. Objectively, no one should disagree with that stance.

steveklabnik 2y ago

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.

adrian_b 2y ago
This works only if you trust the Rust people to do their job. Obviously the maintainer does not trust the Rust people, but they also did nothing to gain his trust, but the opposite. Just saying "Trust me, or else I will shame you" is not a viable strategy. The default position of any code maintainer who sees some people coming and saying that they would maintain from now on some parts of the code and that there should be no worries about that, is to not trust them immediately, but only after enough time passes during which they demonstrate that they are really competent and not just claiming to be so.
- xmgplays 2y ago
  No it does not require trust. If the RfL people don't do their job, well then Linux releases with the Rust parts marked broken and that's that.
- intelfx 2y ago
  Saying "I do not trust you, so I'm going to stonewall your entire work with which you could have built that trust" is not viable either. Besides, none of this was said. Hellwig did not say "I do not trust you enough". He said "you are cancer, go away". First is harsh, but at least somewhat reasonable (in the sense that it _can be reasoned with_); second is not reasonable at all. Your interpretation is excessively charitable to an obvious bad-faith actor.
  - veidr 2y ago
    Why do you guys keep saying he said this?? He did not say that, and you (and everybody else) can see it for yourselves: > If you want to make Linux impossible to maintain due to a cross-language codebase do that in your driver so that you have to do it instead of spreading this cancer to core subsystems. (where this cancer explicitly is a cross-language codebase and not rust itself, just to escape the flameware brigade). https://lore.kernel.org/rust-for-linux/20250128092334.GA28548@lst.de/ https://lore.kernel.org/rust-for-linux/20250128092334.GA2854... That's totally, utterly different than your characterization of it. (So many other people were also falsely claiming that he said it like that, I initially assumed it was true, so I'm a little irritated.)
    - steveklabnik 2y ago
      His reply after that: https://lore.kernel.org/rust-for-linux/20250131075751.GA16720@lst.de/ https://lore.kernel.org/rust-for-linux/20250131075751.GA1672... > You might not like my answer, but I will do everything I can do to stop this.
      - rc00 2y ago
        In the face of Coccinelle for Rust still being unreliable, can you blame him or any maintainer? The codebase is too large to suggest that manual intervention every time something breaks is acceptable, especially when the same automated tool has been in place for C for nearly two decades. And worse yet, much of the code that is generated for Rust is in the form of macros which are quite possibly some of the most unmaintainable and difficult to parse parts of Rust. You might not like the response for being strongly worded but it is indeed backed by a technical stance and not a political or social one as has been repeatedly suggested. Already overworked maintainers are not willing to sign up for additional maintenance to what has been a solved problem. Objectively, no one should disagree with that stance.