Please document the intended policy for minimum Linux kernel versions

[joshtriplett]

I'd love to see mustang have a documented policy for how it selects the minimum Linux kernel version it supports, as well as the current minimum version.

I can imagine three possible policies here:

1. Recent kernels: require a relatively recent kernel, so that mustang can unconditionally use new system calls without fallbacks (or missing functionality if there's no reasonable fallback). This would be appropriate if mustang is primarily demonstrating the best and simplest possible implementation path, without worrying about widespread production use outside of deployment environments people can entirely control.
2. Stable kernels: Require a kernel within the last few years, roughly allowing for "last stable release of common Linux distributions". This would require some fallbacks for new functionality, but fewer of them. This would be appropriate for widespread production use of mustang, including use in containers and distribution of common tools (e.g. precompiled versions of command-line tools).
3. Enterprise kernels: Support every kernel version Rust currently supports. This would require the largest number of fallbacks, but support anyone who could possibly run mustang on any Rust system.

[sunfishcode]

Interesting question!

Right now, in theory, Mustang should run on all Linux versions Rust currently supports. Most of the work for detecting which syscalls are available and for running fallback logic that std needs lives in std itself. Mustang's current approach is to replace libc and use std without modifications, so all the existing fallback code should "just work". That said, the only testing that's been set up so far just the Linux versions available on Github Actions.

If Mustang starts working toward becoming an official Rust target of its own, I imagine it'll go with option 1 or 2. I'd be interested to hear what people who might want to use Mustang in any of the above scenarios think.

[npmccallum]

I suspect the biggest change you might want to consume from recent versions is the ability to set fsbase and gsbase from userspace. That alone might be enough to make you require recent kernels.

[sunfishcode]

Could you say more about the use case you have in mind for fsbase and gsbase? Would this be for Mustang's own use, or for exposing these for applications to use (when they aren't being used as TLS pointers)?

[npmccallum]

@sunfishcode My point was that you might want to depend on them for implementing TLS.

[sunfishcode]

For TLS, we use system calls to set up the fs/gs registers. They're slower than setfsgsbase, but we only call them once per process, to set the TLS address for the main thread, so it doesn't turn out to be significant for performance.

[sunfishcode]

Here's how things look to me right now.

std tends to avoid features which don't work on all supported Linux versions. And std already does use new Linux syscalls to optimize things when they happen to fit into what it's already doing. As such, there aren't many opportunities to use new Linux syscalls to do the things std does in different ways. It'd be fun to avoid ENOSYS/AtomicBool code dealing with older versions, and it'd be fun to have a codebase with fewer #[cfg(...)]s, but those aren't clearly worth all the work they would require.

If someone sees an opportunity to do things differently, or wants to help out with the work required to do something different, I'm open to it. But until then, it seems like Mustang will continue to pursue something like option 3: Aim to support all versions of Linux supported by Rust. We don't have testing for the older versions yet, so there could be bugs yet, but hopefully we'll fix those over time.

[sunfishcode]

I've now posted #74 to document this.

[sunfishcode]

The policy is now documented. As I mentioned above, I'm happy to discuss opportunities to do something different.