Bug 252130

I'd like to see my bios_dev_name tool, a udev helper for naming ethernet 
devices in a predictable manner, added to Fedora 8.

http://sourceforge.net/mailarchive/message.php?msg_name=20070728040323.GA25467%
40auslistsprd01.us.dell.com  describes this in detail.

ANNOUNCE: bios_dev_name 0.2, now with more SMBIOS goodness
From: Matt Domsch <Matt_Domsch@de...> - 2007-07-28 04:03
You may recall a problem several hardware manufacturers faced, where
the BIOS-given name for an ethernet device (e.g. "Gb1") didn't map to
the expected and obvious Linux device name (e.g. eth0), but instead
mapped to another name (e.g. eth1). This was highly confusing to
system admins with such hardware.

Over the past year I've developed 3 separate "fixes" - each more
generic than the last.

1) a kernel patch in 2.6.19-rc3, which implements a "pci=bfsort"
option, to force the kernel to enumerate devices in a breadth-first
manner; by default disabled on all but a few Dell and HP systems.
This is the "brute force" method, and while handy, isn't very
extensible or flexible.

2) name_eths (http://linux.dell.com/files/name_eths), a set of scripts
that modifies on-disk config files
(/etc/sysconfig/network-scripts/ifcfg-eth* HWADDR lines on Red Hat
/ Fedora systems; /etc/udev/rules.d/30-net_persistent_names rules
on SLES/OpenSuSE). This uses the BIOS PCI IRQ routing table to get
the list of embedded vs add-in devices, and assigns names to the
embedded devices first (breadth-first if there are several), then
to the add-ins, in PCI slot number ascending order (breadth-first
if there are several devices in the same slot, e.g. a multiport NIC
card) and works quite well, except in a diskless environment where
you can't read/write config files.

so now, option 3:

3) bios_dev_name (http://linux.dell.com/files/bios_dev_name) -
intended to be a udev helper. For example, something like:

KERNEL=="eth*", ACTION=="add", PROGRAM="/usr/sbin/bios_dev_name -i %k", NAME="%
c"

which, given the kernel's name for a device, retreives the
BIOS-expected name, and sets it to that. Alternately, it can be
integrated into SuSE's rename_netiface script as demonstrated in the
patch included in the release. As a udev helper, it doesn't need
config files to accomplish its work.

Right now #1 uses a hard-coded breadth-first search algorithm; #2 uses
the PCI IRQ routing table and breadth-first. #3 is the same as #2
algorithm-wise, but is written in C rather than perl/shell to be more
available as a udev helper, and it can now use additional SMBIOS table data.

Dell worked with the SMBIOS Working Group on a proposal, included in
the latest SMBIOS version 2.6 DRAFT [1], to add explicit BIOS device
naming assignments to the SMBIOS tables. This will let the OS query
SMBIOS directly to find out the name a given device "should" have
(from the BIOS perspective). Version 0.2 of bios_dev_name takes
advantages of this when included in the spec and implemented in system
BIOS. See extended Type 9 and the new Type 41 (obsoletes Type 10)
fields for the new data. Future Dell systems will provide this data
in their SMBIOS table implementations.

It also can read the similar HP OEM-specific SMBIOS table entries and
use those too.

It's also expected that additional device types will be handled,
rather than only ethernet devices. That'll depend on need.

bios_dev_name is released under the GNU GPL v2.
http://linux.dell.com/files/bios_dev_name/bios_dev_name-0.2.tar.gz
http://linux.dell.com/files/bios_dev_name/bios_dev_name-0.2.tar.gz.sign
GIT: http://linux.dell.com/git/bios_dev_name.git

I'd like to see this incorporated into distros ASAP so we can solve
the BIOS name != kernel name problem forever, using explicit data from
the BIOS that we've never had before. I'm also very open to including
this udev helper app into udev itself. This is applicable to i386 and
x86_64 architectures at least, likely ia64, and others that have
SMBIOS tables and/or the PCI IRQ Routing Table.

Feedback welcome.

Thanks,
Matt

[1] http://www.dmtf.org/standards/published_documents/DSP0134.pdf

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & http://www.dell.com/linux