Comment by weinzierl
3 months ago
That is so good to hear. I feel Rust support came a long way in the past two years and you can do a functional Rust kernel module now with almost no boilerplate.
Removing the "experimental" tag is certainly a milestone to celebrate.
I'm looking forward to distros shipping a default kernel with Rust support enabled. That, to me, will be the real point of no return, where Rust is so prevalent that there will be no going back to a C only Linux.
A few distros already do that. Of the top of my head, both NixOS and Arch enable the QR code kernel panic screen, which is written in Rust. Granted, those are rather bleeding edge, but I know a few more traditional distros have that enabled (I _think_ fedora has it? But not sure).
> both NixOS and Arch enable the QR code kernel panic screen
Interesting, I use both (NixOS on servers, Arch for desktop) and never seen that. Seems you're referring to this: https://rust-for-linux.com/drm-panic-qr-code-generator (which looks like this: https://github.com/kdj0c/panic_report/issues/1)
Too bad NixOS and Arch is so stable I can't remember the last time any full system straight up panicked.
Yep, that's what I'm referring to.
For now there aren't many popular drivers that use Rust, but there are currently 3 in-development GPU drivers that use it, and I suspect that when those get merged that'll be the real point of no return:
- Asahi Linux's driver for Apple GPUs - https://rust-for-linux.com/apple-agx-gpu-driver
- The Nova GPU driver for NVIDIA GPUs - https://rust-for-linux.com/nova-gpu-driver
- The Tyr GPU driver for Arm Mali GPUs - https://rust-for-linux.com/tyr-gpu-driver
I suspect the first one of those to be actually used in production will be the Tyr driver, especially since Google's part of it and they'll probably want to deploy it on Android, but for the desktop (and server!) Linux use-case, the Nova driver is likely to be the major one.
3 replies →
You can force a panic with echo c | /proc/sysrq-trigger
This is so cool! I love things like that, it feels like fresh air after years and years of anachronistic retro-vibes that seem to be a part of C-programming culture.
Arch never failed me. The only time I remember it panicked was when I naively stopped an upgrade in the middle which failed to generate initramfs but quickly fixed it by chroot'ing and running mkinitcpio. Back up in no time
> I'm looking forward to distros shipping a default kernel with Rust support enabled
What does this mean? The kernel has no specific support for Rust userspace -- the syscall API does not suddenly change because some parts of the kernel are compiled with rustc.
They aren’t talking about userspace.
As I understand it, the kernel has a flag, no by default, to enable building rust code as part of the kernel. They’re saying they’d like to see a distributed choosing to default this flag to yes for the kernels they build.
They.
1 reply →
Will it be possible until Rust gets full GCC support, with all its platforms?
I think Fedora 43 is compiled with CONFIG_RUST=y.
This is genuinely funny. In a dark way but still made me chuckle. Thanks.
[flagged]
Because someday the programming state of the art must advance beyond 1970, and someday we must stop introducing new memory safety bugs that cause horrific vulnerabilities, and for kernel code we don't have the luxury of recompiling everything with garbage collection turned on as a band-aid for C's incurable defects.
The Unix/C people wrote their own kernel in the 1970s instead of invading an existing one.
36 replies →
I believe Linus responded to this very question. I recommend that you read through his email.
Basically, technology evolves, and you or anyone else can't stop that just because you don't like it for whatever nonsense (non technical) reason.
He also said in that same email regarding Rust that:
> nobody is forced to suddenly have to learn a new language, and that people who want to work purely on the C side can very much continue to do so.
So any argument that Rust would ever fully replace C in such a way that C would go away and be banned in the kernel is NOT what Linus said.
https://lkml.org/lkml/2025/2/20/2066
4 replies →
Going off on the name makes your entire question and argument subjective and useless in a constructive discussion.
In-general it seems that Rust proponents want ease and modernity to replace the ability to do the same in C better, with more control and intent, and with better results.
Rust is less tight. That’s fine for an application, but the kernel is used by everyone who uses Linux.
Rustians disparage C because it doesn’t have Rust behavior.
Why must the kernel have Rust behavior?
4 replies →