A different KGDB stub
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest6 patches 5 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/6 | A different KGDB stubMakefile include/ include/ +8 more | +1631 | 0 replies | |
| 2/6 | A different KGDB stubdrivers/ drivers/ drivers/ +2 more | +558 | 0 replies | |
| 3/6 | A different KGDB stubdrivers/ drivers/ drivers/ | +178 | 0 replies | |
| 4/6 | A different KGDB stubarch/ arch/ arch/ +8 more | +586 | 0 replies | |
| 5/6 | A different KGDB stubarch/ arch/ arch/ +12 more | +389 | 1 reply | |
| 6/6 | A different KGDB stubarch/ arch/ arch/ +9 more | +703 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH][0/6] A different KGDB stub
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.
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?
Signature · 2 lines
Tom Rini http://gate.crashing.org/~trini/