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.
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.
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to firstname.lastname@example.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 email@example.com
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:26 EST