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 ... 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. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
