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

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

On Mon, Nov 28, 2005 at 11:09:55PM +0100, Pozsar Balazs wrote:
> > 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.
> 
> 
> What I still do not understand is: why do you want to emit the class/mem 
> and class/tty events first, and the block/md events last?

The md devices want all other block devices around before they are
set-up. The tty's are needed very early for all sort of tools, mem
like /dev/zero, /dev/mem, may be needed very eearly too.

The required tty and mem devices are usually part of the static setup,
copied to or created in /dev as the first action, so it may not be
needed. It's a left-over from udevstart, which started on a completely
empty /dev and wanted it around first, to be able to run tools for
other devices.

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