On 5 Jun 2003 at 11:50, Alan Cox wrote:
On Iau, 2003-06-05 at 00:02, [EMAIL PROTECTED] wrote:I did mention in one of the other postings that multiple drivers were not precluded. It would be perfectly valid to register multiple drivers for the same VID/PID combination.
This would be the exception, but it would certainly support the situations which you suggested.
Yes. One thing that bothers me about some of the discussion is the assumption of one path or the other with solving things. Linux generally takes the approach of allowing the unusual when it makes sense. We have similar issues with certain combo PCI cards (especially parallel-serial combo) and they just have their own driver, because its easier than a giant magical sharing layer in the PCI core
This is exactly my suggestion. One driver per device eliminates all of the confusion. The complexity of the driver is dictated by the device, not by some arbitrary assumptions made by software which is unfamiliar with the device.
I don't want to speak for Alan, but I think the point is that we need to consider both single-device/single-driver and single-device/multiple-driver scenarios in the big picture, regardless of what sort of driver you might be working on at the moment.
It is all well and good to suggest single-device/single-driver solutions for manufacturers who have built proprietary USB hardware for one reason or another. On the other hand, a good number of devices are designed to conform to established USB Class standards, even if it's at the per-interface level. Contrast this with PCI combo devices-- there are no corresponding class documents, just a few de-facto standard implementations.
Maybe the mass storage driver isn't the best example (although it has had a high profile on this list as of late-- very few manufacturers seem to understand the SCSI transport layer), but take a look at the current Linux driver support for the printer class, the audio device class, etc. If a manufacturer comes out with a multi-function device with only one non-class-based interface, it would certainly be easier for them to not reinvent the wheel for all of the other functions.
-- Charles Lepple <[EMAIL PROTECTED]> http://www.ghz.cc/charles/
------------------------------------------------------- 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
