Amen here too. From a kernel supportability perspective, a kernel debugger
has
saved me many hours. The open the doors to things that often can't be seen
or
seen easily by just knowing the source.
For a real world 24X7 type support situation where a problem needs fixing
_now_
or there are consequences, it would be difficult to live without one.
-----Original Message-----
From: Jeff V. Merkey [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 13, 2000 5:57 PM
To: Keith Owens
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
> 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 PROTECTED]
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 PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
