On 4 Jun 2003 at 11:14, David Brownell wrote: > [EMAIL PROTECTED] wrote: > >> ... I don't think probe() should be allowed > >>to change configurations. > >> > > > > > > To the contrary, probe() is the only component in the system that > > actually understands a device configuration. The higher-level code > > is just blindly flipping through a list looking for help. > > But what we probe is an _interface_ not a device; > and not a device configuration.
Is that actually true? It seems that we call a probe() with an identified device, then the probe() walks through the interfaces, at least in the code I've looked at. > > > The driver is the component that understands the attached device and > > should be able to determine its configuration. That's the > > definition of a driver, IMHO. > > Actually I'd say we don't yet have a component, even in > userspace, which understands "configuration". In fact > even today, we know there are bugs in the Linux code to > handle non-default configurations. > > I see that as a problem. One we're attacking on a few > different fronts: > > - First, usb_set_configuration() still doesn't do > what it needs to do ... the main remaining bug > I know about is that changing a config (or setting > it to zero) doesn't get rid of old sysfs files. > > - Second, that capability is unavailable from userspace, > where we can expect intelligence about such policies. > > - Third, drivers using usb_set_configuration() have > basically been wanting something other than a > configuration change, since configuration changes > haven't worked. (Except that the hub enumeration > logic has worked for initial config 0 --> default.) > > We're also ignoring the power management issues, like > never enabling configurations that exceed the hub's > power budget. > > Periodically I've thought we might need to add a new notion > to the API, a "configuration driver". Here's a rough idea > of how it might work: > > * New driver call, analagous to probe() but accepting > a usb_device. It'd match only device descriptor fields. > > * Devices that need non-default configuration (index != 0) > would need such driver support. > > * When selecting an initial configuration, usbcore would > first check to see if there's a configuration driver. > > - If so, that driver's configure() call [or whatever] > would be used ... it could set the "Linux Config" vs > the "Windows Config", or whatever. > > - Otherwise, use the current scheme: config index 0. > > Such an approach would address some of the issues that come > up during enumeration. And if sysfs could be used to change > the configuration, bad kernel choices could be reversed. > > - Dave > I like the configuration driver idea, though I submit it should be an integral part of the device driver rather than a separate component. This is just based on a question of system maintenance over time. It's much easier if you have one file responsible for one device. We have an interesting problem of differentiating responsibilities among various OS components. We start out with hot-plug detect, then the enumeration drivers, then to the usb core to find the appropriate driver(s) for the device. But this pales in comparison with the complexities of unplugging ;--0 In my 30+ years of doing drivers and other hardware / software interface stuff, I've always strongly supported the idea of highly modularized code with well-delineated responsibilities. I wonder if we have the appropriate functional definitions on which to base the design of the support software? Best regards and thanks for the response. Leigh Bassett ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
