[LWN Logo]
[Timeline]
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/