biosdevname conventions
Is there a particular reason this feature doesn't follow the biosdevname convetions? Could it be made to? That scheme is already in production (in Fedora and in Enterprise Linux) and is carefully designed to cover many cases (both obscure and common). --Mattdm (talk) 21:36, 18 January 2013 (UTC)
We initially intended to just make it follow the biosdevname conventions, but then ended up following the conventions set forth by udev's own /dev/*/by-path/ logic instead. The reason for that is that biosdevname in various cases makes up its own numbering scheme instead of strictly sticking to the predictable low-level topology data of the device themselves. For some cases, it enumerates things based on what is available, thus requiring that the tool runs at a point where "all" hw is already found (such a point in time does not exist in reality), and where no devices appear/are removed later on anymore. By doing that it kinda defeats its own goal. This creates real problems, like for example this one: https://bugzilla.redhat.com/show_bug.cgi?id=782145#c21 -- Note however that if biosdevname is installed it will always take precedence, this new udev-owned scheme is only the fallback if nothing else is configured. --Lennart (talk) 20:10, 23 January 2013 (UTC)
biosdevname bugs notwithstanding (which I agree need to be addressed), by removing biosdevname from the default package set, and from OS installtime via anaconda, then the systemd/udev names will become the default names. One can _later_ install biosdevname, but installtime will no longer be able to have the benefit of biosdevname, even for situations where it would be better, or desired after install completes. --mdomsch (mdomsch)) 25:00, 12 Feb 2013
Firewire (IEEE 1394) networks?
What about networks with firewire transport (PCI class 0c00 instead of 0200)? Is it simple to include those devices, too?