Messages in this thread |  | | From | Marty Fouts <> | Subject | kernel debugging (was RE: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux) | Date | Tue, 5 Sep 2000 21:09:20 -0700 |
| |
I've debugged quiet a few operating systems on a very wide range of hardware over 25 years using a very wide range of tools and techniques, sometimes even having to use logic analysers. I've also watched this discussion for a while. IMHO, y'all have conflated two quiet different processes (possibly three,) and are trying to use your (lack of) tools as a form of social engineering.
To the extent that computing is science, it is empirical science, and as such any effective tools that gives you visibility into the running computer belongs in your toolkit. A good (remote) source level debugger, *properly used*, is one of the most effective ways of obtaining visibility that I know. Tied in to a decent source code browser, it can also be a very effective way of coming up to speed on the ins and outs of someone else's code.
There are, in essences, three parts to debugging a problem: figuring out what the system is really doing; figuring out why what it is doing is wrong; and figuring out the best way to make it behave less wrongly. Debuggers and source code browsers can figure prominently in the first (as should Meyer's programming contracts or a similar model backed up by real asserts in the code, but that's a different topic.)
As I've posted earlier, our brains complement the computers, and we should use both most effectively. People are good at seeing patterns in the data, but not so good at extracting the data or remembering it. Good debuggers, effectively used, help with both the extraction and the remembering.
Some people work best at identifying problems with abstraction and analysis. That's the way they should work. Others need hands on experience to identify problems. In the real world you need both kinds of people and you need to supply tools for each.
Marty
-----Original Message----- From: David S. Miller [mailto:davem@redhat.com] Sent: Tuesday, September 05, 2000 5:03 PM To: cw@f00f.org Cc: mingo@elte.hu; rgooch@ras.ucalgary.ca; ak@suse.de; jmerkey@timpanogas.com; alan@lxorguk.ukuu.org.uk; jes@linuxcare.com; linux-kernel@vger.kernel.org Subject: Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux
Date: Wed, 6 Sep 2000 12:00:13 +1200 From: Chris Wedgwood <cw@f00f.org>
Right now as I see it (pretending everything is black and white); you, Dave, Linus and a few other people[1] are more than happy with debugging aids as they exist right now in a stock kernel.
However, there are many many other people far less talented than yourselves and for use less capable people having a compile time options of IKD or something might really be of use....
I think what it comes down to is that the folks who know the tree the best and do the most work/fixing in it, think the debugging stuff should remain a seperate patch.
We believe that it doesn't belong in the main source tree mainly for two reasons:
1) It is clutter. I don't want to see the debugging/debugger code when most of the time it serves no purpose.
NOTE: This is different than "BUG()" and "ASSERT()" which serve a different purpose becuase they not only act as a consistency check, but they also _document_ how the author of the code believed the world around it must behave :-)
2) It is hoped that because it isn't the default, some new people will take the quantum leap to actually try debugging using the best debugger any of us have, our brains, instead of relying on automated tools.
Later, David S. Miller davem@redhat.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |