The decision to accept Rust in the Linux kernel was made in 2022 and landed in Linux 6.1[1] in mid-December that year. Back then infrastructure was minimal, bindings covered little surface, and most debate revolved around whether inclusion was desirable at all. Today, in 2026, with real drivers in production, a growing kernel subset exposed to Rust, and the public friction episodes between Rust developers and traditional maintainers, it’s time for a technical balance. Not about hype or revolution: about what works, what still hurts, and where this is reasonably heading.

Key takeaways

  • Rust-written drivers in production (Apple GPU in Asahi Linux, experimental NVMe modules) prove viability for real-complexity components.

  • Memory-bug reduction is the most tangible benefit: use-after-free, concurrency races on badly reasoned locks, don’t happen at the same rate.

  • The cultural cost is real: friction between Rust philosophy (rich types, abstractions) and kernel philosophy (stability, avoiding layers). A Rust maintainer’s August 2024 resignation was symptomatic.

  • Incomplete bindings remain the practical limiter: whole kernel zones without adequate Rust interface.

  • Kernel Rust is the best available entry point for new contributors from the Rust ecosystem.

Starting point and real progress

What was decided in 2022 was that Rust would enter as a second-class citizen at first: no rewriting existing code in Rust, only new subsystems. In 2024, the Apple GPU driver from the Asahi project proved a real-complexity component was doable without rewriting the whole DRM subsystem. It has been written in Rust since its lead developer started the port, in August 2022.

By the project’s own account[2], a cube was rendering on screen within weeks of the port starting. A full GNOME session followed soon after, without the memory races typical of a freshly written kernel driver: only a handful of logic bugs and one memory-management issue showed up. From then on, contribution pace picked up.

In 2026, relevant Rust-written drivers include:

  • The Apple GPU driver, in daily use by tens of thousands of developers on Asahi Linux Macs.

  • An experimental NVMe driver[3], maintained by Andreas Hindborg at Samsung, showing viability in a hot kernel zone. Benchmarks against 6.8-6.15 put it on par with the C driver for most workloads, though C still wins by up to 6% on 512-byte blocks due to extra compute overhead.

  • Plus virtualization drivers and small utilities.

Total volume remains small next to millions of kernel C lines, but trajectory is clear and produced code is robust.

What has worked well

Effective bug reduction. Memory errors plaguing kernel C (dangling pointers, use-after-free, concurrency races on badly reasoned locks) don’t happen in Rust at the same rate because the compiler catches them. The upfront cost of more verbose code with explicit types amortizes in driver stability.

Rust’s unsafe model has worked better than some feared. C-interface zones are marked explicitly, unsafe surface is bounded, and the rest of the code leverages language memory guarantees. Reviewing a kernel Rust patch looks pretty similar to reviewing a C patch, but confidence that safe parts are effectively safe reduces cognitive load.

Lower entry barrier for new contributors. The Linux kernel always had a reputation as a hostile community. Rust doesn’t fully solve that but does lower the first technical barrier. People who never touched kernel C give it a try because the language is familiar, and compiler-checked guarantees give safety against introducing catastrophic bugs in a first patch.

What still costs

Inter-process cultural friction. Linux kernel philosophy privileges backward compatibility, stability, and avoiding unneeded layers. Rust culture tends to prefer rich types, abstractions over low-level APIs, and refactors to clean up old code. The clash between them has a famous case.

The most cited case is Wedson Almeida Filho’s public resignation[4] on August 28, 2024, after nearly four years as a Rust for Linux maintainer. He pointed to a clash with Ted Ts’o over how to type a filesystem’s semantics in Rust. Ts’o’s reply on the kernel mailing list stuck: "here’s the thing, you’re not going to force all of us to learn Rust." Not purely technical but cultural: different expectations on how to review code, negotiate changes, and handle friction points. The episode has repeated at lower intensity in other threads since.

