> There isn't really anything all that special about them. [...]
> So far as anyone really cares, they're .o's. :)
Of course they're .o's, but being able to load them into a running Linux
kernel seems to be a very special property, IMHO.
I think the crux of the matter is that one really does care that only
proper modules get loaded into the kernel -- the result of loading a
.o that *wasn't* a module would be ugly indeed. Better would be if
modules were fully version-locked in some way, so that there was a
high probability that if a module was incompatible with a particular
kernel, it would not load at all. And, ideally, if the kernel were
changed but still compatible with a particular module, the module
could be loaded unchanged. (Unfortunately, I don't understand the
module system well enough to know to what degree MODVERSIONS takes
care of this.)
Well, a random .o that doesn't have symbol table entries for
"init_module", "cleanup_module", and "kernel_version", will completely
fail to be loaded by insmod. So the possibility that insmod will
accidentally load a random .o into the kernel is pretty much nil.
The original modules scheme required that the module be compiled with
the exact same version of the kernel that it was loaded under --- that's
what's stored in the kernel_version symbol table entry. Later on,
MODVERSIONS added checksums of the function signature to the symbol
table entry, which allows for a very high probablity that if module is
incompatible with the kernel, it won't load at all; this allowed insmod
to relax the restriction that the kernel version that the module was
compiled under exactly match the currently running kernel.
- Ted