Date: Thu, 12 Feb 2015 09:57:12 -0800 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: freebsd-arm@freebsd.org Subject: Re: FreeBSD/arm64 MACHINE/MACHINE_ARCH identification Message-ID: <54DCE978.8030104@freebsd.org> In-Reply-To: <CAPyFy2ATn5xgsvePCdvzqnyBS45izVHdL8yLaQQoKeJenSv9tg@mail.gmail.com> References: <CAPyFy2A=Ev5gdYPKgEE0LS3-1sY%2BXmkZA7VCe71E6Fmbb=vMRw@mail.gmail.com> <607BF592-A09B-4DB4-9872-C9E63066AB57@bsdimp.com> <CAPyFy2Bgrap3TkFNuChyMC0Vwbjdt5FVW0ey03XtkK1iwNL1KQ@mail.gmail.com> <71E9C1B9-F819-420B-90A5-A36D58E71817@bsdimp.com> <CAPyFy2ATn5xgsvePCdvzqnyBS45izVHdL8yLaQQoKeJenSv9tg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/12/15 08:05, Ed Maste wrote:
> On 12 February 2015 at 01:54, Warner Losh <imp@bsdimp.com> wrote:
>>
>> They moved the sources in the kernel from aarch64 to arm64. I’m sure.
>
> 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.
>
>> config.guess uses uname -p:
>>
>> *:FreeBSD:*:*)
>> UNAME_PROCESSOR=`/usr/bin/uname -p`
>> echo ${UNAME_PROCESSOR}-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`
>> exit ;;
>
> Ah, yes - it looks like this has changed repeatedly over time, and I
> must have looked at a rather outdated config.guess. It's clear from
> this snippet though that this is a special case for FreeBSD, and most
> other cases rely on uname -m. I also found a few other configure-like
> scripts that only use uname -m.
>
>> so uname -p must be ‘aarch64’ since that’s what is expected.
>
> Yes, I agree this is necessary.
>
>> uname -m must
>> be arm64 unless we move our kernel implementation to sys/aarch64 from the
>> sys/arm64 it is now.
>
> 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.
I don't think we will (or should). We've had platforms where they don't
match for years and years (I'm writing you this email on one such system
now) and have had very little trouble with it. In the wild, close enough
to all code does the right thing that we don't need to worry about it.
In the few cases where it doesn't, ports already has the relevant patches.
-Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54DCE978.8030104>