Why I say Fedora 15 could get my machine's Ethernet's name right
Fedora 15's consistent network device naming
is done by
biosdevname; its documentation implies that this is done
using information that you can also see directly with
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 when I complained
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
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
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
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 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).