The libs team agrees that we can support redox and other such platforms in-tree, as tier-3 platforms, with the following conditions:
- The port must support more-or-less the entire std API. This is sort of the minimum barrier to entry. Today we don’t have any platforms that conditionally-compile out parts of std. It looks like redox has problems with Path, which is very Unix/Windows-specific, and that’s a problem we need to solve. The emscripten port does really poorly here though - it does build the entire API surface, just most of the I/O is broken at runtime today.
- The platform-specific parts need to be limited to a few subsystems, namely std::sys, libc, the alloc and unwind crates. Today that is not quite true, with std containing a few platform-specific cfgs scattered around, but I started a patch to enforce this rule. This is to keep the maintenance burden down, enforce abstraction boundaries that might one day allow us to extract sys from std.
- We are not going to offer automated regression testing, nor binary builds, nor guarantee the build doesn’t break. Inclusion of tier-3 platforms is on a best-effort basis.
- We reserve the right to move teir-3 platforms back out of the tree if we ever reach a solution that allows ports to be maintained easily out of tree.
- This is still not a blanket policy that all such platforms can have in-tree support; they’ll be considered case-by-case.
So next steps are to submit a PR for further review.