Re: incorrect machine reporting...

[Bob Proulx]

Alan Grimes wrote:
> uname (5.0) reports my athlon-mp to be an i686...

Thank you for reporting this.  But you left out some key pieces of
information such as exactly which data fields you were commenting upon
or which options were using to select a particular data field.  I
can only guess you are commenting upon the 'uname -m' output.

The uname program is troubled since there are no standards in this
area.  The relevant references are these.

  http://www.unix-systems.org/single_unix_specification_v2/xsh/uname.html
  http://www.unix-systems.org/single_unix_specification_v2/xsh/sysutsname.h.html

Note that nothing is definitively said about what the data should
contain.  Only that the system call and a few fields must exist.
Older commercial systems have implemented these in various ways
different from each other.  Many do not make sense free software
systems such as GNU systems.  Therefore implementations have had to
"wing it" and come up with their own best uses for those data fields.

Because of the trouble with uname I recommend people avoid all uses of
it except for 'uname' with no options in portable scripts.  After
determining the system is a specific system (such as Linux or HP-UX)
then they can use further options known to exist on that system.

The -m and -p options are documented by coreutils as the following.

       -m, --machine
              print the machine (hardware) type

       -p, --processor
              print the host processor type

The processor type on most systems prints 'unknown' since this
information is not easily determinable.  On BSD systems I infer that
it may be possible to do more.  But on the FreeBSD systems I looked at
it printed the same information as the machine type (i386) even on P3
systems.

The machine type is probably more correctly called the architecture.
On an AMD system i686 is correct in this case and my Athlon machines
are also reported as i686.

The uname(1) standalone command reports the information returned from
the uname(2) system call which reports data stored in the 'struct
utsname' data structure.  This structure is controlled in the kernel
and cannot be affected by the coreutils programs which just report the
data.

> Valid detections for my hardware would include:
> 
> athlon
> athlon-xp
> athlon-mp

Perhaps.

> however, the algorithm should also check the number of CPUs for what 
> would otherwise be an xp detection and set "mp" when appropriate.

Negative.  I have seen people incorrectly use XP processors in an SMP
configuration.  Number of CPUs _should_ indicate this but not if
someone has thrown caution to the wind and skated around on an ice
rink of razor blades with blocks of ice strapped to their feet.

> I looked at the source and couldn't make heads or tails out of it... It 
> was not clear at all how exactly the chip was being identified or which 
> header it was getting its information from... If there is someone else I 
> should report this to please tell me...

It is this part of the code:

      struct utsname name;

      if (uname (&name) == -1)
        error (EXIT_FAILURE, errno, _("cannot get system name"));

      if (toprint & PRINT_KERNEL_NAME)
        print_element (name.sysname);
      if (toprint & PRINT_NODENAME)
        print_element (name.nodename);
      if (toprint & PRINT_KERNEL_RELEASE)
        print_element (name.release);
      if (toprint & PRINT_KERNEL_VERSION)
        print_element (name.version);
      if (toprint & PRINT_MACHINE)
        print_element (name.machine);

The kernel is owner of this data.

> In general any modern CPU detection algorithm sholud look at the CPU's 
> reported vendor name and never report anything other than "GENUINEINTEL' 
> parts as ix86.
> 
> For recient "AUTHONTICAMD" parts the name should either be athlon or 
> opteron... and Nx86 for parts not in the database where N is the 
> reported generation.

You might be peeking at /proc/cpuinfo on Linux systems.  That is the
better place to get this information.  But beware that different Linux
architectures again report different information through that
interface.  Here are some abbreviated examples:

Athlon-XP:
    vendor_id       : AuthenticAMD
    cpu family      : 6
    model           : 6
    model name      : AMD Athlon(tm) XP 1700+
    stepping        : 2

Intel Pentium4:
    vendor_id       : GenuineIntel
    cpu family      : 15
    model           : 2
    model name      : Intel(R) Xeon(TM) CPU 3.06GHz
    stepping        : 5

Intel Pentium-133MHz:
    vendor_id       : GenuineIntel
    cpu family      : 5
    model           : 2
    model name      : Pentium 75 - 200

Intel Madison:
    vendor     : GenuineIntel
    arch       : IA-64
    family     : Itanium 2
    model      : 1
    revision   : 5

Therefore I infer that these are architecture specific fields and
cannot be counted upon across different kernel architectures.  Even on
the same architecture the fields such as madel name are not
consistently used.

Bob