Re: waiting for an unknown set of udev /dev entries to complete

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

On Wed, Nov 23, 2005 at 11:54:22AM +0100, Pozsar Balazs wrote:
> On Wed, Nov 23, 2005 at 08:26:15AM +0000, Scott James Remnant wrote:
> > On Wed, 2005-11-23 at 00:13 +0100, Kay Sievers wrote:
> > 
> > > Scott sent a nice patch to remove the /dev/.udev.queue directory if it's
> > > empty. That makes it pretty easy to work around this:
> > >   start udevd
> > >   mkdir -p /dev/.udev/queue
> > >   trigger uevent's in /sys
> > >   while test -d /dev/.udev/queue; do sleep 0.1; done
> > > 
> > > The last event will just rmdir() the created queue directory.
> > > 
> > There's still a potential race here: if an event arrives after you've
> > created the queue directory and finishes just as you finish triggering
> > the uevents, but before the first triggered event gets queued, the queue
> > directory will be removed and the script won't wait.  
> > 
> > Looking through the kernel code it does look like it's almost
> > impossible, as the triggering of a uevent seems to not complete the
> > write() call until it's been posted down the netlink socket.
> > 
> > Almost isn't totally though; so it's there ... but it's such a remote
> > chance that I think it's fine for now, and the only real way to avoid
> > race conditions is just not to wait and arrange your entire boot
> > sequence to be event-driven rather than serial.
> 
> I have an idea for this: after triggering all the uevents, one more 
> special event should be sent to the netlink socket, meaning that's the 
> end of the event series were are interested in. When udev sees this 
> event, and finished processing all the events _before_ this special 
> event, then we are ready to go on.
> 
> I still think, the best solution would be:
>  - udevd itself triggers all the uevents
>  - when it finished processing all these events, only then daemonizes 
>    itself.
> So the udevd startup script could be nothing more than:
>   udevd --daemon
> 
> Nice daemons always have this kind of behavior: they does not fork 
> and return immediately, but return if the daemon successfully started 
> and initalized itself. For a good example, see hald.

That's a different issue. HAL is a stateful daemon, that offers data to
userspace applications. It also reads static data and does not deal with
hardware initialization, which has a lot of corner cases. That doesn't
count for udev.

Daemon initialization has nothing to to with coldplug. Be sure, you
don't want to hardcode device replay order, or event staging into the
daemon itself and mixup complete different tasks in bootup.

And again, it just doesn't make any sense, to give up the flexibility
to exclude events from being triggered, or wait only for specific events
at a certain stage. You also want to retry failed events with the same
logic at a later stage. And there are setups, you really want to work
around nasty things without patching a daemon.

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_id\x16865&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