>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
Received on Sat Jan 13 2018 - 02:10:19 UTC