From: "Ingo Molnar" <mingo@elte.hu>
>
> On Tue, 5 Sep 2000, Richard Gooch wrote:
>
> > Would you classify IKD as a pile of warts you wouldn't want to see in
> > the kernel?
>
> the quality of IKD is IMO excellent (<plug> having written parts of it),
> yet i wouldnt want to see it in the kernel. That having said, i *did*
> author and integrate one of the IKD subsystems into the mainstream kernel
> - the NMI oopser on SMP systems. If a debugging aid is localized then
> there are no source-code health issues. In the case of the NMI-oopser the
> case was even clearer: nor a developer, nor a user can do anything useful
> with a hard lockup, apart from complaining that it 'locked up'. We clearly
> needed more information than that.
>
> KDB is not a code health issue either, it's quite localized. But KDB has
> the other bad social side-effect David was talking about, it promotes
> band-aids. So it's a tough call IMO.
I guess this has dragged on long enough I feel the urge to stick my
oversize sandles into the mess here.
For decades now I have observed that no tool ever makes a
"hack" into an "artist". All the tool does is allow both to make
their product, mess or art, quicker and with fewer basic errors.
A word processor does not turn the average Joe up the street
into an award winning novelist. But if it is reasonably well designed
there is a prayer that Joe will make fewer basic spelling or
textual errors.
A Kernel Debugger is just another such tool. It helps you find
"something interesting" quicker and with less pain. A great
debugger also offers you interesting views to help you
understand WHY what you are seeing is happening. If the
person using the debugger fails to ask that question he's
created his mess quicker. If the person using the debugger
asks the question and seriously ponders the answer the
kernel debugger is a handy tool for discovering why the
problem is happening. The kernel debugger, or any other
good debugging tool, gives the capable user a cleaner and
more efficient view of what is happening.
If the Kernel Debugger creates faulty solutions through lack
of thinking, and asking why, then surely printk is at least as
bad because it allows somebody to view the operation of
the kernel through a keyhole darkly. This view also fosters
"quick solutions" rather than careful analysis and desk
checking etc. Again, both are tools. They make things happen
quicker. In capable hands you get properly debugged code
quicker. In novice hands you get quicker bandaids placed on
the wrong sores. At least if the novice characterizes a problem
and points to a place where the problem is evident through
the patch presented the capable kernel author can start there
and use his or her thinking process more efficiently. It leverages
the capable person's abilities.
And in my limited experience with the NT kernel debugger you
sometimes can find problems that printk and looking at the same
code over and over again miss.
I guess the refrain is the same as the gun lovers refrain. Kernel
Debuggers do not create problems. People create problems.
{^_^} Joanne Dow, a "debugger" for most of my professional life,
both electronics hardware of many types and software.
-
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:25 EST