Redox support in `liblibc` and `libstd`

[jackpot51]

Redox support in liblibc and libstd

I would like to draft two RFC's to propose the addition of Redox support to liblibc and libstd.

liblibc

Redox currently has issues building using cargo if there is a dependency on the libc crate. This is due to the required patches for adding Redox to liblibc not being available through cargo, and currently liblibc is built as a cargo override using this fork

libstd

Currently, Redox uses a custom libstd, which implements the majority of the public API, but only on Redox. A patch has been in development for the "standard" libstd on this fork

Help Needed

I have maintained these two forks and would like to know the steps required to clean them up and merge them into the Rust mainline, significantly improving ease of development on Redox and potentially allowing for rustc and cargo to be ported to Redox.

[mark-i-m]

As a side note, it would be nice to allow custom OS's to support themselves in this way through some attribute(s). I'm sure Redox is not the only custom OS with these problems. (I have also had a very small taste of this a while ago).

[Stebalien]

@mark-i-m That was the point of #1502 but it fell through.

[mark-i-m]

Hmm... interesting... I guess I was thinking more of something like heap_api, though I guess this may require some of the refactoring discussed in that thread.

[tari]

As I've been working on what amounts to another target that wants to support libstd, I agree that there's a need for better platform abstraction - I've avoided doing much work largely because maintaining a fork would be time-consuming. However, it is currently difficult to determine what a good approach to improving portability is.

It seems like a good short-term solution might be accepting more ports upstream (and deciding what kind of support the core team are willing to provide for these new targets), with a longer-term goal of improving libstd's abstractions. It's difficult to predict the needs of new ports right now, but that should become clearer as they are added.

[mark-i-m]

It seems like a good short-term solution might be accepting more ports upstream

I would argue that this might make it harder to refactor later. I read through #1502 and @brson lays out some of the difficulties pretty well here. One problem is that evaluating patches is difficult because of their excessive sizes. Adding more ports in the short-term would make this worse, I think.

Rather, I would like to see these sorts of ports maintained out-of-tree, as it distributes the load from the rust maintainers, keeps the standard library clean, and generally keeps code modular.

My notion of a good solution is similar but more extreme than that proposed in #1502: We break to libstd into two different libraries (not modules), libstd and libpal. libstd contains all platform independent code and relies on libpal, which contains only platform dependent code with a known interface to libstd. A distribution of Rust for a platform would consist of one copy of both libraries.

libpal would have multiple different versions for different platforms, as opposed to using cfg attributes. Different new platforms can then write and maintain their own libpal, without worrying about libstd, while the Rust developers don't have to approve patches that support a single platform. Only the Unix and Windows versions of libpal should be maintained by the Rust team. Overall, I think this is a much more scalable and maintainable system.

A nice stretch goal would be for libpal implementations to then allow replacing only portions of their functionality with some sort of attribute tag, sort of like language items.

The catch is

• At some point, there will need to be a concerted effort to move stuff out of the libstd and separate out libpal
• The exact boundaries and interfaces of these libraries will likely take a long conversation to finalize.

The result is that unless this suggestion gets really strong support, it is unlikely to happen.

Another recent development is rust-lang/rust#37133, though I haven't really had the chance to look into it.