From: Matt Domsch <Matt_Domsch@dell.com>
To: Dave Jones <davej@redhat.com>
Cc: linux-pci@atrey.karlin.mff.cuni.cz, Greg KH <greg@kroah.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.18-rc5] PCI: sort device lists breadth-first
Date: Fri, 8 Sep 2006 11:18:17 -0500 [thread overview]
Message-ID: <20060908161817.GA12642@lists.us.dell.com> (raw)
In-Reply-To: <20060908155639.GJ28592@redhat.com>
On Fri, Sep 08, 2006 at 11:56:39AM -0400, Dave Jones wrote:
> On Thu, Sep 07, 2006 at 10:14:22PM -0500, Matt Domsch wrote:
> > Problem:
> > New Dell PowerEdge servers have 2 embedded ethernet ports, which are
> > labeled NIC1 and NIC2 on the chassis, in the BIOS setup screens, and
> > in the printed documentation. Assuming no other add-in ethernet ports
> > in the system, Linux 2.4 kernels name these eth0 and eth1
> > respectively. Many people have come to expect this naming. Linux 2.6
> > kernels name these eth1 and eth0 respectively (backwards from
> > expectations). I also have reports that various Sun and HP servers
> > have similar behavior.
>
> This came up years back when 2.6 was something new, and the answer
> then was 'bind the interface to the MAC address'.
Both Red Hat-based distros and openSuSE-based distros do something
like this with configuration files automatically. Red Hat's
anaconda/kudzu puts the HWADDR lines in the generated
/etc/sysconfig/network-scripts/ifcfg-* files. openSuSE's udev rules
puts lines in /etc/udev/rules.d/30-net_persistent_names.rules the
first time it discovers a new interface. Both methods are intended to
maintain a persistent name for each NIC, after being set up the first
time. Neither deals well with replacing one NIC with another - you
must edit the config files.
This works pretty well post-install. It doesn't work well at install
time, all the installers use the kernel's original names, and then
those names become the persistent names in the config files.
> Whilst your patch will fix the case that's currently broken (2.4->2.6),
> doesn't it offer equal possibility to break existing setups when people move
> from <=2.6.18 -> 2.6.19 ?
If they're using config files / udev rules as suggested, it shouldn't
break them.
If they're not, then yes, this could. Debian's
/etc/network/interfaces file allows use of hwaddr fields, though by
default it doesn't appear anything sets it up.
I'm open to suggestions on how *not* to break setups that don't use
the MAC addresses.
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
next prev parent reply other threads:[~2006-09-08 16:18 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-08 3:14 Matt Domsch
2006-09-08 15:56 ` Dave Jones
2006-09-08 16:18 ` Matt Domsch [this message]
2006-09-08 16:55 ` Arjan van de Ven
2006-09-11 19:36 ` Bill Davidsen
2006-09-12 3:08 ` Matt Domsch
2006-09-12 21:06 ` Bill Davidsen
2006-09-08 16:45 ` Greg KH
2006-09-08 18:20 ` Andrew Morton
2006-09-08 18:52 ` Matt Domsch
2006-09-08 18:59 ` Alexey Dobriyan
2006-09-09 9:05 ` Jeff Garzik
2006-09-09 12:11 ` Pavel Machek
2006-09-10 11:26 ` Stefan Richter
2006-09-10 13:02 ` Greg KH
2006-09-15 3:53 ` Dan Carpenter
2006-09-15 13:02 ` Matt Domsch
2006-09-16 2:39 ` Dan Carpenter
2006-09-08 3:18 Matt Domsch
2006-09-08 19:34 Matt Domsch
2006-09-09 14:37 Ragnar Kjørstad
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=20060908161817.GA12642@lists.us.dell.com \
--to=matt_domsch@dell.com \
--cc=davej@redhat.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
/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
Powered by JetHome