GNU testsuite comparison:

Skip an intermittent issue tests/tail/overlay-headers (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/misc/tee (passes in this run but fails in the 'main' branch)

i have opened uutils/platform-info#96 to add the processor() method to the platform-info crate.

once that's merged and released, we can update this PR to use info.processor() instead of the local map_processor() function.

Fix uname -p returning "unknown" by mapping machine architecture strings to processor types, matching GNU coreutils behavior.

This is incorrect. GNU Coreutils returns unknown in many cases.

On x86_64 GNU/Linux:

$ uname --version | head -n 1
uname (GNU coreutils) 9.8.11-bfcfe
$ uname -p
unknown

On aarch64 GNU/Linux:

$ uname --version | head -n 1
uname (GNU coreutils) 9.7
$ uname -p
unknown

See discussion on the history of this option discussed on the GNU Coreutils mailing list.

[1] https://lists.gnu.org/archive/html/coreutils/2025-09/msg00236.html
[2] https://lists.gnu.org/archive/html/coreutils/2025-09/msg00237.html

@collinfunk many thanks for the input :)

I'm reframing this PR from "bug fix" to "feature enhancement".

The original issue was resolved downstream (Ubuntu patched kdump-tools to use uname -m), but uname -p returning "unknown" isn't useful. This PR enhances it to return meaningful processor information.

ref: https://bugs.launchpad.net/ubuntu/+source/coreutils-from/+bug/2122648

testing shows that the current behavior matches standard GNU coreutils:

Standard GNU coreutils behavior (returning "unknown"):

$ podman run --rm debian:latest uname -p
unknown

$ podman run --rm fedora:latest uname -p
unknown

$ podman run --rm alpine:latest uname -p
unknown

With this PR applied (returning mapped values):

$ podman run --rm -v ./target/release/uname:/usr/local/bin/uname debian:latest /usr/local/bin/uname -p
aarch64

$ podman run --rm -v ./target/release/uname:/usr/local/bin/uname fedora:latest /usr/local/bin/uname -p
aarch64

$ podman run --rm -v ./target/release/uname:/usr/local/bin/uname ubuntu:latest /usr/local/bin/uname -p
aarch64

I'm reframing this PR from "bug fix" to "feature enhancement".

The original issue was resolved downstream (Ubuntu patched kdump-tools to use uname -m), but uname -p returning "unknown" isn't useful. This PR enhances it to return meaningful processor information.

ref: https://bugs.launchpad.net/ubuntu/+source/coreutils-from/+bug/2122648

But why? No one uses uname -p.

The script that was fixed there was a Ubuntu invention that was added on top of Debian's kdump-tools package, which they import [1]. You can verify from this from a container:

$ podman run -it --rm ubuntu:rolling 
$ apt-get update -y && apt-get upgrade -y && apt-get install -y kdump-tools
$ ls /usr/share/kdump-tools/kdump_set_default 
/usr/share/kdump-tools/kdump_set_default

$ podman run --rm -it debian:experimental
$ apt-get update -y && apt-get upgrade -y && apt-get install -y kdump-tools
$ ls /usr/share/kdump-tools/kdump_set_default
ls: cannot access '/usr/share/kdump-tools/kdump_set_default': No such file or directory

[1] https://launchpad.net/ubuntu/+source/kdump-tools/1:1.10.7ubuntu1

@collinfunk

No one uses uname -p.

We don't judge the usage of an option. We want to be a full drop-in-replacement of GNU :)

We don't judge the usage of an option. We want to be a full drop-in-replacement of GNU :)

The issue that I have with this proposal is that it diverges from the longstanding behavior of GNU. Also busybox and toybox for that matter:

$ uname -a
Linux 391e1d26e6c7 6.8.11-300.fc40.aarch64 #1 SMP PREEMPT_DYNAMIC Mon May 27 15:22:03 UTC 2024 aarch64 GNU/Linux
$ uname -p
unknown
$ busybox uname -p
unknown
$ toybox uname -p
unknown

If anyone wants the processor type, they just use uname -m which has been around since at least SUSv2 [1]:

$ uname -m
aarch64

If you look up "uname -p" on GitHub, you can find that many people have something in their dotfiles like this:

if test $(uname -p) = arm; then
  # Do MacOS specific setup.
  [...]
fi

This extension will almost certainly break people's configurations. And it will likely break some ./configure (or similar) scripts.

[1] https://pubs.opengroup.org/onlinepubs/007908799/xcu/uname.html

OK, I understand now your concerns. We should do the same then :)
Thanks for taking the time!