Description of problem: uname -m returns "arm" for that processor family, but uname -p returns "unknown" Why ? This seems inconsistent with the man page for uname. The man page for uname states that -p returns the processor type. Which, is clearly known as uname -m is already returning this string. The -m returns "machine" which is an ill defined term and inconsistent across the industry. The returned values from uname -p are far more consistent across operating systems. Example: On AIX uname -m returns 98787687y459 but uname -p returns "powerpc". Uname -m on MacOS returns "Macintosh x86_64" but uname -p returns "x86_64" Uname -m on Solaris returns "i86pc" but Uname -p returns "i386" and similar for other operating systems. The uname -p is clearly more consistent than the -m option. It seems even more strange that Linux would have uname -p return x86_64 on Intel, but "unknown" on ARM, when the same boxes will return x86_64 for the -m option on Intel, and "unknown" on ARM. So there is inconsistency even within the same version of Linux.... Version-Release number of selected component (if applicable): All versions that support ARM processors. How reproducible: Very. Steps to Reproduce: 1.uname -p on any ARM based system. Actual results: # uname -m armv7l # uname -p unknown [~] # Expected results: arm, arm71, armv71 anything that matches what uname -m is returning would be better than "unknown" :-) Additional info:
I tried it on aarch64 and it worked as expected: # rpm -q coreutils coreutils-8.22-18.el7.aarch64 # uname -m aarch64 # uname -p aarch64 # uname -a Linux hp-moonshot-02-c06.khw.lab.eng.bos.redhat.com 4.5.0-15.4.2.el7.aarch64 #1 SMP Wed Mar 22 15:58:27 EDT 2017 aarch64 aarch64 aarch64 GNU/Linux Please provide the output for the above commands captured on your system.
#rpm -q coreutils command not found <<< I'm using a small embedded version of Linux on a system with small amounts of RAM. So, some commands are not present >>>> Actual output: # uname -m armv7l # uname -p unknown ------------- Do you have an arm7l where you can check this ? or perhaps just take a peek at the source code for uname and see if it supports all of the various ARM processor types ? Note: Wikipedia also tries to show all of the various uname outputs, across the various Operating systems, and versions of operating systems. See: https://en.wikipedia.org/wiki/Uname
(In reply to Don Capps from comment #3) > #rpm -q coreutils > command not found > <<< I'm using a small embedded version of Linux on a system with small > amounts of RAM. So, some commands are not present >>>> I need to know exactly which build of coreutils (RPM package) you are using. If you are able to get the output of strace for the above commands, it would also help. Note that you forgot to paste the output of 'uname -a'. > Do you have an arm7l where you can check this ? I am not sure. > or perhaps just take a peek > at the source code for uname and see if it supports all of the various ARM > processor types ? The original source code of uname(1) distributed with coreutils-8.22 is here: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/uname.c;hb=v8.22 Fedora and RHEL apply the following patch on top of that: https://src.fedoraproject.org/cgit/rpms/coreutils.git/tree/coreutils-8.2-uname-processortype.patch?id=34aa7594 > Note: Wikipedia also tries to show all of the various uname outputs, across > the various Operating systems, and versions of operating systems. See: > https://en.wikipedia.org/wiki/Uname It is not clear which implementation of uname(1) the wiki page describes. RHEL-7 implementation differs from upstream. See the patch above.
Looking closer at the patch, it falls back to 'uname -m' for the -p/-i options in case sysinfo() cannot be used to obtain the requested information. It just hides the actual problem, instead of printing "unknown" as documented. The documentation was later improved upstream to make it clear that the -p and -i options are non-portable: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.24-7-g6d67649
Don, could you please verify that you are really using the uname implementation provided by a Red Hat supported coreutils package? I would expect the patched code to return the same output for 'uname -p' as for 'uname -m' instead of returning "unknown".
The system that demonstrated the uname-p problem has been de-installed. So.. We can either close the bug, or try to find another arm71 based system to restart the debug. Thank you, Don Capps
Thanks for reply! I am closing the bug now. Feel free to reopen once you have the requested info...