Comment by cogman10 | Hacker News Reader

Comment by cogman10 | Hacker News Reader

Parent Full thread

Don't know what to tell you. The C developers have the keys of the kingdom. It's up to the rust devs to appease them. When you are a new-comer to an old project a big part of that is working with the current gatekeepers to get your changes through in a way they'll accept. That can sometimes mean doing things sub optimally in your view.

In particular, the DMA maintainer didn't want rust code in their DMA subsystem. That sucks, but it means you need to relocate your dma bridge code out of their subsystem. It does mean your driver will be a second-class citizen in the kernel tree (which was always going to be the case for rust).

Linus' reaction was to someone who started a public campaign against another kernel developer and tried to use that following to pressure the maintainers of the kernel to bend to the will of the newcommer. I'm sorry, but I'd also have a pretty negative reaction to that.

The workplace equivalent is you publishing a whistle blowing article against a team in your company because they'd not accept a pull request you worked very hard on. You don't do that. You handle things internally and privately and sometimes you tell the boss "sorry, I can't get this done because another team is blocking the change and they are unwilling to work with me".

And do not mistake my post. I'm not siding with the C dev just because I'm critiquing the rust dev. Guy sounds like he's too stuck in his way. The problem is you don't get a big well working and long running project like the kernel without having these sorts of long-term maintainers that make the calls and shots on what to reject.

>In particular, the DMA maintainer didn't want rust code in their DMA subsystem. That sucks, but it means you need to relocate your dma bridge code out of their subsystem

The code was never in the DMA subsystem. At no point was there ever any Rust code in the DMA subsystem.

CH didn't even look at the patch before throwing the wall up. When it was pointed out that the patch already was the way he claimed he wanted it, he came up with a 2nd excuse, and then when that avenue was shut down he said he would do anything to stop Rust being put in the kernel, period, he wouldn't work with any Rust developers and he wouldn't accept adding a second maintainer for his subsystem that would do that engagement either.

From that point it's pretty clear that all previous engagement was just in bad faith.

> The workplace equivalent is you publishing a whistle blowing article against a team in your company because they'd not accept a pull request you worked very hard on.

The workplace equivalent is your CEO making a public statement that your work is to be supported, then not firing people who openly gloat about their intent to sabotage your work.

I mean, I hope that you'd get fired for trying to publicly shame people who you see as trying to "sabotage" you in any normal corporation, regardless of how much your vision aligns with the CEO's lol.

Not that it even makes sense to call it sabotage considering that most people that were involved in the original debate (in the rust for Linux side) didn't see it like that, that the normal kernel development processes were on their way to actually make the change happen anyways, and that Marcan's actions probably did more to sabotage actual support from other maintainers and Linus himself than the original NACK that started all of this ever did.

(Not that Linus ever even gave a blank check for rust on Linux, so I don't think that disagreements and even NACKs are somehow going against what Linus decided)

NACKs of bad Rust code, or Rust code that you don’t want in the system that you maintain, would be fine. The specific NACK at issue here was a NACK of code that used a maintainer’s API from a language that he didn’t like, which Linus has confirmed is not allowed.

> Maintainers like Hellwig who do not want to integrate Rust do not have to. But they also cannot dictate the language or manner of code that touches their area of control but does not alter it. The pull request Hellwig objected to "DID NOT TOUCH THE DMA LAYER AT ALL," Torvalds writes (all-caps emphasis his), and was "literally just another user of it, in a completely separate subdirectory."

> "Honestly, what you have been doing is basically saying 'as a DMA maintainer I control what the DMA code is used for.' And that is not how any of this works," Torvalds writes.

> Torvalds writes Hellwig that "I respect you technically, and I like working with you," and that he likes when Hellwig "call[s] me out on my bullshit," as there "needs to be people who just stand up to me and tell me I'm full of shit." But, Torvalds writes, "Now I'm calling you out on YOURS."

> The leader goes on to state that maintainers who want to be involved in Rust can be, and can influence what Rust bindings look like. Those who "are taking the 'I don't want to deal with Rust' option," Torvalds writes, can do so—later describing it as a "wall of protection"—but also have no say on Rust code that builds on their C interfaces.

> "Put another way: the 'nobody is forced to deal with Rust' does not imply 'everybody is allowed to veto any Rust code.'" Maintainers might also find space in the middle, being aware of Rust bindings and working with Rust developers, but not actively involved, Torvalds writes.

https://arstechnica.com/gadgets/2025/02/linux-leaders-pave-a...

Reply on news.ycombinator.com