On 5 Jun 2003 at 10:05, Alan Stern wrote: > 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.
This is at the heart of my concerns. I suggest we should facilitate this model to the greatest extent possible. I believe It is highly advantageous to allow the vendor to control all aspects of the interface to the product. > > > 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. I retract the phrase containing 'discouraged' ;-) The details of the implementation should be left to the discretion of the vendor. > > > 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 most companies with which I have worked, each software product is an administrative unit, with a part number, a version control tree, and an accounting number. I don't claim that this is universally true, but it is certainly common practice. I have worked on many projects in which a single unified component is much easier to sell to upper management than multiple components, even through the total effort involved is the same. Just management perceptions. > > In short, we should permit both types of approach with minimal hassle. > I certainly agree. The 'minimal hassle' criteria is paramount. If we're to enjoy the support of the peripheral manufacturers, we must make their development process as simple and straightforward as possible. I started this thread a few days ago in response to a statement that probe() should not change configurations. It is my belief that the device driver should have complete responsibility for the configuration and operation of the attached device, and the core should simply accept the functionality registered by the driver. This would provide a clean delineation of responsibility which is applicable to both generic and vendor drivers. I believe it would simplify the design on both sides of the boundary. Thanks very much. 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
