this post was submitted on 08 Feb 2025
376 points (98.2% liked)

Open Source

32731 readers
153 users here now

All about open source! Feel free to ask questions, and share news, and interesting stuff!

Useful Links

Rules

Related Communities

Community icon from opensource.org, but we are not affiliated with them.

founded 5 years ago
MODERATORS
top 50 comments
sorted by: hot top controversial new old
[–] [email protected] 85 points 3 days ago (11 children)

https://lore.kernel.org/lkml/[email protected]/

Here’s the source thread.

Tldr: someone wants to put rust in the dma part of the kernel (the part that accesses memory directly)(it’s a memory allocator abstraction layer written in rust which rust code can use directly instead of dealing with the c allocator abstraction layer), is told that rust should use the extant methods to talk to the c dma interface, replies that doing so would make rust programs that talk to dma require some more code, gets told “that’s fine. We can’t do a split codebase”. The two parties work towards some resolution, then hector martin comes in and acts like jerk and gets told to fuck off by Linus.

Martin is no lennart poettering but I don’t try to see things from his perspective anymore.

It’s worth noting that Linus’ “approval” of rust in the kernel isn’t generally seen as a blanket endorsement, but a willingness to see how it might go and rust people have been generally trying to jam their code everywhere using methods that rival the cia simple field sabotage manual.

I don’t think it’s on purpose (except for maybe Martin) but a byproduct of the kernel maintainers moving slowly but surely and the rust developers moving much faster and some seeing the solution to that slow movement as jamming their foot in the door and wedging it open.

[–] [email protected] 12 points 2 days ago* (last edited 2 days ago) (1 children)

Except you're wrong about them wanting to put Rust code in the DMA subtree. As per the article linked below by M1ch431:

In a message to the Linux kernel mailing list, Hellwig wrote: "No Rust code in kernel/dma, please." For what it's worth, the patch added code to the rust/kernel portion of the Linux source tree, not kernel/dma, as far as we can tell.

All they were doing is adding an abstraction layer, within the already existing Rust code, so that rust drivers could communicate with the C DMA code in a uniform and predictable manner. It would have put far more work on maintainers, both C and Rust alike, to have each and every driver implement its own abstraction to the DMA API. Issues would have been/will be filed against the kernel/dma subtree in error due to issues with these myriad abstraction layers.

[–] [email protected] 5 points 2 days ago

It’s a duplication of functionality in kernel/dma.

That’s why the submitter didn’t say “I didn’t submit to kernel/dma, checkmate libs!”.

The intent is to duplicate functionality in kernel/dma then get it included directly or linked to.

That’s what the r4l project is trying to do explicitly!

Before you say that kernel/dma didn’t have functional easy to use rust bindings, so the commit couldn’t have duplicated functionality: someone on kernel/dma said they didn’t want that and suggested using the c bindings instead which is what every other language has to do. Which means there was already a solution that was functional.

It’s like if there’s a community bicycle and you bring your drill and tap set so you can mount your bottle caddy and the community says “please don’t make a hole we have to tig in. Just use a pipe strap.” The right answer isn’t to start building a whole new down tube you can tap for an m5 for your bottle caddy, it’s to just use a pipe strap for your bottle caddy.

I didn’t read the linked article (or any linked article about this) because I’ve been reading the mailing list. Reporting on the kernel and people’s behavior on the list is tiring and often includes a bunch of baseless speculation.

[–] [email protected] 35 points 3 days ago (6 children)

To be fair, I'm not sure how "I will do everything in my power to oppose this" is the anti-Rust side "work[ing] towards some resolution"...

[–] [email protected] 28 points 3 days ago (3 children)

That’s tame for the kernel mailing list lol.

The context is that hellwig doesn’t want another maintainer or deal with a split codebase in the dma subsystem which I honestly agree with.

If I were a maintainer in that position I’d be barring the doors too. It’s not a driver for some esoteric realtek wireless card or something.

Even if I didn’t agree with that position it’s normal to only post on the kernel mailing list about shit you actually care deeply about because it’s public and aside from all your fellow devs taking the time to read what you wrote, psychotic nerds like myself watch it and will try to read the tea leaves too!

