FreeBSD/arm64 MACHINE/MACHINE_ARCH identification

[Warner Losh]

> On Feb 11, 2015, at 10:41 AM, Ed Maste <emaste at FreeBSD.org> wrote:
> 
> The FreeBSD/arm64 work in progress currently reports "arm64" for the
> machine and processor type - i.e., uname -m and uname -p.

Linux used the original aarch64, but later changed to arm64. I suggest
that we follow this carefully. We botched the naming of amd64 and have
dozens of warts in our build system because of it.

> It seems that the official, awkward name aarch64 is broadly used
> elsewhere - for example, in toolchain triples and autoconf tests.  To
> save us grief in the future I think it is worth following suit:
> 
> diff --git a/sys/arm64/include/param.h b/sys/arm64/include/param.h
> index 5cd0445..525a0e7 100644
> --- a/sys/arm64/include/param.h
> +++ b/sys/arm64/include/param.h
> @@ -43,10 +43,10 @@
> #define STACKALIGN(p)  ((uint64_t)(p) & ~STACKALIGNBYTES)
> 
> #ifndef MACHINE
> -#define        MACHINE         "arm64"
> +#define        MACHINE         "aarch64"
> #endif

This defines the kernel architecture. History with amd64 suggests that we should have had machine amd64 an machine_arch x86_64. We have modo places in the tree, and in external files, that do a s/amd64/x86_64/ that’s only done for amd64.

> #ifndef MACHINE_ARCH
> -#define        MACHINE_ARCH    "arm64"
> +#define        MACHINE_ARCH    "aarch64"
> #endif
> 
> I'm not proposing that we rename any of the source files.  I believe
> this approach is consistent with the Debian project - they call it the
> "arm64" port, but report aarch64 from uname.

You can’t propose this change and *NOT* be proposing we rename the system files.
$MACHINE *IS* the directories that we keep the kernel files in, by definition.

> I believe it will be much easier for us to carry around any
> special-case s/aarch64/arm64/ in the base system (if necessary) than
> trying to teach third-party software that the FreeBSD 64-bit ARM
> architecture is called arm64 instead of aarch64.
> 
> Any objections or concerns?

I strongly object to the MACHINE change for reasons stated above, but the MACHINE_ARCH
is likely a very good change since it aligns with the expected values for configuring things like
clang, gcc, bintuils, etc.

We should also change Makefile.inc to set MACHINE_ARCH to aarch64 when MACHINE is arm64.

Warner