Messages in this thread | | | Date | Wed, 11 Feb 2004 16:27:56 -0800 | From | Andrew Morton <> | Subject | Re: [PATCH][0/6] A different KGDB stub |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |