r? @wesleywiser

(rust-highfive has picked a reviewer for you, use r? to override)

⚠️ Warning ⚠️

• These commits modify compiler targets. (See the Target Tier Policy.)

Please copy the list of target requirements and verify all of the requirements are satisfied.

An example from one of the previous PRs: #88529 (comment)

• A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)

Yep, me and @jam1garner.

• Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
  • Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.

We spent a good amount of time bikeshedding this, but aarch64-nintendo-switch is consistent with armv6k-nintendo-3ds and mipsel-sony-psp. One consideration was targets built on top of C libraries, but there's some precedent here for alternate versions of targets in the form of aarch64-apple-ios and aarch64-apple-ios-sim.

• Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
  • The target must not introduce license incompatibilities.
  • Anything added to the Rust repository must be under the standard Rust license (MIT OR Apache-2.0).
  • The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the tidy tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.
  • If the target supports building host tools (such as rustc or cargo), those host tools must not depend on proprietary (non-FOSS) libraries, other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance, rustc built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.
  • Targets should not require proprietary (non-FOSS) components to link a functional binary or library.
  • "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are not limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.

The code in this PR definitely shouldn't pose any issue. Before making PRs for libstd, we plan to consult the core team and foundation (as discussed on Zulip), but none of the explicitly mentioned issues apply.

• Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.
  • This requirement does not prevent part or all of this policy from being cited in an explicit contract or work agreement (e.g. to implement or maintain support for a target). This requirement exists to ensure that a developer or team responsible for reviewing and approving a target does not face any legal threats or obligations that would prevent them from freely exercising their judgment in such approval, even if such judgment involves subjective matters or goes beyond the letter of these requirements.

👍

• Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.

See discussion on Zulip. We're planning on adding support incrementally to make review easier for both ourselves and reviewers.

• The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running tests (even if they do not pass), the documentation must explain how to run tests for the target, using emulation if possible or dedicated hardware if necessary.

Currently, there's not much specific to the target. https://github.com/aarch64-switch-rs/cargo-nx works with --triple=aarch64-nintendo-switch.

• Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain 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 a tier 3 target. Do not send automated messages or notifications (via any medium, including via @) to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.
  • Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.

👍

• Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
  • In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.

Assuming CI passes, I don't see any reason to think this would be an issue.

Also, for some relevant information that was posted on Zulip but wasn't copied here, this PR just adds a target definition. Future PRs for libstd will be pure Rust: we haven't signed any NDAs for the official SDK, and we don't plan to rely on unofficial C/C SDKs.

If this is an NDA compliant port, please drop me a line on the English language official forums under "Off-Topic/Target Triple for Rust std" or "Off-Topic/Rust". If this is a homebrew initiative, an indication as such would be appreciated.

Also, for some relevant information that was posted on Zulip but wasn't copied here, this PR just adds a target definition. Future PRs for libstd will be pure Rust: we haven't signed any NDAs for the official SDK, and we don't plan to rely on unofficial C/C SDKs.

@sgeos Does this answer your question? I agree that this probably should've been in the PR description, but I didn't think of that while we were writing it and I can't edit it.

Also, for some relevant information that was posted on Zulip but wasn't copied here, this PR just adds a target definition. Future PRs for libstd will be pure Rust: we haven't signed any NDAs for the official SDK, and we don't plan to rely on unofficial C/C SDKs.

@sgeos Does this answer your question? I agree that this probably should've been in the PR description, but I didn't think of that while we were writing it and I can't edit it.

The short answer is yes.

For what it's worth, as a note on the naming, the Switch's operating system is a microkernel called Horizon. Horizon was also used on the 3DS, but it evolved quite a bit between the two consoles. aarch64-nintendo-horizon and aarch64-unknown-horizon were also considered, but with the acceptance of a 3DS target under the name armv6k-nintendo-3ds we decided to go with aarch64-nintendo-switch just for consistency.
One possible wrinkle here is that there are three projects reimplementing the Horizon microkernel:

• mesosphere: complete C reimplementation targeting bug-for-bug compatibility, formally only supports the Switch but with a suitable bootloader could likely be ported to other Tegra X1 hardware with minimal changes to the kernel itself
• SunriseOS: Rust reimplementation targeting i386, no longer developed (IIRC the authors were making it as part of an operating systems course, which has concluded)
• Saturnus: early Rust reimplementation, I believe it currently targets the Switch but is planned to be a general-purpose RTOS

These projects might want to use the same target, in which case the aarch64-nintendo-switch name could be misleading. I'm not sure this is an actual issue, though, and I think consistency with the 3DS takes priority.

