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/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:24 EST