Kay Sievers wrote:
On Tue, Jun 2, 2009 at 16:05, Kay Sievers <kay.sievers@xxxxxxxx> wrote:
Version 5. I guess we should go for the signalfd stuff, it looks prett
nice. The socketpair instead of the rtsignal is also nice, it allows
us to pass back arbitrary data from finished events to the main
daemon.
Version 7. We need to handle the netlink unicast addresses, they are
not neccessarily the process pid, so we need to remember the netlink
address.
We also keep 2 workers around, and don't kill them, to handle incoming
events without forking.
Thanks,
Kay
Ok.
I think the patch breaks the settle control message. It now sends the
signal back to udevadm immediately, instead of postponing it until after
handle_inotify(), which was apparently the point.
"
Now udevadm settle will send a control message to udevd, which will
respond by sending SIGUSR1 back to the waiting udevadm settle once it
has completed the main loop iteration in which it received the control
message.
If there were no pending inotify events, this will simply wake up the
udev daemon and allow settle to continue. *If there are pending inotify
events, they are handled first in the main loop* so when settle is
continued they will have been turned into uevents and the kernel
sequence number will have been incremented.
"
Perhaps it would be simplest to reorder the main loop so that
handle_ctrl() comes after handle_inotify(). If I'm right, it could
benefit from a comment pointing out that this order is significant and
should be preserved.
That said, I don't completely understand the settle control message. I
don't get why udevadm-settle only sends it once at the start, instead of
incorporating it as part of the delay loop.
Thanks
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
