GNU bug report logs - #13001
Reporting potential bug | uname -p and uname -i return unknown on Debian

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13001 in the body.
You can then email your comments to 13001 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Ashish, Agrawal" <agrawal.ashish <at> hp.com>
To: "bug-coreutils <at> gnu.org" <bug-coreutils <at> gnu.org>
Subject: Reporting potential bug | uname -p and uname -i return unknown on
	Debian
Date: Mon, 26 Nov 2012 08:48:08 +0000

Hello,

I use the output of 'uname -p' in my product. It seems to work fine on very other Linux distro that I have worked on (ex. RHEL, SUSE Linux Enterprise Server and even Ubuntu 12.04), except Debian where it returns 'unknown'. The following this the relevant information of my machine and setup.

root <at> IWFVM00285:~# cat /etc/debian_version
6.0.5
root <at> IWFVM00285:~# uname -a
Linux IWFVM00285 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux
root <at> IWFVM00285:~# uname -m
x86_64
root <at> IWFVM00285:~# uname -p
unknown
root <at> IWFVM00285:~# uname -i
unknown

I found relevant bugs raised earlier (for example, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193170) but it seems either it was fixed earlier and has resurfaced or it was marked as won't fix.

Please advise. If this issue is already noted, could you please let me know the current status?

Thank you.

Ashish
+91.973.970.9990

Message #8 received at 13001 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: "Ashish, Agrawal" <agrawal.ashish <at> hp.com>
Cc: 13001 <at> debbugs.gnu.org
Subject: Re: bug#13001: Reporting potential bug | uname -p and uname -i return
	unknown on Debian
Date: Mon, 26 Nov 2012 13:11:36 -0500

On Mon, Nov 26, 2012 at 3:48 AM, Ashish, Agrawal wrote:
> I use the output of 'uname -p' in my product. It seems to work fine on very other Linux distro that I have worked on (ex. RHEL, SUSE Linux Enterprise Server and even Ubuntu 12.04), except Debian where it returns 'unknown'. The following this the relevant information of my machine and setup.

