> > 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.
That depends on the device. In some devices it may be obvious,
others may need configuration change on the fly.
[..]
> 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.
No. This just encourages sloppiness :-)
A configuration must be switchable by the user at any time while
the device is plugged in, save for power constraints.
The kernel may just as well choose a default configuration.
Making distinctions here just increases complexity and means that
codepaths will get less testing.
> > 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.
Let's not forget bandwidth issues.
And power management.
Regards
Oliver
-------------------------------------------------------
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
