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

[Arnd Bergmann <arnd@arndb.de>]

On Saturday 07 July 2012, Olof Johansson wrote:

> > ARM introduced AArch64 as part of the ARMv8 architecture
> 
> With the risk of bikeshedding here, but I find the name awkward. How
> about just naming the arch port arm64 instead? It's considerably more
> descriptive in the context of the kernel.  For reference, we didn't
> name ppc64, nor powerpc, after what the IBM/power.org marketing people
> were currently calling the architecture at the time either.

I agree the name sucks, and I'd much prefer to just call it arm64
as well. The main advantage of the aarch64 name is that it's the
same as the identifier in the elf triplet, and it makes sense to
keep the same name for all places where we need to identify the
architecture. This also includes the rpm and dpkg architecture names,
and the string returned by the uname syscall. If everything else
is aarch64, we should use that in the kernel directory too, but
if everyone calls it arm64 anyway, we should probably use that name
for as many things as possible.

> > There is no hardware platform available at this point. From a kernel
> > perspective, the aim is to minimise (or even completely remove) the
> > platform code from the architecture specific directory. FDT is currently
> > mandated and there are ongoing discussions for ACPI support.
> 
> This will be interesting to see how it plays out over time, and how
> many vendors will drop in arm64 cores on their existing designs and
> thus need to pull over infrastructure from arch/arm for their platform
> type. A lot of the drivers have moved out to common code so much of it
> should be possible to do cleanly, but there is still some risk for
> duplication.

For new platforms, the risk is very low, even if they want to support
the same peripherals in both 32 and 64 bit kernels, since almost all
of that can be in drivers/ already. The main missing bits are the
lack of a place to put irqchip drivers (I think there are already
patches to create drivers/irqchip/) and dma engines require platform
specific setup code because of the lack of DT bindings (also being
worked on).

I'm a little more worried about platforms that have an existing 32 bit
code base and have developers that want to reuse the existing code.
We have to make it very clear from the start that copying platform
code from arch/arm to arch/arm64 is not acceptable. Using Makefile
magic to redirect into the 32 bit platform directory would be a
possibility but I would really hope we can get everyone to do a clean
64 platform from the start, and hopefully move the 32 bit code over
to use the same drivers over time, and drastically shrink their
exisiting platform code.

> I guess it's a good chance to clean up some of it and start from a
> clean slate, if you can avoid the temptation of just moving over code.

Agreed. It's clear from the code that it started out as a copy of the
32 bit ARM code base, which I think was a mistake, but it has also
moved on since then and many areas of the 64 bit code are now much
cleaner because they don't have to worry about breaking legacy code.
We're also more flexible with trying out stuff without having to
worry about breaking some 10 year old board code.

	Arnd