My (minimally-informed) summary of the mailing list posts is that Hellwig thinks that the addition of Rust to the kernel is fundamentally bad because it [1]
> turns Linux into a project written in multiple languages with no clear guidelines what language is to be used for where.
And that
> Having worked on codebase like that 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.
Torvalds' position is that Hellwig doesn't have to like Rust or accept it in his subsystem at this point, but he has does have to accept that it will be part of the kernel [2]:
> 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".
Hellwig appears unwilling to accept that.
I think this is a reasonable position on both sides. If Linus wants Rust in his kernel, that's his choice. Memory safe languages are pretty much motherhood and apple pie at this point, and Linus very probably realises that Linux has to adapt or stagnate. On the other hand, if Christoph doesn't want to continue in a role that he sees as becoming mostly churn and pain, it's hard to blame him.
The real issue how strong and stable does his C api need to be?
If I maintain a (code level) api used in a single codebase I typically have a lot of flexibility. I can make “breaking” changes as long as I fix all the uses as the same time. This is really big advantage.
If the codebase has multiple languages using my api I will need to make changes in these other languages if I want to do this. This is a very real cost to me. It will tend to force me to have a really stable api with no breaking changes since I won’t realistically be able to fix them all myself.
> If the codebase has multiple languages using my api I will need to make changes in these other languages if I want to do this. This is a very real cost to me.
Current policy, at least in theory, is that the C interfaces can change as before and it's on the Rust maintainers to fix any issues on their side. From Linus's response:
> So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't have to deal with Rust.
I fail to see how this is a relevant question and "the real issue" with respect to Rust. How is this situation any different from a pure C kernel? There are already protocols on how this gets handled - maintain backwards compatibility and notify other maintainers of your changes, anticipated migration requirements, and any deprecations. To which the responsibility falls on the other maintainers C, Rust, or otherwise.
In practice (in general, not Linux specifically), you can make it all much faster and simpler by sending out the fixes for your change to impacted users. The ability to do this makes it much easier to change your api.
Except we are talking about Linux specifically, the "users" here in your analogy are people working in the collective kernel code, and there is a unique culture and set of practices around maintaining this because it's not some REST API where if something breaks you just shove a bug fix out for your part.
Certainly APIs exposed to userspace can’t ever break. But if a change can be completely hidden by fixing everything all at once (as a trivial example, renaming something) that should be ok, no?
I empathise. It's important in any large software project try to converge on one right way to do something, because inconsistency is bad for maintainability.
That being said, change is inevitable, so this desire for maintainability can't prevent all change.
It's a shame they couldn't find a way to balance these things.
Co-incidentally, I was just listening to the radio, where a former BP strategy employee was pinning the failure of BP's "Beyond Petroleum" strategy squarely on the difficulty of a company that is built to do activity X pivoting to also do (competing) activity Y. The recommended solution there was to spin off a new entity focused entirely on Y. It's hard not to draw a parallel.
The kernel did find a way to balance these things. Nothing is being rewritten in rust (nothing core, some modest drivers have been). Hellwig didn't have to worry about Rust at all, could have kept doing his thing.
If we accept this as the core concern:
> Having worked on codebase like that they are my worst nightmare, because there is a constant churn of rewriting parts from language A to language B
Then he has no need to fear, nothing in the foreseeable would have affected him in any way.
He didn't like that he didn't have control over what other people elsewhere were doing. But there was an extremely generous balance offered him, to be utterly unaffected in any way. And that wasn't good enough for him.
You're not wrong, but if one of the main Rust proponents and one of the main anti-Rust proponents both quit, that doesn't strike me as them finding balance.
Change is not inevitable in this lol. We all speak English here despite the fact that the language has many nits to pick. There's no inherent reason why C needs to be abandoned because some new thing came along and solves a few of the associated nits. C++ was never used for the Linux kernel despite the fact it solves many of C's problems and is far easier to integrate than Rust. Integration of Rust is a pet project that Linus and others have taken an interest in, not some absolutely groundbreaking or necessary change.
The difference between C++ and Rust is more akin to the difference between a standard pencil and a mechanical pencil lol. Also:
>In a similar vein, there's no inherent reason to use a calculator over doing calculations on paper.
Improved speed and reduced mental overhead are the main reasons people use calculators, not accuracy. This is because you can use any tool such as a calculator (or programming language) incorrectly.
I used to hear that the difficulty of relating CPU instructions to lines of C++ was the reason it wasn't suitable for the kernel. Now, all that has gone out the window (as Rust is definitely no simpler than C++), and they're making changes to the Rust language to suit the kernel application (as opposed to using something tried and true). It's a bad idea, but I expect it to be carried out to the point of absurdity.
> I think this is a reasonable position on both sides.
I disagree. Hellwig is trying to dictate who/how uses his subsystem/code. Linus makes it clear, you don't have to use/accept Rust in your own codebase, but you can't tell others what they can do in their codebase.
Whatever it is, Hellwig has used his freetime to maintain these modules. Usually that means that he has seen some value in that. Maybe he liked it. Maybe he hoped that he was doing some good and beneficial.
Now this change caused the total net value become negative. It was perfectly okay to express his opinions. Opinion was disliked and it is pretty okay, while sad, that he stopped maintaining it. Nothing to do with dictating.
You can reasonably disagree with the direction of a project that you're involved in, and you can withdraw from that project if it refuses to change direction.
C subsystem patches have started to be rejected by Linus because they break Rust builds despite the agreement that this wouldn't happen. That's why Hellwig switched from ignoring Rust patches sent to him for review to NACKing this one.
Hellwig did it, from what anyone can tell, to get Linus to publish the actual policy which he still hasn't done yet.
> C subsystem patches have started to be rejected by Linus because they break Rust builds despite the agreement that this wouldn't happen.
No. There was one instance of a toolchain issue accidentally including some Rust stuff when Rust was configured off, this was fairly quickly rectified. Linus even said in one of his more recent emails that this happens infrequently, but also, this happens all the time in general, and that’s why linux-next exists.
Linus did reaffirm the policy of “C folks are allowed to fully ignore Rust stuff.”
exactly; and i think Hellwig is on the wrong side of free software philosophy on this point. the fundamental philosophical core of free software is that the downstream user must be empowered to use the software as they see fit.
Well, no, the issue is that R4L isn't downstream. It's right there alongside the kernel, a part of the kernel, it's one combined project.
Someone can use your text parsing program to run a nuclear power plant, that's fine. The same person can't make you to accept the nuclear power plant control script as part of your repository, and support the "nuclear power plant controlling functionality" of your text parsing program.
Hellwig controls the DMA code. The Rust bindings use the DMA code. Hellwig is free to change the DMA code without considering whether or not it breaks the rust bindings. the rust bindings are not his problem, nor does he need to start maintaining any rust code.
from Linus:
> You are not forced to take any Rust code, or care about any Rust code in the DMA code. You can ignore it. [...] So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings.
sounds like it's structured as a downstream user to me.
He's allowed to reject Rust within DMA, which he maintains. What he wasn't allowed to do was veto code that was merely a user of DMA, on the basis of objecting to R4L in general ("I will do everything I can do to stop this"):
> The fact is, the pull request you objected to DID NOT TOUCH THE DMA LAYER AT ALL. It was literally just another user of it, in a completely separate subdirectory, that didn't change the code you maintain in _any_ way, shape, or form.
Here is the thread that likely sparked his resignation (if this is a resignation), and more specifically Linus’ response to Hellwig’s earlier comments regarding rust and the Linux kernel.
I agree – I'll need to look this up myself, but I'd love to know what his self-reflection on his annoyance involved: I admit that I still need to do the same to learn restraint during disagreements with new collaborators, that I haven't had the experience to feel trust with yet. My anger's stopped me from productively working in informal standardization efforts within my org.
The only person to get to have it both ways it seems is Linus. In the past he's railed against c++ and it would be cold day in hell to see c++ code in linux.
To be fair, it's his tree. On the other hand, I am a little worried that Linus has been hypocritical in the past few years, but most of us get soft as we age I guess.
It's a real shame that the drama led to so much real-world fallout.
Even though I feel pretty strongly that Christoph was in the wrong in this situation, it's impossible to deny that he is one of the most prolific and experienced kernel maintainers, so this is a real loss and not something to feel any schadenfreude about.
I hope all those stepping back can get some space to reflect and figure out a way to operate more productively going forwards.
someone else always does and they always have the same knowledge and skills. except in this case, hellwig had more experience coding in rust than his replacement.
That is on him, the R4L team offered many alternatives to work out his burden, assuring all the C interface breaking changes and build fails on Rust side would be their ultimate responsibility.
> turns Linux into a project written in multiple languages with no clear guidelines what language is to be used for where.
And that
> Having worked on codebase like that 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.
Torvalds' position is that Hellwig doesn't have to like Rust or accept it in his subsystem at this point, but he has does have to accept that it will be part of the kernel [2]:
> 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".
Hellwig appears unwilling to accept that.
I think this is a reasonable position on both sides. If Linus wants Rust in his kernel, that's his choice. Memory safe languages are pretty much motherhood and apple pie at this point, and Linus very probably realises that Linux has to adapt or stagnate. On the other hand, if Christoph doesn't want to continue in a role that he sees as becoming mostly churn and pain, it's hard to blame him.
[1] https://lore.kernel.org/rust-for-linux/Z7SwcnUzjZYfuJ4-@infr...
[2] https://lore.kernel.org/rust-for-linux/CAHk-=wgLbz1Bm8QhmJ4d...
reply