Promote powerpc64-unknown-linux-musl to tier 2 with host tools #946
Description
Proposal
Promote the powerpc64-unknown-linux-musl target to tier 2 with host tools.
Tier 2 target requirements
- A tier 2 target must have value to people other than its maintainers. (It may
still be a niche target, but it must not be exclusively useful for an
inherently closed group.)
While big-endian ppc64 is not as common as little-endian ppc64le these days (software side, all little-endian-capable ppc64 hardware is bi-endian), it's still an important target and somewhat widely used and supported. There are several distributions that support ppc64 musl, for example Gentoo, Chimera Linux, Adélie Linux and a community build of Alpine Linux.
Notable supported hardware includes e.g. the Power Mac G5, iMac G5 and IBM servers with POWER6 or newer CPUs. Several game consoles can also run Linux and use PPC64 CPUs (PlayStation 3, XBox 360).
- A tier 2 target must have a designated team of developers (the "target
maintainers") available to consult on target-specific build-breaking issues,
or if necessary to develop target-specific language or library implementation
details. This team must have at least 2 developers.
The target is actively maintained by myself, @neuschaefer and @famfo, see the platform support page. We also already maintain the ppc64le musl target, which is in tier 2 with host tools and, endianness aside, very similar to this target.
- The target must not place undue burden on Rust developers not specifically
concerned with that target. Rust developers are expected to not gratuitously
break a tier 2 target, but are not expected to become experts in every tier 2
target, and are not expected to provide target-specific implementations for
every tier 2 target.
This is not much different from all the other musl targets already at tier 2. It is also a rather modern target, since unlike the existing tier 2 glibc target, it does not use the legacy ELFv1 ABI (which LLD does not support), so it's unlikely to cause issues in the future.
- The target must provide documentation for the Rust community explaining how
to build for the target using cross-compilation, and explaining how to run
tests for the target. If at all possible, this documentation should show how
to run Rust programs and tests for the target using emulation, to allow
anyone to do so. If the target cannot be feasibly emulated, the documentation
should explain how to obtain and work with physical hardware, cloud systems,
or equivalent.
This is already covered by the platform support documentation linked earlier.
- The target must document its baseline expectations for the features or
versions of CPUs, operating systems, libraries, runtime environments, and
similar.
This target use LLVM's ppc64 CPU as the baseline, which is equivalent to a PowerPC 970 (used in the Mac G5) and implies AltiVec (which in turn means that out of IBM server CPUs, POWER6 or newer is required). I'll update the documentation to be more specific on this.
The version requirements for Linux and musl are well-documented already.
- If introducing a new tier 2 or higher target that is identical to an existing
Rust target except for the baseline expectations for the features or versions
of CPUs, operating systems, libraries, runtime environments, and similar,
then the proposed target must document to the satisfaction of the approving
teams why the specific difference in baseline expectations provides
sufficient value to justify a separate target.
Not applicable.
- Tier 2 targets must not leave any significant portions of
coreor the
standard library unimplemented or stubbed out, unless they cannot possibly be
supported on the target.
This target supports the full standard library functionality.
- The code generation backend for the target should not have deficiencies that
invalidate Rust safety properties, as evaluated by the Rust compiler team.
(This requirement does not apply to arbitrary security enhancements or
mitigations provided by code generation backends, only to those properties
needed to ensure safe Rust code cannot cause undefined behavior or other
unsoundness.) If this requirement does not hold, the target must clearly and
prominently document any such limitations as part of the target's entry in
the target tier list, and ideally also via a failing test in the testsuite.
The Rust compiler team must be satisfied with the balance between these
limitations and the difficulty of implementing the necessary features.
The LLVM codegen backend is used.
- If the target supports C code, and the target has an interoperable calling
convention for C code, the Rust target must support that C calling convention
for the platform viaextern "C". The C calling convention does not need to
be the default Rust calling convention for the target, however.
The C calling convention is supported.
- The target must build reliably in CI, for all components that Rust's CI
considers mandatory.
All components that are typically distributed through rustup build just fine.
- The approving teams may additionally require that a subset of tests pass in
CI, such as enough to build a functional "hello world" program,
./x.py test --no-run, or equivalent "smoke tests". In particular, this requirement may
apply if the target builds host tools, or if the tests in question provide
substantial value via early detection of critical problems.
- Building the target in CI must not take substantially longer than the current
slowest target in CI, and should not substantially raise the maintenance
burden of the CI infrastructure. This requirement is subjective, to be
evaluated by the infrastructure team, and will take the community importance
of the target into account.
- Tier 2 targets should, if at all possible, support cross-compiling. Tier 2
targets should not require using the target as the host for builds, even if
the target supports host tools.
The target supports cross-compilation and programs could be run in QEMU in CI if desired. The build time is similar to the glibc or little endian targets.
- In addition to the legal requirements for all targets (specified in the tier
3 requirements), because a tier 2 target typically involves the Rust project
building and supplying various compiled binaries, incorporating the target
and redistributing any resulting compiled binaries (e.g. built libraries,
host tools if any) must not impose any onerous license requirements on any
members of the Rust project, including infrastructure team members and those
operating CI systems. This is a subjective requirement, to be evaluated by
the approving teams.
No license issues to my knowledge.
- Tier 2 targets must not impose burden on the authors of pull requests, or
other developers in the community, to ensure that tests pass for the target.
In particular, do not post comments (automated or manual) on a PR that derail
or suggest a block on the PR based on tests failing for the target. Do not
send automated messages or notifications (via any medium, including via@)
to a PR author or others involved with a PR regarding the PR breaking tests
on a tier 2 target, unless they have opted into such messages.
Should not cause issues.
- The target maintainers should regularly run the testsuite for the target, and
should fix any test failures in a reasonably timely fashion.
We regularly run the testsuite for the powerpc64(le) targets.
- All requirements for tier 3 apply.
Ack.
Tier 2 With Host Tools Requirements
Some tier 2 targets may additionally have binaries built to run on them as a host (such as rustc and cargo). This allows the target to be used as a development platform, not just a compilation target.
A proposed new tier 2 target with host tools must be reviewed and approved by the compiler team based on these requirements. Such review and approval may occur via a Major Change Proposal (MCP).
In addition, the infrastructure team must approve the integration of the target's host tools into Continuous Integration (CI), and the CI-related requirements for host tools. This review and approval may take place in a PR adding the target's host tools to CI, or simply by an infrastructure team member reporting the outcome of a team discussion.
- Depending on the target, its capabilities, its performance, and the likelihood of use for any given tool, the host tools provided for a tier 2 target may include only rustc and cargo, or may include additional tools such as clippy and rustfmt.
- Approval of host tools will take into account the additional time required to build the host tools, and the substantial additional storage required for the host tools.
POWER hardware is usually high-performance and can be used as a workstation, therefore I would like to request additional tools to be included.
- The host tools must have direct value to people other than the target's maintainers. (It may still be a niche target, but the host tools must not be exclusively useful for an inherently closed group.) This requirement will be evaluated independently from the corresponding tier 2 requirement.
- The requirement to provide "direct value" means that it does not suffice to argue that having host tools will help the target's maintainers more easily provide the target to others. The tools themselves must provide value to others.
- There must be a reasonable expectation that the host tools will be used, for purposes other than to prove that they can be used.
Rust developers using one of the distributions mentioned at the beginning would greatly benefit from e.g. having nightly Rust builds available.
- The host tools must build and run reliably in CI (for all components that Rust's CI considers mandatory), though they may or may not pass tests.
They build fine for me locally and there's no reason to assume they wouldn't in CI.
- Building host tools for the target must not take substantially longer than building host tools for other targets, and should not substantially raise the maintenance burden of the CI infrastructure.
Ditto, this target is very similar to existing tier 2 with host tools targets also in this regard.
- The host tools must provide a substantively similar experience as on other targets, subject to reasonable target limitations.
- Adding a substantively different interface to an existing tool, or a target-specific interface to the functionality of an existing tool, requires design and implementation approval (e.g. RFC/MCP) from the appropriate approving teams for that tool.
- Such an interface should have a design that could potentially work for other targets with similar properties.
- This should happen separately from the review and approval of the target, to simplify the target review and approval processes, and to simplify the review and approval processes for the proposed new interface.
- By way of example, a target that runs within a sandbox may need to modify the handling of files, tool invocation, and similar to meet the expectations and conventions of the sandbox, but must not introduce a separate "sandboxed compilation" interface separate from the CLI interface without going through the normal approval process for such an interface. Such an interface should take into account potential other targets with similar sandboxes.
Not applicable, tools don't require changes.
- If the host tools for the platform would normally be expected to be signed or equivalent (e.g. if running unsigned binaries or similar involves a "developer mode" or an additional prompt), it must be possible for the Rust project's automated builds to apply the appropriate signature process, without any manual intervention by either Rust developers, target maintainers, or a third party. This process must meet the approval of the infrastructure team.
- This process may require one-time or semi-regular manual steps by the infrastructure team, such as registration or renewal of a signing key. Any such manual process must meet the approval of the infrastructure team.
- This process may require the execution of a legal agreement with the signature provider. Such a legal agreement may be revocable, and may potentially require a nominal fee, but must not be otherwise onerous. Any such legal agreement must meet the approval of the infrastructure team. (The infrastructure team is not expected or required to sign binding legal agreements on behalf of the Rust project; this review and approval exists to ensure no terms are onerous or cause problems for infrastructure, especially if such terms may impose requirements or obligations on people who have access to target-specific infrastructure.)
- Changes to this process, or to any legal agreements involved, may cause a target to stop meeting this requirement.
- This process involved must be available under substantially similar non-onerous terms to the general public. Making it available exclusively to the Rust project does not suffice.
- This requirement exists to ensure that Rust builds, including nightly builds, can meet the necessary requirements to allow users to smoothly run the host tools.
This is not applicable, no signing or other changes to the release process are required.
- Providing host tools does not exempt a target from requirements to support cross-compilation if at all possible.
- All requirements for tier 2 apply.
Ack.
Process
The main points of the Major Change Process are as follows:
- File an issue describing the proposal.
- A compiler team member or contributor who is knowledgeable in the area can second by writing
@rustbot second.- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
-C flag, then full team check-off is required. - Compiler team members can initiate a check-off via
@rfcbot fcp mergeon either the MCP or the PR.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
- Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.
You can read more about Major Change Proposals on forge.
Comments
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.