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

[Catalin Marinas <catalin.marinas@arm.com>]

On Fri, Jul 06, 2012 at 11:58:04PM +0100, Alan Cox wrote:
> >  arch/x86/include/asm/atomic64_32.h              |    1 +
> >  arch/x86/include/asm/atomic64_64.h              |    1 +
> >  arch/xtensa/kernel/syscall.c                    |    2 +-
> 
> This looks odd to say the least ?

There are a few preparatory patches at the beginning of this series that
will be merged separately but I wanted to give the full context of why
they are needed, hence posting them together with the AArch64 code.

> The only other question I'd ask is given that ppc and x86 have both done
> 32/64bit separate architectures and then gone the other way is that
> something ARM 64bit needs to think about ?

This has been debated and there are strong reasons to keep it separate:

1. The AArch64 architecture is significantly different from AArch32 (the
official name of the 32-bit ARM architecture), it is not an extension.
It has a new exception model, new instruction set (even the register
names are different), new C ABI, PCS. It has a hardware compat mode but
that's about it, there is no interworking between the two (not allowed
by hardware, nor that the ABIs would make this possible). 

2. Easier code maintenance. While I started the kernel port from the
arch/arm/ code base (it was at a time when Linux didn't even have
generic unistd.h and the AArch64 specs kept changing) the code diverged
significantly both because of architecture differences and software
requirements like new ABI, generic headers (unistd.h, stat.h etc). The
port undergone significant rewrite following the rules for new
architecture ports and some of the few similarities will be moved to a
more generic place (like the mmu_gather patches from peterz). AArch64
SoCs are going into a more standardised direction and the SoC code will
be kept to a minimum and moved under drivers/. So merging AArch32 and
AArch64 together would be rather detrimental to code maintenance for
both architectures (#ifdef's or duplicate 32/64 files).

3. Flexibility. It's early days for AArch64, we don't have a hardware
platform supported yet and there are ongoing debates around ACPI,
firmware standardisation for CPU booting, hotplug, power management. We
need the flexibility to improve the code base without worrying about
backwards compatibility (apart from the compat layer which isn't at all
affected by the hardware developments).

-- 
Catalin