On Mon, Sep 24, 2012 at 07:33:08PM +0100, Pete Batard wrote: > 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" Yes, you don't break existing applications, do you? > 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. Why? It was a mistake, live with it, and provide a chance for programs to adapt. To just force everyone to handle this now, without a major api change, is not ok from a library developer perspective. Why not just do this? That way all existing programs continue to work, and you can provide a way that programs can, without changing, still work properly with libusb and older library versions. Isn't that your goal as a library developer? > 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? No, I wouldn't break an API that has been used by programs. Heck, even if you didn't think it was used, it's part of your public API, and that is not something, as a library developer, you can break without a .so name change as well. > 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. No, you are forcing me to change my program to have it build with your change, you should do it the other way around. If you want programs to use your library, make it so that they don't have to be changed at all. And if I'm going to be forced to change my program, and libusbx has now shown that they don't care about their public api, well, I might as well just rewrite it to remove that dependancy completly, as it's obvious they don't know how to treat their users. greg k-h -- 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
