Hacker News Reader

Comment by Tuna-Fish | Hacker News Reader

It's just really, really dumb to both a) have rust drivers in the kernel and b) not merge this patch. It's just obviously stupid.

If you start with the assumption of a), there are no valid technical challenges to merging it. It's just better for everyone. Before Hellwig put his foot down as "not merging because rust sucks", he made a series of technical arguments against the patch, which were all transparently bullshit. It was those arguments that really raised such a furor, instead of all the other ways some C devs have disdained rust in the kernel in the past, because they were obviously made in bad faith. And when he was called out for them, he just went full "no rust in kernel".

View on HN

> Before Hellwig put his foot down as "not merging because rust sucks"

He didn't say this at all. He explicitly and repeatedly said he has no problems with Rust as a language.

And you can't just assert "there are no valid technical reasons". Just because you don't agree with the objections, or even think they're dumb, doesn't mean you can just dismiss them and start ascribing bad faith motives.

> He didn't say this at all.

Okay, sorry. He just said there should be no rust in the kernel.

You can ascribe bad faith motivations when someone presents technical objections that are already fully answered in the patch that was submitted, and when this is pointed out, they admit that, but don't retract their objections.

The original objections are specifically not a case of differing values or design ideas. They are nonsensical, the equivalent of 1 = 2.

> Okay, sorry. He just said there should be no rust in the kernel.

That's also not what he said; it's "no Rust in kernel/dma". He pretty much explicitly said it's okay for drivers to do their thing in Rust, but with their own wrappers. You can consider that dumb, but you can't shorten that to "no Rust in the kernel".

And "I replied to your objections, therefore the matter is settled" is arrogant beyond belief. People can disagree, you know, because they have different priorities, different preferences, different perspectives, etc.

No he did say he doesn’t want rust in Linux at all. Now I understand that he didn’t say “I won’t allow rust to be in Linux”, which is a useful distinction to make. But let’s not pretend like he didn’t say “rust shouldn’t be in Linux” at all.

https://lwn.net/ml/all/20250204052916.GA28741@lst.de/

He literally said this:

> Every additional bit that the another language creeps in drastically reduces the maintainability of the kernel as an integrated project. The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this. You might not like my answer, but I will do everything I can do to stop this.

https://lwn.net/ml/all/20250131075751.GA16720@lst.de/

> That's also not what he said; it's "no Rust in kernel/dma". He pretty much explicitly said it's okay for drivers to do their thing in Rust, but with their own wrappers. You can consider that dumb, but you can't shorten that to "no Rust in the kernel".

Have you actually taken a look at the patch?

There was NO RUST CODE ADDED TO kernel/dma, they wanted to add a dma wrapper to a rust/ folder.

> 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/

He said no Rust (or any other language except C) in any core code. Notably the patch was not eve being added to kernel/dma

I think he even hates non-C code in the drivers, he just cares less about that. But his position is that kernel maintenance will only work longterm if it's all a single language (C).

> "I replied to your objections, therefore the matter is settled" is arrogant beyond belief. People can disagree, you know, because they have different priorities, different preferences, different perspectives, etc.

I'm sorry for not being clearer, but that is specifically not what is going on. The objections were of factual, technical nature. As in, "do not do X". The problem is that the code in question was not doing X, and it was not doing anything that could be construed as doing X. The objections did not arise from differences in priorities, preferences, or perspectives, they were just factually wrong.

please stop spreading such highly misleading nonsense. look at what is black and white. blindly defending such toxic people is not doing linux any good.

It's pretty clear that the battle over rust is a power struggle. You can't take any of it at face value

So what are you saying? That it's okay to just invent quotes and spread misinformation about people, based on what you suspect their true thoughts might be?

You’re the one doing that by pretending that Hellwig is acting contrary to his own statements.

wait a second, I thought you are the one labelling people as "toxic" when completely ignoring the context that really matters.

He literally called "Rust" a "cancer".

I beleive he clarified in the same sentence that he was not calling the language Rust cancer... to quote "where this cancer explicitly is a cross-language codebase and not Rust itself, just to escape the flameware brigade"

So, to be more specific, he called Rust in Linux kernel source a cancer.

It needs to be a little more specific to be correct; a cross language codebase would be the cancer.

He literally did not. He literally explicitly said right there in the (in)famous "cancer" message that it didn't refer to Rust as a language.[1]

"And I also do not want another maintainer. 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)."

Stop spreading this kind of misinformation.

And no, I don't think he came off very well here, but please, give it a good faith reading.[2]

[1]: https://lwn.net/ml/all/20250128092334.GA28548@lst.de/

[2]: https://news.ycombinator.com/item?id=42977720

care to explain why the following patch that touches nothing got rejected?

rust/bindings/bindings_helper.h | 1 +

rust/kernel/dma.rs | 271 ++++++++++++++++++++++++++++++++

rust/kernel/lib.rs | 1 +

rejecting such patch is the exact cancer that need to cured. stop misleading people.

The reason patch got rejected is super simple: because this wrapper not lives in specific driver and depends on DMA subsystem internal API.

And this cause problem. When someone make any change to Linux kernel they suppose to fix all the code they break across all kernel. And if said wrapper accepted then maintaner of DMA will have to make sure that all patches he accepts also fix Rust parts.

So he just dont want extra burden for himself.

> because this wrapper not lives in specific driver and depends on DMA subsystem internal API.

if multiple rust based drivers all need to have DMA support, what should they do? each come up with their own little magic?

> And this cause problem. When someone make any change to Linux kernel they suppose to fix all the code they break across all kernel.

this has been explained like 10+ times in this thread - it was made crystal clear to the DMA maintainer that he/she doesn't need to maintain the rust stuff, it is totally okay to break it.

> So he just dont want extra burden for himself

he can just resign. simple and period. no one is ever forcing him/her to be the maintainer when he/she is literally forcing other people to stop developing Linux support for the only powerful & affordable ARM machine for home use.

> what should they do?

Sorry to ask, but couldn't it be solved with cargo? I hear all the time about the benefits of Rust tooling and zero-cost abstractions.

Why can't a driver just pull/include the latest-dma-bindings crate and glue the gap with zero-cost abstractions?

If kernel DMA code/API changes, then nothing breaks in the kernel (hopefully) and the "Rust devs will quickly solve the changes" theory can be really proven and tested by quickly updating the bindings AND the updating the drivers.

> that it didn't refer to Rust as a language.

No, he didnt refer to Rust as cancer, but to Rust in the Linux kernel / the R4L project.

Reply on news.ycombinator.com