On Sat, Aug 12, 2006 at 10:57:13AM -0400, Alan Stern wrote:
> On Fri, 11 Aug 2006, Greg KH wrote:
> > > As I see it, there's no advantage in making register_root_hub run in a 
> > > new thread.  There _is_ an advantage in making the call from the hub 
> > > driver run in a new thread, but there are also dangers.  Just as one 
> > > example, what's to prevent someone from doing "rmmod usbcore" while these 
> > > sub-threads are still running?
> > 
> > Here's an updated version that prevents that from happening.
> > 
> > I'll look into moving this further up the call chain so that the root
> > hub stuff is not affected by this.
> 
> I think the best approach would be to put the entire second half of
> hub_port_connect_change (i.e., the big loop that runs SET_CONFIG_TRIES
> times) into the sub-thread.  Then usb_new_device could be left as is,
> which will avoid problems with HCDs registering their root hubs.
> 
> To avoid the other possible problems, khubd should arrange to wait until
> all the sub-threads have ended before calling usb_unlock_device.  That's
> the main requirement: The parent hub must remain locked during the entire
> time its children are being probed.  This would mean that all the devices
> attached to a hub could be probed in parallel, but separate hubs would
> still be serialized.
> 
> Sound good?  I could work on a patch next week.

Yes, that sounds like a good idea.  A bit more complex then my simple
hack, but it probably is the "correct" one :)

thanks,

greg k-h

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to