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

[Xiaofan Chen]

On Wed, Feb 1, 2012 at 3:36 PM, Hans de Goede <hdegoede at redhat.com> wrote:
>>>> 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?

I am not so sure about the "at the same time" part. I am thinking
that it probably will get the same error codes a bit later than
without hot-plugging. But who cares about ms delay since the
resolution of the unplug is probably in the ms or many ms range,
right?

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

This is why I think it will get a bit of delay compared to the
no-hotplug libusb implementation, Am I right?

-- 
Xiaofan