On 2013.08.03 16:41, Hans de Goede wrote: >> 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.
And the idea here is to duplicate what the OS does. If the OS uses quirk lists, which I assume are public, then there's no reason we can't do that too, though I have to wonder how other OSes fare in that matter... Or we just let whatever crash, i.e. "Don't plug cheap known problematic crap and expect stability". Either way is no big deal IMO. > Really doing any IO at all on enumeration is a big no no. The proposal is simply about duplicating the IO we expect the OS to perform naturally, and no matter what you are trying to pretend, you are NOT going to disturb an app any more than the OS will do by duplicating these basic requests within a reasonable timeframe. No matter how you look at it, it wouldn't be more disruptive as the expected disruption naturally brought by the plugging of a new device on an OS that does descriptor caching. If you don't want lowest common denominator, then that's what you have to do. So I can't help but shake the idea that your proposal is all about: "Linux is fine, and I can get what I want there. Why should I have to care about other platforms?" Well, libusb is a cross platform library. Focusing on adding calls that are designed specifically with one type of platform in mind (detach kernel anyone?) is something that we should avoid. > I guess some of our backends my be already > doing some io on enumeration, but we certainly don't need more of it, Why? Because you say so? You have no control over how much IO the OS will do, so how can you confidently say that something that's at the mercy of being doubled with a mere OS update is OK (because it's done by the OS), but something that's doubled by libusb is not? > and we certainly don't want to go and do various probing of devices > by default. And how's that different from what the OS does exactly? Do you have an estimate of how disruptive you think it will be, outside of brandishing the spectre of "extra IO" (when it really is "duplicated IO within a reasonable timeframe following a device's arrival")? The only point I really get from above is "I don't want that". Whenever any device is plugged in, IO will occur. The OS will fetch descriptors. And, outside of Linux, you hardly have any control about what the OS will poke. Well, we've long ceased to try building a library that's meant to cater only for Linux, so IO that you have no control upon on device plug-in is a given with regards to our actual OS landscape. Ergo, having libusb duplicating the expected descriptor caching IO from an OS, within a second (probably much less) of the device being plugged in shouldn't be an issue. You plug a device. You get IO. If you don't want IO, don't plug anything. Whether the IO is duplicated is actually irrelevant as long as the transfers are minimal (they are - we're just fetching descriptors) and occur as soon as the OS lets us do them once device arrival has been advertised. <sigh> I guess I'll have to demonstrate that this is really the only way to go, with a proposal, to actually convince the world and stop having to shoot down all these fallacious arguments about how libusb mimicking standard OS descriptor caching is going to mean the demise of everything else. Oh well, it's number 3 in my "If only I had more time section" [1]. I'm still hoping to get there some day... Regards, /Pete [1] https://github.com/pbatard/libwdi/wiki/Backlog ------------------------------------------------------------------------------ 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
