From: Keith Owens <kaos@ocs.com.au> To: torvalds@transmet.com Subject: Removal of get/put_module_symbol, 2.4 Date: Thu, 19 Oct 2000 15:54:49 +1100 I started work on the removal of get/put_module_symbol and immediately hit problems, these functions are not being used the way we thought. Instead of being used as weak linkage from one module to another, people are using get_module_symbol in kernel code to decide if a module needs to be loaded and, once loaded, to extract symbols from the module. In other words, the dependency chain now goes kernel->module instead of module->kernel. IMNSHO this is wrong and should be removed ASAP. It is confusing, it runs the risk of circular dependencies, it hard codes function names into kernel code instead of letting each module define its own interfaces, each new module requires changes to kernel code. Most of the existing code will not work with symbol versions. get_module_symbol() is in the wrong place and has the wrong interface to pick up versioned symbols. AFAICT all of the uses of get_module_symbol(), with the possible exception of agp support, are being used because people were too lazy to create register_xxx interfaces. Instead of the module registering itself on load like almost every other module, the lookup work is pushed back onto the kernel. This is not a clean interface. Unless somebody can come up with a good reason why they absolutely need get_module_symbol(), it will be removed. Sources that only need to know if an existing function has already been loaded (e.g. agsupport.c needs to know if agp_free_memory has been loaded) will be replaced with weak external references. Sources that issue request_module() then use get_module_symbol() to look inside the module will be changed to use a registration system, as almost every module already does. This will affect mtd, agp and 8390. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/