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 ...

And udev comes along with a mechanism to remember device-name mappings and "unscramble" things in a determinate way. And then udev gets borged by the freedesktop lot and we're waiting for vdev to be ready to replace it ?

> 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.

My suspicion is that your use case isn't all that common - well it's common enough, just a small fraction of systems. And people making "appliances" will have more control over what goes into the system - eg do their own kernels with all drivers included, and run on a limited range of hardware. Those will be far outweighed by the general purpose systems with random hardware.