== Why I say Fedora 15 could get my machine's Ethernet's name right

Fedora 15's [[consistent network device naming Fedora15EthernetNames]]
is done by _biosdevname_; its documentation implies that this is done
using information that you can also see directly with _dmidecode_ and
_biosdecode_. Today I'm going to walk through why I think there's
enough information in my machine's BIOS information to get it right
(as I mentioned [[yesterday Fedora15EthernetNames]] when I complained
about this).

SMBIOS/DMI information comes in several different types. The biosdevname
manpage implies that what it pays attention to are information on actual
physical slots (DMI type 9) and onboard devices (specifically DMI type
41). Both of these report information that includes a 'bus address' for
each thing they are reporting on. On my machine what I see is:

 # dmidecode -t 41
 [...]
 Handle 0x0063, DMI type 41, 11 bytes
 Onboard Device
         Reference Designation:  Onboard LAN
         Type: Ethernet
         Status: Enabled
         Type Instance: 1
         Bus Address: 0000:00:19.0

 # dmidecode -t 9 | fgrep 'Bus Address'
         Bus Address: 0000:00:01.0
         Bus Address: 0000:00:1c.3
         Bus Address: 0000:00:1c.4
         Bus Address: 0000:00:1c.6
         Bus Address: 0000:00:1c.7
         Bus Address: 0000:00:1d.0
         Bus Address: 0000:00:01.0

(The two slots with the same bus address have the designations
``PCIEX16_1'' and ``PCIEX16_2''.)

So the DMI information believes that there is an onboard Ethernet
and as we expect there's nothing with that 'bus address' in the list
of physical slots.

DMI bus addresses for PCI(E) devices appear to be in the form of
'segment group:PCI bus:device.function'. To relate this to _lspci_
output, you drop the segment group; my uninformed impression is that
only complicated large server machines have complex enough PCI bus
topologies to have non-zero segment group numbers. _lspci_ says that the
sole Ethernet device is in slot 07:00.0, sitting behind a PCI bridge
at 00:1c.5 (according to '_lspci -t_', although I don't know how it
determines that), and there is no slot 00:19.

The most informative thing _biosdecode_ can tell us is the PCI interrupt
routing table (aka PIR). This table doesn't have anything for 00:19,
but it does mention 07:00:

 # biosdecode | fgrep 07:00
          Slot Entry 14: ID 07:00, on-board

So in summary: the SMBIOS claims that this machine has an onboard
Ethernet at an otherwise unknown PCI slot name, the only actual
PCI-visible Ethernet is not on or behind a SMBIOS-listed physical slot,
and the BIOS's interrupt routing claims that the Ethernet is onboard.

A program that trusts the SMBIOS (or requires that its claims validate)
will not declare the Ethernet to be an onboard one, because it can't
*prove* that. But proof is the wrong standard for consistent device
naming in the face of the contradictory evidence we have here; what you
want is the most likely and most consistent interpretation. I maintain
that the preponderance of evidence from all of this is that there is
indeed an onboard Ethernet and it is at 07:00.0.

(If you had multiple Ethernet devices you might want to be more
cautious, depending on what you could determine about the other ones,
but we don't here.)

On a side note, I looked at the _dmidecode_ and _biosdecode_ output
on a SunFire X2100 (which has four onboard Ethernet ports). None of
them were listed in _dmidecode_ but all four of them were correctly
identified as onboard devices in the PCI interrupt routing table
from _biosdecode_. My overall conclusion from this is that the PIR
is much more reliable than the DMI information, probably because
things actually care about the PIR's information and malfunction
if it isn't sufficiently correct.

=== Sidebar: sources of more information

[[The SMBIOS specification http://www.dmtf.org/standards/smbios]]
is reasonably readable, although it naturally assumes you
understand things like PCI (which I don't really). DMI is the
older standard which was apparently replaced by SMI (per [[here
http://www.dmtf.org/standards/dmi]]).