this is because many distros patch coreutils' uname to return
something useful on Linux.  the GNU version relies on the standard
interfaces to do that (which they don't).

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

> root <at> IWFVM00285:~# cat /etc/debian_version
> 6.0.5
> root <at> IWFVM00285:~# uname -a
> Linux IWFVM00285 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64 GNU/Linux
> root <at> IWFVM00285:~# uname -m
> x86_64
> root <at> IWFVM00285:~# uname -p
> unknown
> root <at> IWFVM00285:~# uname -i
> unknown

after applying the aforementioned patched, you'd get something like:
$ uname -a
Linux vapier 3.6.5 #5 SMP PREEMPT Wed Nov 14 01:08:40 EST 2012 x86_64
AMD Phenom(tm) II X4 980 Processor AuthenticAMD GNU/Linux
$ uname -m
x86_64
$ uname -p
AMD Phenom(tm) II X4 980 Processor
$ uname -i
AuthenticAMD

> I found relevant bugs raised earlier (for example, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193170) but it seems either it was fixed earlier and has resurfaced or it was marked as won't fix.

note: you've e-mailed the upstream GNU coreutils project, not the
Debian project.  if you want this functionality in Debian, you'll need
to file a bug with them.
-mike

Message #11 received at 13001 <at> debbugs.gnu.org (full text, mbox):

From: "Voelker, Bernhard" <bernhard.voelker <at> siemens-enterprise.com>
To: Mike Frysinger <vapier <at> gentoo.org>, "Ashish, Agrawal"
	<agrawal.ashish <at> hp.com>
Cc: "13001 <at> debbugs.gnu.org" <13001 <at> debbugs.gnu.org>
Subject: RE: bug#13001: Reporting potential bug | uname -p and uname -i
	return	unknown on Debian
Date: Mon, 26 Nov 2012 18:41:32 +0000

Mike Frysinger wrote:

> this is because many distros patch coreutils' uname to return
> something useful on Linux.  the GNU version relies on the standard
> interfaces to do that (which they don't).
> 
> 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

For reference, here's the downstream patch of openSuSE:
https://build.opensuse.org/package/view_file?expand=1&file=coreutils-sysinfo.patch&package=coreutils&project=openSUSE&rev=f0bf5d8bafd85e9efef6ccb334c83a53

It's not as sophisticated as the patch in Gentoo and
mostly uses a fallback to the value of 'uname -m':

  $ uname -mpi
  x86_64 x86_64 x86_64

Have a nice day,
Berny

Message #14 received at 13001 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: "Ashish, Agrawal" <agrawal.ashish <at> hp.com>, Paul Eggert <eggert <at> cs.ucla.edu>,
	Jim Meyering <jim <at> meyering.net>
Cc: 13001 <at> debbugs.gnu.org
Subject: Re: bug#13001: Reporting potential bug | uname -p and uname -i return
	unknown on Debian
Date: Mon, 26 Nov 2012 13:51:33 -0500

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

Message #17 received at 13001 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: agrawal.ashish <at> hp.com,
	eggert <at> cs.ucla.edu,
	jim <at> meyering.net
Cc: 13001 <at> debbugs.gnu.org
Subject: [PATCH] uname: add -i/-p decoding to Linux platforms
Date: Mon, 26 Nov 2012 14:35:26 -0500

To add support for additional platforms, check out the show_cpuinfo()
func in the linux/arch/<ARCH>/ source tree of the kernel.

* src/uname.c: Include trim.h.
(linux_procinfo): New function.
(main): Call linux_procinfo when __linux__ is defined and
PRINT_PROCESSOR or PRINT_HARDWARE_PLATFORM is requested.
---
 src/uname.c | 113 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 113 insertions(+)

diff --git a/src/uname.c b/src/uname.c
index 0eb123b..18f6290 100644
--- a/src/uname.c
+++ b/src/uname.c
@@ -52,6 +52,7 @@
 #include "system.h"
 #include "error.h"
 #include "quote.h"
+#include "trim.h"
 #include "uname.h"
 
 /* The official name of this program (e.g., no 'g' prefix).  */
@@ -153,6 +154,100 @@ Print machine architecture.\n\
   exit (status);
 }
 
+#ifdef __linux__
+
+# if defined(__s390__) || defined(__s390x__)
+#  define CPUINFO_FILE    "/proc/sysinfo"
+#  define CPUINFO_FORMAT  "%64[^\t :]%*[ :]%256[^\n]%c"
+# else
+#  define CPUINFO_FILE    "/proc/cpuinfo"
+#  define CPUINFO_FORMAT  "%64[^\t:]\t:%256[^\n]%c"
+# endif
+
+# define PROCINFO_PROCESSOR         0
+# define PROCINFO_HARDWARE_PLATFORM 1
+
+static int linux_procinfo(int x, char *fstr, size_t s)
+{
+  static const char * const procinfo_keys[] = {
+    /* --processor --hardware-platform */
+# if defined(__alpha__)
+    "cpu model", "system type"
+# elif defined(__arm__)
+    "Processor", "Hardware"
+# elif defined(__avr32__)
+    "processor", "cpu family"
+# elif defined(__bfin__)
+    "model name", "vendor_id",
+# elif defined(__c6x__)
+    "cpu", "soc",
+# elif defined(__cris__)
+    "cpu", "cpu model"
+# elif defined(__frv__)
+    "CPU-Core", "System"
+# elif defined(__i386__) || defined(__x86_64__)
+    "model name", "vendor_id"
+# elif defined(__ia64__)
+    "model name", "vendor"
+# elif defined(__hppa__)
+    "cpu", "model"
+# elif defined(__m68k__)
+    "CPU", "MMU"
+# elif defined(__mips__)
+    "cpu model", "system type"
+# elif defined(__powerpc__) || defined(__powerpc64__)
+    "cpu", "machine"
+# elif defined(__s390__) || defined(__s390x__)
+    "Type", "Manufacturer"
+# elif defined(__sh__)
+    "cpu type", "machine"
+# elif defined(sparc) || defined(__sparc__)
+    "type", "cpu"
+# elif defined(__vax__)
+    "cpu type", "cpu"
+# else
+    "unknown", "unknown"
+# endif
+  };
+  FILE *fp;
+  char key[65], value[257], eol, *ret;
+
+  fp = fopen(CPUINFO_FILE, "r");
+  if (fp == NULL)
+    return -1;
+
+  ret = NULL;
+  while (fscanf(fp, CPUINFO_FORMAT, key, value, &eol) != EOF)
+    {
+      if (!strcmp(trim(key), procinfo_keys[x]))
+        {
+          ret = trim(value);
+          break;
+        }
+
+      if (eol != '\n')
+        {
+          /* We need two fscanf's here in case the previous length limit
+             caused us to read right up to the newline.  Doing something
+             like "%*[^\n]\n" won't eat the newline.  */
+          if (fscanf(fp, "%*[^\n]")) {}
+          if (fscanf(fp, "\n")) {}
+        }
+    }
+
+  fclose(fp);
+
+  if (ret)
+    {
+      strncpy(fstr, ret, s);
+      return 0;
+    }
+
+  return -1;
+}
+
+#endif
+
 /* Print ELEMENT, preceded by a space if something has already been
    printed.  */
 
@@ -307,6 +402,15 @@ main (int argc, char **argv)
           element = processor;
       }
 #endif
