Re: KDB in the mainstream 2.4.x kernels?

[Andi Kleen <ak@muc.de>]

One argument i have against it: KDB is incredibly ugly code. 
Before it could be even considered for merging it would need quite a lot 
of cleanup.

I actually started on porting the KDB backtracer recently to get
reliable frame pointer based backtraces, but it turns out the code
for that is so complicated and ugly that the chances of ever merging
it would be very slim.

As for your home crash debugging I suspect you would be better of with LKCD
or Mcore (crash dump, saving an crash image on some partition, with examining
the crash dump after reboot) 

KDB is usually not useful for debugging hangs on desktop boxes (and even
many servers) because you have usually X running. When the machine crashes and
goes in KDB you cannot see the text output and debug anything. I learned
to type "go<return>" blind when I had still an KDB aware kernel, but
it's not very useful overall.

On a development machine you can avoid that by connecting a serial cable,
but that's usually not easily possible for a desktop box. Doing a post-mortem
after reboot is more practical. That is what LKCD/mcore do.

Disadvantage is that the current crash dump mechanisms (lkcd, mcore
crash, netdump) are all still not very reliable and have horrible
error handling. And you can eat a lot of disk space for the dumps and
they tend to overflow your file systems.  But still it's the only
realistic option for "desktop bugs"

BTW debugging on the X server works on linuxppc/mac with xmon because it 
has a fbcon based console and X server. The debugger can just
work on the X background while the X server is stopped. Very nifty. 
But I don't see the x86 XFree86 switching to a similar fbcon model any 
time soon, so it's unlikely to help.

-Andi