Linux 6.14 and Rust in the kernel, one driver at a time

Linux 6.14 is out. The release is modest by kernel standards — improved AMD and Intel graphics support, ntsync for better Wine and Proton performance, more filesystem work — but the ongoing story underneath is Rust, and this cycle had one of its sharper moments.

where Rust for Linux actually is#

The infrastructure has been merged for several cycles. What has been slower is the bindings: the safe Rust abstractions over kernel C APIs that a driver author would actually use. You cannot write a Rust network driver until somebody writes a sound Rust abstraction over the network device API, and doing that correctly requires deep agreement between the Rust folks and the maintainer of the subsystem in question.

That is where the friction is, and it is not primarily technical.

The concern from some longtime maintainers is legitimate and worth stating plainly: if a Rust abstraction wraps a C API, then a change to the C API can break the Rust side, and now the C maintainer is on the hook for a language they did not sign up to learn. Multiply across dozens of subsystems and you have a real maintenance burden distributed to people who did not choose it.

The counter-position, also legitimate: memory safety bugs in drivers are a substantial and ongoing fraction of kernel CVEs, drivers are where most kernel code lives, and drivers are exactly the place where a language with compile-time memory safety pays off most.

Linus's stated position has been consistent — Rust is welcome, the experiment continues, and maintainers are not required to accept Rust in their subsystems but also are not permitted to block it purely on preference. That is a politically difficult line to hold and he has mostly held it.

the technical state#

What exists and works today:

• Kernel allocation, error handling, and the Result-based error propagation.
• Enough abstraction for real drivers — the Android Binder rewrite and the Asahi Linux GPU driver are both substantial Rust codebases running in production on real hardware.
• pin-init, which solves the self-referential-struct problem that makes kernel data structures awkward in safe Rust.

What is still hard:

• The compiler version floor keeps moving, which distributions dislike.
• Rust's story for no_std allocation failure handling required work that only exists because the kernel needed it.
• Architecture coverage. Rust needs an LLVM backend for the target, which rules out several architectures the kernel still supports.

the honest assessment#

This will take longer than advocates hope and will succeed more than skeptics expect. The pattern is already visible: new drivers in Rust where a maintainer is willing, C everywhere else, indefinitely. Nobody is rewriting the VFS.

That is a fine outcome. The goal was never a Rust kernel. It was to stop shipping new memory-safety bugs in the parts of the kernel that get the most new code, and on that specific goal the trajectory is good.