[lkml]   [2008]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ANNOUNCE] Merkey's Kernel Debugger
    Andi Kleen wrote:
    > Nick Piggin <> 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 <>
    "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:0.024 / U:11.240 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site