From owner-svn-src-all@FreeBSD.ORG Fri Mar 20 14:00:18 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C3301065674; Fri, 20 Mar 2009 14:00:18 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 1C6BE8FC08; Fri, 20 Mar 2009 14:00:17 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id n2KDam33037451; Fri, 20 Mar 2009 14:37:10 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id n2KDamnU037450; Fri, 20 Mar 2009 14:36:48 +0100 (CET) (envelope-from marius) Date: Fri, 20 Mar 2009 14:36:48 +0100 From: Marius Strobl To: Marcel Moolenaar Message-ID: <20090320133648.GE59320@alchemy.franken.de> References: <200903192040.n2JKeoYY075200@svn.freebsd.org> <31910B64-3437-4C1D-8234-FC6A1C3D4F8B@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31910B64-3437-4C1D-8234-FC6A1C3D4F8B@mac.com> User-Agent: Mutt/1.4.2.3i Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r190105 - head/sys/sparc64/sparc64 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2009 14:00:19 -0000 On Thu, Mar 19, 2009 at 05:06:52PM -0700, Marcel Moolenaar wrote: > > On Mar 19, 2009, at 1:40 PM, Marius Strobl wrote: > > >Author: marius > >Date: Thu Mar 19 20:40:49 2009 > >New Revision: 190105 > >URL: http://svn.freebsd.org/changeset/base/190105 > > > >Log: > > There's no need to wrap kdb_enter() in #ifdef KDB as it's always > >available. > > That's not quite how it works. > > option KDB is used to build the kernel with debugging features > that could impact performance, security and/or functionality. > In this case it's not so much a matter of whether kdb_enter() > is defined or not, but rather whether the kernel should respect > -d. > That's generally true but the places where I removed #ifdef KDB don't have an impact on security, performance doesn't matter and -d still does nothing if there's no debugger available (which in turn would require options KDB, at least according to documentation). I'm not sure what your're actually trying to say; following your logic strictly would mean that subr_kdb.c shouldn't be standard but only compiled in when options KDB is present. Marius