Messages in this thread |  | | From | "J. Dow" <> | Subject | Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS for Linux | Date | Wed, 6 Sep 2000 05:01:06 -0700 |
| |
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/
|  |