Messages in this thread | | | Date | Thu, 07 Sep 2000 11:16:59 -0600 | From | "Jeff V. Merkey" <> | Subject | Re: [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/
| |