On Sun, Apr 24, 2011 at 02:24:08PM +0200, Tom Gundersen wrote: > On Sun, Apr 24, 2011 at 3:01 AM, Dave Reisner <[email protected]> wrote: > > This is mostly for the first patch, which allows setting UDEV_TIMEOUT=0 to > > prevent 'udevadm settle' from being called. Looking back historically, this > > seems to cause a lot of grief with a lot of hardware. Googling turns up > > things > > such as... > > > > https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/387086 > > https://bugzilla.redhat.com/show_bug.cgi?id=585527 > > http://lkml.org/lkml/2011/4/12/538 > > https://bbs.archlinux.org/viewtopic.php?id=117481 > > Why not just pass --timeout=0 to udev? Does that not work (from the > discussions I got the impression it should)? It should check the > queue and return immediately, so basically the same as not calling > udevadm at all. It seems like a reasonable workaround for those who > need it.
The end result is the same, but explicitly passing 0 will dump the contents of the event queue if it's not empty. > > > So, we're looking at both recent and less recent. Moreover, most people > > won't miss this if its disabled, as it's really just acting as a barrier > > for coldplug events to complete processing. As long as it's optional and > > documented, I think this is a reasonable thing to do. > > I think it is wrong to say that most people will not miss this. We are > not able to deal with devices that appear after udevsettle, so if the > timeout is too short some drives might not get mounted. > > I think we could support this as a hack for people who are hit by the > bugs you describe (if just passing --timeout=0 does not work), but we > should not give the impression that this is a proper fix (if ever the > timeout is reached it means something is broken...). This doesn't prevent uevents from being handled, it just removes an explicit barrier where we wait for X seconds for the queue to be emptied. Also, there's really 2 groups of people who benefit: 1) Those with problematic hardware who get stuck processing this queue to timeout. 2) Others with non-complicated setups who don't need to wait for udev to fully complete processing. They'll lose a second off their boot time, and no harm will come of this. My intention was never to advertise this as a fix for anything, which is why I didn't document it as such in rc.conf. d
