FreeBSD/arm64 MACHINE/MACHINE_ARCH identification

Ed Maste emaste at freebsd.org
Thu Feb 12 17:15:37 UTC 2015


>> 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.

Ok, it appears they may have abandoned this.

>> 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.

That's why I said "we might decide" -- I'm not sure myself.

However, there's no backwards compatibility concern here, we've never
had a FreeBSD release that reports "arm64" for "uname -m". There's no
reason for us to prefer "arm64" if everyone else uses "aarch64."
Also, having arm64 for uname -m and aarch64 for uname -p seems a bit
odd.

> 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 a special case already for TARGET_TRIPLE :C/arm64/aarch64/.

> 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.

Yes, I'm not too worried about the naming within our tree - dealing
with a few dozen tests in the FreeBSD tree is much easier than trying
to change expectations of third-party software.


More information about the freebsd-arm mailing list