How to promote a specific target from "Tier 2" to "Tier1"

[prozanne]

Hi,
Even though I've carefully read target tier policy and platform support docs, I still have something to ask.
https://doc.rust-lang.org/nightly/rustc/platform-support.html
https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html

We are currently considering to adopt rust to our platform. (commercial use not only for developing test)
But, our target is mainly based on "armv7-unknown-linux-gnueabihf" which is placed to "Tier2".
According to the docs, I read that "Tier1 is guaranteed to work" and "Tier2 is guaranteed to build".

If we have a plan to release the target as a product,
It means "armv7-unknown-linux-gnueabihf" is NOT GUARANTEED TO WORK at all (including a sub-compatibility)?
That makes us to hesitate to adopt rust to our product....

If Tier2 CANNOT be guaranteed to work or sub-compatibility, we'd love to the target is being promoted to Tier1. Is it possible?
Although I read the doc about "Target Tier Policy", the process of promoting to "Tier1" is a bit ambiguous to me.
What kind of things are required for that?
And where can I start suggesting or raising issue "armv7-unknown-linux-gnueabihf" to promote to Tier1?

Thanks in advance.

[the8472]

Tier1 means it's tested in CI (since that's what checks that it works) which requires CI runners with that hardware. Github does not have armv7 runners.
Tier2 means that it builds without error on CI (without running the tests on the target) via cross-compilation.

If we have a plan to release the target as a product,
It means "armv7-unknown-linux-gnueabihf" is NOT GUARANTEED TO WORK at all (including a sub-compatibility)?
That makes us to hesitate to adopt rust to our product....

This is about what the rust project itself guarantees. Third parties (e.g. some linux distros) may provide additional checks.

You can also run tests yourself, either by running the full rust testsuite or by pinning a specific compiler version and checking that it works for your product. You can then stay on that version if it turns out that updating to a new rust release doesn't work anymore and file an issue. If a Tier2 platform breaks for a user and they report it it will generally be fixed (that's why target maintainers are a requirement).

[the8472]

Do aarch64 CPUs support mode-switching to 32bit similar to what x86-64 CPUs generally support? I.e. could a 32bit platform be tested on a 64bit host system without much overhead (and without requiring hardware virtualization, since CI machines don't support that)? But even then there would still be the question whether it's worth it. There are a lot of ARM flavors.

[est31]

@the8472

Do aarch64 CPUs support mode-switching to 32bit similar to what x86-64 CPUs generally support?

It is specified but optional, i.e. whether Aarch32 execution state is supported or not depends on the CPU at hand. M1 can't do it for example. See this stack overflow on how to detect support.

@prozanne

How to promote a specific target from "Tier 2" to "Tier1"

TLDR: It's a big commitment to move something from Tier 2 to Tier 1.

Relevant content on how Aarch64 became tier 1:

• https://www.youtube.com/watch?v=9l4SBee2X34
• https://github.com/rust-lang/rfcs/blob/master/text/2959-promote-aarch64-unknown-linux-gnu-to-tier1.md

They've made a dedicated RFC for it, and as per policy, an RFC is required.

A proposed new tier 1 target must be reviewed and approved by the compiler team based on these requirements. In addition, the release team must approve the viability and value of supporting the target. For a tier 1 target, this will typically take place via a full RFC proposing the target, to be jointly reviewed and approved by the compiler team and release team.

In addition, the infrastructure team must approve the integration of the target into Continuous Integration (CI), and the tier 1 CI-related requirements. This review and approval may take place in a PR adding the target to CI, by an infrastructure team member reporting the outcome of a team discussion, or by including the infrastructure team in the RFC proposing the target.

The RFC to elevate Aarch64 was written by an ARM employee, and ARM has donated the hardware to run the CI on. I don't know whether the donated hardware is still being used, or whether the CPUs used by rust support Aarch32 execution or not. If they do that would make things easier of course.

If you want to make tier 1 armv7 a thing, I suggest you talk to the people who were involved in the original RFC 2959, especially people from the infra and compiler teams, as well as the current armv7 maintainers. The former two can be contacted on zulip (infra, compiler), for latter I don't know but maybe the arm team is the group of people (those names correspond to github handles). They can give you a better overview over the requirements of such a change, and whether they want to add more targets to tier 1 at all.

There is also an earlier thread at the rfcs repo but it doesn't contain that much info.

All this being said, note that tier 2 targets are generally working really well, and large companies do deploy products on those targets.

[prozanne]

Thanks for all your kind replies. @the8472 @est31

Thanks to your reply, We could understand well about the policy of promoting Tier.
Now I need to talk and review with our internal team, and find a next step.
Thanks a lot again :)
Now this issue can be closed I think.

[jyn514]

Glad to hear you understand the target policy better :)