Rust in the Linux Kernel: The Religious War Gets GPU Drivers

I’ve been watching the Rust-in-Linux saga unfold for years now, and let me tell you: I’ve seen some heated technical debates in my more than two decades of experience in software engineering, but this one takes the cake. It’s not just about choosing a programming language anymore. It’s become what Linus Torvalds himself called “almost religious war undertones.” And you know what? He’s absolutely right. Here’s the thing: I’ve written C code very heavily in my early career. I’ve debugged kernel panics at 2 AM. I’ve hunted down memory corruption bugs that made me question my career choices. So when I see the Rust-in-Linux debate, I can’t help but think: this was inevitable. However, let me be perfectly honest with you: the technical arguments are sound, the implementation is progressing, and the cultural war is escalating by the day. Linux 6.13, released in January 2025, brought what Greg Kroah-Hartman called “the tipping point” for Rust driver development. We’re no longer talking about toy projects. We’re discussing the development of real GPU drivers in Rust, with the expectation that one will merge into the mainline kernel within 12–18 months. And yet, maintainers are quitting. Projects are fracturing. The question isn’t whether Rust belongs in the kernel. The question is whether the community can survive the transition.

The Technical Case Is Actually Pretty Damn Strong Let me start with what nobody wants to admit in public but everyone knows in private: C is a beautiful, powerful language that will absolutely let you shoot yourself in the foot, reload, and shoot yourself in the other foot. I’ve been writing C since I was a kid (I sold my first software when I was 12–13, and yes, some of it was written in C). I love C. But here’s what I love more: not having to deal with memory safety bugs in production systems that affect millions of users. The statistics are brutal:

A massive portion of kernel vulnerabilities are memory safety issues
Use-after-free, buffer overflows, null pointer dereferences; the greatest hits of C development
These aren’t theoretical problems. These are CVEs (Common Vulnerabilities and Exposures). These are security patches. These are late-night emergency deployments.

Rust promises to eliminate an entire class of these bugs at compile time. Not at runtime. Not through careful code review. At compile time. The borrow checker is annoying as hell when you’re learning Rust (trust me, I’ve been there), but it catches bugs before they become vulnerabilities. Now, here’s where it gets interesting: Linux 6.13 didn’t just add some experimental Rust code. Greg Kroah-Hartman, one of the most senior kernel maintainers, explicitly said this is “the tipping point” and predicted “way more Rust drivers going forward.” This isn’t hype. This is a Linux kernel maintainer who’s been around for decades, telling you that the landscape is changing.

The GPU Driver Gold Rush Here’s something that surprised me: GPU drivers are becoming the battleground for Rust in the kernel. Multiple GPU drivers are currently being developed in Rust. The Tyr driver for Arm Mali GPUs is already in Linux 6.18. We’re talking about real hardware support, not proof-of-concept code. Why GPU drivers? Because they’re complex, they’re modern, and frankly, they’re the perfect place to prove that Rust can handle the demands of kernel development. GPU drivers deal with:

Complex memory management
Hardware interactions
Performance-critical code paths
All the things that make C dangerous and make Rust’s safety guarantees valuable

The timeline is aggressive: one of these Rust GPU drivers is expected to merge into the mainline kernel within 12 to 18 months. That’s not “someday in the future.” That’s next year. Maybe the year after. And here’s the kicker: once one major driver is in, the floodgates open. Other hardware vendors will look at it and think, “If they can do it, why can’t we?” The network effects are powerful.

The Religious War Isn’t a Metaphor Now let me tell you about the part that makes me shake my head: the cultural conflict. In early 2025, Hector Martin, who was the project lead of Asahi Linux (the project bringing Linux to Apple Silicon Macs), demanded that Linus Torvalds make a decision on a Rust patch. Things escalated. Martin quit as a Linux maintainer and resigned from the Asahi Linux project entirely. Let that sink in for a moment. A talented maintainer working on one of the most impressive Linux porting projects in recent years quit because of Rust-related conflicts. This is what Linus meant by “religious war undertones.” People aren’t just disagreeing on technical merits. They’re entrenched. They’re defensive. They’re treating this like a zero-sum game where one side must lose for the other to win. I’ve seen this pattern before in my career:

