On Mon, 5 Aug 2013, Pete Batard wrote:
> > 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...
The line is clear as can be. Problematic requests created by the
user's program are the user's fault and can be fixed by the user (or
the program author -- at any rate, they aren't libusb's fault).
Problematic requests created autonomously by libusb _are_ libusb's
fault.
> I'm also curious about these problematic devices you have quirks for. Do
> you have typical examples of such devices, and what behaviour prompted
Here's one example that caught my eye: The Artisman Watchdog Dongle
(vendor ID 0x04b4, product ID 0x0526) crashes when it receives a
Get-String-Descriptor request for the iConfiguration or iInterface
strings (or maybe just one of them, I don't remember). These are
descriptors that the kernel normally caches; for this device (and a
handful of others) it carefully _avoids_ caching them.
Another example: The HP 5300/5370C scanner (vendor ID 0x03f0, product
ID 0x0701) crashes if you try to read a string descriptor using a
255-byte transfer request. Instead you have to transfer the number of
bytes specified in the descriptor's bLength. Normally the kernel tries
a 255-byte transfer first, because some devices don't like it if you
ask for less.
> 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?
The reasoning is simple: Linux does its best to work with existing
hardware, even when the hardware is not spec-compliant. Eventually
there may come a point where a device is too unreasonable to deal with,
but we try to push that as far off as possible. After all, if these
devices work with Windows then they should work with Linux.
For USB, a good rule of thumb is: Any request not sent by Windows XP
will crash some device, somewhere.
> 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
The people we deal with are users, not manufacturers. As a general
rule, the manufacturers don't listen to us. They may listen to
customers who buy millions of units, and they may listen to Microsoft,
but very few of them listen to Linux kernel developers.
> 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.
That kind of attitude doesn't work out in the real world. It only
leads to people ignoring you. You can afford to do that sort of thing
if you have Microsoft's clout, but not when your user base is less than
1% of the total.
> 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?
We do it so that people can use the devices they already own. (It's
not unusual for a quirk to be written by somebody who owns one of the
devices it affects.)
Alan Stern
------------------------------------------------------------------------------
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
