Messages in this thread | | | Date | Mon, 6 Sep 1999 05:18:24 -0500 | From | Michael Elizabeth Chastain <> | Subject | get_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/
| |