From owner-freebsd-arm@FreeBSD.ORG Thu Feb 12 17:26:30 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 638E04C5 for ; Thu, 12 Feb 2015 17:26:30 +0000 (UTC) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A71FFEC for ; Thu, 12 Feb 2015 17:26:30 +0000 (UTC) Received: by pdjy10 with SMTP id y10so13259028pdj.6 for ; Thu, 12 Feb 2015 09:26:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=86jM1JweKAz/7o3VDqKaBpPMqd3KAifIKzdqsQ7rLJg=; b=I4y+CffC2pqOkEzOZy96Ee/EZYKN6Xv5VhpG4QOCmdYYn3MMNPSd1tza/4N1Vn2x7c J26hUJ/7w3ChFrhATas+1yqyLl0YAPV6fb8tQ8m7hJaUZkhVHgNBt3X3gpZ3u811t7aN kMV2mKY62DD1F5CAfCkwwrX8fogTx+UmdedWs8zWVXnZHlcCfryBB4JieEdstBPP47nc 1dwzwDfr31b4W6/v9lXiMKi/EigZLBlxxfC5l0PkTEsDdDX8H418p/8fTdEV9mcpwKAP KudoAdXwjOZ+YFKKo/2/7HdTGSZGcIUWKeFKEmMyo/h56/vg+spam1zBFClU5EdiLx79 jOvA== X-Gm-Message-State: ALoCoQkX4kWBiJLVqN58Xt2HxE8ql/E7feOfJbWGEvCK87WzOym9p8Ec8JjHAnqVt7lm1hvMpP5u X-Received: by 10.70.36.174 with SMTP id r14mr8314307pdj.148.1423761989254; Thu, 12 Feb 2015 09:26:29 -0800 (PST) Received: from [10.64.26.244] ([69.53.236.236]) by mx.google.com with ESMTPSA id pr5sm4275437pdb.92.2015.02.12.09.26.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Feb 2015 09:26:28 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: FreeBSD/arm64 MACHINE/MACHINE_ARCH identification From: Warner Losh In-Reply-To: Date: Thu, 12 Feb 2015 10:26:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <84AC4061-2FF8-4066-8C38-D5240F7FB86A@bsdimp.com> References: <607BF592-A09B-4DB4-9872-C9E63066AB57@bsdimp.com> <71E9C1B9-F819-420B-90A5-A36D58E71817@bsdimp.com> <228428CC-4042-4902-90A4-E7040F4BFFF5@bsdimp.com> To: Ed Maste X-Mailer: Apple Mail (2.2070.6) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2015 17:26:30 -0000 > On Feb 12, 2015, at 10:15 AM, Ed Maste wrote: >=20 >>> Oh - I don't care what directory Linux puts the kernel source in, = only >>> what's reported by uname. As far as I can tell that has always been >>> aarch64 for uname -m. >>=20 >> Traditionally in Linux, they have been a matched set. >=20 > Ok, it appears they may have abandoned this. >=20 >>> We might decide that "uname -m" has to be aarch64 to match >>> expectations of third-party software set by other operating systems. >>> If that in turn means we have to move the kernel source, so be it. >>=20 >> This one I=E2=80=99m not on board with. You=E2=80=99ve not made a = compelling case for >> it yet. >=20 > That's why I said "we might decide" -- I'm not sure myself. >=20 > However, there's no backwards compatibility concern here, we've never > had a FreeBSD release that reports "arm64" for "uname -m". There's no > reason for us to prefer "arm64" if everyone else uses "aarch64." > Also, having arm64 for uname -m and aarch64 for uname -p seems a bit > odd. They are different because they can be different. The machine name for pc98 is pc98 not i386. It=E2=80=99s the platform, while the machine_arch = name is i386 since that=E2=80=99s the cpu abi it is built on. FWIW, netbsd reports =E2=80=98amd64=E2=80=99 for the machine and = =E2=80=98x86_64=E2=80=99 for machine_arch which is one of the reasons I know ours is wrong :( >> One other area that these choices impact the system is in the = MACHINE_CPUARCH >> macro, which is derived from MACHINE_ARCH (-p), so it might need = another >> special case. >=20 > There's a special case already for TARGET_TRIPLE :C/arm64/aarch64/. We=E2=80=99ll likely need more of this sort of thing. which is kinda a = pita. >> There=E2=80=99s also a number of places we test different of these = variables >> against arm* that will need to be audited if we make this = change as well. >> Thankfully, there=E2=80=99s only about a dozen. While not externally = visible, any change here >> will need to make sure we=E2=80=99re consistent when building. >=20 > Yes, I'm not too worried about the naming within our tree - dealing > with a few dozen tests in the FreeBSD tree is much easier than trying > to change expectations of third-party software. My worry is that they get fixed at the same time any name changes, which weren=E2=80=99t in the patches :) I=E2=80=99m not at all sure what the right thing here will be. Warner=