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.

I think what you could do here is define the RawOsError type as moto_rt::ErrorCode (copy how we do this for UEFI) and override fn decode_error_kind. That way io::Error is actually just a a moto_rt::ErrorCode, and io::Error::from_raw_os_error can be used rather than needing this function.

I think what you could do here is define the RawOsError type as moto_rt::ErrorCode (copy how we do this for UEFI) and override fn decode_error_kind. That way io::Error is actually just a a moto_rt::ErrorCode, and io::Error::from_raw_os_error can be used rather than needing this function.

Oh, that's a nice trick! I've had a vague desire to use a proper Error enum in public Motor OS API (which is in Rust), and to use a plain ErrorCode/u16 only in internal ABI (which uses C/Linux calling conventions, as Rust doesn't define an ABI).

So I'm going to spend the next several days refactoring the whole Motor OS codebase around a new enum Error (repr u16, most likely).

I think what you could do here is define the RawOsError type as moto_rt::ErrorCode (copy how we do this for UEFI) and override fn decode_error_kind. That way io::Error is actually just a a moto_rt::ErrorCode, and io::Error::from_raw_os_error can be used rather than needing this function.

Oh, that's a nice trick! I've had a vague desire to use a proper Error enum in public Motor OS API (which is in Rust), and to use a plain ErrorCode/u16 only in internal ABI (which uses C/Linux calling conventions, as Rust doesn't define an ABI).

So I'm going to spend the next several days refactoring the whole Motor OS codebase around a new enum Error (repr u16, most likely).

Bummer... Spent the weekend to make Motor OS API (moto-rt, moto-sys) return an enum Error instead of a u16, only to find out that Rust library assumes it is an integer of no more than 32 bits. Will just use u16 then - this is a fight for another day...

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

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

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.

I believe the loose expectation here is that you could pass the result of std::env::current_exe() to another process, which may possibly be launched in another directory, and launch the same binary. If there is a best effort change to make this work then I think it's worthwhile (unless I'm misunderstanding things here)

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.

Amanieu · 2025-10-01T16:12:58Z

We discussed this in the @rust-lang/libs meeting and are happy to add std support for this target because it supports all major functionality of std.

lasiotus · 2025-10-02T15:58:56Z

We discussed this in the @rust-lang/libs meeting and are happy to add std support for this target because it supports all major functionality of std.

Thanks, Amanieu!

@tgross35 Trevor, how can I improve this PR to make it mergeable?

tgross35 · 2025-10-02T18:59:00Z

It's on my list, I just haven't had a chance to do a thorough review yet (probably later this week)

tgross35 · 2025-10-03T22:30:05Z

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 {


I think what you could do here is define the RawOsError type as moto_rt::ErrorCode (copy how we do this for UEFI) and override fn decode_error_kind. That way io::Error is actually just a a moto_rt::ErrorCode, and io::Error::from_raw_os_error can be used rather than needing this function.

tgross35 · 2025-10-03T22:38:28Z

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

+#[unstable(feature = "motor_ext", issue = "none")]
+pub trait ChildExt: Sealed {
+    /// Extracts the main thread raw handle, without taking ownership
+    #[unstable(feature = "motor_ext", issue = "none")]
+    fn sys_handle(&self) -> u64;
+}
+
+#[unstable(feature = "motor_ext", issue = "none")]
+impl ChildExt for crate::process::Child {


Following up from #147000 (comment): just make a library tracking issue (there's a library tracking template) and paste these API in them. We can then go through the stabilization process to make them usable on MotorOS with stable rustc, once we eventually have build-std usable on stable.

It's an imperfect system for the tier 3 targets currently given the build-std situation, but at least this will point interested parties somewhere.

tgross35 · 2025-10-03T22:39:27Z

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

The stable attributes here should technically be unstable(feature = "motor_ext") like the others. Doesn't matter too much for T3 targets though so maybe this is fine (asked on Zulip)

tgross35 · 2025-10-03T22:58:31Z

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

+        target_os = "motor" => {
+            mod motor;
+            pub use motor::*;
+        }
        target_os = "wasi" => {
            mod wasi;
            pub use wasi::*;
        }
        target_os = "uefi" => {
            mod uefi;
            pub use uefi::*;
        }
        _ => {
            mod unsupported;
            pub use unsupported::*;
        }


Can Motor just use the mod unsupported; fallback here? io_slice/motor.rs looks the same.

tgross35 · 2025-10-03T23:07:32Z

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

+pub fn error_string(errno: i32) -> String {
+    format!("errno: {errno}")
+}


If you do the RawOsError bit I mentioned, then s/i32/RawOsError.

Is there a way to go from moto_rt::ErrorCode to a name like E_ALREADY_IN_USE or a descriptive string? If so, that could be returned here.

tgross35 · 2025-10-03T23:32:56Z

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

+    }
+
+    pub fn read_to_end(&self, buf: &mut Vec<u8>) -> io::Result<usize> {
+        let mut temp_vec = alloc::vec::Vec::new();


Already in scope

Suggested change

let mut temp_vec = alloc::vec::Vec::new();

let mut temp_vec = Vec::new();

tgross35 · 2025-10-03T23:37:31Z

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

+pub fn read2(_p1: AnonPipe, _v1: &mut Vec<u8>, _p2: AnonPipe, _v2: &mut Vec<u8>) -> io::Result<()> {
+    todo!()
+}


Probably either unsupported() or a panic!() rather than an empty todo!()

tgross35 · 2025-10-03T23:43:44Z

library/std/src/sys/process/motor.rs

+        for (k, v) in env.capture() {
+            if k.clone().into_string().unwrap() != moto_rt::process::STDIO_IS_TERMINAL_ENV_KEY {
+                vars.push((k, v));
+            }
+        }
+
+        for (k, v) in vars {
+            env.set(&k, &v);
+        }


Save a clone & collect

Suggested change

for (k, v) in env.capture() {

if k.clone().into_string().unwrap() != moto_rt::process::STDIO_IS_TERMINAL_ENV_KEY {

vars.push((k, v));

}

}

for (k, v) in vars {

env.set(&k, &v);

}

for (k, v) in env.capture() {

if k == moto_rt::process::STDIO_IS_TERMINAL_ENV_KEY {

continue;

}

env.set(k, v);

}

tgross35 · 2025-10-03T23:44:42Z

library/std/src/sys/process/motor.rs

+impl From<File> for Stdio {
+    fn from(_file: File) -> Stdio {
+        todo!()
+    }
+}
+
+impl From<io::Stdout> for Stdio {
+    fn from(_: io::Stdout) -> Stdio {
+        todo!()
+    }
+}
+
+impl From<io::Stderr> for Stdio {
+    fn from(_: io::Stderr) -> Stdio {
+        todo!()
+    }
+}


Use panic!(...) or unsupported!(...) rather than todo!(...) (TODO is usually for things to do before merge by tidy's convention)

tgross35 · 2025-10-03T23:46:23Z

library/std/src/sys/process/motor.rs

+            let val = if let Some(v) = v { v.to_str().unwrap() } else { "" };
+            env.push((k.to_str().unwrap().to_owned(), val.to_owned()));


I think this can use as_str() rather than to_str().unwrap()

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

Amanieu removed the I-libs-nominated Nominated for discussion during a libs team meeting. label Oct 1, 2025

tgross35 requested changes Oct 3, 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 Oct 3, 2025

lasiotus mentioned this pull request Oct 6, 2025

Tracking Issue for RawOsError #107792

Open

4 tasks

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

	let mut temp_vec = alloc::vec::Vec::new();
	let mut temp_vec = Vec::new();

		let val = if let Some(v) = v { v.to_str().unwrap() } else { "" };
		env.push((k.to_str().unwrap().to_owned(), val.to_owned()));

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

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!