On Wed, 17 Sep 2003, David Brownell wrote: > Alan Stern wrote: > > > Of course, the other possibility is that the driver might be a > > special-purpose one, written just for that device, and it _knows_ which is > > the correct configuration to use. The core ought to allow for that kind > > of arrangement. > > The only way it could "know" such thing as an absolute is to > ignore userspace requests to change a configuration. And I > think it'd be inappropriate for the kernel to do that. This > is a fair example of a case where local policy mechanisms can > fail, so that more globally aware mechanisms are better.
I don't think things are quite that bad. A vendor might ship a driver module along with a device, for example; the driver would be tailor-made for the device and would select the right configuration. That's more or less how things work under Windows. > Example: several different drivers "know"ing the correct > configuration for a device, but they disagree on which config > that is. System ping-pongs between the configs: one driver > overrides the config, then another, repeat forever. The corollary to the scheme I outlined, having old or otherwise inappropriate drivers hanging around (sometimes referred to as DLL Hell although it's not quite the same thing). However, I don't see how this would happen under either the current scheme or the one you're proposing. Once a driver overrides the config then it ought to bind with no errors, so the other driver wouldn't even get probed. Unless it was a driver for a different interface. > >>The notion I've recently been tossing around is this. Usbcore can > >>easily notice that that after N seconds since usb_set_configuration(): > >> > >> - It's still true that none of the interfaces has a driver; > >> > >> - There's still a config we haven't tried, and it even fits within > >> the power budget available for that port; > >> > >> - So make some task call usb_set_configuration(that-config), to let > >> the usb drivers try binding to that one. > >> > >>No new API needed; user/admin control is possible with sysfs > >>(write bConfigurationValue); and it's simple enough that it won't > >>go haywire. In particular, it stops after bNumConfigurations > >>attempts, or when a semi-functional configuration has been found. > >> > >>I suspect that kind of solution would get rid of the cdc-acm issue, > >>as well as solving the corresponding issue for the CDC Ethernet > >>class support... > > > > > > That would probably work, although it seems a little elaborate. > > I can't see "elaborate" actually. (Except maybe mentioning the > power budgeting issue which Linux has so far ignored! It can > continue to be ignored for a while, but needs a place to belong.) > > It's certainly much simpler than teaching individual drivers how to > safely change configs. I started down that path; it's ugly because > of what it takes to avoid the ping-pong scenarios. The effort of keeping track of all the N-second timeouts and devices being probed sounds a little messy. But no doubt it can be done. Perhaps it would be okay not to let drivers change configurations. But there remains the question of how to handle the "device-morphed" path in usb_reset_device(), which involves basically the same questions. Alan Stern ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
