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?

> > 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/ ?

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)?

> > 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.

> > 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? 

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

Reply via email to