On Thu, 4 Apr 2002 11:26, Greg KH wrote: <snip> > Ok, that's fine. I will create a README in the main drivers/usb/ > directory pointing people to what is in each directory. nice
> So let's try this again: > core/ - this is for all of the core USB code, > including the upcoming driver core code. > core/fs - this is for all of the usbfs code > host/ - this is for all USB host drivers. Like UHCI > OHCI, and EHCI. > device/ - this is for all USB device controller drivers. > Like superh, sl11, sa1100, etc. > > Now come the individual USB driver directories. These are listed in > order of preference (i.e. if a driver can go into the first one, it > will, otherwise it falls down the list until it ends up in the proper > directory.) > class/ - This has all USB class drivers. These are > drivers for which there is a published USB > spec (it can be a not ratified spec too, like > at 0.8 or 0.9 level.) > class/storage/ - all usb-storage Class drivers > class/input/ - all USB HID drivers (is this really needed?) These class sub-dirs need to be higher in the precedence list, otherwise they will tend to be empty. 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:) <snip> > > > > If the "higher level interface" is important, why doesn't dsbr100 > > > > belong with the video stuff, since it uses V4L as well? > > > > > > Because I messed up :) You're right, it should go into video. > > > > Perhaps multimedia? > > Nah, it uses the video kernel interface, so we should stick with video > as the name, until the day that V4L changes its name to M4L :) Something to think about: drivers/video directory contains framebuffer stuff. drivers/media has V4L Brad _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
