On Mon, 21 Aug 2017 at 09:22:22 +0100 Simon Hobson <li...@thehobsons.co.uk> 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
