lkml.org 
[lkml]   [2012]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 00/36] AArch64 Linux kernel port
    Date
    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


    \
     
     \ /
      Last update: 2012-07-07 21:41    [W:4.454 / U:0.308 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site