On Mon, 21 Aug 2017 at 09:22:22 +0100
Simon Hobson <linux@???> wrote:

[...]

> I suppose that one REALLY good way to fix the problem (at least in the
> server & desktop areas) is actually to undo a lot of "progress" and make
> all driver and service initiation strictly linear. Ie, do away with all
> this parallelism and make all drivers be loaded strictly in sequence, one
> after the other, in a defined order. I strongly suspect that it wouldn't
> hugely impact boot times either. Put another way, part of the "problem"
> being "solved" is actually a side effect of "improvements" made elsewhere.

I see some potential problems with serialization as a panacea for
interface naming.

1) How is a driver supposed to know what "queue number" it has at boot time?
"The kernel assigns it, maybe dinamically", all right, how could the
sysadmin then set his own ethernet-card-driver load order? (Suppose a
network booted system must configure it's eth0 via DHCP and then load the
NFS root filesystem out of eth1?)
2) You've got to set timeouts on ethernet drivers loading and initialization
to avoid network card B sitting indefinitely because network card A got
stuck; this could increase boot time considerably, expecially if
networking is required to boot the OS. And what eth number is B going to
get if A got stuck? The same as if A did not get stuck? Or maybe it's
going to get A's?
3) If a network card driver fails to load, how are the other ethernet
interfaces names affected? Are the following ones named just like it
loaded fine or does the naming procedure skip the failed interface?
4) What about a hardware card swap, substitution or removal, how can one know
what effect this will have on the module load sequence and interface
naming?
5) Network initialization and configuration can in some cases take a long
time (DHCP, RPC/NFS, Kerberos/NIS/LDAP/SMB and iSCSI are not
lightning-fast and might be required by other start-up steps, WiFi makes
things a lot worse of course), so serialization of multiple networking
interfaces can have a huge impact on start-up time indeed, depending on
the specific setup.

In short, networking device naming does not have to depend on load time and
sequence, and it should not. It must be predictable and configurable, but it
ought to be independend from driver load time and order. The card's MAC
address should be all that matters and dynamical interface naming should
apply only to unknown hardware that just popped up now or on this boot (and
of course it should assign only names that are not already reserved to
configured network cards, that they are present or not).


Alessandro