Hello,
I'm trying to figure out exactly what modversions.h does.
Speaking to two seperate developers who have worked on the 2.2 kernel,
having modversion on in the kernel config causes module versioning to be
extremely strict, with sort of 'keys' that only allow it to be run on
the exact kernel config a module was built on.
According to several places in the 2.4.x documentation, it is the exact
opposite, and allows for large freedom to exchange modules between kernels.
Could someone please clarify for me?
Thanks,
--Pat
henrique wrote:
> When you try to load the module, the insmod will check if the symbols of your
> module are the same of the current running kernel. If the symbols are the
> same the module will be loaded. So you can use your module on all kernels
> that have the same CRC for the kernel functions your module uses.
So then is that not opposite of what modversion says it does, which is
to allow modules to be more comptible across multiple kernel versions?
Basically, the problem is that if module.h is included and MODVERSION is
not defined, and the module wants to export symbols (EXPORT_SYMTAB is
defined), then module.h automatically ifdefs modversions.h even if the
kernel is not configured to use it (and thus the file does not exist).
--Pat
> As a matter of fact it happens seldomly as the kernel are always changing and
> you have to recompile your module every time you change your kernel. But it
> is still a very good idea.
>
> regards
> Henrique
On Thu, 2002-07-25 at 17:17, Pat Suwalski wrote:
> According to several places in the 2.4.x documentation, it is the exact
> opposite, and allows for large freedom to exchange modules between kernels.
>
> Could someone please clarify for me?
It attempts to ensure you only load a module on a matching kernel. That
means stuff will sometimes load happily between versions which without
modversions it would not. It also mstly ensures you dont mistakenly load
a module from one 2.4.18 kernel into another binary incompatible one.
On Thu, 25 Jul 2002, Pat Suwalski wrote:
> henrique wrote:
> > When you try to load the module, the insmod will check if the symbols of your
> > module are the same of the current running kernel. If the symbols are the
> > same the module will be loaded. So you can use your module on all kernels
> > that have the same CRC for the kernel functions your module uses.
Yes, provided that module and kernel have the same version string
("2.4.18-preX").
> So then is that not opposite of what modversion says it does, which is
> to allow modules to be more comptible across multiple kernel versions?
No. If you enable modversions, that will always cause stricter checking -
without modversions, basically only the comparison of the version string
protects you from inserting an incompatible module. If you have
modversions enabled, the generated checksums provide additional checking
for mismatching ABIs (interfaces).
> Basically, the problem is that if module.h is included and MODVERSION is
> not defined, and the module wants to export symbols (EXPORT_SYMTAB is
> defined), then module.h automatically ifdefs modversions.h even if the
> kernel is not configured to use it (and thus the file does not exist).
The build process in 2.4 will generate a modversions.h file no matter what
CONFIG_MODVERSION says (but it'll be empty if it's switched off). For some
insight in what magic happens I put a lengthy comment into the 2.5 version
of include/linux/module.h - "So how does the CONFIG_MODVERSIONS magic
work?", if you're interested you may want to check that out.
--Kai