[lkml]   [2000]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: The case for a standard kernel debugger
Marco Colombo wrote:

> 2) apply tight filters on what people produce (patches, features) not on
> how they produce. If Linus is right (and in the end I believe it),
> 'debugger people' will produce low quality patches (the ones that fix
> the syntoms not the problems), and those patches won't be blessed
> by Linus. I think Alan made the point that those patches sometimes
> may be useful to others who are looking for the real problems.

I agree with you about the production of bad patches, but it is really hard to debug
your own code
especially when the kernel start to segfault. Then you have to begin a very slow
process of printing
lots of parameters and wondering about what you could have done which is so bad.
This can be really awful if your code is called very often and then saturate the
In that way, I think that a kernel debugger could be a powerful coding tool and not
a patching tool as you say.

The way were I totally agree with you is the educational way : nobody learn anything
by monitoring
a code. If somebody can't understand the C code, it will not be able to understand
the debugger traces.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.083 / U:13.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site