libstd: Drop RHEL 5 support, Increase Minimum kernel version to 2.6.27

[josephlr]

The docs currently claim that the minimum Linux kernel version for libstd is 2.6.18 (released September 20th, 2006). This is because RHEL 5 used that kernel version. However, RHEL 5 entered ELS on March 31, 2017.

Should we continue to support RHEL 5 for libstd, or should we increase the minimum Linux Kernel version to 2.6.27 (2nd LTS) or 2.6.32 (RHEL 6, 3rd LTS)? List of the relevant kernel versions.

Even bumping the min-version to 2.6.27 would allow us to remove most of the Linux-specific hacks in libstd. Example: the O_CLOEXEC code.

[josephlr]

Given that RHEL is the only reason we keep comically old kernel versions around, I would propose that Rust only support RHEL until Maintenance Support ends. This is (essentially) what we already did for RHEL 4. Rust never supported RHEL 4, and set its minimum supported Linux Kernel version back when RHEL 5 still had maintenance support.

It would be nice to get someone from Red Hat or a RHEL customer to comment. This policy would allow us to increment the minimum kernel from 2.6.18 to 2.6.32 (and remove a lot of Linux-specific hacks).

Note that RHEL has a weird (and very long) support system for RHEL 4, 5, and 6 (sources: dates and service details). It has 5 major steps:

• Full Support
  • Normal support of the OS
• Maintenance Support 1
  • Bug/Security fixes
  • Limited hardware refresh
• Maintenance Support 2
  • Bug/Security fixes
  • The end of this phase is considered "Product retirement"
• Extended Life Cycle Support (ELS)
  • Additional paid product from Red Hat
  • Gives updates for a longer period of time
  • No additional releases/images
• Extended Life Phase (ELP)
  • No more updates
  • Limited Technical Support
  • End date not given by Red Hat

Current status of RHEL versions:

• RHEL 4
  • Not supported by Rust
  • Currently in ELP (no end date specified)
  • ELS ended March 31, 2017
• RHEL 5
  • Supported by Rust
  • Currently in ELS
  • Maintenance Support ended March 31, 2017
  • ELS ends November 30, 2020
• RHEL 6
  • Supported by Rust
  • Currently in Maintenance Support 2
  • Maintenance Support ends November 30, 2020

[tesuji]

cc @cuviper which I think they could be related.

[newpavlov]

It also may be worth to drop support of Windows XP and Vista (especially considering that panics are broken on XP since June 2016, see: #34538). Previously it was discussed here.

cc @steveklabnik

[briansmith]

Even bumping the min-version to 2.6.27 would allow us to remove most of the Linux-specific hacks in libstd. Example: the O_CLOEXEC code.

Besides O_CLOEXEC, which other things would we be able to clean up?

[josephlr]

Besides O_CLOEXEC, which other things would we be able to clean up?

Good question! There are 6 workarounds in libstd for older Linux versions (that I could find). Increasing the minimum version to 2.6.32 (aka 3rd Kernel LTS, aka RHEL 6) would fix 5 of them. Code links are inline:

• File::open_c uses the O_CLOEXEC flag with open(2) (mentioned above, added in 2.6.23)
• FileDesc::duplicate uses F_DUPFD_CLOEXEC with fcntl(2) (added in 2.6.24, there is also the mention of a bug occuring on "some linux kernel at some point")
• pipe::anon_pipe uses pipe2(2) to atomically set the O_CLOEXEC flag on the pipe fds (added in 2.6.27)
• Socket::new_raw uses SOCK_CLOEXEC with socket(2) (added in 2.6.27)
• Socket::accept uses accept4(2) to permit use of SOCK_CLOEXEC (added in 2.6.28)
• fs::copy uses copy_file_range(2) (added in 4.5, not fixed by this proposal)

As you can see, the workarounds fixed by this proposal all have a similar flavor.

[cuviper]

I am Red Hat's maintainer for Rust on RHEL -- thanks @lzutao for the cc. I try to keep an eye on new issues, but this one slipped past me.

Red Hat only ships the Rust toolchain to customers for RHEL 7 and RHEL 8. If our customers would like to use Rust on older RHEL, they can do so via rustup, and we'll support them in the same way we would for any other third-party software.

Internally we do also build and use rustc on RHEL 6, mostly because it's needed to ship Firefox updates. This is where it gets a little hairy, because each RHEL N is bootstrapped on RHEL N-1 and often kept that way -- meaning a lot of our RHEL 6 builders are still running on a RHEL 5 kernel. I would have to apply local workarounds if upstream Rust loses the ability to run on 2.6.18 kernels. We prefer to keep fixes upstream as much as possible, both for open sharing and to avoid bitrot.

Is there much of a benefit to removing the current workarounds? I agree all of that CLOEXEC code is annoying and cumbersome, but it's already written, and as far as I know it hasn't been a maintenance burden. Do you see otherwise?

If there are any known issues with such Linux compatibility code, I am definitely willing to take assignment for fixing them.

[alex]

(Not a Rust maintainer, but I'm a Rust user and maintain a lot of other OSS software so I have well-developed feelings around supporting Very Old Software :-))

Do you have any sense of on what timeline Rust would be able to drop support for 2.6.18 kernels without causing you pain?

In general I don't think people mind supporting configurations that have users and are painful to work around, but needing to support them for forever is a bitter pill to swallow! Particularly as they get harder and harder to test over time (already I have no idea how to test on really old kernels besides building it myself). So if there was an estimate "we'd like to be able to support this until Q2 2020", even if it's not set in stone, I think that would be very helpful!

[nikic]

@cuviper The other benefit would be that Rust wouldn't have to use CentOS 5 for CI, which means we don't have to patch LLVM (and Emscripten LLVM) to compile on those systems. Of course that's also fairly limited in scope.

[cuviper]

@alex

Do you have any sense of on what timeline Rust would be able to drop support for 2.6.18 kernels without causing you pain?

As soon as we stop shipping Firefox and Thunderbird updates on RHEL 6, I won't need Rust there anymore. AFAIK this does correspond to the end of Maintenance Support, approximately November 30, 2020. Then I'll be on to RHEL 7 builders as my minimum, probably still with some RHEL 6 2.6.32 kernels involved.

@nikic

The other benefit would be that Rust wouldn't have to use CentOS 5 for CI

It should be fine for me if we update CI to CentOS 6. This is mostly concerned with how the release binaries are linked to GLIBC symbol versions, which is all in userspace. It's a broader community question whether any other Rust users still care about running on RHEL or CentOS 5.

(Small caveat - glibc support for a symbol can still return ENOSYS, as noted for pipe2.)