From: Matt Domsch <Matt_Domsch@dell.com>
To: linux-hotplug@vger.kernel.org
Subject: ANNOUNCE: bios_dev_name tool, 0.1 release
Date: Wed, 29 Nov 2006 23:14:35 +0000 [thread overview]
Message-ID: <20061129231435.GA12292@lists.us.dell.com> (raw)
You may recall several months ago a problem I 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.
Since then, 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¿sort"
option, to force the kernel to enumerate devices in a breadth-first
manner; by default disabled on all but a few Dell 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.
In the future, the SMBIOS Working Group has a proposal 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). I expect bios_dev_name to
be able to take advantage of this when included in the spec and
implemented in system BIOS.
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.1.tar.gz
http://linux.dell.com/files/bios_dev_name/bios_dev_name-0.1.tar.gz.sign
Feedback welcome.
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
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CIDÞVDEV
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
reply other threads:[~2006-11-29 23:14 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20061129231435.GA12292@lists.us.dell.com \
--to=matt_domsch@dell.com \
--cc=linux-hotplug@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).