On Wed, Apr 17, 2002 at 03:39:12PM -0700, Stuart Lynne wrote: > On Wed, Apr 17, 2002 at 02:10:07PM -0700, Greg KH wrote: > > > > But I have a few questions: > > - it doesn't look like the following files are ever used, can I > > remove them?: > > crc10.c > > crc10.h > > crc16.h > > crc16.c > > crc8.c > > crc8.h > > The network function uses crc32 (now, originally was 16). It should be > changed to use the generic 32 bit CRC code. > > The serial function uses crc10. Those files should be moved to the > serial directory. I don't know if there is an alternate crc10 > implementation that it could use instead.
Ok I just moved the crc10.* and crc32.* files into the driver subdirectories and deleted the 16 and 8 files. > > - The code in usbd-debug.c allows for some pretty complicated > > parsing of debug options. Is this really necessary? It looks > > like the code came from a different project, and was added. > > It does look quite flexible, but maybe a bit too flexible :) > > Useful when working on embedded devices that have limited access. Too > much logging and you cannot get at what you need. Too little and you > do not have what you need. And some of these devices have very flaky > hardware so you do need to be able to easily turn on/off debugging. > > Think in terms of a development process where you are compiling on > one system, copying files to another box to copy onto an MMC card, > transporting the MMC card over to the test device, accessing the test > device over a single 9600bps serial link to load/unload and log via. > > Also think of it as something running at about the same speed as a > 486DX2 100. Too many printks will change the timing and results. Finally > think of it as having no working klogd, so you only get a snapshot of > whatever remains when you finally get to run dmesg. > > On that system being able to unload/reload with different debug levels > for different areas of the code was very helpful for tracking down the > hardware problems. > > The good news is that people are asking us to put linux on these types > of systems. The bad news is that people are asking us to put linux on > these types of systems. :-) > > I have to try and keep the process affordable for them. Good debugging is nice to have, but the implementation seems to be a bit overengineered here :) There are macros defining macros defining macros. Not nice stuff, as it looks like the debug code came from a different package originally. I'm all for keeping the functionality, but a good cleanup is in order :) > > - The link process for the processor drivers links files from > > the previous directory, which causes the compile process to > > happen every time you enter the directory. This is not nice. > > Can we take the common code and put it into the "main" > > usbdcore.o (or whatever we end up calling it) module? That is > > what we did for the usb core code. > > The usbd-bi.c provides a module framework for all of the bus interface > modules. The common portions other than the module init/exit etc could > be moved up to the common core. Then the module init/exit would need to > be replicated into each of the bus interface modules. That shouldn't be too tough. Same thing for usbd-func.c, right? > Currently there are four bus interface modules, by the end of the year I > expect another half dozen. Replicating and maintaining the couple > hundred lines to be the same across 6-10 directories can be done. But > it does get to be a pain. We shouldn't need to have 100 lines of the same code for every driver that's the same. Let's put that code into the core, for all to use. > > - It doesn't look like the build process will work if you want > > to build things into the kernel, instead of modules. I'll > > look into fixing this if you don't want to. > > We did at one point make it work. That was a long time ago and with a > very old kernel (2.4.2 if I remember). The customer ended up getting > module loading to work properly so we didn't pursue it. Heh, Ok, I'll look at it. thanks, greg k-h _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
