std: Add Motor OS std library port #147000

lasiotus · 2025-09-24T19:36:16Z

Motor OS was added as a no-std Tier-3 target in
PR 146848 as x86_64-unknown-motor.

This PR adds the std library for Motor OS.

While the PR may seem large, all it does is proxy
std pal calls to moto-rt. Where there is some non-trivial
code (e.g. thread::spawn), it is quite similar, often
identical, to what other platforms do.

rustbot · 2025-09-24T19:36:20Z

These commits modify the library/Cargo.lock file. Unintentional changes to library/Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

The list of allowed third-party dependencies may have been modified! You must ensure that any new dependencies have compatible licenses before merging.

cc @davidtwco, @wesleywiser

rustbot · 2025-09-24T19:36:22Z

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

tgross35 · 2025-09-24T20:55:55Z

Is there any notable std functionality that isn't supported on this platform? Just skimming it, it seems like things are pretty complete (threads, systemtime, process, etc)

Nominating for libs as this adds a new std target.

@rustbot label +I-libs-nominated

lasiotus · 2025-09-24T21:15:22Z

Is there any notable std functionality that isn't supported on this platform? Just skimming it, it seems like things are pretty complete (threads, systemtime, process, etc)

I believe all major pieces are supported/implemented, including networking. Some specific things are not (yet) fully implemented, like FS links, or DNS lookup (at the moment, only "localhost" resolves to an IP address). On the other hand, tokio is ported via a mio port, which was not completely trivial...

library/panic_abort/Cargo.toml

library/std/src/os/fd/raw.rs

library/std/Cargo.toml

tgross35 · 2025-09-24T23:50:43Z

library/std/src/os/motor/mod.rs

+#[unstable(feature = "motor_ext", issue = "none")]
+pub fn map_motor_error(err: moto_rt::ErrorCode) -> crate::io::Error {


Probably doesn't need to be crate public?

If a Rust program calls into moto-sys (the Motor OS kernel API) or moto-rt (the Motor OS runtime API), they get moto_rt::ErrorCode. To convert it into io::Error (e.g. for Tokio) they need access to a similar function. So either the function should be exported here as pub, or duplicated elsewhere, from where std can't import (due to io::Error being in std). If io::Error is moved to core (which I've seen being discussed), I'll move this function to moto-rt.

I prefer to avoid code duplication and just export it here. If it is better to duplicate it elsewhere, I can do that also, let me know.

library/std/src/sys/pal/motor/common.rs

tgross35 · 2025-09-25T00:21:34Z

library/std/src/sys/pal/motor/mod.rs

+#[cfg(not(test))]
+#[unsafe(no_mangle)]
+pub extern "C" fn motor_start() -> ! {


vroom vroom 🙂

library/std/src/sys/pal/motor/mod.rs

tgross35 · 2025-09-25T00:25:38Z

library/std/src/sys/pal/motor/mod.rs

+    moto_rt::process::exit(-1)
+}
+
+pub(crate) use crate::os::motor::map_motor_error;


Why not just define the function here? This is the module for cvt on others

I replied to the previous comment on this function. I can move it here and re-export in os::motor; or just move it here if you don't buy my argument re: why it is nice to have it exported. Please let me know.

library/std/src/sys/fs/mod.rs

library/std/src/sys/pal/motor/os.rs

bjorn3 · 2025-09-25T09:50:58Z

library/std/src/sys/pal/motor/os.rs

+}
+
+pub fn current_exe() -> io::Result<PathBuf> {
+    Ok(crate::sys::args::args().next().unwrap().into())


If you run say ls foo on Motor OS, is the first argument ls (like on Unix and Windows) or /path/to/ls? If the former, this is not a correct implementation. std::env::current_exe() is supposed to return an absolute path to the executable file.

In many modern systems, even unices, there is often no global "absolute path", as programs run in their own jails/containers/whatever. Also just by looking at how other platforms deal with it, it is all over the place:

aix just "infers" the location if args[0] is not an absolute path (which is buggy and thus worse, I'd say);

openbsd does the same thing as Motor OS, only additionally calls canonicalize() if args[0] starts with a dot or contains a slash; if not, args[0] is returned unmodified;

same for vxworks.

So I'd say Motor OS is not unique here. I can add a call to canonicalize(), if you insist, but I don't think it will make things better: I'd rather have an unmodified args[0] rather than have it massaged in some cases and not in others.

bors · 2025-09-25T18:48:13Z

☔ The latest upstream changes (presumably #147019) made this pull request unmergeable. Please resolve the merge conflicts.

As part of work to add stdlib support for Motor OS.

rustbot · 2025-09-26T19:59:21Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Motor OS was added as a no-std Tier-3 target in rust-lang#146848 as x86_64-unknown-motor. This patch/PR adds the std library for Motor OS. While the patch may seem large, all it does is proxy std pal calls to moto-rt. When there is some non-trivial code (e.g. thread::spawn), it is quite similar, often identical, to what other platforms do.

rustbot assigned tgross35 Sep 24, 2025

rustbot added the I-libs-nominated Nominated for discussion during a libs team meeting. label Sep 24, 2025

tgross35 requested changes Sep 25, 2025

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 25, 2025

bjorn3 reviewed Sep 25, 2025

View reviewed changes

library/std/src/sys/pal/motor/os.rs Show resolved Hide resolved

bjorn3 reviewed Sep 25, 2025

View reviewed changes

tidy: allow stdlib to depend on moto-rt

091d639

As part of work to add stdlib support for Motor OS.

lasiotus force-pushed the motor-os_stdlib_pr branch from e2e23a1 to f3884e2 Compare September 26, 2025 19:59

lasiotus force-pushed the motor-os_stdlib_pr branch from f3884e2 to d8da6c0 Compare September 26, 2025 20:41

lasiotus requested a review from tgross35 September 26, 2025 21:38

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 26, 2025

lasiotus requested a review from bjorn3 September 26, 2025 21:38

		#[unstable(feature = "motor_ext", issue = "none")]
		pub fn map_motor_error(err: moto_rt::ErrorCode) -> crate::io::Error {

std: Add Motor OS std library port #147000

Are you sure you want to change the base?

std: Add Motor OS std library port #147000

Uh oh!

Conversation

lasiotus commented Sep 24, 2025

Uh oh!

rustbot commented Sep 24, 2025

Uh oh!

rustbot commented Sep 24, 2025

Uh oh!

tgross35 commented Sep 24, 2025

Uh oh!

lasiotus commented Sep 24, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tgross35 Sep 24, 2025

Choose a reason for hiding this comment

Uh oh!

lasiotus Sep 26, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tgross35 Sep 25, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tgross35 Sep 25, 2025

Choose a reason for hiding this comment

Uh oh!

lasiotus Sep 26, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

bjorn3 Sep 25, 2025

Choose a reason for hiding this comment

Uh oh!

lasiotus Sep 26, 2025

Choose a reason for hiding this comment

Uh oh!

bors commented Sep 25, 2025

Uh oh!

rustbot commented Sep 26, 2025

Uh oh!

Uh oh!