It might be worth to look at what systemd [1] and eudev [2] do here.
When 'udevadm trigger --type=devices --action=add' is performed after
the udev daemon starts executing, it looks like what happens is
basically this:
Thanks a lot for studying this. That's what I was going to do, but
I wouldn't have gotten to it before next week and you saved me a
lot of time.
On the other hand it looks like mdevd-coldplug and BusyBox' 'mdev -s'
want to access the /sys/dev/block/${major}:${minor} and
/sys/dev/char/${major}:${minor} symlinks. If it is the case that some
of these won't exist until the relevant kernel modules are loaded, and
if the device manager is expected to load them, it would mean it can't
reliably use /sys/dev.
I've done some testing and the results are definitely weird.
There are modules for which a /sys/class entry, and an appropriate
major/minor pair for mdevd to create the device node, only appear when
the module is loaded, and there's no prior uevent file to trigger
loading the module: the one I've tested it on is ppp_generic.
/sys/class/ppp/ppp/uevent only appears once you modprobe ppp_generic, at
the same time as /sys/dev/char/108:0. So even scanning /sys/class
does not guarantee you'll get events for all the modules you need.
It probably has to do with the fact that ppp_generic isn't tied to
any hardware in particular; whereas in Olivier's instance, I suspect
the hardware was already visible somewhere under /sys/bus.
The other weird thing is that landley, who actually knew all this
because he wrote this documentation:
https://landley.net/kdocs/pending/hotplug.txt
where he mentions /sys/bus/*/devices/*/dev and /sys/class/*/*/dev ,
chose to use /sys/dev/block and /sys/dev/char instead in mdev -s.
I assumed he knew what he was doing and simply duplicated functionality
from mdev -s, which was apparently the wrong thing to do.
The only explanation I see is that the canonical way of triggering
uevents changed after landley stopped being involved in sysfs and mdev.
I think this is likely, since his doc mentions the obsolete (but still
present) /sys/block hierarchy.
Anyway, I will change to what udev does; but this is annoying because
it requires a rearchitecture, so it will take some time.
With the mdev -s model, it was possible to just read from sysfs,
synthesize events, and send the synthetic events to a dedicated mdevd
instance. With the udevadm trigger model, this is not what happens:
instead of reading from sysfs and synthesizing events, the coldplugger
actually pokes the kernel, which creates real events; and the netlink
listener must be up in order to receive and process them. This means
that it does not make sense to keep the "mdevd reads from stdin"
interface; mdevd and mdevd-netlink should be merged and be a single,
netlink-listening and uevent-processing daemon, and mdevd-coldplug
should be turned into a copy of "udevadm trigger".
Sigh. These interfaces are almost as hidden, hermetic, and difficult
to work with as proprietary software.
--
Laurent
