"David A. Braun" <braun@xxxxxxxxxxxxxxxxxxxxxx> writes:
> Based on your guidance I scanned the online manual for autoconfig. This
> seems to be the source for the terminology in question. In partucular there
> is a script (config.sub) that is part of the autoconfig toolset that
> canonicalizes these strings. What seems to be missing is any definition of
> what each of the field means (cpu, company/manufacturer, os and kernel). The
> response of config.sub to i386-redhat-linux (i386-redhat-linux-gnu) suggests
> it (config.sub) is
> confused too. This would suggest that gnu is an operating system (it is),
> linux is a kernel (it is), i386 is a cpu (well ...) and redhat is a
> manufacturer (the aren't - what machines does Redhat produce)? There doesn't
> seem to be a clear definition on whether "manufacturer" is left or right
> associative. Most of the other usages suggest it's left associative (binds
> with CPU rather than OS or OS-Kernel).
You are certainly correct that configuration names are loosely
defined. Here are my notes on them:
http://www.airs.com/ian/configure/configure_4.html#SEC25
Here is the brief discussion in the goat book, based on my notes:
http://sources.redhat.com/autobook/autobook/autobook_17.html#SEC17
Your comment about i386-redhat-linux is slightly misguided.
config.sub canonicalizes configuration names, it doesn't validate
them. For example, config.sub similarly turns i386-foobar-linux into
i386-foobar-linux-gnu. The purpose of config.sub is to permit people
to write configuration names in a loose format; config.sub will
canonicalize that format such that the same machine can be named in
different ways. config.sub won't check that the configuration name is
correct or valid in any sense.
Configuration names are validated only by how configure scripts are
written. There is no higher level way to look at them. This was
necessary when configuration names were invented because there were so
many different types of systems out there. These days there are only
a few types of systems, and it might be possible to simplify and
formalize configuration names to some degree, if anybody really cares.
The `manufacturer' field is indeed the orphan of the configuration
name system. At one time it made sense to distinguish between, e.g.,
i386-att-sysv4 and i386-sequent-sysv4. In fact, it would still make
sense, if anybody still ran either of those systems. In today's
simpler world, manufacturers have become commoditized, and they no
longer produce their own operating system variants. Once you've said
the CPU and linux-gnu, it doesn't really matter who manufactured the
system.
> BTW I agree with Llwellynn that the result is incorrect but I think the
> correct answer should be along the lines of i386-pc-linux-gnu (i386-pc
> indicating a generic i386 platform). There doesn't seem to be any place in
> the string for a distributor (ala Redhat, Slackware, Suse, etc) even if
> their OS is a variant. It looks as though the script assumes that the
> unidentified string "redhat" is an unrecognized hardware manufacture. I
> tried i386-linux-gnu_redhat and it produced i386-pc-linux-gnu_redhat.
> i386-gnu_redhat => i386-pc-gnu_redhat. All mildly interesting but useless
> without a definition.
If you need to distinguish, e.g. Redhat Linux and S.U.S.E. Linux, then
I think the right approach with the current system is
i386-pc-linuxredhat-gnu
i386-pc-linuxsuse-gnu
However, if you do need to distinguish them, you are almost certainly
doing something wrong.
A more serious drawback of configuration names is for processors like
MIPS, in which the configuration name is expected to represent the CPU
family ("mips"), the ISA (both the level and the specific CPU), the
default ABI, the default endianness, and even perhaps some arbitrary
number of ASEs.
Ian
