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. 2. What's proposed here pretty much relies on the OS already doing the caching, and providing an API to retrieve that data. Do all OSes cache the stiff we want. Who knows? 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... 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). Now, the hard part of such an implementation is to make sure we handle the boundary cases, i.e. avoid losing the libusbx caching state between two runs of libusbx apps (same app or different ones), especially if there wasn't any device arrival in between. This means we really don't want the hp/caching part to exist within the same timeframe as the app => ideally, the hp/caching part should be a standalone background user process, that gets initiated with the first libusbx app that runs, and shuts down with the user session. This way me minimize transfer to the bare minimum: the bunch we'd do at the start of the very first run, when we don't know the landscape (which may not be appreciated by people who also run non-libusbx based USB app that is bandwidth sensitive, but then again, I doubt these people appreciate the current implementation of libusbx either, especially with the constant bus polluting re-enumeration on Windows), and the one triggered on device arrival. The issues we need to solve then become as follows: 1. Cross platform server/client process, which is a fairly common problem, with expected well established solutions. Not to say that it'll be easy to implement, but this kind of stuff has be done. 2. Upgrade handling: eg when sharing the same hp/caching process between different versions of the library, or upgrading the running process while preserving the cached data, in case 1.0.z+1 fixes a bug in this background process from 1.0.z, and we have both 1.0.z and 1.0.z+1 apps running at the same time. Could be tricky, but if we plan for this (by making sure all calls to the hp/caching process provide the version of the library used), this isn't exactly a brick wall either. Keeping API layers compatible between versions is something we're already used to doing. 3. Convincing the world that using a separate process for hp/caching/enum is really the best approach in the long run: That one didn't go down too well, last time I proposed it, so I'd say this'll be the trickiest... 4. Producing a proposal for the above: will require time. Quite a lot of it. And is better done after Windows hp and cross platform event handling has been sorted out. Of course, an ethereal proposal won't do much to help Hans in the short term, but since it's been debated before, I thought I'd throw it back on the table again. Regards, /Pete ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
