From owner-svn-src-all@FreeBSD.ORG Fri Mar 20 16:44:10 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 8D26F106566B; Fri, 20 Mar 2009 16:44:10 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout020.mac.com (asmtpout020.mac.com [17.148.16.95]) by mx1.freebsd.org (Postfix) with ESMTP id 7309F8FC1F; Fri, 20 Mar 2009 16:44:10 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from macbook-pro.jnpr.net ([66.129.224.36]) by asmtp020.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KGT00CW6D55Q620@asmtp020.mac.com>; Fri, 20 Mar 2009 09:43:54 -0700 (PDT) Message-id: <458289DF-A730-453D-81D3-DAB8631A9F34@mac.com> From: Marcel Moolenaar To: Marius Strobl In-reply-to: <20090320163359.GH59320@alchemy.franken.de> Date: Fri, 20 Mar 2009 09:42:32 -0700 References: <200903192040.n2JKeoYY075200@svn.freebsd.org> <31910B64-3437-4C1D-8234-FC6A1C3D4F8B@mac.com> <20090320133648.GE59320@alchemy.franken.de> <20090320163359.GH59320@alchemy.franken.de> X-Mailer: Apple Mail (2.930.3) 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 16:44:11 -0000 On Mar 20, 2009, at 9:33 AM, Marius Strobl wrote: >> >>>>> 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. >> >> The functions in subr_kdb.c have been made standard (i.e >> non-optional) so that they can actually be used safely >> from modules without having to worry about whether the >> kernel has some option enabled. So, option KDB doesn't >> control their visibility. >> >> A debugger is present when either DDB or GDB is defined. >> So, option KDB doesn't control that either. >> >> Option KDB doesn't do much. For the most part it guards >> code that results in entry into the debugger. > > Okay, I now see why you objected to r190105. It wasn't an objection, just a remark. > My point > is that in this case the code in question doesn't > need such protection (just as a module not using KDB > wouldn't have) as there's no relevant impact on > functionality, performance or security here but > especially in r190106 removing it improves readability. My only real objection is that this creates an inconsistency between platforms. By removing option KDB the kernel will not respect -d (or boot_kdb=1) on any platform but sparc64. There's a user-visible impact. I would prefer that we keep all platforms the same so that documentation can apply uniformly and isn't only applicable to i386. I'm perfectly happy if uniformity is achieved by removing the ifdef from all platforms :-) Anyway: it's not a big deal in any case. -- Marcel Moolenaar xcllnt@mac.com