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

From: Dennis Gilmore
Date: Wed Jul 18 2012 - 11:27:20 EST

Hash: SHA1

El Tue, 17 Jul 2012 22:33:33 -0400
Jon Masters <jonathan@xxxxxxxxxxxxxx> escribiÃ:
> On 07/17/2012 06:35 PM, Joe Perches wrote:
> > On Tue, 2012-07-17 at 23:18 +0100, Catalin Marinas wrote:
> >
> >> The uname will still report
> >> "aarch64" to match the compiler triplet and also avoid confusion of
> >> existing 32-bit ARM scripts that simply check for "arm*" in the
> >> machine name.

that means that the yum base arch will need to be aarch64 and the arch
used in rpm will be aarch64 also. its throwing something weird and
confusing right in the face of users. I urge you to change it all to
arm64 just changing the directory in the kernel is pointless as it still
exposes all the weirdness of the name to users and will result in a
large amount of education and a constant stream of the same question
"Where do i find the arm64 bits?" until such time as the users learn
that arm64 is aarch64. All the tooling uses "uname -m" to determine the
package architecture.

The triplet that fedora will use will be preferred
arm64-redhat-linux-gnu or aarch64-redhat-linux-gnu

but again aarch64 will propogate to a lot of highly visible places
where it will just cause undue confusion. adding a extra check for
arm64* before arm* if that is what people are using will not be hard to

> > The compiler triplet seems trivial to change.
> >
> > The other bit is a relatively weak argument as the 32bit arm
> > scripts can be changed or fixed likely just as easily.
> There's a surprising amount of assumption out there around what arm*
> means (or doing wildcard matches liberally). I'm glad (from the point
> of view of a distribution bootstrap) that we don't have to worry
> about that aspect of getting AArch64 support up and running. The
> directory name is just that - a name - and unimportant. I like
> aarch64 from the point of view of distinguishing "this is not ARM,
> no, it's not just an extension, and no it's not just two numbers
> different or wider regs", but it seems fairly inevitable that it's
> going to be arch/arm64. The main thing is that we understand this
> isn't like i686->x86_64.

autoconf etc checks for " arm-* | armbe-* | armle-* | armeb-* |
armv*-* " arm64-* will not match the existing regexs in common
use. configure scripts will need rebuilding regardless of if its
aarch64 or arm64 to me the argument that arm64 will catch existing
scripts is extremely weak. especially when the first target is really
almost completely new for arm in the server market.

Version: GnuPG v2.0.18 (GNU/Linux)

N‹§²æìr¸›yúèšØb²X¬¶ÇvØ^–)Þ{.nÇ+‰·¥Š{±‘êçzX§¶›¡Ü}©ž²ÆzÚ&j:+v‰¨¾«‘êçzZ+€Ê+zf£¢·hšˆ§~†­†Ûiÿûàz¹®w¥¢¸?™¨è­Ú&¢)ßf”ù^jÇy§m…á@A«a¶Úÿ 0¶ìh®å’i