Messages in this thread | | | From | devnull@spaans ... | Date | Tue, 12 Sep 2000 08:04:58 -0400 | Subject | Re: Availability of kdb |
| |
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/
| |