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