Re: Bug with USB proc_bulk in 2.4 kernel

[Benjamin Cherian <benjamin.cherian.kernel@gmail.com>]

Hi,

On Saturday 08 July 2006 13:28, you wrote:
> The decision to cripple the devio in this way was conscious. The problem
> scenario with 2.4.27 and earlier was how many devices would fail if
> a control and other transfer were submitted simultaneously. In other
> words, when desktop components (e.g. HAL) rescanned /proc/bus/usb/devices,
> some other devices would throw errors. The most notorious example
> would be TEAC CD-210PU, because of how widespread and popular it is.
>
> In other words, I crippled your application for the sake of a bunch
> of users of other devices. You have to realize though, that your
> concerns weren't voiced in the time and it was widely believed that
> user-mode drivers did not submit several URBs at once (primarily
> because the queueing in HCDs of 2.4 was a suspect).

I understand your decision but this does not follow the USB spec. According 
to the spec, two threads should be able to perform operations on the same 
device at the same time.

> But it seems to me that the best approach would be if you made
> a special case for bulk+bulk and locked out control transfers somehow.

This is exactly what I suggested in my first email. It just involves adding a 
couple of lines of code, but I'm not sure how the unlock function works in 
2.4. In 2.6, the device is unlocked WITHIN proc_bulk before usb_bulk_mesg is 
called and is locked after usb_bulk_mesg returns. Therefore, the device is 
still locked during control transfers.

Thanks,

Ben