[lkml]   [2004]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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" <> 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.


    greg k-h
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:06    [W:0.022 / U:18.052 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site