"J. Dow" <jdow@earthlink.net> said:
[...]
> I note again that the same arguement applies vis a vis printk
> and desk checks with a paper and pencil. The printk leverages
> the capable person's time. The kernel debugger leverages
> the capable person's time. What IS this urge to be handicapped
> when trying to debug the most important pieces of what gets
> delivered on the distribution CDROMs.
Problem is:
- Debugging code has to be written, integrated and debugged. It has to be
designed for collecting certain types of data. If you get the data to be
collected wrong, it is useless (and as you don't know what bugs you are
looking for, you _will_ get it wrong most of the time, unless you collect
everything in sight)
- Debugging code impacts readability, writeability, and performance of the
instrumented code, specially if it is pervasive (and most functionality
isn't localized)
- Debugging harnesses have to evolve together with the instrumented
code. If they don't, they are just a liability. If they do, they double
(probably more) the development time, as they have to be kept in synch.
- Broken debugging code impacts stability
Do we want Linus & Co. writing cool kernel code or writing a whiz-bang
kernel code debugger? Developer time _is_ finite, you know...
Witness the people who have argued _against_ integrating debugging code
into the kernel, *even code they designed and wrote themselves*.
Check out stuff like the user-level kernel, AFAIU there it is possible to
attach a run-of-the-mill debugger to a live kernel. Or look at the remote
debugging stubs for gdb.
It is not that they don't want better tools, the problem is that the tools
available (or buildable at a reasonable cost) are woefully inadequate to
the task at hand. Typical (low-level!) question when debugging is "Where
the $EXPLETIVE does this $WRONG_VALUE in $RANDOM_VARIABLE come from?", and
no current debugger is able to give you even that little. Sure, you can
single-step to the point of failure, but it is often faster to just grep
for the places where it can be changed. Don't even think about asking stuff
like "Why is $RANDOM_FUNCTION being called so much?". Given this scenario,
the only useful tool is a good understanding of the kernel; instrumentation
which gets more in the way than its usefulness warrants is just left out,
or rots away.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 - 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/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:25 EST