Re: Integrate udevsettle with udevtrigger?

[Kay Sievers <kay.sievers@vrfy.org>]

On Mon, Apr 17, 2006 at 07:16:30PM -0400, Bryan Kadzban wrote:
> It seems to me that udevtrigger and udevsettle are strongly related
> (generate all the uevents, then wait for them to finish -- this seems
> like it's is all part of the same "task").  Therefore I don't really see
> any reason to run udevtrigger without udevsettle.  I doubt any distro's
> bootscripts are going to run the one without the other, for instance,
> but even running udevtrigger manually should (IMO) wait for events to
> settle out.
> 
> Would it make sense to anyone else to integrate the two programs, by
> adding an option to udevtrigger that would tell it to wait?

udevsettle is needed in some other cases too, like repartitioning
a disk and wait for the partition devices to be handled. Or triggering
a "uevent" for a device to update its state like a changed volume label
and wait for udev to finish updating the /dev/disk/by-* links.

> If so, I've attached one possible patch to do that, against udev-090.
> It adds support in udevtrigger (and documentation) for a --wait option,
> which when specified will cause udevtrigger to call a new do_uevent_wait
> function.  do_uevent_wait is basically the guts out of udevsettle.
> - --wait will also take an argument: the number of seconds to wait (this
> is the same option that udevsettle took).
> 
> (I basically cut-and-pasted udevsettle's code into the function; it's
> possible that something got screwed up there.  The code compiles OK for
> me, though, and it hasn't leaked any more uevents than "udevtrigger &&
> udevsettle" over ~6-8 bootups.  To check for leaks, I'm doing what
> Alexander did[1]: putting an ACTION="add" RUN+="bug" rule last,
> clearing out the /dev/bug file after the udevtrigger --wait call,
> sleeping 6 seconds, and looking for anything in /dev/bug.  Both setups
> leak events in the presence of usb-storage devices, but I think that's a
> known issue.

There are some cases where the kernel schedules work and there is
no event pending, not in the kernel and not for udev, but not all devices
are created. You need to add that logic to the stuff that depends on the
devices, like waiting for all devices mentioned in fstab or try to detect
the kernel thread that signifies the pending work, that's nothing
we can really solve in udev.

Kay


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel