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 *);
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).
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.
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
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
