Date: Tue, 8 Aug 2006 13:50:33 +0400 From: Yar Tikhiy <yar@comp.chem.msu.su> To: John Baldwin <jhb@FreeBSD.org> Cc: Sam Leffler <sam@errno.com>, src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: cvs commit: src/sys/net if_vlan.c Message-ID: <20060808095033.GL54416@comp.chem.msu.su> In-Reply-To: <200608041644.08533.jhb@freebsd.org> References: <200608030959.k739x9N6007207@repoman.freebsd.org> <200608041314.24161.jhb@freebsd.org> <20060804200154.GC31805@ns1.xcllnt.net> <200608041644.08533.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 04, 2006 at 04:44:07PM -0400, John Baldwin wrote:
>
> To be honest, as someone who works with bug reports, I'd actually like
> backtraces up front w/o requiring the user to compile a custom kernel, etc.
> Having a simple backend in place and kdb_backtrace()'s where relevant would
> be very handy. :)
>
> > > Places that call kdb_enter() aren't all #ifdef KDB IIRC. It's
> > > just a feature that kdb_foo() functions become NOPs when the kernel isn't
> > > configured for debugging, so I think the #ifdef KDB's would be redundant.
> >
> > None of the kdb_*() functions in src/sys/kern/subr_kdb.c turn into
> > NOPs when option KDB is not present. They are all unconditionally
> > functional by design and should therefore be called conditionally
> > by consequence.
>
> Well, given that separation, I'm not sure KDB is the right option to make
> calls conditional. Rather, some specific is-debugging-enabled? option (like
> INARIANTS or FOO_DEBUG) should be used instead. i.e.:
>
> #ifdef FOO_DEBUG
> if (foo_bad) {
> printf("foo is bad\n");
> kdb_backtrace();
> }
> #endif
>
> I don't think that warrants an extra #ifdef KDB.
Please excuse me, but there is a small inconsistency in your words.
On the one hand, you wish users could obtain and post backtraces
with no special efforts. This is a great point because users don't
always have time or resources to reproduce a problem with kernel
debug features enabled, and some weird problems defy reproducing.
On the other hand, you suggest putting kdb_backtrace() calls under
secial #ifdef's. That would effectively cancel out the benefits
from using kdb_backtrace() for "mild debugging" because you would
still have to have the users re-compile their kernels or modules
and try to catch the bug again. A call to kdb_backtrace() is cheap,
so there is little sense in leaving it out from production kernels
and modules. IMHO the only case when it should be done is when the
consistency check around kdb_backtrace() is expensive and sits on
a performance-critical path.
--
Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060808095033.GL54416>