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".
> 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.
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.
> 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.
> 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.
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.
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?
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"
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]
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.
> 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.
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.
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".