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