:: Re: [DNG] How to stop udev from re-…
Top Page
Delete this message
Reply to this message
Author: Rainer Weikusat
Date:  
To: dng
Subject: Re: [DNG] How to stop udev from re-ordering devices
Simon Hobson <linux@???> writes:
> Rainer Weikusat <rweikusat@???> 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.