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
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
