Date: Wed, 16 Jan 2002 19:42:52 -0600 From: "Mike Meyer" <mwm-dated-1011663772.53227b@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: <15430.11292.89340.470262@guru.mired.org> In-Reply-To: <007201c19ed4$e98bc070$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>
next in thread | previous in thread | raw e-mail | index | archive | help
Anthony Atkielski <anthony@freebie.atkielski.com> types: > Mike writes: > > "fragmentary and incomplete" is redundant. > It's possible for something to be incomplete but contiguous (i.e., not > fragmentary). I don't feel like debating semantics now, but thanks for the offer. > > Often a series of guesses at the missing > > information is *faster* than trying to extract > > the information required to correctly diagnose > > the problem. > It is usually the _only_ way to diagnose the problem, and even then, it > usually isn't really a diagnosis. When dealing with users directly, yes. > > In extreme cases, it's faster to fly an > > expert to the spot so they can gather information > > than it is to try and extract it remotely. > You must be thinking of user information. I'm not talking about getting > information from users--although that is a problem, too. I'm talking about > just getting internal information on how the software works. Typically, no > such information is available. All the information on how the software works is contained in the code. It has to be - otherwise the code won't work. Other sources - that are sometimes easier to read - may exist, but they may not correctly reflect the code. If you can't read the code, you're handicapped in trying to solve problems from the first step. As to writing readable code, there are two approaches that have proven successful. See either "Object-Oriented Software Construction" by Bertrand Meyer, or "Literate Programming" by Donald Knuth. It should be obvious to anyone who's read <URL: http://www.mired.org/home/mwm/good-enough.html > why neither of these approaches has had much commercial success. > > So what have you done to figure out why it > > occured? > Looked for information on the Web, without success. The web is not the code. > > Have you checked LINT for debugging options > > for USB devices ... > I have now, after reading your suggestion. There are USB debugging options, > but no documentation as to what they produce. Yes there is. You can read it by replacing <OPTION> with it in: cd /usr/src/sys; find . -name '*.[ch]' | xargs grep -l <OPTION> | xargs more though that's not necessarily the best approach. > > ... and built a kernel with the appropriate > > ones enabled? > What will happen when I build a kernel with these options enabled? You'll get lots of kernel output describing what those parts of the USB subsystem are doing. Which you could have determined for yourself by examining the code. <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?15430.11292.89340.470262>