Loading...
1=========================
2Building External Modules
3=========================
4
5This document describes how to build an out-of-tree kernel module.
6
7Introduction
8============
9
10"kbuild" is the build system used by the Linux kernel. Modules must use
11kbuild to stay compatible with changes in the build infrastructure and
12to pick up the right flags to the compiler. Functionality for building modules
13both in-tree and out-of-tree is provided. The method for building
14either is similar, and all modules are initially developed and built
15out-of-tree.
16
17Covered in this document is information aimed at developers interested
18in building out-of-tree (or "external") modules. The author of an
19external module should supply a makefile that hides most of the
20complexity, so one only has to type "make" to build the module. This is
21easily accomplished, and a complete example will be presented in
22section `Creating a Kbuild File for an External Module`_.
23
24
25How to Build External Modules
26=============================
27
28To build external modules, you must have a prebuilt kernel available
29that contains the configuration and header files used in the build.
30Also, the kernel must have been built with modules enabled. If you are
31using a distribution kernel, there will be a package for the kernel you
32are running provided by your distribution.
33
34An alternative is to use the "make" target "modules_prepare." This will
35make sure the kernel contains the information required. The target
36exists solely as a simple way to prepare a kernel source tree for
37building external modules.
38
39NOTE: "modules_prepare" will not build Module.symvers even if
40CONFIG_MODVERSIONS is set; therefore, a full kernel build needs to be
41executed to make module versioning work.
42
43Command Syntax
44--------------
45
46 The command to build an external module is::
47
48 $ make -C <path_to_kernel_dir> M=$PWD
49
50 The kbuild system knows that an external module is being built
51 due to the "M=<dir>" option given in the command.
52
53 To build against the running kernel use::
54
55 $ make -C /lib/modules/`uname -r`/build M=$PWD
56
57 Then to install the module(s) just built, add the target
58 "modules_install" to the command::
59
60 $ make -C /lib/modules/`uname -r`/build M=$PWD modules_install
61
62 Starting from Linux 6.13, you can use the -f option instead of -C. This
63 will avoid unnecessary change of the working directory. The external
64 module will be output to the directory where you invoke make.
65
66 $ make -f /lib/modules/`uname -r`/build/Makefile M=$PWD
67
68Options
69-------
70
71 ($KDIR refers to the path of the kernel source directory, or the path
72 of the kernel output directory if the kernel was built in a separate
73 build directory.)
74
75 You can optionally pass MO= option if you want to build the modules in
76 a separate directory.
77
78 make -C $KDIR M=$PWD [MO=$BUILD_DIR]
79
80 -C $KDIR
81 The directory that contains the kernel and relevant build
82 artifacts used for building an external module.
83 "make" will actually change to the specified directory
84 when executing and will change back when finished.
85
86 M=$PWD
87 Informs kbuild that an external module is being built.
88 The value given to "M" is the absolute path of the
89 directory where the external module (kbuild file) is
90 located.
91
92 MO=$BUILD_DIR
93 Specifies a separate output directory for the external module.
94
95Targets
96-------
97
98 When building an external module, only a subset of the "make"
99 targets are available.
100
101 make -C $KDIR M=$PWD [target]
102
103 The default will build the module(s) located in the current
104 directory, so a target does not need to be specified. All
105 output files will also be generated in this directory. No
106 attempts are made to update the kernel source, and it is a
107 precondition that a successful "make" has been executed for the
108 kernel.
109
110 modules
111 The default target for external modules. It has the
112 same functionality as if no target was specified. See
113 description above.
114
115 modules_install
116 Install the external module(s). The default location is
117 /lib/modules/<kernel_release>/updates/, but a prefix may
118 be added with INSTALL_MOD_PATH (discussed in section
119 `Module Installation`_).
120
121 clean
122 Remove all generated files in the module directory only.
123
124 help
125 List the available targets for external modules.
126
127Building Separate Files
128-----------------------
129
130 It is possible to build single files that are part of a module.
131 This works equally well for the kernel, a module, and even for
132 external modules.
133
134 Example (The module foo.ko, consist of bar.o and baz.o)::
135
136 make -C $KDIR M=$PWD bar.lst
137 make -C $KDIR M=$PWD baz.o
138 make -C $KDIR M=$PWD foo.ko
139 make -C $KDIR M=$PWD ./
140
141
142Creating a Kbuild File for an External Module
143=============================================
144
145In the last section we saw the command to build a module for the
146running kernel. The module is not actually built, however, because a
147build file is required. Contained in this file will be the name of
148the module(s) being built, along with the list of requisite source
149files. The file may be as simple as a single line::
150
151 obj-m := <module_name>.o
152
153The kbuild system will build <module_name>.o from <module_name>.c,
154and, after linking, will result in the kernel module <module_name>.ko.
155The above line can be put in either a "Kbuild" file or a "Makefile."
156When the module is built from multiple sources, an additional line is
157needed listing the files::
158
159 <module_name>-y := <src1>.o <src2>.o ...
160
161NOTE: Further documentation describing the syntax used by kbuild is
162located in Documentation/kbuild/makefiles.rst.
163
164The examples below demonstrate how to create a build file for the
165module 8123.ko, which is built from the following files::
166
167 8123_if.c
168 8123_if.h
169 8123_pci.c
170
171Shared Makefile
172---------------
173
174 An external module always includes a wrapper makefile that
175 supports building the module using "make" with no arguments.
176 This target is not used by kbuild; it is only for convenience.
177 Additional functionality, such as test targets, can be included
178 but should be filtered out from kbuild due to possible name
179 clashes.
180
181 Example 1::
182
183 --> filename: Makefile
184 ifneq ($(KERNELRELEASE),)
185 # kbuild part of makefile
186 obj-m := 8123.o
187 8123-y := 8123_if.o 8123_pci.o
188
189 else
190 # normal makefile
191 KDIR ?= /lib/modules/`uname -r`/build
192
193 default:
194 $(MAKE) -C $(KDIR) M=$$PWD
195
196 endif
197
198 The check for KERNELRELEASE is used to separate the two parts
199 of the makefile. In the example, kbuild will only see the two
200 assignments, whereas "make" will see everything except these
201 two assignments. This is due to two passes made on the file:
202 the first pass is by the "make" instance run on the command
203 line; the second pass is by the kbuild system, which is
204 initiated by the parameterized "make" in the default target.
205
206Separate Kbuild File and Makefile
207---------------------------------
208
209 Kbuild will first look for a file named "Kbuild", and if it is not
210 found, it will then look for "Makefile". Utilizing a "Kbuild" file
211 allows us to split up the "Makefile" from example 1 into two files:
212
213 Example 2::
214
215 --> filename: Kbuild
216 obj-m := 8123.o
217 8123-y := 8123_if.o 8123_pci.o
218
219 --> filename: Makefile
220 KDIR ?= /lib/modules/`uname -r`/build
221
222 default:
223 $(MAKE) -C $(KDIR) M=$$PWD
224
225 The split in example 2 is questionable due to the simplicity of
226 each file; however, some external modules use makefiles
227 consisting of several hundred lines, and here it really pays
228 off to separate the kbuild part from the rest.
229
230 Linux 6.13 and later support another way. The external module Makefile
231 can include the kernel Makefile directly, rather than invoking sub Make.
232
233 Example 3::
234
235 --> filename: Kbuild
236 obj-m := 8123.o
237 8123-y := 8123_if.o 8123_pci.o
238
239 --> filename: Makefile
240 KDIR ?= /lib/modules/$(shell uname -r)/build
241 export KBUILD_EXTMOD := $(realpath $(dir $(lastword $(MAKEFILE_LIST))))
242 include $(KDIR)/Makefile
243
244
245Building Multiple Modules
246-------------------------
247
248 kbuild supports building multiple modules with a single build
249 file. For example, if you wanted to build two modules, foo.ko
250 and bar.ko, the kbuild lines would be::
251
252 obj-m := foo.o bar.o
253 foo-y := <foo_srcs>
254 bar-y := <bar_srcs>
255
256 It is that simple!
257
258
259Include Files
260=============
261
262Within the kernel, header files are kept in standard locations
263according to the following rule:
264
265 * If the header file only describes the internal interface of a
266 module, then the file is placed in the same directory as the
267 source files.
268 * If the header file describes an interface used by other parts
269 of the kernel that are located in different directories, then
270 the file is placed in include/linux/.
271
272 NOTE:
273 There are two notable exceptions to this rule: larger
274 subsystems have their own directory under include/, such as
275 include/scsi; and architecture specific headers are located
276 under arch/$(SRCARCH)/include/.
277
278Kernel Includes
279---------------
280
281 To include a header file located under include/linux/, simply
282 use::
283
284 #include <linux/module.h>
285
286 kbuild will add options to the compiler so the relevant directories
287 are searched.
288
289Single Subdirectory
290-------------------
291
292 External modules tend to place header files in a separate
293 include/ directory where their source is located, although this
294 is not the usual kernel style. To inform kbuild of the
295 directory, use either ccflags-y or CFLAGS_<filename>.o.
296
297 Using the example from section 3, if we moved 8123_if.h to a
298 subdirectory named include, the resulting kbuild file would
299 look like::
300
301 --> filename: Kbuild
302 obj-m := 8123.o
303
304 ccflags-y := -I $(src)/include
305 8123-y := 8123_if.o 8123_pci.o
306
307Several Subdirectories
308----------------------
309
310 kbuild can handle files that are spread over several directories.
311 Consider the following example::
312
313 .
314 |__ src
315 | |__ complex_main.c
316 | |__ hal
317 | |__ hardwareif.c
318 | |__ include
319 | |__ hardwareif.h
320 |__ include
321 |__ complex.h
322
323 To build the module complex.ko, we then need the following
324 kbuild file::
325
326 --> filename: Kbuild
327 obj-m := complex.o
328 complex-y := src/complex_main.o
329 complex-y += src/hal/hardwareif.o
330
331 ccflags-y := -I$(src)/include
332 ccflags-y += -I$(src)/src/hal/include
333
334 As you can see, kbuild knows how to handle object files located
335 in other directories. The trick is to specify the directory
336 relative to the kbuild file's location. That being said, this
337 is NOT recommended practice.
338
339 For the header files, kbuild must be explicitly told where to
340 look. When kbuild executes, the current directory is always the
341 root of the kernel tree (the argument to "-C") and therefore an
342 absolute path is needed. $(src) provides the absolute path by
343 pointing to the directory where the currently executing kbuild
344 file is located.
345
346
347Module Installation
348===================
349
350Modules which are included in the kernel are installed in the
351directory:
352
353 /lib/modules/$(KERNELRELEASE)/kernel/
354
355And external modules are installed in:
356
357 /lib/modules/$(KERNELRELEASE)/updates/
358
359INSTALL_MOD_PATH
360----------------
361
362 Above are the default directories but as always some level of
363 customization is possible. A prefix can be added to the
364 installation path using the variable INSTALL_MOD_PATH::
365
366 $ make INSTALL_MOD_PATH=/frodo modules_install
367 => Install dir: /frodo/lib/modules/$(KERNELRELEASE)/kernel/
368
369 INSTALL_MOD_PATH may be set as an ordinary shell variable or,
370 as shown above, can be specified on the command line when
371 calling "make." This has effect when installing both in-tree
372 and out-of-tree modules.
373
374INSTALL_MOD_DIR
375---------------
376
377 External modules are by default installed to a directory under
378 /lib/modules/$(KERNELRELEASE)/updates/, but you may wish to
379 locate modules for a specific functionality in a separate
380 directory. For this purpose, use INSTALL_MOD_DIR to specify an
381 alternative name to "updates."::
382
383 $ make INSTALL_MOD_DIR=gandalf -C $KDIR \
384 M=$PWD modules_install
385 => Install dir: /lib/modules/$(KERNELRELEASE)/gandalf/
386
387
388Module Versioning
389=================
390
391Module versioning is enabled by the CONFIG_MODVERSIONS tag, and is used
392as a simple ABI consistency check. A CRC value of the full prototype
393for an exported symbol is created. When a module is loaded/used, the
394CRC values contained in the kernel are compared with similar values in
395the module; if they are not equal, the kernel refuses to load the
396module.
397
398Module.symvers contains a list of all exported symbols from a kernel
399build.
400
401Symbols From the Kernel (vmlinux + modules)
402-------------------------------------------
403
404 During a kernel build, a file named Module.symvers will be
405 generated. Module.symvers contains all exported symbols from
406 the kernel and compiled modules. For each symbol, the
407 corresponding CRC value is also stored.
408
409 The syntax of the Module.symvers file is::
410
411 <CRC> <Symbol> <Module> <Export Type> <Namespace>
412
413 0xe1cc2a05 usb_stor_suspend drivers/usb/storage/usb-storage EXPORT_SYMBOL_GPL USB_STORAGE
414
415 The fields are separated by tabs and values may be empty (e.g.
416 if no namespace is defined for an exported symbol).
417
418 For a kernel build without CONFIG_MODVERSIONS enabled, the CRC
419 would read 0x00000000.
420
421 Module.symvers serves two purposes:
422
423 1) It lists all exported symbols from vmlinux and all modules.
424 2) It lists the CRC if CONFIG_MODVERSIONS is enabled.
425
426Symbols and External Modules
427----------------------------
428
429 When building an external module, the build system needs access
430 to the symbols from the kernel to check if all external symbols
431 are defined. This is done in the MODPOST step. modpost obtains
432 the symbols by reading Module.symvers from the kernel source
433 tree. During the MODPOST step, a new Module.symvers file will be
434 written containing all exported symbols from that external module.
435
436Symbols From Another External Module
437------------------------------------
438
439 Sometimes, an external module uses exported symbols from
440 another external module. Kbuild needs to have full knowledge of
441 all symbols to avoid spitting out warnings about undefined
442 symbols. Two solutions exist for this situation.
443
444 NOTE: The method with a top-level kbuild file is recommended
445 but may be impractical in certain situations.
446
447 Use a top-level kbuild file
448 If you have two modules, foo.ko and bar.ko, where
449 foo.ko needs symbols from bar.ko, you can use a
450 common top-level kbuild file so both modules are
451 compiled in the same build. Consider the following
452 directory layout::
453
454 ./foo/ <= contains foo.ko
455 ./bar/ <= contains bar.ko
456
457 The top-level kbuild file would then look like::
458
459 #./Kbuild (or ./Makefile):
460 obj-m := foo/ bar/
461
462 And executing::
463
464 $ make -C $KDIR M=$PWD
465
466 will then do the expected and compile both modules with
467 full knowledge of symbols from either module.
468
469 Use "make" variable KBUILD_EXTRA_SYMBOLS
470 If it is impractical to add a top-level kbuild file,
471 you can assign a space separated list
472 of files to KBUILD_EXTRA_SYMBOLS in your build file.
473 These files will be loaded by modpost during the
474 initialization of its symbol tables.
475
476
477Tips & Tricks
478=============
479
480Testing for CONFIG_FOO_BAR
481--------------------------
482
483 Modules often need to check for certain `CONFIG_` options to
484 decide if a specific feature is included in the module. In
485 kbuild this is done by referencing the `CONFIG_` variable
486 directly::
487
488 #fs/ext2/Makefile
489 obj-$(CONFIG_EXT2_FS) += ext2.o
490
491 ext2-y := balloc.o bitmap.o dir.o
492 ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o
1=========================
2Building External Modules
3=========================
4
5This document describes how to build an out-of-tree kernel module.
6
7.. Table of Contents
8
9 === 1 Introduction
10 === 2 How to Build External Modules
11 --- 2.1 Command Syntax
12 --- 2.2 Options
13 --- 2.3 Targets
14 --- 2.4 Building Separate Files
15 === 3. Creating a Kbuild File for an External Module
16 --- 3.1 Shared Makefile
17 --- 3.2 Separate Kbuild file and Makefile
18 --- 3.3 Binary Blobs
19 --- 3.4 Building Multiple Modules
20 === 4. Include Files
21 --- 4.1 Kernel Includes
22 --- 4.2 Single Subdirectory
23 --- 4.3 Several Subdirectories
24 === 5. Module Installation
25 --- 5.1 INSTALL_MOD_PATH
26 --- 5.2 INSTALL_MOD_DIR
27 === 6. Module Versioning
28 --- 6.1 Symbols From the Kernel (vmlinux + modules)
29 --- 6.2 Symbols and External Modules
30 --- 6.3 Symbols From Another External Module
31 === 7. Tips & Tricks
32 --- 7.1 Testing for CONFIG_FOO_BAR
33
34
35
361. Introduction
37===============
38
39"kbuild" is the build system used by the Linux kernel. Modules must use
40kbuild to stay compatible with changes in the build infrastructure and
41to pick up the right flags to "gcc." Functionality for building modules
42both in-tree and out-of-tree is provided. The method for building
43either is similar, and all modules are initially developed and built
44out-of-tree.
45
46Covered in this document is information aimed at developers interested
47in building out-of-tree (or "external") modules. The author of an
48external module should supply a makefile that hides most of the
49complexity, so one only has to type "make" to build the module. This is
50easily accomplished, and a complete example will be presented in
51section 3.
52
53
542. How to Build External Modules
55================================
56
57To build external modules, you must have a prebuilt kernel available
58that contains the configuration and header files used in the build.
59Also, the kernel must have been built with modules enabled. If you are
60using a distribution kernel, there will be a package for the kernel you
61are running provided by your distribution.
62
63An alternative is to use the "make" target "modules_prepare." This will
64make sure the kernel contains the information required. The target
65exists solely as a simple way to prepare a kernel source tree for
66building external modules.
67
68NOTE: "modules_prepare" will not build Module.symvers even if
69CONFIG_MODVERSIONS is set; therefore, a full kernel build needs to be
70executed to make module versioning work.
71
722.1 Command Syntax
73==================
74
75 The command to build an external module is::
76
77 $ make -C <path_to_kernel_src> M=$PWD
78
79 The kbuild system knows that an external module is being built
80 due to the "M=<dir>" option given in the command.
81
82 To build against the running kernel use::
83
84 $ make -C /lib/modules/`uname -r`/build M=$PWD
85
86 Then to install the module(s) just built, add the target
87 "modules_install" to the command::
88
89 $ make -C /lib/modules/`uname -r`/build M=$PWD modules_install
90
912.2 Options
92===========
93
94 ($KDIR refers to the path of the kernel source directory.)
95
96 make -C $KDIR M=$PWD
97
98 -C $KDIR
99 The directory where the kernel source is located.
100 "make" will actually change to the specified directory
101 when executing and will change back when finished.
102
103 M=$PWD
104 Informs kbuild that an external module is being built.
105 The value given to "M" is the absolute path of the
106 directory where the external module (kbuild file) is
107 located.
108
1092.3 Targets
110===========
111
112 When building an external module, only a subset of the "make"
113 targets are available.
114
115 make -C $KDIR M=$PWD [target]
116
117 The default will build the module(s) located in the current
118 directory, so a target does not need to be specified. All
119 output files will also be generated in this directory. No
120 attempts are made to update the kernel source, and it is a
121 precondition that a successful "make" has been executed for the
122 kernel.
123
124 modules
125 The default target for external modules. It has the
126 same functionality as if no target was specified. See
127 description above.
128
129 modules_install
130 Install the external module(s). The default location is
131 /lib/modules/<kernel_release>/extra/, but a prefix may
132 be added with INSTALL_MOD_PATH (discussed in section 5).
133
134 clean
135 Remove all generated files in the module directory only.
136
137 help
138 List the available targets for external modules.
139
1402.4 Building Separate Files
141===========================
142
143 It is possible to build single files that are part of a module.
144 This works equally well for the kernel, a module, and even for
145 external modules.
146
147 Example (The module foo.ko, consist of bar.o and baz.o)::
148
149 make -C $KDIR M=$PWD bar.lst
150 make -C $KDIR M=$PWD baz.o
151 make -C $KDIR M=$PWD foo.ko
152 make -C $KDIR M=$PWD ./
153
154
1553. Creating a Kbuild File for an External Module
156================================================
157
158In the last section we saw the command to build a module for the
159running kernel. The module is not actually built, however, because a
160build file is required. Contained in this file will be the name of
161the module(s) being built, along with the list of requisite source
162files. The file may be as simple as a single line::
163
164 obj-m := <module_name>.o
165
166The kbuild system will build <module_name>.o from <module_name>.c,
167and, after linking, will result in the kernel module <module_name>.ko.
168The above line can be put in either a "Kbuild" file or a "Makefile."
169When the module is built from multiple sources, an additional line is
170needed listing the files::
171
172 <module_name>-y := <src1>.o <src2>.o ...
173
174NOTE: Further documentation describing the syntax used by kbuild is
175located in Documentation/kbuild/makefiles.rst.
176
177The examples below demonstrate how to create a build file for the
178module 8123.ko, which is built from the following files::
179
180 8123_if.c
181 8123_if.h
182 8123_pci.c
183 8123_bin.o_shipped <= Binary blob
184
1853.1 Shared Makefile
186-------------------
187
188 An external module always includes a wrapper makefile that
189 supports building the module using "make" with no arguments.
190 This target is not used by kbuild; it is only for convenience.
191 Additional functionality, such as test targets, can be included
192 but should be filtered out from kbuild due to possible name
193 clashes.
194
195 Example 1::
196
197 --> filename: Makefile
198 ifneq ($(KERNELRELEASE),)
199 # kbuild part of makefile
200 obj-m := 8123.o
201 8123-y := 8123_if.o 8123_pci.o 8123_bin.o
202
203 else
204 # normal makefile
205 KDIR ?= /lib/modules/`uname -r`/build
206
207 default:
208 $(MAKE) -C $(KDIR) M=$$PWD
209
210 # Module specific targets
211 genbin:
212 echo "X" > 8123_bin.o_shipped
213
214 endif
215
216 The check for KERNELRELEASE is used to separate the two parts
217 of the makefile. In the example, kbuild will only see the two
218 assignments, whereas "make" will see everything except these
219 two assignments. This is due to two passes made on the file:
220 the first pass is by the "make" instance run on the command
221 line; the second pass is by the kbuild system, which is
222 initiated by the parameterized "make" in the default target.
223
2243.2 Separate Kbuild File and Makefile
225-------------------------------------
226
227 In newer versions of the kernel, kbuild will first look for a
228 file named "Kbuild," and only if that is not found, will it
229 then look for a makefile. Utilizing a "Kbuild" file allows us
230 to split up the makefile from example 1 into two files:
231
232 Example 2::
233
234 --> filename: Kbuild
235 obj-m := 8123.o
236 8123-y := 8123_if.o 8123_pci.o 8123_bin.o
237
238 --> filename: Makefile
239 KDIR ?= /lib/modules/`uname -r`/build
240
241 default:
242 $(MAKE) -C $(KDIR) M=$$PWD
243
244 # Module specific targets
245 genbin:
246 echo "X" > 8123_bin.o_shipped
247
248 The split in example 2 is questionable due to the simplicity of
249 each file; however, some external modules use makefiles
250 consisting of several hundred lines, and here it really pays
251 off to separate the kbuild part from the rest.
252
253 The next example shows a backward compatible version.
254
255 Example 3::
256
257 --> filename: Kbuild
258 obj-m := 8123.o
259 8123-y := 8123_if.o 8123_pci.o 8123_bin.o
260
261 --> filename: Makefile
262 ifneq ($(KERNELRELEASE),)
263 # kbuild part of makefile
264 include Kbuild
265
266 else
267 # normal makefile
268 KDIR ?= /lib/modules/`uname -r`/build
269
270 default:
271 $(MAKE) -C $(KDIR) M=$$PWD
272
273 # Module specific targets
274 genbin:
275 echo "X" > 8123_bin.o_shipped
276
277 endif
278
279 Here the "Kbuild" file is included from the makefile. This
280 allows an older version of kbuild, which only knows of
281 makefiles, to be used when the "make" and kbuild parts are
282 split into separate files.
283
2843.3 Binary Blobs
285----------------
286
287 Some external modules need to include an object file as a blob.
288 kbuild has support for this, but requires the blob file to be
289 named <filename>_shipped. When the kbuild rules kick in, a copy
290 of <filename>_shipped is created with _shipped stripped off,
291 giving us <filename>. This shortened filename can be used in
292 the assignment to the module.
293
294 Throughout this section, 8123_bin.o_shipped has been used to
295 build the kernel module 8123.ko; it has been included as
296 8123_bin.o::
297
298 8123-y := 8123_if.o 8123_pci.o 8123_bin.o
299
300 Although there is no distinction between the ordinary source
301 files and the binary file, kbuild will pick up different rules
302 when creating the object file for the module.
303
3043.4 Building Multiple Modules
305=============================
306
307 kbuild supports building multiple modules with a single build
308 file. For example, if you wanted to build two modules, foo.ko
309 and bar.ko, the kbuild lines would be::
310
311 obj-m := foo.o bar.o
312 foo-y := <foo_srcs>
313 bar-y := <bar_srcs>
314
315 It is that simple!
316
317
3184. Include Files
319================
320
321Within the kernel, header files are kept in standard locations
322according to the following rule:
323
324 * If the header file only describes the internal interface of a
325 module, then the file is placed in the same directory as the
326 source files.
327 * If the header file describes an interface used by other parts
328 of the kernel that are located in different directories, then
329 the file is placed in include/linux/.
330
331 NOTE:
332 There are two notable exceptions to this rule: larger
333 subsystems have their own directory under include/, such as
334 include/scsi; and architecture specific headers are located
335 under arch/$(ARCH)/include/.
336
3374.1 Kernel Includes
338-------------------
339
340 To include a header file located under include/linux/, simply
341 use::
342
343 #include <linux/module.h>
344
345 kbuild will add options to "gcc" so the relevant directories
346 are searched.
347
3484.2 Single Subdirectory
349-----------------------
350
351 External modules tend to place header files in a separate
352 include/ directory where their source is located, although this
353 is not the usual kernel style. To inform kbuild of the
354 directory, use either ccflags-y or CFLAGS_<filename>.o.
355
356 Using the example from section 3, if we moved 8123_if.h to a
357 subdirectory named include, the resulting kbuild file would
358 look like::
359
360 --> filename: Kbuild
361 obj-m := 8123.o
362
363 ccflags-y := -Iinclude
364 8123-y := 8123_if.o 8123_pci.o 8123_bin.o
365
366 Note that in the assignment there is no space between -I and
367 the path. This is a limitation of kbuild: there must be no
368 space present.
369
3704.3 Several Subdirectories
371--------------------------
372
373 kbuild can handle files that are spread over several directories.
374 Consider the following example::
375
376 .
377 |__ src
378 | |__ complex_main.c
379 | |__ hal
380 | |__ hardwareif.c
381 | |__ include
382 | |__ hardwareif.h
383 |__ include
384 |__ complex.h
385
386 To build the module complex.ko, we then need the following
387 kbuild file::
388
389 --> filename: Kbuild
390 obj-m := complex.o
391 complex-y := src/complex_main.o
392 complex-y += src/hal/hardwareif.o
393
394 ccflags-y := -I$(src)/include
395 ccflags-y += -I$(src)/src/hal/include
396
397 As you can see, kbuild knows how to handle object files located
398 in other directories. The trick is to specify the directory
399 relative to the kbuild file's location. That being said, this
400 is NOT recommended practice.
401
402 For the header files, kbuild must be explicitly told where to
403 look. When kbuild executes, the current directory is always the
404 root of the kernel tree (the argument to "-C") and therefore an
405 absolute path is needed. $(src) provides the absolute path by
406 pointing to the directory where the currently executing kbuild
407 file is located.
408
409
4105. Module Installation
411======================
412
413Modules which are included in the kernel are installed in the
414directory:
415
416 /lib/modules/$(KERNELRELEASE)/kernel/
417
418And external modules are installed in:
419
420 /lib/modules/$(KERNELRELEASE)/extra/
421
4225.1 INSTALL_MOD_PATH
423--------------------
424
425 Above are the default directories but as always some level of
426 customization is possible. A prefix can be added to the
427 installation path using the variable INSTALL_MOD_PATH::
428
429 $ make INSTALL_MOD_PATH=/frodo modules_install
430 => Install dir: /frodo/lib/modules/$(KERNELRELEASE)/kernel/
431
432 INSTALL_MOD_PATH may be set as an ordinary shell variable or,
433 as shown above, can be specified on the command line when
434 calling "make." This has effect when installing both in-tree
435 and out-of-tree modules.
436
4375.2 INSTALL_MOD_DIR
438-------------------
439
440 External modules are by default installed to a directory under
441 /lib/modules/$(KERNELRELEASE)/extra/, but you may wish to
442 locate modules for a specific functionality in a separate
443 directory. For this purpose, use INSTALL_MOD_DIR to specify an
444 alternative name to "extra."::
445
446 $ make INSTALL_MOD_DIR=gandalf -C $KDIR \
447 M=$PWD modules_install
448 => Install dir: /lib/modules/$(KERNELRELEASE)/gandalf/
449
450
4516. Module Versioning
452====================
453
454Module versioning is enabled by the CONFIG_MODVERSIONS tag, and is used
455as a simple ABI consistency check. A CRC value of the full prototype
456for an exported symbol is created. When a module is loaded/used, the
457CRC values contained in the kernel are compared with similar values in
458the module; if they are not equal, the kernel refuses to load the
459module.
460
461Module.symvers contains a list of all exported symbols from a kernel
462build.
463
4646.1 Symbols From the Kernel (vmlinux + modules)
465-----------------------------------------------
466
467 During a kernel build, a file named Module.symvers will be
468 generated. Module.symvers contains all exported symbols from
469 the kernel and compiled modules. For each symbol, the
470 corresponding CRC value is also stored.
471
472 The syntax of the Module.symvers file is::
473
474 <CRC> <Symbol> <Module> <Export Type> <Namespace>
475
476 0xe1cc2a05 usb_stor_suspend drivers/usb/storage/usb-storage EXPORT_SYMBOL_GPL USB_STORAGE
477
478 The fields are separated by tabs and values may be empty (e.g.
479 if no namespace is defined for an exported symbol).
480
481 For a kernel build without CONFIG_MODVERSIONS enabled, the CRC
482 would read 0x00000000.
483
484 Module.symvers serves two purposes:
485
486 1) It lists all exported symbols from vmlinux and all modules.
487 2) It lists the CRC if CONFIG_MODVERSIONS is enabled.
488
4896.2 Symbols and External Modules
490--------------------------------
491
492 When building an external module, the build system needs access
493 to the symbols from the kernel to check if all external symbols
494 are defined. This is done in the MODPOST step. modpost obtains
495 the symbols by reading Module.symvers from the kernel source
496 tree. During the MODPOST step, a new Module.symvers file will be
497 written containing all exported symbols from that external module.
498
4996.3 Symbols From Another External Module
500----------------------------------------
501
502 Sometimes, an external module uses exported symbols from
503 another external module. Kbuild needs to have full knowledge of
504 all symbols to avoid spitting out warnings about undefined
505 symbols. Two solutions exist for this situation.
506
507 NOTE: The method with a top-level kbuild file is recommended
508 but may be impractical in certain situations.
509
510 Use a top-level kbuild file
511 If you have two modules, foo.ko and bar.ko, where
512 foo.ko needs symbols from bar.ko, you can use a
513 common top-level kbuild file so both modules are
514 compiled in the same build. Consider the following
515 directory layout::
516
517 ./foo/ <= contains foo.ko
518 ./bar/ <= contains bar.ko
519
520 The top-level kbuild file would then look like::
521
522 #./Kbuild (or ./Makefile):
523 obj-m := foo/ bar/
524
525 And executing::
526
527 $ make -C $KDIR M=$PWD
528
529 will then do the expected and compile both modules with
530 full knowledge of symbols from either module.
531
532 Use "make" variable KBUILD_EXTRA_SYMBOLS
533 If it is impractical to add a top-level kbuild file,
534 you can assign a space separated list
535 of files to KBUILD_EXTRA_SYMBOLS in your build file.
536 These files will be loaded by modpost during the
537 initialization of its symbol tables.
538
539
5407. Tips & Tricks
541================
542
5437.1 Testing for CONFIG_FOO_BAR
544------------------------------
545
546 Modules often need to check for certain `CONFIG_` options to
547 decide if a specific feature is included in the module. In
548 kbuild this is done by referencing the `CONFIG_` variable
549 directly::
550
551 #fs/ext2/Makefile
552 obj-$(CONFIG_EXT2_FS) += ext2.o
553
554 ext2-y := balloc.o bitmap.o dir.o
555 ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o
556
557 External modules have traditionally used "grep" to check for
558 specific `CONFIG_` settings directly in .config. This usage is
559 broken. As introduced before, external modules should use
560 kbuild for building and can therefore use the same methods as
561 in-tree modules when testing for `CONFIG_` definitions.