[lkml]   [2012]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 00/36] AArch64 Linux kernel port
    Hash: SHA1

    El Tue, 17 Jul 2012 22:33:33 -0400
    Jon Masters <> 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)

    -----END PGP SIGNATURE-----
     \ /
      Last update: 2012-07-18 18:01    [W:0.028 / U:5.272 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site