On Sat, 3 Aug 2013, Pete Batard wrote: > On 2013.08.03 21:18, Alan Stern wrote: > > I agree with Hans. In-library caching should be done on-demand, not > > whenever a new device is enumerated. > > > > If the program asks the library for a string descriptor, the back end > > can get the descriptor from the OS's cache, if one is available. Or it > > can talk to the device. That's up to the back end. But if the program > > doesn't ask for a string descriptor, the library shouldn't go out of > > its way to read it. > > I guess I need to get back to exposing the original problem we want to > solve, and where one byproduct of the proposed solution is that we could > implement easy caching of descriptors across all platforms. > > In the absolute, I agree with you. We shouldn't go out of our way to > cache descriptors unless they are already cached by the OS, especially > if having 2 different applications doing the caching means repeated IO > calls for the same data.
> But first let me get back to the issue we're going to have to solve. One > of the major problems we have on Windows is that we can't build > libusb-compliant enumeration information without requesting some data > from the parent hub of each device we enumerate. Unfortunately, this > ALWAYS sends a formal descriptor query to the device (for the device > descriptor if I remember correctly). Out of curiosity, what data do you need to request from the parent hub? And why does requesting that data send a query to the child device for its device descriptor? > So, to work around this, at least on Windows, we're going to have to > implement some sort of centralized process, that will act as the sole > point of entry for communications with the OS for device > insertion/removal, and that will serve up-to-date libusb enum data to > any libusb apps running on the system. This way we can ensure that enum, > and it's bus polluting IO, is limited and only occurs once for the > inserted device. > > Well, if we have that layer on Windows, which basically duplicates what > we'd like the OS to provide without having to send IO on the bus, we > might as well make that common to all OSes and use it to piggypack on > the IO that is going to occur from the OS on device insertion, to cache > actual descriptor data while we're at it. This way, we can provide a > consistent experience with regards to descriptor caching, and make apps > portable. 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? What happens if two libusbx instances try to start a new central server at the same time? > Now, we may not want to cache all descriptors (In the original mail, I > mentioned that we only wanted to cache the ones that we think our users > will request most, something that can start small, and that we can fine > tune as we go along), but at the very least, I think that if we have a > centralized hotplug/enum process above, we might as well use it to cache > the basic descriptors that are queried by the OS on insertion. All it'll > do is duplicate IO calls that are bound to occur from the OS no matter > what. Therefore, existing devices and bus transfers should be no more > troubled by a few extra similar transfers than by the ones that were > issued just before by the OS. 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. 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. Alan Stern ------------------------------------------------------------------------------ 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
