modversion clarification.

modversion clarification.

[Pat Suwalski]

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

Re: modversion clarification.

[Pat Suwalski]

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

Re: modversion clarification.

[Kai Germaschewski]

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

Re: modversion clarification.

[Alan Cox]

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.