On Tue, 5 Sep 2000, Andi Kleen wrote:
> I don't really believe that. It is as easy to add a silly NULL pointer
> check based on a oops as it is after a debugging session (and it is
> even likely you chose the simple fix because it is harder and more
> work to proceed) Usually with the debugger it is at least easier to
> collect the data needed for a real fix. [...]
this is the conceptual difference David tried to show, and which view i
support as well. There are two basic types of 'debugging behaviors':
A) 'Collect enough data to understand the local context and fix the bug.'
B) 'See the point of the immediate crash, think about that code, think
about code that called this code, think about the intent and
implementation of that code and find the bug based on
understanding the code.'
A) results in people being able to debug easy and moderate kernel bugs.
The same people are lost if faced with bugs that are not apparent in the
'state of the system around the bug' represented by the debugger.
B) results in people with the ability to identify bugs based on the source
code - and the ability to fix the really mindblowing tough bugs. We had
about 10 such bugs during the cycle of the 2.3 kernel.
I do claim that the real mainsteam-kernel development 'bottleneck' is the
ability to fix the tough bugs. It's always these tough bugs that keep up
the addition of new features in devel kernels. We should thus do
everything to teach people the proper debugging methodology.
A) takes less time for the easy bugs - it might also speed up driver
development. But it is utterly useless for the really tough problems. We
had really tough bugs in 2.3 that one couldnt find even with the heaviest
hitting debugging equipment. Debugging code in the kernel also blurs the
intention of the code, which makes B) harder.
B) is a slower process to both learn and practice, but will also lead to
more (unrelated) code improvements (based on better understanding of
various kernel subsystems) and ultimately leads to better kernel
developers.
one problem is developer laziness ;-) We could as well include debugging
code so that experienced people like you can fix easy / moderate bugs
quicker. But the problem is that in this case people are not forced to
understand the code as much as if the debugging tools were 'minimalistic'
like today.
i have nothing against (in fact contributed to) independent debugging
functionality like IKD / KDB. It's slightly more pain to keep it uptodate
with the devel kernel, but the devel kernel itself must stay focused on
the strategic goals, not the tactical ones.
Ingo
-
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:22 EST