On 2013.08.04 07:41, Hans de Goede wrote: > I believe the discussion between you and Alan has hopefully made it > clear why this is a bad idea.
Not in the slightest. It's not because something is difficult to accomplish (i.e. may require _workarounds_ for flaky devices) that it's a bad idea. Caching all the basic controllers that we expect the OS to query by default, by duplicating the requests, is essentially a good idea as it avoids unnecessary transfers down the line at times when the running app will not want/expect to be polluted. And as far as I can see, the one issue with this proposal (besides how long it may take us to implement it, which is a genuine concern, but still irrelevant to its technical merits) has everything to do with having to deal with devices that aren't following the USB specs. Well, to me, that's be a bit like saying that trying to provide medical aid to populations in a conflict/disaster zone is a bad idea, because there's the chance that some medical staff will get hurt. If you can factor-in the risks, the benefit of providing help is still greater. Any other solution here means that transfers are at the mercy of someone doing something as basic as reading a descriptor, that by all means the OS should have cached already, and disrupt the bus for no good reason. Thus, unless we expect descriptors to change on a whim, tailgating the OS on the descriptors it is bound to retrieve (device, conf, basic strings) has to be something we'd want to have. That's not to say it may not be difficult/time consuming to implement, but in the absolute, this is what would be best for our users, as anything else will result in *avoidable* bus transfers at a time where they have a very good chance to be disruptive. > I've the feeling we're deviating a bit from the original topic. Probably. I'm nowhere near being able to propose something that can help, and I suspect you want a solution soon(ish), and not in one year's time or more. So, while you'll keep hearing me vehemently defending the descriptor tailgating proposal (that is until I see a convincing technical argument as to why this isn't something that would be best for our users, if done properly), I'm not going to oppose the implementation of whatever suits you for the time being either... as long as it isn't something too Linux specific. All I've tried to do is respond to your view that the technical proposal I advocated as the best solution was flawed. If instead of "NACK" you'd just said "This would take too long to implement properly, and I need something I can work with now", we wouldn't be having this discussion. ;) > So I agree with you that doing on-demand (not on-enumeration, but > on-demand), caching of various descriptors would be a good idea, and > then we don't need to add special cached versions of various > functions to our API, which would be good. Works as a half solution. But we can do better. > But the problem with using a transparent caching approach (which I > like as an idea) for the string descriptors I'm interested in, is > that our current libusb_get_string_descriptor functions take > a device_handle rather then just a device. And getting a > device_handle requires privileges under Linux, so what I would > like to see is a new set of string descriptor functions which > take a device rather then a device_handle as argument. Which is actually fine by me, and not something that I tried to dispute, as implementing the proper caching I envision will take a lot more effort and time. 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
