From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Mon, 16 Jan 2006 12:36:05 +0000 Subject: Re: cold plugging Message-Id: <20060116123605.GA10539@vrfy.org> List-Id: References: <200601131415.30207.treeve@scarlet.be> In-Reply-To: <200601131415.30207.treeve@scarlet.be> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Mon, Jan 16, 2006 at 09:44:38AM +1100, Aras Vaichas wrote: > Alexander E. Patrakov wrote: > >Thanks, but you probably missed the point. Your loop does NOT wait for > >all events. I think that in my case the following happens: > > > >1) The script creates an empty /dev/.udev/queue directory > >2) The script causes the kernel to emit uevents > >3) udevd gets those uevents, and reacts upon them. This reaction > >involves, among other things, making device nodes and calling > >/sbin/modprobe to load new drivers. > >4) Those drivers are bound to devices by the kernel, this produces new > >uevents, go to (3). > >5) When the internal queue of udevd becomes empty, it removes the > >/dev/.udev/queue directory and the loop exits. > > > >The problem is that some modules take longer than 0.1s to detect their > >hardware, so there is a period of time longer than 0.1s with the empty > >udevd queue, after which new uevents arrive. > > > >6) such late uevents reach udevd after the loop ends, and then it may be > >too late (but it is OK for me to ignore this for my scanner). > > I had a similar problem with a USB Flash drive that had a delay in the > driver for it to "warm up". I just had a larger delay (and less cycles) in > my queue polling script and it works OK. Sure, this can happen with usb_storage. Secondary events, that arrive after a module has scheduled device creation and return immediately, have never been handled and there is no sane way to do it for udev. I'm sure we don't want to introduce another round of sleep 1 to the device management, like the nightmare we had in the past. The right way to solve that - if you really depend on these devices at all - is to have certain checkpoint during boot that have the dependency on these devices recorded. Ususal setups don't depend on scanners and such stuff to be fully initialized before you can continue with booting, you can perfectly do this asynchronously. If you depend on a usb-storage volume, you better put that in fstab and let your "localfs" boot script wait until all reuqirements are fulfilled, instead of guessing how long it could take that "all" events have finished. Thanks, Kay ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ 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