bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#13001: Reporting potential bug | uname -p and uname -i return unknow


From: Mike Frysinger
Subject: bug#13001: Reporting potential bug | uname -p and uname -i return unknown on Debian
Date: Mon, 26 Nov 2012 15:55:27 -0500

On Mon, Nov 26, 2012 at 3:26 PM, Pádraig Brady wrote:
> On 11/26/2012 06:51 PM, Mike Frysinger wrote:
>> On Mon, Nov 26, 2012 at 1:11 PM, Mike Frysinger wrote:
>>> the GNU version relies on the standard
>>> interfaces to do that (which they don't).
>>
>> to be clearer, the interfaces coreutils relies on don't exist on
>> Linux, so it always issues "unknown"
>>
>>> you can find the patch i've been keeping up-to-date in Gentoo:
>>>
>>> http://sources.gentoo.org/gentoo/src/patchsets/coreutils/8.20/003_all_coreutils-gentoo-uname.patch
>>
>>
>> in the past, i assumed this wasn't going anyways because coreutils did
>> not include any target-specific logic.  but i see it has since grown
>> __APPLE__ support, so maybe i can make a case for adding __linux__.
>>
>> Paul: you were against this in the past [1], but in light of
>> 594d5064c950fa1d99a9eafbd357c5f46320d002, can we reconsider ?  i don't
>> mind helping out with this particular can considering i'm going to be
>> doing it anyways ... not to mention every distro is running into the
>> same issue and patching it in their own unique/incomplete way.
>> -mike
>>
>> [1] http://lists.gnu.org/archive/html/bug-coreutils/2005-09/msg00063.html
>
> We should either deprecate the options, or try
> to standardise them a bit.
>
> From POSIX we have
>   -m  Write the name of the hardware type on which
>       the system is running to standard output.
>
> From BSD we have:
>   -m  print the machine hardware name.
>   -p  print the machine processor architecture name.
>   $ uname -mp
>   amd64 x86_64
>
> From Fedora 15 we have:
>   -m  print the machine hardware name.
>   -p  print the processor type or "unknown"
>   -i  print the hardware platform or "unknown"
>
>   $ uname -mpi
>   x86_64 x86_64 x86_64

the current Fedora patch merely shows the output of uname()'s machine
field.  so it's the same as `uname -m`.

it does have a minor hack so that if the machine is i[3-6]86, it
normalizes it to "i386" for the -i option.

> From Solaris we have:
>   -m  Prints the machine hardware name (class).
>       Use of this option is discouraged. Use -p instead.
>   -p  Prints the current host's ISA or processor type.
>   -i  Prints the name of the platform.
>   > uname -mpi
>   sun4v sparc SUNW,SPARC-Enterprise-T5220

Gentoo is very similar:
$ uname -mpi
sparc64 sun4v UltraSparc T1 (Niagara)

> From Debian we have:
>   $ uname -mpi
>   x86_64 unknown unknown

right, Debian is the same as GNU since it doesn't apply any custom patches

> From Gentoo we have:
>
>   $ uname -m
>   x86_64
>   $ uname -p
>   Intel(R) Core(TM) i3-2310M CPU @ 2.10GHz
>   $ uname -i
>   GenuineIntel

looks good to me ;)

> So it's awkward to come up with something coherent
> between them all. I'd be inclined to have -p print the "arch",
> i.e. x86_64, and leave -i to print out the free form
> info from /proc cpu info.

the -m flag already prints out the "arch", so it seems pointless to
have -p do the same.  the former flag is used everywhere for platform
detection while the latter is used for informational purposes in
autoconf packages.
-mike





reply via email to

[Prev in Thread] Current Thread [Next in Thread]