mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-28 18:51:56 -04:00
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 ...
This commit is contained in:
Linus Torvalds
commit
6e936d3e9a
20 changed files with 1471 additions and 319 deletions
|
|
@ -37,15 +37,14 @@ o e2fsprogs 1.29 # tune2fs
|
|||
o jfsutils 1.1.3 # fsck.jfs -V
|
||||
o reiserfsprogs 3.6.3 # reiserfsck -V 2>&1|grep reiserfsprogs
|
||||
o xfsprogs 2.6.0 # xfs_db -V
|
||||
o pcmciautils 004
|
||||
o pcmcia-cs 3.1.21 # cardmgr -V
|
||||
o pcmciautils 004 # pccardctl -V
|
||||
o quota-tools 3.09 # quota -V
|
||||
o PPP 2.4.0 # pppd --version
|
||||
o isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version
|
||||
o nfs-utils 1.0.5 # showmount --version
|
||||
o procps 3.2.0 # ps --version
|
||||
o oprofile 0.9 # oprofiled --version
|
||||
o udev 071 # udevinfo -V
|
||||
o udev 081 # udevinfo -V
|
||||
|
||||
Kernel compilation
|
||||
==================
|
||||
|
|
@ -268,7 +267,7 @@ active clients.
|
|||
|
||||
To enable this new functionality, you need to:
|
||||
|
||||
mount -t nfsd nfsd /proc/fs/nfs
|
||||
mount -t nfsd nfsd /proc/fs/nfsd
|
||||
|
||||
before running exportfs or mountd. It is recommended that all NFS
|
||||
services be protected from the internet-at-large by a firewall where
|
||||
|
|
|
|||
|
|
@ -135,6 +135,7 @@ tags
|
|||
times.h*
|
||||
tkparse
|
||||
trix_boot.h
|
||||
utsrelease.h*
|
||||
version.h*
|
||||
vmlinux
|
||||
vmlinux-*
|
||||
|
|
|
|||
|
|
@ -67,19 +67,19 @@ applicable everywhere (see syntax).
|
|||
- default value: "default" <expr> ["if" <expr>]
|
||||
A config option can have any number of default values. If multiple
|
||||
default values are visible, only the first defined one is active.
|
||||
Default values are not limited to the menu entry, where they are
|
||||
defined, this means the default can be defined somewhere else or be
|
||||
Default values are not limited to the menu entry where they are
|
||||
defined. This means the default can be defined somewhere else or be
|
||||
overridden by an earlier definition.
|
||||
The default value is only assigned to the config symbol if no other
|
||||
value was set by the user (via the input prompt above). If an input
|
||||
prompt is visible the default value is presented to the user and can
|
||||
be overridden by him.
|
||||
Optionally dependencies only for this default value can be added with
|
||||
Optionally, dependencies only for this default value can be added with
|
||||
"if".
|
||||
|
||||
- dependencies: "depends on"/"requires" <expr>
|
||||
This defines a dependency for this menu entry. If multiple
|
||||
dependencies are defined they are connected with '&&'. Dependencies
|
||||
dependencies are defined, they are connected with '&&'. Dependencies
|
||||
are applied to all other options within this menu entry (which also
|
||||
accept an "if" expression), so these two examples are equivalent:
|
||||
|
||||
|
|
@ -153,7 +153,7 @@ Nonconstant symbols are the most common ones and are defined with the
|
|||
'config' statement. Nonconstant symbols consist entirely of alphanumeric
|
||||
characters or underscores.
|
||||
Constant symbols are only part of expressions. Constant symbols are
|
||||
always surrounded by single or double quotes. Within the quote any
|
||||
always surrounded by single or double quotes. Within the quote, any
|
||||
other character is allowed and the quotes can be escaped using '\'.
|
||||
|
||||
Menu structure
|
||||
|
|
@ -237,7 +237,7 @@ choices:
|
|||
<choice block>
|
||||
"endchoice"
|
||||
|
||||
This defines a choice group and accepts any of above attributes as
|
||||
This defines a choice group and accepts any of the above attributes as
|
||||
options. A choice can only be of type bool or tristate, while a boolean
|
||||
choice only allows a single config entry to be selected, a tristate
|
||||
choice also allows any number of config entries to be set to 'm'. This
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ This document describes the Linux kernel Makefiles.
|
|||
=== 4 Host Program support
|
||||
--- 4.1 Simple Host Program
|
||||
--- 4.2 Composite Host Programs
|
||||
--- 4.3 Defining shared libraries
|
||||
--- 4.3 Defining shared libraries
|
||||
--- 4.4 Using C++ for host programs
|
||||
--- 4.5 Controlling compiler options for host programs
|
||||
--- 4.6 When host programs are actually built
|
||||
|
|
@ -69,7 +69,7 @@ architecture-specific information to the top Makefile.
|
|||
|
||||
Each subdirectory has a kbuild Makefile which carries out the commands
|
||||
passed down from above. The kbuild Makefile uses information from the
|
||||
.config file to construct various file lists used by kbuild to build
|
||||
.config file to construct various file lists used by kbuild to build
|
||||
any built-in or modular targets.
|
||||
|
||||
scripts/Makefile.* contains all the definitions/rules etc. that
|
||||
|
|
@ -86,7 +86,7 @@ any kernel Makefiles (or any other source files).
|
|||
|
||||
*Normal developers* are people who work on features such as device
|
||||
drivers, file systems, and network protocols. These people need to
|
||||
maintain the kbuild Makefiles for the subsystem that they are
|
||||
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 knowledge about the
|
||||
public interface for kbuild.
|
||||
|
|
@ -104,10 +104,10 @@ This document is aimed towards normal developers and arch developers.
|
|||
=== 3 The kbuild files
|
||||
|
||||
Most Makefiles within the kernel are kbuild Makefiles that use the
|
||||
kbuild infrastructure. This chapter introduce the syntax used in the
|
||||
kbuild infrastructure. This chapter introduces the syntax used in 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'
|
||||
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, further chapters provide
|
||||
|
|
@ -124,7 +124,7 @@ more details, with real examples.
|
|||
Example:
|
||||
obj-y += foo.o
|
||||
|
||||
This tell kbuild that there is one object in that directory named
|
||||
This tell 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 is used.
|
||||
|
|
@ -140,7 +140,7 @@ more details, with real examples.
|
|||
--- 3.2 Built-in object goals - obj-y
|
||||
|
||||
The kbuild Makefile specifies object files for vmlinux
|
||||
in the lists $(obj-y). These lists depend on the kernel
|
||||
in the $(obj-y) lists. These lists depend on the kernel
|
||||
configuration.
|
||||
|
||||
Kbuild compiles all the $(obj-y) files. It then calls
|
||||
|
|
@ -154,8 +154,8 @@ more details, with real examples.
|
|||
Link order is significant, because certain functions
|
||||
(module_init() / __initcall) will be called during boot in the
|
||||
order they appear. So keep in mind that changing the link
|
||||
order may e.g. change the order in which your SCSI
|
||||
controllers are detected, and thus you disks are renumbered.
|
||||
order may e.g. change the order in which your SCSI
|
||||
controllers are detected, and thus your disks are renumbered.
|
||||
|
||||
Example:
|
||||
#drivers/isdn/i4l/Makefile
|
||||
|
|
@ -203,11 +203,11 @@ more details, with real examples.
|
|||
Example:
|
||||
#fs/ext2/Makefile
|
||||
obj-$(CONFIG_EXT2_FS) += ext2.o
|
||||
ext2-y := balloc.o bitmap.o
|
||||
ext2-y := balloc.o bitmap.o
|
||||
ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o
|
||||
|
||||
In this example xattr.o is only part of the composite object
|
||||
ext2.o, if $(CONFIG_EXT2_FS_XATTR) evaluates to 'y'.
|
||||
|
||||
In this example, xattr.o is only part of the composite object
|
||||
ext2.o if $(CONFIG_EXT2_FS_XATTR) evaluates to 'y'.
|
||||
|
||||
Note: Of course, when you are building objects into the kernel,
|
||||
the syntax above will also work. So, if you have CONFIG_EXT2_FS=y,
|
||||
|
|
@ -221,16 +221,16 @@ more details, with real examples.
|
|||
|
||||
--- 3.5 Library file goals - lib-y
|
||||
|
||||
Objects listed with obj-* are used for modules or
|
||||
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 additional listed in
|
||||
Objects that are listed in obj-y and additionaly listed in
|
||||
lib-y will not be included in the library, since they will anyway
|
||||
be accessible.
|
||||
For consistency objects listed in lib-m will be included in lib.a.
|
||||
For consistency, objects listed in lib-m will be included in lib.a.
|
||||
|
||||
Note that the same kbuild makefile may list files to be built-in
|
||||
and to be part of a library. Therefore the same directory
|
||||
|
|
@ -241,11 +241,11 @@ more details, with real examples.
|
|||
lib-y := checksum.o delay.o
|
||||
|
||||
This will create a library lib.a based on checksum.o and delay.o.
|
||||
For kbuild to actually recognize that there is a lib.a being build
|
||||
For kbuild to actually recognize that there is a lib.a being built,
|
||||
the directory shall be listed in libs-y.
|
||||
See also "6.3 List directories to visit when descending".
|
||||
|
||||
Usage of lib-y is normally restricted to lib/ and arch/*/lib.
|
||||
|
||||
Use of lib-y is normally restricted to lib/ and arch/*/lib.
|
||||
|
||||
--- 3.6 Descending down in directories
|
||||
|
||||
|
|
@ -255,7 +255,7 @@ more details, with real examples.
|
|||
invoke make recursively in subdirectories, provided you let it know of
|
||||
them.
|
||||
|
||||
To do so obj-y and obj-m are used.
|
||||
To do so, obj-y and obj-m are used.
|
||||
ext2 lives in a separate directory, and the Makefile present in fs/
|
||||
tells kbuild to descend down using the following assignment.
|
||||
|
||||
|
|
@ -353,8 +353,8 @@ more details, with real examples.
|
|||
Special rules are used when the kbuild infrastructure does
|
||||
not provide the required support. A typical example is
|
||||
header files generated during the build process.
|
||||
Another example is the architecture specific Makefiles which
|
||||
needs special rules to prepare boot images etc.
|
||||
Another example are the architecture specific Makefiles which
|
||||
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 Makefile is
|
||||
|
|
@ -387,28 +387,28 @@ more details, with real examples.
|
|||
|
||||
--- 3.11 $(CC) support functions
|
||||
|
||||
The kernel may be build with several different versions of
|
||||
The kernel may be built with several different versions of
|
||||
$(CC), each supporting a unique set of features and options.
|
||||
kbuild provide basic support to check for valid options for $(CC).
|
||||
$(CC) is useally the gcc compiler, but other alternatives are
|
||||
available.
|
||||
|
||||
as-option
|
||||
as-option is used to check if $(CC) when used to compile
|
||||
assembler (*.S) files supports the given option. An optional
|
||||
second option may be specified if first option are not supported.
|
||||
as-option is used to check if $(CC) -- when used to compile
|
||||
assembler (*.S) files -- supports the given option. An optional
|
||||
second option may be specified if the first option is not supported.
|
||||
|
||||
Example:
|
||||
#arch/sh/Makefile
|
||||
cflags-y += $(call as-option,-Wa$(comma)-isa=$(isa-y),)
|
||||
|
||||
In the above example cflags-y will be assinged the the option
|
||||
In the above example, cflags-y will be assigned the option
|
||||
-Wa$(comma)-isa=$(isa-y) if it is supported by $(CC).
|
||||
The second argument is optional, and if supplied will be used
|
||||
if first argument is not supported.
|
||||
|
||||
ld-option
|
||||
ld-option is used to check if $(CC) when used to link object files
|
||||
ld-option is used to check if $(CC) when used to link object files
|
||||
supports the given option. An optional second option may be
|
||||
specified if first option are not supported.
|
||||
|
||||
|
|
@ -422,7 +422,7 @@ more details, with real examples.
|
|||
if first argument is not supported.
|
||||
|
||||
cc-option
|
||||
cc-option is used to check if $(CC) support a given option, and not
|
||||
cc-option is used to check if $(CC) supports a given option, and not
|
||||
supported to use an optional second option.
|
||||
|
||||
Example:
|
||||
|
|
@ -430,12 +430,12 @@ more details, with real examples.
|
|||
cflags-y += $(call cc-option,-march=pentium-mmx,-march=i586)
|
||||
|
||||
In the above example cflags-y will be assigned the option
|
||||
-march=pentium-mmx if supported by $(CC), otherwise -march-i586.
|
||||
The second argument to cc-option is optional, and if omitted
|
||||
-march=pentium-mmx if supported by $(CC), otherwise -march=i586.
|
||||
The second argument to cc-option is optional, and if omitted,
|
||||
cflags-y will be assigned no value if first option is not supported.
|
||||
|
||||
cc-option-yn
|
||||
cc-option-yn is used to check if gcc supports a given option
|
||||
cc-option-yn is used to check if gcc supports a given option
|
||||
and return 'y' if supported, otherwise 'n'.
|
||||
|
||||
Example:
|
||||
|
|
@ -443,32 +443,33 @@ more details, with real examples.
|
|||
biarch := $(call cc-option-yn, -m32)
|
||||
aflags-$(biarch) += -a32
|
||||
cflags-$(biarch) += -m32
|
||||
|
||||
In the above example $(biarch) is set to y if $(CC) supports the -m32
|
||||
option. When $(biarch) equals to y the expanded variables $(aflags-y)
|
||||
and $(cflags-y) will be assigned the values -a32 and -m32.
|
||||
|
||||
In the above example, $(biarch) is set to y if $(CC) supports the -m32
|
||||
option. When $(biarch) equals 'y', the expanded variables $(aflags-y)
|
||||
and $(cflags-y) will be assigned the values -a32 and -m32,
|
||||
respectively.
|
||||
|
||||
cc-option-align
|
||||
gcc version >= 3.0 shifted type of options used to speify
|
||||
alignment of functions, loops etc. $(cc-option-align) whrn used
|
||||
as prefix to the align options will select the right prefix:
|
||||
gcc versions >= 3.0 changed the type of options used to specify
|
||||
alignment of functions, loops etc. $(cc-option-align), when used
|
||||
as prefix to the align options, will select the right prefix:
|
||||
gcc < 3.00
|
||||
cc-option-align = -malign
|
||||
gcc >= 3.00
|
||||
cc-option-align = -falign
|
||||
|
||||
|
||||
Example:
|
||||
CFLAGS += $(cc-option-align)-functions=4
|
||||
|
||||
In the above example the option -falign-functions=4 is used for
|
||||
gcc >= 3.00. For gcc < 3.00 -malign-functions=4 is used.
|
||||
|
||||
In the above example, the option -falign-functions=4 is used for
|
||||
gcc >= 3.00. For gcc < 3.00, -malign-functions=4 is used.
|
||||
|
||||
cc-version
|
||||
cc-version return a numerical version of the $(CC) compiler version.
|
||||
cc-version returns a numerical version of the $(CC) compiler version.
|
||||
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 faulty in one
|
||||
area, for example the -mregparm=3 were broken in some gcc version
|
||||
area, for example -mregparm=3 was broken in some gcc versions
|
||||
even though the option was accepted by gcc.
|
||||
|
||||
Example:
|
||||
|
|
@ -477,20 +478,20 @@ more details, with real examples.
|
|||
if [ $(call cc-version) -ge 0300 ] ; then \
|
||||
echo "-mregparm=3"; fi ;)
|
||||
|
||||
In the above example -mregparm=3 is only used for gcc version greater
|
||||
In the above example, -mregparm=3 is only used for gcc version greater
|
||||
than or equal to gcc 3.0.
|
||||
|
||||
cc-ifversion
|
||||
cc-ifversion test the version of $(CC) and equals last argument if
|
||||
cc-ifversion tests the version of $(CC) and equals last argument if
|
||||
version expression is true.
|
||||
|
||||
Example:
|
||||
#fs/reiserfs/Makefile
|
||||
EXTRA_CFLAGS := $(call cc-ifversion, -lt, 0402, -O1)
|
||||
|
||||
In this example EXTRA_CFLAGS will be assigned the value -O1 if the
|
||||
In this example, EXTRA_CFLAGS will be assigned the value -O1 if the
|
||||
$(CC) version is less than 4.2.
|
||||
cc-ifversion takes all the shell operators:
|
||||
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 it may also
|
||||
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
|
|||
done utilising the variable hostprogs-y.
|
||||
|
||||
The second step is to add an explicit dependency to the executable.
|
||||
This can be done in two ways. Either add the dependency in a rule,
|
||||
This can be done in two ways. Either add the dependency in a rule,
|
||||
or utilise the variable $(always).
|
||||
Both possibilities are described in the following.
|
||||
|
||||
|
|
@ -523,28 +524,28 @@ Both possibilities are described in the following.
|
|||
Kbuild assumes in the above example that bin2hex is made from a single
|
||||
c-source file named bin2hex.c located in the same directory as
|
||||
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 programs is
|
||||
similar to the syntax used for kernel objects.
|
||||
$(<executeable>-objs) list all objects used to link the final
|
||||
$(<executeable>-objs) lists all objects used to link the final
|
||||
executable.
|
||||
|
||||
Example:
|
||||
#scripts/lxdialog/Makefile
|
||||
hostprogs-y := lxdialog
|
||||
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 to checklist.o
|
||||
files. In the above example, checklist.c is compiled to checklist.o
|
||||
and lxdialog.c is compiled to lxdialog.o.
|
||||
Finally the two .o files are linked to the executable, lxdialog.
|
||||
Finally, the two .o files are linked to the executable, lxdialog.
|
||||
Note: The syntax <executable>-y is not permitted for host-programs.
|
||||
|
||||
--- 4.3 Defining shared libraries
|
||||
|
||||
--- 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 the usage
|
||||
|
|
@ -557,7 +558,7 @@ Both possibilities are described in the following.
|
|||
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 composed by
|
||||
the two objects expr.o and type.o.
|
||||
|
|
@ -578,7 +579,7 @@ Both possibilities are described in the following.
|
|||
|
||||
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, then an
|
||||
additional line can be used to identify this.
|
||||
|
||||
|
|
@ -587,34 +588,35 @@ Both possibilities are described in the following.
|
|||
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 specific flags.
|
||||
The programs will always be compiled utilising $(HOSTCC) passed
|
||||
the options specified in $(HOSTCFLAGS).
|
||||
To set flags that will take effect for all host programs created
|
||||
in that Makefile use the variable HOST_EXTRACFLAGS.
|
||||
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 following construction
|
||||
is used:
|
||||
|
||||
Example:
|
||||
#arch/ppc64/boot/Makefile
|
||||
HOSTCFLAGS_piggyback.o := -DKERNELBASE=$(KERNELBASE)
|
||||
|
||||
|
||||
It is also possible to specify additional options to the linker.
|
||||
|
||||
|
||||
Example:
|
||||
#scripts/kconfig/Makefile
|
||||
HOSTLOADLIBES_qconf := -L$(QTDIR)/lib
|
||||
|
||||
When linking qconf it will be passed the extra option "-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 are referenced
|
||||
|
|
@ -629,7 +631,7 @@ Both possibilities are described in the following.
|
|||
$(obj)/devlist.h: $(src)/pci.ids $(obj)/gen-devlist
|
||||
( cd $(obj); ./gen-devlist ) < $<
|
||||
|
||||
The target $(obj)/devlist.h will not be built before
|
||||
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).
|
||||
|
||||
|
|
@ -648,7 +650,7 @@ Both possibilities are described in the following.
|
|||
|
||||
--- 4.7 Using hostprogs-$(CONFIG_FOO)
|
||||
|
||||
A typcal pattern in a Kbuild file lok like this:
|
||||
A typical pattern in a Kbuild file looks like this:
|
||||
|
||||
Example:
|
||||
#scripts/Makefile
|
||||
|
|
@ -656,13 +658,13 @@ Both possibilities are described in the following.
|
|||
|
||||
Kbuild knows about both 'y' for built-in and 'm' for module.
|
||||
So if a config symbol evaluate to 'm', kbuild will still build
|
||||
the binary. In other words Kbuild handle hostprogs-m exactly
|
||||
like hostprogs-y. But only hostprogs-y is recommend used
|
||||
when no CONFIG symbol are involved.
|
||||
the binary. In other words, Kbuild handles hostprogs-m exactly
|
||||
like hostprogs-y. But only hostprogs-y is recommended to be used
|
||||
when no CONFIG symbols are involved.
|
||||
|
||||
=== 5 Kbuild clean infrastructure
|
||||
|
||||
"make clean" deletes most generated files in the src tree where the kernel
|
||||
"make clean" deletes most generated files in the obj tree where the kernel
|
||||
is compiled. This includes generated files such as host programs.
|
||||
Kbuild knows targets listed in $(hostprogs-y), $(hostprogs-m), $(always),
|
||||
$(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
|
|||
be deleted. Kbuild will assume files to be in same relative directory as the
|
||||
Makefile except if an absolute path is specified (path starting with '/').
|
||||
|
||||
To delete a directory hirachy use:
|
||||
To delete a directory hierarchy use:
|
||||
|
||||
Example:
|
||||
#scripts/package/Makefile
|
||||
clean-dirs := $(objtree)/debian/
|
||||
|
|
@ -723,29 +726,29 @@ be visited during "make clean".
|
|||
|
||||
The top level Makefile sets up the environment and does the preparation,
|
||||
before starting to descend down in the individual directories.
|
||||
The top level makefile contains the generic part, whereas the
|
||||
arch/$(ARCH)/Makefile contains what is required to set-up kbuild
|
||||
to the said architecture.
|
||||
To do so arch/$(ARCH)/Makefile sets a number of variables, and defines
|
||||
The top level makefile contains the generic part, whereas
|
||||
arch/$(ARCH)/Makefile contains what is required to set up kbuild
|
||||
for said architecture.
|
||||
To do so, arch/$(ARCH)/Makefile sets up a number of variables and defines
|
||||
a few targets.
|
||||
|
||||
When kbuild executes the following steps are followed (roughly):
|
||||
1) Configuration of the kernel => produced .config
|
||||
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 target prepare:
|
||||
- Additional prerequisites are specified in arch/$(ARCH)/Makefile
|
||||
5) Recursively descend down in all directories listed in
|
||||
init-* core* drivers-* net-* libs-* and build all targets.
|
||||
- The value of the above variables are extended in arch/$(ARCH)/Makefile.
|
||||
6) All object files are then linked and the resulting file vmlinux is
|
||||
located at the root of the src tree.
|
||||
- The values of the above variables are expanded in arch/$(ARCH)/Makefile.
|
||||
6) All object files are then linked and the resulting file vmlinux is
|
||||
located at the root of the obj tree.
|
||||
The very first objects linked are listed in head-y, assigned by
|
||||
arch/$(ARCH)/Makefile.
|
||||
7) Finally the architecture specific part does any required post processing
|
||||
7) Finally, the architecture specific part does any required post processing
|
||||
and builds the final bootimage.
|
||||
- This includes building boot records
|
||||
- Preparing initrd images and the like
|
||||
- Preparing initrd images and thelike
|
||||
|
||||
|
||||
--- 6.1 Set variables to tweak the build to the architecture
|
||||
|
|
@ -760,7 +763,7 @@ When kbuild executes the following steps are followed (roughly):
|
|||
LDFLAGS := -m elf_s390
|
||||
Note: EXTRA_LDFLAGS and LDFLAGS_$@ can be used to further customise
|
||||
the flags used. See chapter 7.
|
||||
|
||||
|
||||
LDFLAGS_MODULE Options for $(LD) when linking modules
|
||||
|
||||
LDFLAGS_MODULE is used to set specific flags for $(LD) when
|
||||
|
|
@ -770,7 +773,7 @@ When kbuild executes the following steps are followed (roughly):
|
|||
LDFLAGS_vmlinux Options for $(LD) when linking vmlinux
|
||||
|
||||
LDFLAGS_vmlinux is used to specify additional flags to pass to
|
||||
the linker when linking the final vmlinux.
|
||||
the linker when linking the final vmlinux image.
|
||||
LDFLAGS_vmlinux uses the LDFLAGS_$@ support.
|
||||
|
||||
Example:
|
||||
|
|
@ -780,7 +783,7 @@ When kbuild executes the following steps are followed (roughly):
|
|||
OBJCOPYFLAGS objcopy flags
|
||||
|
||||
When $(call if_changed,objcopy) is used to translate a .o file,
|
||||
then the flags specified in OBJCOPYFLAGS will be used.
|
||||
the flags specified in OBJCOPYFLAGS will be used.
|
||||
$(call if_changed,objcopy) is often used to generate raw binaries on
|
||||
vmlinux.
|
||||
|
||||
|
|
@ -792,7 +795,7 @@ When kbuild executes the following steps are followed (roughly):
|
|||
$(obj)/image: vmlinux FORCE
|
||||
$(call if_changed,objcopy)
|
||||
|
||||
In this example the binary $(obj)/image is a binary version of
|
||||
In this example, the binary $(obj)/image is a binary version of
|
||||
vmlinux. The usage of $(call if_changed,xxx) will be described later.
|
||||
|
||||
AFLAGS $(AS) assembler flags
|
||||
|
|
@ -809,7 +812,7 @@ When kbuild executes the following steps are followed (roughly):
|
|||
Default value - see top level Makefile
|
||||
Append or modify as required per architecture.
|
||||
|
||||
Often the CFLAGS variable depends on the configuration.
|
||||
Often, the CFLAGS variable depends on the configuration.
|
||||
|
||||
Example:
|
||||
#arch/i386/Makefile
|
||||
|
|
@ -830,7 +833,7 @@ When kbuild executes the following steps are followed (roughly):
|
|||
...
|
||||
|
||||
|
||||
The first examples utilises the trick that a config option expands
|
||||
The first example utilises the trick that a config option expands
|
||||
to 'y' when selected.
|
||||
|
||||
CFLAGS_KERNEL $(CC) options specific for built-in
|
||||
|
|
@ -843,18 +846,18 @@ When kbuild executes the following steps are followed (roughly):
|
|||
$(CFLAGS_MODULE) contains extra C compiler flags used to compile code
|
||||
for loadable kernel modules.
|
||||
|
||||
|
||||
|
||||
--- 6.2 Add prerequisites to archprepare:
|
||||
|
||||
The archprepare: rule is used to list prerequisites that needs to be
|
||||
The archprepare: rule is used to list prerequisites that need to be
|
||||
built before starting to descend down in the subdirectories.
|
||||
This is usual header files containing assembler constants.
|
||||
This is usually used for header files containing assembler constants.
|
||||
|
||||
Example:
|
||||
#arch/arm/Makefile
|
||||
archprepare: maketools
|
||||
|
||||
In this example the file target maketools will be processed
|
||||
In this example, the file target maketools will be processed
|
||||
before descending down in the subdirectories.
|
||||
See also chapter XXX-TODO that describe how kbuild supports
|
||||
generating offset header files.
|
||||
|
|
@ -867,18 +870,19 @@ When kbuild executes the following steps are followed (roughly):
|
|||
corresponding arch-specific section for modules; the module-building
|
||||
machinery is all architecture-independent.
|
||||
|
||||
|
||||
|
||||
head-y, init-y, core-y, libs-y, drivers-y, net-y
|
||||
|
||||
$(head-y) list objects to be linked first in vmlinux.
|
||||
$(libs-y) list directories where a lib.a archive can be located.
|
||||
The rest list directories where a built-in.o object file can be located.
|
||||
$(head-y) lists objects to be linked first in vmlinux.
|
||||
$(libs-y) lists directories where a lib.a archive can be located.
|
||||
The rest lists directories where a built-in.o object file can be
|
||||
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 define values for all generic directories,
|
||||
The top level Makefile defines values for all generic directories,
|
||||
and arch/$(ARCH)/Makefile only adds architecture specific directories.
|
||||
|
||||
Example:
|
||||
|
|
@ -915,27 +919,27 @@ When kbuild executes the following steps are followed (roughly):
|
|||
"$(Q)$(MAKE) $(build)=<dir>" is the recommended way to invoke
|
||||
make in a subdirectory.
|
||||
|
||||
There are no rules for naming of the architecture specific targets,
|
||||
There are no rules for naming architecture specific targets,
|
||||
but executing "make help" will list all relevant targets.
|
||||
To support this $(archhelp) must be defined.
|
||||
To support this, $(archhelp) must be defined.
|
||||
|
||||
Example:
|
||||
#arch/i386/Makefile
|
||||
define archhelp
|
||||
echo '* bzImage - Image (arch/$(ARCH)/boot/bzImage)'
|
||||
endef
|
||||
endif
|
||||
|
||||
When make is executed without arguments, the first goal encountered
|
||||
will be built. In the top level Makefile the first goal present
|
||||
is all:.
|
||||
An architecture shall always per default build a bootable image.
|
||||
In "make help" the default goal is highlighted with a '*'.
|
||||
An architecture shall always, per default, build a bootable image.
|
||||
In "make help", the default goal is highlighted with a '*'.
|
||||
Add a new prerequisite to all: to select a default goal different
|
||||
from vmlinux.
|
||||
|
||||
Example:
|
||||
#arch/i386/Makefile
|
||||
all: bzImage
|
||||
all: bzImage
|
||||
|
||||
When "make" is executed without arguments, bzImage will be built.
|
||||
|
||||
|
|
@ -955,10 +959,10 @@ When kbuild executes the following steps are followed (roughly):
|
|||
#arch/i386/kernel/Makefile
|
||||
extra-y := head.o init_task.o
|
||||
|
||||
In this example extra-y is used to list object files that
|
||||
In this example, extra-y is used to list object files that
|
||||
shall be built, but shall not be linked as part of built-in.o.
|
||||
|
||||
|
||||
|
||||
--- 6.6 Commands useful for building a boot image
|
||||
|
||||
Kbuild provides a few macros that are useful when building a
|
||||
|
|
@ -972,8 +976,8 @@ When kbuild executes the following steps are followed (roughly):
|
|||
target: source(s) FORCE
|
||||
$(call if_changed,ld/objcopy/gzip)
|
||||
|
||||
When the rule is evaluated it is checked to see if any files
|
||||
needs an update, or the commandline has changed since last
|
||||
When the rule is evaluated, it is checked to see if any files
|
||||
needs an update, or the command line has changed since the last
|
||||
invocation. The latter will force a rebuild if any options
|
||||
to the executable have changed.
|
||||
Any target that utilises if_changed must be listed in $(targets),
|
||||
|
|
@ -991,8 +995,8 @@ When kbuild executes the following steps are followed (roughly):
|
|||
#WRONG!# $(call if_changed, ld/objcopy/gzip)
|
||||
|
||||
ld
|
||||
Link target. Often LDFLAGS_$@ is used to set specific options to ld.
|
||||
|
||||
Link target. Often, LDFLAGS_$@ is used to set specific options to ld.
|
||||
|
||||
objcopy
|
||||
Copy binary. Uses OBJCOPYFLAGS usually specified in
|
||||
arch/$(ARCH)/Makefile.
|
||||
|
|
@ -1010,10 +1014,10 @@ When kbuild executes the following steps are followed (roughly):
|
|||
$(obj)/setup $(obj)/bootsect: %: %.o FORCE
|
||||
$(call if_changed,ld)
|
||||
|
||||
In this example there are two possible targets, requiring different
|
||||
options to the linker. the linker options are specified using the
|
||||
In this example, there are two possible targets, requiring different
|
||||
options to the linker. The linker options are specified using the
|
||||
LDFLAGS_$@ syntax - one for each potential target.
|
||||
$(targets) are assinged all potential targets, herby kbuild knows
|
||||
$(targets) are assinged all potential targets, by which kbuild knows
|
||||
the targets and will:
|
||||
1) check for commandline changes
|
||||
2) delete target during make clean
|
||||
|
|
@ -1027,7 +1031,7 @@ When kbuild executes the following steps are followed (roughly):
|
|||
|
||||
--- 6.7 Custom kbuild commands
|
||||
|
||||
When kbuild is executing with KBUILD_VERBOSE=0 then only a shorthand
|
||||
When kbuild is executing with KBUILD_VERBOSE=0, then only a shorthand
|
||||
of a command is normally displayed.
|
||||
To enable this behaviour for custom commands kbuild requires
|
||||
two variables to be set:
|
||||
|
|
@ -1045,34 +1049,34 @@ When kbuild executes the following steps are followed (roughly):
|
|||
$(call if_changed,image)
|
||||
@echo 'Kernel: $@ is ready'
|
||||
|
||||
When updating the $(obj)/bzImage target the line:
|
||||
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 build the linker script:
|
||||
When the vmlinux image is built, the linker script
|
||||
arch/$(ARCH)/kernel/vmlinux.lds is used.
|
||||
The script is a preprocessed variant of the file vmlinux.lds.S
|
||||
located in the same directory.
|
||||
kbuild knows .lds file and includes a rule *lds.S -> *lds.
|
||||
|
||||
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 assigment to $(always) is used to tell kbuild to build the
|
||||
target: vmlinux.lds.
|
||||
The assignment to $(CPPFLAGS_vmlinux.lds) tell kbuild to use the
|
||||
|
||||
The assignment to $(always) is used to tell kbuild to build the
|
||||
target vmlinux.lds.
|
||||
The assignment to $(CPPFLAGS_vmlinux.lds) tells kbuild to use the
|
||||
specified options when building the target vmlinux.lds.
|
||||
|
||||
When building the *.lds target kbuild used the variakles:
|
||||
|
||||
When building the *.lds target, kbuild uses the variables:
|
||||
CPPFLAGS : Set in top-level Makefile
|
||||
EXTRA_CPPFLAGS : May be set in the kbuild makefile
|
||||
CPPFLAGS_$(@F) : Target specific flags.
|
||||
|
|
@ -1147,7 +1151,7 @@ The top Makefile exports the following variables:
|
|||
|
||||
=== 8 Makefile language
|
||||
|
||||
The kernel Makefiles are designed to run with GNU Make. The Makefiles
|
||||
The kernel Makefiles are designed to be run with GNU Make. The Makefiles
|
||||
use only the documented features of GNU Make, but they do use many
|
||||
GNU extensions.
|
||||
|
||||
|
|
@ -1169,10 +1173,13 @@ is the right choice.
|
|||
Original version made by Michael Elizabeth Chastain, <mailto:[email protected]>
|
||||
Updates by Kai Germaschewski <[email protected]>
|
||||
Updates by Sam Ravnborg <[email protected]>
|
||||
Language QA by Jan Engelhardt <[email protected]>
|
||||
|
||||
=== 10 TODO
|
||||
|
||||
- Describe how kbuild support shipped files with _shipped.
|
||||
- Describe how kbuild supports shipped files with _shipped.
|
||||
- Generating offset header files.
|
||||
- Add more variables to section 7?
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
|
||||
In this document you will find information about:
|
||||
- how to build external modules
|
||||
- how to make your module use kbuild infrastructure
|
||||
- how to make your module use the kbuild infrastructure
|
||||
- how kbuild will install a kernel
|
||||
- how to install modules in a non-standard location
|
||||
|
||||
|
|
@ -24,7 +24,7 @@ In this document you will find information about:
|
|||
--- 6.1 INSTALL_MOD_PATH
|
||||
--- 6.2 INSTALL_MOD_DIR
|
||||
=== 7. Module versioning & Module.symvers
|
||||
--- 7.1 Symbols fron the kernel (vmlinux + modules)
|
||||
--- 7.1 Symbols from the kernel (vmlinux + modules)
|
||||
--- 7.2 Symbols and external modules
|
||||
--- 7.3 Symbols from another external module
|
||||
=== 8. Tips & Tricks
|
||||
|
|
@ -36,13 +36,13 @@ In this document you will find information about:
|
|||
|
||||
kbuild includes functionality for building modules both
|
||||
within the kernel source tree and outside the kernel source tree.
|
||||
The latter is usually referred to as external modules and is used
|
||||
both during development and for modules that are not planned to be
|
||||
included in the kernel tree.
|
||||
The latter is usually referred to as external or "out-of-tree"
|
||||
modules and is used both during development and for modules that
|
||||
are not planned to be included in the kernel tree.
|
||||
|
||||
What is covered within this file is mainly information to authors
|
||||
of modules. The author of an external modules should supply
|
||||
a makefile that hides most of the complexity so one only has to type
|
||||
of modules. The author of an external module should supply
|
||||
a makefile that hides most of the complexity, so one only has to type
|
||||
'make' to build the module. A complete example will be present in
|
||||
chapter 4, "Creating a kbuild file for an external module".
|
||||
|
||||
|
|
@ -63,14 +63,15 @@ when building an external module.
|
|||
For the running kernel use:
|
||||
make -C /lib/modules/`uname -r`/build M=`pwd`
|
||||
|
||||
For the above command to succeed the kernel must have been built with
|
||||
modules enabled.
|
||||
For the above command to succeed, the kernel must have been
|
||||
built with modules enabled.
|
||||
|
||||
To install the modules that were just built:
|
||||
|
||||
make -C <path-to-kernel> M=`pwd` modules_install
|
||||
|
||||
More complex examples later, the above should get you going.
|
||||
More complex examples will be shown later, the above should
|
||||
be enough to get you started.
|
||||
|
||||
--- 2.2 Available targets
|
||||
|
||||
|
|
@ -89,13 +90,13 @@ when building an external module.
|
|||
Same functionality as if no target was specified.
|
||||
See description above.
|
||||
|
||||
make -C $KDIR M=$PWD modules_install
|
||||
make -C $KDIR M=`pwd` modules_install
|
||||
Install the external module(s).
|
||||
Installation default is in /lib/modules/<kernel-version>/extra,
|
||||
but may be prefixed with INSTALL_MOD_PATH - see separate
|
||||
chapter.
|
||||
|
||||
make -C $KDIR M=$PWD clean
|
||||
make -C $KDIR M=`pwd` clean
|
||||
Remove all generated files for the module - the kernel
|
||||
source directory is not modified.
|
||||
|
||||
|
|
@ -129,29 +130,28 @@ when building an external module.
|
|||
|
||||
To make sure the kernel contains the information required to
|
||||
build external modules the target 'modules_prepare' must be used.
|
||||
'module_prepare' solely exists as a simple way to prepare
|
||||
a kernel for building external modules.
|
||||
'module_prepare' exists solely as a simple way to prepare
|
||||
a kernel source tree for building external modules.
|
||||
Note: modules_prepare will not build Module.symvers even if
|
||||
CONFIG_MODULEVERSIONING is set.
|
||||
Therefore a full kernel build needs to be executed to make
|
||||
module versioning work.
|
||||
CONFIG_MODULEVERSIONING is set. Therefore a full kernel build
|
||||
needs to be executed to make module versioning work.
|
||||
|
||||
--- 2.5 Building separate files for a module
|
||||
It is possible to build single files which is part of a module.
|
||||
This works equal for the kernel, a module and even for external
|
||||
modules.
|
||||
It is possible to build single files which are part of a module.
|
||||
This works equally well for the kernel, a module and even for
|
||||
external modules.
|
||||
Examples (module foo.ko, consist of bar.o, baz.o):
|
||||
make -C $KDIR M=`pwd` bar.lst
|
||||
make -C $KDIR M=`pwd` bar.o
|
||||
make -C $KDIR M=`pwd` foo.ko
|
||||
make -C $KDIR M=`pwd` /
|
||||
|
||||
|
||||
|
||||
=== 3. Example commands
|
||||
|
||||
This example shows the actual commands to be executed when building
|
||||
an external module for the currently running kernel.
|
||||
In the example below the distribution is supposed to use the
|
||||
In the example below, the distribution is supposed to use the
|
||||
facility to locate output files for a kernel compile in a different
|
||||
directory than the kernel source - but the examples will also work
|
||||
when the source and the output files are mixed in the same directory.
|
||||
|
|
@ -170,14 +170,14 @@ the following commands to build the module:
|
|||
O=/lib/modules/`uname-r`/build \
|
||||
M=`pwd`
|
||||
|
||||
Then to install the module use the following command:
|
||||
Then, to install the module use the following command:
|
||||
|
||||
make -C /usr/src/`uname -r`/source \
|
||||
O=/lib/modules/`uname-r`/build \
|
||||
M=`pwd` \
|
||||
modules_install
|
||||
|
||||
If one looks closely you will see that this is the same commands as
|
||||
If you look closely you will see that this is the same command as
|
||||
listed before - with the directories spelled out.
|
||||
|
||||
The above are rather long commands, and the following chapter
|
||||
|
|
@ -230,7 +230,7 @@ following files:
|
|||
|
||||
endif
|
||||
|
||||
In example 1 the check for KERNELRELEASE is used to separate
|
||||
In example 1, the check for KERNELRELEASE is used to separate
|
||||
the two parts of the Makefile. kbuild will only see the two
|
||||
assignments whereas make will see everything except the two
|
||||
kbuild assignments.
|
||||
|
|
@ -255,7 +255,7 @@ following files:
|
|||
echo "X" > 8123_bin_shipped
|
||||
|
||||
|
||||
In example 2 we are down to two fairly simple files and for simple
|
||||
In example 2, we are down to two fairly simple files and for simple
|
||||
files as used in this example the split is questionable. But some
|
||||
external modules use Makefiles of several hundred lines and here it
|
||||
really pays off to separate the kbuild part from the rest.
|
||||
|
|
@ -282,9 +282,9 @@ following files:
|
|||
|
||||
endif
|
||||
|
||||
The trick here is to include the Kbuild file from Makefile so
|
||||
if an older version of kbuild picks up the Makefile the Kbuild
|
||||
file will be included.
|
||||
The trick here is to include the Kbuild file from Makefile, so
|
||||
if an older version of kbuild picks up the Makefile, the Kbuild
|
||||
file will be included.
|
||||
|
||||
--- 4.2 Binary blobs included in a module
|
||||
|
||||
|
|
@ -301,18 +301,19 @@ following files:
|
|||
obj-m := 8123.o
|
||||
8123-y := 8123_if.o 8123_pci.o 8123_bin.o
|
||||
|
||||
In example 4 there is no distinction between the ordinary .c/.h files
|
||||
In example 4, there is no distinction between the ordinary .c/.h files
|
||||
and the binary file. But kbuild will pick up different rules to create
|
||||
the .o file.
|
||||
|
||||
|
||||
=== 5. Include files
|
||||
|
||||
Include files are a necessity when a .c file uses something from another .c
|
||||
files (not strictly in the sense of .c but if good programming practice is
|
||||
used). Any module that consist of more than one .c file will have a .h file
|
||||
for one of the .c files.
|
||||
- If the .h file only describes a module internal interface then the .h file
|
||||
Include files are a necessity when a .c file uses something from other .c
|
||||
files (not strictly in the sense of C, but if good programming practice is
|
||||
used). Any module that consists of more than one .c file will have a .h file
|
||||
for one of the .c files.
|
||||
|
||||
- If the .h file only describes a module internal interface, then the .h file
|
||||
shall be placed in the same directory as the .c files.
|
||||
- If the .h files describe an interface used by other parts of the kernel
|
||||
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
|
|||
.h files which are located under include/asm-$(ARCH)/*.
|
||||
|
||||
External modules have a tendency to locate include files in a separate include/
|
||||
directory and therefore needs to deal with this in their kbuild file.
|
||||
directory and therefore need to deal with this in their kbuild file.
|
||||
|
||||
--- 5.1 How to include files from the kernel include dir
|
||||
|
||||
When a module needs to include a file from include/linux/ then one
|
||||
When a module needs to include a file from include/linux/, then one
|
||||
just uses:
|
||||
|
||||
#include <linux/modules.h>
|
||||
|
|
@ -348,7 +349,7 @@ directory and therefore needs to deal with this in their kbuild file.
|
|||
The trick here is to use either EXTRA_CFLAGS (take effect for all .c
|
||||
files) or CFLAGS_$F.o (take effect only for a single file).
|
||||
|
||||
In our example if we move 8123_if.h to a subdirectory named include/
|
||||
In our example, if we move 8123_if.h to a subdirectory named include/
|
||||
the resulting Kbuild file would look like:
|
||||
|
||||
--> filename: Kbuild
|
||||
|
|
@ -362,19 +363,19 @@ directory and therefore needs to deal with this in their kbuild file.
|
|||
|
||||
--- 5.3 External modules using several directories
|
||||
|
||||
If an external module does not follow the usual kernel style but
|
||||
decide to spread files over several directories then kbuild can
|
||||
support this too.
|
||||
If an external module does not follow the usual kernel style, but
|
||||
decides to spread files over several directories, then kbuild can
|
||||
handle this too.
|
||||
|
||||
Consider the following example:
|
||||
|
||||
|
||||
|
|
||||
+- src/complex_main.c
|
||||
| +- hal/hardwareif.c
|
||||
| +- hal/include/hardwareif.h
|
||||
+- include/complex.h
|
||||
|
||||
To build a single module named complex.ko we then need the following
|
||||
|
||||
To build a single module named complex.ko, we then need the following
|
||||
kbuild file:
|
||||
|
||||
Kbuild:
|
||||
|
|
@ -387,12 +388,12 @@ directory and therefore needs to deal with this in their kbuild file.
|
|||
|
||||
|
||||
kbuild knows how to handle .o files located in another directory -
|
||||
although this is NOT reccommended practice. The syntax is to specify
|
||||
although this is NOT recommended practice. The syntax is to specify
|
||||
the directory relative to the directory where the Kbuild file is
|
||||
located.
|
||||
|
||||
To find the .h files we have to explicitly tell kbuild where to look
|
||||
for the .h files. When kbuild executes current directory is always
|
||||
To find the .h files, we have to explicitly tell kbuild where to look
|
||||
for the .h files. When kbuild executes, the current directory is always
|
||||
the root of the kernel tree (argument to -C) and therefore we have to
|
||||
tell kbuild how to find the .h files using absolute paths.
|
||||
$(src) will specify the absolute path to the directory where the
|
||||
|
|
@ -412,7 +413,7 @@ External modules are installed in the directory:
|
|||
|
||||
--- 6.1 INSTALL_MOD_PATH
|
||||
|
||||
Above are the default directories, but as always some level of
|
||||
Above are the default directories, but as always, some level of
|
||||
customization is possible. One can prefix the path using the variable
|
||||
INSTALL_MOD_PATH:
|
||||
|
||||
|
|
@ -420,17 +421,17 @@ External modules are installed in the directory:
|
|||
=> Install dir: /frodo/lib/modules/$(KERNELRELEASE)/kernel
|
||||
|
||||
INSTALL_MOD_PATH may be set as an ordinary shell variable or as in the
|
||||
example above be specified on the command line when calling make.
|
||||
example above, can be specified on the command line when calling make.
|
||||
INSTALL_MOD_PATH has effect both when installing modules included in
|
||||
the kernel as well as when installing external modules.
|
||||
|
||||
--- 6.2 INSTALL_MOD_DIR
|
||||
|
||||
When installing external modules they are default installed in a
|
||||
When installing external modules they are by default installed to a
|
||||
directory under /lib/modules/$(KERNELRELEASE)/extra, but one may wish
|
||||
to locate modules for a specific functionality in a separate
|
||||
directory. For this purpose one can use INSTALL_MOD_DIR to specify an
|
||||
alternative name than 'extra'.
|
||||
directory. For this purpose, one can use INSTALL_MOD_DIR to specify an
|
||||
alternative name to 'extra'.
|
||||
|
||||
$ make INSTALL_MOD_DIR=gandalf -C KERNELDIR \
|
||||
M=`pwd` modules_install
|
||||
|
|
@ -444,16 +445,16 @@ Module versioning is enabled by the CONFIG_MODVERSIONS tag.
|
|||
Module versioning is used as a simple ABI consistency check. The Module
|
||||
versioning creates a CRC value of the full prototype for an exported symbol and
|
||||
when a module is loaded/used then the CRC values contained in the kernel are
|
||||
compared with similar values in the module. If they are not equal then the
|
||||
compared with similar values in the module. If they are not equal, then the
|
||||
kernel refuses to load the module.
|
||||
|
||||
Module.symvers contains a list of all exported symbols from a kernel build.
|
||||
|
||||
--- 7.1 Symbols fron the kernel (vmlinux + modules)
|
||||
|
||||
During a kernel build a file named Module.symvers will be generated.
|
||||
During a kernel build, a file named Module.symvers will be generated.
|
||||
Module.symvers contains all exported symbols from the kernel and
|
||||
compiled modules. For each symbols the corresponding CRC value
|
||||
compiled modules. For each symbols, the corresponding CRC value
|
||||
is stored too.
|
||||
|
||||
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.
|
|||
Sample:
|
||||
0x2d036834 scsi_remove_host drivers/scsi/scsi_mod
|
||||
|
||||
For a kernel build without CONFIG_MODVERSIONING enabled the crc
|
||||
For a kernel build without CONFIG_MODVERSIONS enabled, the crc
|
||||
would read: 0x00000000
|
||||
|
||||
Module.symvers serve two purposes.
|
||||
1) It list all exported symbols both from vmlinux and all modules
|
||||
2) It list CRC if CONFIG_MODVERSION is enabled
|
||||
Module.symvers serves two purposes:
|
||||
1) It lists all exported symbols both from vmlinux and all modules
|
||||
2) It lists the CRC if CONFIG_MODVERSIONS is enabled
|
||||
|
||||
--- 7.2 Symbols and external modules
|
||||
|
||||
When building an external module the build system needs access to
|
||||
When building an external module, the build system needs access to
|
||||
the symbols from the kernel to check if all external symbols are
|
||||
defined. This is done in the MODPOST step and to obtain all
|
||||
symbols modpost reads Module.symvers from the kernel.
|
||||
symbols, modpost reads Module.symvers from the kernel.
|
||||
If a Module.symvers file is present in the directory where
|
||||
the external module is being build this file will be read too.
|
||||
During the MODPOST step a new Module.symvers file will be written
|
||||
containing all exported symbols that was not defined in the kernel.
|
||||
|
||||
the external module is being built, this file will be read too.
|
||||
During the MODPOST step, a new Module.symvers file will be written
|
||||
containing all exported symbols that were not defined in the kernel.
|
||||
|
||||
--- 7.3 Symbols from another external module
|
||||
|
||||
Sometimes one external module uses exported symbols from another
|
||||
Sometimes, an external module uses exported symbols from another
|
||||
external module. Kbuild needs to have full knowledge on all symbols
|
||||
to avoid spitting out warnings about undefined symbols.
|
||||
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.
|
|||
impractical in certain situations.
|
||||
|
||||
Use a top-level Kbuild file
|
||||
If you have two modules: 'foo', 'bar' and 'foo' needs symbols
|
||||
from 'bar' then one can use a common top-level kbuild file so
|
||||
both modules are compiled in same build.
|
||||
If you have two modules: 'foo' and 'bar', and 'foo' needs
|
||||
symbols from 'bar', then one can use a common top-level kbuild
|
||||
file so both modules are compiled in same build.
|
||||
|
||||
Consider following directory layout:
|
||||
./foo/ <= contains the foo module
|
||||
./bar/ <= contains the bar module
|
||||
The top-level Kbuild file would then look like:
|
||||
|
||||
|
||||
#./Kbuild: (this file may also be named Makefile)
|
||||
obj-y := foo/ bar/
|
||||
|
||||
|
|
@ -509,23 +510,23 @@ Module.symvers contains a list of all exported symbols from a kernel build.
|
|||
knowledge on symbols from both modules.
|
||||
|
||||
Use an extra Module.symvers file
|
||||
When an external module is build a Module.symvers file is
|
||||
When an external module is built, a Module.symvers file is
|
||||
generated containing all exported symbols which are not
|
||||
defined in the kernel.
|
||||
To get access to symbols from module 'bar' one can copy the
|
||||
To get access to symbols from module 'bar', one can copy the
|
||||
Module.symvers file from the compilation of the 'bar' module
|
||||
to the directory where the 'foo' module is build.
|
||||
During the module build kbuild will read the Module.symvers
|
||||
to the directory where the 'foo' module is built.
|
||||
During the module build, kbuild will read the Module.symvers
|
||||
file in the directory of the external module and when the
|
||||
build is finished a new Module.symvers file is created
|
||||
build is finished, a new Module.symvers file is created
|
||||
containing the sum of all symbols defined and not part of the
|
||||
kernel.
|
||||
|
||||
|
||||
=== 8. Tips & Tricks
|
||||
|
||||
--- 8.1 Testing for CONFIG_FOO_BAR
|
||||
|
||||
Modules often needs to check for certain CONFIG_ options to decide if
|
||||
Modules often need to check for certain CONFIG_ options to decide if
|
||||
a specific feature shall be included in the module. When kbuild is used
|
||||
this is done by referencing the CONFIG_ variable directly.
|
||||
|
||||
|
|
@ -537,7 +538,7 @@ Module.symvers contains a list of all exported symbols from a kernel build.
|
|||
|
||||
External modules have traditionally used grep to check for specific
|
||||
CONFIG_ settings directly in .config. This usage is broken.
|
||||
As introduced before external modules shall use kbuild when building
|
||||
and therefore can use the same methods as in-kernel modules when testing
|
||||
for CONFIG_ definitions.
|
||||
As introduced before, external modules shall use kbuild when building
|
||||
and therefore can use the same methods as in-kernel modules when
|
||||
testing for CONFIG_ definitions.
|
||||
|
||||
|
|
|
|||
|
|
@ -69,10 +69,10 @@ recompiled, or use "make C=2" to run sparse on the files whether they need to
|
|||
be recompiled or not. The latter is a fast way to check the whole tree if you
|
||||
have already built it.
|
||||
|
||||
The optional make variable CF can be used to pass arguments to sparse. The
|
||||
build system passes -Wbitwise to sparse automatically. To perform endianness
|
||||
checks, you may define __CHECK_ENDIAN__:
|
||||
The optional make variable CHECKFLAGS can be used to pass arguments to sparse.
|
||||
The build system passes -Wbitwise to sparse automatically. To perform
|
||||
endianness checks, you may define __CHECK_ENDIAN__:
|
||||
|
||||
make C=2 CF="-D__CHECK_ENDIAN__"
|
||||
make C=2 CHECKFLAGS="-D__CHECK_ENDIAN__"
|
||||
|
||||
These checks are disabled by default as they generate a host of warnings.
|
||||
|
|
|
|||
Loading…
Reference in a new issue