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

[Ingo Molnar <mingo@kernel.org>]

* Arnd Bergmann <arnd@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