kern/57985: nvmm.kmod is class MISC but opening /dev/nvmm autoloads it as class DRIVER

[campbell+netbsd%mumble.net@localhost]

>Number:         57985
>Category:       kern
>Synopsis:       nvmm.kmod is class MISC but opening /dev/nvmm autoloads it as class DRIVER
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Mar 03 00:45:00 +0000 2024
>Originator:     Taylor R Campbell
>Release:        current, 10, 9
>Organization:
The NetBSDVMM Foundation
>Environment:
>Description:
nvmm.kmod is defined with MODULE_CLASS_MISC:

   1446 MODULE(MODULE_CLASS_MISC, nvmm, NULL);

https://nxr.netbsd.org/xref/src/sys/dev/nvmm/nvmm.c?r=1.47#1446

However, the system tries to autoload it with MODULE_CLASS_DRIVER when if it is not currently loaded when you open /dev/nvmm:

    895 			(void)module_autoload(name, MODULE_CLASS_DRIVER);

https://nxr.netbsd.org/xref/src/sys/miscfs/specfs/spec_vnops.c?r=1.218#895

This mismatch produces a spurious error message to the console:

WARNING: module error: incompatible module class 1 for `nvmm' (wanted 3)

The message is spurious because there's no other harmful consequences, so this contributes to warning fatigue.
>How-To-Repeat:
modunload nvmm
qemu-system-x86_64 -accel nvmm ...
>Fix:
Yes, please!

It is tempting to just switch it to MODULE_CLASS_DRIVER, but this may have the side effect of changing when initialization happens when it is a built-in module, which means that things like cpu_feature used by nvmm init might not be ready yet:

- The kernel initializes all modules of MODULE_CLASS_DRIVER before autoconf starts, early in configure: https://nxr.netbsd.org/xref/src/sys/kern/init_main.c?r=1.547#773
- The kernel doesn't initialize modules of MODULE_CLASS_MISC until after autoconf has detected devices, shortly before selecting root and dump devices: https://nxr.netbsd.org/xref/src/sys/kern/init_main.c?r=1.547#662

This is an unfortunate conflict between two different concepts: autoconf drivers, and /dev node drivers.  Modules implementing autoconf drivers need to be loaded before autoconf, but the nvmm module implements a /dev node driver which can be triggered by autoload.