From: "Karl O. Pinc" <kop@meme.com>
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 11:42:57 -0500 [thread overview]
Message-ID: <1237912977l.501l.10l@mofo> (raw)
In-Reply-To: <20090324154617.GA16332@auslistsprd01.us.dell.com> (from Matt_Domsch@dell.com on Tue Mar 24 10:46:17 2009)
My thoughts on the subject; from someone who is not
particularly qualified to have opinions.
Reading over your post, I searched for a single sentence describing
the problem you're trying to solve. What I came up with was
this:
On 03/24/2009 10:46:17 AM, Matt Domsch wrote:
> Users continue to have to figure out, for each system type
> and
> potentially for each boot, which NIC is connected to which name. This
> has been the #1 customer complaint about Linux on Dell servers for
> several years. I'd prefer not to keep it this way.
Perhaps a little magic in the udev rule that creates the
z70_persistent-net-rules file would solve the basic problem.
It could sort the nics by mac address when creating the
names. It need only run when the z70 file does not exist.
I presume this would produce consistent results in most cases
and it feels technically feasible; although I am not
fully qualified to make that judgment.
Rather that put the onus on udev to make the above
change Dell could just run a little program at first
boot that mungs the z70 file as desired. (It could then
force a reboot; I forget if this would be needed.)
I imagine Dell boots the boxes once at the factory,
but if not then the user has to suffer with a longer
boot process at first boot. Because this is driven
by Dell, Dell would know exactly what nic has what
name. And Dell knows what nics are on the mobo and
what are not, and so can control the mac address sort
order as desired.
The other solution that screams out at me is to ditch
those legacy BIOSes and go to something like LinuxBIOS.
Again, I'm not really qualified, but it sure feels like
there's an answer in this approach.
The other point that struck me was that sometimes, it seems,
users want persistence in the naming of their network devices
and sometimes they want device names based on bus position.
The sucky thing is that symlinks and nics don't mix well
and so it seems impossible to satisfy both the above
requirements at the same time. This is an area that
IMHO could be better addressed by the Linux community.
Karl <kop@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
next prev parent reply other threads:[~2009-03-24 17:14 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
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 [this message]
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=1237912977l.501l.10l@mofo \
--to=kop@meme.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).