Actually, it should be more like the test in qm_symbols:
if ((mod->flags & (MOD_RUNNING | MOD_DELETED)) != MOD_RUNNING)
well, the inverse of that.
And come to think of it, I have no idea why there exists a
get_module_symbol. I think perhaps it has been there for a
long time and I didn't kill it with the rewrite early in the
2.1 series.
> Also, I think the behaviour of the same
> function is unclear if CONFIG_MODVERSIONS is enabled.
Yep. You could perhaps use the string comparison test from modutils
when it is throwing away symbol versioning:
/* String comparison for non-co-versioned kernel and module. */
static int
ncv_strcmp(const char *a, const char *b)
{
size_t alen = strlen(a), blen = strlen(b);
if (blen == alen + 10 && b[alen] == '_' && b[alen+1] == 'R')
return strncmp(a, b, alen);
else if (alen == blen + 10 && a[blen] == '_' && a[blen+1] == 'R')
return strncmp(a, b, blen);
else
return strcmp(a, b);
}
> 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.
You might consider not using it at all. What are you up to anyway?
> 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.
No, you need to handle this yourself, because mod->deps only describe
symbol dependancies, not usage. So you must mark the daughter in use
with MOD_INC_USE_COUNT.
Without knowing exactly what you are up to, I would recommend an
interface like the following:
parent exports:
struct my_child {
struct my_child *next, *prev;
struct module *the_child;
void (*foo)();
int (*bar)();
int etc;
};
void register_child (struct my_child *);
child does:
static struct my_child {
0, 0, &__this_module,
child_foo, child_bar
} me;
void init_module(void) {
register_child (&me);
}
void cleanup_module(void) {
unregister_child (&me);
}
Now the parent can just request the module as normal and the child
gives you all the information you might have previously found with
get_module_symbol. The parent protects the child against garbage
collection with __MOD_INC_USE_COUNT (ptr->the_child).
This is similar to the way the scsi subsystem treats its modules.
r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu