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

[Segher Boessenkool]

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

Right.  When I say "v2" I just mean "not 1.0.x anymore" :-)

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

That gives you hotplug for new apps.  But my concern is how does
the behaviour change for old apps, i.e. those that do not use the
new hotplug APIs?  Obviously (well, hopefully!) things stay the
same for them if the device is not (un-)plugged at all, but when
you do unplug a device the program is using, will it still get
exactly the same error codes, at the same time?

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

Agreed.


Segher