Marek has graciously offered to maintain the dma-mapping tree
43 comments
·February 26, 2025gnfargbl
Semaphor
> Memory safe languages are pretty much motherhood and apple pie at this point
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.
rurban
> Memory safe languages are pretty much motherhood and apple pie at this point
Then they should use a memory-safe language and not rust.
mherkender
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.
gnfargbl
I also empathise, for the same reasons.
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.
lokar
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.
Ukv
> 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.
drpossum
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.
lokar
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.
GiorgioG
> Hellwig appears to be unwilling to accept that.
> 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.
nicce
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.
toyg
> Maybe he liked it.
Maybe he got a lot of professional mileage from being "the" Christoph Hellwig, Linux DMA maintainer. Independent consultants need publicity.
gnfargbl
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.
beardyw
You can't call resigning "dictating". He has free will.
monocasa
It's not the resigning that was the dictating; it was the NACKing patches.
subsistence234
Or am I missing something?
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.
steveklabnik
> 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.”
woodrowbarlow
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.
amiga386
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.
wronex
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.
https://lore.kernel.org/rust-for-linux/CAHk-=wgLbz1Bm8QhmJ4d...
(Edit to include the correct name)
rokob
Linus seems unusually reasonable and kind in that response.
flykespice
It seems his leave of absence has given fruits.
Old linus would have ticked off for even less, along with name calling and personal attacks.
theiebrjfb
[flagged]
throw7
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.
steveklabnik
What is both ways about it here? The argument against C++ was never about a multi-language codebase being unacceptable.
Filligree
Linus seems to genuinely believe that Rust is superior to C++.
Having used both, I agree.
dralley
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.
GiorgioG
Some else will step up if he doesn't change his mind.
dralley
Well someone already has, as per the title. But I would hope he at least stays on as a contributor.
subsistence234
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.
hu3
For posterity. The Phoronix.com link was posted 3 hours ago.
Havoc
Can’t say I’m surprised. Didn’t seem like a workable situation for him
flykespice
> Didn’t seem like a workable situation for him
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.
ur-whale
Looks to me like psycho-rigidity is a key attribute of being a kernel dev.
Pet_Ant
Yeah, is this a resignation? I'm guessing so from the context, but it's not that clear.
rurban
Just from the dma mappings. He still maintains large parts of many filesystems.
high_na_euv
It is so hard to read those mailing lists, ffs
null
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.
[1] https://lore.kernel.org/rust-for-linux/Z7SwcnUzjZYfuJ4-@infr...
[2] https://lore.kernel.org/rust-for-linux/CAHk-=wgLbz1Bm8QhmJ4d...