[–] [email protected] 10 points 2 days ago* (last edited 2 days ago)

If I were a maintainer in that position I’d be barring the doors too. It’s not a driver for some esoteric realtek wireless card or something.

This effectively kills R4L. If they can't include Rust Interfaces for important subsystems, each driver written in Rust that uses these subsystems has to separately track all the Subsystem Interfaces, leading to lots of extra work for no benefit.

If this is the approach Linux takes, they should just cancel R4L completely.

load more comments (2 replies)
[–] [email protected] 12 points 2 days ago (4 children)

https://lore.kernel.org/lkml/[email protected]/

General idea seems to be "keep your glue outside of core subsystems", not "do not create cross-language glue, I will do everything in my power to oppose this".

load more comments (4 replies)
load more comments (4 replies)
load more comments (9 replies)
[–] [email protected] 61 points 3 days ago (2 children)

Shit they triggered the raid boss early

[–] [email protected] 3 points 1 day ago

OK, who pulled?

Why am I even asking, it was the hunter of course.

[–] [email protected] 27 points 3 days ago* (last edited 3 days ago)

LEEEEROOOOOY JENKINS!

[–] [email protected] 54 points 3 days ago (1 children)

FTA: "However, I will say that the social media brigading just makes me not want to have anything at all to do with your approach.

"Because if we have issues in the kernel development model, then social media sure as hell isn't the solution. The same way it sure as hell wasn't the solution to politics.

"Technical patches and discussions matter. Social media brigading - no thank you." -Linus

Yeah, I have to issue an unqualified agreement here. Linus isn't saying no to Rust, he's smackin' that ass for bringing drama out into social media instead of working through it in normal technical discussion channels.

[–] [email protected] 20 points 3 days ago (15 children)

It sounds like he tried that, and nobody with authority responded until he went outside the list. Even now, Linus hasn't actually answered the question of whether more rust code should be allowed.

load more comments (15 replies)
[–] [email protected] 19 points 2 days ago

This whole thing reads not like a codebase versus, but a traditional engineering approach (don't act like you can patch this once you release it - get it done so it's stable the first time) versus the more modern "move fast and break things" approach.

[–] [email protected] 99 points 3 days ago (16 children)

I am so glad Linus just came out and said it. I was pretty upset at Hector too in the other thread the other day, and I especially didn't appreciate a call to remove a major developer from the kernel because Hector wasn't getting his way. Very militant action on Hector's part where it just wasn't necessary.

Hector, if you're reading this, communication skills are just as if not more important than your Rust development skills, and frankly your communication skills lack.

[–] [email protected] 30 points 3 days ago (1 children)

You seem to be in the loops of the linux kernel?
If so, ive known hector from way before when we was part of f0f, or TT as they were known before, doing wii homebrew work.
What you describe is what my experience was with him 14 years ago too. The guy is smart, he has a very good skill set and knowledge, but his communication skills were lacking back then too.
Granted, both he and myself were still teenagers and students and we were wild, but i had always assumed he grew up a bit since then...

What you said is spot on, and i hope he does read both of these. And if he does :
Marcan, you might not know who i am anymore, but ffs man. Dont screw up your love for all of these by keep kicking the hornets nests. You did it with devkitpro, emudevs when the nier news dropped and with rossman too. Stop it, its for your own good.

load more comments (1 replies)
[–] [email protected] 27 points 3 days ago (1 children)

I can understand their frustration, having multiple other rust for Linux project maintainers quit over nontechnical rust aversion.

And Linus continues to (democratically?) avoid the subject with this response.

As a rust for Linux volunteer you have to be incredibly demoralized reading this mess almost every other month.

[–] [email protected] 16 points 3 days ago

Part of why linux has been a successful long term project is by making decisions conservatively. Other projects like cURL do the same. Incremental improvements over time.

It seems like there is a culture clash with the rust devs who are pushing for changes faster than the long term project maintainers are comfortable with.

load more comments (14 replies)
[–] [email protected] 5 points 2 days ago

This is just a dick measuring contest.

load more comments
view more: next ›