On Mon, 11 Sep 2000, Jeff V. Merkey wrote:
>
> Thanks Ted. I know, but a kernel debugger is one of those nasty pieaces
> of software that can quickly get out of sync if it's maintained
> separately from the tree -- the speed at which changes occur in Linux
> would render it a very difficult project to maintain. If there's going
> to be one (whichever one it is) it would need to be maintained and
> dragged along with the kernel proper or it would be a maintenance
> nightmare. Linus' dislike of the kernel debugger concept would also
If the kernel debugger is done right, it won't require massive changes
as Linux continues to change. Does gdb need to be modified based on the
programs that it debugs?
I can certainly see that certain kernel debugger modules (say, those
that muck with spinlocks for deadlock debugging) might require updating
as the kernel changes, but the overall design goal for any good kernel
debugger is to minimize the number places where it has to hook into the
real parts of the kernel. For one thing, this reduces the chance of
"heisenbugs" which disappear once you enable the kernel debugger, since
if adding the kernel debugger modifies the code paths, the bug is much
more likely to go away. For another, if you want to have the kernel
debugger enabled by default, having lots of hooks into the main parts
kernel makes it much more likely that the whole thing will be a massive
speed/performance hit.
If keeping the kernel debugger outside of the kernel is inspires people
to minimize the number of hooks and patches that are needed to main
parts of the kernel, then that's probably one of the best reasons to
keep it ouside of the mainline kernel distribution.
- Ted
-
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:17 EST