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

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

On Wed, Nov 23, 2005 at 06:25:20PM +0100, Pozsar Balazs wrote:
> On Wed, Nov 23, 2005 at 05:50:40PM +0100, Kay Sievers wrote:
> > 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.
> 
> Well, my basic concern is not that you want flexibility via replaying 
> event outside from udev. That I can understand, though my opinion is 
> that the booting should not be special. If I am not mistaken, you are 
> trying to order the events (generated by writing to the uevent files), 
> which will be handled by udev:
>  - in parallel way

Right.

>  - in an unpredictable order

Wrong.

> What am I missing?

A clue.

> My other concern is, that there should be a nice and clean way to
> "wait until all the events are handled (which are replayed via uevents 
> on boot)". And _no_, that is not polling a directory, of whose 
> disappearence is _hopefully_ the sign. Send a signal, send a netlink, 
> whatever.

Sticking completely different things in a monolithic deamon is neighter
nice nor clean. We may end up with something pretty much different from
what we have today, but be sure, udevd will not scan sysfs and trigger
events.

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