On Mon, 16 Oct 2006, Cornelia Huck wrote:
> On Mon, 16 Oct 2006 10:59:28 -0400 (EDT),
> Alan Stern <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
