Bug 113792

Summary: impossible to build correctly non-core modules against 2.6 kernel
Product: [Retired] Red Hat Raw Hide Reporter: Sergey V. Udaltsov <sergey_udaltsov>
Component: kernelAssignee: Dave Jones <davej>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0CC: kajtzu, pfrields
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-11-27 00:20:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Sergey V. Udaltsov 2004-01-18 02:55:53 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b)
Gecko/20031208

Description of problem:
Just downloaded the latest 2.6 kernel from rawhide, tried to build
ndiswrapper and slmodem against it. Found, resulting .ko modules do
not get __versions symbol, so kernel claims it is tainted when loading
them...


How reproducible:
Always

Steps to Reproduce:
1. Take the latest kernel 2.6 rpm from rawhide
2. Take ndiswrapper release from ndiswrapper.sf.net
3. Build it and install as described in the instruction
4. Try to load the module ndiswrapper.ko
    

Actual Results:  Error messages in the /var/log/messages

Comment 1 Arjan van de Ven 2004-01-18 11:58:24 UTC
can you paste the exact commandline that is given to gcc ?
(and what kind of makefiles are used)

Comment 2 Sergey V. Udaltsov 2004-01-18 14:27:42 UTC
I really do not know the command line. The thing works this way:

make -C /lib/modules/..../build SUBDIRS=/home/svu/ndiswrapper/driver
modules

So it calls standard kernel Makefile pointing to the driver directory.
I do not know whether this is the right way to do or not.

Comment 4 Sergey V. Udaltsov 2004-02-13 23:22:32 UTC
Same story with the latest fedora kernels. Still "kernel tainted"

Comment 5 Sergey V. Udaltsov 2004-02-18 14:42:08 UTC
Actually, the first sub-problem found is that modversions.h is not in
/lib/modules/.../build/include/linux. I think it should be easy to fix
(and really must be fixed).

Comment 6 Arjan van de Ven 2004-02-18 14:44:07 UTC
that is because it no longer exists in 2.6.
There is 
/lib/modules/2.6.2-1.169.rootsmp/build/include/config/modversions.h

but that has a different meaning.


Comment 7 Sergey V. Udaltsov 2004-02-18 15:34:34 UTC
Yes. So it is rather ndiswrapper bug, not yours. Sorry. It uses
linux/modversions.h instead of config/modversions.h

Comment 8 Sergey V. Udaltsov 2004-02-18 15:35:14 UTC
I will try to change their sources and build again...

Comment 9 Arjan van de Ven 2004-02-18 15:36:09 UTC
any module that includes linux/modversions.h is broken beyond belief,
even in 2.4. Shrug.

Comment 10 Sergey V. Udaltsov 2004-02-18 16:35:10 UTC
Changed the configuration to config/modversions.h - still same story.
The MOST funny thing is that same sources/kernel work for other
people. I could believe it is my env - but really have no clue where
to look at.

Comment 11 Sergey V. Udaltsov 2004-02-18 17:00:13 UTC
OK. I will put my questions straight: 
1. Is the version of struct_module required by the module ABI?
2. Is there any way to check (using objdump or something) whether the
version is there or not?
3. When at the build stage this version is determined?

Comment 12 Sergey V. Udaltsov 2004-02-19 10:19:10 UTC
I do not know whether it makes sense or not. Any "good" kernel module
contains the symbol ____versions (in the segment __versions). But all
3rd party modules I built - do not contain it. Looking at the kernel
code, I think it causes my problem. The question is when this symbol
appears and how would I get it into the modules. I presume some
breakage of the build process.

Comment 13 Sergey V. Udaltsov 2004-02-29 22:25:12 UTC
More info. The modpost program generates INCORRECT ndiswrapper.mod.c
file. This file does not contain ____versions array. This happens
because none of the standard symbols are resolved by the modpost
(which generates ndiswrapper.mod.c). Probably this happens because
modpost gets only one argument (ndiswrapper) and cannot resolve
characters in the kernel itself. Is there any way to teach modpost
about the symbols in the kernel core?

I reopen the bug because I'd consider this a bug in modpost - or in
the kernel build Makefiles.

Comment 14 Sergey V. Udaltsov 2004-02-29 23:25:10 UTC
See also here
http://www.mail-archive.com/kbuild-devel@lists.sourceforge.net/msg02079.html

Comment 15 Sergey V. Udaltsov 2004-03-01 14:39:38 UTC
Could the patch mentioned in the link above be used in Fedora please?
I think this is crucual for the 3rd party modules support (like
winmodems etc).

Comment 16 Sergey V. Udaltsov 2004-11-27 00:20:52 UTC
It seems the latest kernel versions are ok in this regard now.