1====================== 2Linux Kernel Makefiles 3====================== 4 5This document describes the Linux kernel Makefiles. 6 7.. Table of Contents 8 9 === 1 Overview 10 === 2 Who does what 11 === 3 The kbuild files 12 --- 3.1 Goal definitions 13 --- 3.2 Built-in object goals - obj-y 14 --- 3.3 Loadable module goals - obj-m 15 --- 3.4 Objects which export symbols 16 --- 3.5 Library file goals - lib-y 17 --- 3.6 Descending down in directories 18 --- 3.7 Compilation flags 19 --- 3.8 Command line dependency 20 --- 3.9 Dependency tracking 21 --- 3.10 Special Rules 22 --- 3.11 $(CC) support functions 23 --- 3.12 $(LD) support functions 24 25 === 4 Host Program support 26 --- 4.1 Simple Host Program 27 --- 4.2 Composite Host Programs 28 --- 4.3 Using C++ for host programs 29 --- 4.4 Controlling compiler options for host programs 30 --- 4.5 When host programs are actually built 31 32 === 5 Kbuild clean infrastructure 33 34 === 6 Architecture Makefiles 35 --- 6.1 Set variables to tweak the build to the architecture 36 --- 6.2 Add prerequisites to archheaders: 37 --- 6.3 Add prerequisites to archprepare: 38 --- 6.4 List directories to visit when descending 39 --- 6.5 Architecture-specific boot images 40 --- 6.6 Building non-kbuild targets 41 --- 6.7 Commands useful for building a boot image 42 --- 6.8 Custom kbuild commands 43 --- 6.9 Preprocessing linker scripts 44 --- 6.10 Generic header files 45 --- 6.11 Post-link pass 46 47 === 7 Kbuild syntax for exported headers 48 --- 7.1 no-export-headers 49 --- 7.2 generic-y 50 --- 7.3 generated-y 51 --- 7.4 mandatory-y 52 53 === 8 Kbuild Variables 54 === 9 Makefile language 55 === 10 Credits 56 === 11 TODO 57 581 Overview 59========== 60 61The Makefiles have five parts:: 62 63 Makefile the top Makefile. 64 .config the kernel configuration file. 65 arch/$(ARCH)/Makefile the arch Makefile. 66 scripts/Makefile.* common rules etc. for all kbuild Makefiles. 67 kbuild Makefiles there are about 500 of these. 68 69The top Makefile reads the .config file, which comes from the kernel 70configuration process. 71 72The top Makefile is responsible for building two major products: vmlinux 73(the resident kernel image) and modules (any module files). 74It builds these goals by recursively descending into the subdirectories of 75the kernel source tree. 76The list of subdirectories which are visited depends upon the kernel 77configuration. The top Makefile textually includes an arch Makefile 78with the name arch/$(ARCH)/Makefile. The arch Makefile supplies 79architecture-specific information to the top Makefile. 80 81Each subdirectory has a kbuild Makefile which carries out the commands 82passed down from above. The kbuild Makefile uses information from the 83.config file to construct various file lists used by kbuild to build 84any built-in or modular targets. 85 86scripts/Makefile.* contains all the definitions/rules etc. that 87are used to build the kernel based on the kbuild makefiles. 88 89 902 Who does what 91=============== 92 93People have four different relationships with the kernel Makefiles. 94 95*Users* are people who build kernels. These people type commands such as 96"make menuconfig" or "make". They usually do not read or edit 97any kernel Makefiles (or any other source files). 98 99*Normal developers* are people who work on features such as device 100drivers, file systems, and network protocols. These people need to 101maintain the kbuild Makefiles for the subsystem they are 102working on. In order to do this effectively, they need some overall 103knowledge about the kernel Makefiles, plus detailed knowledge about the 104public interface for kbuild. 105 106*Arch developers* are people who work on an entire architecture, such 107as sparc or ia64. Arch developers need to know about the arch Makefile 108as well as kbuild Makefiles. 109 110*Kbuild developers* are people who work on the kernel build system itself. 111These people need to know about all aspects of the kernel Makefiles. 112 113This document is aimed towards normal developers and arch developers. 114 115 1163 The kbuild files 117================== 118 119Most Makefiles within the kernel are kbuild Makefiles that use the 120kbuild infrastructure. This chapter introduces the syntax used in the 121kbuild makefiles. 122The preferred name for the kbuild files are 'Makefile' but 'Kbuild' can 123be used and if both a 'Makefile' and a 'Kbuild' file exists, then the 'Kbuild' 124file will be used. 125 126Section 3.1 "Goal definitions" is a quick intro, further chapters provide 127more details, with real examples. 128 1293.1 Goal definitions 130-------------------- 131 132 Goal definitions are the main part (heart) of the kbuild Makefile. 133 These lines define the files to be built, any special compilation 134 options, and any subdirectories to be entered recursively. 135 136 The most simple kbuild makefile contains one line: 137 138 Example:: 139 140 obj-y += foo.o 141 142 This tells kbuild that there is one object in that directory, named 143 foo.o. foo.o will be built from foo.c or foo.S. 144 145 If foo.o shall be built as a module, the variable obj-m is used. 146 Therefore the following pattern is often used: 147 148 Example:: 149 150 obj-$(CONFIG_FOO) += foo.o 151 152 $(CONFIG_FOO) evaluates to either y (for built-in) or m (for module). 153 If CONFIG_FOO is neither y nor m, then the file will not be compiled 154 nor linked. 155 1563.2 Built-in object goals - obj-y 157--------------------------------- 158 159 The kbuild Makefile specifies object files for vmlinux 160 in the $(obj-y) lists. These lists depend on the kernel 161 configuration. 162 163 Kbuild compiles all the $(obj-y) files. It then calls 164 "$(AR) rcSTP" to merge these files into one built-in.a file. 165 This is a thin archive without a symbol table. It will be later 166 linked into vmlinux by scripts/link-vmlinux.sh 167 168 The order of files in $(obj-y) is significant. Duplicates in 169 the lists are allowed: the first instance will be linked into 170 built-in.a and succeeding instances will be ignored. 171 172 Link order is significant, because certain functions 173 (module_init() / __initcall) will be called during boot in the 174 order they appear. So keep in mind that changing the link 175 order may e.g. change the order in which your SCSI 176 controllers are detected, and thus your disks are renumbered. 177 178 Example:: 179 180 #drivers/isdn/i4l/Makefile 181 # Makefile for the kernel ISDN subsystem and device drivers. 182 # Each configuration option enables a list of files. 183 obj-$(CONFIG_ISDN_I4L) += isdn.o 184 obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o 185 1863.3 Loadable module goals - obj-m 187--------------------------------- 188 189 $(obj-m) specifies object files which are built as loadable 190 kernel modules. 191 192 A module may be built from one source file or several source 193 files. In the case of one source file, the kbuild makefile 194 simply adds the file to $(obj-m). 195 196 Example:: 197 198 #drivers/isdn/i4l/Makefile 199 obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o 200 201 Note: In this example $(CONFIG_ISDN_PPP_BSDCOMP) evaluates to 'm' 202 203 If a kernel module is built from several source files, you specify 204 that you want to build a module in the same way as above; however, 205 kbuild needs to know which object files you want to build your 206 module from, so you have to tell it by setting a $(<module_name>-y) 207 variable. 208 209 Example:: 210 211 #drivers/isdn/i4l/Makefile 212 obj-$(CONFIG_ISDN_I4L) += isdn.o 213 isdn-y := isdn_net_lib.o isdn_v110.o isdn_common.o 214 215 In this example, the module name will be isdn.o. Kbuild will 216 compile the objects listed in $(isdn-y) and then run 217 "$(LD) -r" on the list of these files to generate isdn.o. 218 219 Due to kbuild recognizing $(<module_name>-y) for composite objects, 220 you can use the value of a `CONFIG_` symbol to optionally include an 221 object file as part of a composite object. 222 223 Example:: 224 225 #fs/ext2/Makefile 226 obj-$(CONFIG_EXT2_FS) += ext2.o 227 ext2-y := balloc.o dir.o file.o ialloc.o inode.o ioctl.o \ 228 namei.o super.o symlink.o 229 ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o xattr_user.o \ 230 xattr_trusted.o 231 232 In this example, xattr.o, xattr_user.o and xattr_trusted.o are only 233 part of the composite object ext2.o if $(CONFIG_EXT2_FS_XATTR) 234 evaluates to 'y'. 235 236 Note: Of course, when you are building objects into the kernel, 237 the syntax above will also work. So, if you have CONFIG_EXT2_FS=y, 238 kbuild will build an ext2.o file for you out of the individual 239 parts and then link this into built-in.a, as you would expect. 240 2413.4 Objects which export symbols 242-------------------------------- 243 244 No special notation is required in the makefiles for 245 modules exporting symbols. 246 2473.5 Library file goals - lib-y 248------------------------------ 249 250 Objects listed with obj-* are used for modules, or 251 combined in a built-in.a for that specific directory. 252 There is also the possibility to list objects that will 253 be included in a library, lib.a. 254 All objects listed with lib-y are combined in a single 255 library for that directory. 256 Objects that are listed in obj-y and additionally listed in 257 lib-y will not be included in the library, since they will 258 be accessible anyway. 259 For consistency, objects listed in lib-m will be included in lib.a. 260 261 Note that the same kbuild makefile may list files to be built-in 262 and to be part of a library. Therefore the same directory 263 may contain both a built-in.a and a lib.a file. 264 265 Example:: 266 267 #arch/x86/lib/Makefile 268 lib-y := delay.o 269 270 This will create a library lib.a based on delay.o. For kbuild to 271 actually recognize that there is a lib.a being built, the directory 272 shall be listed in libs-y. 273 274 See also "6.4 List directories to visit when descending". 275 276 Use of lib-y is normally restricted to `lib/` and `arch/*/lib`. 277 2783.6 Descending down in directories 279---------------------------------- 280 281 A Makefile is only responsible for building objects in its own 282 directory. Files in subdirectories should be taken care of by 283 Makefiles in these subdirs. The build system will automatically 284 invoke make recursively in subdirectories, provided you let it know of 285 them. 286 287 To do so, obj-y and obj-m are used. 288 ext2 lives in a separate directory, and the Makefile present in fs/ 289 tells kbuild to descend down using the following assignment. 290 291 Example:: 292 293 #fs/Makefile 294 obj-$(CONFIG_EXT2_FS) += ext2/ 295 296 If CONFIG_EXT2_FS is set to either 'y' (built-in) or 'm' (modular) 297 the corresponding obj- variable will be set, and kbuild will descend 298 down in the ext2 directory. 299 300 Kbuild uses this information not only to decide that it needs to visit 301 the directory, but also to decide whether or not to link objects from 302 the directory into vmlinux. 303 304 When Kbuild descends into the directory with 'y', all built-in objects 305 from that directory are combined into the built-in.a, which will be 306 eventually linked into vmlinux. 307 308 When Kbuild descends into the directory with 'm', in contrast, nothing 309 from that directory will be linked into vmlinux. If the Makefile in 310 that directory specifies obj-y, those objects will be left orphan. 311 It is very likely a bug of the Makefile or of dependencies in Kconfig. 312 313 It is good practice to use a `CONFIG_` variable when assigning directory 314 names. This allows kbuild to totally skip the directory if the 315 corresponding `CONFIG_` option is neither 'y' nor 'm'. 316 3173.7 Compilation flags 318--------------------- 319 320 ccflags-y, asflags-y and ldflags-y 321 These three flags apply only to the kbuild makefile in which they 322 are assigned. They are used for all the normal cc, as and ld 323 invocations happening during a recursive build. 324 Note: Flags with the same behaviour were previously named: 325 EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS. 326 They are still supported but their usage is deprecated. 327 328 ccflags-y specifies options for compiling with $(CC). 329 330 Example:: 331 332 # drivers/acpi/acpica/Makefile 333 ccflags-y := -Os -D_LINUX -DBUILDING_ACPICA 334 ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT 335 336 This variable is necessary because the top Makefile owns the 337 variable $(KBUILD_CFLAGS) and uses it for compilation flags for the 338 entire tree. 339 340 asflags-y specifies assembler options. 341 342 Example:: 343 344 #arch/sparc/kernel/Makefile 345 asflags-y := -ansi 346 347 ldflags-y specifies options for linking with $(LD). 348 349 Example:: 350 351 #arch/cris/boot/compressed/Makefile 352 ldflags-y += -T $(srctree)/$(src)/decompress_$(arch-y).lds 353 354 subdir-ccflags-y, subdir-asflags-y 355 The two flags listed above are similar to ccflags-y and asflags-y. 356 The difference is that the subdir- variants have effect for the kbuild 357 file where they are present and all subdirectories. 358 Options specified using subdir-* are added to the commandline before 359 the options specified using the non-subdir variants. 360 361 Example:: 362 363 subdir-ccflags-y := -Werror 364 365 CFLAGS_$@, AFLAGS_$@ 366 CFLAGS_$@ and AFLAGS_$@ only apply to commands in current 367 kbuild makefile. 368 369 $(CFLAGS_$@) specifies per-file options for $(CC). The $@ 370 part has a literal value which specifies the file that it is for. 371 372 Example:: 373 374 # drivers/scsi/Makefile 375 CFLAGS_aha152x.o = -DAHA152X_STAT -DAUTOCONF 376 CFLAGS_gdth.o = # -DDEBUG_GDTH=2 -D__SERIAL__ -D__COM2__ \ 377 -DGDTH_STATISTICS 378 379 These two lines specify compilation flags for aha152x.o and gdth.o. 380 381 $(AFLAGS_$@) is a similar feature for source files in assembly 382 languages. 383 384 Example:: 385 386 # arch/arm/kernel/Makefile 387 AFLAGS_head.o := -DTEXT_OFFSET=$(TEXT_OFFSET) 388 AFLAGS_crunch-bits.o := -Wa,-mcpu=ep9312 389 AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt 390 391 3923.9 Dependency tracking 393----------------------- 394 395 Kbuild tracks dependencies on the following: 396 397 1) All prerequisite files (both `*.c` and `*.h`) 398 2) `CONFIG_` options used in all prerequisite files 399 3) Command-line used to compile target 400 401 Thus, if you change an option to $(CC) all affected files will 402 be re-compiled. 403 4043.10 Special Rules 405------------------ 406 407 Special rules are used when the kbuild infrastructure does 408 not provide the required support. A typical example is 409 header files generated during the build process. 410 Another example are the architecture-specific Makefiles which 411 need special rules to prepare boot images etc. 412 413 Special rules are written as normal Make rules. 414 Kbuild is not executing in the directory where the Makefile is 415 located, so all special rules shall provide a relative 416 path to prerequisite files and target files. 417 418 Two variables are used when defining special rules: 419 420 $(src) 421 $(src) is a relative path which points to the directory 422 where the Makefile is located. Always use $(src) when 423 referring to files located in the src tree. 424 425 $(obj) 426 $(obj) is a relative path which points to the directory 427 where the target is saved. Always use $(obj) when 428 referring to generated files. 429 430 Example:: 431 432 #drivers/scsi/Makefile 433 $(obj)/53c8xx_d.h: $(src)/53c7,8xx.scr $(src)/script_asm.pl 434 $(CPP) -DCHIP=810 - < $< | ... $(src)/script_asm.pl 435 436 This is a special rule, following the normal syntax 437 required by make. 438 439 The target file depends on two prerequisite files. References 440 to the target file are prefixed with $(obj), references 441 to prerequisites are referenced with $(src) (because they are not 442 generated files). 443 444 $(kecho) 445 echoing information to user in a rule is often a good practice 446 but when execution "make -s" one does not expect to see any output 447 except for warnings/errors. 448 To support this kbuild defines $(kecho) which will echo out the 449 text following $(kecho) to stdout except if "make -s" is used. 450 451 Example:: 452 453 #arch/blackfin/boot/Makefile 454 $(obj)/vmImage: $(obj)/vmlinux.gz 455 $(call if_changed,uimage) 456 @$(kecho) 'Kernel: $@ is ready' 457 458 4593.11 $(CC) support functions 460---------------------------- 461 462 The kernel may be built with several different versions of 463 $(CC), each supporting a unique set of features and options. 464 kbuild provides basic support to check for valid options for $(CC). 465 $(CC) is usually the gcc compiler, but other alternatives are 466 available. 467 468 as-option 469 as-option is used to check if $(CC) -- when used to compile 470 assembler (`*.S`) files -- supports the given option. An optional 471 second option may be specified if the first option is not supported. 472 473 Example:: 474 475 #arch/sh/Makefile 476 cflags-y += $(call as-option,-Wa$(comma)-isa=$(isa-y),) 477 478 In the above example, cflags-y will be assigned the option 479 -Wa$(comma)-isa=$(isa-y) if it is supported by $(CC). 480 The second argument is optional, and if supplied will be used 481 if first argument is not supported. 482 483 as-instr 484 as-instr checks if the assembler reports a specific instruction 485 and then outputs either option1 or option2 486 C escapes are supported in the test instruction 487 Note: as-instr-option uses KBUILD_AFLAGS for assembler options 488 489 cc-option 490 cc-option is used to check if $(CC) supports a given option, and if 491 not supported to use an optional second option. 492 493 Example:: 494 495 #arch/x86/Makefile 496 cflags-y += $(call cc-option,-march=pentium-mmx,-march=i586) 497 498 In the above example, cflags-y will be assigned the option 499 -march=pentium-mmx if supported by $(CC), otherwise -march=i586. 500 The second argument to cc-option is optional, and if omitted, 501 cflags-y will be assigned no value if first option is not supported. 502 Note: cc-option uses KBUILD_CFLAGS for $(CC) options 503 504 cc-option-yn 505 cc-option-yn is used to check if gcc supports a given option 506 and return 'y' if supported, otherwise 'n'. 507 508 Example:: 509 510 #arch/ppc/Makefile 511 biarch := $(call cc-option-yn, -m32) 512 aflags-$(biarch) += -a32 513 cflags-$(biarch) += -m32 514 515 In the above example, $(biarch) is set to y if $(CC) supports the -m32 516 option. When $(biarch) equals 'y', the expanded variables $(aflags-y) 517 and $(cflags-y) will be assigned the values -a32 and -m32, 518 respectively. 519 Note: cc-option-yn uses KBUILD_CFLAGS for $(CC) options 520 521 cc-disable-warning 522 cc-disable-warning checks if gcc supports a given warning and returns 523 the commandline switch to disable it. This special function is needed, 524 because gcc 4.4 and later accept any unknown -Wno-* option and only 525 warn about it if there is another warning in the source file. 526 527 Example:: 528 529 KBUILD_CFLAGS += $(call cc-disable-warning, unused-but-set-variable) 530 531 In the above example, -Wno-unused-but-set-variable will be added to 532 KBUILD_CFLAGS only if gcc really accepts it. 533 534 cc-ifversion 535 cc-ifversion tests the version of $(CC) and equals the fourth parameter 536 if version expression is true, or the fifth (if given) if the version 537 expression is false. 538 539 Example:: 540 541 #fs/reiserfs/Makefile 542 ccflags-y := $(call cc-ifversion, -lt, 0402, -O1) 543 544 In this example, ccflags-y will be assigned the value -O1 if the 545 $(CC) version is less than 4.2. 546 cc-ifversion takes all the shell operators: 547 -eq, -ne, -lt, -le, -gt, and -ge 548 The third parameter may be a text as in this example, but it may also 549 be an expanded variable or a macro. 550 551 cc-cross-prefix 552 cc-cross-prefix is used to check if there exists a $(CC) in path with 553 one of the listed prefixes. The first prefix where there exist a 554 prefix$(CC) in the PATH is returned - and if no prefix$(CC) is found 555 then nothing is returned. 556 Additional prefixes are separated by a single space in the 557 call of cc-cross-prefix. 558 This functionality is useful for architecture Makefiles that try 559 to set CROSS_COMPILE to well-known values but may have several 560 values to select between. 561 It is recommended only to try to set CROSS_COMPILE if it is a cross 562 build (host arch is different from target arch). And if CROSS_COMPILE 563 is already set then leave it with the old value. 564 565 Example:: 566 567 #arch/m68k/Makefile 568 ifneq ($(SUBARCH),$(ARCH)) 569 ifeq ($(CROSS_COMPILE),) 570 CROSS_COMPILE := $(call cc-cross-prefix, m68k-linux-gnu-) 571 endif 572 endif 573 5743.12 $(LD) support functions 575---------------------------- 576 577 ld-option 578 ld-option is used to check if $(LD) supports the supplied option. 579 ld-option takes two options as arguments. 580 The second argument is an optional option that can be used if the 581 first option is not supported by $(LD). 582 583 Example:: 584 585 #Makefile 586 LDFLAGS_vmlinux += $(call ld-option, -X) 587 588 5894 Host Program support 590====================== 591 592Kbuild supports building executables on the host for use during the 593compilation stage. 594Two steps are required in order to use a host executable. 595 596The first step is to tell kbuild that a host program exists. This is 597done utilising the variable "hostprogs". 598 599The second step is to add an explicit dependency to the executable. 600This can be done in two ways. Either add the dependency in a rule, 601or utilise the variable "always-y". 602Both possibilities are described in the following. 603 6044.1 Simple Host Program 605----------------------- 606 607 In some cases there is a need to compile and run a program on the 608 computer where the build is running. 609 The following line tells kbuild that the program bin2hex shall be 610 built on the build host. 611 612 Example:: 613 614 hostprogs := bin2hex 615 616 Kbuild assumes in the above example that bin2hex is made from a single 617 c-source file named bin2hex.c located in the same directory as 618 the Makefile. 619 6204.2 Composite Host Programs 621--------------------------- 622 623 Host programs can be made up based on composite objects. 624 The syntax used to define composite objects for host programs is 625 similar to the syntax used for kernel objects. 626 $(<executable>-objs) lists all objects used to link the final 627 executable. 628 629 Example:: 630 631 #scripts/lxdialog/Makefile 632 hostprogs := lxdialog 633 lxdialog-objs := checklist.o lxdialog.o 634 635 Objects with extension .o are compiled from the corresponding .c 636 files. In the above example, checklist.c is compiled to checklist.o 637 and lxdialog.c is compiled to lxdialog.o. 638 639 Finally, the two .o files are linked to the executable, lxdialog. 640 Note: The syntax <executable>-y is not permitted for host-programs. 641 6424.3 Using C++ for host programs 643------------------------------- 644 645 kbuild offers support for host programs written in C++. This was 646 introduced solely to support kconfig, and is not recommended 647 for general use. 648 649 Example:: 650 651 #scripts/kconfig/Makefile 652 hostprogs := qconf 653 qconf-cxxobjs := qconf.o 654 655 In the example above the executable is composed of the C++ file 656 qconf.cc - identified by $(qconf-cxxobjs). 657 658 If qconf is composed of a mixture of .c and .cc files, then an 659 additional line can be used to identify this. 660 661 Example:: 662 663 #scripts/kconfig/Makefile 664 hostprogs := qconf 665 qconf-cxxobjs := qconf.o 666 qconf-objs := check.o 667 6684.4 Controlling compiler options for host programs 669-------------------------------------------------- 670 671 When compiling host programs, it is possible to set specific flags. 672 The programs will always be compiled utilising $(HOSTCC) passed 673 the options specified in $(KBUILD_HOSTCFLAGS). 674 To set flags that will take effect for all host programs created 675 in that Makefile, use the variable HOST_EXTRACFLAGS. 676 677 Example:: 678 679 #scripts/lxdialog/Makefile 680 HOST_EXTRACFLAGS += -I/usr/include/ncurses 681 682 To set specific flags for a single file the following construction 683 is used: 684 685 Example:: 686 687 #arch/ppc64/boot/Makefile 688 HOSTCFLAGS_piggyback.o := -DKERNELBASE=$(KERNELBASE) 689 690 It is also possible to specify additional options to the linker. 691 692 Example:: 693 694 #scripts/kconfig/Makefile 695 HOSTLDLIBS_qconf := -L$(QTDIR)/lib 696 697 When linking qconf, it will be passed the extra option 698 "-L$(QTDIR)/lib". 699 7004.5 When host programs are actually built 701----------------------------------------- 702 703 Kbuild will only build host-programs when they are referenced 704 as a prerequisite. 705 This is possible in two ways: 706 707 (1) List the prerequisite explicitly in a special rule. 708 709 Example:: 710 711 #drivers/pci/Makefile 712 hostprogs := gen-devlist 713 $(obj)/devlist.h: $(src)/pci.ids $(obj)/gen-devlist 714 ( cd $(obj); ./gen-devlist ) < $< 715 716 The target $(obj)/devlist.h will not be built before 717 $(obj)/gen-devlist is updated. Note that references to 718 the host programs in special rules must be prefixed with $(obj). 719 720 (2) Use always-y 721 722 When there is no suitable special rule, and the host program 723 shall be built when a makefile is entered, the always-y 724 variable shall be used. 725 726 Example:: 727 728 #scripts/lxdialog/Makefile 729 hostprogs := lxdialog 730 always-y := $(hostprogs) 731 732 This will tell kbuild to build lxdialog even if not referenced in 733 any rule. 734 7355 Kbuild clean infrastructure 736============================= 737 738"make clean" deletes most generated files in the obj tree where the kernel 739is compiled. This includes generated files such as host programs. 740Kbuild knows targets listed in $(hostprogs), $(always-y), $(always-m), 741$(always-), $(extra-y), $(extra-) and $(targets). They are all deleted 742during "make clean". Files matching the patterns "*.[oas]", "*.ko", plus 743some additional files generated by kbuild are deleted all over the kernel 744source tree when "make clean" is executed. 745 746Additional files or directories can be specified in kbuild makefiles by use of 747$(clean-files). 748 749 Example:: 750 751 #lib/Makefile 752 clean-files := crc32table.h 753 754When executing "make clean", the file "crc32table.h" will be deleted. 755Kbuild will assume files to be in the same relative directory as the 756Makefile, except if prefixed with $(objtree). 757 758To exclude certain files or directories from make clean, use the 759$(no-clean-files) variable. 760 761Usually kbuild descends down in subdirectories due to "obj-* := dir/", 762but in the architecture makefiles where the kbuild infrastructure 763is not sufficient this sometimes needs to be explicit. 764 765 Example:: 766 767 #arch/x86/boot/Makefile 768 subdir- := compressed 769 770The above assignment instructs kbuild to descend down in the 771directory compressed/ when "make clean" is executed. 772 773To support the clean infrastructure in the Makefiles that build the 774final bootimage there is an optional target named archclean: 775 776 Example:: 777 778 #arch/x86/Makefile 779 archclean: 780 $(Q)$(MAKE) $(clean)=arch/x86/boot 781 782When "make clean" is executed, make will descend down in arch/x86/boot, 783and clean as usual. The Makefile located in arch/x86/boot/ may use 784the subdir- trick to descend further down. 785 786Note 1: arch/$(ARCH)/Makefile cannot use "subdir-", because that file is 787included in the top level makefile, and the kbuild infrastructure 788is not operational at that point. 789 790Note 2: All directories listed in core-y, libs-y, drivers-y and net-y will 791be visited during "make clean". 792 7936 Architecture Makefiles 794======================== 795 796The top level Makefile sets up the environment and does the preparation, 797before starting to descend down in the individual directories. 798The top level makefile contains the generic part, whereas 799arch/$(ARCH)/Makefile contains what is required to set up kbuild 800for said architecture. 801To do so, arch/$(ARCH)/Makefile sets up a number of variables and defines 802a few targets. 803 804When kbuild executes, the following steps are followed (roughly): 805 8061) Configuration of the kernel => produce .config 8072) Store kernel version in include/linux/version.h 8083) Updating all other prerequisites to the target prepare: 809 - Additional prerequisites are specified in arch/$(ARCH)/Makefile 8104) Recursively descend down in all directories listed in 811 init-* core* drivers-* net-* libs-* and build all targets. 812 - The values of the above variables are expanded in arch/$(ARCH)/Makefile. 8135) All object files are then linked and the resulting file vmlinux is 814 located at the root of the obj tree. 815 The very first objects linked are listed in head-y, assigned by 816 arch/$(ARCH)/Makefile. 8176) Finally, the architecture-specific part does any required post processing 818 and builds the final bootimage. 819 - This includes building boot records 820 - Preparing initrd images and the like 821 822 8236.1 Set variables to tweak the build to the architecture 824-------------------------------------------------------- 825 826 LDFLAGS 827 Generic $(LD) options 828 829 Flags used for all invocations of the linker. 830 Often specifying the emulation is sufficient. 831 832 Example:: 833 834 #arch/s390/Makefile 835 LDFLAGS := -m elf_s390 836 837 Note: ldflags-y can be used to further customise 838 the flags used. See chapter 3.7. 839 840 LDFLAGS_vmlinux 841 Options for $(LD) when linking vmlinux 842 843 LDFLAGS_vmlinux is used to specify additional flags to pass to 844 the linker when linking the final vmlinux image. 845 LDFLAGS_vmlinux uses the LDFLAGS_$@ support. 846 847 Example:: 848 849 #arch/x86/Makefile 850 LDFLAGS_vmlinux := -e stext 851 852 OBJCOPYFLAGS 853 objcopy flags 854 855 When $(call if_changed,objcopy) is used to translate a .o file, 856 the flags specified in OBJCOPYFLAGS will be used. 857 $(call if_changed,objcopy) is often used to generate raw binaries on 858 vmlinux. 859 860 Example:: 861 862 #arch/s390/Makefile 863 OBJCOPYFLAGS := -O binary 864 865 #arch/s390/boot/Makefile 866 $(obj)/image: vmlinux FORCE 867 $(call if_changed,objcopy) 868 869 In this example, the binary $(obj)/image is a binary version of 870 vmlinux. The usage of $(call if_changed,xxx) will be described later. 871 872 KBUILD_AFLAGS 873 Assembler flags 874 875 Default value - see top level Makefile 876 Append or modify as required per architecture. 877 878 Example:: 879 880 #arch/sparc64/Makefile 881 KBUILD_AFLAGS += -m64 -mcpu=ultrasparc 882 883 KBUILD_CFLAGS 884 $(CC) compiler flags 885 886 Default value - see top level Makefile 887 Append or modify as required per architecture. 888 889 Often, the KBUILD_CFLAGS variable depends on the configuration. 890 891 Example:: 892 893 #arch/x86/boot/compressed/Makefile 894 cflags-$(CONFIG_X86_32) := -march=i386 895 cflags-$(CONFIG_X86_64) := -mcmodel=small 896 KBUILD_CFLAGS += $(cflags-y) 897 898 Many arch Makefiles dynamically run the target C compiler to 899 probe supported options:: 900 901 #arch/x86/Makefile 902 903 ... 904 cflags-$(CONFIG_MPENTIUMII) += $(call cc-option,\ 905 -march=pentium2,-march=i686) 906 ... 907 # Disable unit-at-a-time mode ... 908 KBUILD_CFLAGS += $(call cc-option,-fno-unit-at-a-time) 909 ... 910 911 912 The first example utilises the trick that a config option expands 913 to 'y' when selected. 914 915 KBUILD_AFLAGS_KERNEL 916 Assembler options specific for built-in 917 918 $(KBUILD_AFLAGS_KERNEL) contains extra C compiler flags used to compile 919 resident kernel code. 920 921 KBUILD_AFLAGS_MODULE 922 Assembler options specific for modules 923 924 $(KBUILD_AFLAGS_MODULE) is used to add arch-specific options that 925 are used for assembler. 926 927 From commandline AFLAGS_MODULE shall be used (see kbuild.rst). 928 929 KBUILD_CFLAGS_KERNEL 930 $(CC) options specific for built-in 931 932 $(KBUILD_CFLAGS_KERNEL) contains extra C compiler flags used to compile 933 resident kernel code. 934 935 KBUILD_CFLAGS_MODULE 936 Options for $(CC) when building modules 937 938 $(KBUILD_CFLAGS_MODULE) is used to add arch-specific options that 939 are used for $(CC). 940 From commandline CFLAGS_MODULE shall be used (see kbuild.rst). 941 942 KBUILD_LDFLAGS_MODULE 943 Options for $(LD) when linking modules 944 945 $(KBUILD_LDFLAGS_MODULE) is used to add arch-specific options 946 used when linking modules. This is often a linker script. 947 948 From commandline LDFLAGS_MODULE shall be used (see kbuild.rst). 949 950 KBUILD_LDS 951 952 The linker script with full path. Assigned by the top-level Makefile. 953 954 KBUILD_LDS_MODULE 955 956 The module linker script with full path. Assigned by the top-level 957 Makefile and additionally by the arch Makefile. 958 959 KBUILD_VMLINUX_OBJS 960 961 All object files for vmlinux. They are linked to vmlinux in the same 962 order as listed in KBUILD_VMLINUX_OBJS. 963 964 KBUILD_VMLINUX_LIBS 965 966 All .a "lib" files for vmlinux. KBUILD_VMLINUX_OBJS and 967 KBUILD_VMLINUX_LIBS together specify all the object files used to 968 link vmlinux. 969 9706.2 Add prerequisites to archheaders 971------------------------------------ 972 973 The archheaders: rule is used to generate header files that 974 may be installed into user space by "make header_install". 975 976 It is run before "make archprepare" when run on the 977 architecture itself. 978 979 9806.3 Add prerequisites to archprepare 981------------------------------------ 982 983 The archprepare: rule is used to list prerequisites that need to be 984 built before starting to descend down in the subdirectories. 985 This is usually used for header files containing assembler constants. 986 987 Example:: 988 989 #arch/arm/Makefile 990 archprepare: maketools 991 992 In this example, the file target maketools will be processed 993 before descending down in the subdirectories. 994 See also chapter XXX-TODO that describe how kbuild supports 995 generating offset header files. 996 997 9986.4 List directories to visit when descending 999--------------------------------------------- 1000 1001 An arch Makefile cooperates with the top Makefile to define variables 1002 which specify how to build the vmlinux file. Note that there is no 1003 corresponding arch-specific section for modules; the module-building 1004 machinery is all architecture-independent. 1005 1006 1007 head-y, init-y, core-y, libs-y, drivers-y, net-y 1008 $(head-y) lists objects to be linked first in vmlinux. 1009 1010 $(libs-y) lists directories where a lib.a archive can be located. 1011 1012 The rest list directories where a built-in.a object file can be 1013 located. 1014 1015 $(init-y) objects will be located after $(head-y). 1016 1017 Then the rest follows in this order: 1018 1019 $(core-y), $(libs-y), $(drivers-y) and $(net-y). 1020 1021 The top level Makefile defines values for all generic directories, 1022 and arch/$(ARCH)/Makefile only adds architecture-specific 1023 directories. 1024 1025 Example:: 1026 1027 #arch/sparc64/Makefile 1028 core-y += arch/sparc64/kernel/ 1029 libs-y += arch/sparc64/prom/ arch/sparc64/lib/ 1030 drivers-$(CONFIG_OPROFILE) += arch/sparc64/oprofile/ 1031 1032 10336.5 Architecture-specific boot images 1034------------------------------------- 1035 1036 An arch Makefile specifies goals that take the vmlinux file, compress 1037 it, wrap it in bootstrapping code, and copy the resulting files 1038 somewhere. This includes various kinds of installation commands. 1039 The actual goals are not standardized across architectures. 1040 1041 It is common to locate any additional processing in a boot/ 1042 directory below arch/$(ARCH)/. 1043 1044 Kbuild does not provide any smart way to support building a 1045 target specified in boot/. Therefore arch/$(ARCH)/Makefile shall 1046 call make manually to build a target in boot/. 1047 1048 The recommended approach is to include shortcuts in 1049 arch/$(ARCH)/Makefile, and use the full path when calling down 1050 into the arch/$(ARCH)/boot/Makefile. 1051 1052 Example:: 1053 1054 #arch/x86/Makefile 1055 boot := arch/x86/boot 1056 bzImage: vmlinux 1057 $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ 1058 1059 "$(Q)$(MAKE) $(build)=<dir>" is the recommended way to invoke 1060 make in a subdirectory. 1061 1062 There are no rules for naming architecture-specific targets, 1063 but executing "make help" will list all relevant targets. 1064 To support this, $(archhelp) must be defined. 1065 1066 Example:: 1067 1068 #arch/x86/Makefile 1069 define archhelp 1070 echo '* bzImage - Image (arch/$(ARCH)/boot/bzImage)' 1071 endif 1072 1073 When make is executed without arguments, the first goal encountered 1074 will be built. In the top level Makefile the first goal present 1075 is all:. 1076 An architecture shall always, per default, build a bootable image. 1077 In "make help", the default goal is highlighted with a '*'. 1078 Add a new prerequisite to all: to select a default goal different 1079 from vmlinux. 1080 1081 Example:: 1082 1083 #arch/x86/Makefile 1084 all: bzImage 1085 1086 When "make" is executed without arguments, bzImage will be built. 1087 10886.6 Building non-kbuild targets 1089------------------------------- 1090 1091 extra-y 1092 extra-y specifies additional targets created in the current 1093 directory, in addition to any targets specified by `obj-*`. 1094 1095 Listing all targets in extra-y is required for two purposes: 1096 1097 1) Enable kbuild to check changes in command lines 1098 1099 - When $(call if_changed,xxx) is used 1100 1101 2) kbuild knows what files to delete during "make clean" 1102 1103 Example:: 1104 1105 #arch/x86/kernel/Makefile 1106 extra-y := head.o init_task.o 1107 1108 In this example, extra-y is used to list object files that 1109 shall be built, but shall not be linked as part of built-in.a. 1110 11116.7 Commands useful for building a boot image 1112--------------------------------------------- 1113 1114 Kbuild provides a few macros that are useful when building a 1115 boot image. 1116 1117 if_changed 1118 if_changed is the infrastructure used for the following commands. 1119 1120 Usage:: 1121 1122 target: source(s) FORCE 1123 $(call if_changed,ld/objcopy/gzip/...) 1124 1125 When the rule is evaluated, it is checked to see if any files 1126 need an update, or the command line has changed since the last 1127 invocation. The latter will force a rebuild if any options 1128 to the executable have changed. 1129 Any target that utilises if_changed must be listed in $(targets), 1130 otherwise the command line check will fail, and the target will 1131 always be built. 1132 Assignments to $(targets) are without $(obj)/ prefix. 1133 if_changed may be used in conjunction with custom commands as 1134 defined in 6.8 "Custom kbuild commands". 1135 1136 Note: It is a typical mistake to forget the FORCE prerequisite. 1137 Another common pitfall is that whitespace is sometimes 1138 significant; for instance, the below will fail (note the extra space 1139 after the comma):: 1140 1141 target: source(s) FORCE 1142 1143 **WRONG!** $(call if_changed, ld/objcopy/gzip/...) 1144 1145 Note: 1146 if_changed should not be used more than once per target. 1147 It stores the executed command in a corresponding .cmd 1148 1149 file and multiple calls would result in overwrites and 1150 unwanted results when the target is up to date and only the 1151 tests on changed commands trigger execution of commands. 1152 1153 ld 1154 Link target. Often, LDFLAGS_$@ is used to set specific options to ld. 1155 1156 Example:: 1157 1158 #arch/x86/boot/Makefile 1159 LDFLAGS_bootsect := -Ttext 0x0 -s --oformat binary 1160 LDFLAGS_setup := -Ttext 0x0 -s --oformat binary -e begtext 1161 1162 targets += setup setup.o bootsect bootsect.o 1163 $(obj)/setup $(obj)/bootsect: %: %.o FORCE 1164 $(call if_changed,ld) 1165 1166 In this example, there are two possible targets, requiring different 1167 options to the linker. The linker options are specified using the 1168 LDFLAGS_$@ syntax - one for each potential target. 1169 $(targets) are assigned all potential targets, by which kbuild knows 1170 the targets and will: 1171 1172 1) check for commandline changes 1173 2) delete target during make clean 1174 1175 The ": %: %.o" part of the prerequisite is a shorthand that 1176 frees us from listing the setup.o and bootsect.o files. 1177 1178 Note: 1179 It is a common mistake to forget the "targets :=" assignment, 1180 resulting in the target file being recompiled for no 1181 obvious reason. 1182 1183 objcopy 1184 Copy binary. Uses OBJCOPYFLAGS usually specified in 1185 arch/$(ARCH)/Makefile. 1186 OBJCOPYFLAGS_$@ may be used to set additional options. 1187 1188 gzip 1189 Compress target. Use maximum compression to compress target. 1190 1191 Example:: 1192 1193 #arch/x86/boot/compressed/Makefile 1194 $(obj)/vmlinux.bin.gz: $(vmlinux.bin.all-y) FORCE 1195 $(call if_changed,gzip) 1196 1197 dtc 1198 Create flattened device tree blob object suitable for linking 1199 into vmlinux. Device tree blobs linked into vmlinux are placed 1200 in an init section in the image. Platform code *must* copy the 1201 blob to non-init memory prior to calling unflatten_device_tree(). 1202 1203 To use this command, simply add `*.dtb` into obj-y or targets, or make 1204 some other target depend on `%.dtb` 1205 1206 A central rule exists to create `$(obj)/%.dtb` from `$(src)/%.dts`; 1207 architecture Makefiles do no need to explicitly write out that rule. 1208 1209 Example:: 1210 1211 targets += $(dtb-y) 1212 DTC_FLAGS ?= -p 1024 1213 12146.8 Custom kbuild commands 1215-------------------------- 1216 1217 When kbuild is executing with KBUILD_VERBOSE=0, then only a shorthand 1218 of a command is normally displayed. 1219 To enable this behaviour for custom commands kbuild requires 1220 two variables to be set:: 1221 1222 quiet_cmd_<command> - what shall be echoed 1223 cmd_<command> - the command to execute 1224 1225 Example:: 1226 1227 # 1228 quiet_cmd_image = BUILD $@ 1229 cmd_image = $(obj)/tools/build $(BUILDFLAGS) \ 1230 $(obj)/vmlinux.bin > $@ 1231 1232 targets += bzImage 1233 $(obj)/bzImage: $(obj)/vmlinux.bin $(obj)/tools/build FORCE 1234 $(call if_changed,image) 1235 @echo 'Kernel: $@ is ready' 1236 1237 When updating the $(obj)/bzImage target, the line: 1238 1239 BUILD arch/x86/boot/bzImage 1240 1241 will be displayed with "make KBUILD_VERBOSE=0". 1242 1243 12446.9 Preprocessing linker scripts 1245-------------------------------- 1246 1247 When the vmlinux image is built, the linker script 1248 arch/$(ARCH)/kernel/vmlinux.lds is used. 1249 The script is a preprocessed variant of the file vmlinux.lds.S 1250 located in the same directory. 1251 kbuild knows .lds files and includes a rule `*lds.S` -> `*lds`. 1252 1253 Example:: 1254 1255 #arch/x86/kernel/Makefile 1256 extra-y := vmlinux.lds 1257 1258 #Makefile 1259 export CPPFLAGS_vmlinux.lds += -P -C -U$(ARCH) 1260 1261 The assignment to extra-y is used to tell kbuild to build the 1262 target vmlinux.lds. 1263 The assignment to $(CPPFLAGS_vmlinux.lds) tells kbuild to use the 1264 specified options when building the target vmlinux.lds. 1265 1266 When building the `*.lds` target, kbuild uses the variables:: 1267 1268 KBUILD_CPPFLAGS : Set in top-level Makefile 1269 cppflags-y : May be set in the kbuild makefile 1270 CPPFLAGS_$(@F) : Target-specific flags. 1271 Note that the full filename is used in this 1272 assignment. 1273 1274 The kbuild infrastructure for `*lds` files is used in several 1275 architecture-specific files. 1276 12776.10 Generic header files 1278------------------------- 1279 1280 The directory include/asm-generic contains the header files 1281 that may be shared between individual architectures. 1282 The recommended approach how to use a generic header file is 1283 to list the file in the Kbuild file. 1284 See "7.2 generic-y" for further info on syntax etc. 1285 12866.11 Post-link pass 1287------------------- 1288 1289 If the file arch/xxx/Makefile.postlink exists, this makefile 1290 will be invoked for post-link objects (vmlinux and modules.ko) 1291 for architectures to run post-link passes on. Must also handle 1292 the clean target. 1293 1294 This pass runs after kallsyms generation. If the architecture 1295 needs to modify symbol locations, rather than manipulate the 1296 kallsyms, it may be easier to add another postlink target for 1297 .tmp_vmlinux? targets to be called from link-vmlinux.sh. 1298 1299 For example, powerpc uses this to check relocation sanity of 1300 the linked vmlinux file. 1301 13027 Kbuild syntax for exported headers 1303------------------------------------ 1304 1305The kernel includes a set of headers that is exported to userspace. 1306Many headers can be exported as-is but other headers require a 1307minimal pre-processing before they are ready for user-space. 1308The pre-processing does: 1309 1310- drop kernel-specific annotations 1311- drop include of compiler.h 1312- drop all sections that are kernel internal (guarded by `ifdef __KERNEL__`) 1313 1314All headers under include/uapi/, include/generated/uapi/, 1315arch/<arch>/include/uapi/ and arch/<arch>/include/generated/uapi/ 1316are exported. 1317 1318A Kbuild file may be defined under arch/<arch>/include/uapi/asm/ and 1319arch/<arch>/include/asm/ to list asm files coming from asm-generic. 1320See subsequent chapter for the syntax of the Kbuild file. 1321 13227.1 no-export-headers 1323--------------------- 1324 1325 no-export-headers is essentially used by include/uapi/linux/Kbuild to 1326 avoid exporting specific headers (e.g. kvm.h) on architectures that do 1327 not support it. It should be avoided as much as possible. 1328 13297.2 generic-y 1330------------- 1331 1332 If an architecture uses a verbatim copy of a header from 1333 include/asm-generic then this is listed in the file 1334 arch/$(ARCH)/include/asm/Kbuild like this: 1335 1336 Example:: 1337 1338 #arch/x86/include/asm/Kbuild 1339 generic-y += termios.h 1340 generic-y += rtc.h 1341 1342 During the prepare phase of the build a wrapper include 1343 file is generated in the directory:: 1344 1345 arch/$(ARCH)/include/generated/asm 1346 1347 When a header is exported where the architecture uses 1348 the generic header a similar wrapper is generated as part 1349 of the set of exported headers in the directory:: 1350 1351 usr/include/asm 1352 1353 The generated wrapper will in both cases look like the following: 1354 1355 Example: termios.h:: 1356 1357 #include <asm-generic/termios.h> 1358 13597.3 generated-y 1360--------------- 1361 1362 If an architecture generates other header files alongside generic-y 1363 wrappers, generated-y specifies them. 1364 1365 This prevents them being treated as stale asm-generic wrappers and 1366 removed. 1367 1368 Example:: 1369 1370 #arch/x86/include/asm/Kbuild 1371 generated-y += syscalls_32.h 1372 13737.4 mandatory-y 1374--------------- 1375 1376 mandatory-y is essentially used by include/(uapi/)asm-generic/Kbuild 1377 to define the minimum set of ASM headers that all architectures must have. 1378 1379 This works like optional generic-y. If a mandatory header is missing 1380 in arch/$(ARCH)/include/(uapi/)/asm, Kbuild will automatically generate 1381 a wrapper of the asm-generic one. 1382 13838 Kbuild Variables 1384================== 1385 1386The top Makefile exports the following variables: 1387 1388 VERSION, PATCHLEVEL, SUBLEVEL, EXTRAVERSION 1389 These variables define the current kernel version. A few arch 1390 Makefiles actually use these values directly; they should use 1391 $(KERNELRELEASE) instead. 1392 1393 $(VERSION), $(PATCHLEVEL), and $(SUBLEVEL) define the basic 1394 three-part version number, such as "2", "4", and "0". These three 1395 values are always numeric. 1396 1397 $(EXTRAVERSION) defines an even tinier sublevel for pre-patches 1398 or additional patches. It is usually some non-numeric string 1399 such as "-pre4", and is often blank. 1400 1401 KERNELRELEASE 1402 $(KERNELRELEASE) is a single string such as "2.4.0-pre4", suitable 1403 for constructing installation directory names or showing in 1404 version strings. Some arch Makefiles use it for this purpose. 1405 1406 ARCH 1407 This variable defines the target architecture, such as "i386", 1408 "arm", or "sparc". Some kbuild Makefiles test $(ARCH) to 1409 determine which files to compile. 1410 1411 By default, the top Makefile sets $(ARCH) to be the same as the 1412 host system architecture. For a cross build, a user may 1413 override the value of $(ARCH) on the command line:: 1414 1415 make ARCH=m68k ... 1416 1417 1418 INSTALL_PATH 1419 This variable defines a place for the arch Makefiles to install 1420 the resident kernel image and System.map file. 1421 Use this for architecture-specific install targets. 1422 1423 INSTALL_MOD_PATH, MODLIB 1424 $(INSTALL_MOD_PATH) specifies a prefix to $(MODLIB) for module 1425 installation. This variable is not defined in the Makefile but 1426 may be passed in by the user if desired. 1427 1428 $(MODLIB) specifies the directory for module installation. 1429 The top Makefile defines $(MODLIB) to 1430 $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE). The user may 1431 override this value on the command line if desired. 1432 1433 INSTALL_MOD_STRIP 1434 If this variable is specified, it will cause modules to be stripped 1435 after they are installed. If INSTALL_MOD_STRIP is '1', then the 1436 default option --strip-debug will be used. Otherwise, the 1437 INSTALL_MOD_STRIP value will be used as the option(s) to the strip 1438 command. 1439 1440 14419 Makefile language 1442=================== 1443 1444The kernel Makefiles are designed to be run with GNU Make. The Makefiles 1445use only the documented features of GNU Make, but they do use many 1446GNU extensions. 1447 1448GNU Make supports elementary list-processing functions. The kernel 1449Makefiles use a novel style of list building and manipulation with few 1450"if" statements. 1451 1452GNU Make has two assignment operators, ":=" and "=". ":=" performs 1453immediate evaluation of the right-hand side and stores an actual string 1454into the left-hand side. "=" is like a formula definition; it stores the 1455right-hand side in an unevaluated form and then evaluates this form each 1456time the left-hand side is used. 1457 1458There are some cases where "=" is appropriate. Usually, though, ":=" 1459is the right choice. 1460 146110 Credits 1462========== 1463 1464- Original version made by Michael Elizabeth Chastain, <mailto:mec@shout.net> 1465- Updates by Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de> 1466- Updates by Sam Ravnborg <sam@ravnborg.org> 1467- Language QA by Jan Engelhardt <jengelh@gmx.de> 1468 146911 TODO 1470======= 1471 1472- Describe how kbuild supports shipped files with _shipped. 1473- Generating offset header files. 1474- Add more variables to section 7? 1475