From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 17:37:27 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 002B9106566B for ; Thu, 3 Mar 2011 17:37:26 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from defout.telus.net (outbound04.telus.net [199.185.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id A6B298FC12 for ; Thu, 3 Mar 2011 17:37:26 +0000 (UTC) Received: from edtncm04 ([199.185.220.240]) by priv-edtnes24.telusplanet.net (InterMail vM.8.01.03.00 201-2260-125-20100507) with ESMTP id <20110303173725.PVHA18968.priv-edtnes24.telusplanet.net@edtncm04> for ; Thu, 3 Mar 2011 10:37:25 -0700 Received: from oliver.bc.lan ([66.183.53.162]) by edtncm04 with bizsmtp id EhdQ1g00k3VzCbE01hdQ3w; Thu, 03 Mar 2011 10:37:25 -0700 X-Telus-Outbound-IP: 66.183.53.162 X-Authority-Analysis: v=1.1 cv=Hhb8vUndaQ9JqXo/Swdf63bQvjw2wPrzWawgI51+Yeo= c=1 sm=2 a=ZLM83dXrbFwA:10 a=8nJEP1OIZ-IA:10 a=0KaIw0TcgJitHo1wxPkA:9 a=K4nJAcBs16x5mvLyh-gA:7 a=Y38DdXB3A-cePQTD6_EelwXR_z0A:4 a=wPNLvfGTeEIA:10 Received: from [10.111.111.113] (unknown [10.111.111.113]) by oliver.bc.lan (Postfix) with ESMTP id CC0256455; Thu, 3 Mar 2011 09:37:23 -0800 (PST) Message-ID: <4D6FD1D2.1060404@telus.net> Date: Thu, 03 Mar 2011 09:37:22 -0800 From: Carl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: John Baldwin References: <4D6C78D3.5090803@telus.net> <201103011713.40140.jhb@freebsd.org> <4D6F4B36.6010808@telus.net> <201103031008.36250.jhb@freebsd.org> In-Reply-To: <201103031008.36250.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 03 Mar 2011 19:08:13 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: listing all modules compiled into a kernel instance X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 17:37:27 -0000 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