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
