== 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
http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming]].

As it happens, my Fedora machine's Ethernet is now called _p5p1_. There
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 _em0_ or _em1_ depending
on which bit of documentation I read). It doesn't get the right name
because _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
output of _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.)