FreeBSD/arm64 MACHINE/MACHINE_ARCH identification

Warner Losh imp at bsdimp.com
Thu Feb 12 16:29:29 UTC 2015


> On Feb 12, 2015, at 9:05 AM, Ed Maste <emaste at freebsd.org> wrote:
> 
> On 12 February 2015 at 01:54, Warner Losh <imp at bsdimp.com> wrote:
>> 
>> They moved the sources in the kernel from aarch64 to arm64. I’m sure.
> 
> Oh - I don't care what directory Linux puts the kernel source in, only
> what's reported by uname.  As far as I can tell that has always been
> aarch64 for uname -m.

Traditionally in Linux, they have been a matched set.

>> config.guess uses uname -p:
>> 
>>    *:FreeBSD:*:*)
>>        UNAME_PROCESSOR=`/usr/bin/uname -p`
>>        echo ${UNAME_PROCESSOR}-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`
>>        exit ;;
> 
> Ah, yes - it looks like this has changed repeatedly over time, and I
> must have looked at a rather outdated config.guess. It's clear from
> this snippet though that this is a special case for FreeBSD, and most
> other cases rely on uname -m.  I also found a few other configure-like
> scripts that only use uname -m.
> 
>> so uname -p must be ‘aarch64’ since that’s what is expected.
> 
> Yes, I agree this is necessary.

One done, one to go :)

>> uname -m must
>> be arm64 unless we move our kernel implementation to sys/aarch64 from the
>> sys/arm64 it is now.
> 
> We might decide that "uname -m" has to be aarch64 to match
> expectations of third-party software set by other operating systems.
> If that in turn means we have to move the kernel source, so be it.

This one I’m not on board with. You’ve not made a compelling case for
it yet. Some scripts is a little vague for my liking, especially given the
justification for amd64 we had at the time we made that decision (they
were also about compatibility, official names, and vague notions of
correctness).

One other area that these choices impact the system is in the MACHINE_CPUARCH
macro, which is derived from MACHINE_ARCH (-p), so it might need another
special case. There’s also a number of places we test different of these variables
against arm*<mumble> that will need to be audited if we make this change as well.
Thankfully, there’s only about a dozen. While not externally visible, any change here
will need to make sure we’re consistent when building.

Warner


More information about the freebsd-arm mailing list