Linux Kernel Makefiles
来源：互联网 发布：50部网络禁书下载 编辑：程序博客网 时间：2024/05/21 06:51
Linux Kernel Makefiles
This document describes the Linux kernel Makefiles.
=== Table of Contents
=== 1 Overview
=== 2 Who does what
=== 3 The kbuild files
=== 4 Host Program support
=== 5 Kbuild clean infrastructure
=== 6 Architecture Makefiles
=== 7 Kbuild syntax for exported headers
--- 7.1 header-y
--- 7.2 objhdr-y
--- 7.3 destination-y
--- 7.4 unifdef-y (deprecated)
=== 8 Kbuild Variables
=== 9 Makefile language
=== 10 Credits
=== 11 TODO
=== 1 Overview
The Makefiles have five parts:
Makefile the top Makefile.
.config the kernel configuration file.
arch/$(ARCH)/Makefile the arch Makefile.
scripts/Makefile.* common rules etc. for all kbuildMakefiles.
kbuild Makefiles there are about 500 of these.
The top Makefile reads the .config file, which comes from thekernel
configuration process.
The top Makefile is responsible for building two majorproducts: vmlinux
(the resident kernel image) and modules (any modulefiles).
It builds these goals by recursively descending into thesubdirectories of
the kernel source tree.
The list of subdirectories which are visited depends upon thekernel
configuration. The top Makefile textually includes an archMakefile
with the name arch/$(ARCH)/Makefile. The arch Makefilesupplies
architecture-specific information to the top Makefile.
Each subdirectory has a kbuild Makefile which carries out thecommands
passed down from above. The kbuild Makefile uses informationfrom the
.config file to construct various file lists used by kbuild tobuild
any built-in or modular targets.
scripts/Makefile.* contains all the definitions/rules etc.that
are used to build the kernel based on the kbuildmakefiles.
=== 2 Who does what
People have four different relationships with the kernelMakefiles.
*Users* are people who build kernels. Thesepeople type commands such as
"make menuconfig" or "make". They usually donot read or edit
any kernel Makefiles (or any other source files).
*Normal developers* are people who work on features such asdevice
drivers, file systems, and network protocols. These people need to
maintain the kbuild Makefiles for the subsystem they are
working on. In order to do this effectively,they need some overall
knowledge about the kernel Makefiles, plus detailed knowledgeabout the
public interface for kbuild.
*Arch developers* are people who work on an entirearchitecture, such
as sparc or ia64. Arch developers need toknow about the arch Makefile
as well as kbuild Makefiles.
*Kbuild developers* are people who work on the kernel buildsystem itself.
These people need to know about all aspects of the kernelMakefiles.
This document is aimed towards normal developers and archdevelopers.
=== 3 The kbuild files
Most Makefiles within the kernel are kbuild Makefiles that usethe
kbuild infrastructure. This chapter introduces the syntax usedin the
kbuild makefiles.
The preferred name for the kbuild files are 'Makefile' but'Kbuild' can
be used and if both a 'Makefile' and a 'Kbuild' file exists,then the 'Kbuild'
file will be used.
Section 3.1 "Goal definitions" is a quick intro, furtherchapters provide
more details, with real examples.
--- 3.1 Goal definitions
Goal definitions are the main part (heart) of the kbuildMakefile.
These lines define the files to be built, any specialcompilation
options, and any subdirectories to be enteredrecursively.
The most simple kbuild makefile contains one line:
Example:
obj-y += foo.o
This tells kbuild that there is one object in that directory,named
foo.o. foo.o will be built from foo.c or foo.S.
If foo.o shall be built as a module, the variable obj-m isused.
Therefore the following pattern is often used:
Example:
obj-$(CONFIG_FOO) += foo.o
$(CONFIG_FOO) evaluates to either y (for built-in) or m (formodule).
If CONFIG_FOO is neither y nor m, then the file will not becompiled
nor linked.
--- 3.2 Built-in object goals - obj-y
The kbuild Makefile specifies object files for vmlinux
in the $(obj-y) lists. These lists depend onthe kernel
configuration.
Kbuild compiles all the $(obj-y) files. Itthen calls
"$(LD) -r" to merge these files into one built-in.ofile.
built-in.o is later linked into vmlinux by the parentMakefile.
The order of files in $(obj-y) is significant. Duplicates in
the lists are allowed: the first instance will be linkedinto
built-in.o and succeeding instances will be ignored.
Link order is significant, because certain functions
(module_init() / __initcall) will be called during boot inthe
order they appear. So keep in mind that changing thelink
order may e.g. change the order in which your SCSI
controllers are detected, and thus your disks arerenumbered.
Example:
#drivers/isdn/i4l/Makefile
# Makefile for the kernel ISDN subsystem and devicedrivers.
# Each configuration option enables a list of files.
obj-$(CONFIG_ISDN) += isdn.o
obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
--- 3.3 Loadable module goals - obj-m
$(obj-m) specify object files which are built asloadable
kernel modules.
A module may be built from one source file or severalsource
files. In the case of one source file, the kbuildmakefile
simply adds the file to $(obj-m).
Example:
#drivers/isdn/i4l/Makefile
obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o
Note: In this example $(CONFIG_ISDN_PPP_BSDCOMP) evaluates to'm'
If a kernel module is built from several source files, youspecify
that you want to build a module in the same way asabove.
Kbuild needs to know which the parts that you want to buildyour
module from, so you have to tell it by setting an
$(<module_name>-objs)variable.
Example:
#drivers/isdn/i4l/Makefile
obj-$(CONFIG_ISDN) += isdn.o
isdn-objs := isdn_net_lib.o isdn_v110.o isdn_common.o
In this example, the module name will be isdn.o. Kbuildwill
compile the objects listed in $(isdn-objs) and then run
"$(LD) -r" on the list of these files to generateisdn.o.
Kbuild recognises objects used for composite objects by thesuffix
-objs, and the suffix -y. This allows the Makefiles touse
the value of a CONFIG_ symbol to determine if an object ispart
of a composite object.
Example:
#fs/ext2/Makefile
ext2-y :=balloc.o bitmap.o
In this example, xattr.o is only part of the compositeobject
ext2.o if $(CONFIG_EXT2_FS_XATTR) evaluates to 'y'.
Note: Of course, when you are building objects into thekernel,
the syntax above will also work. So, if you haveCONFIG_EXT2_FS=y,
kbuild will build an ext2.o file for you out of theindividual
parts and then link this into built-in.o, as you wouldexpect.
--- 3.4 Objects which export symbols
No special notation is required in the makefiles for
modules exporting symbols.
--- 3.5 Library file goals - lib-y
Objects listed with obj-* are used for modules, or
combined in a built-in.o for that specific directory.
There is also the possibility to list objects that will
be included in a library, lib.a.
All objects listed with lib-y are combined in a single
library for that directory.
Objects that are listed in obj-y and additionally listedin
lib-y will not be included in the library, since theywill
be accessible anyway.
For consistency, objects listed in lib-m will be included inlib.a.
Note that the same kbuild makefile may list files to bebuilt-in
and to be part of a library. Therefore the samedirectory
may contain both a built-in.o and a lib.a file.
Example:
#arch/i386/lib/Makefile
lib-y := checksum.odelay.o
This will create a library lib.a based on checksum.o anddelay.o.
For kbuild to actually recognize that there is a lib.a beingbuilt,
the directory shall be listed in libs-y.
See also "6.3 List directories to visit whendescending".
Use of lib-y is normally restricted to lib/ andarch/*/lib.
--- 3.6 Descending down in directories
A Makefile is only responsible for building objects in itsown
directory. Files in subdirectories should be taken care ofby
Makefiles in these subdirs. The build system willautomatically
invoke make recursively in subdirectories, provided you let itknow of
them.
To do so, obj-y and obj-m are used.
ext2 lives in a separate directory, and the Makefile presentin fs/
tells kbuild to descend down using the followingassignment.
Example:
#fs/Makefile
obj-$(CONFIG_EXT2_FS) += ext2/
If CONFIG_EXT2_FS is set to either 'y' (built-in) or 'm'(modular)
the corresponding obj- variable will be set, and kbuild willdescend
down in the ext2 directory.
Kbuild only uses this information to decide that it needs tovisit
the directory, it is the Makefile in the subdirectorythat
specifies what is modules and what is built-in.
It is good practice to use a CONFIG_ variable when assigningdirectory
names. This allows kbuild to totally skip the directory ifthe
corresponding CONFIG_ option is neither 'y' nor 'm'.
--- 3.7 Compilation flags
The three flags listed above applies only to the kbuildmakefile
where they are assigned. They are used for all thenormal
cc, as and ld invocation happenign during a recursivebuild.
Note: Flags with the same behaviour were previouslynamed:
EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS.
They are yet supported but their use are deprecated.
ccflags-y specifies options for compiling C files with$(CC).
Example:
# drivers/sound/emu10k1/Makefile
ccflags-y += -I$(obj)
ccflags-$(DEBUG) += -DEMU10K1_DEBUG
This variable is necessary because the top Makefile ownsthe
variable $(KBUILD_CFLAGS) and uses it for compilation flagsfor the
entire tree.
asflags-y is a similar string for per-directory options
when compiling assembly language source.
Example:
#arch/x86_64/kernel/Makefile
asflags-y := -traditional
ldflags-y is a string for per-directory options to$(LD).
Example:
#arch/m68k/fpsp040/Makefile
ldflags-y := -x
The two flags listed above are similar to ccflags-y andas-falgs-y.
The difference is that the subdir- variants has effect for thekbuild
file where tey are present and all subdirectories.
Options specified using subdir-* are added to the commandlinebefore
the options specified using the non-subdir variants.
Example:
subdir-ccflags-y := -Werror
CFLAGS_$@ and AFLAGS_$@ only apply to commands incurrent
kbuild makefile.
$(CFLAGS_$@) specifies per-file options for $(CC). The $@
part has a literal value which specifies the file that it isfor.
Example:
# drivers/scsi/Makefile
CFLAGS_aha152x.o = -DAHA152X_STAT-DAUTOCONF
CFLAGS_gdth.o = #-DDEBUG_GDTH=2 -D__SERIAL__ -D__COM2__ \
CFLAGS_seagate.o = -DARBITRATE -DPARITY-DSEAGATE_USE_ASM
These three lines specify compilation flags foraha152x.o,
gdth.o, and seagate.o
$(AFLAGS_$@) is a similar feature for source files inassembly
languages.
Example:
# arch/arm/kernel/Makefile
AFLAGS_head-armv.o := -DTEXTADDR=$(TEXTADDR)-traditional
AFLAGS_head-armo.o := -DTEXTADDR=$(TEXTADDR)-traditional
--- 3.9 Dependency tracking
Kbuild tracks dependencies on the following:
1) All prerequisite files (both *.c and *.h)
2) CONFIG_ options used in all prerequisite files
3) Command-line used to compile target
Thus, if you change an option to $(CC) all affected fileswill
be re-compiled.
--- 3.10 Special Rules
Special rules are used when the kbuild infrastructuredoes
not provide the required support. A typical example is
header files generated during the build process.
Another example are the architecture-specific Makefileswhich
need special rules to prepare boot images etc.
Special rules are written as normal Make rules.
Kbuild is not executing in the directory where the Makefileis
located, so all special rules shall provide a relative
path to prerequisite files and target files.
Two variables are used when defining special rules:
$(src) is a relative path which points to the directory
where the Makefile is located. Always use $(src) when
referring to files located in the src tree.
$(obj) is a relative path which points to the directory
where the target is saved. Always use $(obj) when
referring to generated files.
Example:
#drivers/scsi/Makefile
$(obj)/53c8xx_d.h: $(src)/53c7,8xx.scr$(src)/script_asm.pl
$(CPP) -DCHIP=810 - < $< | ...$(src)/script_asm.pl
This is a special rule, following the normal syntax
required by make.
The target file depends on two prerequisite files.References
to the target file are prefixed with $(obj), references
to prerequisites are referenced with $(src) (because they arenot
generated files).
echoing information to user in a rule is often a goodpractice
but when execution "make -s" one does not expect to see anyoutput
except for warnings/errors.
To support this kbuild define $(kecho) which will echo outthe
text following $(kecho) to stdout except if "make -s" isused.
Example:
#arch/blackfin/boot/Makefile
$(obj)/vmImage: $(obj)/vmlinux.gz
$(call if_changed,uimage)
@$(kecho) 'Kernel: $@ is ready'
--- 3.11 $(CC) support functions
The kernel may be built with several different versionsof
$(CC), each supporting a unique set of features andoptions.
kbuild provide basic support to check for valid options for$(CC).
$(CC) is usually the gcc compiler, but other alternativesare
available.
as-option is used to check if $(CC) -- when used tocompile
assembler (*.S) files -- supports the given option. Anoptional
second option may be specified if the first option is notsupported.
Example:
#arch/sh/Makefile
cflags-y += $(call as-option,-Wa$(comma)-isa=$(isa-y),)
In the above example, cflags-y will be assigned theoption
-Wa$(comma)-isa=$(isa-y) if it is supported by $(CC).
The second argument is optional, and if supplied will beused
if first argument is not supported.
ld-option is used to check if $(CC) when used to link objectfiles
supports the given option. An optionalsecond option may be
specified if first option are not supported.
Example:
#arch/i386/kernel/Makefile
vsyscall-flags += $(call ld-option,-Wl$(comma)--hash-style=sysv)
In the above example, vsyscall-flags will be assigned theoption
-Wl$(comma)--hash-style=sysv if it is supported by$(CC).
The second argument is optional, and if supplied will beused
if first argument is not supported.
as-instr checks if the assembler reports a specificinstruction
and then outputs either option1 or option2
C escapes are supported in the test instruction
Note: as-instr-option uses KBUILD_AFLAGS for $(AS)options
cc-option is used to check if $(CC) supports a given option,and not
supported to use an optional second option.
Example:
#arch/i386/Makefile
cflags-y += $(callcc-option,-march=pentium-mmx,-march=i586)
In the above example, cflags-y will be assigned theoption
-march=pentium-mmx if supported by $(CC), otherwise-march=i586.
The second argument to cc-option is optional, and ifomitted,
cflags-y will be assigned no value if first option is notsupported.
Note: cc-option uses KBUILD_CFLAGS for $(CC) options
cc-option-yn is used to check if gcc supports a givenoption
and return 'y' if supported, otherwise 'n'.
Example:
#arch/ppc/Makefile
biarch := $(call cc-option-yn, -m32)
aflags-$(biarch) += -a32
cflags-$(biarch) += -m32
In the above example, $(biarch) is set to y if $(CC) supportsthe -m32
option. When $(biarch) equals 'y', the expanded variables$(aflags-y)
and $(cflags-y) will be assigned the values -a32 and-m32,
respectively.
Note: cc-option-yn uses KBUILD_CFLAGS for $(CC) options
gcc versions >= 3.0 changed the type of optionsused to specify
alignment of functions, loops etc. $(cc-option-align), whenused
as prefix to the align options, will select the rightprefix:
gcc < 3.00
cc-option-align = -malign
gcc >= 3.00
cc-option-align = -falign
Example:
KBUILD_CFLAGS += $(cc-option-align)-functions=4
In the above example, the option -falign-functions=4 is usedfor
gcc >= 3.00. For gcc < 3.00,-malign-functions=4 is used.
Note: cc-option-align uses KBUILD_CFLAGS for $(CC)options
cc-version returns a numerical version of the $(CC) compilerversion.
The format is<major><minor>where both are two digits. So for example
gcc 3.41 would return 0341.
cc-version is useful when a specific $(CC) version is faultyin one
area, for example -mregparm=3 was broken in some gccversions
even though the option was accepted by gcc.
Example:
#arch/i386/Makefile
cflags-y += $(shell \
if [ $(call cc-version) -ge 0300 ] ; then \
echo "-mregparm=3"; fi ;)
In the above example, -mregparm=3 is only used for gcc versiongreater
than or equal to gcc 3.0.
cc-ifversion tests the version of $(CC) and equals lastargument if
version expression is true.
Example:
#fs/reiserfs/Makefile
ccflags-y := $(call cc-ifversion, -lt, 0402, -O1)
In this example, ccflags-y will be assigned the value -O1 ifthe
$(CC) version is less than 4.2.
cc-ifversion takes all the shell operators:
-eq, -ne, -lt, -le, -gt, and -ge
The third parameter may be a text as in this example, but itmay also
be an expanded variable or a macro.
cc-fullversion is useful when the exact version of gcc isneeded.
One typical use-case is when a specific GCC version isbroken.
cc-fullversion points out a more specific version thancc-version does.
Example:
#arch/powerpc/Makefile
$(Q)if test "$(call cc-fullversion)" = "040200" ; then \
echo -n '*** GCC-4.2.0 cannot compile the 64-bit powerpc ' ;\
false ; \
fi
In this example for a specific GCC version the build willerror out explaining
to the user why it stops.
cc-cross-prefix is used to check if there exists a $(CC) inpath with
one of the listed prefixes. The first prefix where there exista
prefix$(CC) in the PATH is returned - and if no prefix$(CC) isfound
then nothing is returned.
Additional prefixes are separated by a single space inthe
call of cc-cross-prefix.
This functionality is useful for architecture Makefiles thattry
to set CROSS_COMPILE to well-known values but may haveseveral
values to select between.
It is recommended only to try to set CROSS_COMPILE if it is across
build (host arch is different from target arch). And ifCROSS_COMPILE
is already set then leave it with the old value.
Example:
#arch/m68k/Makefile
ifneq ($(SUBARCH),$(ARCH))
endif
endif
=== 4 Host Program support
Kbuild supports building executables on the host for useduring the
compilation stage.
Two steps are required in order to use a hostexecutable.
The first step is to tell kbuild that a host program exists.This is
done utilising the variable hostprogs-y.
The second step is to add an explicit dependency to theexecutable.
This can be done in two ways. Either add the dependency in arule,
or utilise the variable $(always).
Both possibilities are described in the following.
--- 4.1 Simple Host Program
In some cases there is a need to compile and run a program onthe
computer where the build is running.
The following line tells kbuild that the program bin2hex shallbe
built on the build host.
Example:
hostprogs-y := bin2hex
Kbuild assumes in the above example that bin2hex is made froma single
c-source file named bin2hex.c located in the same directoryas
the Makefile.
--- 4.2 Composite Host Programs
Host programs can be made up based on composite objects.
The syntax used to define composite objects for host programsis
similar to the syntax used for kernel objects.
$(<executable>-objs) lists allobjects used to link the final
executable.
Example:
#scripts/lxdialog/Makefile
hostprogs-y := lxdialog
lxdialog-objs := checklist.o lxdialog.o
Objects with extension .o are compiled from the corresponding.c
files. In the above example, checklist.c is compiled tochecklist.o
and lxdialog.c is compiled to lxdialog.o.
Finally, the two .o files are linked to the executable,lxdialog.
Note: The syntax <executable>-yis not permitted for host-programs.
--- 4.3 Defining shared libraries
Objects with extension .so are considered shared libraries,and
will be compiled as position independent objects.
Kbuild provides support for shared libraries, but theusage
shall be restricted.
In the following example the libkconfig.so shared library isused
to link the executable conf.
Example:
#scripts/kconfig/Makefile
hostprogs-y :=conf
conf-objs := conf.o libkconfig.so
libkconfig-objs := expr.o type.o
Shared libraries always require a corresponding -objs line,and
in the example above the shared library libkconfig is composedby
the two objects expr.o and type.o.
expr.o and type.o will be built as position independent codeand
linked as a shared library libkconfig.so. C++ is not supportedfor
shared libraries.
--- 4.4 Using C++ for host programs
kbuild offers support for host programs written in C++. Thiswas
introduced solely to support kconfig, and is notrecommended
for general use.
Example:
#scripts/kconfig/Makefile
hostprogs-y := qconf
qconf-cxxobjs := qconf.o
In the example above the executable is composed of the C++file
qconf.cc - identified by $(qconf-cxxobjs).
If qconf is composed by a mixture of .c and .cc files, thenan
additional line can be used to identify this.
Example:
#scripts/kconfig/Makefile
hostprogs-y := qconf
qconf-cxxobjs := qconf.o
qconf-objs :=check.o
--- 4.5 Controlling compiler options for host programs
When compiling host programs, it is possible to set specificflags.
The programs will always be compiled utilising $(HOSTCC)passed
the options specified in $(HOSTCFLAGS).
To set flags that will take effect for all host programscreated
in that Makefile, use the variable HOST_EXTRACFLAGS.
Example:
#scripts/lxdialog/Makefile
HOST_EXTRACFLAGS += -I/usr/include/ncurses
To set specific flags for a single file the followingconstruction
is used:
Example:
#arch/ppc64/boot/Makefile
HOSTCFLAGS_piggyback.o := -DKERNELBASE=$(KERNELBASE)
It is also possible to specify additional options to thelinker.
Example:
#scripts/kconfig/Makefile
HOSTLOADLIBES_qconf := -L$(QTDIR)/lib
When linking qconf, it will be passed the extra option
"-L$(QTDIR)/lib".
--- 4.6 When host programs are actually built
Kbuild will only build host-programs when they arereferenced
as a prerequisite.
This is possible in two ways:
(1) List the prerequisite explicitly in a special rule.
Example:
#drivers/pci/Makefile
hostprogs-y := gen-devlist
$(obj)/devlist.h: $(src)/pci.ids $(obj)/gen-devlist
( cd $(obj); ./gen-devlist ) <$<
The target $(obj)/devlist.h will not be built before
$(obj)/gen-devlist is updated. Note that references to
the host programs in special rules must be prefixed with$(obj).
(2) Use $(always)
When there is no suitable special rule, and the hostprogram
shall be built when a makefile is entered, the $(always)
variable shall be used.
Example:
#scripts/lxdialog/Makefile
hostprogs-y := lxdialog
always := $(hostprogs-y)
This will tell kbuild to build lxdialog even if not referencedin
any rule.
--- 4.7 Using hostprogs-$(CONFIG_FOO)
A typical pattern in a Kbuild file looks like this:
Example:
#scripts/Makefile
hostprogs-$(CONFIG_KALLSYMS) += kallsyms
Kbuild knows about both 'y' for built-in and 'm' formodule.
So if a config symbol evaluate to 'm', kbuild will stillbuild
the binary. In other words, Kbuild handles hostprogs-mexactly
like hostprogs-y. But only hostprogs-y is recommended to beused
when no CONFIG symbols are involved.
=== 5 Kbuild clean infrastructure
"make clean" deletes most generated files in the obj treewhere the kernel
is compiled. This includes generated files such as hostprograms.
Kbuild knows targets listed in $(hostprogs-y), $(hostprogs-m),$(always),
$(extra-y) and $(targets). They are all deleted during "makeclean".
Files matching the patterns "*.[oas]", "*.ko", plus someadditional files
generated by kbuild are deleted all over the kernel src treewhen
"make clean" is executed.
Additional files can be specified in kbuild makefiles by useof $(clean-files).
Example:
#drivers/pci/Makefile
clean-files := devlist.h classlist.h
When executing "make clean", the two files "devlist.hclasslist.h" will
be deleted. Kbuild will assume files to be in same relativedirectory as the
Makefile except if an absolute path is specified (pathstarting with '/').
To delete a directory hierarchy use:
Example:
#scripts/package/Makefile
clean-dirs := $(objtree)/debian/
This will delete the directory debian, including allsubdirectories.
Kbuild will assume the directories to be in the same relativepath as the
Makefile if no absolute path is specified (path does not startwith '/').
Usually kbuild descends down in subdirectories due to "obj-*:= dir/",
but in the architecture makefiles where the kbuildinfrastructure
is not sufficient this sometimes needs to be explicit.
Example:
#arch/i386/boot/Makefile
subdir- := compressed/
The above assignment instructs kbuild to descend down inthe
directory compressed/ when "make clean" is executed.
To support the clean infrastructure in the Makefiles thatbuilds the
final bootimage there is an optional target namedarchclean:
Example:
#arch/i386/Makefile
archclean:
$(Q)$(MAKE) $(clean)=arch/i386/boot
When "make clean" is executed, make will descend down inarch/i386/boot,
and clean as usual. The Makefile located in arch/i386/boot/may use
the subdir- trick to descend further down.
Note 1: arch/$(ARCH)/Makefile cannot use "subdir-", becausethat file is
included in the top level makefile, and the kbuildinfrastructure
is not operational at that point.
Note 2: All directories listed in core-y, libs-y, drivers-yand net-y will
be visited during "make clean".
=== 6 Architecture Makefiles
The top level Makefile sets up the environment and does thepreparation,
before starting to descend down in the individualdirectories.
The top level makefile contains the generic part,whereas
arch/$(ARCH)/Makefile contains what is required to set upkbuild
for said architecture.
To do so, arch/$(ARCH)/Makefile sets up a number of variablesand defines
a few targets.
When kbuild executes, the following steps are followed(roughly):
1) Configuration of the kernel => produce.config
2) Store kernel version in include/linux/version.h
3) Symlink include/asm to include/asm-$(ARCH)
4) Updating all other prerequisites to the targetprepare:
5) Recursively descend down in all directories listed in
6) All object files are then linked and the resulting filevmlinux is
7) Finally, the architecture-specific part does any requiredpost processing
--- 6.1 Set variables to tweak the build to thearchitecture
Flags used for all invocations of the linker.
Often specifying the emulation is sufficient.
Example:
#arch/s390/Makefile
LDFLAGS := -m elf_s390
Note: ldflags-y can be used to further customise
the flags used. See chapter 3.7.
LDFLAGS_MODULE is used to set specific flags for $(LD)when
linking the .ko files used for modules.
Default is "-r", for relocatable output.
LDFLAGS_vmlinux is used to specify additional flags to passto
the linker when linking the final vmlinux image.
LDFLAGS_vmlinux uses the LDFLAGS_$@ support.
Example:
#arch/i386/Makefile
LDFLAGS_vmlinux := -e stext
When $(call if_changed,objcopy) is used to translate a .ofile,
the flags specified in OBJCOPYFLAGS will be used.
$(call if_changed,objcopy) is often used to generate rawbinaries on
vmlinux.
Example:
#arch/s390/Makefile
OBJCOPYFLAGS := -O binary
#arch/s390/boot/Makefile
$(obj)/image: vmlinux FORCE
$(call if_changed,objcopy)
In this example, the binary $(obj)/image is a binary versionof
vmlinux. The usage of $(call if_changed,xxx) will be describedlater.
Default value - see top level Makefile
Append or modify as required per architecture.
Example:
#arch/sparc64/Makefile
KBUILD_AFLAGS += -m64 -mcpu=ultrasparc
Default value - see top level Makefile
Append or modify as required per architecture.
Often, the KBUILD_CFLAGS variable depends on theconfiguration.
Example:
#arch/i386/Makefile
cflags-$(CONFIG_M386) += -march=i386
KBUILD_CFLAGS += $(cflags-y)
Many arch Makefiles dynamically run the target C compilerto
probe supported options:
#arch/i386/Makefile
...
cflags-$(CONFIG_MPENTIUMII) += $(call cc-option,\
-march=pentium2,-march=i686)
...
# Disable unit-at-a-time mode ...
KBUILD_CFLAGS += $(call cc-option,-fno-unit-at-a-time)
...
The first example utilises the trick that a config optionexpands
to 'y' when selected.
$(CFLAGS_KERNEL) contains extra C compiler flags used tocompile
resident kernel code.
$(CFLAGS_MODULE) contains extra C compiler flags used tocompile code
for loadable kernel modules.
--- 6.2 Add prerequisites to archprepare:
The archprepare: rule is used to list prerequisites that needto be
built before starting to descend down in thesubdirectories.
This is usually used for header files containing assemblerconstants.
Example:
#arch/arm/Makefile
archprepare: maketools
In this example, the file target maketools will beprocessed
before descending down in the subdirectories.
See also chapter XXX-TODO that describe how kbuildsupports
generating offset header files.
--- 6.3 List directories to visit when descending
An arch Makefile cooperates with the top Makefile to definevariables
which specify how to build the vmlinux file. Note that there is no
corresponding arch-specific section for modules; themodule-building
machinery is all architecture-independent.
$(head-y) lists objects to be linked first in vmlinux.
$(libs-y) lists directories where a lib.a archive can belocated.
The rest list directories where a built-in.o object file canbe
located.
$(init-y) objects will be located after $(head-y).
Then the rest follows in this order:
$(core-y), $(libs-y), $(drivers-y) and $(net-y).
The top level Makefile defines values for all genericdirectories,
and arch/$(ARCH)/Makefile only adds architecture-specificdirectories.
Example:
#arch/sparc64/Makefile
core-y += arch/sparc64/kernel/
libs-y += arch/sparc64/prom/ arch/sparc64/lib/
drivers-$(CONFIG_OPROFILE) +=arch/sparc64/oprofile/
--- 6.4 Architecture-specific boot images
An arch Makefile specifies goals that take the vmlinux file,compress
it, wrap it in bootstrapping code, and copy the resultingfiles
somewhere. This includes various kinds of installationcommands.
The actual goals are not standardized acrossarchitectures.
It is common to locate any additional processing in aboot/
directory below arch/$(ARCH)/.
Kbuild does not provide any smart way to support buildinga
target specified in boot/. Therefore arch/$(ARCH)/Makefileshall
call make manually to build a target in boot/.
The recommended approach is to include shortcuts in
arch/$(ARCH)/Makefile, and use the full path when callingdown
into the arch/$(ARCH)/boot/Makefile.
Example:
#arch/i386/Makefile
boot := arch/i386/boot
bzImage: vmlinux
$(Q)$(MAKE) $(build)=$(boot) $(boot)/$@
"$(Q)$(MAKE) $(build)=<dir>" isthe recommended way to invoke
make in a subdirectory.
There are no rules for naming architecture-specifictargets,
but executing "make help" will list all relevanttargets.
To support this, $(archhelp) must be defined.
Example:
#arch/i386/Makefile
define archhelp
endif
When make is executed without arguments, the first goalencountered
will be built. In the top level Makefile the first goalpresent
is all:.
An architecture shall always, per default, build a bootableimage.
In "make help", the default goal is highlighted with a'*'.
Add a new prerequisite to all: to select a default goaldifferent
from vmlinux.
Example:
#arch/i386/Makefile
all: bzImage
When "make" is executed without arguments, bzImage will bebuilt.
--- 6.5 Building non-kbuild targets
extra-y specify additional targets created in thecurrent
directory, in addition to any targets specified byobj-*.
Listing all targets in extra-y is required for twopurposes:
1) Enable kbuild to check changes in command lines
2) kbuild knows what files to delete during "make clean"
Example:
#arch/i386/kernel/Makefile
extra-y := head.o init_task.o
In this example, extra-y is used to list object filesthat
shall be built, but shall not be linked as part ofbuilt-in.o.
--- 6.6 Commands useful for building a boot image
Kbuild provides a few macros that are useful when buildinga
boot image.
if_changed is the infrastructure used for the followingcommands.
Usage:
target: source(s) FORCE
$(call if_changed,ld/objcopy/gzip)
When the rule is evaluated, it is checked to see if anyfiles
need an update, or the command line has changed since thelast
invocation. The latter will force a rebuild if anyoptions
to the executable have changed.
Any target that utilises if_changed must be listed in$(targets),
otherwise the command line check will fail, and the targetwill
always be built.
Assignments to $(targets) are without $(obj)/ prefix.
if_changed may be used in conjunction with custom commandsas
defined in 6.7 "Custom kbuild commands".
Note: It is a typical mistake to forget the FORCEprerequisite.
Another common pitfall is that whitespace is sometimes
significant; for instance, the below will fail (note the extraspace
after the comma):
target: source(s) FORCE
#WRONG!# $(call if_changed, ld/objcopy/gzip)
Link target. Often, LDFLAGS_$@ is used to set specific optionsto ld.
Copy binary. Uses OBJCOPYFLAGS usually specified in
arch/$(ARCH)/Makefile.
OBJCOPYFLAGS_$@ may be used to set additional options.
Compress target. Use maximum compression to compresstarget.
Example:
#arch/i386/boot/Makefile
LDFLAGS_bootsect := -Ttext 0x0 -s --oformat binary
LDFLAGS_setup := -Ttext0x0 -s --oformat binary -e begtext
targets += setup setup.o bootsect bootsect.o
$(obj)/setup $(obj)/bootsect: %: %.o FORCE
$(call if_changed,ld)
In this example, there are two possible targets, requiringdifferent
options to the linker. The linker options are specified usingthe
LDFLAGS_$@ syntax - one for each potential target.
$(targets) are assigned all potential targets, by which kbuildknows
the targets and will:
1) check for commandline changes
2) delete target during make clean
The ": %: %.o" part of the prerequisite is a shorthandthat
free us from listing the setup.o and bootsect.o files.
Note: It is a common mistake to forget the "target :="assignment,
--- 6.7 Custom kbuild commands
When kbuild is executing with KBUILD_VERBOSE=0, then only ashorthand
of a command is normally displayed.
To enable this behaviour for custom commands kbuildrequires
two variables to be set:
quiet_cmd_<command> - what shallbe echoed
Example:
#
quiet_cmd_image = BUILD $@
targets += bzImage
$(obj)/bzImage: $(obj)/vmlinux.bin $(obj)/tools/buildFORCE
$(call if_changed,image)
@echo 'Kernel: $@ is ready'
When updating the $(obj)/bzImage target, the line
BUILD arch/i386/boot/bzImage
will be displayed with "make KBUILD_VERBOSE=0".
--- 6.8 Preprocessing linker scripts
When the vmlinux image is built, the linker script
arch/$(ARCH)/kernel/vmlinux.lds is used.
The script is a preprocessed variant of the filevmlinux.lds.S
located in the same directory.
kbuild knows .lds files and includes a rule *lds.S-> *lds.
Example:
#arch/i386/kernel/Makefile
always := vmlinux.lds
#Makefile
export CPPFLAGS_vmlinux.lds += -P -C -U$(ARCH)
The assignment to $(always) is used to tell kbuild to buildthe
target vmlinux.lds.
The assignment to $(CPPFLAGS_vmlinux.lds) tells kbuild to usethe
specified options when building the target vmlinux.lds.
When building the *.lds target, kbuild uses thevariables:
KBUILD_CPPFLAGS : Set in top-level Makefile
cppflags-y : May be set in the kbuild makefile
CPPFLAGS_$(@F) : Target specificflags.
The kbuild infrastructure for *lds file are used inseveral
architecture-specific files.
=== 7 Kbuild syntax for exported headers
The kernel include a set of headers that is exported touserspace.
Many headers can be exported as-is but other headers requires a
minimal pre-processing before they are ready foruser-space.
The pre-processing does:
- drop kernel specific annotations
- drop include of compiler.h
- drop all sections that is kernel internat (guarded by ifdef__KERNEL__)
Each relevant directory contain a file name "Kbuild" whichspecify the
headers to be exported.
See subsequent chapter for the syntax of the Kbuildfile.
--- 7.1 header-y
header-y specify header files to be exported.
Example:
#include/linux/Kbuild
header-y += usb/
header-y += aio_abi.h
The convention is to list one file per line and
preferably in alphabetic order.
header-y also specify which subdirectories to visit.
A subdirectory is identified by a trailing '/' which
can be seen in the example above for the usbsubdirectory.
Subdirectories are visited before their parentdirectories.
--- 7.2 objhdr-y
objhdr-y specifies generated files to be exported.
Generated files are special as they need to be looked
up in another directory when doing 'make O=...' builds.
Example:
#include/linux/Kbuild
objhdr-y += version.h
--- 7.3 destination-y
When an architecture have a set of exported headers that needsto be
exported to a different directory destination-y is used.
destination-y specify the destination directory for allexported
headers in the file where it is present.
Example:
#arch/xtensa/platforms/s6105/include/platform/Kbuild
destination-y := include/linux
In the example above all exported headers in the Kbuildfile
will be located in the directory "include/linux" whenexported.
--- 7.4 unifdef-y (deprecated)
unifdef-y is deprecated. A direct replacement isheader-y.
=== 8 Kbuild Variables
The top Makefile exports the following variables:
These variables define the current kernel version. A few arch
Makefiles actually use these values directly; they shoulduse
$(KERNELRELEASE) instead.
$(VERSION), $(PATCHLEVEL), and $(SUBLEVEL) define thebasic
three-part version number, such as "2", "4", and "0". These three
values are always numeric.
$(EXTRAVERSION) defines an even tinier sublevel forpre-patches
or additional patches. It is usually some non-numericstring
such as "-pre4", and is often blank.
$(KERNELRELEASE) is a single string such as "2.4.0-pre4",suitable
for constructing installation directory names or showingin
version strings. Some arch Makefiles use itfor this purpose.
This variable defines the target architecture, such as"i386",
"arm", or "sparc". Some kbuild Makefiles test $(ARCH) to
determine which files to compile.
By default, the top Makefile sets $(ARCH) to be the same asthe
host system architecture. For a cross build,a user may
override the value of $(ARCH) on the command line:
This variable defines a place for the arch Makefiles toinstall
the resident kernel image and System.map file.
Use this for architecture-specific install targets.
$(INSTALL_MOD_PATH) specifies a prefix to $(MODLIB) formodule
installation. This variable is not definedin the Makefile but
may be passed in by the user if desired.
$(MODLIB) specifies the directory for moduleinstallation.
The top Makefile defines $(MODLIB) to
$(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE). The user may
override this value on the command line if desired.
If this variable is specified, will cause modules to bestripped
after they are installed. IfINSTALL_MOD_STRIP is '1', then the
default option --strip-debug will be used. Otherwise,
INSTALL_MOD_STRIP will used as the option(s) to the stripcommand.
=== 9 Makefile language
The kernel Makefiles are designed to be run with GNU Make. The Makefiles
use only the documented features of GNU Make, but they do usemany
GNU extensions.
GNU Make supports elementary list-processing functions. The kernel
Makefiles use a novel style of list building and manipulationwith few
"if" statements.
GNU Make has two assignment operators, ":=" and "=". ":=" performs
immediate evaluation of the right-hand side and stores anactual string
into the left-hand side. "=" is like aformula definition; it stores the
right-hand side in an unevaluated form and then evaluates thisform each
time the left-hand side is used.
There are some cases where "=" is appropriate. Usually, though, ":="
is the right choice.
=== 10 Credits
Original version made by Michael Elizabeth Chastain,<mailto:mec@shout.net>
Updates by Kai Germaschewski<kai@tp1.ruhr-uni-bochum.de>
Updates by Sam Ravnborg<sam@ravnborg.org>
Language QA by Jan Engelhardt<jengelh@gmx.de>
=== 11 TODO
- Describe how kbuild supports shipped files with_shipped.
- Generating offset header files.
- Add more variables to section 7?
0 0
- Linux Kernel Makefiles
- Makefiles by example
- Linux Kernel 排程機制介紹
- Linux Kernel 排程機制介紹
- Linux Kernel SMP …
- Linux Kernel SMP …
- Linux Kernel SMP …
- Linux Kernel SMP …
- Linux Kernel Makefiles(转)
- Linux Kernel Makefiles
- Linux Kernel Makefiles
- Linux Kernel Makefiles
- Linux Kernel Makefiles
- Linux Kernel Makefiles
- Linux Kernel Makefiles
- Linux kernel I2C设备总结
- Linux kernel I2C设备总结
- -Linux Kernel SMP&nbsp…
- 去除新浪博客文字白色背景巧妙方法
- make: *** [depend] 错误 2
- dnw在linux下的安装方法
- Kernel 配置问题集
- OCP-1Z0-051 第74题 oracle单行函数
- Linux Kernel Makefiles
- 看视频做的笔记——内核
- linux超级终端minicom的使用方法[…
- android:inputType参数类型说明
- 编译busybox是遇到的问题--- [netw…
- 看视频笔记----文件系统
- 驱动中使用class_device_create()…
- Linux基础： 解密module_init幕后…
- version magic '2.6.30.4 mod_unlo…
