lkml.org 
[lkml]   [2004]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: udev is too slow creating devices
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.126 / U:0.372 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site