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
> I'm also very open to including this udev helper app into udev itself. putting Kay on CC
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.
closing, see review of new package biosdevname, bz#254048.