Re: [PATCH 00/36] AArch64 Linux kernel port

[Catalin Marinas]

On Mon, Jul 16, 2012 at 12:53:21AM +0100, Linus Torvalds wrote:
> On Sun, Jul 15, 2012 at 4:21 PM, Måns Rullgård <mans@xxxxxxxxx> wrote:
> >
> > FWIW, I'd prefer naming the directory either arm64 or armv8 for a few
> > reasons:
> >
> > - Those are the names people actually use to refer to the architecture
> > - They are more descriptive.
> > - I think the official name is rather silly.
> 
> Agreed on those three for arm64.
> 
> However, please don't use the *INSANE* ARM "v8" naming.

I agree, ARMv8 is not the right name to use in this situation. It doesn't
qualify whether the system is running in 32 or 64-bit mode. ARMv8 is the
name of the latest ARM architecture and we expect this number to go up
in the future. It introduces the new 64-bit execution mode with new
exception model and instruction set called AArch64. ARMv8 may also
support the 32-bit (AArch32) mode which is backwards compatible with the
ARMv7 architecture.

The AArch64 mode will most likely be found in future ARM architecture
versions, so breaking the link between the Linux port and the
architecture version is the right thing. For this reason, uname no
longer reports "armv*" in the 64-bit port but simply "aarch64" (for
compat tasks it still uses the old style). CPU features available to
user space are already advertised via the hwcap bits.

That said, the directory name of the Linux port does not have to match
the name of the architecture or execution mode (we had arch/arm26/ until
a few years ago). So I'm ok with renaming the directory to arch/arm64/,
together with the CONFIG_ARM64* symbols. The uname will still report
"aarch64" to match the compiler triplet and also avoid confusion of
existing 32-bit ARM scripts that simply check for "arm*" in the machine
name.

-- 
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/