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..