std: move `getpid` to `sys::process` by joboet · Pull Request #153130 · rust-lang/rust

joboet · 2026-02-26T12:16:56Z

Availability of process IDs is highly correlated with availability of processes, so moving the getpid implementations to sys::process makes a lot of sense (and removes quite some code duplication). The only notable change here is on Hermit, which doesn't have processes but does have getpid. But that always returns 0, so I doubt it is useful. If the change to a panic is problematic we could always copy the stub implementation and return zero ourselves (this also applies to the other single-process platforms).

CC @stlankes @mkroening

rustbot · 2026-02-26T12:17:00Z

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
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

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: @ChrisDenton, libs
@ChrisDenton, libs expanded to 8 candidates

lygstate · 2026-02-27T08:15:50Z

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

 #[stable(feature = "unix_ppid", since = "1.27.0")]
 pub fn parent_id() -> u32 {
-    crate::sys::os::getppid()
+    crate::sys::process::getppid()


We can implement getppid on windows, don't know why we do not have it.

Mark-Simulacrum · 2026-02-28T16:30:46Z

r=me if you don't want to wait on Hermit target maintainers to respond

mkroening

Thanks for cleaning this up.

This does not break any applications we test in our CI (hermit-os/kernel#2286), so I think this is worth a try. Should we notice any other applications breaking due to this in the future, we'll open a PR. :)

View changes since this review

joboet · 2026-03-01T09:49:59Z

Thanks 😉
@bors r=@Mark-Simulacrum

rust-bors · 2026-03-01T09:50:02Z

📌 Commit 013a904 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

…uwer Rollup of 6 pull requests Successful merges: - #153130 (std: move `getpid` to `sys::process`) - #152549 (Revert "resolve: Downgrade `ambiguous_glob_imports` to warn-by-default") - #153231 (diags: Pass `DiagArgMap` instead of `FluentArgs` into `format_diag_message`) - #153246 (Fix compile error in std::fs impl on VEXos target) - #153255 (Recover feature lang_items for emscripten) - #153257 (update my mailmap)

@stlankes

Rollup merge of #153130 - joboet:move_getpid_sys_process, r=Mark-Simulacrum std: move `getpid` to `sys::process` Part of #117276. Availability of process IDs is highly correlated with availability of processes, so moving the `getpid` implementations to `sys::process` makes a lot of sense (and removes quite some code duplication). The only notable change here is on Hermit, which doesn't have processes but does have `getpid`. But that [always returns 0](https://github.com/hermit-os/kernel/blob/ef27b798856b50d562a42c4ffd2edcb7493c5b5f/src/syscalls/tasks.rs#L21), so I doubt it is useful. If the change to a panic is problematic we could always copy the stub implementation and return zero ourselves (this also applies to the other single-process platforms). CC @stlankes @mkroening

@xobs

std: refactor Xous startup code To facilitate rust-lang#117276 I'm moving all non-path-related code out of `sys::pal::os` (see also rust-lang#153130). This is particularly involved for Xous as `pal::os` also contains the `_start` entry function and the parameter block handling. This PR moves both out into the main `sys::pal` module and also simplifies the parameter block initialisation code slightly. CC @xobs

@xobs

Rollup merge of #153341 - joboet:xous_params, r=tgross35 std: refactor Xous startup code To facilitate #117276 I'm moving all non-path-related code out of `sys::pal::os` (see also #153130). This is particularly involved for Xous as `pal::os` also contains the `_start` entry function and the parameter block handling. This PR moves both out into the main `sys::pal` module and also simplifies the parameter block initialisation code slightly. CC @xobs

@jethrogb

std: move `sys::pal::os` to `sys::paths` Part of rust-lang#117276. After rust-lang#150723, rust-lang#153130, rust-lang#153341 and rust-lang#153413, `sys::pal::os` only contains default-path related functions (like `getcwd` and the `PATH`-splitting logic). In line with rust-lang#117276, this PR thus moves all these implementations into a new module in `sys`: `sys::paths`. ~There is one functional change here: The `chdir` implementation on SGX used to use `sgx_ineffective` which silently fails, but now returns an error unconditionally – I think that's much more reasonable given that SGX doesn't support filesystem stuff at all.~ I've corrected the misleading panic messages in `temp_dir` for UEFI and WASI, aside from that, this PR only consists of code moves. CC @jethrogb @raoulstrackx @aditijannu for the SGX change (resolved)

@jethrogb

std: move `sys::pal::os` to `sys::paths` Part of rust-lang#117276. After rust-lang#150723, rust-lang#153130, rust-lang#153341 and rust-lang#153413, `sys::pal::os` only contains default-path related functions (like `getcwd` and the `PATH`-splitting logic). In line with rust-lang#117276, this PR thus moves all these implementations into a new module in `sys`: `sys::paths`. ~There is one functional change here: The `chdir` implementation on SGX used to use `sgx_ineffective` which silently fails, but now returns an error unconditionally – I think that's much more reasonable given that SGX doesn't support filesystem stuff at all.~ I've corrected the misleading panic messages in `temp_dir` for UEFI and WASI, aside from that, this PR only consists of code moves. CC @jethrogb @raoulstrackx @aditijannu for the SGX change (resolved)

@jethrogb

std: move `sys::pal::os` to `sys::paths` Part of rust-lang#117276. After rust-lang#150723, rust-lang#153130, rust-lang#153341 and rust-lang#153413, `sys::pal::os` only contains default-path related functions (like `getcwd` and the `PATH`-splitting logic). In line with rust-lang#117276, this PR thus moves all these implementations into a new module in `sys`: `sys::paths`. ~There is one functional change here: The `chdir` implementation on SGX used to use `sgx_ineffective` which silently fails, but now returns an error unconditionally – I think that's much more reasonable given that SGX doesn't support filesystem stuff at all.~ I've corrected the misleading panic messages in `temp_dir` for UEFI and WASI, aside from that, this PR only consists of code moves. CC @jethrogb @raoulstrackx @aditijannu for the SGX change (resolved)

@jethrogb

std: move `sys::pal::os` to `sys::paths` Part of rust-lang#117276. After rust-lang#150723, rust-lang#153130, rust-lang#153341 and rust-lang#153413, `sys::pal::os` only contains default-path related functions (like `getcwd` and the `PATH`-splitting logic). In line with rust-lang#117276, this PR thus moves all these implementations into a new module in `sys`: `sys::paths`. ~There is one functional change here: The `chdir` implementation on SGX used to use `sgx_ineffective` which silently fails, but now returns an error unconditionally – I think that's much more reasonable given that SGX doesn't support filesystem stuff at all.~ I've corrected the misleading panic messages in `temp_dir` for UEFI and WASI, aside from that, this PR only consists of code moves. CC @jethrogb @raoulstrackx @aditijannu for the SGX change (resolved)

@jethrogb

std: move `sys::pal::os` to `sys::paths` Part of rust-lang/rust#117276. After rust-lang/rust#150723, rust-lang/rust#153130, rust-lang/rust#153341 and rust-lang/rust#153413, `sys::pal::os` only contains default-path related functions (like `getcwd` and the `PATH`-splitting logic). In line with rust-lang/rust#117276, this PR thus moves all these implementations into a new module in `sys`: `sys::paths`. ~There is one functional change here: The `chdir` implementation on SGX used to use `sgx_ineffective` which silently fails, but now returns an error unconditionally – I think that's much more reasonable given that SGX doesn't support filesystem stuff at all.~ I've corrected the misleading panic messages in `temp_dir` for UEFI and WASI, aside from that, this PR only consists of code moves. CC @jethrogb @raoulstrackx @aditijannu for the SGX change (resolved)

std: move getpid to sys::process

013a904

rustbot assigned Mark-Simulacrum Feb 26, 2026

joboet mentioned this pull request Feb 26, 2026

Tracking Issue for restructuring std::sys #117276

Open

32 tasks

lygstate reviewed Feb 27, 2026

View reviewed changes

mkroening mentioned this pull request Feb 28, 2026

experiment: panic on getpid hermit-os/kernel#2286

Closed

mkroening approved these changes Mar 1, 2026

View reviewed changes

rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 1, 2026

JonathanBrouwer mentioned this pull request Mar 1, 2026

Rollup of 6 pull requests #153260

Merged

rust-bors bot merged commit ad896d3 into rust-lang:main Mar 1, 2026
11 checks passed

rustbot added this to the 1.96.0 milestone Mar 1, 2026

joboet mentioned this pull request Mar 3, 2026

std: refactor Xous startup code #153341

Merged

joboet mentioned this pull request Mar 9, 2026

std: move sys::pal::os to sys::paths #153623

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

std: move `getpid` to `sys::process`#153130

std: move `getpid` to `sys::process`#153130
rust-bors[bot] merged 1 commit intorust-lang:mainfrom
joboet:move_getpid_sys_process

joboet commented Feb 26, 2026 •

edited by rustbot

Loading

Uh oh!

rustbot commented Feb 26, 2026

Uh oh!

lygstate Feb 27, 2026

Uh oh!

Mark-Simulacrum commented Feb 28, 2026

Uh oh!

mkroening left a comment •

edited by rustbot

Loading

Uh oh!

joboet commented Mar 1, 2026

Uh oh!

rust-bors bot commented Mar 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Conversation

joboet commented Feb 26, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Feb 26, 2026

Uh oh!

lygstate Feb 27, 2026

Choose a reason for hiding this comment

Uh oh!

Mark-Simulacrum commented Feb 28, 2026

Uh oh!

mkroening left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joboet commented Mar 1, 2026

Uh oh!

rust-bors bot commented Mar 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

joboet commented Feb 26, 2026 •

edited by rustbot

Loading

mkroening left a comment •

edited by rustbot

Loading