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?

Warner Losh <[email protected]>
Newsgroups gmane.os.freebsd.current,gmane.os.freebsd.devel.arm
Message-ID <CANCZdfrUxEiEtEZfO3G9L=aN44KYtCZ_-AQFLsz=vRJvQ+XORw@mail.gmail.com>
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.

Warner
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.