On 4 Jun 2003 at 14:50, Alan Stern wrote: > On Wed, 4 Jun 2003 [EMAIL PROTECTED] wrote: > > > The only information the core has is the vendor and product IDs. > > This is certainly not sufficient to determine which of multiple > > configurations should be used / activated. > > No, it's not. > > > It is the responsibility of the driver to take control of a device > > if it can, including multiple dissimilar internal functions. Since > > it was registered with a matching vendor and product ID in the first > > place, it can presumably handle all aspects of that device. > > Normally a Linux driver handles only one aspect of the device. If a > device contains multiple dissimilar internal functions, there normally > will be multiple drivers loaded for it. > > > A good example is my Brother MFC 9200C. It contains a printer, a > > fax machine, a scanner, and a smart-card reader. Each of these has > > different driver requirements, yet they should all be supported (or > > not support) by a single driver and a single probe() call. IMHO. > > They could be. But why not modularize the driver, and split it up > into separate printer, fax, scanner, and card-reader drivers? Each > would be easier to write and test, and might even be able to work > generically on other units of the same kind, not just a Brother > device. > > As far as selecting configurations, the argument you gave before can > be taken even farther. If a single driver provides total support for > a device, then presumably it also supports many different > configurations, so it won't know which one to choose either! Only the > user can tell. In Linux this choice is made by the user installing > the proper settings in the hotplug config files. > > Alan Stern >
I'm probably going to step on some toes here, but that's OK. I think we differ in philosophy. It's nice to think in terms of tailoring a system by tweaking files here and there and loading or removing individual modules, but that's not reality. We don't have offices filled with professional system administrators to configure these systems and keep them running. Linux is an end-user product. It's purchased off the shelf by average people who take it home and expect it to work. In this environment, multiple support files are very dangerous. It's too easy to contaminate the configuration, over time and system upgrades, particularly when performed by users with limited technical skills. >From a product support perspective, it's much easier to ask a user for the version of one file than to try to track down versions of a dozen different ones. Complexity translates into money. Support costs are a significant expense for software vendors. You're looking at the question from the inside out, as an OS developer. I think you could benefit from a reverse perspective, from the standpoint of the peripheral manufacturers and driver developers. They have very different concerns. Just some thoughts. 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
