On 2012.07.16 22:29, Alan Stern wrote: > This means we lose one possible device address, since 1 will never be > used as the address of an external device.
I was wondering about that as well, as I anticipate the same potential issue if we switch to using 1 for root hubs on Windows. > In practice, of course, this hardly matters. My opinion as well. > Using the DeviceAddress field as a libusbx device number seems like a > perfectly reasonable thing to do. Or DeviceAddress + 1, if you prefer. > Does Windows guarantee that the DeviceAddress value is always > 0? The field is unsigned short, so yes. > Well, I suppose root hubs could be considered special cases. Certainly > for external devices there should be no expectation that the device > number will have any particular meaning. For example, it's likely to > change from one session to another if you plug in your devices in a > different order. Or if you unplug a device and then plug it in again, > it's likely to get a new number. Agreed. I think we got that question asked already, and replied that we could offer no guarantee as with regards to 2 sessions returning the same numbers (which IMO is also where having a topology call may help). >>> Getting back to the original question... Root hubs do not have device >>> addresses at all, because packets on the USB bus are never addressed to >>> the root hub. No packet sent by the host is meant for the root hub, >>> whereas every packet sent by an external device is (again, with a few >>> special exceptions in USB-3); either way there's no need for a root-hub >>> address. >> >> OK, then that means we probably can't get any descriptors for root hubs >> (at least in outside of the potential USB 3 exceptions, should they apply). > > ? I don't follow. You can get descriptors for root hubs just like > descriptors for any other hub. > > Do you mean that no 'Get-Descriptor' packet gets sent on the bus when > you ask for a root hub's descriptor? Yes, that's what I meant. > That's true... but it doesn't > prevent you from retrieving root-hub descriptors. The descriptors > simply come from the OS's driver rather than from an external device. That makes sense. Should have thought this through... >> OK. Since we have no OS device number to speak of on Windows, and since >> we have to choose anyway, we may want to try to bring it closer to what >> Linux does by using 1 for root hubs as well, and just increment the >> number we pick for configured devices. > > That would be fine. As long as you're sure it won't end up giving two > devices the same number. Now that I have checked, it looks like my concern about "driverless" devices ending with 0 as the device number, and conflicting, was misplaced. "Driverless" devices on Windows do provide a device address that is nonzero. This also makes sense, since the basic usbport.sys driver of Windows will talk to the bus to fetch the device descriptors for the OS, regardless of any formal driver installation. Device number 0 is justy being used internally for enumeration, for helper device instances. Therefore, I think Windows should be OK there. Besides, unlike Linux, that uses a concatenation of bus and libusbx device number for the session id, we use a hash of the Windows device instance path, so duplication of bus:address wouldn't impact us much. There's actually long standing fixme about this in linux_usbfs.c: /* FIXME: session ID is not guaranteed unique as addresses can wrap and * will be reused. instead we should add a simple sysfs attribute with * a session ID. */ 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
