Comment by tsimionescu | Hacker News Reader

Comment by tsimionescu | Hacker News Reader

Parent Full thread

> Other than that, it's not a binary yes/no question; no one is really against some Rust in some parts of the kernel, but which parts? How? Where? That's the big disagreement. Linus has always been fairly hands-off on these types of disagreements.

Some Kernel maintainers are absolutely against Rust anywhere in the kernel tree [0]:

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

This is from Christoph Hellwig, the DMA maintainer. And is in fact what started the thread that led to Hector Martin quitting Linux. You can see other comments by Hellwig in that thread as well, he is extremely explicit - any Rust anywhere in the kernel is a big problem, and even if he can't stop it everywhere, he will do what he can to make it harder to use Rust by blocking it from the pieces he maintains.

[0] https://lore.kernel.org/rust-for-linux/20250131075751.GA1672...

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

If a maintainer of a major subsystem has those objections, it is a good chance to try to convince them otherwise.

If something is not clear, ask him to elaborate.

But blackmailing with a social media campaign is not productive. Even more it’s anti-productive. This just adds to rust=drama=stayaway feeling.

Oh, yes, the idea of settling anything on social media is horrible.

I was just pointing out that the positions are much more binary and un-nuanced than the previous poster was claiming, even in the thread in question. I'd bet the DMA maintainer is not the only one who holds this dogmatic position, either.

I'll also note that the complaints from this maintainer aren't even social though. He is very explicit in his reasoning: two+ languages bad, single language good. There's clearly little that will change this, other than working around him (though, again, I agree that social media blackmail certainly won't improve anything).

> He is very explicit in his reasoning: two+ languages bad, single language good. There's clearly little that will change this, other than working around him

I see you're not even considering the possibility that he might be right, so working around him would be bad.

___

ETA: I see on further reading that you are indeed acknowledging that possibility, good for you! I just didn't see that in this comment.

If you looks at the history then you will see that many different solutions have been proposed but Christoph's responses essentially boil down to 'do it somewhere else' and 'no not there', until it is basically 'not at all'. He is not in a position to make this decision, only Linus is. The patch as it stands lives outside of any sub-systems within Christoph's purview, he is simply being obstructionist out of tribalism.

> he is simply being obstructionist out of tribalism.

What about the part quoted in GPs comment?

> > The only reason Linux managed to survive so long is by not having internal boundaries, and adding another language complely breaks this

Wouldn't adding another language add an internal boundary? I don't know enough the kernel or kernel development to say it's an good argument or not, but it doesn't seem to be tribalism. I do know Rust already seems to be in some/few places in the kernel, but adding more would add more internal boundaries, as it'll get more and more divided. But again, maybe I don't understand clearly.

I agree that it may not be tribalistic, it's very possible that the maintainer has a valid technical/social opinion on this.

However, I don't think it is in any way acceptable to insert this in discussions about a random Rust patch. It's disrespectful to the time and expertise of the people who submitted these patches to first nitpick various technical items, only to later make it clear you were never going to accept their patch in the first place, because you dislike and oppose the decision that you know has already been made, to allow Rust in the kernel.

If he instead was (1) upfront about the fact that he would never allow Rust code in the subcomponent he maintains, and (2) stepped out of the discussion of this patch once it was moved out of said component, and then (3) started a completely separate thread on changing the kernel's stance on Rust to block all future patches and consider removing it entirely, that would all have been normal respectable behavior.

> The patch as it stands lives outside of any sub-systems within Christoph's purview

Wait what? Thought I saw somwehere that he's the DMA maintainer, and wasn't this a DMA patch?

> he is simply being obstructionist out of tribalism.

Or is it the Rust people who are being intrusionist out of their tribalism? Looks at least as much like that to me.

> wasn't this a DMA patch?

Although it was a DMA patch, it was not in the DMA subsystem that Christoph maintains. More specifically, it was not a file in the kernel/dma directory, but rather a file in the rust/kernel directory, which is where the Rust subsystem lives.

The Rust code is essentially a consumer of the DMA public API, much like many other subsystems in the kernel that consume it.

This is why some people are upset and confused about the situation; he added a Nacked-by tag to a patch that is outside his area. He had good reasons for it, but it was hard to see them based on the way he wrote his replies.

Aha, I see. Thanks!

It's not without merit. Two languages is an extreme cost in complexity compared to one, and you have to be a deep expert in both to fully figure out anything on the boundary.

Perhaps rusts potential benefits are worth it, but it's certainly possible to disagree with that

Sure, but (1) that ship has sailed for now, there are already Rust bits in the kernel; and (2) a patch email thread is not the best place to start discussing whether Rust has a place in the kernel.

Is it impossible to just delete the rust parts and go back to pure C?

That ship could come back to port anytime.

That's not a decision that can or should come out of a patch review. I agree it's a possible decision, not something unthinkable. But if it were, it should be taken at a completely different level.

Basically, it's an obstructionist, uncivilized thing to hold up every discussion about a topic that you get to participate in by insisting the topic shouldn't be discussed in this forum. It's perfectly OK to advocate for the removal of Rust from the kernel, it's not ok to bring this up in every random Rust patch while the consensus is that Rust has a place in the kernel.

The kernel doesn't really have a better system mechanism for having these sorts of decisions made unfortunately.

I would quite like my laptop to keep working, and half its drivers are rust…

The Linux drivers can be maintained in a downstream fork. Ultimately that seems to be what upstream wants, unfortunate as that may be.

Then you (and others interested in running Linux on fruit company hardware) can sponsor someone to rewrite those drivers in a way that fits the Linux project.

There are no Rust bits anywhere outside drivers, and hopefully that will continue to be the case. This means that mainline Linux kernel has no hard dependency on Rust whatsoever, which also means that Rust can be excised at any point with a minimum of effort.

I'm 100% behind Christoph, the last thing Linux needs is the extra complexity that Rust brings. I'm fairly optimistic that Rust will never be a hard dependency for the foreseeable future.

Reply on news.ycombinator.com