building kernel modules for linux differnet version
Hi, I have a scenario where I need to build a driver for different kernel versions. I have kernel-headers of different version in /lib/modules/ 2.6.32-xxxx 2.6.39-xxxx and currently I am booted into 2.6.32-xxxx(which I find out by uname -r) Now in my driver makefile, I generate .ko of driver make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules but I notice that the driver .ko gets generated for 2.6.39-xxxx though I am booted into 2.6.32-xxxx. Can anyone help me figure out why this is happening? Regards, Saket Sinha
Hi, Le mardi 11 mars 2014 à 21:16 +0530, Saket Sinha a écrit :
I have a scenario where I need to build a driver for different kernel versions. I have kernel-headers of different version in /lib/modules/ 2.6.32-xxxx 2.6.39-xxxx
and currently I am booted into 2.6.32-xxxx(which I find out by uname -r)
You don't need to boot on a specific kernel version to build external module for it.
Now in my driver makefile, I generate .ko of driver make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
but I notice that the driver .ko gets generated for 2.6.39-xxxx though I am booted into 2.6.32-xxxx. Can anyone help me figure out why this is happening?
Could you check that /lib/modules/2.6.32-xxxx/build is not a symbolic link to linux 2.6.39-xxxx sources ? Regards. -- Yann Droneaud OPTEYA
Please find my response inline
I have a scenario where I need to build a driver for different kernel versions. I have kernel-headers of different version in /lib/modules/ 2.6.32-xxxx 2.6.39-xxxx
and currently I am booted into 2.6.32-xxxx(which I find out by uname -r)
You don't need to boot on a specific kernel version to build external module for it.
I am aware of that. I just need the kernel header of that specific version instead. What I meant was that since I was using the expression "uname -r" in my makefile below- "make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules" so I specified that.
Now in my driver makefile, I generate .ko of driver make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
but I notice that the driver .ko gets generated for 2.6.39-xxxx though I am booted into 2.6.32-xxxx. Can anyone help me figure out why this is happening?
Could you check that /lib/modules/2.6.32-xxxx/build is not a symbolic link to linux 2.6.39-xxxx sources ?
I am pasting the output for you to check [root@Noi1-502156 ~]# cd /lib/modules [root@Noi1-502156 modules]# ls 2.6.32-220.4.2.el6.x86_64 2.6.39-300.17.1.el6uek.x86_64 2.6.32-358.6.2.el6.x86_64 2.6.39-400.24.1.el6uek.x86_64 [root@Noi1-502156 modules]# ll total 16 drwxr-xr-x. 8 root root 4096 Feb 28 14:41 2.6.32-220.4.2.el6.x86_64 drwxr-xr-x. 7 root root 4096 Jul 15 2013 2.6.32-358.6.2.el6.x86_64 drwxr-xr-x 8 root root 4096 Aug 12 2013 2.6.39-300.17.1.el6uek.x86_64 drwxr-xr-x. 4 root root 4096 Jul 10 2013 2.6.39-400.24.1.el6uek.x86_64 [root@Noi1-502156 modules]# Regards, Saket Sinha
Le mardi 11 mars 2014 à 22:42 +0530, Saket Sinha a écrit :
Please find my response inline
I have a scenario where I need to build a driver for different kernel versions. I have kernel-headers of different version in /lib/modules/ 2.6.32-xxxx 2.6.39-xxxx
and currently I am booted into 2.6.32-xxxx(which I find out by uname -r)
You don't need to boot on a specific kernel version to build external module for it.
I am aware of that. I just need the kernel header of that specific version instead. What I meant was that since I was using the expression "uname -r" in my makefile below- "make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules" so I specified that.
Now in my driver makefile, I generate .ko of driver make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
but I notice that the driver .ko gets generated for 2.6.39-xxxx though I am booted into 2.6.32-xxxx. Can anyone help me figure out why this is happening?
Could you check that /lib/modules/2.6.32-xxxx/build is not a symbolic link to linux 2.6.39-xxxx sources ?
I am pasting the output for you to check
[root@Noi1-502156 ~]# cd /lib/modules [root@Noi1-502156 modules]# ls 2.6.32-220.4.2.el6.x86_64 2.6.39-300.17.1.el6uek.x86_64 2.6.32-358.6.2.el6.x86_64 2.6.39-400.24.1.el6uek.x86_64 [root@Noi1-502156 modules]# ll total 16 drwxr-xr-x. 8 root root 4096 Feb 28 14:41 2.6.32-220.4.2.el6.x86_64 drwxr-xr-x. 7 root root 4096 Jul 15 2013 2.6.32-358.6.2.el6.x86_64 drwxr-xr-x 8 root root 4096 Aug 12 2013 2.6.39-300.17.1.el6uek.x86_64 drwxr-xr-x. 4 root root 4096 Jul 10 2013 2.6.39-400.24.1.el6uek.x86_64 [root@Noi1-502156 modules]#
Now try "ls -dFl /lib/modules/2.6.3*/build" And grep '^\(\(VERSION\)\|\(PATCHLEVEL\)\|\(SUBLEVEL\)\|\(EXTRAVERSION\)\| \(MAKEARGS\)\)' /lib/modules/*/build/Makefile Check that matches the expected version. -- Yann Droneaud OPTEYA
On Tue, Mar 11, 2014 at 11:09 PM, Yann Droneaud <ydroneaud@opteya.com> wrote:
Le mardi 11 mars 2014 à 22:42 +0530, Saket Sinha a écrit :
Please find my response inline
I have a scenario where I need to build a driver for different kernel versions. I have kernel-headers of different version in /lib/modules/ 2.6.32-xxxx 2.6.39-xxxx
and currently I am booted into 2.6.32-xxxx(which I find out by uname -r)
You don't need to boot on a specific kernel version to build external module for it.
I am aware of that. I just need the kernel header of that specific version instead. What I meant was that since I was using the expression "uname -r" in my makefile below- "make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules" so I specified that.
Now in my driver makefile, I generate .ko of driver make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
but I notice that the driver .ko gets generated for 2.6.39-xxxx though I am booted into 2.6.32-xxxx. Can anyone help me figure out why this is happening?
Could you check that /lib/modules/2.6.32-xxxx/build is not a symbolic link to linux 2.6.39-xxxx sources ?
I am pasting the output for you to check
[root@Noi1-502156 ~]# cd /lib/modules [root@Noi1-502156 modules]# ls 2.6.32-220.4.2.el6.x86_64 2.6.39-300.17.1.el6uek.x86_64 2.6.32-358.6.2.el6.x86_64 2.6.39-400.24.1.el6uek.x86_64 [root@Noi1-502156 modules]# ll total 16 drwxr-xr-x. 8 root root 4096 Feb 28 14:41 2.6.32-220.4.2.el6.x86_64 drwxr-xr-x. 7 root root 4096 Jul 15 2013 2.6.32-358.6.2.el6.x86_64 drwxr-xr-x 8 root root 4096 Aug 12 2013 2.6.39-300.17.1.el6uek.x86_64 drwxr-xr-x. 4 root root 4096 Jul 10 2013 2.6.39-400.24.1.el6uek.x86_64 [root@Noi1-502156 modules]#
Now try "ls -dFl /lib/modules/2.6.3*/build"
[root@Noi1-502156 ~]# ls -dFl /lib/modules/2.6.3*/build lrwxrwxrwx. 1 root root 50 Feb 17 2012 /lib/modules/2.6.32-220.4.2.el6.x86_64/build -> ../../../usr/src/kernels/2.6.32-220.4.2.el6.x86_64/ lrwxrwxrwx. 1 root root 50 Jun 11 2013 /lib/modules/2.6.32-358.6.2.el6.x86_64/build -> ../../../usr/src/kernels/2.6.32-358.6.2.el6.x86_64 lrwxrwxrwx 1 root root 54 Jul 10 2013 /lib/modules/2.6.39-300.17.1.el6uek.x86_64/build -> ../../../usr/src/kernels/2.6.39-300.17.1.el6uek.x86_64/
And
grep '^\(\(VERSION\)\|\(PATCHLEVEL\)\|\(SUBLEVEL\)\|\(EXTRAVERSION\)\| \(MAKEARGS\)\)' /lib/modules/*/build/Makefile
[root@Noi1-502156 ~]# grep '^\(\(VERSION\)\|\(PATCHLEVEL\)\|\(SUBLEVEL\)\|\(EXTRAVERSION\)\|\(MAKEARGS\)\)' /lib/modules/*/build/Makefile /lib/modules/2.6.32-220.4.2.el6.x86_64/build/Makefile:VERSION = 2 /lib/modules/2.6.32-220.4.2.el6.x86_64/build/Makefile:PATCHLEVEL = 6 /lib/modules/2.6.32-220.4.2.el6.x86_64/build/Makefile:SUBLEVEL = 32 /lib/modules/2.6.32-220.4.2.el6.x86_64/build/Makefile:EXTRAVERSION = -220.4.2.el6.x86_64 /lib/modules/2.6.39-300.17.1.el6uek.x86_64/build/Makefile:VERSION = 3 /lib/modules/2.6.39-300.17.1.el6uek.x86_64/build/Makefile:PATCHLEVEL = 0 /lib/modules/2.6.39-300.17.1.el6uek.x86_64/build/Makefile:SUBLEVEL = 36 /lib/modules/2.6.39-300.17.1.el6uek.x86_64/build/Makefile:EXTRAVERSION = -300.17.1.el6uek.x86_64
Check that matches the expected version.
As already mentioned, driver .ko gets generated for 2.6.39-xxxx. Kindly let me know what you could make out of above outputs and why exactly I am getting a 2.6.39-xxxx .ko file when I am specifying a 2.6.32-xxxx kernel header. Regards, Saket Sinha
The strange part is that your 2.6.39 dir returns 3.0.36 kernel version ..!?
/lib/modules/2.6.39-300.17.1.el6uek.x86_64/build/Makefile:VERSION = 3 /lib/modules/2.6.39-300.17.1.el6uek.x86_64/build/Makefile:PATCHLEVEL = 0 /lib/modules/2.6.39-300.17.1.el6uek.x86_64/build/Makefile:SUBLEVEL = 36 /lib/modules/2.6.39-300.17.1.el6uek.x86_64/build/Makefile:EXTRAVERSION
-- « On ne résout pas un problème avec les modes de pensée qui l’ont engendré. » « You cannot solve current problems with current thinking. Current problems are the result of current thinking »
participants (3)
-
Laurent Navet -
Saket Sinha -
Yann Droneaud