> In the AArch32 kernel port many implementation decisions newer > architectures were made in a way that preserves backwards compatibility > to over 15 years ago (and for *good* reasons, ARMv4 hardware is still in > use). But keeping the same decisions in AArch64 is wrong.
Same argument as x86-32 v x86-64. Same issues about compatibility. > AArch64 is also in its early days with a lot of developments to come > (and still waiting for hardware). Until we really know the final shape, > the AArch64 code base must allowed to evolve independently from the > AArch32 one. That is one area where while the merge was needed and a lot of work the original split may well have been sensible for x86-64 as well. > The initial target is servers (see the companies that have announced > plans around ARMv8) but I agree, we may see it in other devices in the > future. But as the maintainer I have no plans to support a 32-bit SoC on > an AArch64/ARMv8 system (which may or may not support AArch32 at kernel > level). If an AArch64 SoC would share some devices with an AArch32 SoC, > such code will go to drivers/. What plans to other maintainers and board vendors have ? Any design choice has to cope with these happening if a third party goes and does it. Alan -- 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/