On 05/14/2012 01:41 AM, Pete Batard wrote:
> So, in summary, the issue is:
> - you have developed a custom solution/layer to add hotplug to libusbx,
> even as libusbx is going to officially implement the very same feature,
> internally, in a manner that is likely to be quite different from yours.
When I started the implementation, I was not aware of libusb plans
on supporting hotplug in the near future.
Our application access usb-devices.
On Windows applications can only access USB devices for
which a libusbx driver is installed.
Therefore we have to install the driver outside of libusbx.
In the future when libusbx supports hotplug feature we
plan on using it.
BTW, is the plan for libusbx hotplug feature to also install the libusb
driver ?
Our solution is open-source and available to whomever is interested.
> - when using this custom feature/layer, you are experiencing an issue,
> that may or may not manifest itself with the official libusbx hotplug
> implementation (hard to tell before we get there and time constraints
> make it difficult to try to find out in advance), but that cannot occur
> with the current non-hotplug usage of libusbx.
> - still, you would like libusbx to add a fix aimed at making your custom
> feature implementation work, regardless of whether this fix will be
> necessary when libusbx duplicates the same feature internally.
Since it's only a single patch, if needed it can be easily reverted.
I expect much deeper changes to come up when the libusbx
hotplug feature is implemented.
>
> I'm afraid that, the way I see it, you are closer to using a derivative
> version of libusbx, that you would have modified to add your own feature
> (hotplug), than using a vanilla version. As such, any request pertaining
> to a custom addon would seem better left off the official tree, until we
> get to a stage where we have hotplug implemented, through the standard
> review process.
The way I see it, this patch is the only difference between
libusbx vanilla and my tree.
>
> Now, you may argue that your hotplug solution resides outside of libusbx
> itself, and therefore that you are technically using a vanilla version
> of the library which should "just" work with your layer. However, it's
> fairly obvious to me that any hotplug solution that isn't integrated
> into libusbx is likely to encounter issues, as it needs close ties to
> enum (which of course is difficult to do in a layer). And this is
> exactly what you encountered here, albeit only for Windows. Thus, unless
> our goal was to provide a modular version of libusbx, so that people can
> add their own custom layer to extend it, I don't think there is much
> point adding your fix to mainline ATM, as it is really only meant to
> address a behaviour that can currently only happen if people who use
> your custom layer, and therefore install an application for which you
> should be able to provide your own patches version of libusbx.
Let us assume my application does not listen to USB device events.
Instead when it fails to open a USB device, the application asks the
user to install the device driver and press Enter when it's done.
I would still face the same problem.
Also possibly other libusbx users may benefit
from this change, as it provides a way for libusbx to support
applications that are accessing several devices. True, it
is not as nice a solution as a fully featured libusbx hotplug
feature, but it's better than "just restart your application".
(disclaimer: I am not aware of such applications)
If you feel I am wasting your time, I apologize.
That was not the purpose in sending this patch.
Thanks,
Uri.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
