From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 3 08:03:11 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 1080A106566B for ; Thu, 3 Mar 2011 08:03:11 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from defout.telus.net (defout.telus.net [204.209.205.30]) by mx1.freebsd.org (Postfix) with ESMTP id A27518FC08 for ; Thu, 3 Mar 2011 08:03:10 +0000 (UTC) Received: from edmwcm03 ([204.209.205.13]) by priv-edmwes51.telusplanet.net (InterMail vM.8.01.03.00 201-2260-125-20100507) with ESMTP id <20110303080304.SYFZ9447.priv-edmwes51.telusplanet.net@edmwcm03> for ; Thu, 3 Mar 2011 01:03:04 -0700 Received: from oliver.bc.lan ([66.183.53.162]) by edmwcm03 with bizsmtp id EY331g01Z3VzCbE01Y33Dc; Thu, 03 Mar 2011 01:03:04 -0700 X-Telus-Outbound-IP: 66.183.53.162 X-Authority-Analysis: v=1.1 cv=X9rcaziX+10GahXZ2mN8brc3QgEqBDtfVyXTeyj1OEU= c=1 sm=2 a=ZLM83dXrbFwA:10 a=8nJEP1OIZ-IA:10 a=Pean2klS5YVZkl_le0QA:9 a=CrpXPcH4N2Nhui53NL0--SQynlQA:4 a=wPNLvfGTeEIA:10 Received: from [10.111.111.113] (unknown [10.111.111.113]) by oliver.bc.lan (Postfix) with ESMTP id 425196455; Thu, 3 Mar 2011 00:03:03 -0800 (PST) Message-ID: <4D6F4B36.6010808@telus.net> Date: Thu, 03 Mar 2011 00:03:02 -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> <201103010800.35666.jhb@freebsd.org> <4D6D50AC.701@telus.net> <201103011713.40140.jhb@freebsd.org> In-Reply-To: <201103011713.40140.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 12:22:15 +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 08:03:11 -0000 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. Until it is fixed, please tell me how I can reliably query an existing kernel for a list of its functional modules/drivers. --Carl