mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: david@lang.hm
Cc: Ondrej Zajicek <santiago@crfreenet.org>,
	Jan Engelhardt <jengelh@computergmbh.de>,
	Michael Tokarev <mjt@tls.msk.ru>,
	Herbert Rosmanith <kernel@wildsau.enemy.org>,
	linux-kernel@vger.kernel.org
Subject: Re: renaming kernel devices [was: VIA EPIA EK: strange eth dev numbering]
Date: Sat, 04 Aug 2007 11:16:21 +0200	[thread overview]
Message-ID: <46B443E5.2020404@s5r6.in-berlin.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0708032127010.6905@asgard.lang.hm>

david@lang.hm wrote:
> On Fri, 3 Aug 2007, Stefan Richter wrote:
>> There is a variety of possible naming schemes:
>>
>>  - Naming by order of discovery.
>>  - Naming by vendor/model name strings.
>>  - Naming by universally unique identifier.
>>  - Naming by topology.
>>  - ...
>>
>> Only the simplest of these schemes (naming by order of discovery)

(which is in most cases also the scheme that's the least useful to
admins and users)

>> is hardwired into the kernel portion of the Linux OS.  The other naming
>> schemes are (or can be) implemented in the userland portion of the
>> Linux OS.
...
> I understand the flexibility that this provides, unfortunantly (IMHO)
> default udev rules (or at least what many distros are shipping by
> default) changes from this simple naming scheme in a way that hides the
> fact from the user. This means that many users will not even realize the
> change in policy until the hardware changes and things don't act the way
> they were expected to. In my case it was removing 3 quad cards from a
> machine and finding that there was no eth0 on the box, instead there was
> a eth12, this is fairly benign. what would have caused me significant
> problems would have been having a card fail in a production box, have it
> replaced and then found that the interfaces were now eth4-eth22 instead
> of eth0-eth18. having the interfaces named differently on different
> boxes with identical hardware based on the history of what has been
> plugged into the boxes in the past is not what sysadmins expect.

Yes, these rules by far don't fit everyone's needs.  People who often
use hotpluggable NICs are probably served best by MAC address based
naming.  Boxes with field replacable but otherwise fixed NICs apparently
rather need a naming scheme based on PCI/PCIe topology.  (This requires
that the topology is exposed to userspace in comparable manner across
boots and across kernel version updates.)

So, an administrator should get to choose between different well
documented naming schemes.

Also, like Jan mentioned, confusion can already be minimized by renaming
eth[0-9]+ -> net_[a-z]+ (for example, or nic[0-9]+ like Jan wrote)
rather than eth[0-9]+ -> eth[0-9]+.  That way it's clearer at all times
whether the original names or names given by userspace are used.

And there should be a log message when a device was renamed.  Better
yet, like Michal wrote:  In case of device files for mass storage, there
is no _renaming_.  Instead, udev creates _aliases_ (symlinks), and it
does so with a few different naming schemes at once so that admins or
users immediately have a choice:
$ ls /dev/disk/
by-id  by-path  by-uuid

Any chance that there could be aliases to network interfaces?  Aliases
for device files are easy --- they live only in userspace.
-- 
Stefan Richter
-=====-=-=== =--- --=--
http://arcgraph.de/sr/

  reply	other threads:[~2007-08-04  9:17 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-02 10:20 VIA EPIA EK: strange eth dev numbering Herbert Rosmanith
2007-08-02 10:26 ` Michael Tokarev
2007-08-02 10:42   ` Herbert Rosmanith
2007-08-02 10:49     ` Jan Engelhardt
2007-08-02 10:56       ` Herbert Rosmanith
2007-08-02 11:23         ` renaming kernel devices [was: VIA EPIA EK: strange eth dev numbering] Michael Tokarev
2007-08-02 11:47           ` Jan Engelhardt
2007-08-02 12:56             ` Michael Tokarev
2007-08-02 13:30               ` Jan Engelhardt
2007-08-02 13:36                 ` Michael Tokarev
2007-08-02 14:37                   ` Ondrej Zajicek
2007-08-02 13:43                 ` Herbert Rosmanith
2007-08-02 14:51             ` Ondrej Zajicek
2007-08-03  4:45               ` david
2007-08-03 15:12                 ` Stefan Richter
2007-08-04  4:33                   ` david
2007-08-04  9:16                     ` Stefan Richter [this message]
2007-08-04 17:06                       ` david
2007-08-02 11:47         ` VIA EPIA EK: strange eth dev numbering Jan Engelhardt
2007-08-02 12:00           ` Herbert Rosmanith
2007-08-02 12:06             ` Jan Engelhardt
2007-08-02 13:07           ` Michael Tokarev
2007-08-02 13:38             ` Jan Engelhardt
2007-08-02 18:37               ` Jan Engelhardt
2007-08-02 22:00                 ` Kay Sievers
2007-08-02 22:39                   ` Jan Engelhardt
2007-08-02 22:49                     ` Kay Sievers
2007-08-03  7:46                       ` Jan Engelhardt
2007-08-02 11:12       ` Herbert Rosmanith
2007-08-02 10:44 ` Jan Engelhardt

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=46B443E5.2020404@s5r6.in-berlin.de \
    --to=stefanr@s5r6.in-berlin.de \
    --cc=david@lang.hm \
    --cc=jengelh@computergmbh.de \
    --cc=kernel@wildsau.enemy.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjt@tls.msk.ru \
    --cc=santiago@crfreenet.org \
    /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®