FreeBSD/arm64 MACHINE/MACHINE_ARCH identification

Warner Losh imp at bsdimp.com
Thu Feb 12 17:26:30 UTC 2015


> On Feb 12, 2015, at 10:15 AM, Ed Maste <emaste at FreeBSD.org> wrote:
> 
>>> 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.

They are different because they can be different. The machine name for
pc98 is pc98 not i386. It’s the platform, while the machine_arch name is
i386 since that’s the cpu abi it is built on.

FWIW, netbsd reports ‘amd64’ for the machine and ‘x86_64’ for
machine_arch which is one of the reasons I know ours is wrong :(

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

We’ll likely need more of this sort of thing. which is kinda a pita.

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

My worry is that they get fixed at the same time any name changes, which
weren’t in the patches :)

I’m not at all sure what the right thing here will be.

Warner


More information about the freebsd-arm mailing list