Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Rust for Linux

Metadata
Short titleRust for Linux
What and whyBuild the Linux kernel with only stable language features.
Point of contactTomas Sedovic
Task ownersBenno Lossin, Boxy, Alice Ryhl, Ding Xiang Fei, Deadbeef, lcnr, Rémy Rakic, Nia, Niko Matsakis, Oliver Scherer, Tyler Mandry, Yoshua Wuyts

Summary

Rust is now an integral part of the Linux kernel. There are mainline drivers built in it, tooling and it’s even directly in the kernel itself.

The Rust for Linux project is leading the development and the Rust Project is helping to facilitate some of the coordination.

While the project is built on a stable version of the Rust compiler, it relies on language features that are unstable (via the #![feature(...)] declarations). Ultimately, we want to stabilize all the features Rust for Linux relies on and support any platform that Linux itself supports.

Motivation

The status quo

The Rust for Linux page has a great overview of what’s supported and being worked on at the moment.

The project has to use the feature-gated functionality and it’s currently limited to platforms that LLVM supports.

The Rust Project has a regular meeting with the Rust for Linux folks every two weeks and that is where we synchronise on status and discuss any potential road blocks and issues or topics that came out.

We have representatives from the Language and Compiler teams present.

We have also been tracking the coordination through Project goals and this is a continuation of that effort.

Beyond language stabilization, Rust for Linux demonstrates the broader value of Rust in systems software: compartmentalizing unsafe code to reduce critical errors, improving code quality across the kernel (even on the C side — APIs are getting clearer and better documented), and bringing in new contributors who would never have felt confident writing C for low-level systems.

Design axioms

Don’t let perfect be the enemy of good. The primary goal is to offer stable support for the particular use cases that the Linux kernel requires. Wherever possible we aim to stabilize features completely, but if necessary, we can try to stabilize a subset of the functionality that meets the kernel developers’ needs while leaving other aspects unstable.

What we are shooting for

Build Linux kernel releases using the stable Rust language (no feature gates), support all the targets that Linux supports, and address the long tail of features Rust for Linux needs.

How we get there

GoalTimespanWhat and why
Arbitrary self types2026Let user-defined smart pointers work as method receivers, stabilizing the arbitrary_self_types feature.
Deref/Receiver split chain experiment2026Experiment with letting Receiver::Target and Deref::Target diverge, collecting data on utility and use cases.
derive(CoercePointee)2026Support dyn Trait coercion for user-defined smart pointers.
build-std2026Let Cargo rebuild the standard library from source for custom targets and configurations
ADT const params2026Support structs, tuples, arrays in const generics.
Min generic const arguments2026Support associated constants and generic parameters embedded in other expressions.
Stabilize const traits MVP2026Finalize the RFC, complete the compiler implementation, and stabilize so const fn can call trait methods.
Map the field projection design space2026-2028Explore the virtual places approach, document it in the beyond-refs wiki, formalize borrow checker integration, and build a compiler experiment.
In-place initialization2026-2028Align on a language approach for creating values directly at their final location without moving
Move trait2026-2027Let types opt out of being relocated in memory, encoding immovability as a type property rather than a place property.
Guaranteed destructors2026-2027Explore letting types opt out of mem::forget, enabling patterns like safe scoped spawn for async.
Stabilize Rust for Linux compiler features2026-2027Stabilize compiler features the Linux kernel depends on so it can build with only stable Rust
Implement Supertrait auto impl2026Automatically implement supertraits when a subtrait is implemented, enabling trait hierarchy refactoring

Frequently asked questions

When is this done?

When all the work listed here reaches stable Rust — no more #![feature(...)] declarations needed to build the kernel.

How do the goals relate to each other?

The goals largely track independent feature stabilization efforts, coordinated through the biweekly meetings between the Rust Project and Rust for Linux teams.

Other topics

These are other topics Rust for Linux is interested in but that do not have a project goal. There are more (please see the linked lists below), but for 2026 we considered these to be some we would like to focus on. In order of priority (roughly):

  • asm_const_ptr

  • cfg(no_fp_fmt_parse)

  • used_with_arg

  • rustfmt: removing the // hack inside imports (“kernel vertical style”).

    • Essentially being able to trigger the logic that currently gets triggered when rustfmt detects a comment.
  • Coherence domains.

    • Not just for the orphan rule, but also to e.g. define inherent methods on a dependency like core and std do to each other.
    • We will be splitting soon our kernel crate in smaller crates.
  • Niche optimizations.

    • At least for Rust enums that contain pointers to aligned objects (e.g. 4 byte alignment in XArray, or to a page, etc.).
  • Clippy: support for more tagged comments.

    • // PANIC: ..., // CAST: ... and // ORDERING: ....
  • extern types.

    • Currently we use Opaque (a UnsafeCell<MaybeUninit<T>> + PhantomPinned for avoiding uniqueness for mutable references).
  • rustdoc: Stabilizing --output-format=doctest.

  • -Coverflow-checks=report.

    • i.e. a new mode that allows to “report and continue” (wrapping), like UBSan and similar tools.
  • CFI related improvements.

    • fn_cast! macro and bindgen improvements to generate the annotation for CFI encoding on structs.
  • Support packed types to be aligned or to contain aligned members.

    • And bindgen support for it.
  • Custom prelude.

  • build_assert!.

    • Especially ways to fail earlier and/or improve the error messages, similar to GCC’s and Clang’s error/warning attribute.
  • Specialization for improving the performance of our alloc types.

  • --emit=noreturn.

    • We may be able to improve objtool, but having this would significantly improve the situation.
  • Safe transumations.

    • We may vendor zerocopy for now, but long-term we are interested in seeing parts of it make it into the standard library.
  • Contracts/better safety comment tools.

Please see more details at the following Rust for Linux lists: