On Thu, Apr 04, 2002 at 10:16:31AM +1000, Brad Hards wrote:
> On Thu, 4 Apr 2002 09:54, Greg KH wrote:
> > On Thu, Apr 04, 2002 at 09:31:55AM +1000, Brad Hards wrote:
> > > Not very orthogonal. Can you explain the rationale for each directory?
> >
> > Um, didn't the descriptions of the directories help explain that?
> I like things to be explicit. Saves confusion and makes sure everyone has the
> same view of where things "belong". I am not trying to make it difficult,
> just making sure I understand where you are coming from?
Ok, that's fine. I will create a README in the main drivers/usb/
directory pointing people to what is in each directory.
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?)
net/ - all USB network drivers
scanner/ - all USB scanner drivers
serial/ - all USB serial drivers
video/ - all USB video drivers
misc/ - all remaining USB drivers
> > > What takes precedence? That the driver complies with a (currently
> > > defined) class, or the function that the driver performs?
> >
> > class comes first. Then function. And then it goes into misc/ if it
> > doesn't fit into any of the existing function directories.
> Then why doesn't most of storage/ live under class/ ?
Good point, forgot about that too. There are so many non-compliant
usb-storage devices that I forget there are compliant ones around :)
> Also, does the class have to be approved (eg USBIF 1.0 status)? What happens
> with things that comply with draft classes? What if the draft class isn't
> publically available (eg USBIF <0.9)?
As I just wrote, it's ok to put these in the class directory.
> > > acm.c and CDCEther (that probably should be cdc-acm.c and cdc-ether.c if
> > > there is going to be a grand renaming patch :) are both basically
> > > networking drivers (although they don't both interface to the networking
> > > system), both comply with the same spec, and don't live in the same
> > > directory.
> >
> > You're right, sorry. They should both be in class/
> OK. I'd still like them to be renamed.
Me too.
> > > 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 :)
thanks,
greg k-h
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
