Re: Module related stuff

Richard Henderson (
Sun, 24 May 1998 11:57:04 -0700

On Mon, May 25, 1998 at 04:06:49AM +1000, Paul Gortmaker wrote:
> - (mp->flags == MOD_RUNNING) && (mp->nsyms > 0)) {
> + (mp->flags & MOD_RUNNING) && (mp->nsyms > 0)) {

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);
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

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to