rust-lang
Split the `-openbsd*` targets by version
Background
OpenBSD's system interfaces are neither forward- nor backward-compatible, which is somewhat unique among the platforms we support. There are a couple of problems this introduces:
- Binaries compiled for our generic
*-openbsdtargets work with an unclear set of OS versions -
libchas no way to represent changes or removals across versions - Informal consensus seems to be that this would prevent the target from getting to tier 2, even with sufficient interest.
Proposal
Replace our generic *-openbsd triples with a versioned triple -openbsdMmm (M = major, m = minor), which will also set target_env. For example, aarch64-unknown-openbsd707correlates to OpenBSD 7.7 (current latest) and will set target_env = "openbsd707". target_env is currently unused on the platform.
This matches the behavior of our QNX Neutrino targets, which have similar version compatibility.
Affected targets:
-
aarch64-unknown-openbsd -
i686-unknown-openbsd -
powerpc-unknown-openbsd -
powerpc64-unknown-openbsd -
riscv64gc-unknown-openbsd -
sparc64-unknown-openbsd
All are tier 3.
Note that, as far as I can tell, the major and minor versions don't have any significance (similar to Linux) and roll over after x.9. That is, there is no more compatibility between 6.8 and 6.9 than between 6.9 and 7.0. Releases happen every 6 months.
Unresolved Questions
- What syntax should be used?
-openbsd707is the format used by qnx-nto, but-openbsd7.7is easier to read and matches LLVM. - Should the existing targets without a version be deprecated, or kept and forward to e.g. the latest release?
- Do we need to have targets for every version, or can we get by creating a new target only when a breaking change happens?
- How long should we retain old versions? OpenBSD seems to maintain releases for 1 year.
Alternatives
- https://github.com/rust-lang/rfcs/pull/2048 was a proposal to support an OS version, deferred for experimentation.
- There have been proposals that allow specifying versions, most recently https://github.com/rust-lang/rfcs/pull/3750. Most of these proposals focus on specifying a minimum version, which isn't sufficient for OpenBSD because of the lack of forward compatibility.
Mentors or Reviewers
Platform maintainer @semarie
Process
The main points of the Major Change Process are as follows:
- [x] File an issue describing the proposal.
- [ ] A compiler team member who is knowledgeable in the area can second by writing
@rustbot secondor kickoff a team FCP with@rfcbot fcp $RESOLUTION.- Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
- [ ] Once an MCP is seconded, the Final Comment Period begins.
- Final Comment Period lasts for 10 days after all outstanding concerns are solved.
- Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
- If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.
You can read more about Major Change Proposals on forge.
[!CAUTION]
Concerns (3 active)
Managed by
@rustbot—see help for details.
[!IMPORTANT] This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
Concerns or objections can formally be registered here by adding a comment.
@rustbot concern reason-for-concern
<description of the concern>
Concerns can be lifted with:
@rustbot resolve reason-for-concern
See documentation at https://forge.rust-lang.org
@rustbot concern version-churn
All OpenBSD versions are "major", according to @semarie, and they seem to do about 2 a year, as compared to QNX's once every 3 years. The sheer amount of work proposed just to add and cycle targets, even just rubberstamping, is rather a lot.
@rustbot concern nonsystematic-breakage
Do we need to have targets for every version, or can we get by creating a new target only when a breaking change happens?
According to @semarie, OpenBSD makes no particularly high effort to determine or maintain compatibility when breaking changes happen. They expect you to rebuild from the new C source code. However, rustc is not a C compiler and does not have a C preprocessor: our extern "C" blocks were designed around the fact that, frankly, OpenBSD's behavior is very unusual, so it is usually reasonable to hand-bind C interfaces. However, with an OS which changes rapidly, we would be simply gambling.
This does not seem very workable. I currently expect we would need to have a system for programmatically adapting to OpenBSD's changes in order to solve the actually important thing of being compatible with OpenBSD code. That, or we would need some other way of actually systematizing our update processes.
@rustbot concern why-not-ports-rustc
Normally, it is often better for something relevant to our internals to live in rust-lang/rust, since we change rapidly and can adapt code to our changes quickly. However, OpenBSD also changes rapidly, in a very similar way, except they also do not have a clear "public interfaces that won't change" boundary. So the question now arises: Why are we going to the effort of maintaining compatibility with them instead of them maintaining compatibility with us? More specifically, we could simply tell people to use their system's compiler, packaged in OpenBSD's ports collection.
Usually we recommend our toolchain, yes, but OpenBSD is unique enough we should confront this question head-on instead of assuming it as a given. We may be paying a higher price than OpenBSD would to maintain compatibility with them. Note this does not need a specific answer, as I intend to accept any justification if T-compiler broadly finds it persuasive, as long as it is somehow distinct from "on principle, because other targets are like this".