On Tue, 5 Sep 2000, Alan Cox wrote:
> I spend my time thinking. But I prefer to spend it thinking about the
> bug not about finding it and how long fsck takes. [...]
if we only optimize for the debugging time spent by seasoned kernel
developers then you are completely right. But if we optimize for new
kernel developers learning the right methodology, and if we optimize for
the *development* process (not the *release* process) of the kernel then
reducing the amount of debugging functionality is the right choice.
> Things like GUI source level kernel debugging, nice graphs of things
> like cache line reloads between two points and run time spinlock
> deadlock validation and lock tracking (the last one is on my todo list
> only right now) are rather useful
IMO there was only one historically hard spinlock-related problem that
needed solving, this is the 'locks up hard' problem (which is solved). The
rest was never really an debugging obstacle, 99% of the spinlock related
bugs manifest themselves in clear, unambiguous lockups.
there is another type of bug that is tough to find without an automatic
tool - memory leaks.
I dont think there is any other systematic bug (besides hard lockups and
memory leaks) that occur often and can only be effectively found via
debugging tools.
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