From owner-svn-src-all@FreeBSD.ORG Mon Jan 10 00:00:23 2011 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 5D5DC106567A for ; Mon, 10 Jan 2011 00:00:23 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx22.fluidhosting.com [204.14.89.5]) by mx1.freebsd.org (Postfix) with ESMTP id A00198FC1A for ; Mon, 10 Jan 2011 00:00:19 +0000 (UTC) Received: (qmail 27344 invoked by uid 399); 10 Jan 2011 00:00:19 -0000 Received: from localhost (HELO doug-optiplex.ka9q.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 10 Jan 2011 00:00:19 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4D2A4C11.9010108@FreeBSD.org> Date: Sun, 09 Jan 2011 16:00:17 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101210 Thunderbird/3.1.7 MIME-Version: 1.0 To: Warner Losh References: <201101062107.p06L7p9o028440@svn.freebsd.org> <4D27F295.1030609@FreeBSD.org> <4D28EBFE.10004@bsdimp.com> In-Reply-To: <4D28EBFE.10004@bsdimp.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Warner Losh Subject: Re: svn commit: r217071 - head/lib/bind 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: Mon, 10 Jan 2011 00:00:23 -0000 On 01/08/2011 14:58, Warner Losh wrote: > On 01/07/2011 22:13, Doug Barton wrote: >> I've said before that I like to have the opportunity to pre-commit >> review patches in this area because at minimum it helps me to be aware >> of them for potential MFC purposes. > > Thanks for the reminder Doug. Hope there's no hard feelings... Of course not. A waste of time and energy. :) > I think that bsd.endian.mk is -current only, but there's no reason it > can't be MFC'd. I'll merge it to 7 and 8 here in a few minutes and let > you know. That'd be awesome, thanks. I plan to update BIND in RELENG_7 after the release and it would be great to have the bmake stuff consistent between branches to the extent possible. >>> @@ -64,11 +65,7 @@ CFLAGS+= -I${LIB_BIND_DIR} >>> .endif >>> >>> # Use the right version of the atomic.h file from lib/isc >>> -.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386" >>> -ISC_ATOMIC_ARCH= x86_32 >>> -.else >>> -ISC_ATOMIC_ARCH= ${MACHINE_CPUARCH} >>> -.endif >>> +ISC_ATOMIC_ARCH=${MACHINE_CPUARCH:S/i386/x86_32/:S/amd64/x86_32/} >> >> This change I am less enthusiastic about. It seems to me that it does >> the exact same thing, but while admittedly quite a bit more clever >> than I am capable of I find it less readable. Unless this is doing >> something more or better than the previous code I will likely revert >> this. > > Damn. I missed that in my pre-commit review, or I'd have mentioned it in > the commit log. Feel free to revert it if you don't like it, or I'd be > happy to revert it if you wanted me to clean up my own mess. Np, I took care of it. FWIW, I should have been more clear about why I'm more interested in keeping the file readable. BIND updates come in 2 main flavors, planned, and unplanned. :) The latter are generally related to security updates, and therefore of a more urgent nature. So far we've had very good luck with my being available when updates of a more urgent nature are required, in addition to good luck in the sense that we haven't had a _truly_ urgent BIND update in some years now. Also, the bmake glue for BIND isn't all _that_ complex (thanks in large part to des) however ... My nightmare scenario is that we _do_ end up with a truly urgent BIND update, I'm not available for whatever reason, and some poor bastard is stuck with the job of having to enter the labyrinth without the benefit of the bits of the map that exist only in my head. For this reason I've tried to keep the FREEBSD-Update files both up to date and more detailed than is usually the case, but I am the last person to believe that I have done it all correctly. This particular bit of arcana (the x86_32 stuff) took me a non-trivial amount of time to decipher, so I am particularly interested in having the intention of the code to be very clear here. In any case, thanks again for your help on the endian stuff, and your fast response. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/