Thanks for your long response, Peter. > > It would be great if libusbx offered a uint32_t > > get_usb_location_id(libusb_device *dev) [...] > > 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.
I double-checked the actual OS X API (the 32 bits comes from one of their samples). It seems like the underlying object is actually an OSNumber, which is a wrapper for a kernel number of 8, 16, 32 or 64 bits. Is the Windows string something that would map to a 64-bit number? It would seem it would be if I understand correctly the discussions about the device path being of depth 7 at most. > We also have a unique hash generated from the path, as a 32 bit integer. If all paths are 7-deep and all components of a path are 8 bits, maybe a 64-bit unique value is all you'd need without hashing. (I am not voicing an opinion as whichever serves the hash's purposes best.) > 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. I thought about that :) I thought there was enough value in the Location ID to actually ask for it (and I could contribute code too of course). > > 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... Location ID is not related to hot plug. If you don't have hot plugging, devices are still in a given location in the USB device tree. > 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. Why can't there be platform-independent topology and platform-dependent ways to describe a location in the topology? I think hey map to each other well, and on my Mac is seems like the Location ID is simply produced by taking the device path and putting their IDs one after another (the bus first, then port or hub etc.). The path tells you how to get to the location. I really think that those two are two faces of the same concept: the location is where I am in the USB topology that libusbx is aware of. Whether that location is represented as a path, a unique hash of that path or a reasonably short "ID" (which could have been a unique hash; it just seems that the OSes have decided to make it more friendly to human decoding given they could) it's still where a device is in that topology. I'm just arguing that taking the OS value when available is more prudent than spending time trying to reverse engineer the encoding of location ID. THAT would definitely take time away from better things. > 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. OS data might be of interest to different people. That is going to be a bigger effort (and is libusbx going to try to normalize the names of these data?) Location ID is indeed just one piece of data and since you were discussing topology I thought that was appropriate. Assuming you still think Location ID is not related to the topology effort (or is, but would be better served by the bigger "OS data" goal) then I'll probably go with the "let's peak inside the internal of the library" for now, as this means my code will be "portable" [sic] against both libusb and libusbx (until the internals run away from me, in which case I may have to see if dumping the device path into a string, 2 hex bytes at a time, ). YA ------------------------------------------------------------------------------ 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
