svn commit: r366542 - in head/sys: amd64/amd64 arm/arm arm64/arm64 kern riscv/riscv sys

[Mitchell Horne]

On Thu, Oct 8, 2020 at 3:15 PM Kyle Evans <kevans at freebsd.org> wrote:
>
> On Thu, Oct 8, 2020 at 1:02 PM Mitchell Horne <mhorne at freebsd.org> wrote:
> >
> > Author: mhorne
> > Date: Thu Oct  8 18:02:05 2020
> > New Revision: 366542
> > URL: https://svnweb.freebsd.org/changeset/base/366542
> >
> > Log:
> >   Add a routine to dump boot metadata
> >
> >   The boot metadata (also referred to as modinfo, or preload metadata)
> >   provides information about the size and location of the kernel,
> >   pre-loaded modules, and other metadata (e.g. the EFI framebuffer) to be
> >   consumed during by the kernel during early boot. It is encoded as a
> >   series of type-length-value entries and is usually constructed by
> >   loader(8) and passed to the kernel. It is also faked on some
> >   architectures when booted by other means.
> >
> >   Although much of the module information is available via kldstat(8),
> >   there is no easy way to debug the metadata in its entirety. Add some
> >   routines to parse this data and allow it to be printed to the console
> >   during early boot or output via a sysctl.
> >
> >   Since the output can be lengthly, printing to the console is gated
> >   behind the debug.dump_modinfo_at_boot kenv variable as well as the
> >   BOOTVERBOSE flag. The sysctl to print the metadata is named
> >   debug.dump_modinfo.
> >
>
> Hi,
>
> Why both a tunable and boot -v? The tunable is already specifically
> scoped to just this operation, it seems a little odd to double-gate
> it.
>

Hey Kyle,

The original patch was gated behind just boot -v. In testing I
realized this change is potentially quite noisy (even by bootverbose
standards), so I added the tunable to make it opt-in. The thinking is
that you could set debug.dump_modinfo_at_boot=1 once in loader.conf
and forget it, as you wouldn't see the preload_dump() output on a
normal boot.

Thinking about it again, this might be overly complicated for what is
at best a niche debugging feature. If gating it behind just the
tunable is more in line with how other things work then I'm happy to
change it.

Mitchell

> Thanks,
>
> Kyle Evans