Re: [Kgdb-bugreport] [PATCH] Kill kgdb_serial
From: George Anzinger
Date: Thu Mar 11 2004 - 18:47:49 EST
Tom Rini wrote:
On Thu, Mar 11, 2004 at 02:53:34PM -0800, George Anzinger wrote:
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.
This sounds a lot like what I passed along from dwmw2 a week ago. :)
Must be something wrong here. We seem to be agreeing :)
--
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/