Incomplete bindings. There are whole kernel zones with no adequate Rust interface, as already visible in the first stable drivers, and adding one requires significant work from someone who knows kernel C and ecosystem Rust well. This work isn’t glamorous and tends to fall on a small number of people.

Where it’s heading

The next phase, already visible in 2026, is accepting Rust for large subsystems in areas where memory safety offsets cultural cost: new filesystems, high-concurrency network drivers, experimental memory-management subsystems.

There is also recent news that reframes this whole section: Linux 7.0, released in April 2026[5], formally closes Rust’s experimental period in the kernel. The language stops being a tolerated add-on and gets first-tier support alongside C, something that had been under negotiation since the 2025 kernel maintainers summit. In practice this doesn’t change the code overnight, but it changes the conversation: the question is no longer why Rust exists in the kernel, but how far it extends.

The other vector is ecosystem-tooling maturation: adequate documentation, clearer review processes, more professionalized coexistence with maintainers. New contributions arrive better prepared, more willing to adapt style to kernel community norms.

For developers wanting to enter now, kernel Rust is probably the best available door. It has a mature ecosystem, reasonable docs, active mentors, and a production backend track record that gives newcomers confidence the language holds up outside the kernel too.

Conclusion

After four and a half years of Rust in the Linux kernel, the technical balance is clearly positive, the cultural balance is uncomfortable but improving, and the path forward is reasonably marked. The bet has worked enough to justify keeping it and little enough to avoid triumphalism.

The general lesson for those following from outside: integrating a new technical paradigm into a large community with its own tradition is far harder than writing the code. Code is the easy part. The hard part is negotiating culture, convincing people with founded reasons who prefer something else, and enduring the first conflict rounds until stable norms establish.

Rust in Linux has gone through those rounds and survived, which is itself a strong indicator it will stay. The question is no longer whether Rust is viable in the kernel, but how far it will go in the next years.

This article is also available in Spanish.

Last reviewed: 2026-04-22.

Sources:

  1. InfoQ — Linux 6.1 adds official Rust support for kernel development[1]
  2. Asahi Linux — Tales of the M1 GPU[2]
  3. Rust for Linux — NVMe driver project page[3]
  4. The Register — Rust for Linux maintainer steps down in frustration[4]
  5. The Register — Linux 7.0 debuts, closing the experimental Rust period[5]

Frequently asked questions

Does a Rust driver perform as well as a C driver inside the kernel?

For most workloads, yes. The experimental Rust NVMe driver maintained by Andreas Hindborg at Samsung, benchmarked against kernels 6.8-6.15, is on par with the C driver in nearly every scenario. The exception is 512-byte blocks, where C still wins by up to 6% because of extra compute overhead. The Apple GPU driver in Asahi Linux, used daily by tens of thousands of developers, confirms viability for real-complexity components.

Is the Linux kernel going to be rewritten in Rust?

No. The 2022 decision was that Rust would only enter through new subsystems, with no rewriting of existing C code. The next phase, already visible in 2026, is accepting Rust for large subsystems where memory safety offsets the cultural cost: new filesystems, high-concurrency network drivers and experimental memory-management subsystems. Linux 7.0, released in April 2026, formally closes the experimental period and gives Rust first-tier support alongside C.

Why did a Rust for Linux maintainer resign in August 2024?

Wedson Almeida Filho resigned publicly on August 28, 2024, after nearly four years as a Rust for Linux maintainer. The trigger was a clash with Ted Ts'o over how to type a filesystem's semantics in Rust. It was not a purely technical dispute but a cultural one. Different expectations collided about how to review code and negotiate changes: Rust's preference for rich types and abstractions against the kernel's emphasis on stability and avoiding layers.

Sources

  1. landed in Linux 6.1
  2. the project’s own account
  3. experimental NVMe driver
  4. Wedson Almeida Filho’s public resignation
  5. Linux 7.0, released in April 2026