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).
The problem with Fedora 15's consistent network device naming
Lately I've been doing a bunch of things with a real installed Fedora 15 machine (previous experimentation has mostly been with a Live USB stick used temporarily on various machines). One result of this is that I've actually noticed the name that Fedora 15 chose to give my ethernet as a result of its switch to consistent network device naming.
As it happens, my Fedora machine's Ethernet is now called
are at least two problems with this name.
The first one is that it's wrong. Since this is an onboard Ethernet
port, it should have an
emN name (either
on which bit of documentation I read). It doesn't get the right name
biosdevname trusts the BIOS's information about what things
are and aren't onboard devices. Yes, really, despite plenty of
experience that trusting PC BIOSes for anything (or at least anything
not required to boot Windows) mostly serves as a source of comedy gold
(as long as you're at a safe distance).
The second problem is that this is a terrible name. Practically its sole virtue is that it's unique. It's not predictable (not without detailed information about the machine's bus topology and a good understanding of PCI), it's not very meaningful, and it's certainly not memorable. It's the kind of name that can only be sensibly used by programs that get it directly from the system's configuration in one way or another.
(There are a number of problems with slot based names, but one of them is that another machine with a different motherboard (but also onboard Ethernet) might well have a completely different name because its Ethernet controller is hooked up to the PCI(E) bus in a different 'slot' and a machine with a real network card (and no onboard network) will have yet another name.)
What this means is that while the idea of consistent network device
naming may in theory be good, the tools for achieving it are not yet
mature. Right now it certainly looks as if
biosdevname is terminally
naive and will frequently give wrong answers (I would guess that it gets
things wrong more often than it gets them right).
(As it happens I think that there is enough information present in the
biosdecode to deduce that the machine's Ethernet must be an
onboard device, so it's clear that
biosdevname should be able to do
better. Possibly it needs to be taught about all of the common ways
that BIOS creators get this information wrong and given heuristics for
figuring out what the real situation is likely to be.)