Didier Kryn <k...@in2p3.fr> writes: > Le 23/06/2016 09:05, Simon Hobson a écrit : >> Rainer Weikusat<rweiku...@talktalk.net> wrote: >> >>> >Reportedly, Linux hotplug already had the same problem. >> OK, that's what I'd have been seeing in the past then. >> >>> >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 >> Right. That explains a lot. >> So if the driver is built in then devices will be stable and >>> >determinate, if not then they won't. Which I guess means that a >>> >custom kernel with all drivers needed compiled in will have stable >>> >devices, but a general purpose one with loads of modules won't ? >>> >And as the vast majority of systems run generic modular kernels ... > > Hence the solution is simple: for random machine, edit udev rules > to assign names according to the MAC address; for mass-production > devices use a custom kernel with all drivers statically linked in the > kernel. For disks, use UUID.
That's you're preferred set of workarounds. 'Assigning names based on MAC addresses' is problematic as a MAC address is a typically programmable property of a NIC. Assigning names based on bus-location is more universally useful because this means names stick to devices unless the hardware configuration of a system changes. But the idea to encode the current bus configuration in the device names is braindead and the kernel already assigns names based on bus location. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
