Messages in this thread | | | Date | Thu, 7 Sep 2000 19:13:31 +0200 (CEST) | From | Ingo Molnar <> | Subject | Re: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux |
| |
Jeff, please read Linus' mail for an explanation about the dangers of kernel debuggers.
Ingo
On Wed, 6 Sep 2000, Jeff V. Merkey wrote:
> > Ingo, > > KDB is a user mode debugger designed to debug user space apps that's > been hacked to run with a driver. It's not designed as a kernel level > debugger and in real world situations has tons of shortcomings period. > If someone is working on a car, do they use a wrench, or just pry the > bolts loose with their teeth? All this "We don' need better tools > because we are real men" crap I've seen on the list is absurd. Try > taking a tire off a car with a lug wrench. It's tough. But if you have > an air socket wrench, like professional auto garage's use, the tire is > off in under 30 seconds, as opposed to 15 minutes if you do it by hand. > The whole point here is putting the best kernel level tools in possible > makes development go way faster, and makes it funner. > > :-) > > Jeff > > Ingo Molnar wrote: > > > > 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. > > > > but the other IKD components, like the soft lockup detector, kernel > > tracer, leak detector and other goodies, are clearly intrusive. It's > > also a pain (and distraction) to 'drag' all that functionality along > > in a developer kernel - i'm sure Mike can attest to that, IDK is > > frequently broken by lowlevel changes. > > > > > Surely there must be some useful features that can be included in the > > > kernel without uglyfing it or slowing it down (configed > > > out)? [...] > > > > sure, and we have a number of them included already. And we rutinely > > include debugging facilities along newly rewritten code (witness the > > spinlock debugging helpers, the waitqueue and highmem debugging helpers, > > the io.h debugging helper). These things do get removed rutinely though. > > (maybe except the spinlock.h stuff - IMO we still have too much flux in > > the SMP code.) > > > > it's always a matter of balancing - we have multiple conflicting > > requirements. One factor in judging a debugging facility is the frequency > > and difficulty of bugs it detects. If a bug doesnt happen often and is > > easy to analyze then we need no debugging facility for it. Another factor > > is the impact of the patch on the kernel proper - memleak for example is > > extremely intrusive. Yet another factor is the maintainance 'drag' on the > > generic kernel (this is an issue even if the subsystem itself is > > localized) - eg. the mcount() debugging aids (on which several IKD > > features are based) periodically caused merging problems in the x86 arch, > > and they will continue causing problems once we implement fast-syscalls on > > x86. I'm happy that Mike and Andrea are maintaining IKD - but we dont want > > to force this maintainance overhead on Linus. Plus the social factors > > mentioned by David and Alexander. There are easy decisions and there are > > hard decisions. KDB is IMO not an easy call. > > > > Ingo > > > > - > > 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/
| |