From: Dan Williams <dcbw@redhat.com>
To: Patrick McHardy <kaber@trash.net>
Cc: Matt Domsch <Matt_Domsch@dell.com>,
netdev@vger.kernel.org, linux-hotplug@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: Network Device Naming mechanism and policy
Date: Tue, 24 Mar 2009 12:40:58 -0400 [thread overview]
Message-ID: <1237912858.9082.39.camel@localhost.localdomain> (raw)
In-Reply-To: <49C9087C.5070907@trash.net>
On Tue, 2009-03-24 at 17:21 +0100, Patrick McHardy wrote:
> Matt Domsch wrote:
> > 2) udev may have rules to change the device names. This is most often
> > seen in the '70-persistent-net.rules' file. Here we have
> > additional challenges:
> >
> > ...
> >
> > c) udev may not always be able to change a device's name. If udev
> > uses the kernel assignment namespace (ethN), then a rename of
> > eth0->eth1 may require renaming eth1->eth0 (or something else).
> > Udev operates on a single device instance at a time, it becomes
> > difficult to switch names around for multiple devices, within
> > the single namespace.
>
> I would classify this as a bug, especially the fact that udev doesn't
> undo a failed rename, so you end up with ethX_rename. Virtual devices
> using the same MAC address trigger this reliably unless you add
> exceptions to the udev rules.
Any particular reason the MAC addresses are the same? This came up a
while ago with the 'dnet' device in the thread "Dave DNET ethernet
controller".
If the MAC address isn't a UUID for the device, then *what* is?
If there isn't one, then certainly udev can't be blamed for getting
ordering or names wrong, because there's nothing to use to actually
match up the device to a name, uniquely. Note that combinations
including bus IDs or device positions in the bus don't work for any type
of hotplug case, because you can plug another adapter into the same
location but it's a different adapter.
Either people want (a) a name assigned to a specific device (which
implies a UUID like a MAC address stored on that device somewhere
accessible to the driver at plug/boot time), or they want (b) to assign
a name to a *position* on the PCI or USB or firewire or whatever bus, or
they (c) don't care about this at all.
The answer is really 'all of the above'. Most of the people Matt cares
about are probably in the (b) camp. But most desktop/laptop users are
in the (a) camp because they use hotplug so much.
Dan
> You state that it only operates on one device at a time. If that is
> correct, I'm not sure why the _rename suffix is used at all instead
> of simply trying to assign the final name, which would avoid this
> problem.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-03-24 16:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-24 15:46 Network Device Naming mechanism and policy Matt Domsch
2009-03-24 16:21 ` Patrick McHardy
2009-03-24 16:28 ` Kay Sievers
2009-03-24 16:38 ` Patrick McHardy
2009-03-24 16:40 ` Dan Williams [this message]
2009-03-24 17:00 ` Alan Cox
2009-03-24 17:04 ` Patrick McHardy
2009-03-24 18:51 ` david
2009-03-24 21:02 ` Alan Cox
2009-03-24 23:14 ` Greg KH
2009-03-24 16:42 ` Karl O. Pinc
2009-03-24 17:45 ` Matt Domsch
2009-03-24 17:02 ` Scott James Remnant
2009-03-24 17:52 ` Matt Domsch
2009-03-24 18:12 ` Bill Nottingham
2009-03-24 18:20 ` Scott James Remnant
2009-03-24 18:49 ` david
2009-03-24 19:22 ` Matt Domsch
2009-03-24 22:57 ` David Miller
2009-03-25 20:22 ` Chris Friesen
2009-03-26 20:17 ` Dan Williams
2009-03-26 16:39 ` Matt Domsch
2009-03-26 20:16 ` Dan Williams
2009-03-27 16:06 ` Len Brown
2009-04-09 14:58 ` Matt Domsch
2009-03-31 14:07 ` Kurt Van Dijck
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=1237912858.9082.39.camel@localhost.localdomain \
--to=dcbw@redhat.com \
--cc=Matt_Domsch@dell.com \
--cc=kaber@trash.net \
--cc=linux-hotplug@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.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