> [EMAIL PROTECTED] wrote: > > 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 signature in 2.5 is: > > probe (struct usb_interface *, const struct usb_device_id *); >
So this would be the appropriate point for the change to occur. > And the api spec (kerneldoc) is clear that what's in question > is that specific interface ... sometimes drivers will claim > additional interfaces (CDC), but the probe() question is whether > the driver will handle _that_ interface. It's not an invitation > to claim different interfaces and leave that alone, or change > the configuration (breaking other driver bindings). This is another manufactured problem. If you have only one driver, there is no question of "breaking other driver bindings". > > > > > 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. > > Likely it'd be easiest to phase in that way too. Details > remain to be worked -- the main question in my mind has > been how kernel code should affect the "what configuration" > choice that needs to be made. And again, this can be done entirely within the driver. The kernel is operating blindly in selecting a configuration. It doesn't know the difference between a mouse and a printer. It is just manipulating lists of support routine entry points. The software which understands the environment and the device capabilities resides in the driver. > > > > 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 > > Eh? Unplug should be the _easy_ one! Everything goes away, > and cleanup is straightforward. Assuming the drivers stacked > over USB understand the notion of "hardware gone"; the SCSI > code has taken a while to do that. > > Note that in 2.5, there's a "device level" hotplug event, > which can be a reasonable hook for userspace to kick in a > "use this configuration" policy if it's needed. If we > need that, we'll need to remove the kernel's automagic > selection of config index zero in cases where there's > a real choice to be made. > > > > 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? > > We're not too far from it, once we make it clear (as I think > we've done in 2.5) that USB works with "interface drivers". > The 2.3 development cycle got things working, but left ragged > edges ... 2.5 filed them down, delineating things better. > > That leaves "what configuration" as the main open issue on the > enumeration path ... and all sorts of cleanups still needed on > some of the funkier paths, like "reset" (separate thread) and > the related "change the firmware" logic. > > - Dave > The simplest ( != best ;-) ) solution is to default to configuration 0 and let the driver determine whether a different selection is appropriate. Best regards. 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
