[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.106 / U:4.128 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site