driver:linux2.6 Kernel module Export function instance (export_symbol) "Go"

Transferred from: http://blog.chinaunix.net/uid-23381466-id-3837650.html

Kernel version: 2.6.38-11-generic

The kernel itself is a large number of kernel symbol table export function, then should be exported, LDD3 said only need to export_symbol a class of macro export can, the results have been a long time, the final view of the document, is understood a little.

For the export symbol table, the kernel document gives three solutions, see trailer, now ignored.

Now there are two modules, a module export function myprint,b module Use this function, imagine if a module Export_symbol (myprint), actually B module know, it is clear that the B module is not very clear to the matter (so it is not very accurate), To call the Myprint function of the A module, you need to know the location of the Myprint function in memory, first in the kernel symbol table is not described, so ...

When we compile the A module, look at some of the files, do not have a module.symvers file, open to see what the situation?
0x705034f7 Myprint/home/darren/desktop/darren/print/myprint Export_symbol
Well, this line is sufficient for the B module, specifying the memory location, symbol name, and module path. The simplest way is to copy this file to the directory where the B module is located, and then compile it without annoying errors, and you can insmod the module normally. This approach is one of the methods mentioned in the kernel documentation.

But every time the function is called to copy once, even worse is a module every compile, to replicate again, why the kernel itself exported functions we can directly use it? Now it's settled:

Compile the kernel will also generate a module.symvers file, the kernel exported all the symbols are inside, we compile the module will actually call the kernel of the top layer makefile, that is, the kernel module.symvers to our module is visible, and our own MODULE.S Ymvers file, OK, the module a module.symvers file merge into the kernel module.symvers file, this time the Myprint function becomes the real export function, the other modules only need to life a bit can be used.

The code is as follows
a module code:

1. #include <linux/module.h>
2. #include <linux/init.h>
3. #include <linux/kernel.h>
5. Module_license ("GPL");
6. int myprint (void)
7. {
8. PRINTK ("C");
9. return 0;
10. }
11. static int darren_init (void)
12. {
13. return 0;
14. }
15. static void Darren_exit (void)
16. {
17. }
18. Module_init (Darren_init);
19. Module_exit (Darren_exit);
20. Export_symbol (Myprint);

B Module Code :

1. #include <linux/seq_file.h>
2. #include <linux/cdev.h>
3. #include <asm/system.h>
5. Module_license ("GPL");
6. extern int print (void);
7. static int darren_init (void)
8. {
9. int i=0;
10. PRINTK ("b module init\n");
11. for (; i<10;i++) print ();
12. return 0;
13. }
14. static void Darren_exit (void)
15. {
16. }
17. Module_init (Darren_init);
18. Module_exit (Darren_exit);

The makefile of a module is as follows:

1. Name:=a
2. Sym:=/usr/src/linux-headers-2.6.38-8-generic/module.symvers
3. dir:=/lib/modules/$ (shell uname-r)/build/
4. pwd:=$ (shell pwd)
5. Obj-m = $ (NAME). O
6. Build
8. Make-c $ (DIR) m=$ (PWD)
9. sudo chmod 777 $ (SYM)
10. sudo sed-i '/myprint/d ' $ (SYM)
11. sudo cat module.symvers>>$ (SYM)
12. sudo chmod 644 $ (SYM)

B-Module Makefile :

1. Name:=b
2. dir:=/lib/modules/$ (shell uname-r)/build/
3. pwd:=$ (shell pwd)
4. Obj-m = $ (NAME). O
5. Build
6. Make-c $ (DIR) m=$ (PWD)

Note: The path/usr/src/linux-headers-2.6.38-8-generic/module.symvers may not be correct if it does not change to/usr/src/linux-headers-' uname-r '- Generic/module.symvers

Kernel Documentation :

2. Sometimes, an external module uses exported symbols from
4. Another external module. Kbuild needs to has full knowledge of
6. All symbols to avoid spitting out warnings about undefined
8. Symbols. Three solutions exist for this situation.
12. Note:the method with a top-level Kbuild file is recommended
14. But May is impractical in certain situations.
18. Use a top-level kbuild file
20. If you have both modules, Foo.ko and Bar.ko, where
22. Foo.ko needs symbols from Bar.ko, can use a
24. Common top-level Kbuild file so both modules is
26. Compiled in the same build. Consider the following
28. Directory layout:
32. ./foo/<= contains Foo.ko
34. ./bar/<= contains Bar.ko
38. The top-level kbuild file would then look like:
42. #./kbuild (or./makefile):
44. Obj-y: = foo/bar/
48. and executing
52. $ make-c $KDIR m= $PWD
56. Expected and compile both modules with
58. Full knowledge of symbols from either module.
62. Use of an extra module.symvers file
64. When the external module is built, a module.symvers file
66. is generated containing all exported symbols which are
68. Not defined in the kernel. To get access to symbols
70. From Bar.ko, copy the Module.symvers file from the
72. Compilation of Bar.ko to the directory where Foo.ko is
74. Built. During the module build, Kbuild would read the
76. Module.symvers file in the directory of the external
78. module, and when the build is finished, a new
80. Module.symvers file is created containing the sum of
82. All symbols defined and is part of the kernel.
86. Use ' Make ' variable kbuild_extra_symbols
88. If It is impractical to copy module.symvers from
90. Another module, you can assign a space separated list
92. of files to Kbuild_extra_symbols in your build file.
94. These files would be loaded by modpost during the
96. Initialization of its symbol tables.

driver:linux2.6 Kernel module Export function instance (export_symbol) "Go"