On Tue, Feb 18, 2025 at 4:57 PM Mark Millard <mark...@yahoo.com> wrote:
> On Feb 18, 2025, at 14:01, Warner Losh <i...@bsdimp.com> wrote: > > > > On Tue, Feb 18, 2025 at 2:56 PM Warner Losh <i...@bsdimp.com> wrote: > >> > >> On Sat, Feb 15, 2025 at 10:04 AM Mark Millard <mark...@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.] > >>> > >>> In: > >>> > >>> # man 5 device.hints > >>> DEVICE.HINTS(5) FreeBSD File Formats Manual > DEVICE.HINTS(5) > >>> > >>> NAME > >>> device.hints – device resource hints > >>> > >>> . . . > >>> > >>> 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. > >>> . . . > >>> > >>> > >>> > >>> For reference: > >>> > >>> # 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 > >>> > >>> > >>> Multiple points: > >>> > >>> ) It seems that aarch64 (arm64?) and armv7 (arm?) have no > >>> such GENERIC.hints file. The same goes for riscv64 > >>> (riscv?). > >>> > >>> The intent for powerpc64 , powerpc64le , and powerpcspe > >>> may have the same issue. > >>> > >>> > >>> ) 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. > >>> > >>> 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.) > >>> > >>> Best to not to depend on /sys in the notation shown? > >>> > >>> > >>> ) 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 == MACHINE_CPUARCH , > >>> MACHINE == MACHINE_ARCH , and > >>> MACHINE_CPUARCH == MACHINE_ARCH. However, based on the > >>> NOTE paths: > >> > >> Like all things kernel, it's MACHINE. > >> > >>> # 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 > >>> > >>> 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?: > >>> > >>> /usr/src/sys/arm64/conf/GENERIC.hints > >>> /usr/src/sys/arm/conf/GENERIC.hints > >>> /usr/src/sys/riscv/conf/GENERIC.hints > >>> > >>> with no aarch64 , armv7 , powerpc64* , powerpcspe , or > >>> riscv64 examples? > >> > >> We store these in /dev/null these days :). > >> > >> I'll create empty ones for this. > > > > 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.) > I'm open to commenting out such things. Warner
