Messages in this thread |  | | Date | Thu, 14 Sep 2000 12:52:27 +0200 | From | Frederic Magniette <> | Subject | Re: 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 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/
|  |