redox: convert to target_family unix

[jackpot51]

Major changes have been happening in Redox since the design of the libstd/sys/redox module. The creation of relibc has led to the development of a POSIX, C API for Redox that supports the vast majority of required functions in the libstd/sys/unix module. This has allowed the use of a separate target family for Redox to be reconsidered, perhaps allowing it to fall under the unix target family and gain support from a large number of crates without requiring any explicit changes.

After such a unification, the one remaining issue is #52331. Solving this requires the potentially breaking change indicated in these four lines. This change adds a path::Prefix::Scheme variant, but only on Redox. Although this would be a breaking change for Redox, all of the supported packages on Redox have already been compiled successfully with this new variant.

I believe that this change will significantly reduce the work required to move Redox OS to Tier 3, with full support for cargo, rustc, and the other rust tools.

The downside is that crates that have both cfg(unix) and cfg(target_os = "redox") defined will not compile correctly on Redox. This would likely break Redox support for some of the crates that have already added specific support for Redox, while enabling Redox support for many crates that only have support for the unix target family.

I would appreciate any feedback on this potential change.

[jackpot51]

Here is a simple example of the kind of support that would be broken:

#[cfg(target_os = "redox")]
fn do_stuff() { /* Redox stuff */ }

#[cfg(unix)]
fn do_stuff() { /* Unix stuff */ }

[lu-zero]

I wonder if:

• would that change in libstd require to use relibc or just implement a redox.rs in the sys/unix?
• the brokenness in crates supporting both would be silent or evident?

[jackpot51]

• The change would be to use the libc crate as is used in sys/unix already, and add Redox specific support where required. Most of the time, it would use libc, which links to relibc already.
• It would be evident on Redox, but silent on all other platforms. The Redox team would take responsibility for cleaning up our own mess.

[lu-zero]

Would that change anything on the link line for the binaries?

I'm trying to figure out if the shortcomings in this approach are negligible compared the compatibility boost.

Recently I did some cross-compilation experiment and not having to deal with libc and friends (as packaged or not by distributions) would be a boon.

[jackpot51]

It already has to link libc

[lu-zero]

So there isn't really a shortcoming beside cleaning up some crates and the problems there will be evident once you try to build.

And and the solution is to just drop the specific code more often than not.

[jackpot51]

Yep, most of the time it will reduce maintenance burden. There are a few special cases where there are things like target_os = "linux", target_os = "redox" and those will have to be kept. winit, for example

[charleschege]

The way I see it is that this is not much of problem if things break to improve Redox since Redox is not yet at a place we can call stable for general use

[lucbf]

Is redox a unix system? If it is I don't mind this change

[BananaLoaf]

It surely will bring more attention to the project, imo it would be a positive change

[jackpot51]

Ok, I think this is agreeable with everyone so far. I will get to work! Starting, probably, with the libc crate

[matiu2]

https://giphy.com/gifs/yosub-girl-taco-why-not-both-3o85xIO33l7RlmLR4I

Why not both?

[jackpot51]

Proposed changes for rust: https://gitlab.redox-os.org/redox-os/rust/compare/redox-2019-04-06...redox-unix-2019-04-06

Proprosed changes for liblibc: https://gitlab.redox-os.org/redox-os/liblibc/compare/redox...redox-unix

Will PR both once I move forward

[SiebrenW]

Can the Rust compiler be set to ignore cfg(unix) if cfg(target_os = "redox") is present and otherwise use unix? That way an application can still use native and optimised Redox code if desired.

[jackpot51]

Yes, you just have to do something like cfg(all(unix, not(target_os = "redox")))

[SiebrenW]

Then can't you still keep the Scheme in place and if it's not specified it may use files by default and emulate the /dev/ files which link to the appropriate scheme? At one point this might even be deprecated and removed once Redox is in a more mature state.
I fail to see why the removal of schemes is necessary.

[jackpot51]

What? Schemes are not going away

[SiebrenW]

Ah, I was getting the idea this was what it might get down to in my then sleep deprived mind. As long as it doesn't divert too much from the original design. This might get a bit over my head and I shouldn't jump in that early in the morning. Now that I reread it, I see what's up more clearly.
So then, I think it's relatively trivial for the crates to patch for the new change, and it's so early on crates shouldn't expect everything'll work forever.
As long as these kinds of changes aren't as frequent as GTK's. You can focus on backwards compatibility from version 1.0 onwards.

[MggMuggins]

I think you've got it, but just to reiterate, this change has really nothing to do with the design of Redox, just how rust and std deal with Redox.

I also want to quick point out a (hopefully) relevant misconception that I was prey to, and I see a lot (feel free to delete this message if it isn't relevant). On redox, when file is opened relative to the root (like this: /some/file/someplace), the default scheme is the scheme of the current working directory, not file:. file: is almost always the location of the cwd, hence the misconception. This is just something to keep in mind when merging code that deals with hardcoded paths.

[jackpot51]

It is done!