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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 16 Oct 2006 11:56:29 -0400 (EDT),
Alan Stern <[email protected]> wrote:

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

I think we're talking about the same thing :)

> 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.

If dev->driver has not been set and symlink creation failed, we'll end
up with an unbound but registered device. Maybe the same should happen
if dev->driver had been set before (register the device but reset
dev->driver to NULL)?

> 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.

Agreed.
 
> 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().

I'll do a new patch series tomorrow.

-- 
Cornelia Huck
Linux for zSeries Developer
Tel.: +49-7031-16-4837, Mail: [email protected]
-
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]
  Powered by Linux