dce@mips.UUCP (04/10/87)
Mips supports two versions of Unix: one based on System V.3 and one
based on 4.3BSD. Currently, we are adding the uname system call and
command to our BSD-based system, but we've run into some a snag that
affects both systems.
The snag is that we don't know what the values returned should be,
and we could use some help.
Going down the list (as given in SVID Vol. 1, page 141 and comparing with
SVID Vol. 2, page 127):
sysname - This one is tough because the uname() system call says
it is the "current operating system" whereas the uname
command (both code and manual page) imply that it is the
host name. The BRL uname bears this out.
nodename - If sysname is the host name, when and why is nodename
different?
release and version - What are the value restrictions for these?
Do people really expect these to not contain spaces even
though it isn't specified?
machine - The same questions as above apply, plus, is there an
official registry of hardware names? The SVID says that
this is a "standard name that identifies the hardware",
but it doesn't give anything else.
Is uname really intended to be useable by programs, or is it kind of
like the id command; useful in interactive mode, but useful in programs
only if you are willing to process the data with something like sed or
expr.
--
David Elliott {decvax,ucbvax,ihnp4}!decwrl!mips!dceguy@gorodish.UUCP (04/11/87)
> sysname - This one is tough because the uname() system call says > it is the "current operating system" whereas the uname > command (both code and manual page) imply that it is the > host name. The BRL uname bears this out. > > nodename - If sysname is the host name, when and why is nodename > different? I suspect the term "historical dreg" applies here. In PWB/UNIX 1.0, the "uname" call had a "sysname" but not a "nodename" field; PWB/UNIX 1.0 was V6-based, so it didn't have anything like UUCP. I suspect "sysname" values were local values, and not necessarily globally unique (e.g., I suspect the PWB A machine was just called "a"), and that "nodename" was added for the benefit of UUCP or something like that. I think the "current operating system" stuff derives from the "/usr/group" and IEEE standards; somebody probably saw that "sysname" was redundant and interpreted "sys" as meaning "operating system", not "machine". A 3B2 we have here gives them both the same values; the "uname" that we supply is basically Doug Gwyn's version and also returns the same value for both fields. BTW, note that if you don't increase the length of the "nodename" (and "sysname", if you make it a copy of "nodename") component, it would be a mistake for anybody to *use* "uname" to get the name of the host, since the limit is 9 bytes (i.e., 8 characters plus a NUL) in the S5 "uname" structure but is 32 characters in 4.2BSD and 64 characters in 4.3BSD. > release and version - What are the value restrictions for these? > Do people really expect these to not contain spaces even > though it isn't specified? I don't know that people expect *anything* from those fields. People tended to put things like "mmdd", giving the month and the day you configured the kernel, there. I guess a system using BSD-style kernel configuration could put the same ordinal there that get stuck in the boot message. As for "release", if a vendor puts *their* release number in there, there's little you can count on being there in general. > machine - The same questions as above apply, plus, is there an > official registry of hardware names? Nope, no registry. In VAX S5, I think they had "vax780" and "vax750"; the question is whether anybody cared whether the machine was a 780 or a 750. > Is uname really intended to be useable by programs, or is it kind of > like the id command; useful in interactive mode, but useful in programs > only if you are willing to process the data with something like sed or > expr. The only thing I can see that's of any general use is "nodename". "release" might be useful if you wanted to know which release of the OS you were running. Other than that, the result of "uname" seems largely decorative in function.