ETAs for libusbx operability and first release?

Segher Boessenkool segher at kernel.crashing.org
Mon Jan 30 16:15:43 EST 2012


>>> For instance, if you want a hotplug proposal right after the  
>>> 1.0.9 release,
>>
>> I'd say hotplug is something for v2.
>
> I must say that I don't really like the idea of a v2, what I would  
> like
> to see is 1.0.x and master git branches, with everything going to  
> master
> first, with aggressive cherry picking to 1.0.x for fixes, and safe  
> features.

What is the difference, other than naming?

> I don't think ABI / API breakage is soemthing we should think to  
> lightly
> about. How long has it been since we moved from 0.1 to 1, and how many
> apps are still using 0.1 ? For example libgphoto2, one of our major
> users has only moved to libusb1 very recently!

Funny, I used a Linux libc1 system today.  Old stuff doesn't die.

I don't see how we can do hotplug without breaking the API, since
any device can appear, disappear and reappear at any time, while
in the 1.0 API a device can only ever disappear and that's a hard
error then.  Even if you manage to keep the same function calls
the semantics of the API will change too much, in my estimation.

But maybe it works well enough in practice.  Who knows, without
any concrete proposal.

> I'm not against an ABI breaking v2 if we have too, but I've the  
> feeling
> people are thinking much to lightly about this. If reasonably possible
> we should try to add something like hotplug to the existing v1 libusb.

I'm still not convinced it is a good idea at all to keep the libusb
version number when we aren't compatible to libusb anymore.


Segher




More information about the libusbx mailing list