this post was submitted on 21 Feb 2025
185 points (97.0% liked)
Linux
6101 readers
450 users here now
A community for everything relating to the GNU/Linux operating system
Also check out:
Original icon base courtesy of [email protected] and The GIMP
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
Because I am familiar with human behaviour.
I'm not too familiar with Linux's CI system but I assume they at least test that it compiles, even if it is disabled by default.
Human behavior doesn't dictate that a Linux kernel with failing Rust builds wouldn't get published.
Yes, the systems would notice that something broke. Those systems have no say in whether something gets released.