Ah, another Monday. And another great day for more baseless Windows bashing/Windows inaccuracies, as spread by Peter...
On 2012.07.16 12:29, Peter Stuge wrote: > 255 is an arbitrary value that Pete chose to assign to root hubs > in the Windows backend, and is not a valid device address per the USB > spec. I didn't realize that 255 was invalid, but can easily fix the source to use 127 instead. HCD hubs used to be have address 0 with old enum and this was changed to 255 with new enum because more convenient. Obvsiously, since nobody complained about it, it's probably because it has yet to negatively affect libusb/libusbx users in any way. I actually wouldn't mind having some kind of harmonizing here, which will require looking more closely at whether other plaforms always use the 1 address for root hubs (as well as sorting out *BSD - see below). I'll probably log an enhancement request to do just that. > On other operating systems the kernel API that backends use > expose root hubs like if they were external hubs, so there no address > is invented. I suggest you take a look at what *BSD does. Whether root hubs are accessible or not, and unlike what is the case with other backends, including Windows, they're not exposed at all in libusb/libusbx (just issue a listdevs to see it). Also, root hubs are exposed on Windows. Might want to be careful with trying to prove a point using generalizations that don't stand scrutiny. > I'm sure Microsoft allows the same port manipulation, but they don't > expose the root hub as if it was an external hub, They do. We get two devices: one for the HCD and one for the root hub, and we can issue limited calls to these hubs just like other hubs (at the very least, we use IOCTLs to locate their children). I also think it may be possible to replace the driver with WinUSB or whatever, as it the case for regular hubs, but I don't recall trying that. Still, in the now obsoleted HID branch, I had a version of libusb that included limited access for hubs [1] (added open/close calls, which we don't have in libusb/libusbx master), to allow libusb/Windows to query hubs for (cached) descriptors. Again, don't remember trying it against a root hub (especially as I don't think the current enum tries to cache stuff for those), but at least as far as the MS API is concerned, there's nothing that really differentiate a root hub from another hub. > and since the root > hub isn't an actual USB device it doesn't have a device address. The actual issue on Windows is that concept of using a number for bus and device address is foreign, yet this is what libusb/libusbx relies on. So we actually "invent" libusbx device addresses for every device we see (not just root hubs). Therefore your statement should really be that no USB device on Windows has a device address, insofar as libusb/libusbx defines it. Or, if instead you're not talking about using numbers for device address, then a root hub very much has an address on Windows. Heck, even John's log gave it to you in plain sight: [ 0.046009] [0000181c] libusbx: debug [init_device] (bus: 1, addr: 255, depth: 0, port: 0): '\\.\USB#ROOT_HUB#4&12E21394&0' \\.\USB means it's an *actual* USB device as far as Windows is concerned. This is even more explicit if you look at the Enum section of the registry, under the USB key: all the root hubs are also instantiated there as "actual USB devices". > I think the good way is for the WinUSB backend to not fabricate a > root hub device, since it can never be communicated with anyway. First of all, please try to use an "I would prefer" instead of the "good" or "bad" absolutes that you so certainly like to abuse. History has proven that what you see as "good" or "bad" differs greatly from what others may judge as "good" or "bad", and stating that what is only your preference is "good" is akin to stating that your preference is not really a preference but the "one true way". Now, this statement is also factually wrong (or "bad", if you prefer) on two accounts: 1. As explained, we may be able to retrieve descriptors from root hubs just as we do for standard hubs. At least there's nothing in the Windows API that hints at treating root hubs differently, and Microsoft may very well provide a more comprehensive APIs for hubs in the future, so we very much want to keep root hubs listed. So the "never be communicated with anyway" is either wrong or ignoring the full picture. 2. The WinUSB backend does not fabricate a root hub device. This is done independently of WinUSB or any future backend, such as libusb0.sys, during enumeration. The root hubs we retrieve then are actual Windows USB devices which should pretty much behave like standard hubs => the "fabricate a root hub" part is also wrong, unless you want to include all USB devices, and just not the root hubs. Regards, /Pete [1] http://git.libusb.org/?p=libusb-pbatard.git;a=blob;f=libusb/os/windows_usb.c;hb=f0ae88c60b70915bfaf2091d7c833e55a5165388;js=1#l2343 ------------------------------------------------------------------------------ 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
