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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/