|| ||Ingo Molnar <mingo-AT-kernel.org> |
|| ||Arnd Bergmann <arnd-AT-arndb.de> |
|| ||Re: [PATCH 00/36] AArch64 Linux kernel port |
|| ||Tue, 10 Jul 2012 09:10:23 +0200|
|| ||Olof Johansson <olof-AT-lixom.net>,
Catalin Marinas <catalin.marinas-AT-arm.com>,
Linus Torvalds <torvalds-AT-linux-foundation.org>,
Russell King <linux-AT-arm.linux.org.uk>,
Andrew Morton <akpm-AT-linux-foundation.org>,
Alan Cox <alan-AT-lxorguk.ukuu.org.uk>|
|| ||Article, Thread
* Arnd Bergmann <email@example.com> wrote:
> 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, [...]
So why not change it now, when it only bothers a few dozen
people and it is only present in 36 patches? Why go full steam
ahead to annoy thousands of people with it and why spread the
naming madness to thousands of commits?
> [...] and I'd much prefer to just call it arm64 as well.
Then do it! :-)
arch/aarch64/ is a heck of a toungue twister, it's double typing
all over the place and if everyone calls it arm64 anyway I'd
suggest you change the code, not people!
> [...] 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. [...]
Doesn't really matter in practice: we have arch/x86/ which isnt
the elf triplet either, and besides some minimal kbuild glue
it's not an issue, and having a good short name matters quite a
bit when trying to write good kernel code.
Wouldn't be the first time the GNU toolchain embarked on silly,
user-hostile naming. i386-unknown-Linux, anyone?
So there's no valid technical reason there that I can see.
> [...] 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.
> > 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.
Just for the record, you guys are repeating all the same
arguments that led to the x86_64 fork a decade ago...
With the difference that the case for unifying platforms seems
even *stronger* in the ARM space than it is in the x86 space:
32-bit computing will probably stay around with us far longer in
the gadget and appliance space than in the server space.
Thinking that arm64 will only be limited to servers is rather
It all reminds me of what Sir John Templeton said: “The four
most dangerous words in investing are, it’s different this
to post comments)