Rust Officially Mainstream in Linux Kernel: Tokyo Summit Ends Years of Controversy
Rust in Linux kernel officially mainstream after Tokyo Summit decision. Experimental tag removed with zero pushback, but the cost of…
Rust in Linux kernel officially mainstream after Tokyo Summit decision. Experimental tag removed with zero pushback, but the cost of maintainer burnout remains high.
December 10, 2025. Tokyo. Zero pushback. The “experimental” label on Rust in the Linux kernel dies today. After years of heated mailing list debates, resignations, and maintainer conflicts, Rust just won its place at the heart of Linux development. The victory, however, came at a cost nobody predicted.
The Tokyo Consensus
At the Linux Kernel Maintainers Summit, top Linux maintainers reached a formal consensus on something that seemed impossible just two years ago: Rust is no longer experimental.
It’s officially a core part of the kernel.
No heated debates. No walkouts. No veto threats. The room agreed, and the “experimental” tag will be stripped from Rust kernel code.
I’ve seen how hard consensus is to achieve at any scale. The fact that the kernel community reached this point tells you something about how far the Rust integration has come.
Production drivers are shipping. Android Binder IPC. Network PHYs. Block devices. Linux 6.14 is approaching what maintainers call the “write a real driver in Rust” stage. This isn’t theoretical anymore.
If this resonates with your experience watching the Rust debates unfold, clap so other engineers can find it.
The Memory Safety Reality
Let me be direct about why this matters.
70% of kernel vulnerabilities are memory safety issues. Buffer overflows. Use-after-free bugs. Null pointer dereferences. The kinds of bugs that C makes easy and Rust makes structurally impossible.
The U.S. government has been pushing for memory-safe languages. CISA published guidance. The White House Office of the National Cyber Director issued recommendations. This isn’t just kernel politics; it’s national security policy now.
After 20+ years building systems across telecommunications, digital health, and conversational AI, I’ve seen what memory safety issues look like in production. They’re not abstract compiler warnings. They’re 2 AM pages, customer data exposure, and expensive incident retrospectives.
Rust doesn’t eliminate all bugs. But it eliminates entire categories of them. The kernel maintainers finally acknowledged that trade-off is worth making.
I am a human writer who gets motivated to write more with your support! You don’t need to pay. I just need your clap 👏 if you like my story and comment ✍️ if you want to say something. You can follow me on Medium, LinkedIn, Instagram, and X.
The Human Cost
Here’s where the victory turns bittersweet.
Alex Gaynor just announced he’s formally stepping down as one of the Rust for Linux maintainers. His removal patch is queued for Linux 6.19.
He’s not the first. Wedson Almeida Filho resigned earlier this year. The Rust for Linux project has been bleeding maintainers faster than it can grow them.
Why?
Burnout. Sustained resistance from parts of the C kernel community. Technical debates that turned personal. The exhaustion of defending every design decision against skeptics who weren’t always arguing in good faith.
I’ve seen this pattern before. When I co-founded a technology company, I learned that winning the technical argument doesn’t mean you’ve won. You need people who can sustain the effort long enough to see it through. Rust just lost some of its most committed advocates at the moment of its greatest triumph.
Have you experienced maintainer burnout in open source? The emotional weight of defending technical decisions year after year?
What This Unlocks
The “experimental” removal isn’t symbolic. It changes what’s possible.
Driver development opens up. With official blessing, teams can invest in Rust drivers without political risk. GPU drivers. Storage drivers. Network drivers. The floodgates just opened.
Subsystem adoption accelerates. Maintainers who were waiting to see if Rust would survive can now plan integrations. The “wait and see” period is over.
Recruitment changes. Kernel contributors who want to write Rust don’t have to justify their language choice anymore. The language is legitimate. Full stop.
What’s actually production ready:
Linux 6.13 brought major expansions: in-place modules, trace events, and driver bindings for PCI, platform devices, and I/O operations. Linux 6.14 represents the “write a real driver” milestone Greg Kroah-Hartman referenced. Production-ready bindings for real driver development are here.
Real drivers shipping in production: Android’s Binder IPC driver is being ported to Rust. Experimental drivers are live covering network PHYs, block devices, and DRM panic screens.
This is the progression from “interesting experiment” to “use this in your work.” The Tokyo consensus means Linux 7.x could see Rust drivers across multiple subsystems.
The Architecture Challenge
Rust in the kernel faces unique constraints that don’t exist in typical application development:
No standard library. Kernel code can’t use Rust’s std library. Everything happens in no_std mode with custom allocators. Every data structure you take for granted in normal Rust development must be reimplemented or imported from third-party no_std crates.
C interop everywhere. Rust code must seamlessly call C functions and be called by C code. This requires careful binding generation and memory safety guarantees across the FFI boundary. When you’re bridging between Rust’s ownership model and C’s manual memory management, every interface is a potential safety violation waiting to happen.
Build system integration. The kernel’s Kbuild system had to evolve to support Rust compilation alongside C. This wasn’t just adding rustc to the build chain. It meant coordinating two completely different compilation models, linking strategies, and module formats.
Toolchain requirements. You need a specific Rust toolchain version that’s validated against the kernel version. The kernel can’t just use “latest stable Rust.” It needs predictable behavior across years of maintenance.
These aren’t insurmountable problems. They’re engineering challenges that required years of work to solve properly. The Tokyo decision validated that the work paid off.
What This Means For Kernel Development
If you’re a kernel developer, here’s the practical reality:
You don’t need to learn Rust immediately. C isn’t going anywhere. The existing codebase is millions of lines of C, and that won’t change overnight. But ignoring Rust won’t be sustainable forever.
New driver development may shift. For new drivers, especially in areas prone to memory safety issues, Rust will become the preferred choice. Not mandated. But preferred. The path of least resistance will favor Rust for greenfield work.
Subsystem maintainers will need Rust literacy. Even if you’re not writing Rust, you’ll need to review Rust code in your subsystem. You don’t need to be a Rust expert. But you need to understand enough to evaluate patches.
The tooling is maturing. rust-analyzer works with kernel code now. The developer experience has improved significantly from the early experimental days. This isn’t the Wild West anymore.
Have you started experimenting with Rust for kernel development? I’m curious what the on-the-ground experience looks like for those already diving in.
The Political Lesson
The technical arguments rarely determine outcomes.
Rust didn’t win because memory safety is objectively valuable (though it is). Rust won because enough maintainers got tired of fighting, and the production results became undeniable.
The Android Binder IPC driver works. Network PHYs work. Block devices work. When code ships and doesn’t break things, arguments against it lose their power.
This is the pattern I’ve seen across every major technology transition:
Early adopters face intense skepticism
Skeptics demand proof at every step
Production evidence accumulates
Skeptics either leave or convert
The new approach becomes “obvious”
Rust just completed step 5.
What Happens Next
The Tokyo decision opens a new chapter. But open chapters need authors.
The maintainer gap is real. With Gaynor stepping down and Almeida Filho already gone, the Rust for Linux project needs fresh leadership. The technical challenges are manageable. The cultural challenges require people willing to do the work.
Corporate investment matters now. Google, Microsoft, and others backing Rust need to fund not just code, but community. That means paid maintainer time, not just drive-by patches.
C isn’t going anywhere. Millions of lines of C kernel code won’t rewrite themselves. Rust is additive, not replacement. The two languages will coexist for decades.
I expect the next 18 months to determine whether Rust becomes pervasive in the kernel or remains a niche (but officially blessed) alternative. The Tokyo consensus removed the political barrier. The execution barrier remains.
The Real Victory
The real victory isn’t the removal of an “experimental” tag.
It’s the proof that fundamental architectural change is possible in large, established projects. The Linux kernel is one of the oldest, most complex, and most politically contested codebases on Earth. If Rust can win here, it can win anywhere.
I’ve learned that resistance doesn’t stop progress. It just determines whether you’re part of it or left behind.
The C holdouts who spent years fighting Rust integration now face a choice: adapt or become increasingly irrelevant. The Tokyo Summit just made that choice explicit.
Rust is in the kernel. Officially. Permanently. The debate is over.
What remains is the work.
What’s your prediction for Rust adoption in the kernel over the next two years? Are you building (or planning to build) Rust kernel drivers? Please share your perspective in the comments.
I am a human writer who gets motivated to write more with your support! You don’t need to pay. I just need your clap 👏 if you like my story and comment ✍️ if you want to say something. You can follow me on Medium, LinkedIn, Instagram, and X.