Hi, I know this discussion was a while ago, but I left this mail to respond to once I have time, and I've (some) time now ...
On 05/29/2013 04:10 AM, Pete Batard wrote: > On 2013.05.28 23:08, Tim Roberts wrote: >> Hans de Goede wrote: >>> I would like to give libusb using applications to os cached string >>> descriptors, so that those can be accessed without the need to open a >>> device and do io on it. >> >> The device is already open, because your API requires a libusb_device, >> right? So, you're saving the cost of one device descriptor read, and >> two string descriptor reads. >> >> I don't know. The API is well-defined and simple enough, but it doesn't >> require any information private to the library. Would it be used often >> enough to justify including it in the library, as opposed to having it >> in a code sample? I can't judge that. I am, admittedly, a minimalist. > > OK, let's consider the issue: > > 1. If we start providing an API call for cached string descriptors, then > there's really no reason we won't want to do it for other descriptors. > Maybe there's some BOS descriptor that's going to become super-useful in > the future, and that everyone will want to see us cache. *Ideally*, > then, we would want libusbx to cache as many common descriptors as we > think our users will need => doing it as proposed above may be the path > to a multiplication of descriptor retrieval API calls, whereas was we > really would want is if our already existing calls we just to return > cached versions where available. In theory I love the idea to change out existing calls to return the cached version where possible (and where we can be sure the cached info won't be stale somehow). But the problem with this approach is that many of our APi-s for this take a libusb_device_handle rather then a libusb_device, and getting a libusb_device_handle requires special privileges, at least under Linux it does. > 2. What's proposed here pretty much relies on the OS already doing the > caching, and providing an API to retrieve that data. Correct. > Do all OSes cache > the stiff we want. Who knows? They likely won't but I really don't want the libusb API to be limited to being the lowest common denominator, that just means it will be crippled (in one form or the other) everywhere, and is a loosing proposition IMHO. > Personally, I don't like taking a bet that all OSes will be cooperative. > This may be fine on Linux, where you can always make a case to the > kernel people, but on proprietary, such as OS X or Windows, you are in > for a long uncertain wait... Right, so again I don't want a lowest common denominator solution, being able to show device strings to the user is mostly a nice to have thing, we can make the functions return LIBUSB_ERROR_NOT_SUPPORTED, and add a capability flag for this, then apps can fallback to not showing the strings (instead showing ie usb-ids) on other platforms. > > So, how could we solve 1&2 once and for all? > "Simple", we add an extra layer to libusbx that does user-side caching > of all the descriptors we need, and tie this caching, along with > enumeration, to the newly added hotplug functionality: whenever a device > is plugged in, we get libusbx to issue a bunch of calls similar to the > ones the OS issues, to fetch the descriptors we are interested in > caching (which may result in doubling bus transfers, but unless you're > low speed, this will hardly be an issue: on any device plug in, you > should expect to have transfers that you have no control on from the OS > anyway, so whether these calls are doubled is hardly something to cry > foul over). Strong NACK, we really do not want to do any IO on enumeration at all. USB devices tend to be cheap crap, and various operating systems go out of there way to not upset the cheap crap, ie the Linux kernels uses quite large quirklists for this because some devices crash if you try to get string descriptors. Really doing any IO at all on enumeration is a big no no. I guess some of our backends my be already doing some io on enumeration, but we certainly don't need more of it, and we certainly don't want to go and do various probing of devices by default. So back to my original proposal. I like the idea of over loading existing API rather then adding a copy of it for cached descriptor, but I get stuck at libusb_get_string_descriptor needing a handle rather then a device. So I really see no alternative then adding extra API for this. Suggestions are welcome though. Regards, Hans ------------------------------------------------------------------------------ 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
