I don't think kgdb and a simple assembler debugger
are directly comparable. kgdb always requires a remote machine,
which has many advantages, but is also often very inconvenient
or impossible to arrange. An low overhead assembler debugger
can be always compiled in just in case.
Also at least for the x86 port the debugger interfaces should
be general enough now (see die hooks as a "debug vfs") that it would
be quite possible to have a multitude of debuggers just using
them. In fact that's already the cases, kprobes and kgdb and
kdump are all kinds of debuggers using such hooks.
As long as it doesn't impact the core code and the mdb
code itself is considered merge worthy and has clean interfaces
that would seem fine to me.It essentially would just live somewhere in
its own directory using the existing interfaces. My standard
test for seeing if a debugger has clean interfaces is to see
if it can be loaded as a module.
There are enough different debugging styles around that offering
developers different tools of which they can pick whatever suits
them is not a bad idea. Also as everyone knows debugging
is often a major time eater and if more tools are available that
can only help the kernel.
That said I haven't read the mdb code, not judging on its general
merge-worthiness or am really completely sure what are all the details
of a "netware style debugger", just a general high level comment on
debuggers. At least judging based on the patch sizes it at least
doesn't seem particularly bloated. But of course it would need full
proper review first.
-Andi
--
