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.

--Carl
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Reply via email to