On May 24, 2013, at 11:05 AM, Sean McBride <s...@rogue-research.com> wrote:
> On Fri, 24 May 2013 10:53:22 -0600, Nathan Hjelm said: > >>>> So the question then maybe if there are any apps doing hotplug already >>>> (and thus on >>>> their own) for darwin, if there are no such apps, then we may consider >>>> simply not >>>> fixing this under darwin. >>> >>> I haven't followed this 'hotplugging' discussion much, and am not even >> sure if the term has some exact USB-specific meaning beyond the term's >> generic meaning, but anyway... >>> >>> We use the OS X IOServiceAddMatchingNotification() API to watch for >> the plugging/unplugging of the vendor/product ID that we are interested >> in. When the OS calls us back when a device is plugged in, we ask >> libusbx to reemumerate all devices. It would be nice if we could just >> pass the new io_service_t to libusbx… >> >> 1.2.0 will have a hotplug API so you won't need to do this yourself. >> Your app may not work as is with 1.2.0 due to a race between the darwin >> backend enumerating the device and your call to libusb_get_device_list() >> but I can fix it if there is a need. > > A race internal to libusbx itself? Sounds undesirable. If I continue to use > IOServiceAddMatchingNotification() myself, but don't actually call into > libusbx as a response, that should be fine, yes? Yes. As long as the response is not to immediately call libusb_get_device_list() there is no race. > In fact, I don't actually use libusbx directly at all, I use this, which in > turn uses libusbx: > > <https://github.com/labjack/exodriver> > > Sounds like it may need updating for 1.2. Ideally, yes. But in the meantime I will implement a fix for the race. > Is this hotplug API opt-in? libusbx won't start observing the comings and > goings of all USB devices by default I hope? The hotplug API is opt-in but the internal event handlers are not. Here is a short summary of the changes within libusbx: - Devices are enumerated 1) when a context is created (by libusb_init()) or 2) when connected. Devices are no longer enumerated when you call libusb_get_device_list(). - Each backend is responsible for keeping the device list of each active context up to date. In the darwin and linux backends to this handled with an event thread. - When a backend updates a context device list with either usbi_connect_device or usbi_disconnect_device a message is written on an internal libusb pipe. The message is read and the event is handled by libusb_handle_events(). Feedback on this design is greatly appreciated. -Nathan ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
