Path: utzoo!news-server.csri.toronto.edu!rutgers!dimacs.rutgers.edu!seismo!uunet!uunet.UU.NET!sef
From: karish@mindcraft.com (Chuck Karish)
Newsgroups: comp.std.unix
Subject: Re: uname.sysname
Summary: Don't count on it
Message-ID: <125490@uunet.UU.NET>
Date: 13 Mar 91 17:20:34 GMT
References: <125382@uunet.UU.NET>
Sender: usenet@uunet.UU.NET
Organization: Mindcraft, Inc.
Lines: 28
Approved: sef@uunet.uu.net (Moderator, Sean Eric Fagan - comp.std.unix)
Nntp-Posting-Host: uunet.uu.net
X-Submissions: std-unix@uunet.uu.net
Originator: sef@uunet.UU.NET

Submitted-by: karish@mindcraft.com (Chuck Karish)

In article <125382@uunet.UU.NET> ernest@pegasus.dsg.tandem.com
(Ernest Hua) writes:
>What is the real definition of "sysname" field in the uname struct?
>It seems that at some hardware vendors put in the operating system
>revision (as 1003.1-1988 defines on p. 77, ugly green book).  But
>others use "nodename" and "sysname" as equivalent.

The real definition, in the POSIX.1 context, anyway, is the one Mr. Hua
cites: "Name of this implementation of the operating system".  In
practice, vendors use the fields of the uname structure in very
different ways that long predate POSIX.  It's useless to try to
interpret these fields other than on an implementation-specific basis.

Another example of the differences we see in struct uname:  Some
vendors use the "release" and "version" fields to convey major release
and build/patch numbers for their implementation, while others use them
to hold the release identifiers for the porting base from which their
implementation was derived.  I've seen very different versions of a
vendor's operating system both identified as "3.2.2".  Other vendors
change the "version" field for each upgrade of the OS.

	Chuck Karish		karish@mindcraft.com
	Mindcraft, Inc.		(415) 323-9000


Volume-Number: Volume 23, Number 12