From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Sun, 20 Nov 2005 23:53:29 +0000 Subject: Re: waiting for an unknown set of udev /dev entries to complete Message-Id: <20051120235329.GB28968@vrfy.org> List-Id: References: <20051118223045.GA28401@us.ibm.com> In-Reply-To: <20051118223045.GA28401@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Sun, Nov 20, 2005 at 09:10:35PM +0100, Pozsar Balazs wrote: > On Sun, Nov 20, 2005 at 07:03:57AM +0100, Kay Sievers wrote: > > On Fri, Nov 18, 2005 at 02:30:45PM -0800, Patrick Mansfield wrote: > > > Any ideas on the best way to wait for udev to finish handling a set of > > > hotplug events? > > > > I have changes in my udev tree, to export the udevd event queue. It > > will probably be in 076 - if it works as expected. For every queued > > or running event, a symlink in /dev/.udev/queue/ is created and removed > > after the udev event process has exited. For all failing udev events, > > the queue files are moved to /dev/.udev/failed. > > > > We want this for coldplug after bootup, to try to trigger failed events > > again, if requirements are fulfilled only at a later stage of the boot > > process. > > What failed events do you think of? I suppose you really need this for > some cases, and I can't imagine what it is. For checkpointing the boot process. Simplest example is that programs needed for some devices to set-up are not on the root filesystem. These events will fail, cause RUN will fail with the coldplug calls. The failed events can be tried again, after the localfs's are mounted. We will see what weird things we will need to work around, to support all the insane options people invented in the unix history. > Side note about coldplug: wouldn't it be nicer if udevd would: > - trigger all events using the uevent files under /sys > - wait for these events to arrive and to finish > - _then_ fork and daemonize itself. That would make no difference, besides hardcoding the event trigger order into the daemon. > This would mostly eliminate the need to hack ugly scripts around udev to > watch its queue, wait for devices on boot etc. Well these scripts are not ugly, it's pretty simple and flexible. Be sure, we have much uglier things to handle and we will need the flexibility and control over the event generation. Kay ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&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