Bug 2189656

Summary:	uname -p now returns "unknown" always returned "x86_64" previously
Product:	[Fedora] Fedora	Reporter:	Tom Horsley <horsley1953>
Component:	coreutils	Assignee:	Kamil Dudka <kdudka>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	38	CC:	admiller, bruno, jamartis, jarodwilson, kdudka, kzak, noloader, ooprala, ovasik, p, svashisht, vmihalko
Target Milestone:	---	Keywords:	Regression
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-04-26 07:22:26 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tom Horsley 2023-04-25 20:16:52 UTC

Lots of little shells scripts I have now no longer work because the -p opton on uname has changed. It will probably take months to locate every script that uses uname -p and change it to use uname -m instead. Please fix uname to work the way it always has.

Reproducible: Always

Steps to Reproduce:
1.uname -p
2.see it echo "unknown"
3.
Actual Results:  
unknown

Expected Results:  
x86_64

Comment 1 Jeffrey Walton 2023-04-26 00:15:56 UTC

The man page for uname (1) says its a valid option:

       -p, --processor
              print the processor type (non-portable)

       -i, --hardware-platform
              print the hardware platform (non-portable)

Comment 2 Kamil Dudka 2023-04-26 07:22:26 UTC

It was a mistake that a Fedora package maintainer added the downstream-only patch more than 20 years ago.  All the scripts that relied on the behavior were non-portable.  If we did not remove the patch now, people would continue to write new non-portable scripts.  I understand how annoying it is to fix the technical debt that accumulated over the years but it needs to be done.  Otherwise the annoyance would only grow in the future because there is no chance that upstream would adopt the patch.

*** This bug has been marked as a duplicate of bug 2126206 ***

Comment 3 Jeffrey Walton 2023-04-26 07:28:47 UTC

(In reply to Kamil Dudka from comment #2)
> ... If we did not remove the patch now, people would
> continue to write new non-portable scripts...

So what? How is this relevant to supporting the documented options?

What interest does Linux have in ensuring correctness on other operating systems like Solaris or Windows?

Comment 4 Kamil Dudka 2023-04-26 07:45:08 UTC

(In reply to Jeffrey Walton from comment #3)
> So what? How is this relevant to supporting the documented options?

The options have been documented as non-portable since 2015:
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=v8.24-7-g6d67649

Non-portable means they work differently (or not at all) on different systems.

> What interest does Linux have in ensuring correctness on other operating
> systems like Solaris or Windows?

In this case, the options did not work portably even on Linux.  They only worked on Fedora and its derivatives.

Comment 5 Kamil Dudka 2023-04-26 07:49:50 UTC

For example, if I run `uname -p` on my Gentoo Linux box, I get:

    Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz

Would your scripts work on such a system?

Comment 6 Bruno Haible 2023-04-26 19:30:33 UTC

> They only worked on Fedora and its derivatives.
Well, then Ubuntu, Slackware, and openSUSE count as Fedora derivatives?

Here's the results that I get for `uname --version` and `uname -mip` on several machines:

x86
===
Slackware 14       8.19             i686 AMD Ryzen 7 4800U with Radeon Graphics AuthenticAMD
Ubuntu 18.04       8.28             i686 athlon i686

x86_64
======
CentOS 7           8.22             x86_64 x86_64 x86_64
openSUSE 15.2      8.29             x86_64 x86_64 x86_64
Ubuntu 22.04       8.32             x86_64 x86_64 x86_64
Fedora 36          9.0              x86_64 x86_64 x86_64
Arch Linux 19.11   8.31             x86_64 unknown unknown
Alpine Linux 3.17  BusyBox          x86_64 unknown unknown
coreutils upstream 8.32.251-7b0db   x86_64 unknown unknown

I would agree that on x86 the values were not very useful due to missing normalization (e.g. "AuthenticAMD" vs. "i686"), whereas on x86_64 they were not very useful because identical to `uname -m`.

A program that really needs to know details about the processor is gmp-6.2.1/config.guess, and they don't use `uname -i` or `uname -p` for this purpose, but instead inspect the value of the cpuid instruction.

Comment 7 Kamil Dudka 2023-04-27 07:05:09 UTC

(In reply to Bruno Haible from comment #6)
> > They only worked on Fedora and its derivatives.
> Well, then Ubuntu, Slackware, and openSUSE count as Fedora derivatives?

I meant that this very specific behavior was available only on Fedora and its derivatives.  `uname -p` and `uname -i`, of course, work on many other distros in the sense that they return "something".