lkml.org 
[lkml]   [1999]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectget_module_symbol and 8390.o
I am looking at the CONFIG_MODVERSIONS mess, and I have a question
about this function:

/*
* Gets the address for a symbol in the given module. If modname is
* NULL, it looks for the name in any registered symbol table. If the
* modname is an empty string, it looks for the symbol in kernel exported
* symbol tables.
*/
unsigned long
get_module_symbol(char *modname, char *symname)
{
...
}

This function is used in only two places:

drivers/net/8390.h
drivers/isdn/divert/divert_procfs.c.

In drivers/net/8390.h, "load_8390_module" uses get_module_symbol.
Looking at the callers of load_8390_module, I see that callers can use
get_module_symbol to achieve delayed name binding, like this:

/* drivers/net/wd.c */
int __init wd_probe1(struct net_device *dev, int ioaddr)
{
... probe for wd ...
if ( ... wd found .... )
load_8390_module("wd.c");
}

Someone please tell me if my understanding is correct here.

Ok, now for the putative bug. If the 8390 module was compiled with
CONFIG_MODVERSIONS on, then its public symbols will be decorated with
"foo_R12345678" style signatures. get_module_symbol doesn't know anything
about decorations. So, if CONFIG_MODVERSIONS is on, get_module_symbol
will return "no match", and this clever dynamic loading of 8390.o
will fail.

Note that 8390.o works when resident because it's an L_OBJ, not an LX_OBJ,
so that all of its symbols are treated as EXPORT_SYMBOL_NOVERS. But it
will fail if, for instance, ne2000.o and 8390.o are both modules and
CONFIG_MODVERSIONS is turned on.

Is this ringing any "aha!" bells for network driver maintainers?

I suppose the cheap fix would be to make 8390.o an M_OBJ rather than an
MX_OBJ. A less devious version is to convert all of its EXPORT_SYMBOL
calls to EXPORT_SYMBOL_NOVERS, with a little comment on them. A
straightforward, but limited, solution would be to give up get_module_symbol
and simply allow all these drivers to load the little 8390.o driver
when they load instead of doing fancy delayed loading.

I believe drivers/isdn/divert/divert_procfs.c will have the same
problem dynamically loading proc_register and proc_unregister. In this
case, I think the simplest solution is to give up using get_module_symbol.

(I got interested in this because I am writing a new CONFIG_MODVERSIONS,
and this piece of code really puzzled me.)

Michael Elizabeth Chastain
<mailto:mec@shout.net>
"love without fear"

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.053 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site