I haven’t forgotten about this thread, I’m just pretty torn about how to proceed. My conflicting thoughts on this:
- I want to support Redox to the extent that we can, while also balancing what’s appropriate for upstream Rust
- I want it to be easy for experimental projects, OS and otherwise, to reuse the standard library and other parts of the main Rust codebase
- I realize that maintaining patches out of tree sucks
- I don’t want mainline Rust to undertake maintenance of code to support every Rust OS project because of increased maintenance burden. Having such a blanket policy seems likely to cause sadness for the Rust maintainers.
- I think there is a very plausible story for using crate replacement to abstract the relatively small platform-specific components of std, and we’re pretty close to making that possible now. This is how I want out-of-tree std porting to work.
- In lieu of having that story in place I think there is a reasonable argument that mainline Rust should be willing to have support in-tree for projects actively maintaining ports of std, so that they don’t have to keep forward porting their patches, assuming those platform-specific parts are cleanly factored out of the primary code paths. I see this as somewhat similar to the Linux kernel begging vendors to put their niche drivers in tree.
I’ve put this on the libs team’s agenda for some high bandwidth feedback but it hasn’t happened yet. Maybe some could give an opinion. cc @library_subteam.