When our app first comes up (actually the interface layer for our apps), it uses libusb to get a list of devices that are currently on the bus. The information in that list is placed in our own internal list, filtered by the user's request to our interface layer (in that, all USB devices, devices with a specific VID, or devices with a specific VID, PID).
Upon a hot-plug event (a plug or unplug event), our layer is notified (using the various mechanisms available across OS platforms). Our layer then requests a new list of devices from libusb. We compare that list against our initial internal list. New devices are added, any devices in our list now missing are marked as unplugged, and any devices that match devices in our list that were previously marked as unplugged are now marked as present. For us, the major distinguishing item between devices is the serial number. Notifications are sent out to any listeners of our internal list and to any "owners" of the individual devices that also registered as listeners. While our layer is active, that internal list may grow, but will not shrink. When we need to access the device, we have available all the information we retrieved via the get list method in libusb to access the device through the other libusb calls. We provide two basic interfaces in the above layer (speaking from a Java point of view): A provider interface and a device interface. The provider handles getting the device list and keeping it up to date and notifying any registered listeners of list changes. Methods include (among many) getting the device list, "obtaining" a device, and attaching as a listener for list changes. Once a device is obtained, a device interface is used to communicate with that particular device (connecting, disconnecting, writing, reading, resetting, getting descriptors, attaching as a listener for plug/unplug notifications, etc). -----Original Message----- From: Pete Batard [mailto:p...@akeo.ie] Sent: Friday, May 11, 2012 11:46 AM To: libusbx-devel@lists.sourceforge.net Subject: Re: [Libusbx-devel] [PATCH] Add topology calls On 2012.05.11 19:11, Peter Stuge wrote: > philip.jos...@microchip.com wrote: >> We currently do this in a layer above libusb > > Can you tell us about how your users can use your layer? Ie. rough > details of the primitives and API offered? I'd also be curious about it. On 2012.05.11 18:46, philip.jos...@microchip.com wrote: > We also retain information for any device which is unplugged > during a "session" (any time between boots or power-up) and simply > mark it as unplugged. That's how I see it as well, with your session definition being the same as mine, even at it is bound to add some complexity as a result. If one drops the refcount, devices that may be in use still need to be accessible in one way or another, so retaining data for newly disconnected devices, and just flagging them unplugged, is likely to be the way to go. Hopefully, we'll come to overhauling enum in a few months, in the libusbx devel branch, so your comments and requests will be appreciated there. Regards, /Pete ------------------------------------------------------------------------ ------ 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 ------------------------------------------------------------------------------ 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
