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?

On Feb 18, 2025, at 16:04, Warner Losh <[email protected]> wrote:

> On Tue, Feb 18, 2025 at 4:57 PM Mark Millard <[email protected]> wrote:
>> On Feb 18, 2025, at 14:01, Warner Losh <[email protected]> wrote:
>> > 
>> > On Tue, Feb 18, 2025 at 2:56 PM Warner Losh <[email protected]> wrote:
>> >> 
>> >> On Sat, Feb 15, 2025 at 10:04 AM Mark Millard <[email protected]> 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.

So I reenabled having virtio_gpu in my kernel builds, rebuilt, and
then installed the update. I then created:

# more /boot/device.hints 
# This is for virtio_gpu --for avoiding its use under Parallels:
# dmesg -a | grep -i "virtio.*gpu"
# virtio_pci1: <VirtIO PCI (modern) GPU adapter> mem 0x10000000-0x17ffffff,0x18008000-0x18008fff,0x18000000-0x18003fff at device 10.0 on pci0
hint.virtio_pci.1.disabled="1"

On reboot virtio_gpu was not substituted for efifb . Strings on
the kernel.CA76-NODBG/kernel showed virtio_gpu was again present
and kernel.CA76-NODBG.old/kernel showed no such text.

In other words: it all worked just fine.

I do not know if some variation of this would make a good
commented-out example in /usr/src/sys/arm64/conf/GENERIC.hints
or not.

===
Mark Millard
marklmi at yahoo.com