|Summary:||kernel needs /lib/modules/`uname -r`/build subdirectory|
|Product:||Red Hat Enterprise Linux 4||Reporter:||David Kewley <david_kewley>|
|Component:||kernel||Assignee:||Rik van Riel <riel>|
|Status:||CLOSED NOTABUG||QA Contact:||Brian Brock <bbrock>|
|Version:||4.0||CC:||davej, dwmw2, jbaron, riel, smithj4|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2005-04-01 20:01:54 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description David Kewley 2005-03-25 03:44:30 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.1; Linux) Description of problem: For every `uname -r`, there should exist a /lib/modules/`uname -r`/build directory pointing to the kernel files necessary for building modules. This seems to work well in Fedora Core 3. RHEL 4, on the other hand, has a new package kernel-devel that installs source in /usr/src/kernels/<kernel name>, and makes a symlink to that source directory from /lib/modules/`uname -r`/build. This obscures things when you're building a modules for UP and SMP kernels. Best I can tell, I'm supposed to do this: For UP kernel: 1) cd /usr/src/kernels/<UP kernel name> 2) cp /boot/config-<UP kernel name> ./.config 3) make oldconfig 4) make 5) cd <my module dir> 6) make SRC=/usr/src/kernels/<UP kernel name> 7) cp <my module>.ko /lib/modules/<UP kernel name>/updates Then for SMP kernel: 1) cd /usr/src/kernels/<SMP kernel name> 2) cp /boot/config-<SMP kernel name> ./.config 3) make oldconfig 4) make 5) cd <my module dir> 6) make SRC=/usr/src/kernels/<SMP kernel name> 7) cp <my module>.ko /lib/modules/<SMP kernel name>/updates Shouldn't I instead be able to do this instead?: For UP kernel: 1) cd <my module dir> 2) make SRC=/lib/modules/<UP kernel name>/build 3) cp <my module>.ko /lib/modules/<UP kernel name>/updates Then for SMP kernel: 1) cd <my module dir> 2) make SRC=/lib/modules/<SMP kernel name>/build 3) cp <my module>.ko /lib/modules/<SMP kernel name>/updates Fedora Core 3 allows me to do it the latter, faster, easier way. Why don't we use FC3's scheme instead of the one currently in RHEL4? I'm treading on new ground here, so please correct any misstatements I've made. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. ls -ald /lib/modules/`uname -r`/build 2. rpm -ql kernel-devel | grep -v /usr/src 3. Notice that we have a build symlink for UP kernels but not for SMP 4. Notice that there is no kernel-devel-smp or some such. 5. Notice that we have to 'make' the kernel for UP and SMP separately, rather than taking advantage of pre-built trees for building external modules. Actual Results: We notice that kernel-devel is the package that provides the /lib/modules/`uname -r`/build symlinks, but it only provides symlinks for UP kernels, not for SMP kernels. We notice that it takes too many steps to build external modules. Expected Results: kernel should have a full external module build tree under /lib/modules/`uname -r`/build, rather than a symlink. This would enable us to build external modules more easily. Additional info:
Comment 1 David Kewley 2005-03-25 04:11:44 UTC
A little followup: The Release Notes state: "An exploded source tree is not required to build kernel modules against the currently in-use kernel. For example, to build the foo.ko module, create the following file (named Makefile) in the directory containing the foo.c file: obj-m := foo.o KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) default: $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules Issue the make command to build the foo.ko module." This isn't possible at present out of the box. And an update: Even with the kernel build tree provided by kernel-devel in /usr/src/kernels/<kernel name>, 'make' doesn't work, so I can't change the config and make an SMP tree for building external modules against. At this point I'm left with getting the src.rpm and starting from that. Possible, but unfriendly.
Comment 2 Rik van Riel 2005-03-25 04:16:44 UTC
Could you please give me an example of an out-of-tree driver that I can try building here, so I can see exactly why it breaks and how to get it fixed ?
Comment 3 David Kewley 2005-03-25 04:31:44 UTC
Sure. I am currently working on the latest 3Ware 9xxx series driver. You can get it from: http://www.3ware.com/support/download_9.2.asp?SNO=490 Best I can tell, I *could* attach this because it'd GPL'd, but I'll be a little cautious and just point to the 3ware site. :) You should be able to make it with e.g. make SRC=/lib/modules/`uname -r`/build As described earlier, look at what happens when you try to build for UP and SMP kernels (at least on x86_64, probably all arches).
Comment 4 Jason Smith 2005-03-25 20:20:47 UTC
There is a minor packaging/naming issue which is somewhat related to this that I would like to report. It appears that the kernel-devel packages write into directories like: /usr/src/kernels/`uname -r`-$ARCH except for the smp kernel packages, which add an extra - between the EL in the kernel release number and smp. For example, this is what I currently have: $ ls /usr/src/kernels 2.6.9-5.0.3.EL-i686 2.6.9-5.0.3.EL-smp-i686 2.6.9-5.EL-i686 2.6.9-5.EL-smp-i686 This looks like a mistake to me since it would make much more sense to remove the - before smp and just use `uname -r`-$ARCH.
Comment 6 David Kewley 2005-03-26 01:33:43 UTC
*** Bug 152130 has been marked as a duplicate of this bug. ***
Comment 7 David Kewley 2005-04-01 20:01:54 UTC
Just now I learned that the UP package kernel-devel has an SMP sibling kernel-smp-devel. With that installed, I believe all my objections are answered -- it is then possible to compile UP and SMP external modules the "easy" way that I suggested when I opened this bug. Sorry for the waste of time; I like to think I'm a reasonably thorough researcher, but I missed kernel-smp-devel.