From:	 Greg KH <greg@kroah.com>
To:	 Brad Hards <bhards@bigpond.net.au>
Subject: Re: [linux-usb-devel] [RFC] drivers/usb directory restructure
Date:	 Wed, 3 Apr 2002 17:26:48 -0800
Cc:	 linux-usb-devel@lists.sourceforge.net

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

_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel