On Sat, 6 Jul 2002, Keith Owens wrote:
> include/linux/version.h contains both the numeric part of the kernel
> version and the full uts_release string. version.h is included almost
> everywhere, either on its own or via module.h. module.h and modutils
> only require the numeric kernel version, the use of UTS_RELEASE is
> incorrect and causes significant recompiles when EXTRAVERSION changes.
>
> This patch moves UTS_RELEASE into its own header which is explicitly
> included in only the files that really use UTS_RELEASE. module.h uses
> a new field (KERNEL_VERSION_STRING) which has been added to version.h.
> With this patch, a change to EXTRAVERSION no longer recompiles 95% of
> your kernel.
>
> The only significant changes are to module.h and Makefile. The rest of
> the patch is adding #include <linux/uts_release.h> in those files that
> use UTS_RELEASE. I suspect some of those files really only need
> KERNEL_VERSION_STRING but that has been left as an exercise for the
> file owners. Some of those files may no longer required version.h,
> again that has been left for the file owners.
When I looked at the same thing, I gave up when I realized that the
EXTRAVERSION part is actually used in module.h, thereby affecting most
files in the tree.
Now, you get around this by only including the numeric part of the kernel
version in the module. That's of course a possibility, but I'd think
people should be aware that this actually a major change.
(I just looked at modutils-2.4.15, don't know if sth changed in the
latest version)
a) This change breaks compatibility to current modutils. A module
compiled for 2.5.30-pre5 will contain only "2.5.30" as its version
after your patch, thus current modutils will refuse to insert it
into "2.5.30-pre5". (unless using insmod -f)
This is of course easily fixed by having a new version of modutils
only compare the numeric part.
But then we have
b) modutils will not complain when insmod'ing a module compiled for
2.5.30-preX into 2.5.30-final (or any 2.5.30-, for that matter). If
that happens, it of course means the user fscked up. However,
I think the trend is to make things rather more fool-proof than
less so, so I'm not convinced that we're on the right track with this
change.
Of course, on the other hand the patch means that when going from -pre<N>
to -pre<N+1> modules won't be recompiled just for the heck of updating the
version string, but only if something else changed.
(We don't have -pre's in 2.5, so think 2.6, or inserting modules from -djX
into a vanilla kernel or so)
As I'd guess this issue is somewhat controversial, I'd like to gather
opinions on whether it should be done or not.
--Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 23 2002 - 22:00:36 EST