On Tue, 16 Sep 2003, David Brownell wrote:
I don't like any driver to be making these policy decisions as absolutes. Some other driver, not yet (mod)probed, might have better luck binding to this interface (or might already be bound to another interface in this config!) ... the config may be a lot better than this driver thinks it is, with just its current local perspective!
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.
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.
Which is why I described a mechanism where the kernel stops trying to switch configs as soon as one "works" (some driver gets bound), so there can be no "ties". The role of the kernel is limited to finding something that works. Choosing between configurations that "work" (a driver binds) is userspace policy.
The role of the driver within that is local: telling whether it can bind to an interface in the current configuration. That's sufficient to come up with a "working" configuration, they don't even need to hint to usbcore which config(s) would be better.
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.
Maybe it
would be best simply to leave all decisions of this sort to a user process, like a hotplug script. Using the sysfs interface, your scheme could be carried out that way.
The sysfs interface I provided (and which I hope Greg will merge soon!) does allow hotplug scripts to help out here; that's been a goal for some time. So that's one of the schemes I described.
But I'm also looking at the cdc-acm issue too. That's clearly a policy choice: must we demand userspace input? Or can we retain the 2.4 behavior?
That mechanism I described above (try binding drivers to a new config if the current one doesn't check out) would be a different scheme, maintaining the 2.4 behavior without userspace input.
I'll respond to other parts of your post later, I wanted to clarify why I described this particular notion: a safe way to eliminate requirements for additional userspace or kernel changes. At this point in the 2.6 cycle, that seems desirable.
- Dave
------------------------------------------------------- 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
