Building Rust-for-Linux on stable Rust

Posted Sep 25, 2024 2:15 UTC (Wed) by milesrout (subscriber, #126894)
In reply to: Building Rust-for-Linux on stable Rust by cesarb
Parent article: Committing to Rust in the kernel

>are considered experimental, and only enabled when using the pre-release "nightly" version of the compiler. This allows them to iterate on the feature's design, without having to worry about projects outside the compiler and its standard library depending on them.

So why is Linux going to depend on them? How is that supposed to work?

to post comments

Building Rust-for-Linux on stable Rust

Posted Sep 25, 2024 5:11 UTC (Wed) by admalledd (subscriber, #95347) [Link] (2 responses)

There are a few approaches to this, but the basic one that R4L is (mostly) taking is thus:

1. Recommend a specific known nightly or beta build.
2. Often, the specific nightly build chosen is *actually* the same as the then-just-released "stable compiler", but with the nightly features enabled.

Work-in-progress to get to (2), and really I've used a nightly version from over a year ago (mostly) just fine, the stability-or-not of the total compiler is still (nearly) production worthy, it is the specific features themselves that are more a risk. To mitigate that, Rust-For-Linux *explicitly* tracks and lists exactly which ones they use and why: https://github.com/Rust-for-Linux/linux/issues/2 and that it is (strongly) recommended to not add to that list without good reason.

Further, by linking that github issue as they have, any *changes* in the upstream Rust compiler known to change those unstable features the R4L project depends on gets ping'd to them, which they can then address. Most of the time, the features used by R4L are "user stable" in that "Rust *wants* to enable and let users use it exactly like X, but there are some corner cases that we choose to cause the compiler to error on that should work as well". IE: The features R4L are (mostly) using aren't expected to change much if at all from the developer's perspective. If they are likely to need to change though, due to github bot-magic, they will have plenty of warning and involvement before it even hits a nightly release.

Building Rust-for-Linux on stable Rust

Posted Sep 25, 2024 10:03 UTC (Wed) by sam_c (subscriber, #139836) [Link]

Replying to both you and asahilina: thanks. I'm pleased to hear that there's a strong presumption against adding more such cases especially.

Building Rust-for-Linux on stable Rust

Posted Sep 25, 2024 16:56 UTC (Wed) by ojeda (subscriber, #143370) [Link]

To clarify: we have never recommended nightly or beta compilers (specific or not). We have always supported stable (released) compilers only, until v6.11.

Since v6.11, we support a minimum Rust version, currently 1.78.0. Thus 1.79, 1.80 and 1.81 work too. Beta and nightly compilers should also generally work now.

The Rust project and bindgen have now the kernel in their pre-merge CI. This means that unintentional changes to unstable features in Rust that break Linux do not get merged into Rust.

The #2 issue (and the sublists) definitely helps as you say (and it is one of the reasons why I started it in GitHub, since it cross-references issues), but having the CI is even better. Upstream Rust also has a tag for us, A-rust-for-linux, that we are starting to use.

This has also allowed us to cover the toolchains of a few Linux distributions too.

Please see https://rust-for-linux.com/rust-version-policy, as well as the Kernel Summit talk from LPC a few days ago (the stream/video is not available yet, as far as I understand).

Building Rust-for-Linux on stable Rust

Posted Sep 25, 2024 7:06 UTC (Wed) by asahilina (subscriber, #166071) [Link]

There is a backdoor in the stable compiler to enable nightly features. R4L uses this backdoor, and therefore works with stable Rust builds.

Since the features are still "nightly features" they can and do change, which can break the build with newer compiler versions, but the list keeps getting shorter and we try not to add any new required nightly features unless they are necessary or very important to achieve the R4L goals.

At some point all of the features will be promoted to stable, the backdoor will no longer be necessary, and R4L builds will be guaranteed not to break with newer compilers.