aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@g5.osdl.org>2006-09-24 17:24:14 -0400
committerLinus Torvalds <torvalds@g5.osdl.org>2006-09-24 17:24:14 -0400
commit6e936d3e9a45a4307e7f4a29ee9829e7a0464af1 (patch)
tree555f9d89779e6a675b38d9703f278ecf0579531c /Documentation
parenta68aa1cc6f3203b8a332683ebde67a00f39eec43 (diff)
parent5cc8d246d0ebbdf827d4bb7c3de175377d244d73 (diff)
Merge git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild
* git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild: (28 commits) kbuild: add distclean info to 'make help' and more details for 'clean' dontdiff: add utsrelease.h kbuild: fix "mkdir -p" usage in scripts/package/mkspec kbuild: correct and clarify versioning info in Makefile kbuild: fixup Documentation/kbuild/modules.txt kbuild: Extend kbuild/defconfig tags support to exuberant ctags kbuild: fix for some typos in Documentation/makefiles.txt kbuild: clarify "make C=" build option Documentaion: update Documentation/Changes with minimum versions kbuild: update help in top level Makefile kbuild: fail kernel compilation in case of unresolved module symbols kbuild: remove debug left-over from Makefile.host kbuild: create output directory for hostprogs with O=.. build kbuild: add missing return statement in modpost.c:secref_whitelist() kbuild: preperly align SYSMAP output kbuild: make -rR is now default kbuild: make V=2 tell why a target is rebuild kbuild: modpost on vmlinux regardless of CONFIG_MODULES kbuild: ignore references from ".pci_fixup" to ".init.text" kbuild: linguistic fixes for Documentation/kbuild/makefiles.txt ...
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/Changes7
-rw-r--r--Documentation/dontdiff1
-rw-r--r--Documentation/kbuild/kconfig-language.txt12
-rw-r--r--Documentation/kbuild/makefiles.txt265
-rw-r--r--Documentation/kbuild/modules.txt161
-rw-r--r--Documentation/sparse.txt8
6 files changed, 231 insertions, 223 deletions
diff --git a/Documentation/Changes b/Documentation/Changes
index 488272074c36..abee7f58c1ed 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@ -37,15 +37,14 @@ o e2fsprogs 1.29 # tune2fs
37o jfsutils 1.1.3 # fsck.jfs -V 37o jfsutils 1.1.3 # fsck.jfs -V
38o reiserfsprogs 3.6.3 # reiserfsck -V 2>&1|grep reiserfsprogs 38o reiserfsprogs 3.6.3 # reiserfsck -V 2>&1|grep reiserfsprogs
39o xfsprogs 2.6.0 # xfs_db -V 39o xfsprogs 2.6.0 # xfs_db -V
40o pcmciautils 004 40o pcmciautils 004 # pccardctl -V
41o pcmcia-cs 3.1.21 # cardmgr -V
42o quota-tools 3.09 # quota -V 41o quota-tools 3.09 # quota -V
43o PPP 2.4.0 # pppd --version 42o PPP 2.4.0 # pppd --version
44o isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version 43o isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version
45o nfs-utils 1.0.5 # showmount --version 44o nfs-utils 1.0.5 # showmount --version
46o procps 3.2.0 # ps --version 45o procps 3.2.0 # ps --version
47o oprofile 0.9 # oprofiled --version 46o oprofile 0.9 # oprofiled --version
48o udev 071 # udevinfo -V 47o udev 081 # udevinfo -V
49 48
50Kernel compilation 49Kernel compilation
51================== 50==================
@@ -268,7 +267,7 @@ active clients.
268 267
269To enable this new functionality, you need to: 268To enable this new functionality, you need to:
270 269
271 mount -t nfsd nfsd /proc/fs/nfs 270 mount -t nfsd nfsd /proc/fs/nfsd
272 271
273before running exportfs or mountd. It is recommended that all NFS 272before running exportfs or mountd. It is recommended that all NFS
274services be protected from the internet-at-large by a firewall where 273services be protected from the internet-at-large by a firewall where
diff --git a/Documentation/dontdiff b/Documentation/dontdiff
index 24adfe9af3ca..63c2d0c55aa2 100644
--- a/Documentation/dontdiff
+++ b/Documentation/dontdiff
@@ -135,6 +135,7 @@ tags
135times.h* 135times.h*
136tkparse 136tkparse
137trix_boot.h 137trix_boot.h
138utsrelease.h*
138version.h* 139version.h*
139vmlinux 140vmlinux
140vmlinux-* 141vmlinux-*
diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt
index ca1967f36423..003fccc14d24 100644
--- a/Documentation/kbuild/kconfig-language.txt
+++ b/Documentation/kbuild/kconfig-language.txt
@@ -67,19 +67,19 @@ applicable everywhere (see syntax).
67- default value: "default" <expr> ["if" <expr>] 67- default value: "default" <expr> ["if" <expr>]
68 A config option can have any number of default values. If multiple 68 A config option can have any number of default values. If multiple
69 default values are visible, only the first defined one is active. 69 default values are visible, only the first defined one is active.
70 Default values are not limited to the menu entry, where they are 70 Default values are not limited to the menu entry where they are
71 defined, this means the default can be defined somewhere else or be 71 defined. This means the default can be defined somewhere else or be
72 overridden by an earlier definition. 72 overridden by an earlier definition.
73 The default value is only assigned to the config symbol if no other 73 The default value is only assigned to the config symbol if no other
74 value was set by the user (via the input prompt above). If an input 74 value was set by the user (via the input prompt above). If an input
75 prompt is visible the default value is presented to the user and can 75 prompt is visible the default value is presented to the user and can
76 be overridden by him. 76 be overridden by him.
77 Optionally dependencies only for this default value can be added with 77 Optionally, dependencies only for this default value can be added with
78 "if". 78 "if".
79 79
80- dependencies: "depends on"/"requires" <expr> 80- dependencies: "depends on"/"requires" <expr>
81 This defines a dependency for this menu entry. If multiple 81 This defines a dependency for this menu entry. If multiple
82 dependencies are defined they are connected with '&&'. Dependencies 82 dependencies are defined, they are connected with '&&'. Dependencies
83 are applied to all other options within this menu entry (which also 83 are applied to all other options within this menu entry (which also
84 accept an "if" expression), so these two examples are equivalent: 84 accept an "if" expression), so these two examples are equivalent:
85 85
@@ -153,7 +153,7 @@ Nonconstant symbols are the most common ones and are defined with the
153'config' statement. Nonconstant symbols consist entirely of alphanumeric 153'config' statement. Nonconstant symbols consist entirely of alphanumeric
154characters or underscores. 154characters or underscores.
155Constant symbols are only part of expressions. Constant symbols are 155Constant symbols are only part of expressions. Constant symbols are
156always surrounded by single or double quotes. Within the quote any 156always surrounded by single or double quotes. Within the quote, any
157other character is allowed and the quotes can be escaped using '\'. 157other character is allowed and the quotes can be escaped using '\'.
158 158
159Menu structure 159Menu structure
@@ -237,7 +237,7 @@ choices:
237 <choice block> 237 <choice block>
238 "endchoice" 238 "endchoice"
239 239
240This defines a choice group and accepts any of above attributes as 240This defines a choice group and accepts any of the above attributes as
241options. A choice can only be of type bool or tristate, while a boolean 241options. A choice can only be of type bool or tristate, while a boolean
242choice only allows a single config entry to be selected, a tristate 242choice only allows a single config entry to be selected, a tristate
243choice also allows any number of config entries to be set to 'm'. This 243choice also allows any number of config entries to be set to 'm'. This
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
index 0706699c9da9..b7d6abb501a6 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -22,7 +22,7 @@ This document describes the Linux kernel Makefiles.
22 === 4 Host Program support 22 === 4 Host Program support
23 --- 4.1 Simple Host Program 23 --- 4.1 Simple Host Program
24 --- 4.2 Composite Host Programs 24 --- 4.2 Composite Host Programs
25 --- 4.3 Defining shared libraries 25 --- 4.3 Defining shared libraries
26 --- 4.4 Using C++ for host programs 26 --- 4.4 Using C++ for host programs
27 --- 4.5 Controlling compiler options for host programs 27 --- 4.5 Controlling compiler options for host programs
28 --- 4.6 When host programs are actually built 28 --- 4.6 When host programs are actually built
@@ -69,7 +69,7 @@ architecture-specific information to the top Makefile.
69 69
70Each subdirectory has a kbuild Makefile which carries out the commands 70Each subdirectory has a kbuild Makefile which carries out the commands
71passed down from above. The kbuild Makefile uses information from the 71passed down from above. The kbuild Makefile uses information from the
72.config file to construct various file lists used by kbuild to build 72.config file to construct various file lists used by kbuild to build
73any built-in or modular targets. 73any built-in or modular targets.
74 74
75scripts/Makefile.* contains all the definitions/rules etc. that 75scripts/Makefile.* contains all the definitions/rules etc. that
@@ -86,7 +86,7 @@ any kernel Makefiles (or any other source files).
86 86
87*Normal developers* are people who work on features such as device 87*Normal developers* are people who work on features such as device
88drivers, file systems, and network protocols. These people need to 88drivers, file systems, and network protocols. These people need to
89maintain the kbuild Makefiles for the subsystem that they are 89maintain the kbuild Makefiles for the subsystem they are
90working on. In order to do this effectively, they need some overall 90working on. In order to do this effectively, they need some overall
91knowledge about the kernel Makefiles, plus detailed knowledge about the 91knowledge about the kernel Makefiles, plus detailed knowledge about the
92public interface for kbuild. 92public interface for kbuild.
@@ -104,10 +104,10 @@ This document is aimed towards normal developers and arch developers.
104=== 3 The kbuild files 104=== 3 The kbuild files
105 105
106Most Makefiles within the kernel are kbuild Makefiles that use the 106Most Makefiles within the kernel are kbuild Makefiles that use the
107kbuild infrastructure. This chapter introduce the syntax used in the 107kbuild infrastructure. This chapter introduces the syntax used in the
108kbuild makefiles. 108kbuild makefiles.
109The preferred name for the kbuild files are 'Makefile' but 'Kbuild' can 109The preferred name for the kbuild files are 'Makefile' but 'Kbuild' can
110be used and if both a 'Makefile' and a 'Kbuild' file exists then the 'Kbuild' 110be used and if both a 'Makefile' and a 'Kbuild' file exists, then the 'Kbuild'
111file will be used. 111file will be used.
112 112
113Section 3.1 "Goal definitions" is a quick intro, further chapters provide 113Section 3.1 "Goal definitions" is a quick intro, further chapters provide
@@ -124,7 +124,7 @@ more details, with real examples.
124 Example: 124 Example:
125 obj-y += foo.o 125 obj-y += foo.o
126 126
127 This tell kbuild that there is one object in that directory named 127 This tell kbuild that there is one object in that directory, named
128 foo.o. foo.o will be built from foo.c or foo.S. 128 foo.o. foo.o will be built from foo.c or foo.S.
129 129
130 If foo.o shall be built as a module, the variable obj-m is used. 130 If foo.o shall be built as a module, the variable obj-m is used.
@@ -140,7 +140,7 @@ more details, with real examples.
140--- 3.2 Built-in object goals - obj-y 140--- 3.2 Built-in object goals - obj-y
141 141
142 The kbuild Makefile specifies object files for vmlinux 142 The kbuild Makefile specifies object files for vmlinux
143 in the lists $(obj-y). These lists depend on the kernel 143 in the $(obj-y) lists. These lists depend on the kernel
144 configuration. 144 configuration.
145 145
146 Kbuild compiles all the $(obj-y) files. It then calls 146 Kbuild compiles all the $(obj-y) files. It then calls
@@ -154,8 +154,8 @@ more details, with real examples.
154 Link order is significant, because certain functions 154 Link order is significant, because certain functions
155 (module_init() / __initcall) will be called during boot in the 155 (module_init() / __initcall) will be called during boot in the
156 order they appear. So keep in mind that changing the link 156 order they appear. So keep in mind that changing the link
157 order may e.g. change the order in which your SCSI 157 order may e.g. change the order in which your SCSI
158 controllers are detected, and thus you disks are renumbered. 158 controllers are detected, and thus your disks are renumbered.
159 159
160 Example: 160 Example:
161 #drivers/isdn/i4l/Makefile 161 #drivers/isdn/i4l/Makefile
@@ -203,11 +203,11 @@ more details, with real examples.
203 Example: 203 Example:
204 #fs/ext2/Makefile 204 #fs/ext2/Makefile
205 obj-$(CONFIG_EXT2_FS) += ext2.o 205 obj-$(CONFIG_EXT2_FS) += ext2.o
206 ext2-y := balloc.o bitmap.o 206 ext2-y := balloc.o bitmap.o
207 ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o 207 ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o
208 208
209 In this example xattr.o is only part of the composite object 209 In this example, xattr.o is only part of the composite object
210 ext2.o, if $(CONFIG_EXT2_FS_XATTR) evaluates to 'y'. 210 ext2.o if $(CONFIG_EXT2_FS_XATTR) evaluates to 'y'.
211 211
212 Note: Of course, when you are building objects into the kernel, 212 Note: Of course, when you are building objects into the kernel,
213 the syntax above will also work. So, if you have CONFIG_EXT2_FS=y, 213 the syntax above will also work. So, if you have CONFIG_EXT2_FS=y,
@@ -221,16 +221,16 @@ more details, with real examples.
221 221
222--- 3.5 Library file goals - lib-y 222--- 3.5 Library file goals - lib-y
223 223
224 Objects listed with obj-* are used for modules or 224 Objects listed with obj-* are used for modules, or
225 combined in a built-in.o for that specific directory. 225 combined in a built-in.o for that specific directory.
226 There is also the possibility to list objects that will 226 There is also the possibility to list objects that will
227 be included in a library, lib.a. 227 be included in a library, lib.a.
228 All objects listed with lib-y are combined in a single 228 All objects listed with lib-y are combined in a single
229 library for that directory. 229 library for that directory.
230 Objects that are listed in obj-y and additional listed in 230 Objects that are listed in obj-y and additionaly listed in
231 lib-y will not be included in the library, since they will anyway 231 lib-y will not be included in the library, since they will anyway
232 be accessible. 232 be accessible.
233 For consistency objects listed in lib-m will be included in lib.a. 233 For consistency, objects listed in lib-m will be included in lib.a.
234 234
235 Note that the same kbuild makefile may list files to be built-in 235 Note that the same kbuild makefile may list files to be built-in
236 and to be part of a library. Therefore the same directory 236 and to be part of a library. Therefore the same directory
@@ -241,11 +241,11 @@ more details, with real examples.
241 lib-y := checksum.o delay.o 241 lib-y := checksum.o delay.o
242 242
243 This will create a library lib.a based on checksum.o and delay.o. 243 This will create a library lib.a based on checksum.o and delay.o.
244 For kbuild to actually recognize that there is a lib.a being build 244 For kbuild to actually recognize that there is a lib.a being built,
245 the directory shall be listed in libs-y. 245 the directory shall be listed in libs-y.
246 See also "6.3 List directories to visit when descending". 246 See also "6.3 List directories to visit when descending".
247 247
248 Usage of lib-y is normally restricted to lib/ and arch/*/lib. 248 Use of lib-y is normally restricted to lib/ and arch/*/lib.
249 249
250--- 3.6 Descending down in directories 250--- 3.6 Descending down in directories
251 251
@@ -255,7 +255,7 @@ more details, with real examples.
255 invoke make recursively in subdirectories, provided you let it know of 255 invoke make recursively in subdirectories, provided you let it know of
256 them. 256 them.
257 257
258 To do so obj-y and obj-m are used. 258 To do so, obj-y and obj-m are used.
259 ext2 lives in a separate directory, and the Makefile present in fs/ 259 ext2 lives in a separate directory, and the Makefile present in fs/
260 tells kbuild to descend down using the following assignment. 260 tells kbuild to descend down using the following assignment.
261 261
@@ -353,8 +353,8 @@ more details, with real examples.
353 Special rules are used when the kbuild infrastructure does 353 Special rules are used when the kbuild infrastructure does
354 not provide the required support. A typical example is 354 not provide the required support. A typical example is
355 header files generated during the build process. 355 header files generated during the build process.
356 Another example is the architecture specific Makefiles which 356 Another example are the architecture specific Makefiles which
357 needs special rules to prepare boot images etc. 357 need special rules to prepare boot images etc.
358 358
359 Special rules are written as normal Make rules. 359 Special rules are written as normal Make rules.
360 Kbuild is not executing in the directory where the Makefile is 360 Kbuild is not executing in the directory where the Makefile is
@@ -387,28 +387,28 @@ more details, with real examples.
387 387
388--- 3.11 $(CC) support functions 388--- 3.11 $(CC) support functions
389 389
390 The kernel may be build with several different versions of 390 The kernel may be built with several different versions of
391 $(CC), each supporting a unique set of features and options. 391 $(CC), each supporting a unique set of features and options.
392 kbuild provide basic support to check for valid options for $(CC). 392 kbuild provide basic support to check for valid options for $(CC).
393 $(CC) is useally the gcc compiler, but other alternatives are 393 $(CC) is useally the gcc compiler, but other alternatives are
394 available. 394 available.
395 395
396 as-option 396 as-option
397 as-option is used to check if $(CC) when used to compile 397 as-option is used to check if $(CC) -- when used to compile
398 assembler (*.S) files supports the given option. An optional 398 assembler (*.S) files -- supports the given option. An optional
399 second option may be specified if first option are not supported. 399 second option may be specified if the first option is not supported.
400 400
401 Example: 401 Example:
402 #arch/sh/Makefile 402 #arch/sh/Makefile
403 cflags-y += $(call as-option,-Wa$(comma)-isa=$(isa-y),) 403 cflags-y += $(call as-option,-Wa$(comma)-isa=$(isa-y),)
404 404
405 In the above example cflags-y will be assinged the the option 405 In the above example, cflags-y will be assigned the option
406 -Wa$(comma)-isa=$(isa-y) if it is supported by $(CC). 406 -Wa$(comma)-isa=$(isa-y) if it is supported by $(CC).
407 The second argument is optional, and if supplied will be used 407 The second argument is optional, and if supplied will be used
408 if first argument is not supported. 408 if first argument is not supported.
409 409
410 ld-option 410 ld-option
411 ld-option is used to check if $(CC) when used to link object files 411 ld-option is used to check if $(CC) when used to link object files
412 supports the given option. An optional second option may be 412 supports the given option. An optional second option may be
413 specified if first option are not supported. 413 specified if first option are not supported.
414 414
@@ -422,7 +422,7 @@ more details, with real examples.
422 if first argument is not supported. 422 if first argument is not supported.
423 423
424 cc-option 424 cc-option
425 cc-option is used to check if $(CC) support a given option, and not 425 cc-option is used to check if $(CC) supports a given option, and not
426 supported to use an optional second option. 426 supported to use an optional second option.
427 427
428 Example: 428 Example:
@@ -430,12 +430,12 @@ more details, with real examples.
430 cflags-y += $(call cc-option,-march=pentium-mmx,-march=i586) 430 cflags-y += $(call cc-option,-march=pentium-mmx,-march=i586)
431 431
432 In the above example cflags-y will be assigned the option 432 In the above example cflags-y will be assigned the option
433 -march=pentium-mmx if supported by $(CC), otherwise -march-i586. 433 -march=pentium-mmx if supported by $(CC), otherwise -march=i586.
434 The second argument to cc-option is optional, and if omitted 434 The second argument to cc-option is optional, and if omitted,
435 cflags-y will be assigned no value if first option is not supported. 435 cflags-y will be assigned no value if first option is not supported.
436 436
437 cc-option-yn 437 cc-option-yn
438 cc-option-yn is used to check if gcc supports a given option 438 cc-option-yn is used to check if gcc supports a given option
439 and return 'y' if supported, otherwise 'n'. 439 and return 'y' if supported, otherwise 'n'.
440 440
441 Example: 441 Example:
@@ -443,32 +443,33 @@ more details, with real examples.
443 biarch := $(call cc-option-yn, -m32) 443 biarch := $(call cc-option-yn, -m32)
444 aflags-$(biarch) += -a32 444 aflags-$(biarch) += -a32
445 cflags-$(biarch) += -m32 445 cflags-$(biarch) += -m32
446 446
447 In the above example $(biarch) is set to y if $(CC) supports the -m32 447 In the above example, $(biarch) is set to y if $(CC) supports the -m32
448 option. When $(biarch) equals to y the expanded variables $(aflags-y) 448 option. When $(biarch) equals 'y', the expanded variables $(aflags-y)
449 and $(cflags-y) will be assigned the values -a32 and -m32. 449 and $(cflags-y) will be assigned the values -a32 and -m32,
450 respectively.
450 451
451 cc-option-align 452 cc-option-align
452 gcc version >= 3.0 shifted type of options used to speify 453 gcc versions >= 3.0 changed the type of options used to specify
453 alignment of functions, loops etc. $(cc-option-align) whrn used 454 alignment of functions, loops etc. $(cc-option-align), when used
454 as prefix to the align options will select the right prefix: 455 as prefix to the align options, will select the right prefix:
455 gcc < 3.00 456 gcc < 3.00
456 cc-option-align = -malign 457 cc-option-align = -malign
457 gcc >= 3.00 458 gcc >= 3.00
458 cc-option-align = -falign 459 cc-option-align = -falign
459 460
460 Example: 461 Example:
461 CFLAGS += $(cc-option-align)-functions=4 462 CFLAGS += $(cc-option-align)-functions=4
462 463
463 In the above example the option -falign-functions=4 is used for 464 In the above example, the option -falign-functions=4 is used for
464 gcc >= 3.00. For gcc < 3.00 -malign-functions=4 is used. 465 gcc >= 3.00. For gcc < 3.00, -malign-functions=4 is used.
465 466
466 cc-version 467 cc-version
467 cc-version return a numerical version of the $(CC) compiler version. 468 cc-version returns a numerical version of the $(CC) compiler version.
468 The format is <major><minor> where both are two digits. So for example 469 The format is <major><minor> where both are two digits. So for example
469 gcc 3.41 would return 0341. 470 gcc 3.41 would return 0341.
470 cc-version is useful when a specific $(CC) version is faulty in one 471 cc-version is useful when a specific $(CC) version is faulty in one
471 area, for example the -mregparm=3 were broken in some gcc version 472 area, for example -mregparm=3 was broken in some gcc versions
472 even though the option was accepted by gcc. 473 even though the option was accepted by gcc.
473 474
474 Example: 475 Example:
@@ -477,20 +478,20 @@ more details, with real examples.
477 if [ $(call cc-version) -ge 0300 ] ; then \ 478 if [ $(call cc-version) -ge 0300 ] ; then \
478 echo "-mregparm=3"; fi ;) 479 echo "-mregparm=3"; fi ;)
479 480
480 In the above example -mregparm=3 is only used for gcc version greater 481 In the above example, -mregparm=3 is only used for gcc version greater
481 than or equal to gcc 3.0. 482 than or equal to gcc 3.0.
482 483
483 cc-ifversion 484 cc-ifversion
484 cc-ifversion test the version of $(CC) and equals last argument if 485 cc-ifversion tests the version of $(CC) and equals last argument if
485 version expression is true. 486 version expression is true.
486 487
487 Example: 488 Example:
488 #fs/reiserfs/Makefile 489 #fs/reiserfs/Makefile
489 EXTRA_CFLAGS := $(call cc-ifversion, -lt, 0402, -O1) 490 EXTRA_CFLAGS := $(call cc-ifversion, -lt, 0402, -O1)
490 491
491 In this example EXTRA_CFLAGS will be assigned the value -O1 if the 492 In this example, EXTRA_CFLAGS will be assigned the value -O1 if the
492 $(CC) version is less than 4.2. 493 $(CC) version is less than 4.2.
493 cc-ifversion takes all the shell operators: 494 cc-ifversion takes all the shell operators:
494 -eq, -ne, -lt, -le, -gt, and -ge 495 -eq, -ne, -lt, -le, -gt, and -ge
495 The third parameter may be a text as in this example, but it may also 496 The third parameter may be a text as in this example, but it may also
496 be an expanded variable or a macro. 497 be an expanded variable or a macro.
@@ -506,7 +507,7 @@ The first step is to tell kbuild that a host program exists. This is
506done utilising the variable hostprogs-y. 507done utilising the variable hostprogs-y.
507 508
508The second step is to add an explicit dependency to the executable. 509The second step is to add an explicit dependency to the executable.
509This can be done in two ways. Either add the dependency in a rule, 510This can be done in two ways. Either add the dependency in a rule,
510or utilise the variable $(always). 511or utilise the variable $(always).
511Both possibilities are described in the following. 512Both possibilities are described in the following.
512 513
@@ -523,28 +524,28 @@ Both possibilities are described in the following.
523 Kbuild assumes in the above example that bin2hex is made from a single 524 Kbuild assumes in the above example that bin2hex is made from a single
524 c-source file named bin2hex.c located in the same directory as 525 c-source file named bin2hex.c located in the same directory as
525 the Makefile. 526 the Makefile.
526 527
527--- 4.2 Composite Host Programs 528--- 4.2 Composite Host Programs
528 529
529 Host programs can be made up based on composite objects. 530 Host programs can be made up based on composite objects.
530 The syntax used to define composite objects for host programs is 531 The syntax used to define composite objects for host programs is
531 similar to the syntax used for kernel objects. 532 similar to the syntax used for kernel objects.
532 $(<executeable>-objs) list all objects used to link the final 533 $(<executeable>-objs) lists all objects used to link the final
533 executable. 534 executable.
534 535
535 Example: 536 Example:
536 #scripts/lxdialog/Makefile 537 #scripts/lxdialog/Makefile
537 hostprogs-y := lxdialog 538 hostprogs-y := lxdialog
538 lxdialog-objs := checklist.o lxdialog.o 539 lxdialog-objs := checklist.o lxdialog.o
539 540
540 Objects with extension .o are compiled from the corresponding .c 541 Objects with extension .o are compiled from the corresponding .c
541 files. In the above example checklist.c is compiled to checklist.o 542 files. In the above example, checklist.c is compiled to checklist.o
542 and lxdialog.c is compiled to lxdialog.o. 543 and lxdialog.c is compiled to lxdialog.o.
543 Finally the two .o files are linked to the executable, lxdialog. 544 Finally, the two .o files are linked to the executable, lxdialog.
544 Note: The syntax <executable>-y is not permitted for host-programs. 545 Note: The syntax <executable>-y is not permitted for host-programs.
545 546
546--- 4.3 Defining shared libraries 547--- 4.3 Defining shared libraries
547 548
548 Objects with extension .so are considered shared libraries, and 549 Objects with extension .so are considered shared libraries, and
549 will be compiled as position independent objects. 550 will be compiled as position independent objects.
550 Kbuild provides support for shared libraries, but the usage 551 Kbuild provides support for shared libraries, but the usage
@@ -557,7 +558,7 @@ Both possibilities are described in the following.
557 hostprogs-y := conf 558 hostprogs-y := conf
558 conf-objs := conf.o libkconfig.so 559 conf-objs := conf.o libkconfig.so
559 libkconfig-objs := expr.o type.o 560 libkconfig-objs := expr.o type.o
560 561
561 Shared libraries always require a corresponding -objs line, and 562 Shared libraries always require a corresponding -objs line, and
562 in the example above the shared library libkconfig is composed by 563 in the example above the shared library libkconfig is composed by
563 the two objects expr.o and type.o. 564 the two objects expr.o and type.o.
@@ -578,7 +579,7 @@ Both possibilities are described in the following.
578 579
579 In the example above the executable is composed of the C++ file 580 In the example above the executable is composed of the C++ file
580 qconf.cc - identified by $(qconf-cxxobjs). 581 qconf.cc - identified by $(qconf-cxxobjs).
581 582
582 If qconf is composed by a mixture of .c and .cc files, then an 583 If qconf is composed by a mixture of .c and .cc files, then an
583 additional line can be used to identify this. 584 additional line can be used to identify this.
584 585
@@ -587,34 +588,35 @@ Both possibilities are described in the following.
587 hostprogs-y := qconf 588 hostprogs-y := qconf
588 qconf-cxxobjs := qconf.o 589 qconf-cxxobjs := qconf.o
589 qconf-objs := check.o 590 qconf-objs := check.o
590 591
591--- 4.5 Controlling compiler options for host programs 592--- 4.5 Controlling compiler options for host programs
592 593
593 When compiling host programs, it is possible to set specific flags. 594 When compiling host programs, it is possible to set specific flags.
594 The programs will always be compiled utilising $(HOSTCC) passed 595 The programs will always be compiled utilising $(HOSTCC) passed
595 the options specified in $(HOSTCFLAGS). 596 the options specified in $(HOSTCFLAGS).
596 To set flags that will take effect for all host programs created 597 To set flags that will take effect for all host programs created
597 in that Makefile use the variable HOST_EXTRACFLAGS. 598 in that Makefile, use the variable HOST_EXTRACFLAGS.
598 599
599 Example: 600 Example:
600 #scripts/lxdialog/Makefile 601 #scripts/lxdialog/Makefile
601 HOST_EXTRACFLAGS += -I/usr/include/ncurses 602 HOST_EXTRACFLAGS += -I/usr/include/ncurses
602 603
603 To set specific flags for a single file the following construction 604 To set specific flags for a single file the following construction
604 is used: 605 is used:
605 606
606 Example: 607 Example:
607 #arch/ppc64/boot/Makefile 608 #arch/ppc64/boot/Makefile
608 HOSTCFLAGS_piggyback.o := -DKERNELBASE=$(KERNELBASE) 609 HOSTCFLAGS_piggyback.o := -DKERNELBASE=$(KERNELBASE)
609 610
610 It is also possible to specify additional options to the linker. 611 It is also possible to specify additional options to the linker.
611 612
612 Example: 613 Example:
613 #scripts/kconfig/Makefile 614 #scripts/kconfig/Makefile
614 HOSTLOADLIBES_qconf := -L$(QTDIR)/lib 615 HOSTLOADLIBES_qconf := -L$(QTDIR)/lib
615 616
616 When linking qconf it will be passed the extra option "-L$(QTDIR)/lib". 617 When linking qconf, it will be passed the extra option
617 618 "-L$(QTDIR)/lib".
619
618--- 4.6 When host programs are actually built 620--- 4.6 When host programs are actually built
619 621
620 Kbuild will only build host-programs when they are referenced 622 Kbuild will only build host-programs when they are referenced
@@ -629,7 +631,7 @@ Both possibilities are described in the following.
629 $(obj)/devlist.h: $(src)/pci.ids $(obj)/gen-devlist 631 $(obj)/devlist.h: $(src)/pci.ids $(obj)/gen-devlist
630 ( cd $(obj); ./gen-devlist ) < $< 632 ( cd $(obj); ./gen-devlist ) < $<
631 633
632 The target $(obj)/devlist.h will not be built before 634 The target $(obj)/devlist.h will not be built before
633 $(obj)/gen-devlist is updated. Note that references to 635 $(obj)/gen-devlist is updated. Note that references to
634 the host programs in special rules must be prefixed with $(obj). 636 the host programs in special rules must be prefixed with $(obj).
635 637
@@ -648,7 +650,7 @@ Both possibilities are described in the following.
648 650
649--- 4.7 Using hostprogs-$(CONFIG_FOO) 651--- 4.7 Using hostprogs-$(CONFIG_FOO)
650 652
651 A typcal pattern in a Kbuild file lok like this: 653 A typical pattern in a Kbuild file looks like this:
652 654
653 Example: 655 Example:
654 #scripts/Makefile 656 #scripts/Makefile
@@ -656,13 +658,13 @@ Both possibilities are described in the following.
656 658
657 Kbuild knows about both 'y' for built-in and 'm' for module. 659 Kbuild knows about both 'y' for built-in and 'm' for module.
658 So if a config symbol evaluate to 'm', kbuild will still build 660 So if a config symbol evaluate to 'm', kbuild will still build
659 the binary. In other words Kbuild handle hostprogs-m exactly 661 the binary. In other words, Kbuild handles hostprogs-m exactly
660 like hostprogs-y. But only hostprogs-y is recommend used 662 like hostprogs-y. But only hostprogs-y is recommended to be used
661 when no CONFIG symbol are involved. 663 when no CONFIG symbols are involved.
662 664
663=== 5 Kbuild clean infrastructure 665=== 5 Kbuild clean infrastructure
664 666
665"make clean" deletes most generated files in the src tree where the kernel 667"make clean" deletes most generated files in the obj tree where the kernel
666is compiled. This includes generated files such as host programs. 668is compiled. This includes generated files such as host programs.
667Kbuild knows targets listed in $(hostprogs-y), $(hostprogs-m), $(always), 669Kbuild knows targets listed in $(hostprogs-y), $(hostprogs-m), $(always),
668$(extra-y) and $(targets). They are all deleted during "make clean". 670$(extra-y) and $(targets). They are all deleted during "make clean".
@@ -680,7 +682,8 @@ When executing "make clean", the two files "devlist.h classlist.h" will
680be deleted. Kbuild will assume files to be in same relative directory as the 682be deleted. Kbuild will assume files to be in same relative directory as the
681Makefile except if an absolute path is specified (path starting with '/'). 683Makefile except if an absolute path is specified (path starting with '/').
682 684
683To delete a directory hirachy use: 685To delete a directory hierarchy use:
686
684 Example: 687 Example:
685 #scripts/package/Makefile 688 #scripts/package/Makefile
686 clean-dirs := $(objtree)/debian/ 689 clean-dirs := $(objtree)/debian/
@@ -723,29 +726,29 @@ be visited during "make clean".
723 726
724The top level Makefile sets up the environment and does the preparation, 727The top level Makefile sets up the environment and does the preparation,
725before starting to descend down in the individual directories. 728before starting to descend down in the individual directories.
726The top level makefile contains the generic part, whereas the 729The top level makefile contains the generic part, whereas
727arch/$(ARCH)/Makefile contains what is required to set-up kbuild 730arch/$(ARCH)/Makefile contains what is required to set up kbuild
728to the said architecture. 731for said architecture.
729To do so arch/$(ARCH)/Makefile sets a number of variables, and defines 732To do so, arch/$(ARCH)/Makefile sets up a number of variables and defines
730a few targets. 733a few targets.
731 734
732When kbuild executes the following steps are followed (roughly): 735When kbuild executes, the following steps are followed (roughly):
7331) Configuration of the kernel => produced .config 7361) Configuration of the kernel => produce .config
7342) Store kernel version in include/linux/version.h 7372) Store kernel version in include/linux/version.h
7353) Symlink include/asm to include/asm-$(ARCH) 7383) Symlink include/asm to include/asm-$(ARCH)
7364) Updating all other prerequisites to the target prepare: 7394) Updating all other prerequisites to the target prepare:
737 - Additional prerequisites are specified in arch/$(ARCH)/Makefile 740 - Additional prerequisites are specified in arch/$(ARCH)/Makefile
7385) Recursively descend down in all directories listed in 7415) Recursively descend down in all directories listed in
739 init-* core* drivers-* net-* libs-* and build all targets. 742 init-* core* drivers-* net-* libs-* and build all targets.
740 - The value of the above variables are extended in arch/$(ARCH)/Makefile. 743 - The values of the above variables are expanded in arch/$(ARCH)/Makefile.
7416) All object files are then linked and the resulting file vmlinux is 7446) All object files are then linked and the resulting file vmlinux is
742 located at the root of the src tree. 745 located at the root of the obj tree.
743 The very first objects linked are listed in head-y, assigned by 746 The very first objects linked are listed in head-y, assigned by
744 arch/$(ARCH)/Makefile. 747 arch/$(ARCH)/Makefile.
7457) Finally the architecture specific part does any required post processing 7487) Finally, the architecture specific part does any required post processing
746 and builds the final bootimage. 749 and builds the final bootimage.
747 - This includes building boot records 750 - This includes building boot records
748 - Preparing initrd images and the like 751 - Preparing initrd images and thelike
749 752
750 753
751--- 6.1 Set variables to tweak the build to the architecture 754--- 6.1 Set variables to tweak the build to the architecture
@@ -760,7 +763,7 @@ When kbuild executes the following steps are followed (roughly):
760 LDFLAGS := -m elf_s390 763 LDFLAGS := -m elf_s390
761 Note: EXTRA_LDFLAGS and LDFLAGS_$@ can be used to further customise 764 Note: EXTRA_LDFLAGS and LDFLAGS_$@ can be used to further customise
762 the flags used. See chapter 7. 765 the flags used. See chapter 7.
763 766
764 LDFLAGS_MODULE Options for $(LD) when linking modules 767 LDFLAGS_MODULE Options for $(LD) when linking modules
765 768
766 LDFLAGS_MODULE is used to set specific flags for $(LD) when 769 LDFLAGS_MODULE is used to set specific flags for $(LD) when
@@ -770,7 +773,7 @@ When kbuild executes the following steps are followed (roughly):
770 LDFLAGS_vmlinux Options for $(LD) when linking vmlinux 773 LDFLAGS_vmlinux Options for $(LD) when linking vmlinux
771 774
772 LDFLAGS_vmlinux is used to specify additional flags to pass to 775 LDFLAGS_vmlinux is used to specify additional flags to pass to
773 the linker when linking the final vmlinux. 776 the linker when linking the final vmlinux image.
774 LDFLAGS_vmlinux uses the LDFLAGS_$@ support. 777 LDFLAGS_vmlinux uses the LDFLAGS_$@ support.
775 778
776 Example: 779 Example:
@@ -780,7 +783,7 @@ When kbuild executes the following steps are followed (roughly):
780 OBJCOPYFLAGS objcopy flags 783 OBJCOPYFLAGS objcopy flags
781 784
782 When $(call if_changed,objcopy) is used to translate a .o file, 785 When $(call if_changed,objcopy) is used to translate a .o file,
783 then the flags specified in OBJCOPYFLAGS will be used. 786 the flags specified in OBJCOPYFLAGS will be used.
784 $(call if_changed,objcopy) is often used to generate raw binaries on 787 $(call if_changed,objcopy) is often used to generate raw binaries on
785 vmlinux. 788 vmlinux.
786 789
@@ -792,7 +795,7 @@ When kbuild executes the following steps are followed (roughly):
792 $(obj)/image: vmlinux FORCE 795 $(obj)/image: vmlinux FORCE
793 $(call if_changed,objcopy) 796 $(call if_changed,objcopy)
794 797
795 In this example the binary $(obj)/image is a binary version of 798 In this example, the binary $(obj)/image is a binary version of
796 vmlinux. The usage of $(call if_changed,xxx) will be described later. 799 vmlinux. The usage of $(call if_changed,xxx) will be described later.
797 800
798 AFLAGS $(AS) assembler flags 801 AFLAGS $(AS) assembler flags
@@ -809,7 +812,7 @@ When kbuild executes the following steps are followed (roughly):
809 Default value - see top level Makefile 812 Default value - see top level Makefile
810 Append or modify as required per architecture. 813 Append or modify as required per architecture.
811 814
812 Often the CFLAGS variable depends on the configuration. 815 Often, the CFLAGS variable depends on the configuration.
813 816
814 Example: 817 Example:
815 #arch/i386/Makefile 818 #arch/i386/Makefile
@@ -830,7 +833,7 @@ When kbuild executes the following steps are followed (roughly):
830 ... 833 ...
831 834
832 835
833 The first examples utilises the trick that a config option expands 836 The first example utilises the trick that a config option expands
834 to 'y' when selected. 837 to 'y' when selected.
835 838
836 CFLAGS_KERNEL $(CC) options specific for built-in 839 CFLAGS_KERNEL $(CC) options specific for built-in
@@ -843,18 +846,18 @@ When kbuild executes the following steps are followed (roughly):
843 $(CFLAGS_MODULE) contains extra C compiler flags used to compile code 846 $(CFLAGS_MODULE) contains extra C compiler flags used to compile code
844 for loadable kernel modules. 847 for loadable kernel modules.
845 848
846 849
847--- 6.2 Add prerequisites to archprepare: 850--- 6.2 Add prerequisites to archprepare:
848 851
849 The archprepare: rule is used to list prerequisites that needs to be 852 The archprepare: rule is used to list prerequisites that need to be
850 built before starting to descend down in the subdirectories. 853 built before starting to descend down in the subdirectories.
851 This is usual header files containing assembler constants. 854 This is usually used for header files containing assembler constants.
852 855
853 Example: 856 Example:
854 #arch/arm/Makefile 857 #arch/arm/Makefile
855 archprepare: maketools 858 archprepare: maketools
856 859
857 In this example the file target maketools will be processed 860 In this example, the file target maketools will be processed
858 before descending down in the subdirectories. 861 before descending down in the subdirectories.
859 See also chapter XXX-TODO that describe how kbuild supports 862 See also chapter XXX-TODO that describe how kbuild supports
860 generating offset header files. 863 generating offset header files.
@@ -867,18 +870,19 @@ When kbuild executes the following steps are followed (roughly):
867 corresponding arch-specific section for modules; the module-building 870 corresponding arch-specific section for modules; the module-building
868 machinery is all architecture-independent. 871 machinery is all architecture-independent.
869 872
870 873
871 head-y, init-y, core-y, libs-y, drivers-y, net-y 874 head-y, init-y, core-y, libs-y, drivers-y, net-y
872 875
873 $(head-y) list objects to be linked first in vmlinux. 876 $(head-y) lists objects to be linked first in vmlinux.
874 $(libs-y) list directories where a lib.a archive can be located. 877 $(libs-y) lists directories where a lib.a archive can be located.
875 The rest list directories where a built-in.o object file can be located. 878 The rest lists directories where a built-in.o object file can be
879 located.
876 880
877 $(init-y) objects will be located after $(head-y). 881 $(init-y) objects will be located after $(head-y).
878 Then the rest follows in this order: 882 Then the rest follows in this order:
879 $(core-y), $(libs-y), $(drivers-y) and $(net-y). 883 $(core-y), $(libs-y), $(drivers-y) and $(net-y).
880 884
881 The top level Makefile define values for all generic directories, 885 The top level Makefile defines values for all generic directories,
882 and arch/$(ARCH)/Makefile only adds architecture specific directories. 886 and arch/$(ARCH)/Makefile only adds architecture specific directories.
883 887
884 Example: 888 Example:
@@ -915,27 +919,27 @@ When kbuild executes the following steps are followed (roughly):
915 "$(Q)$(MAKE) $(build)=<dir>" is the recommended way to invoke 919 "$(Q)$(MAKE) $(build)=<dir>" is the recommended way to invoke
916 make in a subdirectory. 920 make in a subdirectory.
917 921
918 There are no rules for naming of the architecture specific targets, 922 There are no rules for naming architecture specific targets,
919 but executing "make help" will list all relevant targets. 923 but executing "make help" will list all relevant targets.
920 To support this $(archhelp) must be defined. 924 To support this, $(archhelp) must be defined.
921 925
922 Example: 926 Example:
923 #arch/i386/Makefile 927 #arch/i386/Makefile
924 define archhelp 928 define archhelp
925 echo '* bzImage - Image (arch/$(ARCH)/boot/bzImage)' 929 echo '* bzImage - Image (arch/$(ARCH)/boot/bzImage)'
926 endef 930 endif
927 931
928 When make is executed without arguments, the first goal encountered 932 When make is executed without arguments, the first goal encountered
929 will be built. In the top level Makefile the first goal present 933 will be built. In the top level Makefile the first goal present
930 is all:. 934 is all:.
931 An architecture shall always per default build a bootable image. 935 An architecture shall always, per default, build a bootable image.
932 In "make help" the default goal is highlighted with a '*'. 936 In "make help", the default goal is highlighted with a '*'.
933 Add a new prerequisite to all: to select a default goal different 937 Add a new prerequisite to all: to select a default goal different
934 from vmlinux. 938 from vmlinux.
935 939
936 Example: 940 Example:
937 #arch/i386/Makefile 941 #arch/i386/Makefile
938 all: bzImage 942 all: bzImage
939 943
940 When "make" is executed without arguments, bzImage will be built. 944 When "make" is executed without arguments, bzImage will be built.
941 945
@@ -955,10 +959,10 @@ When kbuild executes the following steps are followed (roughly):
955 #arch/i386/kernel/Makefile 959 #arch/i386/kernel/Makefile
956 extra-y := head.o init_task.o 960 extra-y := head.o init_task.o
957 961
958 In this example extra-y is used to list object files that 962 In this example, extra-y is used to list object files that
959 shall be built, but shall not be linked as part of built-in.o. 963 shall be built, but shall not be linked as part of built-in.o.
960 964
961 965
962--- 6.6 Commands useful for building a boot image 966--- 6.6 Commands useful for building a boot image
963 967
964 Kbuild provides a few macros that are useful when building a 968 Kbuild provides a few macros that are useful when building a
@@ -972,8 +976,8 @@ When kbuild executes the following steps are followed (roughly):
972 target: source(s) FORCE 976 target: source(s) FORCE
973 $(call if_changed,ld/objcopy/gzip) 977 $(call if_changed,ld/objcopy/gzip)
974 978
975 When the rule is evaluated it is checked to see if any files 979 When the rule is evaluated, it is checked to see if any files
976 needs an update, or the commandline has changed since last 980 needs an update, or the command line has changed since the last
977 invocation. The latter will force a rebuild if any options 981 invocation. The latter will force a rebuild if any options
978 to the executable have changed. 982 to the executable have changed.
979 Any target that utilises if_changed must be listed in $(targets), 983 Any target that utilises if_changed must be listed in $(targets),
@@ -991,8 +995,8 @@ When kbuild executes the following steps are followed (roughly):
991 #WRONG!# $(call if_changed, ld/objcopy/gzip) 995 #WRONG!# $(call if_changed, ld/objcopy/gzip)
992 996
993 ld 997 ld
994 Link target. Often LDFLAGS_$@ is used to set specific options to ld. 998 Link target. Often, LDFLAGS_$@ is used to set specific options to ld.
995 999
996 objcopy 1000 objcopy
997 Copy binary. Uses OBJCOPYFLAGS usually specified in 1001 Copy binary. Uses OBJCOPYFLAGS usually specified in
998 arch/$(ARCH)/Makefile. 1002 arch/$(ARCH)/Makefile.
@@ -1010,10 +1014,10 @@ When kbuild executes the following steps are followed (roughly):
1010 $(obj)/setup $(obj)/bootsect: %: %.o FORCE 1014 $(obj)/setup $(obj)/bootsect: %: %.o FORCE
1011 $(call if_changed,ld) 1015 $(call if_changed,ld)
1012 1016
1013 In this example there are two possible targets, requiring different 1017 In this example, there are two possible targets, requiring different
1014 options to the linker. the linker options are specified using the 1018 options to the linker. The linker options are specified using the
1015 LDFLAGS_$@ syntax - one for each potential target. 1019 LDFLAGS_$@ syntax - one for each potential target.
1016 $(targets) are assinged all potential targets, herby kbuild knows 1020 $(targets) are assinged all potential targets, by which kbuild knows
1017 the targets and will: 1021 the targets and will:
1018 1) check for commandline changes 1022 1) check for commandline changes
1019 2) delete target during make clean 1023 2) delete target during make clean
@@ -1027,7 +1031,7 @@ When kbuild executes the following steps are followed (roughly):
1027 1031
1028--- 6.7 Custom kbuild commands 1032--- 6.7 Custom kbuild commands
1029 1033
1030 When kbuild is executing with KBUILD_VERBOSE=0 then only a shorthand 1034 When kbuild is executing with KBUILD_VERBOSE=0, then only a shorthand
1031 of a command is normally displayed. 1035 of a command is normally displayed.
1032 To enable this behaviour for custom commands kbuild requires 1036 To enable this behaviour for custom commands kbuild requires
1033 two variables to be set: 1037 two variables to be set:
@@ -1045,34 +1049,34 @@ When kbuild executes the following steps are followed (roughly):
1045 $(call if_changed,image) 1049 $(call if_changed,image)
1046 @echo 'Kernel: $@ is ready' 1050 @echo 'Kernel: $@ is ready'
1047 1051
1048 When updating the $(obj)/bzImage target the line: 1052 When updating the $(obj)/bzImage target, the line
1049 1053
1050 BUILD arch/i386/boot/bzImage 1054 BUILD arch/i386/boot/bzImage
1051 1055
1052 will be displayed with "make KBUILD_VERBOSE=0". 1056 will be displayed with "make KBUILD_VERBOSE=0".
1053 1057
1054 1058
1055--- 6.8 Preprocessing linker scripts 1059--- 6.8 Preprocessing linker scripts
1056 1060
1057 When the vmlinux image is build the linker script: 1061 When the vmlinux image is built, the linker script
1058 arch/$(ARCH)/kernel/vmlinux.lds is used. 1062 arch/$(ARCH)/kernel/vmlinux.lds is used.
1059 The script is a preprocessed variant of the file vmlinux.lds.S 1063 The script is a preprocessed variant of the file vmlinux.lds.S
1060 located in the same directory. 1064 located in the same directory.
1061 kbuild knows .lds file and includes a rule *lds.S -> *lds. 1065 kbuild knows .lds files and includes a rule *lds.S -> *lds.
1062 1066
1063 Example: 1067 Example:
1064 #arch/i386/kernel/Makefile 1068 #arch/i386/kernel/Makefile
1065 always := vmlinux.lds 1069 always := vmlinux.lds
1066 1070
1067 #Makefile 1071 #Makefile
1068 export CPPFLAGS_vmlinux.lds += -P -C -U$(ARCH) 1072 export CPPFLAGS_vmlinux.lds += -P -C -U$(ARCH)
1069 1073
1070 The assigment to $(always) is used to tell kbuild to build the 1074 The assignment to $(always) is used to tell kbuild to build the
1071 target: vmlinux.lds. 1075 target vmlinux.lds.
1072 The assignment to $(CPPFLAGS_vmlinux.lds) tell kbuild to use the 1076 The assignment to $(CPPFLAGS_vmlinux.lds) tells kbuild to use the
1073 specified options when building the target vmlinux.lds. 1077 specified options when building the target vmlinux.lds.
1074 1078
1075 When building the *.lds target kbuild used the variakles: 1079 When building the *.lds target, kbuild uses the variables:
1076 CPPFLAGS : Set in top-level Makefile 1080 CPPFLAGS : Set in top-level Makefile
1077 EXTRA_CPPFLAGS : May be set in the kbuild makefile 1081 EXTRA_CPPFLAGS : May be set in the kbuild makefile
1078 CPPFLAGS_$(@F) : Target specific flags. 1082 CPPFLAGS_$(@F) : Target specific flags.
@@ -1147,7 +1151,7 @@ The top Makefile exports the following variables:
1147 1151
1148=== 8 Makefile language 1152=== 8 Makefile language
1149 1153
1150The kernel Makefiles are designed to run with GNU Make. The Makefiles 1154The kernel Makefiles are designed to be run with GNU Make. The Makefiles
1151use only the documented features of GNU Make, but they do use many 1155use only the documented features of GNU Make, but they do use many
1152GNU extensions. 1156GNU extensions.
1153 1157
@@ -1169,10 +1173,13 @@ is the right choice.
1169Original version made by Michael Elizabeth Chastain, <mailto:mec@shout.net> 1173Original version made by Michael Elizabeth Chastain, <mailto:mec@shout.net>
1170Updates by Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de> 1174Updates by Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
1171Updates by Sam Ravnborg <sam@ravnborg.org> 1175Updates by Sam Ravnborg <sam@ravnborg.org>
1176Language QA by Jan Engelhardt <jengelh@gmx.de>
1172 1177
1173=== 10 TODO 1178=== 10 TODO
1174 1179
1175- Describe how kbuild support shipped files with _shipped. 1180- Describe how kbuild supports shipped files with _shipped.
1176- Generating offset header files. 1181- Generating offset header files.
1177- Add more variables to section 7? 1182- Add more variables to section 7?
1178 1183
1184
1185
diff --git a/Documentation/kbuild/modules.txt b/Documentation/kbuild/modules.txt
index 61fc079eb966..2e7702e94a78 100644
--- a/Documentation/kbuild/modules.txt
+++ b/Documentation/kbuild/modules.txt
@@ -1,7 +1,7 @@
1 1
2In this document you will find information about: 2In this document you will find information about:
3- how to build external modules 3- how to build external modules
4- how to make your module use kbuild infrastructure 4- how to make your module use the kbuild infrastructure
5- how kbuild will install a kernel 5- how kbuild will install a kernel
6- how to install modules in a non-standard location 6- how to install modules in a non-standard location
7 7
@@ -24,7 +24,7 @@ In this document you will find information about:
24 --- 6.1 INSTALL_MOD_PATH 24 --- 6.1 INSTALL_MOD_PATH
25 --- 6.2 INSTALL_MOD_DIR 25 --- 6.2 INSTALL_MOD_DIR
26 === 7. Module versioning & Module.symvers 26 === 7. Module versioning & Module.symvers
27 --- 7.1 Symbols fron the kernel (vmlinux + modules) 27 --- 7.1 Symbols from the kernel (vmlinux + modules)
28 --- 7.2 Symbols and external modules 28 --- 7.2 Symbols and external modules
29 --- 7.3 Symbols from another external module 29 --- 7.3 Symbols from another external module
30 === 8. Tips & Tricks 30 === 8. Tips & Tricks
@@ -36,13 +36,13 @@ In this document you will find information about:
36 36
37kbuild includes functionality for building modules both 37kbuild includes functionality for building modules both
38within the kernel source tree and outside the kernel source tree. 38within the kernel source tree and outside the kernel source tree.
39The latter is usually referred to as external modules and is used 39The latter is usually referred to as external or "out-of-tree"
40both during development and for modules that are not planned to be 40modules and is used both during development and for modules that
41included in the kernel tree. 41are not planned to be included in the kernel tree.
42 42
43What is covered within this file is mainly information to authors 43What is covered within this file is mainly information to authors
44of modules. The author of an external modules should supply 44of modules. The author of an external module should supply
45a makefile that hides most of the complexity so one only has to type 45a makefile that hides most of the complexity, so one only has to type
46'make' to build the module. A complete example will be present in 46'make' to build the module. A complete example will be present in
47chapter 4, "Creating a kbuild file for an external module". 47chapter 4, "Creating a kbuild file for an external module".
48 48
@@ -63,14 +63,15 @@ when building an external module.
63 For the running kernel use: 63 For the running kernel use:
64 make -C /lib/modules/`uname -r`/build M=`pwd` 64 make -C /lib/modules/`uname -r`/build M=`pwd`
65 65
66 For the above command to succeed the kernel must have been built with 66 For the above command to succeed, the kernel must have been
67 modules enabled. 67 built with modules enabled.
68 68
69 To install the modules that were just built: 69 To install the modules that were just built:
70 70
71 make -C <path-to-kernel> M=`pwd` modules_install 71 make -C <path-to-kernel> M=`pwd` modules_install
72 72
73 More complex examples later, the above should get you going. 73 More complex examples will be shown later, the above should
74 be enough to get you started.
74 75
75--- 2.2 Available targets 76--- 2.2 Available targets
76 77
@@ -89,13 +90,13 @@ when building an external module.
89 Same functionality as if no target was specified. 90 Same functionality as if no target was specified.
90 See description above. 91 See description above.
91 92
92 make -C $KDIR M=$PWD modules_install 93 make -C $KDIR M=`pwd` modules_install
93 Install the external module(s). 94 Install the external module(s).
94 Installation default is in /lib/modules/<kernel-version>/extra, 95 Installation default is in /lib/modules/<kernel-version>/extra,
95 but may be prefixed with INSTALL_MOD_PATH - see separate 96 but may be prefixed with INSTALL_MOD_PATH - see separate
96 chapter. 97 chapter.
97 98
98 make -C $KDIR M=$PWD clean 99 make -C $KDIR M=`pwd` clean
99 Remove all generated files for the module - the kernel 100 Remove all generated files for the module - the kernel
100 source directory is not modified. 101 source directory is not modified.
101 102
@@ -129,29 +130,28 @@ when building an external module.
129 130
130 To make sure the kernel contains the information required to 131 To make sure the kernel contains the information required to
131 build external modules the target 'modules_prepare' must be used. 132 build external modules the target 'modules_prepare' must be used.
132 'module_prepare' solely exists as a simple way to prepare 133 'module_prepare' exists solely as a simple way to prepare
133 a kernel for building external modules. 134 a kernel source tree for building external modules.
134 Note: modules_prepare will not build Module.symvers even if 135 Note: modules_prepare will not build Module.symvers even if
135 CONFIG_MODULEVERSIONING is set. 136 CONFIG_MODULEVERSIONING is set. Therefore a full kernel build
136 Therefore a full kernel build needs to be executed to make 137 needs to be executed to make module versioning work.
137 module versioning work.
138 138
139--- 2.5 Building separate files for a module 139--- 2.5 Building separate files for a module
140 It is possible to build single files which is part of a module. 140 It is possible to build single files which are part of a module.
141 This works equal for the kernel, a module and even for external 141 This works equally well for the kernel, a module and even for
142 modules. 142 external modules.
143 Examples (module foo.ko, consist of bar.o, baz.o): 143 Examples (module foo.ko, consist of bar.o, baz.o):
144 make -C $KDIR M=`pwd` bar.lst 144 make -C $KDIR M=`pwd` bar.lst
145 make -C $KDIR M=`pwd` bar.o 145 make -C $KDIR M=`pwd` bar.o
146 make -C $KDIR M=`pwd` foo.ko 146 make -C $KDIR M=`pwd` foo.ko
147 make -C $KDIR M=`pwd` / 147 make -C $KDIR M=`pwd` /
148 148
149 149
150=== 3. Example commands 150=== 3. Example commands
151 151
152This example shows the actual commands to be executed when building 152This example shows the actual commands to be executed when building
153an external module for the currently running kernel. 153an external module for the currently running kernel.
154In the example below the distribution is supposed to use the 154In the example below, the distribution is supposed to use the
155facility to locate output files for a kernel compile in a different 155facility to locate output files for a kernel compile in a different
156directory than the kernel source - but the examples will also work 156directory than the kernel source - but the examples will also work
157when the source and the output files are mixed in the same directory. 157when the source and the output files are mixed in the same directory.
@@ -170,14 +170,14 @@ the following commands to build the module:
170 O=/lib/modules/`uname-r`/build \ 170 O=/lib/modules/`uname-r`/build \
171 M=`pwd` 171 M=`pwd`
172 172
173Then to install the module use the following command: 173Then, to install the module use the following command:
174 174
175 make -C /usr/src/`uname -r`/source \ 175 make -C /usr/src/`uname -r`/source \
176 O=/lib/modules/`uname-r`/build \ 176 O=/lib/modules/`uname-r`/build \
177 M=`pwd` \ 177 M=`pwd` \
178 modules_install 178 modules_install
179 179
180If one looks closely you will see that this is the same commands as 180If you look closely you will see that this is the same command as
181listed before - with the directories spelled out. 181listed before - with the directories spelled out.
182 182
183The above are rather long commands, and the following chapter 183The above are rather long commands, and the following chapter
@@ -230,7 +230,7 @@ following files:
230 230
231 endif 231 endif
232 232
233 In example 1 the check for KERNELRELEASE is used to separate 233 In example 1, the check for KERNELRELEASE is used to separate
234 the two parts of the Makefile. kbuild will only see the two 234 the two parts of the Makefile. kbuild will only see the two
235 assignments whereas make will see everything except the two 235 assignments whereas make will see everything except the two
236 kbuild assignments. 236 kbuild assignments.
@@ -255,7 +255,7 @@ following files:
255 echo "X" > 8123_bin_shipped 255 echo "X" > 8123_bin_shipped
256 256
257 257
258 In example 2 we are down to two fairly simple files and for simple 258 In example 2, we are down to two fairly simple files and for simple
259 files as used in this example the split is questionable. But some 259 files as used in this example the split is questionable. But some
260 external modules use Makefiles of several hundred lines and here it 260 external modules use Makefiles of several hundred lines and here it
261 really pays off to separate the kbuild part from the rest. 261 really pays off to separate the kbuild part from the rest.
@@ -282,9 +282,9 @@ following files:
282 282
283 endif 283 endif
284 284
285 The trick here is to include the Kbuild file from Makefile so 285 The trick here is to include the Kbuild file from Makefile, so
286 if an older version of kbuild picks up the Makefile the Kbuild 286 if an older version of kbuild picks up the Makefile, the Kbuild
287 file will be included. 287 file will be included.
288 288
289--- 4.2 Binary blobs included in a module 289--- 4.2 Binary blobs included in a module
290 290
@@ -301,18 +301,19 @@ following files:
301 obj-m := 8123.o 301 obj-m := 8123.o
302 8123-y := 8123_if.o 8123_pci.o 8123_bin.o 302 8123-y := 8123_if.o 8123_pci.o 8123_bin.o
303 303
304 In example 4 there is no distinction between the ordinary .c/.h files 304 In example 4, there is no distinction between the ordinary .c/.h files
305 and the binary file. But kbuild will pick up different rules to create 305 and the binary file. But kbuild will pick up different rules to create
306 the .o file. 306 the .o file.
307 307
308 308
309=== 5. Include files 309=== 5. Include files
310 310
311Include files are a necessity when a .c file uses something from another .c 311Include files are a necessity when a .c file uses something from other .c
312files (not strictly in the sense of .c but if good programming practice is 312files (not strictly in the sense of C, but if good programming practice is
313used). Any module that consist of more than one .c file will have a .h file 313used). Any module that consists of more than one .c file will have a .h file
314for one of the .c files. 314for one of the .c files.
315- If the .h file only describes a module internal interface then the .h file 315
316- If the .h file only describes a module internal interface, then the .h file
316 shall be placed in the same directory as the .c files. 317 shall be placed in the same directory as the .c files.
317- If the .h files describe an interface used by other parts of the kernel 318- If the .h files describe an interface used by other parts of the kernel
318 located in different directories, the .h files shall be located in 319 located in different directories, the .h files shall be located in
@@ -323,11 +324,11 @@ under include/ such as include/scsi. Another exception is arch-specific
323.h files which are located under include/asm-$(ARCH)/*. 324.h files which are located under include/asm-$(ARCH)/*.
324 325
325External modules have a tendency to locate include files in a separate include/ 326External modules have a tendency to locate include files in a separate include/
326directory and therefore needs to deal with this in their kbuild file. 327directory and therefore need to deal with this in their kbuild file.
327 328
328--- 5.1 How to include files from the kernel include dir 329--- 5.1 How to include files from the kernel include dir
329 330
330 When a module needs to include a file from include/linux/ then one 331 When a module needs to include a file from include/linux/, then one
331 just uses: 332 just uses:
332 333
333 #include <linux/modules.h> 334 #include <linux/modules.h>
@@ -348,7 +349,7 @@ directory and therefore needs to deal with this in their kbuild file.
348 The trick here is to use either EXTRA_CFLAGS (take effect for all .c 349 The trick here is to use either EXTRA_CFLAGS (take effect for all .c
349 files) or CFLAGS_$F.o (take effect only for a single file). 350 files) or CFLAGS_$F.o (take effect only for a single file).
350 351
351 In our example if we move 8123_if.h to a subdirectory named include/ 352 In our example, if we move 8123_if.h to a subdirectory named include/
352 the resulting Kbuild file would look like: 353 the resulting Kbuild file would look like:
353 354
354 --> filename: Kbuild 355 --> filename: Kbuild
@@ -362,19 +363,19 @@ directory and therefore needs to deal with this in their kbuild file.
362 363
363--- 5.3 External modules using several directories 364--- 5.3 External modules using several directories
364 365
365 If an external module does not follow the usual kernel style but 366 If an external module does not follow the usual kernel style, but
366 decide to spread files over several directories then kbuild can 367 decides to spread files over several directories, then kbuild can
367 support this too. 368 handle this too.
368 369
369 Consider the following example: 370 Consider the following example:
370 371
371 | 372 |
372 +- src/complex_main.c 373 +- src/complex_main.c
373 | +- hal/hardwareif.c 374 | +- hal/hardwareif.c
374 | +- hal/include/hardwareif.h 375 | +- hal/include/hardwareif.h
375 +- include/complex.h 376 +- include/complex.h
376 377
377 To build a single module named complex.ko we then need the following 378 To build a single module named complex.ko, we then need the following
378 kbuild file: 379 kbuild file:
379 380
380 Kbuild: 381 Kbuild:
@@ -387,12 +388,12 @@ directory and therefore needs to deal with this in their kbuild file.
387 388
388 389
389 kbuild knows how to handle .o files located in another directory - 390 kbuild knows how to handle .o files located in another directory -
390 although this is NOT reccommended practice. The syntax is to specify 391 although this is NOT recommended practice. The syntax is to specify
391 the directory relative to the directory where the Kbuild file is 392 the directory relative to the directory where the Kbuild file is
392 located. 393 located.
393 394
394 To find the .h files we have to explicitly tell kbuild where to look 395 To find the .h files, we have to explicitly tell kbuild where to look
395 for the .h files. When kbuild executes current directory is always 396 for the .h files. When kbuild executes, the current directory is always
396 the root of the kernel tree (argument to -C) and therefore we have to 397 the root of the kernel tree (argument to -C) and therefore we have to
397 tell kbuild how to find the .h files using absolute paths. 398 tell kbuild how to find the .h files using absolute paths.
398 $(src) will specify the absolute path to the directory where the 399 $(src) will specify the absolute path to the directory where the
@@ -412,7 +413,7 @@ External modules are installed in the directory:
412 413
413--- 6.1 INSTALL_MOD_PATH 414--- 6.1 INSTALL_MOD_PATH
414 415
415 Above are the default directories, but as always some level of 416 Above are the default directories, but as always, some level of
416 customization is possible. One can prefix the path using the variable 417 customization is possible. One can prefix the path using the variable
417 INSTALL_MOD_PATH: 418 INSTALL_MOD_PATH:
418 419
@@ -420,17 +421,17 @@ External modules are installed in the directory:
420 => Install dir: /frodo/lib/modules/$(KERNELRELEASE)/kernel 421 => Install dir: /frodo/lib/modules/$(KERNELRELEASE)/kernel
421 422
422 INSTALL_MOD_PATH may be set as an ordinary shell variable or as in the 423 INSTALL_MOD_PATH may be set as an ordinary shell variable or as in the
423 example above be specified on the command line when calling make. 424 example above, can be specified on the command line when calling make.
424 INSTALL_MOD_PATH has effect both when installing modules included in 425 INSTALL_MOD_PATH has effect both when installing modules included in
425 the kernel as well as when installing external modules. 426 the kernel as well as when installing external modules.
426 427
427--- 6.2 INSTALL_MOD_DIR 428--- 6.2 INSTALL_MOD_DIR
428 429
429 When installing external modules they are default installed in a 430 When installing external modules they are by default installed to a
430 directory under /lib/modules/$(KERNELRELEASE)/extra, but one may wish 431 directory under /lib/modules/$(KERNELRELEASE)/extra, but one may wish
431 to locate modules for a specific functionality in a separate 432 to locate modules for a specific functionality in a separate
432 directory. For this purpose one can use INSTALL_MOD_DIR to specify an 433 directory. For this purpose, one can use INSTALL_MOD_DIR to specify an
433 alternative name than 'extra'. 434 alternative name to 'extra'.
434 435
435 $ make INSTALL_MOD_DIR=gandalf -C KERNELDIR \ 436 $ make INSTALL_MOD_DIR=gandalf -C KERNELDIR \
436 M=`pwd` modules_install 437 M=`pwd` modules_install
@@ -444,16 +445,16 @@ Module versioning is enabled by the CONFIG_MODVERSIONS tag.
444Module versioning is used as a simple ABI consistency check. The Module 445Module versioning is used as a simple ABI consistency check. The Module
445versioning creates a CRC value of the full prototype for an exported symbol and 446versioning creates a CRC value of the full prototype for an exported symbol and
446when a module is loaded/used then the CRC values contained in the kernel are 447when a module is loaded/used then the CRC values contained in the kernel are
447compared with similar values in the module. If they are not equal then the 448compared with similar values in the module. If they are not equal, then the
448kernel refuses to load the module. 449kernel refuses to load the module.
449 450
450Module.symvers contains a list of all exported symbols from a kernel build. 451Module.symvers contains a list of all exported symbols from a kernel build.
451 452
452--- 7.1 Symbols fron the kernel (vmlinux + modules) 453--- 7.1 Symbols fron the kernel (vmlinux + modules)
453 454
454 During a kernel build a file named Module.symvers will be generated. 455 During a kernel build, a file named Module.symvers will be generated.
455 Module.symvers contains all exported symbols from the kernel and 456 Module.symvers contains all exported symbols from the kernel and
456 compiled modules. For each symbols the corresponding CRC value 457 compiled modules. For each symbols, the corresponding CRC value
457 is stored too. 458 is stored too.
458 459
459 The syntax of the Module.symvers file is: 460 The syntax of the Module.symvers file is:
@@ -461,27 +462,27 @@ Module.symvers contains a list of all exported symbols from a kernel build.
461 Sample: 462 Sample:
462 0x2d036834 scsi_remove_host drivers/scsi/scsi_mod 463 0x2d036834 scsi_remove_host drivers/scsi/scsi_mod
463 464
464 For a kernel build without CONFIG_MODVERSIONING enabled the crc 465 For a kernel build without CONFIG_MODVERSIONS enabled, the crc
465 would read: 0x00000000 466 would read: 0x00000000
466 467
467 Module.symvers serve two purposes. 468 Module.symvers serves two purposes:
468 1) It list all exported symbols both from vmlinux and all modules 469 1) It lists all exported symbols both from vmlinux and all modules
469 2) It list CRC if CONFIG_MODVERSION is enabled 470 2) It lists the CRC if CONFIG_MODVERSIONS is enabled
470 471
471--- 7.2 Symbols and external modules 472--- 7.2 Symbols and external modules
472 473
473 When building an external module the build system needs access to 474 When building an external module, the build system needs access to
474 the symbols from the kernel to check if all external symbols are 475 the symbols from the kernel to check if all external symbols are
475 defined. This is done in the MODPOST step and to obtain all 476 defined. This is done in the MODPOST step and to obtain all
476 symbols modpost reads Module.symvers from the kernel. 477 symbols, modpost reads Module.symvers from the kernel.
477 If a Module.symvers file is present in the directory where 478 If a Module.symvers file is present in the directory where
478 the external module is being build this file will be read too. 479 the external module is being built, this file will be read too.
479 During the MODPOST step a new Module.symvers file will be written 480 During the MODPOST step, a new Module.symvers file will be written
480 containing all exported symbols that was not defined in the kernel. 481 containing all exported symbols that were not defined in the kernel.
481 482
482--- 7.3 Symbols from another external module 483--- 7.3 Symbols from another external module
483 484
484 Sometimes one external module uses exported symbols from another 485 Sometimes, an external module uses exported symbols from another
485 external module. Kbuild needs to have full knowledge on all symbols 486 external module. Kbuild needs to have full knowledge on all symbols
486 to avoid spitting out warnings about undefined symbols. 487 to avoid spitting out warnings about undefined symbols.
487 Two solutions exist to let kbuild know all symbols of more than 488 Two solutions exist to let kbuild know all symbols of more than
@@ -490,15 +491,15 @@ Module.symvers contains a list of all exported symbols from a kernel build.
490 impractical in certain situations. 491 impractical in certain situations.
491 492
492 Use a top-level Kbuild file 493 Use a top-level Kbuild file
493 If you have two modules: 'foo', 'bar' and 'foo' needs symbols 494 If you have two modules: 'foo' and 'bar', and 'foo' needs
494 from 'bar' then one can use a common top-level kbuild file so 495 symbols from 'bar', then one can use a common top-level kbuild
495 both modules are compiled in same build. 496 file so both modules are compiled in same build.
496 497
497 Consider following directory layout: 498 Consider following directory layout:
498 ./foo/ <= contains the foo module 499 ./foo/ <= contains the foo module
499 ./bar/ <= contains the bar module 500 ./bar/ <= contains the bar module
500 The top-level Kbuild file would then look like: 501 The top-level Kbuild file would then look like:
501 502
502 #./Kbuild: (this file may also be named Makefile) 503 #./Kbuild: (this file may also be named Makefile)
503 obj-y := foo/ bar/ 504 obj-y := foo/ bar/
504 505
@@ -509,23 +510,23 @@ Module.symvers contains a list of all exported symbols from a kernel build.
509 knowledge on symbols from both modules. 510 knowledge on symbols from both modules.
510 511
511 Use an extra Module.symvers file 512 Use an extra Module.symvers file
512 When an external module is build a Module.symvers file is 513 When an external module is built, a Module.symvers file is
513 generated containing all exported symbols which are not 514 generated containing all exported symbols which are not
514 defined in the kernel. 515 defined in the kernel.
515 To get access to symbols from module 'bar' one can copy the 516 To get access to symbols from module 'bar', one can copy the
516 Module.symvers file from the compilation of the 'bar' module 517 Module.symvers file from the compilation of the 'bar' module
517 to the directory where the 'foo' module is build. 518 to the directory where the 'foo' module is built.
518 During the module build kbuild will read the Module.symvers 519 During the module build, kbuild will read the Module.symvers
519 file in the directory of the external module and when the 520 file in the directory of the external module and when the
520 build is finished a new Module.symvers file is created 521 build is finished, a new Module.symvers file is created
521 containing the sum of all symbols defined and not part of the 522 containing the sum of all symbols defined and not part of the
522 kernel. 523 kernel.
523 524
524=== 8. Tips & Tricks 525=== 8. Tips & Tricks
525 526
526--- 8.1 Testing for CONFIG_FOO_BAR 527--- 8.1 Testing for CONFIG_FOO_BAR
527 528
528 Modules often needs to check for certain CONFIG_ options to decide if 529 Modules often need to check for certain CONFIG_ options to decide if
529 a specific feature shall be included in the module. When kbuild is used 530 a specific feature shall be included in the module. When kbuild is used
530 this is done by referencing the CONFIG_ variable directly. 531 this is done by referencing the CONFIG_ variable directly.
531 532
@@ -537,7 +538,7 @@ Module.symvers contains a list of all exported symbols from a kernel build.
537 538
538 External modules have traditionally used grep to check for specific 539 External modules have traditionally used grep to check for specific
539 CONFIG_ settings directly in .config. This usage is broken. 540 CONFIG_ settings directly in .config. This usage is broken.
540 As introduced before external modules shall use kbuild when building 541 As introduced before, external modules shall use kbuild when building
541 and therefore can use the same methods as in-kernel modules when testing 542 and therefore can use the same methods as in-kernel modules when
542 for CONFIG_ definitions. 543 testing for CONFIG_ definitions.
543 544
diff --git a/Documentation/sparse.txt b/Documentation/sparse.txt
index 5a311c38dd1a..f9c99c9a54f9 100644
--- a/Documentation/sparse.txt
+++ b/Documentation/sparse.txt
@@ -69,10 +69,10 @@ recompiled, or use "make C=2" to run sparse on the files whether they need to
69be recompiled or not. The latter is a fast way to check the whole tree if you 69be recompiled or not. The latter is a fast way to check the whole tree if you
70have already built it. 70have already built it.
71 71
72The optional make variable CF can be used to pass arguments to sparse. The 72The optional make variable CHECKFLAGS can be used to pass arguments to sparse.
73build system passes -Wbitwise to sparse automatically. To perform endianness 73The build system passes -Wbitwise to sparse automatically. To perform
74checks, you may define __CHECK_ENDIAN__: 74endianness checks, you may define __CHECK_ENDIAN__:
75 75
76 make C=2 CF="-D__CHECK_ENDIAN__" 76 make C=2 CHECKFLAGS="-D__CHECK_ENDIAN__"
77 77
78These checks are disabled by default as they generate a host of warnings. 78These checks are disabled by default as they generate a host of warnings.