Comment by harshreality | Hacker News Reader

Comment by harshreality | Hacker News Reader

Parent Full thread

I think this is an important data point, too:

Gunthorpe [nvidia]: https://lore.kernel.org/rust-for-linux/20250130154646.GA2298...

Basically, there is concern that even with a declaration that Rust-for-Linux devs will maintain this (and potentially every other) cross-language API translation layer file, the demarcation point between C and Rust isn't sufficient, and is causing C developers lag or headaches by having PRs rejected because of Rust-side failures. I don't see how that can be fixed without wholesale buy-in to Rust of enough kernel devs that they can fix whatever Rust problems are created by C API changes. Or Linus will have to accept PRs that break Rust-enabled builds. The R4L devs, by themselves, don't have the bandwidth to keep up. Even if they can rapidly fix problems, that adds potential friction to every C API change.

Hellwig may not be communicating in a good way, but he might be right, unfortunately. Linux may need to stay as a C-only codebase until an AI language-translation tool is good enough to do things like maintain the Rust API translation layer itself. Or until basically all maintainers learn and accept Rust.

Greg replied and explained that this is a mischaracterization https://lore.kernel.org/rust-for-linux/2025013030-gummy-cosm...

You are misrepresenting the current state. The thread was unfortunately diverted before Jason's question received an appropriate response and conclusion: https://lore.kernel.org/rust-for-linux/20250131135421.GO5556...

> Then I think we need a clear statement from Linus how he will be working. If he is build testing rust or not.

> Without that I don't think the Rust team should be saying "any changes on the C side rests entirely on the Rust side's shoulders".

> It is clearly not the process if Linus is build testing rust and rejecting PRs that fail to build.

The matter and the question at heart is still unsettled. The answer of whether or not Rust being in a broken state is a blocker for working and valid C code will hopefully be addressed by the end of this cycle of development. Either the patches are accepted and Rust is truly allowed to be broken or the patches will not be accepted due to breaking the Rust builds. If it is the latter, as many of the C developers fear, that is the exact burden being placed upon them that they have been stressing very loudly that they have no interest in taking on. And once other maintainers see this, what is the inevitable response to this metastasization? Comments like those from Ted and Christoph will pale in comparison. The only bright side might be that this finally accelerates the inevitable demise of this failed Rust experiment so that all parties can move on with their business.

Let's say that we both agree that Linus should be making clear statements here, and that lack of clarity is causing lots of problems.

That one bug happened one time does not mean that the promise is broken. To be clear, it's a bad thing, but acting like this means the entire working rules are a lie is overreacting.

> That one bug happened one time does not mean that the promise is broken.

It's not been once. Don't you understand that is why things have gotten to this point? Are you aware of how the developers have been using Coccinelle in their workflows and how many subsystems support it? And are you aware that the Coccinelle for Rust implementation is constantly in a dire state? Have some empathy for the folks who have had their workflows broken and burdens increased because of it.

> Let's say that we both agree that Linus should be making clear statements here, and that lack of clarity is causing lots of problems.

Clarity will be communicated by the result of this patch set.

> Have some empathy for the folks who have had their workflows broken and burdens increased because of it.

Okay. Will you show empathy to the R4L folks constantly having sand poured into their fuel tank by kernel maintainers?

> Will you show empathy to the R4L folks constantly having sand poured into their fuel tank by kernel maintainers?

But the thing is, the kernel isn't "the R4L folks"' "fuel tank", is it? Doesn't the very name you use, "kernel maintainers", tell you that that's their "fuel tank"? Seems the people pouring sand into that are "the R4L folks".

Kernel maintainers aren't doing anything to R4L folks except where their activities intersect with the upstream linux kernel. Your analogy isn't right.

R4L folks thought that preliminary R4L infrastructure being accepted upstream meant that all the changes they needed in the future would be accepted easily as well, and now that there are concerns from subsystem maintainers, a few R4L folks are playing the dramatic victim card.

From what I understand, market pressures are causing R4L folks to panic. If they can't get more R4L stuff upstream, people can't ship Rust drivers, and R4L development falls apart.

