lkml.org 
[lkml]   [2000]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ANNOUNCE] Withdrawl of Open Source NDS Project/NTFS/M2FS forLinux

Ingo,

I did read it. You have to understand, I'm not a young guy but an old
man, so it takes me longer to ponder and digest things -- not because
I'm slower, but becasue I'm older. I used to blindy charge at anything
when a red flag was waved in front of my face in my youth. As I got
older, I learned that at times, it's best to examine things for a while
since there can be "barbed wire" between you and the target that not
immediately visible, and a person can get tangled up in it.....

:-)

Jeff

Ingo Molnar wrote:
>
> 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/

\
 
 \ /
  Last update: 2005-03-22 12:41    [W:0.253 / U:0.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site