Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Increasing Rustix's minimum supported Linux version to 3.2 #907

Closed
sunfishcode opened this issue Oct 28, 2023 · 3 comments · Fixed by #927
Closed

Increasing Rustix's minimum supported Linux version to 3.2 #907

sunfishcode opened this issue Oct 28, 2023 · 3 comments · Fixed by #927

Comments

@sunfishcode
Copy link
Member

So far, rustix's approach has been to aim to support the Linux versions that Rust supported in rustix's MSRV. The MSRV is currently 1.63, which happens to have supported Linux 2.6.32. However, the choice of Rust 1.63 was guided by Debian stable, while this approach implies supporting Linux 2.6.32 which is older than Debian oldoldstable at this point.

This hasn't usually been a problem, because we can still provide support for features in newer Linux versions, and they'll just fail with NOSYS or OPNOTSUPP at runtime if they're not supported. However, in a few areas, such as the one reported in #905, this is starting to become a burden.

I propose we adopt and document a minimum supported Linux version policy, guided by taking the minimum version of all Linux versions supported by any Rust target (currently 3.2) and the oldest version in Debian stable (currently 4.19) at the time of a rustix release. The choice of Debian stable here and in the MSRV isn't due to any specific requirement, and is just used as a representative "very stable Linux distro". I'm open to feedback on better ways to determine either of these versions.

Do we need a semver bump for this? My guess is that we don't, at least for this initial policy. Linux 3.2 is sufficiently old that I don't expect we need to worry about it at this time.

Comments, questions, and feedback are encouraged!

@joshtriplett
Copy link
Member

I think, in practice, "minimum of oldest version supported by a Rust target and version in Debian stable" is going to reduce to "oldest version supported by a Rust target", since we're very unlikely to require a newer kernel than Debian stable.

I would also suggest that, for any target-specific code in rustix, the minimum version should be the kernel version supported by that Rust target, which might be newer. For instance, a rustix feature that's specific to aarch64 Linux targets could assume Linux 4.1, since the aarch64 Linux targets for Rust require Linux 4.1.

Otherwise, this seems like a reasonable conservative policy. Anything less conservative than that could be driven by feature flags opting into requiring newer kernel versions.

@notgull
Copy link
Contributor

notgull commented Oct 28, 2023

Linux 3.2 is still glacially old. I support this bump.

sunfishcode added a commit that referenced this issue Nov 10, 2023
Add a Minimum Linux Version policy, which is currently Linux 3.2, and
enable `ClockId::Boottime` and other values without extra feature gates.

Fixes #905.
Fixes #907.
sunfishcode added a commit that referenced this issue Nov 10, 2023
Add a Minimum Linux Version policy, which is currently Linux 3.2, and
enable `ClockId::Boottime` and other values without extra feature gates.

Fixes #905.
Fixes #907.
sunfishcode added a commit that referenced this issue Nov 10, 2023
Add a Minimum Linux Version policy, which is currently Linux 3.2, and
enable `ClockId::Boottime` and other values without extra feature gates.

Fixes #905.
Fixes #907.
@sunfishcode
Copy link
Member Author

I've now opened #927 to document the Linux 3.2 requirement.

sunfishcode added a commit that referenced this issue Nov 17, 2023
Add a Minimum Linux Version policy, which is currently Linux 3.2, and
enable `ClockId::Boottime` and other values without extra feature gates.

Fixes #905.
Fixes #907.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants