Bug 252130

Summary: add bios_dev_name udev helper for ethernet device naming
Product: [Fedora] Fedora Reporter: Matt Domsch <matt_domsch>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: kay.sievers, wwlinuxengineering
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://linux.dell.com/files/bios_dev_name/
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-08-23 16:06:47 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Matt Domsch 2007-08-13 23:22:08 EDT
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.

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="%

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.
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.


[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
Comment 1 Harald Hoyer 2007-08-14 06:00:38 EDT
> I'm also very open to including this udev helper app into udev itself.

putting Kay on CC
Comment 2 Matt Domsch 2007-08-14 08:36:20 EDT
In a comment on linux-hotplug-devel, Kay would like to see this packaged 
separately from udev, which is fine by me.  I'll prepare a package for Fedora 
and openSuSE.
Comment 3 Matt Domsch 2007-08-23 16:06:47 EDT
closing, see review of new package biosdevname, bz#254048.