> > Actually, I kind of agree with you. The sad fact is that no one has come > up with a really satisfactory way of simplifying system administration > tasks for the user. The approach of the more popular operating systems is > to present a nice-looking user interface which works fine most of the time > but is insufficiently powerful when something unusual comes up or things > go wrong. Coupled with the way they hide and fail to document the way in > which the settings are handled internally, it's not good enough for me > (and maybe lots of other Linux developers).
I would certainly never propose the type of fragile, undocumented and idiosyncratic peripheral support that we are forced to tolerate in other operating environments. That was never my intent. 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. When a device is plugged in, the core calls the registered device driver as determined by the VID/PID. The driver is responsible for configuring the device and registering supported functions with the core. By definition, the driver knows the capabilities of the device, while the core does not. 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. This concept scales very nicely to both generic and vendor devices. Simple system devices (mice, keyboards, etc) could each be supported by one driver which accommodates all standard variants. Vendors can provide individual drivers for their products, and upgrade and enhance them as desired without worrying about mixing and matching components. > > No doubt people are working on other ways to do solve this problem. In > the end, I don't see the user's administrative interface to the system as > being directly determined by the way in which the kernel implements its > internal mechanism and policy. A nice GUI program can manipulate hotplug > configuration files as easily as it can load driver modules. > > Alan Stern The administrative interface can certainly implemented in a GUI, but the underlying complexity must still be addressed by a developer at some point. It's not sufficient to say "let a GUI do it" unless you also identify the resources to maintain that GUI. 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. Unfortunately, we are not number 1, and until we are, we have to concentrate our efforts on developing an environment that encourages others to support our system, not one which confuses and confounds their efforts. Not preaching, just thinking. Thanks for your time. 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
