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
_______________________________________________
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"
