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 the matter is, in order to solve something not directly related, we're going to have to implement a process that is actually well suited for caching. So, if the idea is that we want to provide consistent descriptor caching across platforms, we might as well use that. 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). And since it's Windows, I can't go heckle the guy in charge of the USB stack implementation there, to try to fix this... ;) So (with the current libusb/Windows) every time we (re)enumerate, we get an IO request sent to pretty much every device, as we try to figure out how they are related to one another in order to return up to date enum data to the user. Ouch! This is of course quite disruptive and something we want to avoid if we can (some people are very unhappy about this, and have proposed simply dropping the idea of building any form of topology on Windows). You may have a libusb app doing ISOC or something and all it takes is another app simply getting the list of USB devices, to get polluting descriptor requests all over the bus. Again, none of this has anything to do with trying to cache descriptors. Even if you have hotplug, and set your enum process to only update the data it needs according to the device insert/removal notification, as long as the updated enum data isn't shared across all libusb apps, it just takes another app issuing its first enum to disrupt your bus. 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. 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. As long as we only get one set of duplicated calls, for all libusb apps and for all users, and limited to device insertion, I don't see this basic OS-independent caching being that much of an issue (but yeah, it will take some work to get there). 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
