* Arnd Bergmann <a...@arndb.de> wrote: > > 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. > > It is slightly worrying to have multiple SoC vendors working > on their own platform support. There are a few things we can > assume though: > > * Everyone who has an AArch64 implementation has access to > Catalin's kernel patches in is basing their stuff on top of > it. > > * Most likely they are all working on server chips, which > means they want to have their hardware supported in upstream > kernels and enterprise distros.
Dunno, the moment Apple comes out with their 64-bit iPhone6 (or whichever version they'll go 64-bit) *everyone* will scramble to go 64-bit, for marketing reasons. Code and SoC details will be ported to 64-bit in the usual fashion: in the crudest, fastest possible way. There's also a technological threshold: once RAM in a typical smartphone goes above 2GB the pain of a 32-bit kernel becomes significant. We are only about a year away from that point. So are you *really* convinced that the colorful ARM SoC world is not going to go 64-bit and will all unify behind a platform, and that we can actually force this process by not accepting non-generic patches? Is such a platform design being enforced by ARM, like Intel does it on the x86 side? > * Unlike on 32 bit, the different platforms cannot be > compile-time exclusive. A platform port that cannot be enabled > without breaking another platform is not getting merged. > > * I do not expect board-specific kernel patches, at least no > more than we have them on x86 with the occasional hack to work > around a broken machine. If 64-bit hardware is made on existing SoC designs, which looks rather likely, then we are not in a position to reject kernel support for them. Saying 'no' is very rarely a valid option for hardware ugliness. We are encouraged to say 'no' for software details that is actionable by the author of the patches, but hardware ugliness is rarely actionable on that level and we are not holding our users hostage in general just to make a point about ugliness. > * The differences between SoCs will be confined to device > drivers to a much larger degree than they are on 32 bit, > partly because the SoC companies are trying to be fit into the > single-kernel model, and partly because we have added the > infrastructure to allow it. There's 600 KLOC of code in arch/arm/, that's 3 times larger than arch/x86/. Most of it is not in any fashion related to the bitness of the CPU, it's platform IO code that is in principle bitness agnostic. I have a really hard time imagining that all 64-bit ARM hardware will be supported from drivers/: IRQ controllers, timer drivers, all the ugly SoC details. Do you *really* think that all of the 32-bit ARM code should essentially be thrown away when going to 64-bit ARM, that patches can only touch arch/arm64/ + drivers/ or the highway? The moment someone adds 64-bit CPU support to arch/arm/ and it's merged we'll have an interesting situation on hand: support for the same CPU in two different architectures in the kernel tree. Anyway, I'm not an ARM person so I really don't want to make your life harder, I just wanted to potentially save you the 2 years of extreme unification stress that the x86 tree went through ;-) Thanks, Ingo -- 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/