All of
 help / color / mirror / Atom feed
From: Andi Kleen <>
Subject: Re: KDB in the mainstream 2.4.x kernels?
Date: Fri, 18 Jul 2003 22:43:57 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> ('s message of "Fri, 18 Jul 2003 22:10:11 +0200")

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.


       reply	other threads:[~2003-07-18 20:31 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2003-07-18 20:43 ` Andi Kleen [this message]
2003-07-19  0:31   ` KDB in the mainstream 2.4.x kernels? linas
2003-07-19  0:57     ` Andi Kleen
2003-07-20 12:55   ` Keith Owens
2003-07-20 13:31     ` David S. Miller
2003-07-20 22:27       ` Keith Owens
2003-07-21 15:06     ` Andi Kleen
2003-07-29 19:44   ` Robin Holt
2003-08-13  4:40   ` Martin Pool
2003-08-13 11:04     ` Andi Kleen
2003-08-25 12:16       ` Greg Stark
2003-08-25 16:23         ` Andi Kleen
2003-08-26 13:39           ` Greg Stark
2003-08-27 13:49           ` Alan Cox
2003-08-30 10:35             ` Pavel Machek
2003-09-02 20:40 Tolentino, Matthew E
  -- strict thread matches above, loose matches on Subject: below --
2003-08-28 17:08 Tolentino, Matthew E
2003-08-28 20:24 ` Alan Cox
2003-07-18 20:06 linas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.