ANNOUNCE: bios_dev_name 0.2, now with more SMBIOS goodness

ANNOUNCE: bios_dev_name 0.2, now with more SMBIOS goodness

[Matt Domsch]

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¿sort"
   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 & www.dell.com/linux

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
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

Re: ANNOUNCE: bios_dev_name 0.2, now with more SMBIOS goodness

[Matt Domsch]

On Fri, Jul 27, 2007 at 11:03:23PM -0500, Matt Domsch wrote:
> 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.

[snip]

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

Any thoughts on this?
-Matt

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
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

Re: ANNOUNCE: bios_dev_name 0.2, now with more SMBIOS goodness

[Matt Domsch]

On Mon, Aug 06, 2007 at 09:37:08AM -0500, Matt Domsch wrote:
> On Fri, Jul 27, 2007 at 11:03:23PM -0500, Matt Domsch wrote:
> > 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.
> 
> [snip]
> 
> > 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.

I'd appreciate any feedback people have on this.  I've gotten one
report of it working for someone with both Dell and non-Dell hardware
on Debian.  I think it solves a real problem, cleanly.

Thanks,
Matt

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
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

Re: ANNOUNCE: bios_dev_name 0.2, now with more SMBIOS goodness

[Greg KH]

On Mon, Aug 13, 2007 at 09:57:53PM -0500, Matt Domsch wrote:
> On Mon, Aug 06, 2007 at 09:37:08AM -0500, Matt Domsch wrote:
> > On Fri, Jul 27, 2007 at 11:03:23PM -0500, Matt Domsch wrote:
> > > 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.
> > 
> > [snip]
> > 
> > > 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.
> 
> I'd appreciate any feedback people have on this.  I've gotten one
> report of it working for someone with both Dell and non-Dell hardware
> on Debian.  I think it solves a real problem, cleanly.

I have no objection to this solution, but I'm a little unclear as to
what you want us to do about this?  Do you want to add this to the udev
tree?  If so, send a patch.

But you asked that it go into distros, and the developers here, while
some do work for distros, the proper way to achieve this is to probably
go through the different company "add a feature" request proceedure.

thanks,

greg k-h

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
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

Re: ANNOUNCE: bios_dev_name 0.2, now with more SMBIOS goodness

[Kay Sievers]

On 8/14/07, Greg KH <greg@kroah.com> wrote:
> On Mon, Aug 13, 2007 at 09:57:53PM -0500, Matt Domsch wrote:
> > On Mon, Aug 06, 2007 at 09:37:08AM -0500, Matt Domsch wrote:
> > > On Fri, Jul 27, 2007 at 11:03:23PM -0500, Matt Domsch wrote:
> > > > 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.

> > > > 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.
> >
> > I'd appreciate any feedback people have on this.  I've gotten one
> > report of it working for someone with both Dell and non-Dell hardware
> > on Debian.  I think it solves a real problem, cleanly.
>
> I have no objection to this solution, but I'm a little unclear as to
> what you want us to do about this?  Do you want to add this to the udev
> tree?

If we can avoid, we do not like to run another program for every
event, just for the case some bios would like to suggest a name. Is
there really a need to run that again and again, every time at bootup
and when a new network interface is registered?

It is all about built-in interfaces that never change, right? So this
could run once at installation time, or once when the persistent
interfaces file is created, and never after that. Is that right?

> If so, send a patch.

I think it belongs to the distro installer, not in udev. Oh, and the
tarball it's 1.5 the size of udev itself. :) It should go in its own
package.

Thanks,
Kay

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
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