Re: [PATCH][0/6] A different KGDB stub

[Andrew Morton <akpm@osdl.org>]

Tom Rini <trini@kernel.crashing.org> 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.

OK.

> 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_MORE
CONFIG_KGDB_OPTIONS
CONFIG_NO_KGDB_CPUS
CONFIG_KGDB_TS
CONFIG_STACK_OVERFLOW_TEST
CONFIG_KGDB_SYSRQ		(Just turn it on by default?)

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