Increase the minimum linux-gnu versions

[cuviper]

This is implementing the MCP from rust-lang/compiler-team#493. It is
increasing the minimum requirements of a couple Tier 1 targets, and
others at lower tiers, so this should go through FCP sign-offs for both
T-compiler and T-release.

The new linux-gnu baseline is kernel 3.2 and glibc 2.17. We will also
take that kernel as the minimum floor for all *-linux-* targets, so
it may be broadly assumed in the implementation of the standard library.
That does not preclude specific targets from having greater requirements
where it makes sense, like a new arch needing something newer, or a
platform like linux-android choosing a newer baseline.

[rust-highfive]

r? @pietroalbini

(rust-highfive has picked a reviewer for you, use r? to override)

[cuviper]

Note that this one actually went backwards because crosstool-ng 1.24 doesn't have kernel 4.2, but the nearest are 4.1.49 or 4.4.174. It doesn't make any practical difference AFAIK.

[workingjubilee]

Hmmm. 4.4 is Ubuntu 16 and is "Super LTS", so if we rolled forward here it would be easier to test compliance.

And, well, there were also significant improvements in the Linux kernel's arm64 support in 4.2, 4.3, and 4.4, in particular in atomics and page support. so I think it might actually be better to roll forward, if we have to move one way or another.

[lancethepants]

Many modern Asus wifi6/ax routers are running the 4.1 kernel so I'm glad and appreciate that 4.1 is the baseline for aarch64. I hope it remains there until such time all linux targets are moved beyond this version.

[jonhoo]

This feels worthy of a blog post either to the main Rust blog or to the Inside Rust blog, since it may require some action inside larger organizations using Rust. I also wonder if it might be valuable to delay by at least one stable release after the announcement to give more than one release cycle for big users to make changes they may need to make to absorb this change. Especially because this doesn't feel like a change that it's critical to get out the door asap, unless I'm missing something?

[cuviper]

@jonhoo FWIW this should get at least a little visibility by the FCP section of TWiR, but I suppose we could make a more specific announcement. Do you happen to know of any orgs that will be impacted?

I also wonder if it might be valuable to delay by at least one stable release after the announcement to give more than one release cycle for big users to make changes they may need to make to absorb this change.

There's the natural delay between stuff landing on master before it rides the train to stable, between 6-12 weeks depending on when it merges in the cycle. That's also after the FCP waiting period. Do you imagine needing more than that? I also expect that such careful big orgs can delay their adoption of a new release as needed, on their own time.

[jonhoo]

FWIW this should get at least a little visibility by the FCP section of TWiR, but I suppose we could make a more specific announcement.

This feels like a big enough change to a Tier 1 platform that it's worth a blog post to at least the Inside Rust blog.

Do you happen to know of any orgs that will be impacted?

Amazon + AWS :)

There are a non-trivial number of environments where for one reason or another we are stuck on older versions of GLIBC with "migrate to a newer platforms" is the way to get off of them. Many have migrated, but many are still putting pretty big wheels in motion and will take time to move.

Now, that's not to say we should block upgrading GLIBC for Rust — quite to the contrary. I think Rust moving on is (another) good incentive for those "big wheels" to get moving. But it does suggest that it's worthwhile to give fair warning before making the change (see below).

There's the natural delay between stuff landing on master before it rides the train to stable, between 6-12 weeks depending on when it merges in the cycle. That's also after the FCP waiting period. Do you imagine needing more than that?

Depends on how quickly the FCP lands and when in the release cycle it's released. My thinking was something like two stable releases after the deprecation announcement is posted, which gives about three months of advance warning.

I also expect that such careful big orgs can delay their adoption of a new release as needed, on their own time.

Two points on this, more to give context than anything else.

First, I don't think it's necessarily careful orgs that get hit by this. Instead, it's more a matter of practicality at scale that some users are harder to move than others. Platforms with newer GLIBCs have been available internally for a long time, but when you're running X million lines of code in production on Y hosts with Z users worldwide, something as big as a platform change has to be approached very deliberately and takes time to minimize customer impact.

Second, while it's true that big orgs (or subsets of big orgs) can choose not to adopt new Rust releases if, say, they won't work with the version of GLIBC they happen to be stuck on, doing so comes with its own (often significant) risks. It may mean not getting critical Rust point releases, being unable to take updates to library dependencies that bump their MSRV, or being subject to miscompilations or other compiler bugs with no easy recourse.

I don't say that to argue this change shouldn't happen — again, I definitely think it should — just that it's a change that should be given fair warning and lenient lead time, especially given that it's not urgent for Rust itself to land this change.

[cuviper]

OK, that's all fair. I'm often on that conservative side as well with my Red Hat on -- but that also makes me feel relief when I can finally let an old target go. :) So thanks for that added context, and for registering this as non-blocking. I think that's a reasonable request for an Inside Rust post and two more stable releases as-is.

r? @Mark-Simulacrum perhaps? (on both the PR and this plan)

[pietroalbini]

I can review it tomorrow, sorry for the delay 🙂

r? @pietroalbini

[pietroalbini]

