[lkml]   [2006]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Patch 3/3] Driver core: Per-subsystem multithreaded probing.
    On Mon, 16 Oct 2006, Cornelia Huck wrote:

    > On Mon, 16 Oct 2006 10:59:28 -0400 (EDT),
    > Alan Stern <> wrote:
    > > That's not quite true. You could acquire dev->parent->sem always, just to
    > > be certain.
    > But dev->parent->sem wouldn't be taken in the non-multithreaded path,
    > so we would change the semantics.

    You would only be changing it for the multithreaded path, which itself is
    very new. But this is all hypothetical anyway...

    > > Some other things were left out of the patch. Since we can no longer know
    > > whether any drivers will get bound at all, device_attach() should now
    > > return void.
    > But device_bind_driver() may still return an error, if creating the
    > links failed.

    So the question is what do do if someone calls device_register() or
    device_add() with dev->driver set. If everything succeeds except for
    creation of the symlinks, should the device remain registered? The driver
    core has been vacillating about this recently. I'm not sure what the
    right answer is.

    However the kerneldoc for device_attach() should be updated to mention
    that when multithreaded probing is used, a driver might end up getting
    bound even though the return value is 0.

    Alan Stern

    P.S.: If you initialize probe_task to ERR_PTR(-ENOMEM) or something
    similar, then you could eliminate one of the calls to bus_for_each_drv()
    in device_attach().

    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: 2006-10-16 17:59    [W:0.020 / U:8.648 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site