[OpenAFS-devel] Linux Kernel Module build question

[Elliot Lee]

On 12 Jul 2001, Derek Atkins wrote:

> Yes, that is my requirement.  And no, currently due to bugs in
> linux/rhconfig.h, there is not (IMHO) a better way of doing it.  Take
> a look at http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=38460
> for the full explanation.  The jist is that there is no way to
> override the architecture of the currently-running kernel
> (386/586/686/athlon) because you only check #ifdef, not #if defined()
> && != 0 like you do for SMP.

Hmm, have you considered a solution like the following:

#include "/boot/kernel.h"

#undef __MODULE_KERNEL_subarch1
#undef __MODULE_KERNEL_subarch2
...
#undef __MODULE_KERNEL_subarchN
#undef __BOOT_KERNEL_SMP
#undef __BOOT_KERNEL_UP

#define __MODULE_KERNEL_desiredsubarch 1
#define __BOOT_KERNEL_SMP 1

/* include all the various kernel headers as needed */

This allows you to completely control the platform that you are targetting
with your compilation, while not depending on an updated kernel package
from RH nor modifying installed files.

> > If you look at the RH kernel RPM package, it does the right thing for each
> > possible --target that you can specify. e.g. it skips the kernel-source
> > package if you use --target=i686, but builds it if you use
> > --target={i386,alpha,ia64,otherbasearchs...}.
>
> This is exactly what I meant.  If you're building for the base
> platform you need to build everything, and if you're building for a
> 'sub-platform' you need to be careful to ONLY build certain
> sub-packages (e.g. just the kernel modules).

Yes, but this care only needs to be taken once in the .spec file, and is
relatively easy to implement and maintain. It's not like you're forcing
the packager to select the subpackages every time they build.

> Where it is currently, in the afs initscript.  It already attempts to
> choose the 'correct' module, but it only bases it on 'uname -r'.
> Obviously this doesn't help in the case of i386 v. i586 v. i686
> v. athlon.  But I've got code to fix this, and choose the module based
> upon the contents of /proc/ksyms.

It would seem to be preferable to just let the kernel have modprobe load
the module as needed. But, probably not my problem. :)

-- Elliot
Your freedom to change my source code does not translate into my
responsibility to foist your changes upon users at large.