All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Matt Domsch <Matt_Domsch@dell.com>
Cc: 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 16:21:16 +0000	[thread overview]
Message-ID: <49C9087C.5070907@trash.net> (raw)
In-Reply-To: <20090324154617.GA16332@auslistsprd01.us.dell.com>

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.

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.

WARNING: multiple messages have this Message-ID (diff)
From: Patrick McHardy <kaber@trash.net>
To: Matt Domsch <Matt_Domsch@dell.com>
Cc: 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 17:21:16 +0100	[thread overview]
Message-ID: <49C9087C.5070907@trash.net> (raw)
In-Reply-To: <20090324154617.GA16332@auslistsprd01.us.dell.com>

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.

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.

  reply	other threads:[~2009-03-24 16:21 UTC|newest]

Thread overview: 51+ 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 15:46 ` Matt Domsch
2009-03-24 16:21 ` Patrick McHardy [this message]
2009-03-24 16:21   ` Patrick McHardy
2009-03-24 16:28   ` Kay Sievers
2009-03-24 16:28     ` Kay Sievers
2009-03-24 16:38     ` Patrick McHardy
2009-03-24 16:38       ` Patrick McHardy
2009-03-24 16:40   ` Dan Williams
2009-03-24 16:40     ` Dan Williams
2009-03-24 17:00     ` Alan Cox
2009-03-24 17:04     ` Patrick McHardy
2009-03-24 17:04       ` Patrick McHardy
2009-03-24 18:51     ` david
2009-03-24 18:51       ` david
2009-03-24 21:02       ` Alan Cox
2009-03-24 23:14         ` Greg KH
2009-03-24 23:14           ` Greg KH
2009-03-24 16:42 ` Karl O. Pinc
2009-03-24 16:42   ` Karl O. Pinc
2009-03-24 17:45   ` Matt Domsch
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 17:52     ` Matt Domsch
2009-03-24 18:12     ` Bill Nottingham
2009-03-24 18:12       ` Bill Nottingham
2009-03-24 18:20       ` Scott James Remnant
2009-03-24 18:49 ` david
2009-03-24 18:49   ` david
2009-03-24 19:22   ` Matt Domsch
2009-03-24 19:22     ` Matt Domsch
2009-03-24 22:57 ` David Miller
2009-03-24 22:57   ` David Miller
2009-03-25 20:22   ` Chris Friesen
2009-03-25 20:22     ` Chris Friesen
2009-03-26 20:17     ` Dan Williams
2009-03-26 20:17       ` Dan Williams
2009-03-26 16:39   ` Matt Domsch
2009-03-26 16:39     ` Matt Domsch
2009-03-26 20:16     ` Dan Williams
2009-03-26 20:16       ` Dan Williams
2009-03-27 16:06       ` Len Brown
2009-03-27 16:06         ` Len Brown
2009-04-09 14:58   ` Matt Domsch
2009-04-09 14:58     ` Matt Domsch
2009-03-31 14:07 ` Kurt Van Dijck
2009-03-31 14:07   ` Kurt Van Dijck
  -- strict thread matches above, loose matches on Subject: below --
2009-08-05 19:50 Jordan_Hargrave
2009-08-05 21:49 ` Alan Jenkins
2009-08-06  8:15   ` Alan Jenkins

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=49C9087C.5070907@trash.net \
    --to=kaber@trash.net \
    --cc=Matt_Domsch@dell.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.