About one third of the time when I run "make depend" on
an 866MHz Pentium III, it accidentally leaves some files out
of the include/linux/modversions.h file that it generates.
This is caused by a the one second granularity of file modification
times returned by stat (and recorded by most file systems, including
ext2), and the fact that that linux/Rules.Make determines that it
is time to rebuild modversions.h by noticing that the .ver files
are newer. So, if the last two or more directories are processed
by "make depend" in the same one second tick, only the first directory
in that one second tick will cause modversions.h to be rebuilt.
When this happens, the build silently succeeds, but any
modules that reference symbols that were defined by the missing
modversions.h have no symbol versioning for those symbols, while
the kernel or the exporting module does, so the modules cannot
be loaded. The symbols are usually from arch/i386/kernel/ksyms.c,
which I think is the last symbol exporting file processed by
make depend on x86.
Anyhow, I have developed two patches to solve the problem.
I am posting the simpler one, which just causes an extra rebuild
of modversions.h after "make depend."
The other patch, which I would be happy to provide if
there is interest, is a more complex but more "correct" approach.
It creates an earlier phase of "make depend" that traverses the
source tree to generate all of the ".ver" files, then it generates
modversions.h just once, and then does the rest of dependency
generation. This more complex patch eliminates the need to
rebuild modversions.h many times throughout the "make depend"
process, and it also eliminates some situations where modules
are made to depend on modversions.h, relying on the fact that
modversions.h gets regenerated as a result of all sorts of minor
changes, and using the resulting updated modification date to
trigger rebuilds. Instead, generationg of .ver files are
made directly dependent on their .c counterparts, which is
the truth anyhow. However, I hesitate to put this more complex
patch forward because the extra descent into the source tree
takes more time than the repeated rebuilding of modversions.h
(about 3% slower), and while both the old and the my new scheme
can produce mismatched kernels and modules if you are editing
the kernel sources and attempting to incrementally recompile, such
a problem is a bit less likely with the old scheme because of all
of the extra recompiles that it triggers.
Anyhow, I have attached the simple patch below.
Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
firstname.lastname@example.org \ / San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l United States of America
fax +1 408 261-6631 "Free Software For The Rest Of Us."
--- linux-2.3.99-pre7-8/Makefile Wed May 10 03:43:51 2000
+++ linux/Makefile Wed May 10 05:16:38 2000
@@ -442,6 +442,10 @@
depend dep: dep-files $(MODVERFILE)
+ rm -f $(MODVERILE)
+ $(MAKE) $(MFLAGS) $(MODVERFILE)
# make checkconfig: Prune 'scripts' directory to avoid "false positives".
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:15 EST