Date: Sat, 7 Apr 2001 17:37:27 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Greg Lehey <grog@lemis.com> Cc: FreeBSD-arch@FreeBSD.ORG Subject: Re: Making ddb a kld Message-ID: <Pine.BSF.4.21.0104071718190.62414-100000@besplex.bde.org> In-Reply-To: <20010406150129.O66503@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 6 Apr 2001, Greg Lehey wrote: > A little over a year, I did some work for Sitara Networks. In the > course of this work, I made ddb an lkm, in order to be able to load it > on a production system if needed. > > I'm now in the process of merging Sitara's code, which is based on > 3.2-RELEASE, into RELENG_4. Sitara have generously agreed that we can > commit any fixes they have in their tree which are not vital to their > commercial interests. The ddb mods would be one of them. Do we want > to do this? Of course not. > The pros and cons I see are: > > Pro: > > 1. We often get people who say "my system crashes. Why". On > checking, there's no practical way to determine why, because they > don't have a debugger in the system. They can run gdb if they have a panic dump. I have thought of making ddb backtraces for panics a standard part of the kernel. People shouldn't need to know how to run ddb or ddb to produce useful crash reports. Having an loadable ddb is not much more useful than having a ddb option. It will never be there when you need it unless you always configure it. > 2. Occasionally it's convenient to look at what's happening in a > running system. Admittedly, you have to freeze the system to use > ddb, but it can be of use. Again, it is better to always configure ddb, in case you need it to look at what's happening on a hung system that can't load a module. > Con: > > 1. This will require moving all the ddb code, which is scattered > around the system, into a separate file. I'm prepared to do the > work, but it's possible that somebody would complain about the > colour of the bikeshed. Here's your chance. This would demodularise all the code that is scattered around the system. It would also give the nice version mismatch problems: e.g., ps in the kernel would tend to panic the whole system where ps in userland would just panic itself. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0104071718190.62414-100000>