Hi Alan, On Monday 02 August 2004 17:14, Alan Stern wrote: > On Mon, 2 Aug 2004, Duncan Sands wrote: > > > After the storm, silence... Does this mean that everyone is now happy with these > > patches? That's hard to believe... > > My impression was that people would be happy to have nothing more than the > part that drops the lock after issuing an URB and reacquires it later.
that was my impression too. A better (but more intrusive) way of handling dev->serialize would be to turn it into a r/w semaphore. In that case usbfs would need to take an additional lock in a few places (a spinlock would suffice). > > > in that case the urb fails, that's all. If you drop the lock before the urb is > > > submitted, it might get sent to the wrong endpoint. Consider the following: > > > (A) you drop the lock > > > (B) someone calls usb_set_configuration > > > (C) you submit the urb > > > If the new configuration happens to have an endpoint with the same pipe > > > as the one you are sending to, won't the urb be sent to it? > > > > Can someone please confirm that this problem really exists? If so, it is really > > a problem with the way the core handles things. My sparkling new start_wait_urb > > is just a work-around for it (there may be other problems it avoids too, the whole > > thing is a can of worms). Probably urbs should take a pointer to a (reference > > counted) interface, and not a pipe. > > There is indeed a problem, but it's not solved so easily. > > Consider this instead: > > (A) User process uses libusb or /proc/bus/usb/devices or whatever > to determine what the configuration is and what interfaces exist. > > (B) Someone else changes the configuration. > > (C) The first process submits an URB to one of the old endpoints. Actually, I thought of that. usbfs does indeed suffer from this problem, because it automatically claims an interface for you if you forgot to claim it yourself. This was a bad design decision IMHO, and should be changed. Imagine now that that wasn't true anymore: if you forgot to claim an interface, then usbfs gives you -EGOAWAY. Then you can do as follows: (A) set the configuration to whatever you want it to be. (B) claim an interface (C) check that the configuration is still what you set in A (if not, bail out) (D) submit your urbs Case 0. No-one else changes the configuration. Then all is well. Case 1. Someone changes the configuration between A and B. Then you will detect it in C. Case 2. Someone changes the configuration between B and C. Case 2a. It was changed to something else. Then you detect it in C. Case 2b. It was changed to something else and back again. Then the interface will no longer be claimed by you (disconnect bumps you off the interface), so your urbs will fail in D. Case 3. Someone changes the configuration between C and D. Then the interface is no longer claimed by you, so your urbs fail in D. So urbs only get sent successfully if the configuration is the one you wanted. > You can see that once (B) has happened it's already too late to fix > things, and this is _before_ you have even received the ioctl for (C)! > > Since configuration changes can happen at any time, and there's no way for > usbfs to notify a user process that a change has occurred, there's no way > to fix this problem. Not in the current framework. See above. > Perhaps usbfs could be changed to require that users claim an interface > before submitting an URBs and that users indicate the interface at the > time the URB is submitted. Then usbfs could invalidate all claimed > interfaces when a config change occurs and fail further submissions to any > of their endpoints. This would clearly require changes to libusb and > maybe even to user programs. Only now do I read this paragraph! This is already the case, except that usbfs doesn't require the interface to be claimed at the moment. I suggest printing a message when usbfs autoclaims an interface: "this feature will be removed in August 2005". And then change it in a years time. Thanks for your comments, Duncan. ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
