lkml.org 
[lkml]   [2008]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [ANNOUNCE] Merkey's Kernel Debugger
Date
Andi Kleen wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> writes:
>> 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
>
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.

And Andi explains just *why* this is different (and in many cases better):
> 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.
>
I totally agree with this, the whole idea of a remote machine implies
that the ability to connect is not what you are debugging.

> 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.
>
In 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.
> 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.
>
I 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.

The need for a special setup make spur-of-the-moment investigation of
unusual behavior difficult for anyone but a hard-core developer who does
daily work on a setup with the remote machine available at hand. I think
this new approach would encourage people to do quick checks when the
behavior is observed.

--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot



\
 
 \ /
  Last update: 2008-08-06 15:05    [W:1.196 / U:0.580 seconds]
©2003-2014 Jasper Spaans. Advertise on this site