Not necessarily. Having kdb in the 2.3 series tree and beyond has
a number of advantages; firstly, if you don't configure it in, it has
no impact on a running system. Secondly, having it in the main tree
makes maintenance of it much easier (as those who add new features to
the kernel have the responsibility to keep it working :-); thirdly
it reduces the demands on my time for support (as I am working on
several other projects, kdb only gets about 25% of my time right now).
Kdb itself is mostly self-contained, with a couple of hooks in
traps.c, keyboard.c and serial.c. A general purpose mechanism
should be devised in traps.c to allow attaching and detaching handlers
for specific faults, and having multiple handlers for individual
faults (an implementation of which is found in the gdb-stubs patch,
if I recall correctly). This would reduce further the impact of
kdb on the kernel source base. If the hooks were done right, the
entire kdb could be a loadable module with no run-time impact if
the module is not loaded.
Over the last 14 years of OS development, I've found having a
debugger in a production kernel to be invaluable (especially when
the run-time impact is limited to a small amount of RAM).
While I've no idea what Linus and others reactions will be to including
kdb in the base kernel release would be, I'll champion it for now, and
if it is deemed that it doesn't belong there, then I'll be glad to
integrate it into IKD (It should probably be done for the 2.2 series
kernels, anyway).
scott
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/