On Sun, 9 Oct 2005, Pete Zaitcev wrote: > > I converted libusual to use the kthread API. > > Hmm. The new API looks promising with the explicit starting and > stopping. This is a good idea, but I have to revisit it separately.
I'm not sure that the explicit starting will help you very much. The real problem is that you don't know when the libusual module is fully loaded. The explicit stopping doesn't apply here. The probe_thread stops when it's finished, not when it's told to. As far as I can see, the real reason for using the kthread API is that it provides a slightly simpler, better maintained technique than calling kernel_thread/daemonize. > > There's not much extra overhead if you check the bias string > > every time a new device is probed. By doing so, libusual can > > react to changes made through sysfs. A new routine was added > > to handle this: usb_usual_check_type. > > I think that open-coding the comparison was wrong and usb_usual_check_type > is a better way to do it, but it is a wrong time to parse strings and > print diagnostics. So I kept the parsing where it was, but also adopted > usb_usual_check_type(). The libusual does not change usb_device_id > array on the fly anymore. Not changing the array was a notable aspect of the suggestion, although I didn't point it out. I'm glad you decided to keep that part. It's possible for driver code to be notified when the user writes a module parameter via sysfs, but it's slightly cumbersome. I can't think of any other way to change the bias without reloading the module. > > The call to up(&usu_init_notify) can be moved to the end of the > > probe_thread routine. We may as well extend the region of mutual > > exclusion over the whole routine, since most of the time a > > spinlock is held anyway. > > No, I do not like that, because I do not want request_module to be > covered with any extra locks. That thing does too much, and there may > be deadlocks if I do that. Not currently, but I do not like leaving > things like this sitting in ambush. > > It's not a lock really, just a notification done through a semaphore > because the stock completion primitive required a precise balance > between calls to notify and to test. I think that we should get rid > of it by using kthread_start. But when would you call kthread_start? What happens if the thread calls request_module too soon? Does the request fail, or does it block until the initialization function completes? If it just blocks, then the notification/semaphore isn't needed at all. > Please see the attached patch. It goes on top of what I sent yesterday. It looks good to me. BTW, it's a little surprising that the hotplug support programs can work okay with modules using external references for their usb_id tables. Do they interpret that the same as having an empty table (or no table)? I was worried at first that when any storage device was detected, the hotplug system would always load both ub and usb-storage, even though only one of them would bind to the device. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
