Date: Thu, 17 Jan 2002 12:22:07 -0600 From: "Mike Meyer" <mwm-dated-1011723728.a9b65b@mired.org> To: "Anthony Atkielski" <anthony@freebie.atkielski.com> Cc: "FreeBSD Questions" <freebsd-questions@freebsd.org> Subject: Re: USB CF reader (SanDisk) epilog Message-ID: <15431.5711.715952.313252@guru.mired.org> In-Reply-To: <015701c19f32$1d330a70$0a00000a@atkielski.com> References: <15428.34332.870130.2946@guru.mired.org> <00cc01c19e06$8dafddf0$0a00000a@atkielski.com> <15428.38970.224790.33804@guru.mired.org> <00ee01c19e0d$4c518960$0a00000a@atkielski.com> <15428.53337.168408.720031@guru.mired.org> <01b301c19e55$f11330a0$0a00000a@atkielski.com> <15429.45776.491932.646543@guru.mired.org> <007201c19ed4$e98bc070$0a00000a@atkielski.com> <15430.11292.89340.470262@guru.mired.org> <015701c19f32$1d330a70$0a00000a@atkielski.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Anthony Atkielski <anthony@freebie.atkielski.com> types: > Mike writes: > > All the information on how the software works > > is contained in the code. > Similarly, a core dump of the software will tell you exactly how it works, > too, but here again, it is not practical to try to learn how a program works > by reading machine language in a core dump, despite the theoretical (and > actual) 100% completeness of what the dump contains. Actually, a core dump won't tell you how anything works, unless you've got a description of the hardware as well. Even then, source code is much easier to read. > > As to writing readable code, there are two > > approaches that have proven successful. > The only approach I've seen that works is hiring highly competent > programmers. And that failed to be become popular for the same reasons - the internal quality of the code isn't seen by the user, and has no bearing on sales. So money spent on it is wasted when it comes to sales. > Object-oriented programming What Meyer describes includes a lot of things that document what the code should be doing that didn't make it into most popular OO languages. If you haven't read his book and do OO programming, you're missing half the value of the technic. > > The web is not the code. > The Web is more cost-effective than an examination of tens of thousands of > lines of code, and the code will not tell me everything I'd need to know > (such as how the USB standard works). Since you didn't find anything, the web had a value of 0 and a cost of hours. That's makes it as cost effective as staring at the wall. Reading the code carefully is more cost effective than that. > > cd /usr/src/sys; find . -name '*.[ch]' | xargs > > grep -l <OPTION> | xargs more > I tried this; all I get is a listing of the umass.c module, which I had > already looked at. No documentation. That was the documentation. I suspect you missed the line in it that tells you where on the web the USB standards can be found. In this case, that documentation won't help you much, because the device you're having problems with doesn't follow the standard - at least as it was interpreted by the authors of the code. > > You'll get lots of kernel output describing > > what those parts of the USB subsystem are doing. > Messages, you mean? How will seeing what the subsystem _does_ help me to > know what it _should_ be doing? Because that will tell you what it's doing that causes the device to complain. Which tells you what behavior needs to be changed. This really isn't the place for lessons on how to debug software. Unfortunately, I don't know of anyone who really teaches that, though Abelson, Sussman, and Sussman make a good start of it in "Structure and Interpretation of Computer Programs". <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15431.5711.715952.313252>