On Wed, 4 Jun 2003 [EMAIL PROTECTED] wrote: > My concern is with the division of responsibility between the core and the > device driver. My proposal is an architecture which supports device drivers > which are responsible for all aspects of the configuration and operation of the > devices which they support.
There can be no question that Linux should support such drivers. The current API allows them, in the sense that it will load them based on matching the VID/PID and allow them to bind to all the interfaces. But it doesn't provide any support for making such a process particularly easy. > At the heart of this proposal is the concept of one device / one driver. It > would not preclude registration of multiple drivers for the same VID/PID pair, > but this practice would be discouraged. I don't see any reason for discouraging multiple drivers. After all, a vendor might prefer to do things that way. > Generic drivers are not a problem. The vendor-provided drivers are very much a > problem. Vendors won't expend extraordinary effort to support complex > administrative environments unless they see a business advantage in doing so. I suspect that the administrative requirements for supporting multiple drivers aren't that much more onerous than for supporting a single one. And a vendor might have very good reasons for wanting to modularize their drivers. Increased simplicity of development and testing, plus the ability to perform selective updates, come to mind. In short, we should permit both types of approach with minimal hassle. Alan Stern ------------------------------------------------------- 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
