listing all modules compiled into a kernel instance

[John Baldwin]

On Thursday, March 03, 2011 3:03:02 am Carl wrote:
> On 2011-03-01 2:13 PM, John Baldwin wrote:
> >> On 2011-03-01 5:00 AM, John Baldwin wrote:
> >>>> Maybe ucom doesn't appear because it doesn't have a DRIVER_MODULE()
> >>>> declaration (because it isn't a driver).
> >>>
> >>> Yes, that would explain it.
> >>
> >> I can explicitly include ucom in a kernel by adding "device ucom" in the
> >> configuration file, in which case it would call DRIVER_MODULE(), right?
> >> That would then make it appear in the "kldstat -v" list? So why is it a
> >> driver when it's done explicitly, but not a driver when done implicitly?
> >> That makes no sense to me since the functionality doesn't change. IMHO,
> >> this is a bug that needs to be fixed, not just for ucom but any
> >> implicitly included driver.
> >
> > No, the _source_ code of device ucom has to explicitly say "I am a module
> > named 'foo'" using a DECLARE_MODULE() macro (or another macro such as
> > DRIVER_MODULE() that invokes DECLARE_MODULE()).  The 'device ucom' in a config
> > file does not generate this, that is just an instruction that config(8) uses
> > when looking in sys/conf/files to see which C source files to include in the
> > kernel build.
> 
> My wording was unclear. I do understand that it's the source code rather 
> than the configuration file that invokes the macro. The argument I am 
> making is that no matter how the ucom source code ends up being compiled 
> into the kernel, the end result is that the ucom device is functionally 
> present and available at run time. As such, it makes no sense to me that 
> one can discover it's presence/availability with "kldstat -v" _only_ 
> when compiled in as a consequence of a "device ucom" statement. As a 
> user I care about accurate reporting when I query for information and 
> currently "kldstat -v" cannot be relied upon. I shouldn't have to 
> concern myself with what mechanism caused ucom to be included, but only 
> that it was. Moreover, I suggest that for all practical purposes, a 
> module is a module by virtue of its behaviour, not because 
> DECLARE_MODULE() was invoked. Thus my assertion that this is a bug.

Ah, but your assertion is what is wrong.  There is no 'apic' module for
'device apic' for example.  Also, a single 'device foo' might enable
multiple "modules" (e.g. if foo supports devices on both PCI and ISA
buses, you will have foo/pci and foo/isa modules).

A module != a kld.  A kld file may contain zero or more modules.  Most kld's
include at least one module.

> Until it is fixed, please tell me how I can reliably query an existing 
> kernel for a list of its functional modules/drivers.

There are ways to query multiple things about the kernel, but they are more
specific than a nebulous "module" concept:

- kldstat lists the kld's currently loaded
- kldstat -v lists the declared modules in all of the kld's
- lsvfs lists the filesystems currently available
- all new-bus device drivers end up in the kldstat -v output as
  'driver/parent', but this does not work for devices that are actually
  support libraries shared by other drivers (e.g. ucom).

ucom is a bit special as it isn't an actual driver, it's a library of routines
shared by various USB serial drivers: u3g, uark, ubsa, uftdi, etc.  Those are
the "real" drivers that one would want to test for.  By itself 'device ucom'
doesn't buy you anything.  'device ucom' is probably dubious as if you put
'device u3g' in your kernel config, the kernel will automatically include the
USB serial driver library routines.  If you 'kldload u3g.ko' it will
automatically load 'ucom.ko' as a dependency, so an explicit 'device ucom' is
generally not needed.  There is no 'device uether' for the common USB ethernet
routines shared by all the USB ethernet drivers (though there is a uether.ko),
and 'device ucom' should probably be removed.

-- 
John Baldwin