|
|
Subscribe / Log in / New account

Linus on Rust and the kernel's DMA layer

At the end of January we ran this article on the discussions around a set of Rust bindings for the kernel's DMA-mapping layer. Many pixels have been expended on the topic since across the net, most recently in this sprawling email thread. Linus Torvalds has now made his feelings known on the topic:

You are not forced to take any Rust code, or care about any Rust code in the DMA code. You can ignore it.

But "ignore the Rust side" automatically also means that you don't have any *say* on the Rust side.

You can't have it both ways. You can't say "I want to have nothing to do with Rust", and then in the very next sentence say "And that means that the Rust code that I will ignore cannot use the C interfaces I maintain".

The code in question seems highly likely to be merged for the 6.15 release.


to post comments

Pity he had to do this

Posted Feb 21, 2025 14:28 UTC (Fri) by rsidd (subscriber, #2582) [Link] (2 responses)

He seems to have pretty much said the same in private mail to Hellwig and Ojeda but Hellwig not only didn't agree but went public about the private mail. I don't see how that is healthy.

Pity he had to do this

Posted Feb 21, 2025 18:42 UTC (Fri) by NYKevin (subscriber, #129325) [Link]

Linus's email strikes me as entirely run-of-the-mill FOSS do-ocracy theory - if you don't work on [X], then you don't have a say in how [X] is done. For such a basic and foundational premise to generate such controversy is... not good.

I understand that maintainers are humans who have a finite amount of bandwidth. I understand that keeping a codebase alive and functional is difficult and thankless work. And I'm even willing to accept that sometimes, you have to reject perfectly reasonable code just because you don't have the developer-hours to deal with it. But it is rather bizarre and unworkable for one part of a project to dictate these things to another part of that same project, solely on the basis that the one calls into the other. Of course, Linus could always pull the plug on Rust, if he so chose, but you can't vest every maintainer of every subsystem with that kind of authority, because where does it end?

Pity he had to do this

Posted Feb 23, 2025 2:07 UTC (Sun) by jmalcolm (subscriber, #8876) [Link]

Kind of an extra dose of bad behaviour if, after Linus complained about "social media brigading", Christoph decided the right response was to publicly complain about Linus' communication.

Linus puts down the hammer

Posted Feb 21, 2025 14:36 UTC (Fri) by cen (subscriber, #170575) [Link] (11 responses)

just like in the good old days.

Linus puts down the hammer

Posted Feb 21, 2025 14:49 UTC (Fri) by kragil (guest, #34373) [Link] (9 responses)

It was more than necessary. All these Anti-Rust Bullshitters needed to told what time it is. Can’t wait for their next schemes to stop progress.

Linus puts down the hammer

Posted Feb 21, 2025 14:50 UTC (Fri) by kragil (guest, #34373) [Link]

/s/to told/to BE told

Linus puts down the hammer

Posted Feb 21, 2025 15:02 UTC (Fri) by ncultra (✭ supporter ✭, #121511) [Link] (5 responses)

> It was more than necessary. All these Anti-Rust Bullshitters needed to told what time it is. Can’t wait for their next schemes to stop progress.

None of the maintainers are scheming to stop progress. They are working very hard to keep progressing. None of them are "Bullshitters." Linus made a technical decision and communicated it clearly, he didn't "put down the hammer."

Linus puts down the hammer

Posted Feb 21, 2025 15:06 UTC (Fri) by kragil (guest, #34373) [Link] (3 responses)

Eye of the beholder.

Linus puts down the hammer

Posted Feb 22, 2025 15:57 UTC (Sat) by Wol (subscriber, #4433) [Link] (2 responses)

Well, in the eye of this beholder, Christoph works damn hard maintaining interfaces and apis. And trying to make the kernel a cleaner and better place to work.

Which is why I can't understand this storm in a teacup.

But hey ho.

Cheers,
Wol

Linus puts down the hammer

Posted Feb 23, 2025 2:16 UTC (Sun) by jmalcolm (subscriber, #8876) [Link] (1 responses)

Did you read the email from Linus? What part was not clear?

Other maintainers work hard too. They do not deserve to be completely blocked for reasons unrelated to design or code quality by somebody that does not agree with project decisions that have already been made above their paygrade.

Linus is quite clear. You have no authority over code you will not maintain (like USERS of your code). This maintainer somehow thought otherwise and was pulling absolute "never happening ever, ever, ever" rank over the contributions of others. Good people quit in frustration. The only possible resolution was for somebody with greater authority to break the tie.

What part of this response from Linus did you find unnecessary?

Linus puts down the hammer

Posted Feb 23, 2025 9:03 UTC (Sun) by Wol (subscriber, #4433) [Link]

> Did you read the email from Linus? What part was not clear?

I wasn't talking about Linus.

I simply do not understand Christoph's behaviour. How can he be doing such a good job in the area of API's, and yet blow up when other people try to help him?

Cheers,
Wol

Linus puts down the hammer

Posted Feb 23, 2025 2:09 UTC (Sun) by jmalcolm (subscriber, #8876) [Link]

It was not even a technical decision--it was governance.

In my view, it was good leadership by Linus and really great to see even if it came a bit later than some would like.

With luck, he has clarified things concretely enough to avoid similar shenanigans in the future and a reduction in noise around Rust in the kernel.

Assume good faith

Posted Feb 21, 2025 15:30 UTC (Fri) by corbet (editor, #1) [Link]

Can we please assume good faith on the part of the developers who have worked for many years to create the best kernel they can? This kind of name-calling helps nobody. Fortunately the people who are actually working on Rust in the kernel have taken a rather more respectful approach.

Linus puts down the hammer

Posted Feb 21, 2025 20:25 UTC (Fri) by marcH (subscriber, #57642) [Link]

I can't tell whether this comment is 1st or 2nd degree. There's no smiley but it is laughable.

Linus puts down the hammer

Posted Feb 22, 2025 14:02 UTC (Sat) by rsidd (subscriber, #2582) [Link]

> Just like in the good old days

Not really, this one was relatively professionally written, I thought. But "old Linus" resurfaces elsewhere in the thread. (unrelated to rust)

Dammit, I'm done with this discussion. We are not enabling that shit-for-brains warning. If you are a compiler person and think the warning is valid, you should take up some other work. Maybe you can become a farmer or something useful, instead of spreading your manure in technology.

And if you think warning about an extra "x < 0" check is about "security", you are just a joke.

Hellwig's position

Posted Feb 21, 2025 16:39 UTC (Fri) by runekock (subscriber, #50229) [Link] (50 responses)

Hellwig's position is much more understandable after reading his post in this thread (https://lwn.net/ml/all/Z7SwcnUzjZYfuJ4-@infradead.org/).

Especially this part:
"Having worked on codebase like that [two languages] they are my worst nightmare, because there is a constant churn of rewriting parts from language A to language B because of reason X and then back because of reason Z."

Hellwig's position

Posted Feb 21, 2025 16:51 UTC (Fri) by camhusmj38 (subscriber, #99234) [Link] (28 responses)

He also used the word cancer which is a little emotive.

Hellwig's position

Posted Feb 21, 2025 18:00 UTC (Fri) by mcon147 (subscriber, #56569) [Link] (27 responses)

Its a clinical description of a growth pattern

Hellwig's position

Posted Feb 21, 2025 18:11 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

Linux is a cancer, then?

Hellwig's position

Posted Feb 21, 2025 22:43 UTC (Fri) by Jannes (subscriber, #80396) [Link] (2 responses)

That's not at all anywhere near what was said.

> these bindings creep everywhere like a cancer

Hellwig's position

Posted Feb 21, 2025 22:44 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

So... Just like Linux? It's even in my freaking coffee machine!

Hellwig's position

Posted Feb 21, 2025 22:45 UTC (Fri) by mb (subscriber, #50428) [Link]

bindings = API users

Hellwig's position

Posted Feb 22, 2025 8:10 UTC (Sat) by ssmith32 (subscriber, #72404) [Link] (22 responses)

>Its a clinical description of a growth pattern

It's really not, especially in the context of the metaphor in question.

He already said it was growing everywhere, adding the metaphor about cancer only serves to add the additional connotation that the spread is disease-like, and a threatens the host.

Hellwig's position

Posted Feb 22, 2025 17:46 UTC (Sat) by hallyn (subscriber, #22558) [Link] (21 responses)

I've heard this several times, and wonder what kind of culural shift this is. The idea that I can't use any words bearing the slightest negative connotation is downright dystopian. Christoph's point in this case was respectfully made. As Linus made clear, he was out of line wrt what he had authority to nack. But "cancer" was an accurate methaphor for his concern. That (he thinks) it "threatens the host" (as you said) is precisely his point. So argue against that, not the choice of word.

James Bottomley has some good suggestions on how to address the problem of pure c patches breaking the rust build. That holds promise.

I'm waffling on whether to post this or whether it's off topic, but given that the next sentence usually involves CoC and that very much affects linux kernel dev, maybe it is on topic.

Hellwig's position

Posted Feb 22, 2025 19:02 UTC (Sat) by Paf (subscriber, #91811) [Link] (17 responses)

Cancer has *extremely* negative connotations and specifically refers to unbenign examples. It’s not just a word with a moderate connotation.

Hellwig's position

Posted Feb 22, 2025 21:56 UTC (Sat) by hallyn (subscriber, #22558) [Link] (5 responses)

And most of us have lost family, friends, and mentors to it. It's a horrible thing. Still neither you nor anyone else has the right to tell anybody that they cannot use the word, even if referring to and denigrating your favorite project.

Hellwig's position

Posted Feb 23, 2025 1:40 UTC (Sun) by Paf (subscriber, #91811) [Link] (2 responses)

I don’t think this is about rights - there is a point where language usage is intended to denigrate as much as inform. Ie, when a conversation becomes more about having a fight than discussing. The use of very emotive language is one sign of this and it’s not unreasonable for particular places to suggest it’s inappropriate sometimes.

In other words if a word is intended to express seeing red and make those who read it see red, maybe it shouldn’t be in a technical discussion regardless of meaning. Context and nuance matter here too.

Hellwig's position

Posted Feb 26, 2025 4:55 UTC (Wed) by DimeCadmium (subscriber, #157243) [Link] (1 responses)

Is the word "cancer" really "intended to make those who read it see red"? Seriously?

Hellwig's position

Posted Feb 26, 2025 5:30 UTC (Wed) by intelfx (subscriber, #130118) [Link]

Uness you are discussing medical practice, yes.

Hellwig's position

Posted Feb 23, 2025 2:03 UTC (Sun) by NYKevin (subscriber, #129325) [Link]

This is not about freedom of speech. This is about not being a complete jerk.

You have the right to say horrible things to everyone around you. But as a mature adult, you have the responsibility to think about the consequences of doing that. Everyone around you has the right to decide that they don't want to work with people who say horrible things on a regular basis (or even once, if they are so inclined). That's just the other side of the free speech coin - freedom of association. If group A does not want to put up with person B, then they are not obliged to do so.

Codes of Conduct, flawed as they may be, are ultimately just a way of writing down exactly how nasty someone has to get before we all agree to stop talking to them. There can be no infringement of anyone's rights in doing that.

Hellwig's position

Posted Feb 23, 2025 4:01 UTC (Sun) by motk (guest, #51120) [Link]

I absolutely do have that right, and that obligation. YCombinator is over there somewhere.

Hellwig's position

Posted Feb 23, 2025 12:14 UTC (Sun) by rbranco (subscriber, #129813) [Link] (10 responses)

Rust's mascot is a crab. Cancer is the Latin word for crab. It was a pun.

Hellwig's position

Posted Feb 23, 2025 14:13 UTC (Sun) by Wol (subscriber, #4433) [Link] (9 responses)

That connotation didn't hit me. But is Christoph German?. It would be obvious to them because it's the same word - Krebs.

Cheers,
Wol

Hellwig's position

Posted Feb 27, 2025 5:44 UTC (Thu) by PeeWee (guest, #175777) [Link] (8 responses)

I guess he is German but so am I and those are not synonyms. The German word for "crab" is "Krabbe" and the one for "cancer" is "Krebs"; but not all "Krebs" is cancer (the disease), it may also mean "crayfish", the animal of the the crustacean family.

And there really is no argument convincing anybody that Hellwig's use of the word "cancer" in this context did not have all the *intended* negative connotations as described above. It basically boils down to: "Rust is cancer, the disease that, if untreated, kills the host, so needs to be fought tooth and nail". BTW, the real life "cure" (chemo therapy) often kills the host as well.

Hellwig's position

Posted Feb 27, 2025 8:01 UTC (Thu) by Wol (subscriber, #4433) [Link] (7 responses)

> BTW, the real life "cure" (chemo therapy) often kills the host as well.

Because, unfortunately, "host" is the wrong word ... a host implies a pathogen/predator, but here the disease is a malfunctioning host (okay, caused by a pathogen in some cases, such as herpes). But my research makes me think there's a very simple explanation for the massive rise in cancer today - cancer is basically gene malfunction. The natural mechanism for switching genes on and off is to attach or detach sugars at the appropriate site. And what's the other massive new scourge today? Type II diabetes - uncontrollably high sugar levels. So we end up with the biological equivalent of a bunch of kids running amuck turning light switches on and off, with random (and sometimes unfortunate) results.

Cheers,
Wol

Hellwig's position

Posted Feb 27, 2025 8:59 UTC (Thu) by PeeWee (guest, #175777) [Link] (3 responses)

That may be an explanation but I am not well versed in these matters. But one thing came to light just recently which explains why the "cure" often kills the patient as well and it is kind of similar to the current scourge of "Ai" idiocy. It is rather stupidly simple: the criterion to make a chem cocktail a "good candidate" was, and still often is, "does it kill the cancer"? And statistically illiterate pharma people simply looked at those numbers, failing to see that this is only the *necessary* criterion, with the *sufficient* criterion being "patient lives". Or maybe it's the other way around; necessary: patient lives, sufficient: cancer dies.
This is one more example that people fail to understand the moral of the story about the "Genie in a bottle", which takes your wishes all too literal. And, to close the circle, that is the same with "Ai" (LLM): "fool a Turing test", was the wish, basically. More precisely, the criterion is to produce grammatically sound sentences; nobody said anything about the content of those, hence "hallucinations", which is just another lie people swallow to convince themselves of some kind of "ghost in the machine".

Hellwig's position

Posted Feb 27, 2025 9:53 UTC (Thu) by rschroev (subscriber, #4164) [Link]

Quite off-topic but I'd say both "patient lives" and "cancer dies" each on itself are necessary but not sufficient conditions; the combination "patient lives" AND "cancer dies" is a necessary and sufficient condition.

Hellwig's position

Posted Feb 27, 2025 10:18 UTC (Thu) by stijn (subscriber, #570) [Link] (1 responses)

> But one thing came to light just recently

Citation needed because ...

> It is rather stupidly simple: the criterion to make a chem cocktail a "good candidate" was, and still often is, "does it kill the cancer"? And statistically illiterate pharma people simply looked at those numbers, failing to see that this is only the *necessary* criterion, with the *sufficient* criterion being "patient lives"

Really, people in the life sciences have a pretty good grasp of statistics, and tend not to have oversights like this. This view of the world puzzles me.

Hellwig's position

Posted Feb 27, 2025 11:23 UTC (Thu) by Wol (subscriber, #4433) [Link]

> Really, people in the life sciences have a pretty good grasp of statistics, and tend not to have oversights like this. This view of the world puzzles me.

So why do doctors continue to make stupid blunders? The answer (in the light of my advanced years) is (a) lack of experience, and (b) being bombarded by ignorant advertising. Take for example Ibuprofen is regularly prescribed for period pain. Yet apparently women were excluded from the trials "because hormones interfered with the pain killing"!!!

If we're going on about Chemo, the chemical cocktail targets rapidly dividing cells. So giving someone Chemo at night when the body in general (but not cancer cells) generally shuts down, is likely to be far more effective. Likewise womens bodies change in line with their periods. I believe that there is plenty of evidence that giving chemo at night is far more effective, as is timing it in line with womens periods. But people get called in for Chemo because it's convenient for the hospital - during the day, no attention paid to what state the patient's body is in.

And - with a different illness - I live that tragic reality every day! There is plenty of evidence that taking medication "as required" is far more powerful and effective than taking it on a rigid schedule - so why is it so many patients come out of hospital with their chronic conditions made MUCH worse, because the doctors and nurses focus on the ACUTE condition? And won't allow patients to self-medicate, but rigidly give them their tablets on the regular drug-round? Sadly, that's reality :-(

Cheers,
Wol

Hellwig's position

Posted Feb 27, 2025 10:34 UTC (Thu) by stijn (subscriber, #570) [Link] (2 responses)

> But my research makes me think there's a very simple explanation for the massive rise in cancer today

I know this is getting quite off-topic, but huge claims dismissing entire fields of research deserve calling out.
You're not the first and you will not be the last. The simple explanations tend to vary and wrongly focus on a single thing.
World health organisation:

"Around one-third of deaths from cancer are due to tobacco use, high body mass index, alcohol consumption, low fruit and vegetable intake, and lack of physical activity. In addition, air pollution is an important risk factor for lung cancer."

- there are likely many factors at work.

> The natural mechanism for switching genes on and off is to attach or detach sugars at the appropriate site

Ummmm, these are words and 'gene' and 'sugar' are among them, but I'm pretty sure not much can be drawn from this.

Hellwig's position

Posted Feb 27, 2025 12:25 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

And where I am dismissing large fields of research? You are conflating cause, effect, and mechanism.

> "Around one-third of deaths from cancer are due to tobacco use, high body mass index, alcohol consumption, low fruit and vegetable intake, and lack of physical activity. In addition, air pollution is an important risk factor for lung cancer."

Alcohol consumption (a cause, along with over-eating) leads to high BMI (an effect). There is a very strong correlation between these two and high blood sugar aka diabetes (presumably another effect).

And then high blood sugar gives us a blindingly obvious mechanism for causing cancer.

And while this is just circumstantial evidence, it's worthy of future research - we had a high-profile athlete with cancer a few years back. Every time she went into training for some charity thing - ie exercising hard and driving blood sugar down - her cancer went into remission. Sadly it finally won, but four or five remissions all correlated with a marathon or long-distance cycle or some other high-exercise situation?

To me it just seems blindly obvious that blood sugar is the MECHANISM behind cancer. There may be multiple causes, and multiple fixes, but eating and drinking (and imho snacking in particular) too much just seems the obvious *preventative* thing to target.

Cheers,
Wol

Hellwig's position

Posted Feb 27, 2025 14:01 UTC (Thu) by daroc (editor, #160859) [Link]

In my experience, everything in biology is hopelessly circular spaghetti code. Everything partially causes everything else, and trying to tease individual factors apart requires specialist knowledge that I, at least, don't have.

This is definitely off-topic for LWN, though; the discussion of Hellwig's use of metaphor was barely on topic, this is clearly past that line. Let's leave this discussion here, and the systematic reform of the research sciences to the research scientists.

Hellwig's position

Posted Feb 22, 2025 21:07 UTC (Sat) by koverstreet (✭ supporter ✭, #4296) [Link] (2 responses)

It's not about connotation.

When you have the kind of stature that, say, I or Christoph have, you can't just be voicing your own personal opinions: the opinions and thoughts that we share carry real weight.

People act and react based on what we say. If we share our thoughts well, it can motivate a huge amount of useful and productive work on the part of others. If we share our thoughts poorly - without due consideration, or in an outburst - good and productive work may stop, people get frustrated, and they may even leave.

We're well past the point where "rust is cancer" is a point of view with any standing whatsoever. Rust is the future, more than enough people have bought into it, it's going to happen, and it's going to be worth it; it's going to make all our lives better 10 years out.

But it's still in the early stages and the people doing the actual work on the ground are younger, with a lot of energy, but without the standing to fight every battle on their own - if key maintainers are going to put of fights. This work needs support.

IOW - someone being petulant can cause a lot of problems. If you want to be one of the respected elders, don't act like a petulant dick.

Hellwig's position

Posted Feb 26, 2025 9:50 UTC (Wed) by ljsloz (subscriber, #158382) [Link] (1 responses)

With respect Kent, might I suggest a little humility + self-reflection?

Hellwig's position

Posted Feb 26, 2025 14:26 UTC (Wed) by draco (subscriber, #1792) [Link]

As someone who has also had to learn this lesson, this *is* the result of a lot of self-reflection

Hellwig's position

Posted Feb 21, 2025 17:17 UTC (Fri) by khim (subscriber, #9252) [Link] (2 responses)

> Having worked on codebase like that [two languages] they are my worst nightmare, because there is a constant churn of rewriting parts from language A to language B because of reason X and then back because of reason Z

And nothing like that ever happens in single-language project? Seriously?

These things are happening routinely in any big project, the only difference is that when only one language is involved there are no big drama language drama and no language-related name-calling. That's it.

The only way to stop such churn is to freeze everything and stop the development.

Hellwig's position

Posted Feb 21, 2025 17:31 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

And the problem wasn't two languages, it was two conflicting C APIs.

However, from what I've seen of Christoph's work over the last few years, a large chunk of what he's been doing appears to have been cleaning up exactly this API mess in C, so I can understand him being touchy.

I do think his reaction was a case of "shoot the messenger", though :-(

Cheers,
Wol

Hellwig's position

Posted Feb 21, 2025 18:08 UTC (Fri) by ma4ris8 (subscriber, #170509) [Link]

I can see similarities between Linus and maintainer, when reading message as a whole,
and something positive, like maintainer wants to mention
experienced setbacks, and proceeds into constructive side in the end.

Both want to give constructive space for each side, for being able to be at their best,
at least from my rosy glasses point of view,
and both try to protect each side to have burnout, and enable continue the hobby,
or work.

Hellwig's position

Posted Feb 21, 2025 19:59 UTC (Fri) by Phantom_Hoover (subscriber, #167627) [Link] (7 responses)

Regardless of the merits of Hellwig’s arguments for his position, his stated goal of foisting it on everyone else by abusing his role as maintainer to sabotage Rust integration wherever possible was completely unacceptable. It’s an insane organisational guerilla warfare tactic against other developers which severely undermines his status as a good faith contributor.

Hellwig's position

Posted Feb 22, 2025 8:22 UTC (Sat) by ssmith32 (subscriber, #72404) [Link] (6 responses)

>Regardless of the merits of Hellwig’s arguments for his position, his stated goal of foisting it on everyone else by abusing his role as maintainer to sabotage Rust integration wherever possible was completely unacceptable. It’s an insane organisational guerilla warfare tactic against other developers which severely undermines his status as a good faith contributor.

To be fair, while we're calling out over-the-top metaphors, "guerilla warfare" is a bit much.

The dude tried to NACK something outside of his subsystem and was reminded by the person who actually had the authority to NACK anything being pulled into Linus' branch that was not how things work.

He tried to assume a power he never had, and never will have, sure.

If he was in a position to have his NACK have any affect beyond causing a media circus, I'd be more amenable to your metaphorical hyperbole.

But as it stands, this is more of an "old man shakes fist at cloud" situation (and then is reminded by the weather god that he only is in charge of his puddle, that contributes to the humidity levels, sure, but is certainly not in charge of determining what water sources can contribute to cloud formation to _really_ stretch the metaphor), rather than guerilla warfare.

Hellwig's position

Posted Feb 22, 2025 9:11 UTC (Sat) by dottedmag (subscriber, #18590) [Link] (1 responses)

He apparently has the power to push another maintainers off the project by making it so tiresome to try to upstream anything that uses code of the subsystem he maintains. Having a patch NACKed and then waiting for Linus to step in and override the maintainer is not a healthy development process.

Hellwig's position

Posted Feb 22, 2025 12:54 UTC (Sat) by kragil (guest, #34373) [Link]

No it isn't, but a lot of people really don't want to change and even more people have sympathies for this kind of behavior (just look at the LWN comments). So it will continue and will get worse.

But these are the times we live in, I guess.

Hellwig's position

Posted Feb 22, 2025 11:15 UTC (Sat) by Phantom_Hoover (subscriber, #167627) [Link] (3 responses)

> If he was in a position to have his NACK have any affect beyond causing a media circus, I'd be more amenable to your metaphorical hyperbole.

The Rust DMA bindings didn’t get merged! That’s the effect this whole drama revolves around!

Hellwig's position

Posted Feb 22, 2025 19:56 UTC (Sat) by airlied (subscriber, #9104) [Link] (2 responses)

They haven't been submitted for merge, that are still in review stage

Hellwig's position

Posted Feb 22, 2025 22:23 UTC (Sat) by Phantom_Hoover (subscriber, #167627) [Link] (1 responses)

I'm not super familiar with the formal process but everyone's reactions, and LWN's own reporting, indicate that Hellwig's NACK was a de facto blocker for the changes until Linus overrode him. So this idea it was a lot of drama over nothing seems unfounded: useful work from the R4L team was being held up by Christoph's position.

Hellwig's position

Posted Feb 23, 2025 11:00 UTC (Sun) by Wol (subscriber, #4433) [Link]

The thing with a NACK is it almost always is a blocker.

But if you're going to NACK something, you need the authority. For example, as somebody who hasn't actually done an awful lot of *code* in Open Source, I might nack changes to code I wrote. I have nacked changes to documentation I've written. As the guy who basically ran the kernel raid wiki for years I've only once felt the need to nack a change, but I certainly felt I had the authority. I'm glad I never had to use it.

So it's a shame Linus had to step in and declare this a case of "power without authority". Because Christoph certainly has authority. A lot of it. But there's a lot of people stepping outside the bounds at the moment :-(

Cheers,
Wol

Hellwig's position

Posted Feb 22, 2025 13:00 UTC (Sat) by kragil (guest, #34373) [Link] (5 responses)

That argument only counts once a part of the kernel that was Rust was rewritten in C.

Has that really happened?

Hellwig's position

Posted Feb 22, 2025 13:12 UTC (Sat) by pizza (subscriber, #46) [Link]

> That argument only counts once a part of the kernel that was Rust was rewritten in C.
> Has that really happened?

So "a part rewritten in Rust" doesn't count?

Meanwhile, the Linux kernel isn't the only large codebase out there.

(FWIW, I've personally experienced this "rewrite back and forth" on multiple occasions over my career, and it's every bit as awful as Hellwig mentions)

Hellwig's position

Posted Feb 23, 2025 2:37 UTC (Sun) by jmalcolm (subscriber, #8876) [Link] (3 responses)

Taken at face value, Linus is saying three things:

1) You cannot block Rust code that simply calls into your code

2) You can block the inclusion of Rust in the code that you maintain

3) You can mix C and Rust code if everybody agrees on how that will work. It is up to the individual maintainer.

What he does not say is that you can also completely replace a C subsystem with Rust if the powers that be see the Rust implementation as superior. I would expect this to require a better design and not just a re-implementation of the same ideas in a new language. Still, I expect this to happen eventually. Of course, you could completely replace Rust with C as well I would think (again, given the same requirement to be better).

As happens with C code, there will likely be competing implementations at some point that can be optionally compiled in (maybe a Rust scheduler or memory manager). I would think it would be allowed as long as it was possible to build the kernel without it. And, if it is better, the default could change in the future, at which point the kernel could not really be built without it. But that seems a long way away. For one thing, there is not yet a Rust compliler that can target all the platforms that Linux supports.

Hellwig's position

Posted Feb 23, 2025 20:39 UTC (Sun) by NYKevin (subscriber, #129325) [Link]

> I would expect this to require a better design and not just a re-implementation of the same ideas in a new language.

Rust has a stricter aliasing model than C, so a straight re-implementation might actually have slightly better performance, depending on what part of the kernel we're talking about and how good LLVM is at taking advantage of noalias. You could therefore argue that the re-implementation is already superior even without a redesign.

But the same is also true of Fortran, and I can't imagine Linus merging a patch that rewrites something in Fortran, even if it was faster. So the question is whether Rust is considered acceptable enough to justify using it for small performance gains, or if it needs to offer more substantial benefits in order to be accepted.

The other, more straightforward problem, is that rewriting things costs a lot of developer-hours, and I don't see anyone lining up to pay for that work just to get a tiny increase in performance, so at best it would be done in somebody's spare time. More realistically, it would not be done at all.

Hellwig's position

Posted Feb 24, 2025 7:52 UTC (Mon) by khim (subscriber, #9252) [Link] (1 responses)

> Still, I expect this to happen eventually.

This have already happened: the plan now is to reimplement that functionality within the Rust code using workqueues instead.

Hellwig's position

Posted Feb 24, 2025 12:53 UTC (Mon) by nix (subscriber, #2304) [Link]

That's not what that article says. They're reimplementing something in the Rust code that exists in the C DMA layer, but they're not *replacing* that code in the DMA layer: other callers will continue to use it. This is perfectly normal "replace something that is generic but doesn't quite do what we want with something closer to our code that can be modified without running the risk of breaking other stuff", i.e. it's more or less the *opposite* of what you suggest (a rewrite of the generic stuff).

Hellwig's position

Posted Feb 22, 2025 17:17 UTC (Sat) by k3ninho (subscriber, #50375) [Link]

His position is made explicit, but it also looks like there's a critical lack of redundancy maintaining the DMA subsystem. Both for working with Mr Hellwig and for what happens if Mr Hellwig no longer participates in maintaining the DMA subsystem.

K3n.

Hellwig's position

Posted Feb 23, 2025 2:21 UTC (Sun) by jmalcolm (subscriber, #8876) [Link] (2 responses)

His opinion makes sense. Nobody is calling him out on his opinion or his right to have it. In fact, deference to this point of view is why Linus is saying maintainers do not have to accept Rust into C code that they maintain.

In this case, the code being blocked was not code that the maintainer was going to have to maintain and his reasons for blocking it were in opposition to the previously decided direction of the project. So no, his actions made no sense at all and completely exceeded his authority.

Which is exactly what Linus says.

The position, "I think mixed code bases are a mistake, therefore I refuse to allow the Linux Project overall to pursue its stated goal of creating a mixed code base" is not defensible.

Hellwig's position

Posted Feb 24, 2025 8:31 UTC (Mon) by zorro (subscriber, #45643) [Link] (1 responses)

Hellwig's position is understandable, though. He is afraid that unencumbered redesign of the C code will not be possible anymore once too much Rust code starts to depend on it. Sure, Linus may proclaim that this is not a concern of the C code maintainer, but the more Rust code ends up in or near the kernel, the more the C code will be restricted in what it can and cannot do. The end game is either a Frankenstein of a kernel, or a kernel that is entirely written in Rust and Rust-compatible C.

Hellwig's position

Posted Feb 24, 2025 8:58 UTC (Mon) by Wol (subscriber, #4433) [Link]

> The end game is either a Frankenstein of a kernel, or a kernel that is entirely written in Rust and Rust-compatible C.

Of course. The alternative - which is what sparked off this whole mess - is a kernel with inconsistent APIs written in buggy C.

Don't forget - this whole thing was sparked off because there were TWO (maybe more) C users of the code in question, that were using it in two different incompatible ways. So one of them was clearly buggy. The Rust guys wanted a clear, well-defined API. Surely that's not a problem to ask? More importantly, surely the language is irrelevant to that ask?

Cheers,
Wol

People do seem to be changing their minds . . .

Posted Feb 22, 2025 0:58 UTC (Sat) by himi (subscriber, #340) [Link] (2 responses)

Elsewhere in that thread it's actually really nice to see that one of the people who was fairly vocal in his concerns about Rust in the kernel seems to have changed his mind with further discussions - Ted Ts'o in the brief side-thread starting at https://lwn.net/ml/all/20250219170623.GB1789203@mit.edu/ is clearly a lot more comfortable with the idea now than he was in the past.

For what seems on the face of it like a very technical issue, this is clearly something that's become extremely emotionally charged - that makes the debate difficult on all sides. But it's also clear that reaching a resolution that's ultimately beneficial for all is possible, even if has to proceed one individual at a time. Hopefully getting to that point doesn't burn out too many people on the way . . .

People do seem to be changing their minds . . .

Posted Feb 23, 2025 4:28 UTC (Sun) by motk (guest, #51120) [Link] (1 responses)

He's calmly pretending his behaviour on the day was just some quibble with the presentation, and that he didn't behave in an extraoradinarily unproffesional manner. Unimpressed.

People do seem to be changing their minds . . .

Posted Mar 19, 2025 16:26 UTC (Wed) by sammythesnake (guest, #17693) [Link]

That's a possible narrative, but I'd prefer to assume a more charitable/optimistic narrative - that he's simply trying to move on from a bad reaction[1] toward a better one[2].

I know that I've reacted badly to various things in my life and when I've tried to move on to replace that reaction with a better one, I've been really appreciative of people making that easier by putting to one side their own (understandably negative) emotional reactions to mine. The alternative scenario being that the emotional hurt I caused by my immoderate reaction being an impediment to healing and moving onward.

I try (with qualified success!) to live by this. In my experience, the times I give the benefit of the doubt and it turns out to be a mistake are rarer than my instincts expect. Even if the doubt isn't justified, it'll often redirect an unhelpful emotional situation. If the benefit off the doubt isn't justified, and the person you have it to isn't softened by being given it, and continues to be antagonistic, the cost of waiting out another couple of interactions before deciding the problem is not one I can help by being optimistic is really not that much, either.

I often talk of my "Brain Goblins" - those aspects of my thinking/feeling that are immoderate & unwise, and of how "being an adult" means hearing those voices without putting them in charge. It's like when I'm driving and my 4yo says "let's crash the car, it's funny!" and my job is to say "no"[3]. The difference is that the "Brain Goblins" are *internal* and it's easy to forget that they're *still not the ones in charge*!

[1] Generally, and I suspect in this case, this is often fuelled by our quick, strong, but not very moderate/wise emotional reactions.

[2] I.e. one that recognises and acknowledges, but coralles those emotional reactions with the benefit of our wiser and more moderate (but slower and less forceful) *considered* thought process.

[3] True story!

The process...

Posted Feb 22, 2025 8:27 UTC (Sat) by ssmith32 (subscriber, #72404) [Link] (2 responses)

works..

I mean, I definitely see room for improvement, but, overall, another point in favor of the argument that the Linux development process basically works, and is resilient to various human foibles.

The process...

Posted Feb 24, 2025 1:13 UTC (Mon) by ikm (guest, #493) [Link] (1 responses)

It kind of didn't work though, in that that Linus had to intervene in the end. Unless him intervening is a core part of the process, of course. To that end, I'm not even sure what the process *is* supposed to be. Hope that the parties involved would figure what is right between themselves, and intervene if that doesn't seem to be working? Sounds like a right approach, but hardly something special. In the end it's Linus's kernel, so it's him who ultimately calls the shots.

The process...

Posted Feb 24, 2025 7:44 UTC (Mon) by khim (subscriber, #9252) [Link]

> In the end it's Linus's kernel, so it's him who ultimately calls the shots.

Yes, but…

> Sounds like a right approach, but hardly something special.

It may not sound “special”, but it works. If you look on other projects then you'll see significantly more “drama” and forks and tears. Recall just Rust language: how many developers have burned out and left?


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds