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

[Hans de Goede]

Hi,

On 02/01/2012 05:30 AM, 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:
>
> Right. When I say "v2" I just mean "not 1.0.x anymore" :-)
>

Ok, I think it makes sense to stick to the more or less classic FOSS
versioning scheme, so:
major.minor.patchlevel

Where:
- major bumps mean ABI breakage
- minor odd means development release
- minor even means stable
- minor bumps mean ABI additions, or just that good progress has been made

I'm not saying that we must follow this model, but I think that
doing a v2 may lead to people thinking we're breaking ABI
(see my reaction for example :) .

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

The idea is indeed that behavior will not change at all for
existing apps. Note that having an unplug callback will always be racy,
so an app with hotplug support may very well see a couple of IO-s
fail with ENODEV before getting the unplug callback. One may even
get various other errors, the same happens to in kernel USB driver,
simply because often the HUB port does not see the disconnect at the
hardware level quickly enough, so the HCI may try to send a couple
of USB packets to the disconnected device, and utterly fail with
a variance of error codes.

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

Good!

Regards,

Hans