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/