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
logs.
In that way, I think that a kernel debugger could be a powerful coding tool and not
only
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.
Fred
-
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 : Fri Sep 15 2000 - 21:00:23 EST