[lkml]   [2000]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: The case for a standard kernel debugger

    Amen Brother!!!!


    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
    > Please read the FAQ at
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:38    [W:0.029 / U:69.804 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site