That's not kernel maintainers' problem, though. They have a job to do to, and it has nothing to do with Rust kernel drivers except as far as they're persuaded Rust drivers help the linux community overall and will be maintainable without unacceptably disrupting their tool-assisted workflows. Several of them have concluded, so far, that R4L PRs will unacceptably disrupt existing workflows.

That's where R4L has failed. They've failed to persuade subsystem maintainers that some added headaches/retooling/efficiency-loss is worth it to enable Rust drivers. Which drivers, and who wants to use them? Perhaps the potential downstream users of those drivers can talk with kernel devs, persuade them it's really valuable, and figure out a plan?

> a few R4L folks are playing the dramatic victim card.

Not just 'a few R4L folks', these are basically the spearhead of the effort. And it hasn't been a single occurrence, we now have seen two of those Rust developers resign from the effort out of pure frustration from the entrenched, heels-in-the-sand attitude from kernel maintainers.

The same thing has happened in the past. I will point to TuxOnIce, which got stonewalled by a stubborn maintainer. It would have moved most suspend and hibernation code to userspace, where it would have been easier to maintain and iterate. Or right now we have two divergent RAM compression paths (Zram and Zswap). There are patches for Zram to use the unified Zpool API, but the Zram maintainer refuses to integrate these for absolutely no solid technical reason.

It seems that the R4L peoples are fine with doing any effort required, as long as they know it is not in vain. So far, comments akin to "language barriers in the kernel are a cancer" and "I will do everything to prevent/sabotage this" do not exactly build trust in that regard.

As an aside, would it really be so horrible for kernel maintainers to learn (some) Rust? This is not a dire ask for someone in the software world, your job will often ask this of you. And I can't imagine the maintainers haven't ever dabbled in other languages and/or aren't capable enough to learn a second language.

I understand the fear that saying "ok, we can do more languages than one" opens up the door to a third and fourth language down the road, but that seems unlikely. There's a reason Rust has passed Linus' sniff test where no other language has so far.

> Which drivers, and who wants to use them?

Short term it seems mostly GPU drivers.

Long, looong term (multiple decades?) the plan is probably to rewrite more important parts of the kernel, to significantly increase memory safety.

> language barriers in the kernel are a cancer

Well they are. Second class citizens like this just cause problems.

> As an aside, would it really be so horrible for kernel maintainers to learn (some) Rust?

Are the Rust folks planning to pay the existing kernel developers for spending that time? Because otherwise it should be up to those existing maintainers to decide and not something anyone else gets to demand.

Overall this just sounds like people crying that their hostile takeover of an existing project is being met with resistance.

> > a few R4L folks are playing the dramatic victim card.

> Not just 'a few R4L folks', these are basically the spearhead of the effort.

A "spearhead" is by definition a few people.

> As an aside, would it really be so horrible for kernel maintainers to learn (some) Rust?

If they want to contribute to the Linux kernel, would it really be so horrible for these Rust programmers to learn the language the kernel is written in?

> There's a reason Rust has passed Linus' sniff test where no other language has so far.

Doesn't seem it has, really.

> the plan is probably to rewrite more important parts of the kernel

So just fork it and rewrite it all in Rust.

No, because they are the once choosing to add this complexity to an existing project because of their own interests/ideals.

Calling memory safety an 'ideal' is like calling back-ups an 'ideal'. You can cast it off as a "nice to have", until you get bitten in the ass by a lack of it.

To quote myself[1]: I don't get why those Rustafaris do this in the first place. Like, if you want to contribute to a piece of software written in C, then write your contributions in C. If, on the other hand, you want a Linux kernel in Rust... Then just fork it and rewrite it in Rust. It's not as if that were a new idea, is it? Heck, most days it feels like about half the top headlines here are “<Software X> rewritten in Rust!” So why don't they just do that in stead of this constant drama???

[1]: https://news.ycombinator.com/item?id=42993961

I'm not sure this is fundamentally different from e.g. a complex filesystem implementation relying on a specific MM or VFS or whatever API, and a "C developer" wanting to change that API. Just because the callers are in C doesn't necessarily make the global change easy.

Reply on news.ycombinator.com