On Sun, 16 Nov 2003, Duncan Sands wrote: > Hi Alan, thanks for replying. > > > I'm not nearly as familiar with the details of devio.c as you are, so I > > can't answer the points you've raised. However, you have done a very good > > job of confirming my initial statement, that locking in usbfs is full of > > errors. (And I still think we should never be using the BKL -- if > > everything else was done properly there would no need for it.) > > A quick fix involving minimal changes requires the BKL.
Minimal, yes. A somewhat larger but still relatively small change could involve substituting a private usbfs lock for the BKL. Is there any reason that wouldn't work? > I think that a proper > fix also requires a clear idea of the future of usbfs. After all, at the bottom > of it, many of the locking problems come from a mal-adapted API. One > thought I had was that the usbfs files (001 etc) could become directories. > The directory would contain a subdirectory for each interface (for the > current configuration), and each interface directory would contain an > endpoint file for each endpoint of the current altsetting. Sending an urb > to an endpoint would require opening that endpoint and writing to it (or > doing an ioctl). Configuration and altsetting changes would cause > directory contents to change. What happens if you have an open endpoint > when a change deletes that endpoint? Exactly the same thing that happens > with other file systems when you have an open file that someone else deletes: > you get to keep your copy until you close it, at which point it evaporates. The > whole interface claiming/releasing business could be eliminated by saying > (like for many device files) that endpoints can't be opened more than > once. That way, if you open an endpoint you get exclusive access to it. > To "claim an interface", you could just open each endpoint in it. If other > types of locking are required, maybe a more standard file locking method > could be used. Your ideas sound a lot like what other people have proposed. They will make a good project for 2.7. > Backwards compatibility could be maintained by allowing the traditional > ioctl's on the top-level directory (001 etc). That is an unfortunate necessity. It means that the current mess does need to be cleaned up, regardless of future development. > > So I won't tell you what to do; I'll just confirm what the rest of usbcore > > should expect. Basically, changes to the device configuration or state > > (connected vs. disconnected) may happen at any time but only under the > > protection of usbdev->serialize. In addition, creation/removal of > > interfaces (as would be caused by a configuration change) and > > binding/unbinding of drivers to interfaces require holding the driver > > model's usb subsystem rwsem. During probe and disconnect processing this > > is done automatically by the driver model core. > > Any objection to usbdev->serialize becoming a rwsem? I don't have any personal objections. Greg KH might think that's too big a change to go into 2.6.0. Why do you want to make it a rwsem? Under what conditions would multiple readers have the lock? > > Unfortunately these things are only incompletely implemented in usbcore, > > and practically not at all in usbfs. There's still a long way to go. > > Yes. In the meantime I will try to find a fix suitable for the current 2.6 freeze. Sounds good. Alan Stern ------------------------------------------------------- This SF. Net email is sponsored by: GoToMyPC GoToMyPC is the fast, easy and secure way to access your computer from any Web browser or wireless device. Click here to Try it Free! https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
