Nick Piggin <nickpiggin@xxxxxxxxxxxx> writes:That idea sounds familiar, the "suspend2" response, when something new and significantly different is offered, instead of putting it in and letting people choose in configuration, take the position that what is there is good enough, and if the author of the new solution will just drop all their ideas and slap some band-aids on the existing code it will be "gooder enough" without actually offering people a choice of something different.Seriously? Because it doesn't seem to have had enough peer review,
it hasn't had widespread testing in somewhere like linux-next or
-mm, and we already have kgdb so you have to also explain why you
can't improve kgdb in the areas it trails mdb.
But the ideal outcome would be if you could contribute patches to
kgdb to the point where it is as good as mdb. It is already in the
I don't think kgdb and a simple assembler debugger are directly comparable. kgdb always requires a remote machine,I totally agree with this, the whole idea of a remote machine implies that the ability to connect is not what you are debugging.
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 shouldIn addition to "Bravo!" I will add that tools which work somewhat differently will increase the chances of having a tool which will work at all, depending on what's being investigated.
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 generalI would suggest that if it meets coding standards and doesn't break anything else it could be included in -mm (assume there's no objection there) and let people beat on it there, with the assumption that unless problems are found it will be promoted.
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.