Date: Thu, 12 Feb 2015 22:56:55 +0000 From: Andrew Turner <andrew@fubar.geek.nz> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arm@freebsd.org Subject: Re: FreeBSD/arm64 MACHINE/MACHINE_ARCH identification Message-ID: <20150212225655.26c865aa@bender.lan> In-Reply-To: <EC5AAE72-F553-4F31-8768-9854B6EE2C69@bsdimp.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> <228428CC-4042-4902-90A4-E7040F4BFFF5@bsdimp.com> <CAPyFy2BKzhiA4tbi-mXd6T114_zawmWTi3XbyXiUcgijQfHdyw@mail.gmail.com> <54DCE9B5.8040203@freebsd.org> <EC5AAE72-F553-4F31-8768-9854B6EE2C69@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 12 Feb 2015 11:37:38 -0700 Warner Losh <imp@bsdimp.com> wrote: >=20 > > On Feb 12, 2015, at 10:58 AM, Nathan Whitehorn > > <nwhitehorn@freebsd.org> wrote: > >=20 > > On 02/12/15 09:15, Ed Maste wrote: > >>>> 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 com= pelling 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. > >=20 > > I would assume uname -m would be "arm", not "arm64". Unless there > > are fundamental platform differences you are baking in somehow, > > which I don't know. >=20 > arm would be a pleasing outcome, but looking at his WIP tree, it > looks like it would be possible, but rather inconvenient to merge the > arm64 bits back under arm and make them conditional. They are two different architectures. They don't share any assembly, and the exception handling is different, both in exception types and number of modes/levels. Along with this they only sort of share the special registers. The method to access them is different, on 32-bit it is via a coprocessor call where on 64-bit there is an instruction to get them by name. We may be able to share some of the new pmap code, however it would need a lot of work as the virtual memory layout is different and it is likely we will need to handle 64k granules on arm64 in the future. Because of this any sharing there would need to be handled carefully. The interrupt controller and timer drivers will be shared, but these are both devices and maybe they should be moved under sys/dev. The two architectures will share very little code or headers. An ARMv8 core may be able to execute either 32 or 64-bit code (both are optional so either one or both options will be enabled) so there is a case for use to handle cc -m32, but I don't feel this is enough justification to merge two otherwise different architectures just because they were designed by the same company. Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150212225655.26c865aa>