Building Rust-for-Linux on stable Rust

Posted Sep 24, 2024 18:42 UTC (Tue) by sam_c (subscriber, #139836)
In reply to: Building Rust-for-Linux on stable Rust by josh
Parent article: Committing to Rust in the kernel

Genuinely quite pleased to hear this as it's been causing us a lot of concern.

But I do wonder how this also isn't a sign that Rust isn't stable enough for use yet in the kernel? Nobody is adding dependencies on bleeding-edge GCC or Clang for unratified C features which may change at any point ("unstable"). Extensions do get used but that is once the compilers agree they're an interface and not subject to change, and the kernel always has fallbacks for older GCC and Clang where they're not available.

to post comments

Building Rust-for-Linux on stable Rust

Posted Sep 24, 2024 18:51 UTC (Tue) by mb (subscriber, #50428) [Link] (5 responses)

>Extensions do get used but that is once the compilers agree

That's pretty much not true historically.
For most of the time Linux just used what gcc provided as an extension and didn't care about anything else or whether it was "mature enough".

>and the kernel always has fallbacks for older GCC

Distributions used to ship special versions of gcc just for the kernel.

Building Rust-for-Linux on stable Rust

Posted Sep 24, 2024 18:54 UTC (Tue) by sam_c (subscriber, #139836) [Link] (4 responses)

> For most of the time Linux just used what gcc provided as an extension and didn't care about anything else or whether it was "mature enough".

It took a very long time indeed to agree to use newer C: https://lwn.net/Articles/885941/.

> Distributions used to ship special versions of gcc just for the kernel.

That doesn't mean we want to return to that. But the minimum GCC version even now is pretty conservative anyway?

Building Rust-for-Linux on stable Rust

Posted Sep 24, 2024 23:50 UTC (Tue) by Heretic_Blacksheep (subscriber, #169992) [Link] (3 responses)

Kernel docs says minimum version is GCC v. 5.1, but it varies depending on architecture. Obviously recently ported hardware would require a newer GCC so take that with a grain of salt. If a (micro)arch was only integrated into GCC last year, that's your likely minimal version. The rest of the build tools versions vary similarly.

Building Rust-for-Linux on stable Rust

Posted Sep 27, 2024 12:26 UTC (Fri) by andy_shev (subscriber, #75870) [Link] (1 responses)

“Obviously recently ported hardware would require a newer GCC so take that with a grain of salt.” Obviously? Not at all to me! Can you elaborate on how you came to this conclusion? (Also it looks like you missed word “driver” along the lines)

Building Rust-for-Linux on stable Rust

Posted Sep 27, 2024 16:55 UTC (Fri) by knewt (subscriber, #32124) [Link]

>> “Obviously recently ported hardware would require a newer GCC so take that with a grain of salt.” Obviously? Not at all to me! Can you elaborate on how you came to this conclusion? (Also it looks like you missed word “driver” along the lines)

I imagine the thought here is that newer processor architectures will have only gotten GCC support more recently, and as such only in newer versions of GCC, which feels reasonable.

Building Rust-for-Linux on stable Rust

Posted Sep 27, 2024 16:59 UTC (Fri) by knewt (subscriber, #32124) [Link]

>> Kernel docs says minimum version is GCC v. 5.1, but it varies depending on architecture.

In coincidental timing, seems that's getting bumped up as of 6.13! This patch is in the pipeline as of recently:

========
From: Ard Biesheuvel <ardb@kernel.org>

Bump the minimum GCC version to 8.1 to gain unconditional support for
referring to the per-task stack cookie using a symbol rather than
relying on the fixed offset of 40 bytes from %GS, which requires
elaborate hacks to support.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
========

Building Rust-for-Linux on stable Rust

Posted Sep 24, 2024 20:25 UTC (Tue) by cesarb (subscriber, #6266) [Link] (14 responses)

The issue is that Rust developers are very conservative about new language features; unlike GCC (and clang which copied the behavior from GCC) which always allows the use of language extensions, on Rust all these language features (which would be extensions in GCC) 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.

> and the kernel always has fallbacks for older GCC and Clang where they're not available.

It doesn't; the kernel uses several non-standard GCC extensions with no fallback, and requires a version of GCC or clang which is recent enough to provide all these required extensions.

Building Rust-for-Linux on stable Rust

Posted Sep 24, 2024 20:50 UTC (Tue) by pizza (subscriber, #46) [Link] (8 responses)

> It doesn't; the kernel uses several non-standard GCC extensions with no fallback, and requires a version of GCC or clang which is recent enough to provide all these required extensions.

While what you are saying is _technically_ correct, the details paint a very different story.

Linux only requires GCC 5.1, which was released *nine years* ago. Versus rustc 1.78, which only landed *four months* ago.

(Or you could use LLVM/Clang intstead of GCC, that requires a ~2.5-year old version (13.0.1)

Source: https://www.kernel.org/doc/html/next/process/changes.html

Building Rust-for-Linux on stable Rust

Posted Sep 24, 2024 22:33 UTC (Tue) by intelfx (subscriber, #130118) [Link] (6 responses)

> While what you are saying is _technically_ correct, the details paint a very different story.

Only if you conveniently ignore some of these details and highlight the others.

> Linux only requires GCC 5.1, which was released *nine years* ago. Versus rustc 1.78, which only landed *four months* ago.

Yes, so how old is the C code in Linux, and how old is the Rust code in Linux? And how much time did it take (since the inception of $LANGUAGE code in Linux) to arrive at this state of affairs?

I’ve said it before, and I’ll say it again: it is unfair and disingenuous that the “new contender” is immediately required to clear the bar that nothing else was subjected to for a damn long time.

Building Rust-for-Linux on stable Rust

Posted Sep 25, 2024 0:06 UTC (Wed) by pizza (subscriber, #46) [Link] (5 responses)

> I’ve said it before, and I’ll say it again: it is unfair and disingenuous that the “new contender” is immediately required to clear the bar that nothing else was subjected to for a damn long time.

It is unfair to deliberately misstate Linux's C compiler requirements as well.

When Linux 5.15 bumped the minimum version to GCC 5.1, the latter had been available for *seven years*. (As opposed to the then-brand-new GCC 11)

Building Rust-for-Linux on stable Rust

Posted Sep 25, 2024 4:48 UTC (Wed) by khim (subscriber, #9252) [Link] (4 responses)

And when Linus presented Linux in comp.os.minix he explicitly have written: It also uses every feature of gcc I could find. And he used the most recent version of gcc he could find.

Now, that doesn't mean that then need to use bleeding version of Rust would stay with us forever, but I don't see why Rust have to be treated differently from how C was treated in the Linux bringup phase.

Building Rust-for-Linux on stable Rust

Posted Sep 25, 2024 11:56 UTC (Wed) by pizza (subscriber, #46) [Link] (3 responses)

> Now, that doesn't mean that then need to use bleeding version of Rust would stay with us forever, but I don't see why Rust have to be treated differently from how C was treated in the Linux bringup phase.

Because unlike Linus's original announcement of Linux 30-odd years ago, Linux is no longer a just-for-fun toy.

If Rust proponents claim that the quality standards/practices of yesteryear are wholly insufficient today then they can't claim "waaah we're being held to a higher standard than ysteryear" when the mirror is turned on them.

The response to the "Rust tooling is still immature and doesn't cover all use cases that some folks need" *fact* should be (and according to the _actual_ R4L devs, is) "We're still working on it; we'll get there", not "waah different standards, give us special treatment instead" or "those use cases don't matter" of the _very_ annoying fanbois that keep coming out of the woodwork.

Building Rust-for-Linux on stable Rust

Posted Sep 25, 2024 14:15 UTC (Wed) by intelfx (subscriber, #130118) [Link]

> The response to the "Rust tooling is still immature and doesn't cover all use cases that some folks need" *fact* should be (and according to the _actual_ R4L devs, is) "We're still working on it; we'll get there", not "waah different standards, give us special treatment instead" or "those use cases don't matter" of the _very_ annoying fanbois that keep coming out of the woodwork.

Now this is a case of shifting the goalposts.

The response is, and always was, "We're still working on it and we'll get there". Nobody has ever said "waah different standards" while asking for "special treatment". The problem with different standards is merely that certain vocal people want "getting there" to happen in zero time. C did not get there in zero time, so why does Rust have to?

Building Rust-for-Linux on stable Rust

Posted Oct 2, 2024 10:57 UTC (Wed) by taladar (subscriber, #68407) [Link] (1 responses)

Seems to me that C is a pretty immature language if you need a 9 year old compiler because some platforms are so reluctant to update that unstable mess to a newer version that they are almost 10 major versions behind the current version.

Seems if you try even a little bit portraying the facts to make the process the other side uses look bad is actually pretty easy.

Building Rust-for-Linux on stable Rust

Posted Oct 2, 2024 12:12 UTC (Wed) by pizza (subscriber, #46) [Link]

> Seems to me that C is a pretty immature language if you need a 9 year old compiler because some platforms are so reluctant to update that unstable mess to a newer version that they are almost 10 major versions behind the current version.

For Linux, said 9-year-old compiler is the *minimum* required version, not the *only* version that is supported/expected to work.

(I am typing these words on a system with the most recent Linux release, compiled using the most recent GCC release)

> Seems if you try even a little bit portraying the facts to make the process the other side uses look bad is actually pretty easy.

Another thing that makes you look bad is deliberately mis-stating documented facts.

Building Rust-for-Linux on stable Rust

Posted Sep 25, 2024 1:22 UTC (Wed) by Wol (subscriber, #4433) [Link]

> Linux only requires GCC 5.1, which was released *nine years* ago. Versus rustc 1.78, which only landed *four months* ago.

istr that for many years Linux had a *maximum* version of gcc, which was positively ancient! If Linux can complain, at different times, that some gccs are too old, while other gccs are too new, then why can't it complain that some rustcs are too old, while others are too new? It is what it is. You just have to use whatever compiler that works.

At the end of the day, the version of the compiler is irrelevant. Seeing as most of the Rust code currently appears to be drivers, if the compiler is contemporaneous with the hardware or feature, what's the problem?

Cheers,
Wol

Building Rust-for-Linux on stable Rust

Posted Sep 25, 2024 2:15 UTC (Wed) by milesrout (subscriber, #126894) [Link] (4 responses)

>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?

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.