- cross-posted to:
- linux@lemmy.ml
- asahilinux@lemmy.world
- cross-posted to:
- linux@lemmy.ml
- asahilinux@lemmy.world
Hellwig is the maintainer of the DMA subsystem. Hellwig previously blocked rust bindings for DMA code, which in part resulted in Hector Martin from stepping down as a kernel maintainer and eventually Asahi Linux as a whole.
You must log in or register to comment.
I don’t understand enough about the technical aspects of this to have an opinion, but I hope it all gets resolved peaceably.
God damn… In the amount of time that people have talked about all of this drama all of these guys could have learned how to write Rust.
But seriously, Linus has been right at every turn here. He was right for telling Marcan that he handled it poorly by taking it to social media, and he’s right here too about opting out of Rust.
I wish this was given a less provocative title. People who read the whole post will find that it’s not all shouting, and Linus’ stance seems pretty even-keeled.
This excerpt gives context and tone:
I respect you technically, and I like working with you.
And no, I am not looking for yes-men, and I like it when you call me out on my bullshit. I say some stupid things at times, there needs to be people who just stand up to me and tell me I’m full of shit.
But now I’m calling you out on YOURS.
I wrote the initial title. I first saw this news on Reddit with a title like “Linus slams Hellwig…” and I really don’t like titles like that.
So I opted for a direct quote that was able to fit in the title bar that gave a decent summary of the situation. I do agree it’s still a bit provocative, but at least it’s not me putting the spin on it.
Come on and slam
Welcome to the jam
“don’t quote the shouty bit; it’s not all shouty”
More like, “don’t pick an inflammatory minor excerpt to represent a lengthy and well-reasoned post.”
Similarly, don’t choose a red fruit to represent a pine forest just because there happens to be an apple tree somewhere within. It’s misleading.
Mmmmmm Pineapple
To be fair, it’s entirely possible someone else made a post about this topic with an non-sensationalized title, but no one engaged with that one. Including us.
But drama!
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.
I hope this won’t turn into a cat and mouse game.
Doubt it. Why would a maintainer intentionally self sabotage their own API stability? Cutting off one’s nose to spite the face.
Some folk are just really really petty, and will self sabotage to “prove themselves right”.
Changing that kernel API wouldn’t just hurt the Rust devs, it would hurt literally anyone who uses that API, which includes other Linux maintainers. Anyone trying to “prove themselves right” by mucking with kernel APIs would swiftly be called out on their bullshit, and probably be removed from the project.
Oh, absolutely, and that’s exactly what should happen.
Man, imagine if he had just come out and said this earlier before burning out a kernel contributor…
You’re implying that Linus is somehow responsible for burning out Marcan? I don’t think that’s a fair assessment.
Linus should have stepped in earlier. The R4L guys have been running against walls over and over (just look at how T’so, the “thin blue line” guy, spewed hate at that one conference), because individual developers think they can use their power to slow down the R4L project. They don’t argue on a technical level. Linus, as the project lead, has to step in when this happens, otherwise the experiment can’t work.
But he did step in, albeit privately. I actually agree an earlier public statement would have helped, but we don’t know the specifics of what went on behind the scenes.
In any case, I don’t think it’s fair to assign blame for Marcan’s burnout to Linus, as the post above did. Marcan himself mentioned personal reasons too when he announced his departure. I think we should show understanding and patience with both sides, and assigning blame isn’t helping with that.
I’m not trying to assign blame for Marcan’s burnout, but it’s important to try and understand what went wrong here, because things did go wrong. Linus’s earlier inaction (I haven’t seen anything about reaching out privately, could you link that?) isn’t the cause of it, but it’s what should have prevented things from going this far.
If we ignore what went wrong, the same thing will happen again.
Thanks!
To add nuance to my comment: I think that Linus mismanaged the conflict, and that this was a significant and avoidable factor in Marcan getting burned out. For an example of how Linus could have approached this instead: he could have publicly criticized both Marcan and Hellwig at the same time, rather than first publicly criticizing Marcan and then only after Marcan left publicly criticizing Hellwig for his own behavior. This probably would have made Marcan feel less picked on and less likely to have been burnt out. (Or maybe not; I do not claim to deal in certainties.)
nonsense.
at what point did Linus frustrate the contributor? it was Hellwig all the way
The contributor’s frustration with Linus started with Linus ignoring multiple explicit requests for his intervention. When the contributor was so frustrated at the lack of response from Linus that he had the audacity to talk about it off list (linking here because the original toot has been deleted), it was at that point that Linus finally chimed in to tell the contributor “Maybe the problem is you,” implying that Hellwig’s obstructionism was not a problem in his eyes and that the only issue was the contributor drawing public attention to it.
you went from “ignored” to “lack of response” in one sentence there. either way you’re implying a malicious ignorance on Linus’ part
the contributor posted 29th and went “public” on the 4th. they lasted a whole 5 days before throwing their toys out of the mailing list pram into social media
Linus deemed this behaviour problematic and started to assess the situation. contributor quit
eventually Linus responds by reminding Hellwig of the situation. nothing has changed. R4L continues with the same rules as before.
do you really think burnout happens because of one incident? it takes time and Hellwig and co have been the problem that entire time, not Linus
Theprimeigen covers the drama very effectively and their are some good technical arguments on both sides.
So far, the only good argument I have really seen from the ones opposing the Rust4Linux effort comes down to: adding Rust to a C codebase introduces a lot of complexity that is hard to deal with.
But the argument offers no solution except to give up and not even attempt to address the real issues the kernel struggles with. It’s effectively a form of defeatism when you want to give up and don’t want to let others attempt to do what you don’t see as feasible.
I don’t know I think the argument about forcing maintainers to learn Rust is probably true - sure the Rust code might not touch the DMA code, but Linux doesn’t have stable APIs so in theory you’re supposed to be able to change an API as long as you fix all the drivers that use it.
That now involves fixing Rust drivers, so you’re going to need to know Rust.
However I don’t think that’s a good reason not to do it. In my opinion Linus should just be honest and say that the Rust experiment has been successful, Rust is going to be part of the kernel moving forwards, and you will probably have to get off your arse and learn it.
All this “you won’t have to learn Rust” talk is thin reassurance to keep people happy. I don’t think anyone really believes it.
Reminds me of when WASM was introduced and everyone was saying “the goal isn’t to replace JavaScript” to keep the JavaScript folk happy, despite everyone knowing that that was exactly the goal.
That now involves fixing Rust drivers, so you’re going to need to know Rust.
The R4L approach is that C maintainers never need to touch any Rust code. They can break it all day long without paying any attention to it. This has been an essential part of the project from the start, I don’t understand how people talking about this topic still don’t understand this.
Last time around Asahi Lina (major contributor to the Apple Silicon GPU driver) made a very nice writeup on mastodon about her attempts to mainline her work.
Part of the problem was that the C interface was straight-up broken; not only were a bunch of lifetimes undocumented, but freeing the kernel objects properly was impossible, but GCC doesn’t care and neither did anyone because GPU drivers are expected to just… never exit (IIRC). So she refactored it to be saner.
Anyway apparently it was rejected for much the same reasons, aka Rust bashing thinly disguised as concerns over maintainability.
Technically the R4L project did have an impact. But what’s the worst case? Spending some time on improving the C interface for an edge case? The ignominy! NAK.
To be clear I fully support Rust in Linux. I just think it’s going to rapidly be impractical to work on Linux without learning Rust.
The solution isn’t to pretend that isn’t the case; it’s to learn Rust!
I do understand that that’s what they claim. I just don’t believe them. Because it requires either
- magical Rust maintainers who are always on call to help, or
- people to be on with the Rust code breaking all the time.
Neither seems likely.
What’s there not to believe? If Rust gets broken, either someone will fix it, or the kernel releases with broken Rust. Where’s the issue?
It’s such a strange position to take.
or the kernel releases with broken Rust
This is what I don’t believe. I think what will actually happen (or could at least), is:
C dev that refuses the learn Rust: “Hi, here’s a change to the DMA API.”
Linus: “Can you fix the Rust code before I merge this?”
C dev: “Ok, Rust devs it’s your job - can you fix it?”
Rust devs: “”
C dev: “Hello? Where are you?”
…
C dev: “Can we just merge it now?”
Linus: “No we need to fix the Rust.”
Again, to be 100% clear, I think that this shouldn’t block Rust. We should just expect the C devs to learn a bit of Rust (seriously if they’re writing Linux DMA systems they are easily bright enough to do it). But pretending that they won’t have to to keep them happy seems disingenuous.
Okay? And why are you imagining things would go down like that, when the policy is specifically not doing it this way? When this issue hasn’t occurred so far?
Rust is disabled by default, so it’s not like it would be harder to build a kernel when it’s broken. Seriously, I just don’t get why you’re imagining these things.
That now involves fixing Rust drivers, so you’re going to need to know Rust.
I also don’t think the latter follows from the former. You can continue to not know Rust as long as you’re willing to work with those that can. Problems only start if you’re unwilling to collaborate.
