Re: [Kgdb-bugreport] [KGDB PATCH][1/7] Add / use kernel/Kconfig.kgdb

[Tom Rini <trini@kernel.crashing.org>]

On Fri, Feb 27, 2004 at 02:30:57PM -0800, George Anzinger wrote:

> Comments below...

I'm going to set aside some of the comments, simply because I'm not
going to change behavior / content right now, we can do that afterwards.

[snip]
> >+choice
> >+	depends on KGDB_8250 || PPC_SIMPLE_SERIAL
> >+    	prompt "Debug serial port BAUD"
> >+	default KGDB_115200BAUD
> >+	help
> >+	  Gdb and the kernel stub need to agree on the baud rate to be
> >+	  used.  Some systems (x86 family at this writing) allow this to
> >+	  be configured.
> 
> Should this depend on the archs that can use it?

The help is wrong, that's all, it's not arch-dependant, it's driver
dependant.

> >+config KGDB_IRQ
> >+	int "IRQ of the debug serial port"
> >+	depends on !KGDB_SIMPLE_SERIAL && (KGDB_8250 || PPC_SIMPLE_SERIAL)
> >+	default 4
> >+	help
> >+	  This is the irq for the debug port.  If everything is working
> >+	  correctly and the kernel has interrupts on a control C to the
> >+	  port should cause a break into the kernel debug stub.
>
> I think setserial will also spit this out.

And of course, ^C isn't needed now too.

> >+config KGDB_THREAD
> >+	bool "KGDB: Thread analysis"
> >+	depends on KGDB
> >+	help
> >+	  With thread analysis enabled, gdb can talk to kgdb stub to list
> >+	  threads and to get stack trace for a thread. This option also 
> >enables
> >+	  some code which helps gdb get exact status of thread. Thread 
> >analysis
> >+	  adds some overhead to schedule and down functions. You can disable
> >+	  this option if you do not want to compromise on speed.
> 
> Lets remove the overhead and eliminate the need for this option in favor of 
> always having threads.  Works in the mm kgdb...

Once it's clean, perhaps.

> >+config KGDB_CONSOLE
> >+	bool "KGDB: Console messages through gdb"
> >+	depends on KGDB
> >+	help
> >+	  If you say Y here, console messages will appear through gdb.
> >+	  Other consoles such as tty or ttyS will continue to work as usual.
>
> Might want to warn them of the need to connect prior to the first message 
> from the kernel....

There is no such need.

-- 
Tom Rini
http://gate.crashing.org/~trini/