rust-embedded
RFC: Arm team to maintain additional compiler targets
Per https://github.com/rust-lang/compiler-team/issues/896, currently the following targets will be demoted to Tier 3 without new maintainers:
aarch64-unknown-none
aarch64-unknown-none-softfloat
armv7a-none-eabi
armv7r-none-eabi
armv7r-none-eabihf
armebv7r-none-eabi
armebv7r-none-eabihf
And the following target is already tier 3 but is worth including in the discussion:
armv8r-none-eabihf
We (the WG Arm team) could volunteer to maintain these targets in addition to the targets we already maintain. Keeping them tier 2 means they are shipped in rustc, which makes them much more accessible to potential users.
For the big endian targets armebv7r-none-eabi and armebv7r-none-eabihf we don't currently have any way to test these targets and the only open source emulator I'm aware of (qemu) does not have working support, so it might be realistic to let those drop to tier 3 unless and until someone with interest and actual hardware wants to help out. For the other targets they are either quite commonly available or at least quite easily emulated, so it's practical for us to test Rust firmware on them. For armv8r-none-eabihf there's been interest in having this promoted to tier 2 as it's an interesting target with accelerating bare-metal usage that would be made a lot easier if it was included in rustc.
I'm opening this issue to discuss with other Arm team members - is there interest in supporting these targets alongside the ones we currently support? It's not much work, until something comes up with the target that needs fixing. We should have some regular tests run on these platforms via emulator in CI.
- [x] @adamgreig
- [x] @berkus
- [x] @jonathanpallant
- [ ] @nchong-at-aws
- [ ] @newAM
- [ ] @raw-bin
- [x] @robamu
- [ ] @thalesfragoso
- [x] @therealprof
- [ ] @ithinuel
- [x] @bartmassey
armv7a-none-eabi, armv7r-none-eabi, armv7r-none-eabihf and armv8r-none-eabihf are tested in the https://github.com/rust-embedded/cortex-ar repo.
aarch64-unknown-none-softfloat is tested in https://github.com/rust-embedded/aarch64-cpu/ (but not aarch64-unknown-none?).
Two alternatives:
- Ignore the issue, and if the targets get dropped to Tier 3, so be it
- Have individuals sign up to be maintainers, instead of wg-embedded/t-arm (which would be different to what we did with, e.g.
thumbv7m-none-eabi)
I'm definitely interested, but I'm both swamped and probably not expert enough.
Let's definitely try to get some names, or at least ideas of names we can ask, at the next WG meeting.
I've volunteered to be the point person for aarch64-unknown-none and aarch64-unknown-none-softfloat if the ARM team will take them on: the proposal seemed to be well-received? I think these are the most urgent, and I know enough to work on them and ask for help when appropriate. I put up an issue to try to find someone to write the target docs: otherwise I'll work on it when I get back from China.
Does this sound OK?
It sounds OK to me, but we didn't get enough votes in favour.
Ping @berkus @ithinuel @robamu @thalesfragoso @newAM @raw-bin @nchong-at-aws
The OP doesn't seem to reflect the current resolution. Do we need another comment detailing what exactly we're voting on?
I and one other could be added to the ballot, I think, as new members of the ARM team?
I have an armv9 board that is mostly idle, can probably have some ci bot on that.
## Majority
For the first week after an issue is opened, the current 50% threshold remains
in place. Votes which receive sufficient approvals can be accepted as usual.
After one week has passed, the threshold is reduced to 33%, and remains at 33%
for two weeks. There must still be zero unresolved concerns; but only 33% of
the members need to approve for a proposal to be accepted.
After those two weeks have passed (three weeks in total), two approvals from
members who are not the propser will permit a vote to be accepted, so long as
there are no unresolved concerns. A member is explicitly permitted to raise a
concern that there are not sufficient approvals or an issue has not received
sufficient attention and thereby block it from being accepted until that
concern is addressed.
Turns out this passed ages ago.
I can bet $100 there must be some sort of technology to convert this rules section into a voting bot...
I have some branches with some proposed updates: https://github.com/thejpster/rust/branches
Please send PRs to that branch with any changes you'd like before it goes upstream.