Re: [Kgdb-bugreport] [PATCH] Kill kgdb_serial
From: George Anzinger
Date: Thu Mar 11 2004 - 17:57:05 EST
Tom Rini wrote:
On Thu, Mar 11, 2004 at 01:33:40PM -0800, George Anzinger wrote:
Tom Rini wrote:
I am afraid I don't quite understand what he was saying other than early
init stuff. On of the problems with trying early init stuff, by the way,
is that a lot of things depend on having alloc up and that happens rather
late in the game.
I assume you aren't talking about kgdb stuff here (or what would be the
point of going so early) but I believe he was talking about allowing for
stuff that could be done early, to be done early.
One of the issues with the UART set up is registering the interrupt handler
with the kernel. It will fail if alloc is not up. The -mm patch does two
things with this. a) It tries every getchar to register the interrupt
handler, and b) it has a module init entry to register it. This last will
happen late in the bring up and is safe. a) is there to get it ASAP if you
are actually using kgdb during the bring up.
There's two ways to look at this.
- All the more reason to acknowledge that the earliest you can safely
get into KGDB is point X, where X is where alloc works,
Just to get ^C to work? I would rather give it up entirely!
mappings done
if needed, etc, etc, and IFF we change things slightly in kgdboe so
that it can call kgdb_schedule_breakpoint() if it needs to as an
initial break, and handle setting kgdb_serial to the serial driver in
kgdb_arch_init, or something, and remove all of the extra kludges to
get us a few lines / function calls earlier on.
- More and more special cases.
How about a command line set up ASAP which calls a driver entry to do the break.
The driver being serial does it NOW, but being some thing that needs
additional resources, just sets a flag to break when it gets them and returns.
Seems rather simple.
Roughly. :)
--
George Anzinger george@xxxxxxxxxx
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/