Messages in this thread |  | | Date | Wed, 13 Sep 2000 15:57:01 -0600 | From | "Jeff V. Merkey" <> | Subject | Re: The case for a standard kernel debugger |
| |
Amen Brother!!!!
Jeff
Keith Owens wrote: > > Resend, this time with cc: torvalds. > > This note puts the case for including a kernel debugger in the master > tarballs. These points do not only apply to kdb, they apply to any > kernel debugger. Comments about the perceived deficiencies of kdb, > kgdb, xmon or any other debugger are not relevant here, nor are > questions about how or when debuggers should be activated. I want to > concentrate of whether the kernel should have *any* standard debugger > at all. > > If Linus still says "no" to including any debugger in the master > tarball then that will be the end of this thread as far as I am > concerned. I will then talk to distributors about getting a debugger > included in their kernels as a patch. Hopefully the distributors who > want a kernel debugger can then agree on a standard one. > > Disclaimer: Part of my paying job is to maintain kdb. SGI want kdb to > be used more widely to benefit from GPL support. More eyes > and hands means better code for everybody. > > (1) Random kernel errors are easier to document and report with a > debugger. Oops alone is not always enough to find a problem, > sometimes you need to look at parameters and control blocks. This > is particularly true for hardware problems. > > (2) Support of Linux in commercial environments will benefit from a > standard kernel debugger. The last thing we want is each > commercial support contract including a different debugger and > supplying different bug reports. Bug reports on supported systems > should go to the support contractor but some will filter through to > the main linux lists. > > (3) Architecture consistency. Sparc, mips, mips64, ppc, m68k, superh, > s390 already have remote debugger support in the standard kernel. > i386, alpha, sparc64, arm, ia64 do not have standard debuggers, > they have to apply extra patches. Some architectures have extra > debugger code in addition to the remote gdb support. > > (4) Debugger consistency. Back in 1997 there were a lot of individual > kernel debugging patches going around for memory leaks, stack > overflow, lockups etc. These patches conflicted with each other so > they were difficult for people to use. I built the original set of > Integrated Kernel Debugging (IKD) patches because I contend that > having a standard debugging patch instead of lots of separate ones > is far easier for everybody to use. The same is true of a kernel > debugger, having one standard debugger that all kernels use will > improve the productivity of everyone who has to support kernel > code, no need to learn the semantics of multiple separate > debuggers. > > (5) Easier for kernel beginners to learn the kernel internals. Having > worked on 10+ operating systems over the years, I can testify that > some form of kernel/OS tracing facility is extremely useful to get > people started. I agree with Linus when he said > > "'Use the Source, Luke, use the Source. Be one with the code.'. > Think of Luke Skywalker discarding the automatic firing system > when closing on the deathstar, and firing the proton torpedo (or > whatever) manually. _Then_ do you have the right mindset for > fixing kernel bugs." > > But Linus has also said "The main trick is having 5 years of > experience with those pesky oops messages ;-)". Beginners need > some way of getting that experience. Reading the source from a > cold start is an horrendous learning curve, debuggers help to see > what the source is really doing. Always remember that 90%+ of > kernel users are beginners, anything that helps to convert somebody > from kernel beginner to kernel expert cannot be bad. > > (6) I contend that kernel debuggers result in better patches, most of > the time. Sometimes people misuse a debugger, as Linus said > > "I'm afraid that I've seen too many people fix bugs by looking > at debugger output, and that almost inevitably leads to fixing > the symptoms rather than the underlying problems." > > Does that occur? Of course it does, I have been guilty of that > myself over the years. Is it inevitable? IMNSHO, no. Seven of > the twelve architectures in the standard kernel already have built > in debuggers. Where is the evidence that these architectures have > more bad patches because of the presence of the debuggers? > > Even if somebody does submit a patch to fix the symptom instead of > the problem, that alone is valuable information. Fixing the > symptom focuses attention and the associated information helps to > fix the real problem. We get problem patches even without > debuggers (let's not mention the recent truncate problems ;) but > there are enough eyes on the kernel to find problem patches and > remove them. Adding a standard debugger will improve the quality > of some of those eyes at a faster rate. > > So how about it Linus? Does any of this change your mind about > including a standard kernel debugger? > > Asbestos_underware_mode=ON. > > - > 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/
|  |