From: "Horst von Brand" <[EMAIL PROTECTED]>
> 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...
So you place your money into the bank until you have a "large enough sum
to be worth investing in a mutual fund or stock", I presume. If not then you
SHOULD understand the invest now for returns later ideas. If the time is
invested now the return on investment later will be far greater than if they
finally grudgingly try to do it later.
While I was at Magnavox I watched several software projects from
proposal through production code. The more time that was invested
up front in tools the more likely the project was to be on time and on
budget or even under budget. (And this was with that roundly dispised
thing called Ada. Go figure.)
I rather strongly think it is well past time to make the debugger
investment. But building a good one is hard to do. Where is someone
smart enough and capable enough to get the core built so that there
is a rational debugger project to parallel the kernel development?
It's not a glamorous job. But somebody ought to grit their teeth and
get their name on The Linux Kernel Debugger. I suspect the community
would remember THAT person a LONG time. I kinda wish I had the
time and that it better fit my skill sets. I know the people who fit the
project are out there earning REALLY big bucks from Raytheon
and Rockwell as well as some of the more often thought of companies.
> Witness the people who have argued _against_ integrating debugging code
> into the kernel, *even code they designed and wrote themselves*.
"If it was hard to design by God it should be hard to maintain, too."
> 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, I think you are pointing out one of the more
splendidly large worms in the Open Source apple. Better tools are
needed and if they exist they would be used. But nobody wants the
job. So it doesn't get done.
Alas, *I* do not have a solution other than maybe to embarrass someone
into doing what has to be done and geting intense satisfaction about that
when it is done.
{^_^}
-
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/
