kernel module mismatch
 

I 've just started module programming following the Alessandro Rubini and Jonathan Corbet "Linux Device Drivers " book for kernel 2.4. I have got Redhat 9.0 installed on my system. I try to use "insmod " to insert a module called hello.o, however the system returns a message

hello.o: kernel-module version mismatch.
hello.o was compiled for kernel version 2.4.20
while this kernel is 2.4.20-8custom

In the book it is mentioned that it would be better to recompile the kernel without the version support for modules. I believe I did the right thing by simply changing the option of "loadable module support - > set version information on all module symbols " from y to n. I booted the recompiled custom kernel without any problems.

make sure you are using the right include paths when building the module ( if you include the 2.4.20-8custom source directory, the module will not load). check the Makefile in the toplevel of the kernel source you are linking against and at the top it will have the version information. Make sure it is 2.4.20 with no EXTRAVERISION specified

Me too... how to update "include" path?
 

I too discovered that my <linux/...> include path was wrong while compiling hello.c from LDD.

I installed base system from Debian -> 2.4.18, then immediately upgraded to 2.4.23 (I know .29 is available but I need .23 for this app); the problem is that I want to use my distro set of headers, i.e. in /usr/src/linux/include/linux

(Note: /usr/src/linux is symlink to /usr/src/linux-2.4.23)

Can I:
mv /usr/include/linux /usr/include/linux-2.4.18

and then:
ln -s /usr/src/linux/include/linux /usr/include/linux?
will this break anything?

And how do I know that my newly built kernel (2.4.23) used its own include src instead of /usr/include/linux?

hi,

first the header files in /usr/include are user space interface to glibc not kernel space headers
it's extreemly important they stay what they were when glibc was compiled or you will have header files that don't match the library and problems and degraded performance will be the result.

second make sure you are actually running the kernel you think you are with
uname -r

find the current running kernel source directory with
ls -l /lib/modules/`uname -r`/build

when you compile something that needs kernel space sources and not user space glibc kernel interface
use the flag
-nostdinc
meaning (no standrd includes) and then use the -I flag to point to your current running kernels sources
you can even use the `uname -r` to make sure
gcc -c -Wall -nostdinc -I /lib/modules/`uname -r`/build/include hello.c