I wouldn't go as far as saying that the current solution imposes an
onerous requirement on any user wishing to build third-party modules
by relying on a complete and properly configured kernel source tree,
but it certainly seems like a step backwards from Linux 2.4, where
properly configured kernel headers are sufficient.
Of course, this only holds true for external projects using kbuild to
build the modules; other build systems would not only require that a
complete, configured kernel source tree be installed, they would also
rely on that source tree to be uncleaned since they have no knowledge
of how init/vermagic.o is to be built (and shouldn't make assumptions,
not considering possible legal/licensing implications). This I really
do consider an unnecessary, burdensome prerequisite.
Since I'm not intimately familiar with kbuild, I'm also wondering if
this scenario would be a problem:
Somebody downloaded Linux 2.5.59, configured it and built it using a
pre-3.0 version of gcc, e.g. gcc 2.95. The user had plenty of disk
space and decided, based on past experiences, that leaving the source
tree uncleaned is least likely to cause problems, should he/she ever
be intersted in building third-party modules. For some time, the user
placed no interest in external modules and used his/her system quite
happily; with the release of a new, improved version of a driver, the
user decided that he wants to give it a try, however, and built the
driver module, which picked up init/vermagic.o; our imaginary user is
using a distribution that provides frequent updates and he/she makes
regular use of this service - it just so happens that one of these
updates installed gcc 3.0 as the new default compiler. The new module
is thus built using gcc 3.0, but init/vermagic.o still indicates gcc
2.95; the module loader will erroneously believe everything is fine.
I agree with Mark that moving the code in init/vermagic.c into a new
header file like linux/vermagic.h is a better solution.
-- christian zander email@example.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/