I think one relevant point about this being primarily designed for homebrew (I can't imagine an officially sanctioned game using this; if only because they need to dynamically link against the nnsdk), however we would like to keep the possibility for there to be another target designated for use when linking against the nnsdk. (an aarch64-nintendo-switch-nnsdk, if you will)

This is further complicated by the fact our plan for this target is to be a pure Rust toolchain (just interfacing with the syscall interface), which makes it a bit weird trying to specify a toolchain in the target. I think aarch64-nintendo-switch doesn't properly articulate it being for homebrew, but there isn't really a toolchain to append to it (like -musl on Linux targets). From a technical standpoint it makes sense as a 'default' as it's the least common denominator and would work in any context, but from a social standpoint much less so.

At risk of bikeshedding: If anyone has any thoughts on how this should be handled (even if just 'leave it alone'), I'd appreciate outside input

For what it's worth, as a note on the naming, the Switch's operating system is a microkernel called Horizon. Horizon was also used on the 3DS, but it evolved quite a bit between the two consoles. aarch64-nintendo-horizon and aarch64-unknown-horizon were also considered, but with the acceptance of a 3DS target under the name armv6k-nintendo-3ds we decided to go with aarch64-nintendo-switch just for consistency.
One possible wrinkle here is that there are three projects reimplementing the Horizon microkernel:

* [mesosphere](https://github.com/Atmosphere-NX/Atmosphere/tree/master/mesosphere): complete C   reimplementation targeting bug-for-bug compatibility, formally only supports the Switch but with a suitable bootloader could likely be ported to other Tegra X1 hardware with minimal changes to the kernel itself

* [SunriseOS](https://github.com/sunriseos/SunriseOS): Rust reimplementation targeting i386, no longer developed (IIRC the authors were making it as part of an operating systems course, which has concluded)

* [Saturnus](https://github.com/vbe0201/Saturnus): early Rust reimplementation, I believe it currently targets the Switch but is planned to be a general-purpose RTOS

These projects might want to use the same target, in which case the aarch64-nintendo-switch name could be misleading. I'm not sure this is an actual issue, though, and I think consistency with the 3DS takes priority.

I think it's also worth noting that mesosphere is the only one out of the three currently 'production ready' (so to speak) and can for all intents and purposes be considered only for use on the switch, so I think actual room for confusion from 'switch' in the name to be nonexistant.

I think one relevant point about this being primarily designed for homebrew (I can't imagine an officially sanctioned game using this; if only because they need to dynamically link against the nnsdk), however we would like to keep the possibility for there to be another target designated for use when linking against the nnsdk. (an aarch64-nintendo-switch-nnsdk, if you will)

This is further complicated by the fact our plan for this target is to be a pure Rust toolchain (just interfacing with the syscall interface), which makes it a bit weird trying to specify a toolchain in the target. I think aarch64-nintendo-switch doesn't properly articulate it being for homebrew, but there isn't really a toolchain to append to it (like -musl on Linux targets). From a technical standpoint it makes sense as a 'default' as it's the least common denominator and would work in any context, but from a social standpoint much less so.

At risk of bikeshedding: If anyone has any thoughts on how this should be handled (even if just 'leave it alone'), I'd appreciate outside input

aarch64-nintendo-switch does not conflict with any target triples that have been discussed behind the NDA wall, but it still might be confusing. aarch64-nintendo-switch-homebrew is entirely unambiguous. Personally, I would love to see a target that can be used for licensed commercial development. I am hoping this effort can be used as a basis for an official or semi-official target since you will probably move faster than me. Note that any such target, if created, will likely remain behind the NDA wall, probably forever.

Personally, I would love to see a target that can be used for licensed commercial development. I am hoping this effort can be used as a basis for an official or semi-official target since you will probably move faster than me. Note that any such target, if created, will likely remain behind the NDA wall, probably forever.

One thing I hope @sgeos (after further legal discussion, because I believe this will be an even more dicey endeavor than the currently proposed homebrew target) is that once further development is done on this target there could be a non-NDA'd target that would purely be based on the exposed symbols of the Nintendo SDK.

The reason I believe this could be possible is that (please note before I continue that I am not under a Nintendo NDA, have never looked upon or been given information covered by a Nintendo NDA, or otherwise interacted with NDA materials) the Nintendo SDK exports quite a large portion of libc required to produce a working Rust libstd.

I have experimented with this in the past for the purpose of modding games in the past (consider the fact that when modding games you are subject to a programming environment equivalent to that of the game, so a lot of this work could very well be helpful to a toolchain targetting 'official' game development).

I would believe that at minimum the subset of libc exported (sockets, pthreads, and a limited file API) would be enough to produce a semi-useful target without *any* copyrighted materials being involved (as, while I am not a lawyer and this is ofc not legal advice, I do not believe Nintendo has the rights to copyright a subset of libc :P )

As to whether or not such a target could dynamically link against other symbols in the nnsdk within libstd is less clear to me, however, but at minimum (a) skyline-rs/rust is a quite functional starting place for those under NDA making games if they would like a starting point and (b) I am willing to answer any questions about it people have (this is not the place to do so but it's not hard to find me elsewhere).

While working with the Rust Foundation and/or Rust core team when working on the homebrew libstd implementation I intend to also inquire about this. Hopefully there is a course of action I can take to enable development in the open but ultimately not putting the Rust project in legal jeopardy is my #1 priority for either of the proposed targets.

Also I should add that the current gameplan is that leo and I are currently assessing libstd implementation strategy and I plan on contacting both the foundation and the core team once both:

1. an implementation strategy is clear enough to present to legal and
2. this PR has merged

Personally, I would love to see a target that can be used for licensed commercial development. I am hoping this effort can be used as a basis for an official or semi-official target since you will probably move faster than me. Note that any such target, if created, will likely remain behind the NDA wall, probably forever.

One thing I hope @sgeos (after further legal discussion, because I believe this will be an even more dicey endeavor than the currently proposed homebrew target) is that once further development is done on this target there could be a non-NDA'd target that would purely be based on the exposed symbols of the Nintendo SDK.

The reason I believe this could be possible is that (please note before I continue that I am not under a Nintendo NDA, have never looked upon or been given information covered by a Nintendo NDA, or otherwise interacted with NDA materials) the Nintendo SDK exports quite a large portion of libc required to produce a working Rust libstd.

I have experimented with this in the past for the purpose of modding games in the past (consider the fact that when modding games you are subject to a programming environment equivalent to that of the game, so a lot of this work could very well be helpful to a toolchain targetting 'official' game development).

I would believe that at minimum the subset of libc exported (sockets, pthreads, and a limited file API) would be enough to produce a semi-useful target without any copyrighted materials being involved (as, while I am not a lawyer and this is ofc not legal advice, I do not believe Nintendo has the rights to copyright a subset of libc :P )

As to whether or not such a target could dynamically link against other symbols in the nnsdk within libstd is less clear to me, however, but at minimum (a) skyline-rs/rust is a quite functional starting place for those under NDA making games if they would like a starting point and (b) I am willing to answer any questions about it people have (this is not the place to do so but it's not hard to find me elsewhere).

While working with the Rust Foundation and/or Rust core team when working on the homebrew libstd implementation I intend to also inquire about this. Hopefully there is a course of action I can take to enable development in the open but ultimately not putting the Rust project in legal jeopardy is my #1 priority for either of the proposed targets.

First of all, I am not an attorney. If you have legal concerns, it is a good idea to consult an attorney. Having said that, my understanding is that reverse engineering trade secrets is legal. Reverse engineering cannot be used as a defense for patent infringement, but there is precedent in the USA for interoperability and overturning silly patents.

The upshot is that reverse engineering whatever Nintendo is doing and implementing a target based on that knowledge is almost certainly legal, but there are a few things to be aware of. First of all, after signing an NDA and being approved as a developer, access to a lot of trade secret secrets is granted, technical and nontechnical. People who have signed such an NDA are obligated not to share these trade secrets even if they stop developing for the system. Anyone behind the NDA wall is legally unable to share trade secrets with you, but you are free to use publicly available information. I am pretty sure that leaks are public information that can be used, but I would double check this if it is important.

If someone who has signed an NDA feeds you information, that puts both you and that person at risk legally. I have seen projects roll back functionality that is based on propriety information. I think that this is a good idea if you get information that cannot be used legally. To the extent you have not signed an NDA, you are free to work and share information openly, but you may not make use of trade secrets provided by someone who has signed an NDA. Once you have signed an NDA, there is no going back, but people behind the NDA wall are free to use reverse engineered work, license permitting.

As far as concrete detail go, I do not see any problem building a target that relies on reverse engineered symbols that are present on the device. If you write a target that uses whatever subset of libc is exported, your aarch64 implementation may actually work on other aarch64 targets that export all of libc. Furthermore, it sounds like it might also work on the 3DS for the people who are still interested in developing homebrew for it. I think that working with the available reverse engineered libc symbols is the ideal strategy to use.

@sgeos Thanks for the writeup and your view on this. I want to add another perspective though: whether something is legal or not is not the only concern. The problem is an intersection of the structure of the libc crate and legal interpretations. Because libc is one library spelling out all the targets, any action taken against one target - independent of the outcome - will impact all the others. That's the reason why we need to be careful and very solid in footing there. Every target needs to rely on our reading to be correct and when the reading includes external documents and agreements, it gets problematic.

That would be very different if a libc-switch crate existed and could be linked instead of the libc crate.

@skade Thank you for the reply.

As far as external agreements go, my recommendation is to only allow people to contribute if A) they have no external agreements (NDA not signed, NDA trade secrets never seen, etc.), or B) they have explicit permission to contribute despite having signed an NDA. My understanding is that external documentation based on reverse engineering should be OK, but I honestly have no idea what the Switch homebrew community is using. Some of the other homebrew communities use extensive data sheets of technical information.

Does it make sense to create a libc-switch crate and conditionally link to it instead of the standard libc crate? If so, then the crate not existing is a solvable problem. Furthermore, implementing it may be an excellent strategy for approaching this kind of target. Worst case scenario, this libc-switch crate can simply be removed if unforeseeable problems emerge.

I'm not sure we are in a position to verify that the contributors haven't signed some sort of an NDA, and drawing a line in the code for where such a verification should be made and where its not necessary seems infeasible at best.

Then again, adding a plain target dues not raise huge concerns here. Adding supporting code to libc/libstd seems like it would.

@sgeos I'll write a full reply later, but just to make clear: the libc-switch crate was just a strawman, not a real idea and proposal. I just wanted to use it to illustrate how a separate scope may ease things.

My understanding is that external documentation based on reverse engineering should be OK, but I honestly have no idea what the Switch homebrew community is using. Some of the other homebrew communities use extensive data sheets of technical information.

Leaked materials definitely aren't used, though the public Tegra X1 TRM is frequently referenced for low-level details.

There's likely enough documentation for clean-room implementations, but if you consider having looked at any disassembly/decompilation to taint someone, you'll have a hard time finding developers. It's definitely a far better situation than the GameCube, where I've heard that chunks of the toolchain were directly taken from decompiler output...

For what it's worth, I think the fact that Nintendo hasn't taken action against Atmosphere (which has bug-compatible reimplementations of many system components) is good evidence that they wouldn't take action against a Rust port.

@wesleywiser I was actually planning on doing that but I mistakenly thought those were in a separate repo, I'll write some.

For what it's worth, I'm open to a target name like aarch64-nintendo-switch-homebrew, but that feels way too long and I don't have any better ideas... It's also not especially descriptive: it could also be ambiguous with a theoretical libnx target.

Also I should add that the current gameplan is that leo and I are currently assessing libstd implementation strategy and I plan on contacting both the foundation and the core team once both:

1. an implementation strategy is clear enough to present to legal and
2. this PR has merged

I think it would be helpful to go ahead and start this conversation now. From a technical perspective, the code here is fine and could be signed off on as it is. However, while it seems ok to me to merge this, I recognize that I am not a lawyer and don't really know what I'm talking about. 🙂

I would prefer if we had some kind of agreed upon strategy here for the target with those folks. If, for example, we could not find an implementation path that allows for in-tree libcore/libstd support for this target, that would place this target below Tier 3 support with no way to reach that level which seems undesirable long-term. In such a case, is having the target definition in-tree even useful? Hopefully, that is not the conclusion and we can provide robust support for the target but it would be good to clarify the situation at this time.

Edit: Upon a closer reading of the target tier RFC, it appears that Tier 3 support does not require libcore implemented so only having the target definition in-tree would technically qualify as Tier 3 support but that still doesn't seem like a desirable outcome.

Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (core for most targets, alloc for targets that can support dynamic memory allocation, std for targets with an operating system or equivalent layer of system-provided functionality)

Additionally, the 3ds is EoL, the Switch is still actively sold. And another factor (echoing leo's sentiment but from a different angle) I think linking against a homebrew focused toolchain is likely a net negative for any use in published games (more applicable to a hypothetical nnsdk target, but also potentially applicable to a freestanding target).

I don't think there's actually any concern regarding the switch targets, just more things for project members and foundation legal to consider.

And @wesleywiser @nellshamrell any changes? I know @skade left the core team, is there anyone who was involved with the policy decision here that is still involved, or has this stalled and we need to find new project members to work with on this? Want to understand whether or not this is needing patience or finding new people within the rust project to discuss this with

I will bring the legal question back to the Foundation. @wesleywiser do you know of any project specific concerns around this?

@jam1garner thanks so much for your patience! I'm sorry it's taken this long to get an answer back to you.

Per our discussions with the Foundation's legal staff, we don't see an issue with merging this PR therefore:

@bors r rollup

📌 Commit 29611d2ee50418a7f7149e33bd2e5445d29dbcd1 has been approved by wesleywiser

It is now in the queue for this repository.

Re-approving

@bors r rollup

📌 Commit 62aafb0 has been approved by wesleywiser

It is now in the queue for this repository.