Date: Tue, 18 Feb 2025 15:57:14 -0800 From: Mark Millard <marklmi@yahoo.com> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: No GENERIC.hints for aarch64 (arm64?), armv7, and more; also /sys/ based paths are referenced but seem to not be universally standard; also which ARCH standard in path? Message-ID: <FDE404AE-0E82-469F-BBC5-4B61FE77535B@yahoo.com> In-Reply-To: <CANCZdfpeg070CTCqWYBFZKouK3EHsv15kOJ%2B73fnS-0G2zz7LQ@mail.gmail.com> References: <82B278D1-6483-438A-AAA5-DFD809B2E736.ref@yahoo.com> <82B278D1-6483-438A-AAA5-DFD809B2E736@yahoo.com> <CANCZdfqSG2j7PDenfAC9fboC4hYuq0ND7hxLunO0yosKJ0UjCw@mail.gmail.com> <CANCZdfpeg070CTCqWYBFZKouK3EHsv15kOJ%2B73fnS-0G2zz7LQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 18, 2025, at 14:01, Warner Losh <imp@bsdimp.com> wrote: >=20 > On Tue, Feb 18, 2025 at 2:56=E2=80=AFPM Warner Losh <imp@bsdimp.com> = wrote: >>=20 >> On Sat, Feb 15, 2025 at 10:04=E2=80=AFAM Mark Millard = <marklmi@yahoo.com> wrote: >>> [This seems likely to not be limited to main [so: 15 as stands]. >>> But I'm using main as the example for the issue.] >>>=20 >>> In: >>>=20 >>> # man 5 device.hints >>> DEVICE.HINTS(5) FreeBSD File Formats Manual = DEVICE.HINTS(5) >>>=20 >>> NAME >>> device.hints =E2=80=93 device resource hints >>>=20 >>> . . . >>>=20 >>> FILES >>> /boot/device.hints Device resource = hints file. >>> /sys/ARCH/conf/GENERIC.hints Sample resource = hints for the >>> GENERIC kernel. >>> /sys/ARCH/conf/NOTES Notes on the kernel >>> configuration file = and device >>> resource hints. >>> . . . >>>=20 >>>=20 >>>=20 >>> For reference: >>>=20 >>> # find -s / -name GENERIC.hints -print >>> /usr/src/sys/amd64/conf/GENERIC.hints >>> /usr/src/sys/i386/conf/GENERIC.hints >>> /usr/src/sys/powerpc/conf/GENERIC.hints >>>=20 >>>=20 >>> Multiple points: >>>=20 >>> ) It seems that aarch64 (arm64?) and armv7 (arm?) have no >>> such GENERIC.hints file. The same goes for riscv64 >>> (riscv?). >>>=20 >>> The intent for powerpc64 , powerpc64le , and powerpcspe >>> may have the same issue. >>>=20 >>>=20 >>> ) At least for how the local systems were installed, there >>> is no such place predefined as /sys/ , not even as a >>> symbolic link. "man 7 hier" does not list such. >>>=20 >>> So it seems /sys -> /usr/src/sys is intended. (But >>> /usr/src/ need not have been populated, leaving a >>> lack of any GENERIC.hints in such a case.) >>>=20 >>> Best to not to depend on /sys in the notation shown? >>>=20 >>>=20 >>> ) The /ARCH/ reference is unclear vs. MACHINE, >>> MACHINE_CPUARCH, and MACHINE_ARCH. The example paths >>> existing for GENERIC.hints do not help because they >>> all allow MACHINE =3D=3D MACHINE_CPUARCH , >>> MACHINE =3D=3D MACHINE_ARCH , and >>> MACHINE_CPUARCH =3D=3D MACHINE_ARCH. However, based on the >>> NOTE paths: >>=20 >> Like all things kernel, it's MACHINE. >>=20 >>> # find -s /usr/src/ -name NOTES -print | grep /conf/NOTES | more >>> /usr/src/sys/amd64/conf/NOTES >>> /usr/src/sys/arm/conf/NOTES >>> /usr/src/sys/arm64/conf/NOTES >>> /usr/src/sys/conf/NOTES >>> /usr/src/sys/i386/conf/NOTES >>> /usr/src/sys/powerpc/conf/NOTES >>> /usr/src/sys/riscv/conf/NOTES >>> /usr/src/sys/x86/conf/NOTES >>>=20 >>> None of of the MACHINE* are right: x86 is not one of >>> any of the 3. Otherwise /arm64/conf/NOTES would suggest >>> MACHINE as the only possibility if /ARCH/ was uniform >>> for relative to the 3 MACHINE* possibilities. So?: >>>=20 >>> /usr/src/sys/arm64/conf/GENERIC.hints >>> /usr/src/sys/arm/conf/GENERIC.hints >>> /usr/src/sys/riscv/conf/GENERIC.hints >>>=20 >>> with no aarch64 , armv7 , powerpc64* , powerpcspe , or >>> riscv64 examples? >>=20 >> We store these in /dev/null these days :). >>=20 >> I'll create empty ones for this. >=20 > https://reviews.freebsd.org/D49052 Thanks. > Just to expand a little: These platforms don't have legacy devices > they need to hard-wire in various ways, unlike the other platforms. > However, people use them to do device instance wiring, so I've created > the empty ones. An example can also be disabling something that needs to be avoided for some unusual reason, such as avoiding virtio_gpu under parallels on aarch64 macOS. (I've not tested doing that yet.) =3D=3D=3D Mark Millard marklmi at yahoo.com =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FDE404AE-0E82-469F-BBC5-4B61FE77535B>