From owner-cvs-all@FreeBSD.ORG Tue Aug 8 09:50:55 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57D0416A4E1; Tue, 8 Aug 2006 09:50:55 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E2D843D62; Tue, 8 Aug 2006 09:50:50 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k789oZBs067314; Tue, 8 Aug 2006 13:50:35 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k789oYKX067308; Tue, 8 Aug 2006 13:50:34 +0400 (MSD) (envelope-from yar) Date: Tue, 8 Aug 2006 13:50:33 +0400 From: Yar Tikhiy To: John Baldwin Message-ID: <20060808095033.GL54416@comp.chem.msu.su> References: <200608030959.k739x9N6007207@repoman.freebsd.org> <200608041314.24161.jhb@freebsd.org> <20060804200154.GC31805@ns1.xcllnt.net> <200608041644.08533.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608041644.08533.jhb@freebsd.org> User-Agent: Mutt/1.5.9i Cc: Sam Leffler , src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Marcel Moolenaar Subject: Re: cvs commit: src/sys/net if_vlan.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2006 09:50:55 -0000 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