[Ksummit-2012-discuss] [ATTEND] kernel debugging, tracing, backtracing

[Nicholas A. Bellinger]

Hi Jason,

On Mon, 2012-06-18 at 00:26 -0500, Jason Wessel wrote:
> While no one had mentioned it yet I am certainly up for discussing the
> future of debugging and tracing.
> 
> Over the last few years it appears there has been a lot less need for
> a stop mode debugger, so long as you have a good backtrace, printk, or
> kdump.  I am certainly curious how others feel about this.  I am also
> curious if we have some kind of mechanism to get a poll out to folks
> such as our core community.  Obviously if no one cares to even respond
> to a poll that tells us something as well. :-)
> 

As a user of kdb for 10+ years now,  I have to say that a stop mode
debugger is more critical to me for target development than ever
before..

The improvements elsewhere are certainly useful, but when it comes down
to the nitty-gritty of debugging really difficult target bugs kdb is the
tool that I depend on.

> There are a number of orphaned debug tools, that with some focus could
> potentially make it to the mainline but it doesn't seem as if there is
> a high demand.  One of the main reasons these have become orphans is
> that each requires some invasive change to a particular subsystem.  I
> am not entirely sure that the various subsystem maintainers would even
> allow the kinds of changes required, or if we truly have a need for
> these tools.
> 
> The orphan list:
>    * KDB shell with USB keyboard
>         - Requires invasive poll changes to USB stack

Unfortunately the Romley / Crown Pass sample I've been using for the
last six months does not have a serial port on it.  (Not sure if it's
just the sample that's missing it or what)

Not having KDB on this machine certainly limits it's usefulness
development wise..  :(

But regardless, thank you Jason for all of your work on kdb!

--nab