Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!sdcrdcf!hplabs!hao!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn )
Newsgroups: net.unix-wizards
Subject: Re: How do *you* debug device drivers?
Message-ID: <6899@brl-tgr.ARPA>
Date: Wed, 2-Jan-85 11:14:13 EST
Article-I.D.: brl-tgr.6899
Posted: Wed Jan  2 11:14:13 1985
Date-Received: Fri, 4-Jan-85 04:46:55 EST
References: <541@vu44.UUCP> <895@dual.UUCP> <2205@umcp-cs.UUCP>
Organization: Ballistic Research Lab
Lines: 12

> Well, the ideal way is not to write any bugs.
> 
> Of course, we sometimes tend to fall short of the ideal.  I like to see
> where the machine crashed or what the erroneous behaviour was, think a
> while, and come up with something that explains the problem exactly,
> without "explaining" things that didn't happen.  Then it's time to look
> at the code and see whether that explanation is correct.

Right on!  If you cannot legitimately EXPECT your code to work right
the first time, then you do not have it under control.  Better to think
it out then do it right, rather than to tediously hack away hoping to
get that "last known bug" out eventually..