On 2013.08.04 00:51, Alan Stern wrote: > Out of curiosity, what data do you need to request from the parent hub?
Now that I've looked a bit through old e-mails, it seems that these are config descriptors, coming from a Windows IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTION request. I'll have to re-check what goes on the bus though, as we also have an IOCTL_USB_GET_NODE_CONNECTION_INFORMATION elsewhere (which provides us data such as the device connection speed). So I may be misremembering things, as the data we seem to derive from the first IOCTL isn't used for the topology, but to cache the actual config descriptor (which libusb mandates us to cache) and it looks like it's really a matter of caching our descriptors on Windows after all. > And why does requesting that data send a query to the child device for > its device descriptor? I guess that Microsoft decided that their IOCTL for the config desc should always translate as a bus request. And there is no API call I know of that would allow us to get cached data for those during enum. > That seems reasonable. How does this central server process get > established? Will libusbx fork a new process to do the work if it > can't contact an existing server? That's how I'd see it. > What happens if two libusbx > instances try to start a new central server at the same time? At least on Windows, you can get global named mutexes. And this is a fairly common problem to solve. The trickiest part, IMO, will be if the API of that process/server changes, as we may need 2 different versions of the library with 2 separate server processes running, to meet their needs. And even for non API breakage, there may be process restart required to always have the most up to date version running (bugfix, etc), still in case we have 2 different versions of the library running. Could be a bit tricky, but that's something we discussed in the past. If you plan for it, it's addressable. > This is where I (and probably Hans) disagree. The central server > should cache whatever it needs and -- on demand -- whatever clients ask > for. Nothing more, unless the server's back end can get the data > directly from the OS without any USB traffic. I simply see no point in > "polluting the bus" to get data that a client _might_ want. So, provided this is all we'd need to do to avoid pollution on Windows, your preference would be for libusb to cancel its established contract (I think it's explicitly documented) to cache the config descriptors on all platforms? > BTW, you'd be amazed at how much trouble you can get into merely by > trying to send standard requests that try to duplicate what the OS does > anyway. And you'd be amazed at the hoops an OS has to jump through to > get reasonable data without upsetting devices. Ths OS can't afford the > luxury of crashing a device merely because that device fails to comply > with the USB spec. Then I'd be tempted to say that what applies to the kernel doesn't necessarily have to apply to a userland library... ;) Regards, /Pete ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
