[lkml]   [2000]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Availability of kdb
    On Mon, 11 Sep 2000 16:19:14 -0600, 
    "Jeff V. Merkey" <> wrote:
    >Who pays you?

    I used to work on kdb in my own time, for free. Then I joined SGI and
    now I get paid to work on it. If I left SGI I would continue to work
    on kdb, the original kdb developer left SGI but still contributes.

    >> The kernel debuggers that are kept up to date get used. The ones that
    >> are used get feedback for kernel changes which keep them up to date.
    >> kdb has taken off precisely because it is being kept up to date with
    >> the kernel. And if I miss something, I know that people will tell me.
    >I'm sure this is all true. kdb was just rejected by Linus however, what
    >message does that send to you?

    That Linus does not like kernel debuggers. This is news? There are
    several examples of code that Linus did not like originally but enough
    people wanted them and they eventually got included in the kernel.
    Complaining to Linus does nothing, "show me the code".

    >kdb is about 1/100th the size of the MANOS debugger in terms of source
    >code size, and isn't a hacked in after thought like kdb. It uses task
    >gates and other tables beneath the OS that just are not there in kdb and
    >that will impinge on architectural freedom for Linus. It also uses
    >nested task gates, and requires changes to the xcall layer in Linux to
    >plug it in.

    kdb is not a hacked in after thought. It was designed from scratch as
    a minimalist kernel debugger which coexists with the existing kernel
    design. Note "minimalist", adding kdb to a kernel has little effect on
    the running kernel, the biggest impact is the symbol table (adds 20-30%
    to loaded kernel size) and the last branch recording in the page fault
    handler which probably slows page faulting slightly, although I have
    not measured it.

    kdb does a reasonable job at the binary level which is exactly what it
    was designed to do. If you have to change the kernel design to
    incorporate a debugger then you seriously need to think if your
    debugger design is suitable.

    >If Linus doesn't support the concept, it could be a lot of
    >work. I know my code, you know yours -- Linus habit of breaking things
    >as he puts in new and better features that you stated aealier is true,
    >so where does that leave us?

    In exactly the same position as every other kernel developer. Nobody
    promised us that kernel APIs would remain stable in development
    kernels, if it breaks we fix it in the next patch. This is the Linux
    development model, everyone else lives with it.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:38    [W:0.026 / U:3.192 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site