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 493