Date: Thu, 03 Mar 2011 09:37:22 -0800 From: Carl <k0802647@telus.net> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: listing all modules compiled into a kernel instance Message-ID: <4D6FD1D2.1060404@telus.net> In-Reply-To: <201103031008.36250.jhb@freebsd.org> References: <4D6C78D3.5090803@telus.net> <201103011713.40140.jhb@freebsd.org> <4D6F4B36.6010808@telus.net> <201103031008.36250.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D6FD1D2.1060404>