The integration of Rust into the Linux kernel continues to evolve, with increasing adoption across various subsystems and growing support from both the Linux community and the industry. However, there are still many questions regarding how Rust is maintained, who is responsible for its code, and how it impacts kernel development.
This article provides an in-depth look at the current policies governing Rust for Linux, based on the latest updates from the development team.
How Is Rust Introduced into a Kernel Subsystem?
The adoption of Rust varies by subsystem, with no single approach mandated. Kernel maintainers have the flexibility to choose the best way to integrate Rust based on their needs and available resources. Generally, three main strategies have emerged:
- Direct Integration by Subsystem Maintainers: Some maintainers choose to manage Rust integration themselves, reviewing patches and fixing issues, which also helps them become familiar with the language.
- Adding a Rust-Specific Co-Maintainer: Others assign a dedicated Rust maintainer or reviewer to handle Rust-related changes, either within their main development tree or through a separate repository.
- Opting Out of Rust for Now: Some maintainers have decided not to adopt Rust yet, often due to bandwidth constraints or other priorities.
At the 2022 Kernel Maintainers Summit, it was requested that flexibility be allowed when major Rust-based kernel components require key APIs that existing C maintainers might not be able to maintain in Rust.
Do Kernel Maintainers Support Rust?
Yes, several key kernel maintainers have expressed support for Rust in the Linux kernel. This has been highlighted in events like FOSDEM 2025, where the Rust for Linux keynote included statements from maintainers backing Rust adoption.
However, support does not mean that all maintainers must accept Rust into their subsystems immediately. Each has the freedom to decide if and when to integrate Rust within their domain.
Who Maintains Rust Code in the Kernel?
Kernel maintenance policies apply to Rust code just as they do to C. This means that each subsystem maintains its own Rust code where applicable.
The “RUST” subsystem is responsible for maintaining certain core facilities and shared APIs, but it does not manage all Rust code in the kernel. However, the Rust team is available to assist other maintainers in the adoption process.
In the future, the “RUST” subsystem could also serve as a fallback maintainer for Rust code, similar to how akpm (Andrew Morton) serves as a fallback for C code maintenance.
What Happens If a C Change Breaks Rust Compatibility?
As a general rule, no changes should break the kernel build, including Rust.
However, in some exceptional cases, a subsystem may temporarily allow Rust breakage if C maintainers need to prioritize urgent fixes and cannot immediately address Rust compatibility.
For example, the block layer (storage subsystem) implemented this strategy in its “Stage 1” Rust integration plan, allowing temporary breakage to facilitate Rust adoption.
This approach is considered reasonable as long as too many subsystems do not adopt it simultaneously, as that could make maintaining linux-next builds difficult.
Should Rust Code Be Held to the Same Standards as C Code?
Ideally, yes. However, in practice, Rust adoption is an evolving process, so some subsystems may initially have more flexibility when maintaining Rust code.
The goal is to avoid discouraging maintainers from trying Rust simply because they feel unable to immediately support it at the same level as C. Over time, as Rust matures in the kernel, its maintenance will align with standard quality expectations.
Does Rust Increase the Workload for Maintainers?
From the outset, the Rust for Linux team acknowledged the costs and risks of introducing a second language into the kernel. However, the benefits of Rust—especially in memory safety—outweigh these costs.
Over time, the advantages of Rust have become more evident, while many of the initial costs have already been addressed:
- Successful complex Rust drivers have been developed and merged.
- Rust has driven improvements in C code, showing positive cross-language collaboration.
- Industry demand for memory-safe languages has increased, reinforcing Rust’s relevance.
Additionally, much of the foundational work required to support Rust in Linux is now in place, including stabilized Rust features, improved tooling, and broader industry adoption.
Are Duplicate C/Rust Drivers Allowed?
By default, duplicating a C driver in Rust is not allowed under standard kernel policy.
However, some subsystems may temporarily permit duplication to help bootstrap Rust integration while ensuring system stability. This is evaluated on a case-by-case basis.
Is Rust for Linux Led by the Rust Community?
No. Rust for Linux is not managed by the Rust Project or the Rust Foundation.
The initiative is driven by a diverse group of developers, including kernel maintainers, Rust experts, hobbyists, and employees from major tech companies.
In fact, Rust for Linux was originally started as a personal project by a Linux kernel maintainer and has grown through community collaboration.
Are Companies Supporting Rust in the Kernel?
Yes. At least six major companies have publicly assigned full-time engineers (FTEs) to work on Rust for Linux and its integration.
Additionally, there is growing academic and industry interest in supporting Rust within the kernel. More details can be found on the Industry and Academia Support page.
Conclusion: The Future of Rust in the Linux Kernel
Rust is steadily gaining traction in the Linux kernel, with growing support from maintainers, industry leaders, and the development community. While adoption is still in progress and presents challenges, the successes so far demonstrate Rust’s viability.
The coming years will be crucial in defining Rust’s role in Linux kernel development. As the community continues evaluating its impact, one thing is clear: Rust is here to stay.
