Re: [Patch 3/3] Driver core: Per-subsystem multithreaded probing.

[Alan Stern <stern@rowland.harvard.edu>]

On Mon, 16 Oct 2006, Cornelia Huck wrote:

> On Mon, 16 Oct 2006 10:59:28 -0400 (EDT),
> Alan Stern <stern@rowland.harvard.edu> 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 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/