> The arm port has a USB host and client driver (or so I've been told, the > client might be this one for all I know :) I've seen the host driver, > and it will probably end up in the drivers/usb/ directory soon. Same > thing goes for a embedded PPC USB host controller driver that is based > off of usb-ohci.c, it too will end up in the drivers/usb directory soon.
Hmm ... but why not keep architecture specific drivers in the relevant arch/... subtree? > drivers/usb/dcd sounds ok, I don't mind too much, but don't like the > "usbd" directory name, as it sounds too much like "USB Deamon" to me > (but I might have been staring at all of the different kernel deamon > names too long...) I agree ... that "usbd" name has been used many times to mean "USB Daemon". It also has a particular meaning in the USB spec, as a _host side_ API (sect 10.1.1) and in MSFT's host side API ... if we use that term, it ought to be a precise match for what's in the USB spec. (Where it's more or less equivalent to today's "usbcore".) > I think the network and video drivers now have a critical mass to move > them to their own directory if no one objects. Nice thing about > bitkeeper, file moves are very simple to do :) I certainly wouldn't object ... :) There might be other ideas for how to sort the drivers into other directories, but that was the approach that seemed most effective to me. > > Before it goes there, I thought I'd request some discussion > > and convergence of the API with what's already there. > > Easier to achieve that before integration than after. > > Actually, if the code is in the kernel, I think it is easier to provide > better discussion, as we can all share patches against a common view. > Just because the code ends up in the tree, does not mean at all that the > API can't change, or be radically altered. It just makes it easier :) Yes and no. Some changes are easier to do before merges than after. At any rate, I'd hope that such things would be discussed before integration. Not entirely clear to me that it shouldn't be done on linux-usb-devel, though a more focust sublist can often be big win. "linux-usb-devices"?? Though as has been noted, the "USB On-The-Go" (peer-to-peer USB) will affect both hosts and devices. - Dave _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
