> But this still isn't foolproof (speaking from the fools POV:). If you > build the source with SMP, say with KERNELRELEASE=2.4.20-18.9smp this > results in a set of modules versioned for this configuration of the > kernel. Then if you rebuild the source for a uniprocessor kernel (say > KERNELRELEASE=2.4.20-18.9), you'll find that both > /lib/modules/2.4.20-18.9/build/include and > /lib/modules/2.4.20-18.9smp/build/include point to the same include > directory. This happens using the redhat supplied config files. > > This is a problem, since the module version files are different (in > include/linux/modules/*.ver) for the two different configurations of > the same kernel source. I currently rebuild the kernel (up through > "make dep") to re-generate the module info when building add-on modules > for different kernel "flavors". well the kernel we has both in the same files with #ifdef's to automatically pick the right one...... unless you do make dep to nuke all those.
Attachment:
signature.asc
Description: This is a digitally signed message part
