On Thursday 10 February 2005 12:42 pm, Alan Stern wrote: > On Thu, 10 Feb 2005, David Brownell wrote: > > > Right. Except that all the HCDs currently handle the single-URB > > unlink scenarios, so it's seemed like a low priority. If I saw a > > good fix (that didn't lose functionality) I'd be interested. > > It's a shame the hard parts were all written before anyone decided to try > simplifying things...
Actually it'd just be a "later" simplification. If you will, removing a lot of the LK 2.2/2.4 special case logic -- simplifying things a lot, so they for example became realistically testable! -- opened the door to further possibilities, like this one. Plus, remember that my original question was whether a "kill the whole queue" primitive _would_ be a net simplification. If it weren't for the ep0 case, I think the answer would be "yes" ... though it's still not clear to me how much of one it'd be. > Calling this a "fix" gives the wrong impression. It's not that anything > is wrong now; it's that HC drivers could be made smaller and simpler. Agreed that it's not wrong. How much smaller, simpler? And how would it affect the device drivers? IMO any real win should be in letting those drivers be simpler -- all of them! -- rather than in letting a handful of HCDs get rid of a dozen or two lines of not-too-tricky code. > > - The HID driver initialization ... implements its > > own [memory-wasteful] control queuing ... > > I didn't know that. But since the driver doesn't queue its control URBs, > the change I suggested won't slow it down. If it is changed to use > queuing then it would be slowed down somewhat. Probably not too much > (don't these things tend to run at low speed anyway?) and not in a > time-critical section. It'd be a switch from queuing in the HID core to queueing lower down ... either in the HCD (current framework) or usbcore (as you noted). The reason I said this doesn't care if it's done in the HCD is that the init logic isn't speed-critical code. (I _think_ that's only used to initialize the reports...) > I suppose there could be a preprocessor flag to suppress the special > treatment for the ep0 queue in usbcore. You wouldn't want to use it for > normal operation, Actually, I think a config option here would be rather dangerous. It'd pretty much guarantee that the HCD level queueing would break, sooner or later, out of sheer disuse. > but it would permit usbtest to work -- so long as there > aren't any control queue tests that involve unlinking one URB while > keeping others active. (Now you'll probably think "Yeah, that would be a > good test!" and you'll go add it in... :-) I decided against spending time writing such a test, way back when. Takes too much time to write and debug such a beast. It'd be a fine task for some _other_ enterprising soul to take on ... ;) This is a gap in the testing framework though. Every such gap is worth filling, while examining it for bugs and misfeatures... > > - Handling malcontent devices which misbehave in the face of > > control transfers while bulk transfers are pending... > > Not a bad idea, but how does one identify such devices without provoking > a problem? I was under the impression they were all usb-storage devices.... :) The problem we had identifying them was that this almost seemed like an urban legend. (However I think the 2.4 kernel now has some logic to handle this case...) > > - Limiting how many TDs get tied up per queue with UHCI. > > ... > > One of the things on my todo list for UHCI is to limit the number of TDs > allocated per endpoint. Another thing on the list is to shrink the TD > structure itself. One reason I decided to ignore this issue at the usbcore level was that this particular UHCI thing can also be handled wholly inside the UHCI driver ... and since no other HCD seems to have that issue, such a hook wouldn't be used except by UHCI. > > Actually we could do this right now for everything except control > > transfers (on ep0), and get most of the win. Bulk transfers are > > the main use of URB queues ... originally for networking (usbnet), > > and later for mass storage (usb-storage). > > I'm not sure what you mean here. The win is that we can remove from the > HCDs all the code that takes one URB off a queue while leaving others > behind. If that code has to remain (for taking care of ep0) then there's > no win. The win should be in drivers, which can just say "kill this endpoint's queue". That could affect the usb_sg_*() stuff and usbnet ... maybe nothing else cares lately, except some endpoint_disable code in hcd.c (which, hmm, can now be moved out of the HCD glue code, up one level or just calling that new kill_queue logic). But now that usbcore tracks endpoint queues, such a "kill_queue" API could be added anyway, and it doesn't even need HCD level support. Though if such support came along later, it might simplify that routine! - Dave ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
