Greg -- Greg KH wrote: > I agree. We can either use Pete's patch, or work on backporting the 2.6 > code to 2.4 (no semaphores, and any locking that is needed must be > handled by the individual drivers.)
Thanks for the pointer to Pete's patch--I did a quick search before posting but did not find this. I did not realize the problem was already so well understood. > Which do you feel is the better solution? The 2.6 idea that drivers should do their own locking is better. See linux/Documentation/Docbook/kernel-locking: "Don't hold locks during callbacks." This was a problem in the alternate uhci driver, too. Pete's patch is not the right way to do it--it is overly complex and breaks the guarantee of in order writes. A slightly better solution would be to have usbserial buffer all writes and call the lower layer usb write at a safe time--but this is wrong too. It adds an unnecessary extra buffering layer and any good usb serial driver will still need to do its own locking. I think usbserial should be a thin layer, providing necessary services and perhaps some optional extra services, but should leave the usb serial driver free to do locking, buffering, and so on as the driver requires. Too often we end up working around or fighting against usbserial, already. Providing a "safe" place for poorly written drivers is a bad idea, bound to fail, and will only hurt Linux. We should be writing good drivers and/or providing user space solutions for those who want to write simple drivers. -- Al ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
