关于内核中export_symbols()用后warning修改。

no symbol version for XXXX  

    用EXPORT_SYMBOL引出函数后，第二个模块加载时候报错：
osd: no symbol version for func_test
osd: Unknown symbol func_test
    确认了下，GPL声明了，/proc/kallsyms里也能查到func_test。查了半天终于明白了
    6.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 symbol, the corresponding CRC value is also stored.
        The syntax of the Module.symvers file is:
                <CRC>       <Symbol>           <module>
                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 from vmlinux and all modules.
        2) It lists the CRC if CONFIG_MODVERSIONS is enabled.

    6.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. modpost obtains the symbols by reading Module.symvers from the kernel source tree. 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.

    6.3 Symbols From Another External Module
        Sometimes, an external module uses exported symbols from another external module. kbuild needs to have full knowledge of all symbols to avoid spitting out warnings about undefined symbols. Three solutions exist for this situation.

        NOTE: 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.ko and bar.ko, where foo.ko needs symbols from bar.ko, you can use a common top-level kbuild file so both modules are compiled in the same build. Consider the following directory layout:
                ./foo/ <= contains foo.ko
                ./bar/ <= contains bar.ko
                The top-level kbuild file would then look like:
                #./Kbuild (or ./Makefile):
                        obj-y := foo/ bar/
                And executing
                        $ make -C $KDIR M=$PWD
               will then do the expected and compile both modules with  full knowledge of symbols from either module.

        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 bar.ko, copy the Module.symvers file from the compilation of bar.ko to the directory where foo.ko 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.

        Use "make" variable KBUILD_EXTRA_SYMBOLS
        If it is impractical to copy Module.symvers from another module, you can assign a space separated list of files to KBUILD_EXTRA_SYMBOLS in your build file. These files will be loaded by modpost during the initialization of its symbol tables.

   即
有两个我们自己的模块，其中Module B使用了Module A中export的函数，因此在Module B的Makefile中必须加上这样的选项
KBUILD_EXTRA_SYMBOLS += /path/to/Module A/Module.symvers
export KBUILD_EXTRA_SYMBOLS
这样在编译Module B时，才不会出现Warning，提示说func1这个符号找不到，而编译得到的ko加载时也会出错。






转自http://falloutmx.blog.163.com/blog/static/39236020201110152245513/