listing all modules compiled into a kernel instance

Carl k0802647 at
Thu Mar 3 17:37:27 UTC 2011

On 2011-03-03 7:08 AM, John Baldwin wrote:
> 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.

Thanks for the great explanation, John. What prompted this thread was me 
wanting to know which *.ko files corresponded to functionality already 
included in the kernel. And ucom became a point of focus, in part, 
because no less than 13 different man pages specify that "device ucom" 
is required in the configuration file despite the fact that the GENERIC 
kernel has no such statement and contains ucom. Since the man pages are 
therefore in error, I've already provided HPS with a patch that perhaps 
he will use to correct the man pages.


More information about the freebsd-hackers mailing list