In December 2025, the kernel project announced that Rust in the Linux kernel is no longer experimental and that Rust development is now an official part of kernel development. For engineers who write and maintain drivers, this is a real change in direction, not a side project. This post sets out what actually changed, where Rust stands in the kernel today, and what an embedded or kernel engineer should reasonably do about it. The aim is an evidence-based view, not advocacy for or against the language.
What changed: Rust in the Linux kernel is no longer experimental
Rust support was first merged into the kernel in version 6.0, released in October 2022. At that point the kernel could build Rust code, but there were no useful drivers in the tree and the feature was clearly marked as experimental. The December 2025 announcement removed that label. In practical terms it means the maintainers have committed to keeping the Rust support working, reviewing Rust patches as part of normal development, and accepting new drivers written in Rust rather than treating them as a trial.
This does not mean the kernel is being rewritten in Rust. The kernel remains overwhelmingly C, and there is no plan to change existing C code. Rust is allowed for new code, mostly drivers, that sits on top of abstractions over the existing C subsystems.
Where Rust actually is in the kernel today
It helps to look at concrete merged code rather than announcements. The first useful driver written in Rust was the ASIX AX88772A network PHY driver, merged in Linux 6.8 in early 2024, along with a PHY abstraction layer. Since then the set of Rust code in or near the tree has grown:
- The Android Binder inter-process communication driver has been rewritten in Rust by Google.
- Network PHY drivers for ASIX and Realtek parts.
- An NVMe driver effort and a null block driver used for storage experiments.
- The Nova project, a Rust successor to the Nouveau driver for Nvidia GPUs, led by Red Hat.
- Asahi Linux’s AGX GPU DRM driver for Apple silicon, which is a large real-world Rust driver developed alongside the in-kernel DRM abstractions.
- Smaller pieces such as the DRM Panic QR code generator.
The pattern is clear. Most Rust work is in drivers and in the abstraction layers that let a Rust driver talk to a C subsystem safely. This is exactly the part of the kernel that embedded engineers work in.
Why this matters for embedded engineers specifically
Embedded and BSP work is driver work: character devices, platform drivers, I2C and SPI clients, network PHYs, and DRM and media drivers. That is the area where Rust is being introduced first, because a driver is a contained unit with a defined interface to the rest of the kernel. The argument made for Rust here is memory safety. A large share of kernel security bugs come from memory errors such as use-after-free and buffer overruns, and Rust’s ownership and borrow rules are designed to catch many of these at compile time rather than at runtime on a shipped device.
There is also a tooling reason that affects embedded teams. Rust drivers still bind to C through generated bindings, so an engineer who understands both the C subsystem and the Rust abstraction over it is the person who can actually get a Rust driver working on real hardware. That combined knowledge is becoming a distinct skill.
The honest counterpoint
The difficulties are equally real and should be stated plainly. Maintaining a kernel in two languages has a real cost. Every change to a C interface that a Rust abstraction depends on can require matching work on the Rust side, and some longtime maintainers have said publicly that this dual-language burden is a serious concern. Vendor board support packages are still written in C, hardware vendors are cautious about committing to Rust drivers they must maintain for years, and the Rust abstractions for many subsystems are still incomplete. None of this is hidden; it is an active discussion in the community. The reasonable reading is that Rust in the kernel is now permanent and growing, but C remains the language of the vast majority of the kernel and of almost all production embedded systems today.
What to learn now
The evidence points to a clear and unglamorous answer. Strong C and a solid understanding of kernel internals remain the foundation, because the abstractions Rust drivers sit on are written in C, and almost all existing code and vendor BSPs are C. On top of that, it is worth learning enough Rust to read kernel Rust code: the ownership and borrowing model, the kernel’s own kernel crate and its abstractions, and how the binding boundary between Rust and C is generated.
If you maintain a kernel tree, you can check whether your toolchain can build Rust code using the kernel’s own target:
raghu@techveda.org:~$ make LLVM=1 rustavailable
Rust is available!
And you can confirm whether a given build has Rust support enabled:
raghu@techveda.org:~$ grep CONFIG_RUST= .config
CONFIG_RUST=y
Trying to build and read one of the existing in-tree Rust drivers, alongside a C driver for similar hardware, is a practical way to understand the difference without committing a production driver to Rust. The deeper your grounding in C kernel driver development, the easier the Rust abstractions are to follow, which is one reason our Linux device drivers training stays focused on the underlying kernel mechanisms first.
Key takeaways
- As of December 2025, Rust in the Linux kernel is officially supported, not experimental; Rust support itself was first merged in Linux 6.0.
- Most Rust code so far is drivers and the abstraction layers over C subsystems, starting with the ASIX PHY driver in Linux 6.8 and now including Binder, GPU, and storage work.
- This is directly relevant to embedded engineers, because driver and BSP work is exactly where Rust is being introduced first.
- C and kernel internals remain the primary skills; learning to read the kernel’s Rust abstractions and the Rust-to-C binding boundary is a sensible addition, not a replacement.
