API for hotplug (was Re: ETAs for libusbx operability and first release?)

[Hans de Goede]

Hi,

On 01/30/2012 10:15 PM, Segher Boessenkool wrote:
>>>> 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?
>

To me version numbers say something about ABI stability, so:

1.0.x, ABI compatible to original libusb-1.0, may introduce new symbols for
        some minor new functionality, so code compiled against it does
        not necessary run with the original libusb-1.0

1.2.x, Like 1.0.x, but may introduce major new features like hotplug.

2.x.x, ABI and possibly API incompatible version, with presumably major new
        features.

But as Vitali said lets cross this bridge when we get there.

> 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.

As the author of a piece of software which already does hotplug +
libusb by using libudev for the hotplug part I disagree :)

All we need is for the user to be able to register 3 new callbacks:
-one for a new device
-one for a device going away (for apps that keep a list of devices)
-one for an open device going away

The 3th one is needed since currently there is no way to get notified
if a device goes away when there is no IO pending to it.

The callbacks can be driven from the current pollfd functionality for
Linux / Mac OS X.

Unrelated: Currently what I do for libusb + windows is have a
separate thread call libusb_handle_events() in a loop, and my callbacks
are aware that they are running in a different thread.

>> 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.

As I've stated before it is my intend that we stay compatible with libusb
in the sense that apps build against / written for libusb should just work
with libusbx. Since we are planning on adding a lot of new features the other
way around is impossible, which is fine.

Regards,

Hans