[lkml]   [2004]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH][0/6] A different KGDB stub
    Tom Rini <> wrote:
    > Hi Andrew. As a reply to this message, I'm going to send you patches to
    > replace George's KGDB with a version that is Amit Kale's work, with a
    > number of additional cleanups (that I'll put in his CVS ASAP). There
    > are 6 different patches:
    > core.patch: All of the non-arch specific bits, that aren't drivers.
    > 8250.patch: The i/o driver for KGDB, via a standard PC uart.
    > kgdboe.patch: The i/o driver for KGDB, via netpoll.
    > i386.patch: The i386-specific code, tested.
    > ppc32.patch: The ppc32-specific code, tested.
    > x86_64.patch: The x86_64-specific bits, untested.


    > With this, there's a few design questions I have. First, as I've done
    > things right now, a breakpoint at the first line of C code is untested.
    > It should work, but I have a question of how we want to handle setting
    > up the pointer to our i/o functions (if we have a pointer). There's a
    > couple of ways that this could be solved, with pros and cons. For
    > example, if we want to allow for both serial and enet to be used in the
    > same kernel, we could default to setting this pointer to the 8250
    > version, and allow for kgdb_arch_init to override (as PPC sometimes
    > does). This is what I've done for now, but I don't know if I like how
    > it looks or not. If we don't care about allowing for > 1 i/o driver, we
    > can simply drop kgdb_serial as a function pointer and just call
    > kgdb_getDebugChar/kgdb_putDebugChar/etc. Or someone else can suggest an
    > better way.

    I don't think runtime selection is very important, personally. You tend to
    get things set up with a serial cable or ethernet and just leave it that
    way. Given that you need to recompile the kernel anyway, I'd say that
    Kconfig-time selection is acceptable.

    > Next, what features of George's version are a must-have? And what that
    > we have now, can we drop? For example, up until I started working on
    > kgdboe+netpoll, I found KGBB_CONSOLE quite handy. Now, I'm very happy
    > with netconsole, so I don't have a strong attachment to KGDB_CONSOLE
    > anymore. But it's not much code anyhow. And of course, what could be
    > done better?

    I use KGDB_CONSOLE occasionally, although that's only when I can't stomach
    the thought of using minicom ;)

    A few things which I believe have debatable value are:

    CONFIG_KGDB_SYSRQ (Just turn it on by default?)

    I have never used (or, as far as I know, needed) any of the above.

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

     \ /
      Last update: 2005-03-22 14:00    [W:0.044 / U:8.540 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site