--- 2.2 Available targets
--- 2.3 Available options
--- 2.4 Preparing the kernel tree for module build
- --- 2.5 Building separate files for a module
=== 3. Example commands
=== 4. Creating a kbuild file for an external module
=== 5. Include files
=== 6. Module installation
--- 6.1 INSTALL_MOD_PATH
--- 6.2 INSTALL_MOD_DIR
- === 7. Module versioning & Module.symvers
- --- 7.1 Symbols fron the kernel (vmlinux + modules)
- --- 7.2 Symbols and external modules
- --- 7.3 Symbols from another external module
+ === 7. Module versioning
=== 8. Tips & Tricks
--- 8.1 Testing for CONFIG_FOO_BAR
of modules. The author of an external modules should supply
a makefile that hides most of the complexity so one only has to type
'make' to build the module. A complete example will be present in
-chapter 4, "Creating a kbuild file for an external module".
+chapter ยค. Creating a kbuild file for an external module".
=== 2. How to build external modules
make -C $KDIR M=$PWD modules_install
Install the external module(s).
Installation default is in /lib/modules/<kernel-version>/extra,
- but may be prefixed with INSTALL_MOD_PATH - see separate
- chapter.
+ but may be prefixed with INSTALL_MOD_PATH - see separate chapter.
make -C $KDIR M=$PWD clean
Remove all generated files for the module - the kernel
Therefore a full kernel build needs to be executed to make
module versioning work.
---- 2.5 Building separate files for a module
- It is possible to build single files which is part of a module.
- This works equal for the kernel, a module and even for external
- modules.
- Examples (module foo.ko, consist of bar.o, baz.o):
- make -C $KDIR M=`pwd` bar.lst
- make -C $KDIR M=`pwd` bar.o
- make -C $KDIR M=`pwd` foo.ko
- make -C $KDIR M=`pwd` /
-
=== 3. Example commands
=> Install dir: /lib/modules/$(KERNELRELEASE)/gandalf
-=== 7. Module versioning & Module.symvers
+=== 7. Module versioning
Module versioning is enabled by the CONFIG_MODVERSIONS tag.
compared with similar values in the module. If they are not equal then the
kernel refuses to load the module.
-Module.symvers contains a list of all exported symbols from a kernel build.
-
---- 7.1 Symbols fron 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
+During a kernel build a file named Module.symvers will be generated. This
+file includes the symbol version of all symbols within the kernel. If the
+Module.symvers file is saved from the last full kernel compile one does not
+have to do a full kernel compile to build a module version's compatible module.
- For a kernel build without CONFIG_MODVERSIONING enabled the crc
- would read: 0x00000000
-
- Module.symvers serve two purposes.
- 1) It list all exported symbols both from vmlinux and all modules
- 2) It list CRC if CONFIG_MODVERSION 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 build this file will be read too.
- During the MODPOST step a new Module.symvers file will be written
- containing all exported symbols that was not defined in the kernel.
-
---- 7.3 Symbols from another external module
-
- Sometimes one 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', '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 build 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 build.
- 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.
-
=== 8. Tips & Tricks
--- 8.1 Testing for CONFIG_FOO_BAR
git://git.onelab.eu / linux-2.6.git / blobdiff