On 2012.09.24 18:24, Greg KH wrote: > I don't think so. Remember, usbutils is the _one_ libusb package that > everyone has on their system. The fact that the libusbx release wasn't > tested with that package makes me wonder how it was tested at all.
Greg, We made the conscious decision to potentially break applications in order to stick to the USB specs exactly. We feel that an USB library that doesn't follow the specs to the letter is less trustworthy than one that does, and that keeping an erroneous attribute for historical reason it too much of a risk, as it creates a precedent for acceptable deviation from the specs. If you want a fix for usbutils, I'll send you one. And no, libusbx wasn't tested against usbutils, though it doesn't matter here, since we're not discovering a problem: we did anticipate breakage with software that relied on MaxPower. And by the way, since our testing resources are limited and we have quite a few platforms to support besides Linux, I might as well take this opportunity to ask anyone who think that they could lend a hand improve testing against RCs to join the libusbx mailing list. But the problem really is that libusb (and libusbx prior to v1.0.13) has a typo that makes it deviate from the USB specs, which left uswith 3 choices: 1. leave the typo as is, and say "It's fine to deviate from the USB specs for historical reasons, even if we know our descriptor structure is wrong" 2. allow both MaxPower and bMaxPower to be used simultaneously, which we explored for a while, through anonymous structs, but decided against, especially as it made part of #1 still apply. 3. Treat the problem as we would treat an errata from the USB specs, and declare the old way of accessing the Max Power attribute erroneous and requiring immediate fixing. To that extent, let me ask you this: if this was a typo from the specs rather than libusb/libusbx, and an errata was issued by the USB committee, would you not want to apply the errata, even if that meant possible breakage of existing apps? Unfortunately, mistakes do happen. We screwed up the header (well, libusb did, but we'll share the blame just as well) because MaxPower should never ever have been used there. Therefore we decided to treat it exactly as we would treat an errata from the specs and fix it by declaring the old way obsolete (though we did keep some provisions to keep using it). And yes, we're sorry about the fact that it can make applications accessing (b)MaxPower break, including prominent ones, but then again, we also expect applications to break when specs erratas are issued and applied. Therefore we considered that applications that are expected to have the flexibility to handle erratas from the specs should have enough flexibility to apply "erratas" from libusbx. And we also think that erratas should be applied as soon as they are detected. > And to have distros start to blame _me_ for usbutils breaking because > libusbx changed a field of a structure in "stable" release cycle (I say > stable as I don't think they bumped the .so name of the library, did > they?) That's acting pretty rude, don't you think? Bumping to 1.1 was an option we considered (and that I actually would have preferred as well), but decided against it as we saw the fix as very straightforward, and we also tried to made sure it was prominently well documented. We introduced an API_VERSION macro for the sake allowing applications using the newer libusbx to also compile and run against old versions of libusbx or libusb if needed. Once again, please understand that what decides the content of the libusbx library and its header is the USB specs, and if we find a deviation that we can address that's what we'll do. We also made the decision to try doing that sooner, when fewer applications were expected to access MaxPower, as we think it will be even more painful to leave that for later. Regards, /Pete ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
