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.
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 */ }
I wonder if:
relibc
or just implement a redox.rs in the sys/unix?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.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.
It already has to link libc
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.
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
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
Is redox a unix system? If it is I don't mind this change
It surely will bring more attention to the project, imo it would be a positive change
Ok, I think this is agreeable with everyone so far. I will get to work! Starting, probably, with the libc
crate
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
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.
Yes, you just have to do something like cfg(all(unix, not(target_os = "redox")))
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.
What? Schemes are not going away
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.
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.
It is done!
Most helpful comment
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