The Vim vs. Emacs wars (mostly harmless)
The systemd debates (less harmless)
The programming language holy wars (mostly pointless)

But this one is different because it’s happening inside the Linux kernel development community, and that community has always prided itself on pragmatism over ideology.

What The C Developers Are Actually Afraid Of Let me be blunt: I understand why C kernel developers are resistant, and it’s not because they’re stupid or stubborn. It’s because they’re being asked to fundamentally change how they work. When you’ve spent 20, 25, 30 years mastering C kernel development, when you can read assembly in your sleep, when you know the subtle edge cases of memory ordering on different architectures, being told “learn Rust or become irrelevant” feels like a punch in the gut. And it’s not just about learning a new language. It’s about:

Different idioms and patterns
Different tooling and build systems
Different debugging approaches
Having to interface between Rust and C code
Maintaining code you can’t read or modify yourself

But here’s what I learned from that experience: resistance doesn’t stop progress. It just determines whether you’re part of the progress or left behind by it. The Timeline That Actually Matters Let me break down where we actually are in this transition: Linux 6.1 (December 2022): Laid the groundwork for Rust support. Experimental, not production-ready. Linux 6.8 (March 2024): Added first experimental Rust drivers. Still not mainstream. Linux 6.13 (January 2025): The tipping point, according to Greg Kroah-Hartman. Rust driver development becomes serious. Linux 6.18 (projected): Tyr driver for Arm Mali GPUs included. 12–18 months from now (late 2025/early 2026): First major Rust GPU driver in mainline expected. Notice the acceleration? From experimental support to production drivers in about three years. That’s lightning fast for the Linux kernel, which typically moves at the speed of extreme caution. What This Actually Means For You If you’re a kernel developer: The writing is on the wall. You don’t have to become a Rust expert tomorrow, but pretending this isn’t happening is career suicide. Start learning. Start experimenting. Start accepting that the kernel of 2030 will look different from the kernel of 2020. If you’re a systems programmer not working on the kernel: Watch this space closely. The patterns and lessons from Rust in Linux will influence how Rust is adopted in other system projects. This is the bellwether. If you’re a security professional: This is good news. Genuinely good news. Reducing the memory safety vulnerability surface area in the world’s most widely deployed kernel? That’s a win. If you’re just someone who uses Linux: Honestly? You probably won’t notice the difference. Your system will be more secure over time. Some drivers will be more stable. But the change will be gradual and mostly invisible.

My Prediction (For What It’s Worth) Here’s what I think happens over the next 3–5 years:

The first major Rust GPU driver merges, probably in 2026
Other hardware vendors start Rust driver development
New subsystems begin with Rust-first approaches
The C codebase continues to be maintained, but stops growing as fast
By 2028–2030, Rust is unremarkable in the kernel; just another tool

The religious war will simmer down not because anyone wins the argument, but because the pragmatists will look at working Rust drivers and say, “This is fine, actually.” Some C developers will never accept it. Some will quit, like Hector Martin did. That’s their choice, and I respect it. But the kernel will continue, because the kernel always continues. The Bottom Line The technical case for Rust in the Linux kernel is strong. The timeline is aggressive but achievable. The cultural resistance is real and understandable. What frustrates me is that this debate often loses sight of what actually matters: building a more secure, more maintainable kernel that serves users better. That’s it. That’s the goal. Whether we get there with C, Rust, or a combination of both should be a pragmatic decision based on evidence, not a religious war based on identity. Linux 6.13 marked the tipping point. Multiple GPU drivers are coming. The question now isn’t whether Rust has a place in the kernel; it’s how quickly the community can move past the religious war and get back to building great software. I know this is not easy. Change never is. However, I’ve been around long enough to know that the technologies that survive are the ones that solve real problems, not those that merely feel comfortable. Rust solves real problems. The rest is just an adjustment.