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