From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Tue, 18 Apr 2006 08:03:03 +0000 Subject: Re: Integrate udevsettle with udevtrigger? Message-Id: <20060418080303.GA15645@vrfy.org> List-Id: References: <444421CE.3030206@kadzban.is-a-geek.net> In-Reply-To: <444421CE.3030206@kadzban.is-a-geek.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.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&kid0944&bid$1720&dat1642 _______________________________________________ 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