Simon Hobson <li...@thehobsons.co.uk> writes: > Rainer Weikusat <rweiku...@talktalk.net> wrote: >> In absences of post hoc driver shuffling, these names *are not* >> random.
[...] > You've posted a statement that says drivers are loaded in a > non-deterministic order. Therefore, in the general case where not all > interfaces are using the same driver, in the absence of something to > deal with it, the order the interfaces get their driver's loaded in > not deterministic. > Eg, if I had (say) an Intel and a Broadcom NIC - then according to > what you wrote, it's indeterminate which driver will load first. Thus > it's indeterminate whether the Intel or Broadcom NIC would get to be > eth0. The same thing with multiple SCSI interfaces - something I have > personally suffered from in the past. > > Now, if you are saying that absent udev randomising things, the kernel > will always load things in the same order - well I'll buy that. Reportedly, Linux hotplug already had the same problem. During initialization, the kernel walks through the bus or busses it finds in order to locate all devices and enables them by calling the responsible driver init routines with information about the physical devices which were found. This means the names will be stable if all needed drivers are compiled into the kernel (in absence of deliberate sabotage by the drivers themselves). If there's no compiled-in driver for some device, a so-called hotplug event is generated, either by running the program whose name is recorded in /proc/sys/kernel/hotplug with a certain set of environment variables or (if no such program is defined) by sending a uevent to netlink listeners interested in uevents. What happens then is entirely the responsibility of the userspace software processing these events. It's usually expected to load a kernel module providing a driver for the device. If these module load operations are serialized wrt each other, the names will again be stable, otherwise not. I've designed and implemented a complete hotplugging system for a Linux-based UTM appliance which took care of preserving this order in the past. But apparently, this idea doesn't have many fans. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng