Didier Kryn <kryn@???> writes:
> Le 23/06/2016 09:05, Simon Hobson a écrit :
>> Rainer Weikusat<rweikusat@???> 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.