Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 Feb 2015 09:29:25 -0700
From:      Warner Losh <imp@bsdimp.com>
To:        Ed Maste <emaste@freebsd.org>
Cc:        "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>
Subject:   Re: FreeBSD/arm64 MACHINE/MACHINE_ARCH identification
Message-ID:  <228428CC-4042-4902-90A4-E7040F4BFFF5@bsdimp.com>
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 Feb 12, 2015, at 9:05 AM, Ed Maste <emaste@freebsd.org> wrote:
>=20
> On 12 February 2015 at 01:54, Warner Losh <imp@bsdimp.com> wrote:
>>=20
>> They moved the sources in the kernel from aarch64 to arm64. I=E2=80=99m=
 sure.
>=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.

Traditionally in Linux, they have been a matched set.

>> config.guess uses uname -p:
>>=20
>>    *:FreeBSD:*:*)
>>        UNAME_PROCESSOR=3D`/usr/bin/uname -p`
>>        echo ${UNAME_PROCESSOR}-unknown-freebsd`echo =
${UNAME_RELEASE}|sed -e 's/[-(].*//'`
>>        exit ;;
>=20
> 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.
>=20
>> so uname -p must be =E2=80=98aarch64=E2=80=99 since that=E2=80=99s =
what is expected.
>=20
> Yes, I agree this is necessary.

One done, one to go :)

>> uname -m must
>> be arm64 unless we move our kernel implementation to sys/aarch64 from =
the
>> sys/arm64 it is now.
>=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.

This one I=E2=80=99m not on board with. You=E2=80=99ve not made a =
compelling case for
it yet. Some scripts is a little vague for my liking, especially given =
the
justification for amd64 we had at the time we made that decision (they
were also about compatibility, official names, and vague notions of
correctness).

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. There=E2=80=99s also a number of places we test different =
of these variables
against arm*<mumble> 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.

Warner=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?228428CC-4042-4902-90A4-E7040F4BFFF5>