Marek has graciously offered to maintain the dma-mapping tree
lore.kernel.org
lore.kernel.org
> 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...
> 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.
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.
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.
The fact that he was not allowed to do that is exactly why he escalated.
> 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.
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.
Maybe he got a lot of professional mileage from being "the" Christoph Hellwig, Linux DMA maintainer. Independent consultants need publicity.
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.
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.”
For anyone else who never heard of this saying:
> The phrase motherhood and apple pie denotes a core principle, value, belief, characteristic, aspect, etc., of the U.S.A. or its citizens.
Then they should use a memory-safe language and not rust.
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.
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.
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.
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.
>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.
https://lore.kernel.org/rust-for-linux/CAHk-=wgLbz1Bm8QhmJ4d...
(Edit to include the correct name)
Old linus would have ticked off for even less, along with name calling and personal attacks.
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.
Having used both, I agree.
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.
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.