+#ifdef __linux__
+      if (element == unknown)
+        {
+          static char processor[257];
+          if (0 <= linux_procinfo (PROCINFO_PROCESSOR, processor,
+                                   sizeof processor))
+            element = processor;
+        }
+#endif
 #ifdef UNAME_PROCESSOR
       if (element == unknown)
         {
@@ -352,6 +456,15 @@ main (int argc, char **argv)
           element = hardware_platform;
       }
 #endif
+#ifdef __linux__
+      if (element == unknown)
+        {
+          static char hardware_platform[257];
+          if (0 <= linux_procinfo (PROCINFO_HARDWARE_PLATFORM,
+                                   hardware_platform, sizeof hardware_platform))
+            element = hardware_platform;
+        }
+#endif
 #ifdef UNAME_HARDWARE_PLATFORM
       if (element == unknown)
         {
-- 
1.7.12.4

Message #20 received at 13001 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Mike Frysinger <vapier <at> gentoo.org>
Cc: "Ashish, Agrawal" <agrawal.ashish <at> hp.com>, Jim Meyering <jim <at> meyering.net>,
	13001 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#13001: Reporting potential bug | uname -p and uname -i return
	unknown on Debian
Date: Mon, 26 Nov 2012 20:26:33 +0000

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

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

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

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

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.

cheers,
Pádraig.

Message #23 received at 13001 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: "Ashish, Agrawal" <agrawal.ashish <at> hp.com>, Jim Meyering <jim <at> meyering.net>,
	13001 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: 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

Message #26 received at 13001 <at> debbugs.gnu.org (full text, mbox):

From: Bob Proulx <bob <at> proulx.com>
To: "Ashish, Agrawal" <agrawal.ashish <at> hp.com>, 13001 <at> debbugs.gnu.org
Subject: Re: bug#13001: Reporting potential bug | uname -p and uname -i
	return unknown on Debian
Date: Mon, 26 Nov 2012 15:03:35 -0700

Pádraig Brady wrote:
> We should either deprecate the options, or try
> to standardise them a bit.

I would deprecate them.  By working at all they suck people into using
them when they should be avoided.

> From POSIX we have
> ...

In HP-UX we have:

  $ uname -m
  9000/800

  $ uname -i
  1545710558

  $ uname -p
  uname: illegal option -- p
  usage: uname [-amnrsvil] [-S nodename]

Bob

Message #29 received at 13001 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Mike Frysinger <vapier <at> gentoo.org>
Cc: "Ashish, Agrawal" <agrawal.ashish <at> hp.com>, Jim Meyering <jim <at> meyering.net>,
	13001 <at> debbugs.gnu.org
Subject: Re: bug#13001: Reporting potential bug | uname -p and uname -i return
	unknown on Debian
Date: Mon, 26 Nov 2012 18:22:08 -0800

On 11/26/2012 10:51 AM, Mike Frysinger wrote:
> Paul: you were against this in the past [1], but in light of
> 594d5064c950fa1d99a9eafbd357c5f46320d002, can we reconsider ?

I'm not sure what that hexadecimal number refers to, but
my objection originally was to the hassle of maintaining
something, but if the GNU/Linux folks have an agreed-upon
way of generating -p and -i from /proc/cpuinfo then I
suppose we could fold it in.

Message #32 received at 13001 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: "Ashish, Agrawal" <agrawal.ashish <at> hp.com>, Jim Meyering <jim <at> meyering.net>,
	13001 <at> debbugs.gnu.org
Subject: Re: bug#13001: Reporting potential bug | uname -p and uname -i return
	unknown on Debian
Date: Mon, 26 Nov 2012 21:54:52 -0500

On Mon, Nov 26, 2012 at 9:22 PM, Paul Eggert wrote:
> On 11/26/2012 10:51 AM, Mike Frysinger wrote:
>> Paul: you were against this in the past [1], but in light of
>> 594d5064c950fa1d99a9eafbd357c5f46320d002, can we reconsider ?
>
> I'm not sure what that hexadecimal number refers to

it's the SHA1 of the commit in the coreutils.git that adds __APPLE__
specific logic
-mike

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.