I haven't chimed in on this thread yet, and as the original
biosdevname author, I suppose I should. Some points of consideration,
which I had shared with Lennart and Kay when they first showed me
their work.
A) I'm glad to see someone else recognize and want to tackle
this. Doing it in udev makes a lot of sense, and will certainly
force more distros and hardware vendors to use it. RHEL6 still has
it enabled only for Dell systems, by request of (other hardware
vendors) who didn't want to inflict biosdevname on their users. We
will need a method to enable/disable on a per-vendor basis as we
added to RHEL in the udev rules that invoke (or don't) biosdevname.
The suggestion of linking in (or not) rules files won't work for a
distro-wide per-vendor configuration.
B) I have had far more positive feedback about the effectiveness of
biosdevname from Dell customers than I have negative. They love
that finally the physical external chassis labels have a direct
correlation to the Linux (and Windows Server 2012 if you're
counting) device name.
C) There are several cases that biosdevname handles that udev doesn't
(yet) - NPAR and SR-IOV at least. These are widely used in Dell
and other vendors' servers.
D) the udev scheme will run out of characters in IFNAMSIZ (you've got
at most 15 chars to work with, really less 5 because decimal-based
VLAN tagging is allowed, hence MAC-based won't fit). Once you
allow NPAR/SR-IOV you need at least 4 characters there (e.g. i254
as suffix), leaving you with 6 usable. You take 2 to define the
interface type (en,wl,ww), leaving 4 to describe the PCI topology.
Not gonna fit... And last time I looked, we can't make IFNAMESIZ
bigger, as it's kernel ABI to userspace and used in a ton of
places. This is why the biosdevname naming convention is not as
pretty as yours - there simply isn't enough space in IFNAMSIZ to do
much given the claims already on the space that we can't ignore.
"We can't solve that, so we won't" is not acceptable. Real people
use these network features every day.
E) In this thread, it has come up several times that biosdevname falls
back to an emumeration method in some cases where the BIOS
information is not present. Yes, it does, though there are command
line flags that can disable that in general (e.g. --smbios26 means
it won't trigger unless the info is present in firmware). As I've
handed of maintenance of biosdevname to a whole engineering team, I
don't know the current state of any other enumeration codepaths,
but I agree, that's a lousy way to get the "right" answer, and I'm
sure the engineering team would take suggestions on how to fix it,
rather than 'throw out the baby with the bathwater'.
F) "sane" (to a programmer) PCI bus topology is getting more and more
difficult to come by, as multiple PCI roots now hang off specific
CPUs. It will not be unusual for embedded devices to hang off the
second CPU slot, which may or may not be populated with a CPU.
We're long past the days where I can convince any motherboard
designers to physically route their boards to bring sanity to OS
device naming schemes.
So, in short, I support making Consistent Network Device Names
better. But I'm not convinced the udev proposal is the right solution.
I'd like to see an analysis of what I got wrong in biosdevname,
proposals to fix those that don't cause even more problems, and then
come to a solution. I expect Lennart and Kay have already done this,
but the only argument I keep hearing on this thread is "biosdevname
sometimes does enumeration of its own - that's evil" which is correct,
but not sufficient justification to throw it out.
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
Attachment:
pgpDCHifozasM.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
