From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Lucas De Marchi <lucas.demarchi@profusion.mobi>,
linux-kernel@vger.kernel.org, Nick Piggin <npiggin@kernel.dk>,
Al Viro <viro@zeniv.linux.org.uk>, Christoph Hellwig <hch@lst.de>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Andrew Morton <akpm@linux-foundation.org>,
David Howells <dhowells@redhat.com>,
"Serge E. Hallyn" <serge.hallyn@canonical.com>,
Daniel Lezcano <daniel.lezcano@free.fr>,
Jiri Slaby <jslaby@suse.cz>, Greg Kroah-Hartman <gregkh@suse.de>,
James Morris <jmorris@namei.org>
Subject: Re: [PATCH] sysctl: add support for poll()
Date: Thu, 2 Jun 2011 13:43:38 +0100 [thread overview]
Message-ID: <20110602134338.0c56160e@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <BANLkTimcPweT-HONEtVDn3mD2a6dUGDEYA@mail.gmail.com>
> Host names are dynamic, can change during system runtime by dhcp or
> similar setups, or just get changed by the user.
I don't actually see what this has to do with utsname. uname historically
defined nodename as "name within an implementation-defined communications
network" and actually tended to be the UUCP name. Modern SuS says "`the
name of the node of the communications network to which this node is
attached, if any"
The latter unfortunately makes no sense anyway and is a fine example of
standards body cluelessness as name mapping on IP networks is not one
name per host, and also because the standard doesn't require the fields
in the struct are long enough to hold a DNS name!
(Indeed in its usual head up backside manner its technically valid to
define
char nodename[1];
and have only \0 as a valid reply)
Realistically all the naming policy has to be in userspace, and that
means that all the userspace bits have to agree on what they use utsname
for (or indeed if they are wise not use nodename in the first place) so
they can handle name management outside of kernel.
In the DHCP case for example a node which is acquiring a DHCP address on
wireless and on ethernet at the same time (very typical) has to make sure
all its DHCP and other address management policies agree rather than have
the two have a kernel food fight over the name to use.
So this all belongs in conman, network manager and other similar
systems and I'd suggest they try and deal with the meaningful IP world
questions of "what list of names do I posess for purpose X on network Y"
and "is this one of my names on ..."
> The alternative is to have a process constantly polling and reading
> the file, which is nothing we even want to think about in 2011.
Or to manage it properly.
> It's just another special case to bring us out of the UNIX stone age
> of doing things. :)
Unfortunately not. It's a misguided attempt to follow stone age Unix 'one
short name' policy. Forget utsname node names, they are a historical
quirk of UUCP and friends and on many OS platforms will be limited to 15
chars !
As to poll in general I can see some of the other proc files being
more relevant, eg for process monitoring tools being able to poll
in /proc/<pid> and some of the proc/sys and sysctl data that does change
meaningfully. Utsname however is not one of those things.
Alan
next prev parent reply other threads:[~2011-06-02 12:43 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-01 12:14 Lucas De Marchi
2011-06-02 2:51 ` Lucas De Marchi
2011-06-02 3:31 ` Eric W. Biederman
2011-06-02 12:06 ` Kay Sievers
2011-06-02 12:43 ` Alan Cox [this message]
2011-06-02 13:01 ` Kay Sievers
2011-06-02 13:02 ` Lucas De Marchi
2011-06-02 13:12 ` Alan Cox
2011-06-02 13:24 ` Kay Sievers
2011-06-02 13:56 ` Eric W. Biederman
2011-06-02 17:32 ` Kay Sievers
2011-06-08 22:17 ` Andrew Morton
2011-06-09 13:16 ` Kay Sievers
2011-06-13 16:05 ` Kay Sievers
2011-06-14 3:53 ` Lucas De Marchi
2011-06-14 4:17 ` NeilBrown
2011-07-26 2:17 ` Lucas De Marchi
2011-08-02 22:53 ` Kay Sievers
2011-08-02 23:16 ` Greg KH
2011-08-03 1:12 ` Lucas De Marchi
2011-08-03 9:40 ` Eric W. Biederman
2011-08-03 13:17 ` Lucas De Marchi
2011-08-03 18:08 ` Eric W. Biederman
2011-08-03 18:45 ` Lucas De Marchi
2011-08-04 18:57 ` Lucas De Marchi
2011-08-23 17:57 ` Greg KH
2011-08-26 21:06 ` Andrew Morton
2011-06-12 15:34 ` Eric W. Biederman
2011-06-13 14:28 ` Kay Sievers
2011-06-02 14:16 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110602134338.0c56160e@lxorguk.ukuu.org.uk \
--to=alan@lxorguk.ukuu.org.uk \
--cc=akpm@linux-foundation.org \
--cc=daniel.lezcano@free.fr \
--cc=dhowells@redhat.com \
--cc=ebiederm@xmission.com \
--cc=gregkh@suse.de \
--cc=hch@lst.de \
--cc=jmorris@namei.org \
--cc=jslaby@suse.cz \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lucas.demarchi@profusion.mobi \
--cc=npiggin@kernel.dk \
--cc=serge.hallyn@canonical.com \
--cc=sfr@canb.auug.org.au \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®