Adding a MACHINE_ARCH note

[Nathan Whitehorn]

On 07/10/13 16:31, Baptiste Daroussin wrote:
> On Wed, Jul 10, 2013 at 03:27:12PM -0600, Warner Losh wrote:
>> On Jul 10, 2013, at 3:24 PM, Baptiste Daroussin wrote:
>>
>>>
>>> You should look at how MACHINE_CPUARCH vs MACHINE vs MACHINE_ARCH works.
>>>
>>> Keep in mind that amd64/i386/pc98 should probably have MACHINE_CPUARCH of x86,
>>> but we just haven't done that yet.  If we did that I think you could follow
>>> src's conventions and be fine.  Something like:
>>>
>>> os:version:cpuarch:arch
>>>
>>> Where cpuarch == MACHINE_CPUARCH (should be x86 on amd64/i386/pc98, but isn't
>>> yet.  It ss sane on other platforms) and
>>> arch == MACHINE_ARCH (amd64/i386 (for pc98 MACHINE_ARCH is i386))
>>>
>>> So that would give:
>>>
>>> freebsd:9:x86:amd64
>>> freebsd:9:x86:i386 (for both pc98 and i386)
>>> freebsd:9:arm:armv6
>>>
>>> etc.
>>>
>>> I think that means we could eventually support x32 as:
>>>
>>> freebsd:9:x86:x32
>>>
>>> We might have an x32 world (but perhaps not a kernel?, though we would need
>>> the headers to DTRT)
>>> I do like the idea a lot.
>> We should add a flag to uname to get MACHINE_CPUARCH, and publish it as hw.cpu_arch in sysctl.
>>
> I will still have to workaround on older releases. The one without those
> informations.
>
> regards,
> Bapt

On those systems, I think you can easily get away with assuming hw.abi 
== `uname -p`. Installing i386 packages on amd64 systems (or powerpc on 
powerpc64 or ...) will likely require some infrastructure work anyway 
and hw.abi is a perfect quick MFC candidate.  A few quick special cases 
will solve any remaining problems almost universally.
-Nathan