brain-damage in SysV/386 r3.2 uname, etc.

[Guy Harris]

(Not S5/386 specific; followups to "comp.bugs.sys5", for now, although
it might want to sneak into one of the other UNIX groups.)

>Although it may not be entirely clear to some people, as I read the
>uname(2) man-page, it is obvious uname(1,2) are meant to determine the
>system type, by default, and nodename is *always* an option.  As the
>manpage says, "sysname" is the name of the current UNIX *system*,
>"nodename" is the name that system is known by on a network,

Unfortunately, the word "system" there appears to have been interpreted
differently by different folks.  Back in the PWB/UNIX 1.0 (as in
"V6-flavored") days, when "uname" first popped up, there was no
"nodename" field because there wasn't anything such as UUCP in PWB/UNIX;
there was only "sysname", which was the name of the *machine*.

I suspect it tended to be a very short and non-unique name (e.g., "a"),
so that when UUCP showed up, there needed to be another field to give a
name more likely to be globally unique, so "nodename" was added.

I think the original SVID implied that "sysname" was supposed to be the
name of the *OS*, rather than the name of the machine, with "nodename"
the name of the machine.  I don't have the original handy to check, but
I remember *some* standard - perhaps it was a POSIX draft, as the
standard in question predated 1003.1 officially coming out - saying so. 
I also don't have volume 1 of SVID Issue 2 handy, but volume 2 says
about the "uname" *command* that 1) "sysname" is "a name by which the
system is known in the local installation", which could mean it's
supposed to be a machine name, and 2) "uname" with no arguments prints
"sysname".

The model specified by POSIX, in which "sysname" is the "name of this
implementation of the operating system", makes more sense to me; having
two machine names doesn't seem useful.  Unfortunately, a lot of code may
have depended on "sysname" being the machine name - or, at least, on an
unadorned "uname" generating the *machine's* name, which the S5
accounting scripts require, and which SVID Issue 2 specifies - so there
may have been some resistance to converting it.

>"release" and "version" *further* identify the *system*,

Given "system" meaning "the OS", POSIX seems to specify that as well,
with "release" being "current release level of this implementation" and
"version" being "current version level of this release".  Back in
PWB/UNIX days (and this continued up to S5R2 or so), "release" was the
release number (as in "3.0.1" for System III) and "version" was some
administrator-specified string, typically the month and year on which
the system was built - i.e., it wasn't a vendor-chosen version, it was a
user-chosen or administrator-chosen version.  POSIX's specification
isn't exactly precise here....

>and "machine" contains a standard name that identifies the hardware
>(which in my experience should be the same as the /bin/<machine>
>command which returns TRUE).

I tend to agree, although there is a problem there - on my machine, more
than one "/bin/<machine>" (well, "/usr/bin/machine" - it's running SunOS
4.x) command returns TRUE!  "sparc", "sun", and "sun4c" all return TRUE.

In other words, how much should it tell you about the machine?

Some VAX versions of S5R2 seemed not to return "vax", but to tell you
"vax780" or "vax750", which is even more specific than, say, "sun" or
"sun4c".

My personal vote would be to have "machine" identify the highest-level
CPU architecture; i.e., basically the level for which ABI's exist. 
Thus, any machine with a 68K in it (or, at least, a 68020 or better)
would say "m68k"; any machine with an 80386 or better would say "i386";
any VAX (if anybody cares any more) would say "vax"; any SPARC-based
machine would say "sparc"; any 88K-based machine would say "m88k" or
whatever; etc..  If AT&T's current WE32K-based machines can all execute
each other's normal application binaries, they should say "we32k" or
something, *NOT* "3B2" (unless all AT&T's current WE32K-based machines
are 3B2's, not 3B15's or so).

I.e., I don't think it should tell you who made the box, or what kind of
I/O bus it has, or other stuff irrelevant to most applications.  It
might be useful to have other mechanisms to find that out, but the
"machine" field shouldn't specify it.

>I.e. instead of "eci386 eci386 1.0.6 1 80386", our machine should
>answer "ISC eci386 1.0.6 1 i386" to 'uname -a'.

I tend to agree there.

>I'm not sure how far spread this crazyness is, but beware.  Anyone
>know the details of SysVr4.0's behaviour?

SVID, Third Edition (i.e., the S5R4 one) matches POSIX, not
surprisingly, for the "uname()" procedure call.  "uname(BA_OS)" says
that "sysname" "name(s) the current operating system", while "nodename"
is "the name that the system is known by on a communications network". 
"release" and "version" "further identify the operating system", and
"machine" "contains a standard name that identifies the hardware on
which the operating system is running" - the latter has a bit more of an
implication of detailed information about the particular box than I'd
like.

Unfortunately, it *still* says that "sysname" is the default, and "is a
name by which the system is known in the local installation", for the
"uname" *command*, in "uname(BU_CMD)".

*However*, the S5R4 *User's Reference Manual* says that the "uname"
command prints "nodename" by default, and that "uname -s" prints "the
name of the current operating system (e.g., UNIX System V)".  It also
indicates that "uname -S" changes the nodename, and doesn't seem to say
that it changes the "sysname".  I hope that the problem is that the SVID
just hasn't caught up to reality....

(Of course, you now have the question of on *which* communications network
the machine is known by what's in "nodename".  The machine's name on a
TCP/IP network may be different from the name on a UUCP network; SunOS
4.1's HDB, and perhaps the S5R3.2 HDB from which it's derived, do let
you say that the UUCP name of the machine isn't its "standard" name, as
derived from "gethostname()" or "uname()".  Dunno what happens if the
machine can talk, say, both TCP/IP and OSI....)