The code changes look good! It'd be nice in the future to make the crosstools config changes actually reviewable, but I trust you did the right tweaks there.

Regarding the communication, the target tier policy states this:

Raising the baseline expectations of a tier 1 target (such as the minimum CPU features or OS version required) requires the approval of the compiler and release teams, and should be widely communicated as well, but does not necessarily require a full RFC.

In addition to the FCP I think it's reasonable to have another two stable releases as-is and mention the future compatibility change in the relnotes and blog post (just a line in the end) of those two releases.

[pietroalbini]

r=me whenever this is ready to merge

[cuviper]

It's ready as far as I'm concerned, but don't you need to initiate the FCP as the reviewer?

[jonhoo]

If the goal is to have two stable releases with this change after it is first announced, then the earliest we should merge this is April 8th assuming the change will be mentioned in the release notes for 1.60 on April 7th.

Speaking of, should we mark this as relnotes? Or do something else to ensure it'll actually be included in the 1.60 release notes even though the change itself hasn't been merged.

[cuviper]

I have the relnotes pr for 1.60, #94817, so I can add that. How do we want to phrase it right now? Say that we will change in 1.62, or just that we're planning to -- and are we soliciting feedback?

(I presume we'll have a more definitive statement in 1.61.)

[pietroalbini]

@rfcbot fcp merge

[rfcbot]

Team member @pietroalbini has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Aaron1011
• @Dylan-DPC
• @Dylan-DPC-zz
• @Mark-Simulacrum
• @cjgillot
• @cuviper
• @davidtwco
• @eddyb
• @estebank
• @lcnr
• @matthewjasper
• @michaelwoerister
• @nagisa
• @nikomatsakis
• @oli-obk
• @petrochenkov
• @pietroalbini
• @pnkfelix
• @tmandry
• @wesleywiser

Concerns:

• we-should-publish-blog-post-before-merging-this resolved by Increase the minimum linux-gnu versions #95026 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[estebank]

If the goal is to have two stable releases with this change after it is first announced, then the earliest we should merge this is April 8th assuming the change will be mentioned in the release notes for 1.60 on April 7th.

It might be prudent to delay the switch even further and publicize our intent ASAP in order to give enough time for people to make their concerns heard. Even if we might end up deciding that what we find aren't blockers, we might be made aware of some that we haven't yet seen.

[Mark-Simulacrum]

I have the relnotes pr for 1.60, #94817, so I can add that. How do we want to phrase it right now? Say that we will change in 1.62, or just that we're planning to -- and are we soliciting feedback?

(I presume we'll have a more definitive statement in 1.61.)

I think just an initial timeline is the right approach here; I would not set a hard expectation of 1.62. In particular, if we get strong feedback that seems actionable (i.e., has a concrete and trusted timeline attached) for ~X release cycles being enough that someone moves off the removed platforms in time, I think that would be worthwhile to consider at least. (Depends on the X, at least, of course).

There is some negative value to a floating window, but I think we can commit to deprecation starting now (~1.61), which just means an edit to the tier support page. As a reversible decision I feel comfortable r+ing that without FCP. We can use the blog post from 1.60 / release notes to determine if we have a 1-cycle (1.61 deprecated, 1.62 removed) deprecation or a longer time period there.

[oblique]

Correct me if I'm wrong, but the minimum Linux version for glibc 2.17 is Linux 2.6.19. Based on this, can you reevaluate the minimum Linux kernel version?

glibc increases its requirements to Linux 3.2 on 2.24 version. I'm actually using an ARM embedded system with glibc 2.23 and Linux 3.0.

[slanterns]

Correct me if I'm wrong, but the minimum Linux version for glibc 2.17 is Linux 2.6.19. Based on this, can you reevaluate the minimum Linux kernel version?

glibc increases its requirements to Linux 3.2 on 2.24 version. I'm actually using an ARM embedded system with glibc 2.23 and Linux 3.0.

It's also about which system apis can be used in libstd. So I think it's a rather fair choice (especially for most of the Rust users with a kernel version >= 3.2).

[cuviper]

Correct me if I'm wrong, but the minimum Linux version for glibc 2.17 is Linux 2.6.19. Based on this, can you reevaluate the minimum Linux kernel version?

That would in effect be doubling our minimum period, taking an old glibc version and using its even older minimum kernel version that made sense at that time. Glibc 2.17 was released on 2012-12-24, and Linux 2.6.19 was released much further back on 2006-11-29. Linux 3.2 was released on 2012-01-04, which is closer to being contemporary with our new minimum glibc.

glibc increases its requirements to Linux 3.2 on 2.24 version.

Right, and they still hold that requirement today, so I cited this as a kernel version that makes sense for current software to continue supporting.

[oblique]

I understand. I was wondering if you were willing to increase only the glibc requirement and Linux kernel requirement stays as it is (2.6.32), but increasing it for using newer system apis is a valid point.

[rylev]

re: perf - given the difficulty of investigating the performance issues and since the largest of regressions are in doc builds (where we have slightly higher tolerances for regressions), I'm going to mark this as triaged.

@rustbot label: +perf-regression-triaged