bhyve: add command to list config options

[novel]

Summary

For a software built on top of bhyve(8) and/or managing bhyve(8),
it is very convenient to know what specific features the given binary supports.
Currently, bhyve(8) provides some of this information, and it could be
retrieved by parsing bhyve -h, bhyve -s help, bhyve -l help.

Sometimes it is not enough, for example, the recently added
"oemstrings" feature cannot be fully probed using these commands.
Over time, some workarounds were suggested. Specifically:

• Mapping features to __FreeBSD_version. I see at least two issues with that:
  • __FreeBSD_version does not directly map to bhyve(8) features, so this is simply not accurate.
  • bhyve(8) might be updated separately from the system, which is not so uncommon, especially for development purposes. Then such a probing will be inaccurate.
• Manual pages parsing. I see more disadvantages with that:
  • Manual pages are meant to be read by a human. Extracting information from it by a machine is not the most convenient thing. Especially understanding side notes like: "Note, feature 'foo' is arm64-only!".
  • Manual pages might be inaccurate, they might miss options.
  • bhyve(8) could be used in an environment where manual pages are not installed.

This commit attempts to close this gap by introducing the "bhyve -o
help" command which prints all the supported configuration variables.
In my opinion, it is, in combination with the other commands mentioned
above, sufficient to retrieve most of the capabilities of the given
bhyve(8) binary.

The current implementation defines a simple configuration schema for
common and machdep code and prints out a list of supported configuration
variables for the current architecture.

It sits a bit to the side to the rest of the code which is okay for RFC
purpose.

The next step as I see it would be extending set_config*() functions
to validate the user provided values against the schema, so users get
notified early on incorrect or misspelled configuration variables.
It would also be nice to allow users to only validate their
configuration, think of 'nginx configtest / -t'.

[chuck]

I like the approach of defining the options in each module (e.g., machdep), but it would be interesting to see what this approach looks like for one of the storage devices (e.g., NVMe) which have both their own options as well as the common blockif options.

[novel]

Support module-based options sets.

[novel]

In D58419#1340678, @chuck wrote:

I like the approach of defining the options in each module (e.g., machdep), but it would be interesting to see what this approach looks like for one of the storage devices (e.g., NVMe) which have both their own options as well as the common blockif options.

That’s a good point. I’ve updated the patch to support composable option sets allowing device-specific schemas such as NVMe to inherit the common blockif options. This affects only the code structure; the output remains flat.

[bnovkov]

Thank you for working on this, this is a useful feature.
Aside from the inline comments, I have one remark regarding config_schema_merge_options.

I would suggest that you use the tree(3) RB_TREE structure as the final option container instead of a top-level struct config_schema since it would make the implementation cleaner, IMO.
It would:

1. Remove the need to call reallocarray whenever a new option gets added,
2. Remove the need for qsort,
3. Make it easier to figure out what is going on in the function due to verbs in the RB_* macros (e.g., RB_INSERT, RB_FIND).

usr.sbin/bhyve/config_schema.c

3

Please use the shorter version of the copyright header.

217–218

I would suggest putting braces around this foreach since it is not immediately obvious that this is a for loop, despite its name.

usr.sbin/bhyve/riscv/bhyverun_machdep.c

71–72

Same for the other places where you do a similar calculation.

[novel]

• Switch to tree(3) RB_TREE.
• Use shorter copyright headers.
• Format macros loops (*_FOREACH) with {}.
• sizeof(a) / sizeof(a[0]) -> nitems(a).
• Update bhyve.8.