lkml.org 
[lkml]   [2004]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: udev is too slow creating devices
    On Tue, Sep 14, 2004 at 04:04:09PM -0700, Greg KH wrote:
    > On Wed, Sep 15, 2004 at 12:47:31AM +0200, Andrea Arcangeli wrote:
    > > On Tue, Sep 14, 2004 at 02:51:22PM -0700, Greg KH wrote:
    > > > True, so sit and spin and sleep until you see the device node. That's
    > > > how a number of distros have fixed the fsck startup issue.
    > >
    > > that's more a band-aid than a fix (I can imagine a userspace hang if the
    > > device isn't created for whatever reason), if there's no way to do
    > > better than this if you've to run fsck (or if it's not the best to run
    > > the fsck inside the dev.d scripts), then probably this needs better
    > > fixing. is such a big problem to execute a sys_wait4 to wait the udev
    > > userspace to return before returning from the insmod syscall?
    >
    > But how do you know what to wait for?

    the kernel sure can know about it, by passing a waitqueue into the
    registration routine and calling wake_up once the discovery is over.

    > Sitting and waiting is a band-aid, I agree. That's why we created the
    > /etc/dev.d/ notifier system to fix this issue (that is there for systems
    > that don't even use udev.)

    if the fsck can run from there ok, if for some reason it's not feasible
    to run it from there (like if it would create a bus congestion by
    running all the fsck in parallel if you attach multiple devices at the
    same time), and/or you need some other seriaization, then probably
    having a way to run things serially without a
    spin-and-sleep-and-risk-to-hang could be needed. I guess in the worst
    case one could serialize things by using file locking in /var/run
    and by creating an API between the dev.d and the init.d scripts, is that
    how the long term is supposed to work?

    So it's more a question if the current interface is complete for all
    usages, and if the fsck spin-and-sleep is just a temporary band-aid, or
    if the spin-and-sleep is supposed to last longer than a few month
    release cycle.

    (and I'm not a udev guru, just in listen mode ;)
    -
    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.022 / U:0.564 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site