Hi Yves, On 2012.05.22 19:06, Yves Arrouye wrote: > I stumbled upon libusbx when researching whether libusb would support > exposing the concept of a USB Location ID (which I am not sure is part > of a standard, but seems to be widely understood as available on > Darwin/OS X and Windows, and may be available or constructed on Linux). > It seems that the path is close to that concept.
Yes. At least on Windows we need to store such information in the private part of the device attributes, albeit as a character string. We also have a unique hash generated from the path, as a 32 bit integer. > It would be great if libusbx offered a uint32_t > get_usb_location_id(libusb_device *dev) function whose result would > match the location IDs used by the underlying OS (whether it's obtained > directly, as should be possible---I think remembering that the Darwin > support relies on location IDs to distinguish devices; or whether it's > synthesized). Because location ID is a concept supported across OSes (at > least two here) my preference would be to be able to get the OS value > whenever available. Well, unless we use the hash, which is something we could factorize as a common unique device ID across all backends (and which we may very well have to do when we add hotplug), but which would be specific to libusbx and not exactly reusable with the OS APIs, using an uint32_t is probably going to be a bit too limiting. At least on Windows, matching the location usually requires a full fledged string. So I guess get_usb_location_id would have to return a void* or an int_ptr_t, that can then be cast to the data type that the OS actually uses. This may also present additional challenges in case this data needs to be allocated by the library, but nothing that seems insurmountable. > The reason I personally want this is that I am writing a Darwin > application that communicates with a daemon managing some USB devices > through libusb. The daemon right now uses its own dynamic numbering of > devices, and so my application cannot reliably map a detection of a > device to an identifier for that device for the daemon (and if one > inserts devices nearly simultaneously this becomes worse). If both the > daemon and my app could rely on location ID as a way to uniquely > identify a device at that point, we could communicate. I am aware of at least one implementation that simply took a look at the private part of the libusb(x) device struct (which is supposed to be opaque) and just remapped a copy of that struct to pick the items that were of interest for the app. Of course, this is not a solution we would encourage, as we may change the structure without notice, and anything you do with what is very much intended to be an opaque item is 100% unsupported. But if this is a blocking item for you, simply duplicating the private structure may work. This being said, we have had some discussions in the past about providing access to OS/backend specific parameters, though these were mostly aimed at initialization. > I could make my > app dependent on libusbx but there is not really a reason and I need hot > plug support which is not here yet I think, Alas not. There's still some backlog to go through before we can look at hotplug. There is an hotplug branch in libusbx-pbatard though [1], that is intended for Linux, Darwin and Windows, but it is in long need of an update. > and location ID is a useful > concept to bridge identification between libusbx apps and other apps? Except that if we start to have to support each custom implementation of hotplug in one way or another, I fear that we're going to take time away from officially implementing hotplug... > It seems to me that location ID is worth being part of the topology > information, and offers a reliable way to identify a device on both the > libusbx side of things and the native OS side too. I wouldn't exactly call it as part of the topology, as topology data is intended to be the same regardless of the OS/backend used. What you are asking for is really OS data. However I tend to agree that we may want to investigate the idea of providing such a feature to our users, but with the added twist that I would say this is really a feature that belongs to the 2.0 branch, which is the one that will also implement hotplug, rather than one that we should rush into 1.0. I have now created Trac ticked #24 [2] against v2.0, so that we can decide whether we want to add such a feature then. Unfortunately, 2.0 is likely to be some time away. Regards, /Pete [1] http://libusbx.git.sourceforge.net/git/gitweb.cgi?p=libusbx/libusbx-pbatard;a=shortlog;h=refs/heads/hp [2] https://sourceforge.net/apps/trac/libusbx/ticket/24 ------------------------------------------------------------------------------ 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
