On 6/15/22 18:39, наб wrote:
The NOTES were not only weirdly reductionist, but also highly opinionated in the wrong direction. Yes, it's a syscall in SysIII; not in 4.4BSD. Well, in general, it exists in 4.4BSD for obvious conformace reasons. No, it doesn't "know" (and if it does, that's not relevant), historically and practically this is the broad CPU/machine type (compare uname -p on SysVr4 (=> SunOS 5 => NetBSD), which is the actual CPU model (usually)). Everywhere, ex. def., the nodename is what the BSD calls the hostname. "No standard" also speaks of sethostname(), so. Historical precedent (i.e. all implementations, save *maybe* for weirdo XENIX, who cares about weirdo XENIX) defines the hostname to be uname -n (indeed, SVr3 uname -S sets /both/ nodename /and/ sysname! that's not relevant here; SunOS gets it from the network (unless configured manually)). Someone clearly cited SysVr4's "Internet hostnames" comment w/o credit; fix that. 8-byte truncation is really quite secondary here (indeed, that's what SysVr4 does for pre-SysVr4 uname() callers that haven't been rebuilt. you will never encounter it). The hostname is not meaningless, obviously?? Also fix machine to say "hardware type", like the standard; "hardware identifier" would be hostid. I wrote six seething pages about hostid, and machine is /not/ hostid. Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@xxxxxxxxxxxxxxxxxx>
Both patches applied. Thanks! Alex
---
man2/uname.2 | 49 ++++++++++++-------------------------------------
1 file changed, 12 insertions(+), 37 deletions(-)
diff --git a/man2/uname.2 b/man2/uname.2
index fa991edfc..b0da6270b 100644
--- a/man2/uname.2
+++ b/man2/uname.2
@@ -34,7 +34,7 @@ struct utsname {
char release[]; /* Operating system release
(e.g., "2.6.28") */
char version[]; /* Operating system version */
- char machine[]; /* Hardware identifier */
+ char machine[]; /* Hardware type identifier */
#ifdef _GNU_SOURCE
char domainname[]; /* NIS or YP domain name */
#endif
@@ -57,49 +57,23 @@ is set to indicate the error.
.I buf
is not valid.
.SH CONFORMING TO
-POSIX.1-2001, POSIX.1-2008, SVr4.
-There is no
-.BR uname ()
-call in 4.3BSD.
+POSIX.1-2001, POSIX.1-2008, SVr4, 4.4BSD.
.PP
The
.I domainname
member (the NIS or YP domain name) is a GNU extension.
.SH NOTES
-This is a system call, and the operating system presumably knows
-its name, release, and version.
-It also knows what hardware it runs on.
-So, four of the fields of the struct are meaningful.
-On the other hand, the field
+The kernel has the name, release, version, and supported machine type built in.
+Conversely, the
.I nodename
-is meaningless:
-it gives the name of the present machine in some network
-to which it's attached,
-but typically machines are in more than one network
-and have several names by which they're reachable.
-Moreover, the kernel has no way of knowing
-about such things, so it has to be told what to answer here.
-The same holds for the additional
+field is configured by the administrator to match the network
+(this is what the BSD historically calls the "hostname",
+and is set via
+.BR sethostname (2)).
+Similarly, the
.I domainname
-field.
-.PP
-To this end, Linux uses the system calls
-.BR sethostname (2)
-and
+field is set via
.BR setdomainname (2).
-Note that there is no standard that says that the hostname set by
-.BR sethostname (2)
-is the same string as the
-.I nodename
-field of the struct returned by
-.BR uname ()
-(indeed, some systems allow a 256-byte hostname and an 8-byte nodename),
-but this is true on Linux.
-The same holds for
-.BR setdomainname (2)
-and the
-.I domainname
-field.
.PP
The length of the fields in the struct varies.
Some operating systems
@@ -114,7 +88,8 @@ or
.BR _UTSNAME_LENGTH .
Clearly, it is a bad
idea to use any of these constants; just use sizeof(...).
-Often 257 is chosen in order to have room for an internet hostname.
+SVr4 uses 257, "to support Internet hostnames"
+\(em this is the largest value likely to be encountered in the wild.
.PP
Part of the utsname information is also accessible via
.IR /proc/sys/kernel/ { ostype ,
-- Alejandro Colomar <http://www.alejandro-colomar.es/>
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
