Re: udev is too slow creating devices

[Greg KH <greg@kroah.com>]

On Wed, Sep 15, 2004 at 06:51:16PM +0200, Marc Ballarin wrote:
> On Wed, 15 Sep 2004 17:45:03 +0200
> "Giacomo A. Catenazzi" <cate@debian.org> wrote:
> 
> > It is right.
> > But an option --wait would be sufficient.
> > This option will require modprobe to wait (with a timeout of
> > x seconds) that hotplug event finish (so if device is created or
> > not is no more a problem).
> > Ideally this should be done modifing only hotplug and IMHO
> > should be enabled by default.
> 
> At the moment th hotplug event finishes nothing is guaranteed. In fact,
> the device node is never created at this point. All you know is that udev
> will now *begin* to create the node. You don't know how long it will take
> or if it will succeed at all.
> As i understand, udev definitely has to be involved in this process. It
> would need a way to inform modprobe of its state.
> 
> Maybe something like an udev state could be added. The script would
> pass a cookie to modprobe, which would in turn pass it to the kernel (or
> to udevd?), which would add it to the hotplug event. udev would then place
> the cookie in a defined file that is checked by modprobe. If that cookie's
> state is set to "done" modprobe would return and the script would
> continue.
> 
> Example:
> modprobe blah -c cookie-123
> "cookie-123" is passed to the kernel and returned by all hotplug events
> this modprobe triggers.

Again, such tracking is pretty much impossible.

> udev will then place something like "cookie-123=>processing" in
> /dev/udev-state.
> modprobe is still running and will poll this file until it contains
> "cookie-123=>finished". When that happens modprobe will tell udevd to
> remove this entry and return succesfully. If the timeout is reached
> modprobe will return an error code instead.
> 
> (Of course, modprobe could handle the cookie generation internally.)
> 
> This sound complicated and requires changes in many places. Maybe there is
> an easier solution.

There is, just run your stuff off of /etc/dev.d/ and stop relying on a
device node to be present after modprobe returns.

thanks,

greg k-h