On 2013.08.04 15:33, Alan Stern wrote:
>> So, provided this is all we'd need to do to avoid pollution on Windows,
>> your preference would be for libusb to cancel its established contract
>> (I think it's explicitly documented) to cache the config descriptors on
>> all platforms?
>
> Not at all. As I said above, the server should cache whatever it
> needs. If config descriptors are part of the established contract
> then the server needs them.
I was talking about a non-service implementation (i.e. modifying what we
have right now). But I guess that's part of what Hans discussed.
>>> BTW, you'd be amazed at how much trouble you can get into merely by
>>> trying to send standard requests that try to duplicate what the OS does
>>> anyway. And you'd be amazed at the hoops an OS has to jump through to
>>> get reasonable data without upsetting devices. Ths OS can't afford the
>>> luxury of crashing a device merely because that device fails to comply
>>> with the USB spec.
>>
>> Then I'd be tempted to say that what applies to the kernel doesn't
>> necessarily have to apply to a userland library... ;)
>
> True. But do you look forward to telling users: "Libusb doesn't work
> with your device because it crashes when we send it this request for
> information which we don't really need"?
Well, considering that we're not applying any quirks when a user tries
to replicate a sequence of transfers that the kernel may have quirks
for, I'd say that, right now, libusb's policy is already to let flaky
devices crash...
Granted, the difference is that, in this case, this wouldn't be
something produced by libusb itself, so we can just blame the user
("Don't do that!"). But the line between the two looks a bit blurry as
far as I'm concerned. And maybe there are quirks that we would actually
be better off trying to apply in libusb right now...
I'm also curious about these problematic devices you have quirks for. Do
you have typical examples of such devices, and what behaviour prompted
these? And, more importantly, what's the reasoning behind the kernel not
just wanting to let them crash and burn, if the issue was a poor
implementation of the specs?
I'm genuinely trying to wrap my head around why you wouldn't want to
just tell the device manufacturer "it's your problem - fix it", as I
don't really see anything but a short term goals there, that may end up
hurting users more in the long run, such as:
- Device has a ROM or can't be updated from a software app => Well,
personally, I don't see why anyone wouldn't want to rid the world of
such devices once and for all. Reported vulnerabilities won't ever be
fixed by the manufacturer and even more importantly, these devices have
no means of being repurposed by their users as they see fit. IMO, any
"smart" hardware that executes code that users cannot alter is really a
loss for the community, so the more we do to try to rid the world of
such devices, the better.
- Manufacturer considers the device as discontinued/doesn't want to
allocate devs to fix issues => similar story. Telling consumers that
hardware has an arbitrary expiration date is practice that must be
discouraged when important bugfixes are at play, and the manufacturer
has the resources to fix them. Now if the manufacturer is out of
business, or too broke, that's a different story, but considering it's
not that dissimilar to a vulnerability not getting fixed, it's a very
good opportunity to educate consumers on why they should try to avoid
hardware that runs closed source.
- Fear that users will have a poor impression of Linux if the same
hardware works OK on Windows or OS X => Again, not playing in Linux's
favour in the long run, because it basically tells manufacturers that
it's perfectly fine to ignore Linux altogether.
So I have to wonder: What am I missing? What is the reason that pushes
you guys to add quirks for flaky devices in the kernel?
Regards,
/Pete
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
