Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Jan 2011 11:40:16 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, Doug Barton <dougb@freebsd.org>, src-committers@freebsd.org
Subject:   Re: svn commit: r217213 - head/lib/bind
Message-ID:  <4D2CA410.108@bsdimp.com>
In-Reply-To: <201101110847.24284.jhb@freebsd.org>
References:  <201101092347.p09NlB4M060802@svn.freebsd.org> <201101101433.18847.jhb@freebsd.org> <4D2BE4F8.3030902@FreeBSD.org> <201101110847.24284.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 01/11/2011 06:47, John Baldwin wrote:
> On Tuesday, January 11, 2011 12:04:56 am Doug Barton wrote:
>> I have no objection to putting it back to the state that it was in at
>> r209886, although frankly less diffs to RELENG_[78] without good reason
>> make my life easier.
> 209886 did not use MACHINE_CPUARCH for ISC_ATOMIC_ARCH, and in fact the file
> is now back to the 209886 state (nwhitehorn did not change ISC_ATOMIC_ARCH
> to use MACHINE_CPUARCH).
>
> Fixing this does create diffs to [78] because MACHINE_CPUARCH is not present
> at all in [78], but that is because [78]'s handling of different endians for
> mips, arm, etc. is deficient.  You are likely stuck with using MACHINE_CPUARCH
> for 9+ and MACHINE_ARCH for<= 8.

I've created compatibility shims for MACHINE_CPUARCH in RELENG_8, but 
not for RELENG_7 (at least in some places, now that I go looking for 
it).  I'm thinking seriously of MFCing it to make future MFCs easier, 
especially for some MIPS work that I've been doing.

In -current, Doug's likely will operate correctly for quite some time.  
We're not going to change MACHINE_ARCH of i386 or amd64.  At most, we'll 
change MACHINE_CPUARCH to x86, but that would be a lot of work to 
undertake in the whole tree...  The only down-side is that it increases 
by two the number of MACHINE_ARCH instances that I need to audit when I 
sweep the tree looking for problems.  If there's no good reason for the 
chaff, I change it.  If there is, like this case, I note it as good and 
move on.

While I'd prefer to have everything converted, I'm willing to be 
flexible when necessary...

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D2CA410.108>