listing all modules compiled into a kernel instance

[Carl]

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