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