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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
