if i might follow up on the earlier thread (because it reminded me
that i'm not clear *myself* on the mechanics here), what is the proper
way to support both manually-loadable module params that also extends
to building that module into the kernel?
for out-of-tree modules, it's easy, i know that. but the instant
you decide to incorporate that module/driver into the kernel, you want
to be able to initialize that driver the same way at boot time.
as a real-life example, consider this snippet from
Documentation/kernel-parameters.txt:
i8042.debug [HW] Toggle i8042 debug mode
i8042.direct [HW] Put keyboard port into non-translated mode
i8042.dumbkbd [HW] Pretend that controller can only read data from
keyboard and cannot control its state
(Don't attempt to blink the leds)
i8042.noaux [HW] Don't check for auxiliary (== mouse) port
i8042.nokbd [HW] Don't check/create keyboard port
i8042.noloop [HW] Disable the AUX Loopback command while probing
for the AUX port
... and so on ...
clearly(?), those commandline parms refer to the "i8042" module
that's been built into the kernel, right? the corresponding source
file, drivers/input/serio/i8042.c, defines those parms in the obvious
way:
static bool i8042_nokbd;
module_param_named(nokbd, i8042_nokbd, bool, 0);
MODULE_PARM_DESC(nokbd, "Do not probe or use KBD port.");
static bool i8042_noaux;
module_param_named(noaux, i8042_noaux, bool, 0);
MODULE_PARM_DESC(noaux, "Do not probe or use AUX (mouse) port.");
... etc etc ...
but what is the underlying mechanism by which *that* particular
driver is identified by the prefix "i8042"? if i look down that
source file, i eventually get to this:
...
static struct platform_driver i8042_driver = {
.driver = {
.name = "i8042",
.owner = THIS_MODULE,
#ifdef CONFIG_PM
.pm = &i8042_pm_ops,
#endif
},
.remove = __devexit_p(i8042_remove),
.shutdown = i8042_shutdown,
};
...
is that driver.name field value of "i8042" what associates that
prefix "i8042" with the settable driver parms? i'm sure i could
figure this out if i read the source, but if someone else just wants
to clarify that, that would be terrific. or explain to me what's
*actually* happening. thanks.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
