Bug 1447460

Summary:	Uname -m returns arm for that processor, but uname -p returns Unknown ????? why ?
Product:	Red Hat Enterprise Linux 7	Reporter:	Don Capps <don.capps>
Component:	coreutils	Assignee:	Kamil Dudka <kdudka>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	qe-baseos-daemons
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	7.5-Alt	CC:	don.capps, kdudka, law, ohudlick
Target Milestone:	rc
Target Release:	---
Hardware:	arm
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-05-15 16:20:52 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Don Capps 2017-05-02 21:24:18 UTC

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:

Comment 2 Kamil Dudka 2017-05-03 10:22:28 UTC

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.

Comment 3 Don Capps 2017-05-03 13:35:13 UTC

#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

Comment 4 Kamil Dudka 2017-05-03 14:07:31 UTC

(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.

Comment 5 Kamil Dudka 2017-05-03 15:10:00 UTC

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

Comment 6 Kamil Dudka 2017-05-15 15:44:18 UTC

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".

Comment 7 Don Capps 2017-05-15 15:50:06 UTC

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

Comment 8 Kamil Dudka 2017-05-15 16:20:52 UTC

Thanks for reply!  I am closing the bug now.  Feel free to reopen once you have the requested info...