summaryrefslogtreecommitdiff
path: root/NEWS
diff options
context:
space:
mode:
authorScott James Remnant <scott@ubuntu.com>2009-03-10 13:00:16 +0000
committerScott James Remnant <scott@ubuntu.com>2009-03-12 10:02:37 +0000
commitbb38678e3ccc02bcd970ccde3d8166a40edf92d3 (patch)
tree77c38998c139205350553b38bc727d0790e6bb0d /NEWS
parentc2c24d4d3c8f83c5f4507bb13ba6c989f9d6ea45 (diff)
udevadm: settle - synchronise with the udev daemon
There's still a slight race condition when using udevadm settle, if the udev daemon has a pending inotify event but hasn't yet generated the "change" uevent for it, the kernel and udev sequence numbers will match and settle will exit. 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. Since the inotify event is pending for udevd when the close() system call returns (it's queued as part of the kernel handling for that system call), and since the kernel sequence number is incremented by writing to the uevent file (as udevd does), this solves the race. When the settle continues, if there were pending inotify events that udevd had not read, they are now pending uevents which settle can wait for. Signed-off-by: Scott James Remnant <scott@ubuntu.com>
Diffstat (limited to 'NEWS')
0 files changed, 0 insertions, 0 deletions