[PVFS-users] Question regarding include/modules *.stamp/*.ver files for pvfs

[Murali Vilayannur]

Hi,
> 
> make: *** No rule to make target `/usr/src/linux/include/linux/modules/
>   af_netlink.ver', needed by `pvfs_mod.o'.
> 
> is the absence of the two files, af_netlink.stamp and af_netlink_ver, in
> the later subtree.
> 
> I've searched the web on information regarding the function and layout of
> *.stamp and *.ver files. If info is available, it's not readily available
> or easily found. Does anyone have information on these types of files?

These files are created or can be created by the following rules shown 
below. Basically the "*.ver" file is created by piping the preprocessed 
output of the corresponding C file to a special program called "genksyms"
(that is provided with your modutils package), in addition to the kernel 
version information and whether or not it is a smp enabled kernel, and the 
resultant output of the genksyms program is saved as the "*.ver" file.
The "*.stamp" file just serve as a timestamp, that prevents any 
unnecessary re-creation of the "*.ver" files from the C-files.

The genksyms program read the pre-processed file from standard input,
parses it and if it finds any EXPORT_MODULE() symbol
in the input, it finds the definition of that function in the C sources
and computes the CRC checksum from the function name/definition, and emits
the macros that you see in your "*.ver" files that are therefore 
effectively CRC checksums of all exported functions in a C file.
To regenerate you could simply do the same by hand
like how the rules below dictate. Even if you hand copy those files
from the *.7 tree and "recompile" the kernel and the modules,
it is just fine. (the way the versioning of function names is incorporated 
into the kernel symbol table is by means of the pre-processor, and it 
will always #include the ".ver" files. It just wont be the crc checksums
though and by some weird chance, you may end up loading a module that 
may not have been written for your specific kernel version).
In any case the files that you mention don't export any symbols
and hence should be 0 byte files and can simply be touched for the build 
error to go away.

Hope this helps,
thanks
Murali


 Snipped from Rules.make

>>>

$(MODINCL)/%.ver: %.c
   @if [ ! -r $(MODINCL)/$*.stamp -o $(MODINCL)/$*.stamp -ot $< ]; then \
      echo '$(CC) $(CFLAGS) $(EXTRA_CFLAGS_nostdinc) -E -D__GENKSYMS__ 
$<'; \
      echo '| $(GENKSYMS) $(genksyms_smp_prefix) -k 
$(VERSION).$(PATCHLEVEL).$(SUBLEVEL) > $@.tmp'; \
      $(CC) $(CFLAGS) $(EXTRA_CFLAGS_nostdinc) -E -D__GENKSYMS__ $< \
      | $(GENKSYMS) $(genksyms_smp_prefix) -k 
$(VERSION).$(PATCHLEVEL).$(SUBLEVEL) > $@.tmp; \
      if [ -r $@ ] && cmp -s $@ $@.tmp; then echo $@ is unchanged; rm -f 
$@.tmp; \
      else echo mv $@.tmp $@; mv -f $@.tmp $@; fi; \
   fi; touch $(MODINCL)/$*.stamp

>>>>

> 
> In the 2.4.20.28 subtree, the two relevant files are:
>   -rw-r--r--    1 root     root            0 Dec 18  2003 af_netlink.stamp
>   -rw-r--r--    1 root     root            1 Dec 18  2003 af_netlink.ver
> 
> Obviously, I can create the two files in the 2.4.20.28.9 subtree or copy
> them from the *.7 subtree. But, it would be nice to know the
> ramifications, if any, of doing so. Any info is appreciated. Thanks.
>