Hi all,
I'd like to spark some discussion on how to properly package kernel modules for FC2. I have personally packaged a few kernel module packages for FC1 for fedora.us (see http://thomas.apestaart.org/download/pkg/fedora-1-i386-fedora-stable/), and Ville Skytta has packaged some others using a different technique.
I have spent some time this week getting more familiar with the linux 2.6 buildsystem, and have come up with a similar system to what I had for 2.4. I'd like to explain the various parts of the problem and solution and get some feedback so I can fix the procedure and propose it to fedora.us
First of all, a few things are different with 2.6 and FC2: - you cannot use kernel-source anymore to build for all archs (i586, i686 - athlon is dropped) and types (regular and -smp) This is because you need a bunch of different headers and built files - these built files are packaged in the kernel rpm and install in /lib/modules/`uname -r`/build which is now no longer a symlink to /usr/src/linux-(rel) but a real directory. This effectively prevents you from building kernel modules for more than one arch at the same time on your system, since there's no way to install the same kernel rpm for different archs. - afaict the FC2 kernel no longer uses symbol versioning (MODVERSIONS not defined, and Module.symvers only contains "0" versions. I have no idea why this change has been made. - 2.6 has a new kbuild system that makes it possible to build out-of-source kernel modules more reliably/easily
So, how does the current procedure work ?
- I wrote a script (http://thomas.apestaart.org/download/tmp/kmd.py) which takes a set of kernel rpms for the same-version release, but different arch/types, extracts them, then creates a symlink/copy forest that produces a tree of dirs with the same contents as each of the four rpms (http://thomas.apestaart.org/download/pkg/fedora-2-i386-fedora-stable/kernel-...) The reason for doing this is so that modules for each arch/target combo can again be built on one kernel, and the resulting rpm is smaller than four copies of the other rpms. Currently, this rpm puts files in
/usr/share/kernel-module-devel-2.6.5-1.358 :
common kernel-smp-2.6.5-1.358.i586.rpm kernel-2.6.5-1.358.i586.rpm kernel-smp-2.6.5-1.358.i686.rpm kernel-2.6.5-1.358.i686.rpm
common is a symlink to /lib/modules/`uname -r` (which can be regular or smp, and is symlinked at %post time by the rpm). the four other directories are named exactly like the rpm they were part of, and contains a tree of files that are different to the others, and symlinks to the common directory.
- In the autostars project, we have come up with a set of scripts and a sample project to package kernel modules and build them reliably and reproducably against any kernel build tree (http://cvs.sourceforge.net/viewcvs.py/autostars/autostars/linux/) This has been updated with a full set of procedures to build for 2.6 as well. Given only the argument --with-linuxdir=/usr/share/kernel-module-devel-(ver-rel)/(rpm dir), it can build the correct kernel module. (This same project can still be used to build 2.4 modules correctly as well, including redhat's special defines for boot,enterprise,smp,bigmem from /boot/kernel.h) For 2.6, it includes a libtool-like script that takes care of installing modules and taking into account symbol versions.
- like before, I have created patches to hostap and ipw2100 drivers to autotoolize them using this setup. This only takes ten minutes if you're used to autotools, and ten more if you want it to work out of the box for both 2.4 and 2.6 (assuming the source allows this).
- Since ipw2100 needs symbol versions and include files from hostap, I've made the hostap rpm install these files as part of a kernel-module-devel-hostap-(ver-rel) rpm, in the same tree as the original kernel-module-devel rpm. all hostap*.symvers files end up in e.g. /usr/share/kernel-module-devel-2.6.5-1.358/kernel-2.6.5-1.358.i686.rpm (which is where Modules.symvers lives). The .h files I have for now put in /usr/share/kernel-module-devel-2.6.5-1.358/kernel-2.6.5-1.358.i686.rpm/include/modules/hostap
- the spec files for ipw2100 and hostap need some small tweaks to build both on pre-fc2 (with 2.4) and post-fc2. It mainly consists of the first buildrequire'ing kernel-source and kernel, and the second buildrequiring kernel-module-devel-(ver-rel). For hostap, depending on 2.4 or 2.6, different symbol versioning files are installed (builddir/include/linux/modules/*.ver versus builddir/*.symvers) Currently the configure invocation is slightly different too, but this could be fixed.
The resulting rpms are up at http://thomas.apestaart.org/download/pkg/fedora-2-i386-fedora-stable/kernel-... and http://thomas.apestaart.org/download/pkg/fedora-2-i386-fedora-stable/kernel-... and are of course built with mach.
I'd appreciate it if some other people (particularly on smp, though I don't even know if there are people with an ipw2100 AND dual cpu's) try them out and let me know if it works.
I'll work on some other kernel module projects as well (I've done the qc-usb module too, but the resulting module doesn't seem to work correctly. The original upstream build against my /lib/modules tree doesn't work either, so I'm sure it's not my changes that break it :))
Here is a list of things I still need to decide or fix and would like to have input on: - the devel rpm containst the kernel's version and release as part of the name, in accordance with fedora.us's policy for actual kernel modules. It's not possible to have a "-" in the version number, so I can't put kernel ver/rel in that, and I don't want to stick it in the release tag since then it's impossible to buildrequire: it properly since on fedora.us the resulting rpm gets a 0.fdr.2 appended to the release tag. Is this ok ?
- the devel rpm currently stores its files in /usr/share/kernel-module-devel-(ver-rel) Would it be more appropriate to put stuff in /usr/lib/kernel-module-devel-(ver-rel) instead ?
- the devel rpm is currently set with arch i386. I've considered making it noarch, since it contains files for more than one arch. But I assume it's not possible anyway to easily build for x86, ppc and ia64 on the same machine (though the -devel rpm could still be created for all of them since it just unpacks rpms and compares files). Which of the two would be preferable in this case ?
- the hostap rpm does the following: - when built with --target i386, it does the build for the four arch/type combos and packages only the devel files (symbol versions + headers), installing them in the same dir as the kernel-module-devel rpm. - when built with --target i586 or i686, it does only one build for the given 'kernel' uname -r define, and removes the devel files. This would be an argument in favour of having the -devel packages be i386; I don't think it's possible to build a -devel rpm for ppc, x86 and ia64 at the same time if you have to actually build the files.
- currently, .symvers files are installed in the root of the builddir, and include files are installed in builddir/include/modules/(basename of module). For the .symvers, I think this is an ok location. For the headers, I'm not sure yet. Of course, this needs to be a location we need to agree on so interdependent modules can be built correctly. For building ipw2100, an extra include directive is given in the Makefile.am patch that points to builddir/include/modules/hostap Any suggestions on standardizing this or is this ok ? What would projects like these be expected to install them to normally ?
- the module spec files could be made to work with fc2 and pre-fc2. I normally use a check to scan /etc/fedora-release and build a conditional based on that. Maybe it should check for the kernel version instead ? If so, can that be done reliably without invoking rpm as part of the check ? Is it worth it to try and integrate, or would it make more sense to just do 2.4 and 2.6 spec files separately ?
- I cannot test the smp versions because my machine cannot boot the smp kernel. For all 2.4 kernels this worked fine. Has it become impossible to run smp kernels on up machines ? Does anyone know more about this ?
- Anyone know why FC2 module versioning is turned off ? AFAIK the build setup we've come up with would take symbol versioning into account correctly if it were turned on.
- any other suggestions/questions/objections ?
Thanks, Thomas
Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> yes i am a long way from home <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/
On Sat, 2004-05-22 at 17:56, Thomas Vander Stichele wrote:
- Anyone know why FC2 module versioning is turned off ? AFAIK the build
setup we've come up with would take symbol versioning into account correctly if it were turned on.
in 2.6 it makes it really hard to build external modules with, in addition the thing we had symbol versioning for (preventing wrong modules to be inserted) now gets caught by the module version magic.
Hi,
- Anyone know why FC2 module versioning is turned off ? AFAIK the build
setup we've come up with would take symbol versioning into account correctly if it were turned on.
in 2.6 it makes it really hard to build external modules with
How so ? Seems to work fine.
, in addition the thing we had symbol versioning for (preventing wrong modules to be inserted) now gets caught by the module version magic.
This is the line that reads "vermagic: 2.6.5-1.358 686 REGPARM 4KSTACKS gcc-3.3" for example, right ? Aren't there other settings in the kernel build that affect module versioning that aren't represented in the vermagic ? If not, why is module versioning still needed ?
Thomas
Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Will you take me for a ride The one that never ends <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/
On May 24, 2004, Thomas Vander Stichele thomas@apestaart.org wrote:
Hi,
- Anyone know why FC2 module versioning is turned off ? AFAIK the build
setup we've come up with would take symbol versioning into account correctly if it were turned on.
in 2.6 it makes it really hard to build external modules with
How so ? Seems to work fine.
If you want to build modules for both i586 and i686, it's a pain, unless you're willing to have two different build roots, one with the i586 kernel, and one with the i686 kernel. smp kernels can be installed alongside with UP kernels, since they report a different string from the UP ones with `uname -r', but there's no way to distinguish i586 from i686.
I suggested to Arjan to add .i586 and .i686 tags to the kernel version string, similar to smp, but he said he was disgusted at the idea. That's too bad, because it would greatly simplify building kernel modules :-(
Maybe doing that only for non-i686 kernels would make it more palatable?
Hi,
Hi,
- Anyone know why FC2 module versioning is turned off ? AFAIK the build
setup we've come up with would take symbol versioning into account correctly if it were turned on.
in 2.6 it makes it really hard to build external modules with
How so ? Seems to work fine.
If you want to build modules for both i586 and i686, it's a pain, unless you're willing to have two different build roots, one with the i586 kernel, and one with the i686 kernel. smp kernels can be installed alongside with UP kernels, since they report a different string from the UP ones with `uname -r', but there's no way to distinguish i586 from i686.
Yep, but this is a limitation of the current packaging of the kernel rpm, not a limitation of the kernel itself. This is also what the kernel-module-devel package I made solves.
I suggested to Arjan to add .i586 and .i686 tags to the kernel version string, similar to smp, but he said he was disgusted at the idea.
Well, AFAICT Arjan also thinks that instead of having external module packages, module code should just be merged in the kernel upstream. A valid point of view, but one I don't really share. Kernel module code should get ample testing from people that have the hardware but not the experience, hence my quest for packaging kernel modules.
Thomas
Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Well baby let me shake it If I can move it with you will you let me take it <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/
-
Alexandre Oliva -
Arjan van de Ven -
Thomas Vander Stichele