Created attachment 183822 [details] v0 All architectures in arch(7) manpage use `uname -p` but aarch64 seems to use `uname -m`. This prohibits adding another architecture based on arm64 e.g., aarch32.
(In reply to Jan Beich from comment #0) > All architectures... Err, pc98 was another exception.
This is just an FYI. Mention has been made of trying to have uname results that match up with what might be tested in upstream linux materials for ports. (The context was the potential armv7l split from armv6.) Unfortunately when I tried uname in a couple of linux contexts and then looked at 3 GNU or Linux source code for uname I found that only uname -m seems to be common for content across the 3 examples. See, for example, the notes in: https://lists.freebsd.org/pipermail/freebsd-arm/2017-June/016325.html In particular: linux distributions seem to put uname -p to various uses with different text, modifying source or applying patches to GNU source to do so. (This is separate from potential variability in kernel vintages or variations: that might add more variability.) My guess is FreeBSD will stick with its -m and -p usage independent of Linux. Otherwise -m would be following whatever linux generally does but -p can not really be made to match overall.
Looking at: https://www.freebsd.org/cgi/man.cgi?query=arch&apropos=0&sektion=0&manpath=FreeBSD+12-current&arch=default&format=html ia64 and pc98 are only mentioned in the table of of initial and final releases as head (12) does not support them: ia64 5.0 10.x . . . pc98 2.2 11.x The only place in arch(7) mentions "aarch64" is: arm64 __aarch64__ Just to be specific for uname's existing behavior for arm64/aarch64 (on a head version): pine64# uname -m arm64 pine64# uname -p aarch64 pine64# uname -apKU FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT r317015M arm64 aarch64 1200028 1200028 so uname itself has room for uname -p returning aarch32 someday. Also TARGET_ARCH=aarch64 works so it has room for TARGET_ARCH=aarch32 as well. I expect that the default arm64 will always be aarch64 so that TARGET_ARCH=aarch64 is not required and TARGET=arm64 is sufficient --but for aarch32 TARGET_ARCH=aarch32 would be required if it is ever added, say for spporting cortex-a32 that is armv8-a but aarch32 only (no aarch64 state mode).
(In reply to Mark Millard from comment #3) I should have noticed and reported that the web page that I referenced (looking up 12's) does say: HISTORY An arch manual page appeared in FreeBSD 12. FreeBSD 11.1 May 16, 2017 FreeBSD 11.1 which would indicate that for: pc98 2.2 11.x pc98 should still be covered but is not.
A commit references this bug: Author: ian Date: Sun Aug 5 22:24:39 UTC 2018 New revision: 337364 URL: https://svnweb.freebsd.org/changeset/base/337364 Log: Document 64-bit arm in terms of arch name (aarch64) not machine (arm64). Other architectures are documented in terms of the name that is displayed by 'uname -p', aka MACHINE_ARCH and TARGET_ARCH in the build system, now aarch64 matches the rest of them. PR: 220297 Changes: head/share/man/man7/arch.7
A commit references this bug: Author: ian Date: Mon Apr 22 15:26:22 UTC 2019 New revision: 346562 URL: https://svnweb.freebsd.org/changeset/base/346562 Log: MFC r337364: Document 64-bit arm in terms of arch name (aarch64) not machine (arm64). Other architectures are documented in terms of the name that is displayed by 'uname -p', aka MACHINE_ARCH and TARGET_ARCH in the build system, now aarch64 matches the rest of them. PR: 220297 Changes: _U stable/11/ stable/11/share/man/man7/arch.7