At the moment, insmod explicitly allows a module to define symbols that
are already defined in the kernel or by other modules. Richard
Henderson even patched modutils 2.2-pre to ensure that when this
occurs, the first (kernel) definition is used. There is no way to tell
if anybody is using this feature so forbidding it is problematical.
Also it would only work for modules that export symbols, many do not
which is why ksymoops had so many problems with Oops in modules. It is
not safe to look at all symbols in a module, there are guaranteed to be
conflicts on static and global but unexported symbols, leading to false
rejections of modules.
What happens when you load the same module more than once, under a
different name? For example,
insmod -o fred1 fred.o
insmod -o fred2 fred.o
I'm not knocking the idea, just that implementation is not as easy as
it seems. One possibility is adding an explicit symbol to every object
that can be compiled as a module but is currently compiled into the
kernel. Something like __NO_MODULE_LOAD_modname. Then insmod modname
looks for __NO_MODULE_LOAD_modname and refuses to load. Those rare
objects that can be compiled in and still be safely loaded as a module
would #define MODULE_AND_KERNEL_OK at the start of the code, before
#include <modules.h>. I could probably do this with a simple change to
modules.h, cost is an entry in the symbol table and either 0 or 1 byte
per object that can be compiled as an object.
Comments?
-
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/