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

Promote x86_64-unknown-none to Tier 2 #499

Closed
1 of 3 tasks
bstrie opened this issue Mar 23, 2022 · 5 comments
Closed
1 of 3 tasks

Promote x86_64-unknown-none to Tier 2 #499

bstrie opened this issue Mar 23, 2022 · 5 comments
Labels
major-change A proposal to make a major change to rustc major-change-accepted A major change proposal that was accepted T-compiler Add this label so rfcbot knows to poll the compiler team

Comments

@bstrie
Copy link

bstrie commented Mar 23, 2022

Proposal

Promote the x86_64-unknown-none target to Tier 2.

This target was originally proposed for Tier 3 in #462 and implemented in rust-lang/rust#89062 .

Tier 2 Target Requirements

A tier 2 target must have value to people other than its maintainers.

This target is useful to anyone doing bare-metal development on x86-64, including kernels and firmware.

A tier 2 target must have a designated team of developers.

This target is maintained by @haraldh and @mikeleany .

The target must not place undue burden on Rust developers not specifically concerned with that target.

Other than lacking an OS, this target is standard x86-64. This target deliberately does not support libstd, so it imposes no additional library burden.

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.

Documentation is provided for building and testing.

The target must document its baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar.

Documentation is provided for platform requirements.

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.

There are two similar Tier 3 targets: x86_64-unknown-none-hermitkernel and x86_64-unknown-none-linuxkernel. The maintainers of the former are amenable to replacing their target with x86_64-unknown-none: rust-lang/rust#90404. The maintainer of the latter also appears amenable to using a standardized target: rust-lang/rust#64051 (comment) . We envision that x86_64-unknown-none will supplant these two targets.

Tier 2 targets must not leave any significant portions of core or the standard library unimplemented or stubbed out, unless they cannot possibly be supported on the target. As an exception, a target identical to an existing tier 1 target except for lower baseline expectations for the OS, CPU, or similar, may propose to qualify as tier 2 (but not higher) without support for std if the target will primarily be used in no_std applications, to reduce the support burden for the standard library. In this case, evaluation of the proposed target's value will take this limitation into account.

This target qualifies for the listed exception. While libstd cannot be supported, there is no difficulty in supporting libcore.

The code generation backend for the target should not have deficiencies that invalidate Rust safety properties, as evaluated by the Rust compiler team.

I hope the compiler team will confirm, but as far as I am aware there is no deficiency in LLVM's ability to generate stack probes etc. for this target.

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 via extern "C".

This target supports extern "C" via the System V calling convention (without red zones).

The target must build reliably in CI, for all components that Rust's CI considers mandatory.

We have not yet tried to build in CI, but I see no reason to suspect this will not be satisfied.

The approving teams may additionally require that a subset of tests pass in CI.

None of the other unknown-none targets appear to run any tests as part of CI.

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 is not anticipated.

Tier 2 targets should, if at all possible, support cross-compiling.

This target does not provide host tools, so it exclusively supports cross-compiling.

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.

Distributing this target does not involve distributing any new third-party code.

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.

This target runs no tests.

The target maintainers should regularly run the testsuite for the target, and should fix any test failures in a reasonably timely fashion.

Same as the previous.

Mentors or Reviewers

@joshtriplett

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 merge on either the MCP or the PR.
  • 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.

@bstrie bstrie added T-compiler Add this label so rfcbot knows to poll the compiler team major-change A proposal to make a major change to rustc labels Mar 23, 2022
@rustbot
Copy link
Collaborator

rustbot commented Mar 23, 2022

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.

cc @rust-lang/compiler @rust-lang/compiler-contributors

@joshtriplett
Copy link
Member

Tier 2 targets must not leave any significant portions of core or the standard library unimplemented or stubbed out, unless they cannot possibly be supported on the target. As an exception, a target identical to an existing tier 1 target except for lower baseline expectations for the OS, CPU, or similar, may propose to qualify as tier 2 (but not higher) without support for std if the target will primarily be used in no_std applications, to reduce the support burden for the standard library. In this case, evaluation of the proposed target's value will take this limitation into account.

This target qualifies for the listed exception. While libstd cannot be supported, there is no difficulty in supporting libcore.

Clarifying here: the exception you're referring to is "unless they cannot possibly be supported on the target"? (Not having an OS is not "lower baseline expectations for the OS". :) )

(I agree that you're meeting this requirement.)

@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Mar 24, 2022
@wesleywiser
Copy link
Member

@rustbot second

@rustbot rustbot added the final-comment-period The FCP has started, most (if not all) team members are in agreement label Mar 24, 2022
@bstrie
Copy link
Author

bstrie commented Apr 5, 2022

@apiraino Now that the FCP is over and there have been no objections, can this be merged?

@apiraino
Copy link
Contributor

apiraino commented Apr 5, 2022

@rustbot label -final-comment-period +major-change-accepted

@apiraino apiraino closed this as completed Apr 5, 2022
@rustbot rustbot added major-change-accepted A major change proposal that was accepted to-announce Announce this issue on triage meeting and removed final-comment-period The FCP has started, most (if not all) team members are in agreement labels Apr 5, 2022
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Apr 7, 2022
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Apr 8, 2022
Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts

This implements rust-lang/compiler-team#499 , in which the compiler team accepted the x86_64-unknown-none target for promotion to a Tier 2 platform.
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Apr 8, 2022
Promote x86_64-unknown-none target to Tier 2 and distribute build artifacts

This implements rust-lang/compiler-team#499 , in which the compiler team accepted the x86_64-unknown-none target for promotion to a Tier 2 platform.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
major-change A proposal to make a major change to rustc major-change-accepted A major change proposal that was accepted T-compiler Add this label so rfcbot knows to poll the compiler team
Projects
None yet
Development

No branches or pull requests

5 participants