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 in stable: compiler features

Metadata
Point of contactTomas Sedovic
StatusProposed
Tracking issuerust-lang/rust-project-goals#407
Zulip channel[#rust-for-linux][channel-rfl]
Stabilizationtrue
compiler championWesley Wiser
Teamscompiler
Task owners(none)

Summary

Develop and stabilize compiler features that Rust for Linux uses. This is a continuation of the existing Rust for Linux effort.

Motivation

Getting the Linux kernel to build with stable Rust and, more generally, supporting the needs of the Linux kernel to make Rust a success there, has been a priority for the Rust project and a previous flagship goal: 2024H2, 2025H1.

One of the key areas are compiler features, which encompass a wide range of topics: architecture/target-related flags, sanitizers, mitigations, performance/optimization-oriented flags, and so on.

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

The status quo

The Linux kernel, at the time of writing, relies on some Rust compiler unstable features such as:

There are others that we will want to start using in the future, such as:

There is also the build-std project goal support that we need as well (or, rather, only “build-core” for the Linux kernel), and the sanitizers project goal.

What we propose to do about it

We track each compiler feature we’re interested in and move them forward towards stabilization. Historically, this was done by either compiler developers or the Rust for Linux team members.

Work items over the next year

Ideally, the Linux kernel would not need to rely on any of the existing compiler unstable features by the time the period is over, but that is fairly unlikely. Thus, any progress on any feature (or an alternative to using a given unstable feature) would be welcome.

In particular, finishing the work and stabilizing the features that the kernel is already using upstream would be considered a major success.

Longer-term, the Linux kernel does not rely on any compiler-related unstable feature anymore, except for those that may need to be added in the future for different reasons, such as:

  • New hardware features.
  • New mitigations.
  • New sanitizers.
  • New architectures.

For that reason, this goal is conceptually never ending, even if we may reach points where no unstable compiler feature is actually used.

Team asks

TeamSupport levelNotes
compilerMediumReviews, RfL meetings