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