>OK, I did this, I compared what I got by reading every
>/sys/class/*/*/uevent and /sys/bus/*/devices/*/uevent file (like
>mdevd-coldplug does for /sys/dev/*/*/uevent) with what I got by
>writing 'add' to them (like udevadm trigger does) and then using
>'udevadm monitor --kernel --property' to watch the netlink events, and
>there's no difference.
Ah, but you are too late, Mr. Bond! The change was already in motion,
and all your competence cannot stop me from unleashing it upon the
world. And you will be in a prime spot to witness and experience it
firsthand, ha ha ha!
Even though it's still possible to synthesize events, I find it
cleaner, as in more architecturally correct, to let the kernel create
them. The kernel is inherently more trustworthy than any userland
process, so it loosens up the requirements on validation: there will
be no fake events, and events will all be well-formed.
The only reason why I did not do this before is that I was closely
following the "mdev -s" model, for compatibility; but if the model is
wrong, I'll switch to the "udevadm trigger" one in a heartbeat.
This also solves Olivier's secondary problem, since "start the uevent
manager first, then run the coldplug and have the existing uevent
manager pick up events" becomes the correct - and only - way to make
it work properly.
The latest mdevd git head implements those changes: mdevd-netlink and
mdevd have been merged, the mdevd-netlink binary has disappeared, and
mdevd-coldplug doesn't print anything on stdout but triggers kernel
events instead, scanning /sys/subsystem/*/devices/* when /sys/subsystem
exists and /sys/class/*/* and /sys/bus/*/devices/* otherwise.
mdevd uses the "-D fd" option to trigger readiness notification, since
the -d switch was already used.
The change is obviously incompatible with mdevd-0.0.1.0. It appears to
work for me, but please test it - especially Olivier who was missing
events with the old coldplug. If no problems are found, I'll cut the
0.1.0.0 release.
--
Laurent
Received on Mon Jan 15 2018 - 11:39:19 UTC