Re: [PATCH v2 2/2] uname.2: deweirdify

[Alejandro Colomar <alx.manpages@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4652 bytes --]

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@nabijaczleweli.xyz>

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]