Bug 152129

Summary: kernel needs /lib/modules/`uname -r`/build subdirectory
Product: Red Hat Enterprise Linux 4 Reporter: David Kewley <david_kewley>
Component: kernelAssignee: Rik van Riel <riel>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: davej, dwmw2, jbaron, riel, smithj4
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-04-01 20:01:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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 
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 

Version-Release number of selected component (if applicable):

How reproducible:

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) 
    $(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: 
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

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 5 David Woodhouse 2005-03-25 23:18:04 UTC
Comment #4 was addressed in bug #145914.

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.