On Fri, Apr 05, 2002 at 09:52:37AM +0200, Oliver Neukum wrote: > > > > Also, the class/input (if used) should be class/hid (because hiddev is > > > not an input mechanism). Does wacom.c go in here (almost HID:) > > > > class/hid/ should be used. And no, I don't think wacom.c should go into > > there, as it is not a HID driver. It should stay in the misc/ directory > > until there gets to be enough input drivers and then they could move to > > a input/ directory. > > Actually that defeats the purpose. > Differentiating class and nonclass drivers is a good criterion as > long as it does not interfere with things that matter to the programmer. > > In terms of code we care about relationships in drivers. > The most basic similarity is the kernel API used. > > Eg. printer is a class driver as is storage. Their relatedness is zero. > Their closest relatives would be say auersbach respectively hpusbscsi. > If things that eg use the input layer (hid,wacom,iforce) are split in > three directories the reorganisation hinders the coders. > > Furthermore subsubsystem deserve their own directories. > serial and storage deserve their own directories independent of class. > As do input, net and media. Actually scanner as a directory has little > use, as there's little internal relationship. You'd be better of putting > them into misc.
I have to second this. The acm.c code is much closer to serial code than for example to printer.c, and I think that most of the acm.c code will be merged into the usbserial framework, to make things simpler. Also for HID, things will be tougher soon, because there will be hid-ff.c for Logitech HID (but not PID) based force feedback devices, which will need hid-core, but won't use an USB-defined class interface, then there will be hid-pid.c for USB PID based FF devices, most likely also hid-wacom.c, because the Wacoms really use HID, though in a very twisted way, etc, etc. I'd really prefer not to look at specs, classes, whatever for the driver grouping, but on the kernel APIs and shared code between the drivers instead. Just my thoughts. -- Vojtech Pavlik SuSE Labs _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
