Do yo mean version specific? Module versioning (CONFIG_MODVERSIONS)
overcomes this for the most part. I have a joystick module that
I compiled quite some time ago. Since I use module versioning,
that module loads easily in later kernels.
There are times that the ABI changes. This does not happen too
frequently, and when it does, usually only affects a small
subset of modules. (One must bare in mind that developmental
kernels are a different thing altogether, where fundamental
changes to the ABI can occur frequently.)
>As more modules come into the kernel, I see the opportunity for some
>standard "interface" depending on the type of module.
There is a standard interface. The kernel's ABI is exported as
a discrete set of its symbols for use by modules.
>I cannot see why the module for the 3c509 and the ne2000 have seperate
>imports and exports that are different from each other. Would this not
>clean up the kernel IO interfaces a little bit?
They also have quite a few in common.
They use what they need to use. Modules don't really "import"
anything. They link to the kernel. The kernel exports it's
ksyms (kernel symbols) so that the linker (insmod) can link
the module to the kernel. Modules can "export" symbols for
other modules to use. This allows things like the bsd
compressor to attach to the PPP module. It would make no
sense allow the bsd compressor to link to a kernel without
PPP support.
>I am thinking of something like the Novell or Microsoft drivers that
>they load. In a sense, you could call them modules, the only difference
>is that they have a common calling structure.
The kernel has a very well defined module interface. The
kernel *always* calls the module's init function when it
loads and *always* calls the module's release function
before it unloads. The modules have a standard ABI that
they can link to (the ksyms).
>I know that the disadvantage to this is lack of optimization. Every
>time we standardize, we seem to seek the lowest common denominator but
>we could work to minimize this by having these "optional" hooks in the
>kernel. What I mean by optional is that the module does not fail to run
>because they are not there.
The ABI is always there. Module versioning allows modules to
be used in later kernels, as long as the ABI has not changed.
The current scheme is quite optimal and standardized already.
Rob
(rriggs@tesser.com)