Messages in this thread | | | From | Benjamin Cherian <> | Subject | Re: Bug with USB proc_bulk in 2.4 kernel | Date | Mon, 17 Jul 2006 14:35:21 -0700 |
| |
Hi Pete,
> This consideration is wholly irrelevant to the pertinent topic, > because the very issue arises from devices being non-compliant. > If we want them to operate, we have to apply workarounds, which > may but us outside of the spec envelope. So I am not even going > to argue if the spec in fact mandates this behaviour.
I understand the need to apply workarounds. But here is why the spec is relevant. By applying workarounds you have *broken* the functionality of Linux with respect to the USB specification. In my opinion, workarounds should be constrained to fixing the problem rather than creating new ones.
> > 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. > > I explained why this technique is not applicable to 2.4 in the part > of the message you failed to quote. To recap, if bulk methods were > simply to drop locks with a "couple of lines of code", they would allow > control transfers to happen simultaneously with bulk transfers. > It happens to work in 2.6 only because of its string caching feature. > Indeed, Stuart Hayes of Dell reported that he can cause TEAC CD-210PU > to break under 2.6.16 in the same way it did in 2.4.27, simply by doing > "lsusb -v" instead of "cat /proc/bus/usb/devices". The issue is still > with us. Greg chose to bypass it in 2.6, instead of fixing it, due > to the amount of work involved.
Honestly, you provided very little information in your initial email. I had to dig through the kernel source to make sense of what was going on. Even for the above, I'm not understanding why "lsusb -v" causes problems under 2.6.16. Does the "-v" option cause the kernel to send control packets to the device? You have to understand that the USB driver stack under Linux is not my domain of expertise and I'm coming to you with a problem that is not of my doing. It would help a great deal to receive more details from you.
> This is a fixable issue, but it's not two lines of code. And its > impact is very limited. If you, the person who actually suffers, are > not willing to do the necessary work, then why would anyone else be? > Still, I would be happy to consider your patch, if it were to emerge.
It is really looking like you are backing me into a corner to make the change myself. However, before doing so I'd like to say that I am disappointed that the kernel developer list has not been more accommodating to this issue. I understand that this problem only affects very few people. However, please consider the spirit of what has happened here. My device adheres to the specification. In an effort to fix other devices that do not adhere to the specification you have broken my device. Then I am being asked to make modifications to the OS, when clearly this is not my domain. We all want Linux to be a primetime operating system and this sort of interaction with the developers list is *not* representative of that desire.
Besides, the device that is being broken is a 10x CD-ROM drive! Who even uses these anymore? :-)
Regards,
Benjamin Cherian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |