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

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

On Wed, Nov 23, 2005 at 07:16:58PM +0100, Pozsar Balazs wrote:
> On Wed, Nov 23, 2005 at 06:46:57PM +0100, Kay Sievers wrote:
> > 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.
> 
> Sorry, I still don't get it...
> 
> udevd receives the events, and starts to handle them in parallel.
> From that on, there are no guarantees about execution order, it all 
> depends on the linux kernel scheduler. Are there?

All events will be forked in order of arrival, not random. Events
for the same devpath will be serialized, one runs after the other.

Udevd throttles forking of childs and limits the running processes.
Later events will wait for execution, if there are already to many
in running state. If the event carries TIMEOUT, the event will run
immedediately, without queuing.

Events will not be forked, if a parent of the devpath is already
running, or the physical device event backing the device is still
running. Physical device chains in /sys/devices are all serialized
by it's devpath and run one after the other.

Another example, partition events will wait for the main block device
event to finish, so the partition can import the parents information
stored in the udev database. Therefore, the events for the main
devices will need to be triggered _before_ the partition devices and
udevd will take care of the right execution sequence.

For some events, special rules are needed, cause you want to setup all
block devices, before you setup a raid, and a lot of other crazy things
like this, especially for the not-so-common architectures and setups.

Believe me, you don't want to code that into a binary daemon and get
support calls to debug or work around this. I'm more than happy to
have all this in a few lines of shell script.

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