Moving Redox OS support to Tier 1

@jackpot51

For context, we recently made a policy on platform support. The gist of that is that a platform is Tier 1 if we have CI for it. I listed Redox there as a Tier 2 platform, because we don't have CI for it.

We want to support Redox OS, because it's an awesome project. uutils is also the default implementation of coreutils on Redox (at least it was when I last checked). However, we have probably accidentally broken support for Redox since #2550. For example in #5064, but there are probably many more failing tests to find. This is due to no fault of the authors of the PRs that broke the support, because it is simply impractical for us to keep compatibility without a Redox CI job. The longer we wait with setting this up, the harder it will be to fix.

I think the way to support this is as follows:

Investigate how bad the damage is, by building and testing the utils on Redox.
Fix some issues that break the entire build for all utils (e.g. the terminal_size issue mentioned below)

Figure out which subset of utils that already compiles and adapt this feature set accordingly:

coreutils/Cargo.toml

Lines 239 to 245 in 1f081f3

    
           # "feat_os_unix_redox" == set of utilities which can be built/run on "Redox OS" (refs: <https://www.redox-os.org>; <https://en.wikipedia.org/wiki/Redox_(operating_system)>) 
        
           feat_os_unix_redox = [ 
        
             "feat_common_core", 
        
             # 
        
             "chmod", 
        
             "uname", 
        
           ]

Create a CI job to build, test and lint on Redox
Update our platform support page to make the support "official" :)
Open an issue to keep track of all the utils that should work but don't.
Then we can start accepting fixes to enable more utils.

I'm not sure what the best way is to add a CI job for Redox. We probably need to to set up a VM (similar to how we do FreeBSD).

Some things to explore:

Are there examples of projects that already have Redox tests in their CI?
What subset of utils make sense to support on Redox?

@jackpot51, hope you don't mind me pinging you here. I've tried to follow up on the outstanding issues from #2550:

filetime seems to have made a release in the meantime here: Bump to 0.2.15 alexcrichton/filetime#72
termsize has been removed from our dependency tree and replaced with terminal_size (deps: change termsize dependency to terminal_size #3864). However, terminal_size makes no mention of Redox, so I suspect it won't work. We depend on this directly in ls and the coreutils multi-call binary, but also via clap (because we enabled wrap_help feature). So maybe we should first ask terminal_size to support redox. Otherwise we'll have to think about workarounds.
Do you have any advice for a CI setup that works well in your opinion? Or any opinions/ideas/advice about this effort in general?

cc @sylvestre @cakebaker any opinions on this? Anything I missed?

I can make a PR for CI support. That is the best place to start since it will show what other items are broken.

That would be great. Thanks!

Currently there are some issues with Redox's toolchain being based on 1.68. I'll need to update it again before trying this.

#5502 fixes the build on Redox. Not too many things needed to be changed.

A very easy way to do CI tests for different platforms is to just run a cargo check test, which for pure Rust code doesn't require a sysroot or linker and will catch most compile issues. Though for uutils this fails at the build script for onig_sys.

Another reason to get rid of onig 😄 Good to hear it's not too difficult!

cargo check --target x86_64-unknown-redox --features feat_os_unix_redox seems to work without a redox toolchain/sysroot if expr is commented out from feat_common_core, so onig seems to be the only issue with that currently.

In other areas of the codebase the default regex utility was implemented with the regex with a TODO to say that it does not have the full GNU regex syntax support. Was wondering if we could add a feature flag that would be able to support using the regex crate in expr without the full GNU compatibility as a backstop for now to enable Redox to use it since to remove onig with a fully compatible implementation does not seem to be possible for a while or until a new dependency that has those capabilities is built

What is the regex crate missing?

I believe it's just back-references and look-around that's missing. I think all of the other available crates currently that support those two features are all just wrappers for c libraries such as onig

Is there any "prebuilt" redoxer we can use at CI?

redox was removed from CI in #10950 due to a tooling issue (#10918)

We currently only have redoxer pre-built in the redoxos/redoxer docker image. Maybe cargo binstall could provide it?

cargo binstall uses binaries published to GitHub Releases or equivalent, these do not appear to exist: https://github.com/redox-os/redoxer/releases https://gitlab.redox-os.org/redox-os/redoxer/-/releases

(https://snoozeth.is/WRBfUbFXXYk) I will wait until https://github.com/rust-lang/libc has tag 0.2.190 and then add a comment.

Resolved.

the https://uutils.org/coreutils/book/platforms.html link in the issue of policy on platform support, is already returns 404, is a dead link

the https://uutils.org/coreutils/book/platforms.html link

Content was moved to https://uutils.org/coreutils/docs/platforms.html

Blocked by bytecodealliance/rustix#1643.

Navigation Menu

Repository navigation

Moving Redox OS support to Tier 1 #5210

28 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	# "feat_os_unix_redox" == set of utilities which can be built/run on "Redox OS" (refs: <https://www.redox-os.org>; <https://en.wikipedia.org/wiki/Redox_(operating_system)>)
	feat_os_unix_redox = [
	"feat_common_core",
	#
	"chmod",
	"uname",
	]

Moving Redox OS support to Tier 1 #5210

Description

Activity

jackpot51 commented on Aug 27, 2023

tertsdiepraam commented on Aug 27, 2023

jackpot51 commented on Sep 7, 2023

ids1024 commented on Nov 6, 2023

tertsdiepraam commented on Nov 7, 2023

ids1024 commented on Nov 7, 2023

oech3 commented on Nov 6, 2025

ChrisDryden commented on Jan 2, 2026

jackpot51 commented on Jan 3, 2026

ChrisDryden commented on Jan 3, 2026

oech3 commented on Feb 15, 2026

xtqqczze commented on Feb 18, 2026

jackpot51 commented on Feb 18, 2026

xtqqczze commented on Feb 18, 2026

28 remaining items

xtqqczze commented on Sep 26, 2026

SnoozeThis commented on Sep 26, 2026

SnoozeThis commented on Oct 2, 2026

HackingRepo commented on Oct 8, 2026

xtqqczze commented on Oct 8, 2026

xtqqczze commented on Oct 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions