I think this may be a bug in get_module_symbol:
diff -ur linux-pre104/kernel/module.c linux/kernel/module.c
--- linux-pre104/kernel/module.c Sun May 24 15:09:08 1998
+++ linux/kernel/module.c Sun May 24 20:09:21 1998
@@ -961,7 +961,7 @@
for (mp = module_list; mp; mp = mp->next) {
if (((modname == NULL) || (strcmp(mp->name, modname) == 0)) &&
- (mp->flags == MOD_RUNNING) && (mp->nsyms > 0)) {
+ (mp->flags & MOD_RUNNING) && (mp->nsyms > 0)) {
for (i = mp->nsyms, sym = mp->syms;
i > 0; --i, ++sym) {
which prevents one from getting/using the module symbols of a module
if any other flags are set. Also, I think the behaviour of the same
function is unclear if CONFIG_MODVERSIONS is enabled. For example, a
test (within a module) for kmod support like:
if (get_module_symbol("", "request_module") == 0) {
printk("%s: module auto-load (kmod) support not present.\n", driver);
printk("%s: parent unable to auto-load daughter module.", driver);
return -ENOSYS;
}
will fail if CONFIG_MODVERSIONS is enabled, but work if it is not
enabled. Since get_module_symbol is currently not used anywhere in
the kernel, I doubt that this has affected anything else but what
I'm working on.
BTW, modules that request "daughter" modules via kmod during their
own initialization works quite well. The only problem is that the
daughter is not marked in use by the parent that loaded it, and so
you can accidentally unload the daughter while the parent is still
using it. Somehow the mod->deps need to be updated to reflect the
parent's dependence on the daughter module when it is loaded, but
I'm not sure of the best way to do this.
Paul.
PS: kerneld (now dead) is still mentioned in MAINTAINERS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu