ANNOUNCE: bios_dev_name tool, 0.1 release

Matt Domsch Matt_Domsch at
Sat Dec 2 12:31:04 CST 2006

On Sat, Dec 02, 2006 at 03:25:13PM +0100, Ragnar Kj?rstad wrote:
> > 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.
> This means that if the udev helper is used on non Dell systems it may
> swap the ordering where it was not supposed to, right?

Yes.  The idea behind the udev helper is to make it platform-agnostic
and to make the device naming more deterministic.  Regardless of
system type, it'll enumerate the embedded devices first, then
enumerate the add-in devices.  It's also got a modular naming policy,
so you can have it generate names like eth_s0_1, eth_s2_1, etc. for
the first embedded port and the first port on the card in PCI slot 2
respectively.  This gets us away from the pure "ethN is wrong for my
choice of N" and more towards the way a network switch is laid out
where ports are named for Blade X Port Y which is immediately
understood by the sysadmin.  Naming based on physicality rather than
some logical abstraction.

> > 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.
> Excellent. I think this is the real fix.
> However, it's probably going to take a bit of time before this gets
> implemented both in BIOS and in the distributions. So, in the mean time:
> 1. How can the udev helper be used in a heterogenous environment with
>    some 9G Dell systems and some system from other vendors that may have
>    the another device ordering? Is the best solution to _only_ install
>    the udev helper on the 9G Dell systems (and other systems with the
>    same kind of device ordering), or is there another way?

I intend it to be useful for all systems, not just Dell 9G, and to
behave as expected on all systems. 

>   I like the approach in your kernel patch here - it will fix the
>   problems on 9G Dell automatically, make it easy to specify that
>   other systems need the same fix, and yet not create problems on
>   systems that depend on the old device ordering.

That could be wrapped around or into it, but isn't really the
direction I want to go.

> 2. Any signals that Red Hat and SuSE will pick this up? (I guess it
>    depends on #1). Only for new releases, or will there be updates for
>    existing distributions available?

This was the first time most folks at either distro had seen it, so no
word/commitment yet.  :-)

> 3. How can the udev helper be added to existing distributions. In other
>    words, how can the helper be used from anaconda and autoyast to get
>    the device ordering right during installation over the network.

That's actually exactly why I wrote it, and it's got a very small CLI
interface on top of an underlying library, exactly so it could be
incorported into anaconda's first stage loader or autoyast linuxrc.
There'a already an example of how to hook it into the SuSE
udev + rename_netiface code path in the distro-patches/sles10/
directory, but that isn't run early enough in the installer.  It needs
to be pulled into linuxrc directly. SLES{9,10} bugzilla 209107 has
been filed as an enhancement request to look at this approach.  For
RHEL5 I think we're too late, and the kernel solution is "good enough"
for now.


Matt Domsch
Software Architect
Dell Linux Solutions &
Linux on Dell mailing lists @

More information about the Linux-PowerEdge mailing list