+Module.symvers contains a list of all exported symbols from a kernel build.
+
+--- 7.1 Symbols from the kernel (vmlinux + modules)
+
+ During a kernel build, a file named Module.symvers will be generated.
+ Module.symvers contains all exported symbols from the kernel and
+ compiled modules. For each symbols, the corresponding CRC value
+ is stored too.
+
+ The syntax of the Module.symvers file is:
+ <CRC> <Symbol> <module>
+ Sample:
+ 0x2d036834 scsi_remove_host drivers/scsi/scsi_mod
+
+ For a kernel build without CONFIG_MODVERSIONS enabled, the crc
+ would read: 0x00000000
+
+ Module.symvers serves two purposes:
+ 1) It lists all exported symbols both from vmlinux and all modules
+ 2) It lists the CRC if CONFIG_MODVERSIONS is enabled
+
+--- 7.2 Symbols and external modules
+
+ When building an external module, the build system needs access to
+ the symbols from the kernel to check if all external symbols are
+ defined. This is done in the MODPOST step and to obtain all
+ symbols, modpost reads Module.symvers from the kernel.
+ If a Module.symvers file is present in the directory where
+ the external module is being built, this file will be read too.
+ During the MODPOST step, a new Module.symvers file will be written
+ containing all exported symbols that were not defined in the kernel.
+
+--- 7.3 Symbols from another external module
+
+ Sometimes, an external module uses exported symbols from another
+ external module. Kbuild needs to have full knowledge on all symbols
+ to avoid spitting out warnings about undefined symbols.
+ Two solutions exist to let kbuild know all symbols of more than
+ one external module.
+ The method with a top-level kbuild file is recommended but may be
+ impractical in certain situations.
+
+ Use a top-level Kbuild file
+ If you have two modules: 'foo' and 'bar', and 'foo' needs
+ symbols from 'bar', then one can use a common top-level kbuild
+ file so both modules are compiled in same build.
+
+ Consider following directory layout:
+ ./foo/ <= contains the foo module
+ ./bar/ <= contains the bar module
+ The top-level Kbuild file would then look like:
+
+ #./Kbuild: (this file may also be named Makefile)
+ obj-y := foo/ bar/
+
+ Executing:
+ make -C $KDIR M=`pwd`
+
+ will then do the expected and compile both modules with full
+ knowledge on symbols from both modules.
+
+ Use an extra Module.symvers file
+ When an external module is built, a Module.symvers file is
+ generated containing all exported symbols which are not
+ defined in the kernel.
+ To get access to symbols from module 'bar', one can copy the
+ Module.symvers file from the compilation of the 'bar' module
+ to the directory where the 'foo' module is built.
+ During the module build, kbuild will read the Module.symvers
+ file in the directory of the external module and when the
+ build is finished, a new Module.symvers file is created
+ containing the sum of all symbols defined and not part of the
+ kernel.