Linux Kernel Makefiles - - -
Linux Kernel Makefiles
This article was translated by Wang Li in May 3, 2003. Originally in Linux-2.4.20 Documentation / Kbuild / Makefiles.txt, by Michael Elizabeth Chastain
It works on September 14, 2000.
1 Overview
Makefile consists of five parts:
Makefile: Top Makefile. .config: kernel profile. Arch / * / makefile: Architecture Makefiles. Subdate Makefile: About 300. Rules.make: Provides general rules for all subdirectories Makefile.
The top Makefile reads into the .config file generated during the kernel configuration.
Top Makefile is responsible for the creation of two main products: Vminux (resident kernel image) and module (any module file). It fell by recursive to the kernel source code tree to create these goals. The subdites you need to enter are determined by the kernel configuration.
The top Makefile introduces an architecture Makefile called Arch / $ (Arch) / Makefile. Architecture makefile provides specific information for the top Makefile to provide architecture.
Each subdirectory has a Makefile to complete the command passed from the upper layer. The subdirectory Makefile uses information from the .config file to construct a list of various files, and then introduce the general rules in Rules.make.
Rules.make defines the general rules for all subdirectories Makefile. Its variable list consists of its public interface. Then it declares the rules according to these list.
2, who needs
People have four different relationships with the kernel Makefile.
Users are people who create kernels. These people enter commands such as "make MenuConfig" or "make bzimage". They usually don't read or edit kernel Makefile (or any other source code).
Ordinary developers are people developing, such as equipment drivers, file systems, or network protocols. These people need to maintain the sub-directory Makefile used for the subsystem for their developed subsystem. In order to effectively complete this maintenance task, they need some global knowledge about kernel Makefile, as well as some details about the rules.make public interface.
The architecture developer is a person who develops the entire architecture (such as SPARE or IA64). Architecture developers need to understand architecture Makefile and subdirectalog Makefile.
Kbuild developers are people who develop kernel creation system itself. These people need to know all aspects of the kernel Makefile.
This document is for ordinary developers and architectural developers.
3, Makefile Language
The kernel Makefile is designed to use GNU Make. These makefiles only use the function described by the GNU Make document, but they use a lot of GNU extensions.
GNU Make supports basic list processing functions. The kernel Makefile creates and operates in a novel list with a small amount of IF statements.
GNU Make has two assignment operators: ": =": ":" Immediately perform value to the right and store the result string in the left variable. "=" More like formulas; it is not asked The value of the value is saved on the right and the content is evaluated when using the left variable.
In some cases, "=" is more applicable. But usually ": =" is the correct choice.
All examples of this document come from the actual kernel source code. These examples have been retrograde (changed the division of the blank characters and rows), but others are exactly the same.
4, the variables passing from the top floor
Top Makefile exports the following variables:
Version, PatchLevel, SUBEVEL, Extraversion defines the current core version. Minority Architecture Makefile uses these values directly; they should use $ (kernelrelease). $ (Version), $ (PatchLevel) and $ (SUBLEVEL) define three basic version numbers, such as "2", "4", and "0". These three values are always values. $ (Extraversion) defines a lower level preparation patch or additional patch. It is usually similar to "-pre4" non-numeric string and is often empty. KernelRelease $ (kernelrelease) is a single string similar to "2.4.0-Pre4", adapted to construct the installation directory name or display in the version string. Some architecture makefile uses it for this purpose. ARCH This variable defines the target architecture, such as "I386", "ARM", or "SPARC". Many subdirectory Makefile Test $ (Arch) to decide to compile those files. By default, the top Makefile sets $ (Arch) as a host system. For cross-creation, the user can overwrite the value of $ (Arch) at the command line. Make Arch = M68k ... TOPDIR, HPATH $ (TOPDIR) is the path to the kernel source code tree top. The subdirectory Makefile requires this variable to introduce $ (TopDir) /Rules.make. $ (HPATH) equivalent to $ (TOPDIR) / Include. Minority architecture makefile requires it to use introduction files to do some special things. Subdirs $ (SUBDIRS) is the top Makefile should enter a list of directory creations created by VMLinux or module. $ (Subdir) contains those directories depend on the kernel configuration. Top Makefile defines this variable, the architecture makefile extends this variable. HEAD, CORE_FILES, NETWORKS, DRIVERS, LIBS, LINKFLAGS $ (HEAD), $ (Core_Files), $ (NetWorks), $ (Drivers) and $ (LIBS) give a list of target files and libraries to connect to VMLinux. The files in $ (head) are first connected to VMLinux. $ (Linkflags) Specifies the logo to create a VMLinux. Top Makefile and Architecture Makefile defines these variables. Top Makefile Definition $ (Core_Files), $ (NetWorks), $ (Drivers) and $ (LIBS). Architecture Makefile defines $ (head) and $ (linkflags) and extends $ (Core_Files) and $ (LIBS). Note: These variables are not necessarily necessary. $ (NetWorks), $ (Drivers) or even $ (libs) should be merged into $ (core_files). CPP, CC, AS, LD, AR, NM, Strip, Objcopy, Objdump, CPPFLAGS, CFLAGS, CFLAGS_KERNEL, MODFLAGS, AFLAGS, LDFLAGS, Perl, Genksyms These variables specify that rules.make is used to create target files from source code files. Commands and signs. $ (Cflags_kernel) contains an additional C compiler flag for compiling a resident core code. $ (MODFLAGS) contains additional C compiler flags for compiling the kernel modules. This flag may be changed to more common $ (cflags_module). $ (AFLAGS) contains assembly logos. $ (Genksyms) contains commands for generating kernel symbols when enabling config_modversions. The genksyms command is provided by the MODUTILS package. CROSS_COMPILE This variable is a prefix path such as $ (CC), $ (as), and $ (ld). Architecture Makefile sometimes explicitly uses and sets this variable. Sub-directory Makefile does not need to care.
If desired, the user can override the value of $ (cross_compile) in the command line. Hostcc, Hostcflags These variables define the C compiler and C compiler flags for compilation of programs running on local hosts. They use separate variables because the target architecture may differ from the host architecture. If your Makefile is compiled and running a program running during a kernel, it should use $ (Hostcc) and $ (HostcFlags). For example, the Drivers / PCI sub-directory contains a helper program named Gen-Devlist.c. This program reads a list of PCI IDs and generated C code called ClassList.h and Devlist.h. Assume that the user has an i386 computer and needs to create a kernel for the IA64 machine. The user should use the IA64 cross-compiler in most compilation, but you should compile Drivers / PCI / Gen-Devlist.c using the i386 local compiler. Also, the KBUILD assistant program such as Scripts / MkDep.c and Scripts / LXDialog / *. C should be compiled with $ (Hostcc) instead of $ (cc). Root_DEV, SVGA_MODE, RAMDisk end user Edits this variable to specify specific configuration information about their kernel. These variables are antiques! They can only use the I386 architecture. They really should be replaced with config_ * options. Makeboot This variable is only defined and used in the top Makefile. The top layer makefile should not export it. Install_path This variable defines the architecture Makefile should be installed there to the resident kernel image and the System.map file. Install_mod_path, MODLIB $ (install_mod_path) Specifies the prefix for the $ (MODLIB) of the module. Makefile does not define this variable, but if necessary, the user can define it. $ (MODLIB) Specifies the directory where the module installation is installed. Top Makefile defines $ (install_mod_path) / lib / modules / $ (kernelrelease). If a user can override this value in the command line. Config_shell This variable is a private variable between makefile and rules.make. Architecture makefile and subdirectory Makefile should not use it. MODVERFILE internal variable. Since it is not used outside the top Makefile, it is not necessary to export it. Make, Makefiles Some of the internal variables of GNU Make. $ (Makefiles) is especially used for the mandatory architecture Makefile and subdirectory Makefile Read $ (TOPDIR) /. Config without reverse it. (This is a solid line detail and can be corrected). 5, architecture Makefile structure
5.1, architecture specific variable
Top Makefile introduces an architecture Makefile: Arch / $ (Arch) / makefile. This section explains the function of the architecture Makefile.
Architecture Makefile uses architecture specific to extend variables of certain top Makefiles.
SubDirs top Makefile Definition $ (Subdirs). Architecture Makefile Extensions with a set of architectures. For example: # arch / alpha / makefile
Subdirs: = $ (SUBDIRS) Arch / alpha / kernel Arch / Alpha / MM Arch / Alpha / LIB Arch / Alpha / Math-EMU
This list may depend on configuration: # arch / arm / makefile
IFEQ ($ (config_arch_acorn), y)
Subdirs = drivers / acorn ...
ENDIF
CPP, CC, AS, LD, AR, NM, Strip, Objcopy, Objdump, CPPFLAGS, CFLAGS, CFLAGS_KERNEL, MODFLAGS, AFLAGS, LDFLAGS top Makefile defines these variables, and the architecture Makefile extends them. Many architectural Makefile dynamically run the target C compiler to detect the options it support: # Arch / i386 / makefile
# prevent GCC from Keeping The Stack 16 Byte Aligned
CFLAGS = $ (Shell IF $ (cc) -mpreferred-stack-boundary = 2 -s -o / dev / null -xc / dev / null> / dev / null 2> & 1; the echo "-mpreferred-stack- Boundary = 2 "; Fi)
Moreover, $ (cflags) may of course depend on the configuration:
# Arch / i386 / makefile
IFDEF Config_M386
Cflags = -March = i386
ENDIF
IFDEF config_m486
CFLAGS = -March = i486
ENDIF
IFDEF config_m586
Cflags = -MARCH = i586
ENDIF
Some architecture makefile redefines the compile command to add an architecture specific sign: # Arch / s390 / makefile
LD = $ (cross_compile) ld -m elf_s390
Objcopy = $ (Cross_Compile) Objcopy -o binary -r .note -r .comment -r
5.2, VMLinux creates variables
Architecture Makefile and top Makefile work together to define how to create variables for VMLinux files. Note that there is no corresponding architecture-specific module part; the module creation mechanism is completely independent.
HEAD, CORE_FILES, LIBS, LINKFLAGS Top Makefile defines these variables to independent of architectural structures, while architectural Makefile expands them. Note Architecture makefile definition (not just extended) $ (head) and $ (linkflags). For example: # arch / m68k / makefile
IFNDEF config_sun3
LINKFLAGS = -t $ (topdir) /arch/m68k/vmlinux.lds
Else
LINKFLAGS = -t $ (topdir) /arch/m68k/vmlinux-sun3.lds -n
ENDIF
...
IFNDEF config_sun3
Head: = Arch / m68k / kernel / head.o
Else
Head: = Arch / m68k / kernel / sun3-head.o
ENDIF
Subdirs = Arch / M68K / KERNEL ARCH / M68K / MM ARCH / M68K / LIB
Core_files: = Arch / M68K / KERNEL / KERNEL.O ARCH / M68K / MM / mm.o $ (Core_Files)
Libs = Arch / m68k / lib / lib.a
5.3, after -VMLinux
The architecture makefile defines obtaining a VMLinux file, compresses it to boot code, and copy the result file to a certain target. This includes various types of installation commands. These post-Vmlinux targets are not universal between different architectures. Below is a list of these objectives and supports their architectural structures (from the kernel version 2.4.0-test6-pre5):
balo mipsbootimage alphabootpfile alpha, ia64bzImage i386, m68kbzdisk i386bzlilo i386compressed i386, m68k, mips, mips64, shdasdfmt s390Image armimage s390install arm, i386lilo m68kmsb alpha, ia64my-special-boot alpha, ia64orionboot mipsrawboot alphasilo s390srmboot alphatftpboot.img sparc, sparc64vmlinux.64 mips64vmlinux. AOUT SPARC64ZIMAGE ARM, I386, M68K, MIPS, MIPS64, PPC, Shzimage.Initrd Ppczdisk I386, MIPS, MIPS64, SHZINSTALL ARMZLILO I386ZNETBOOT.Initrd PPC
5.4, compulsory architecture specific goals
Architecture Makefile must define the specific goals of the following architecture. These goals provide a specific work of the corresponding top-level Makefile target:
Archclean CleanarchDep DEPARCHMRPROPER MRPROPER
6, subdirectory Makefile structure
The subdirectory makefile has four parts.
6.1, note
The first part is a comment head. Many anonymous people in history have edited kernel Makefile without leaving any modified records in the head; it will be valuable from their annotations.
6.2, target definition
The second part is a set of definitions as a subdirectory Makefile core. These lines define the files that need to be created, all special compilation options, and subdirectors that must be recursively entered. The declarations of these rows seriously depend on the kernel configuration variable (config_ * symbol).
The second part looks like this:
# Drivers / Block / makefile
Obj - $ (config_mac_floppy) = Swim3.o
Obj - $ (config_blk_dev_fd) = floppy.o
Obj - $ (config_amiga_floppy) = amiflop.o
Obj - $ (config_atari_floppy) = ataflop.o
6.3, Rules.make section
The third part is only one line:
INCLUDE $ (TOPDIR) /Rules.make
6.FOUR, special rules
The fourth part contains any special Makefile rules that must be completed in the universal rules in Rules.make.
7, Rules.make variable
Rules.make's public interface consists of the following variables:
7.1, subdirectory
A Makefile is only responsible for the creation of its directory target file. The files in the subdirectory should be created by makefile in those subdirectories. As long as you let the creation system know these subdirectories, create the system automatically call Make to recursively enter the subdirectory.
To this end, use subDir- {y, m, n,} variable:
Subdir - $ (config_isdn) = i4L
Subdir - $ (config_isdn_capi) = CAPI
When creating a core, for example: Vmlinux ("Make {VMLINUX, BZIMAGE, ..."), MAKE drops recursive to the directory listed by $ (subdir-y). When the module is created ("Make Modules"), Make will drop recursive to the directory listed by $ (subdir-m).
When creating a dependency ("Make Dep"), Make needs to view all subdirectory, so it will drop to $ (Subdir-Y), $ (Subdir-n), $ (Subdir -) All subdirectories listed.
You may encounter the configuration option to "y", but you still need to create a module in that subdirectory.
For example, Drivers / ISDN / CAPI / Makefile are:
Obj - $ (config_isdn_capi) = kernelcapi.o capiutil.o
Obj - $ (config_isdn_capi_capi20) = CAPI.O
May be config_isdn_capi = y, but config_isdn_capi_capi20 = m.
This can be expressed in the following form in its parent's Makefile:
Mod-subdirs: = i4L Hisax Capi eicon
Subdir - $ (config_isdn_capi) = CAPI
Even if the subdirectory ("CAPI") appears in $ (subDir-y), the subdirector ("CAPI") occurs in the $ (MOD-SUBDIRS) variable to create a system The subdirector is entered in the process of "Make Modules".
7.2, target file objectives
O_target, OBJ-Y subdirectory Makefile specifies the target file for VMLinux in List $ (OBJ-Y). These lists depend on kernel configuration. Rules.make recompores all $ (OBJ-Y) files. Then it calls "$ (ld) -r" to merge these files into a .o file named $ (o_target). This $ (o_target) is connected to the VMLinUX from the parent Makefile. The order of the files in the $ (OBJ-Y) is important. Repeat in the allowable list: The first appearance will be connected to $ (o_target), and ignore the subsequent appearance. The connection order is important because some functions will be called in the order they appear at startup. So remember to change the connection order, for example, you may change the order in which you detect the SCSI controller, thereby changing the number of your disk. For example: # Makefile for the Kernel Isdn Subsystem and Device Drivers.
# The Target Object and module list name.
O_target: = vmlinux-obj.o
# Each Configuration Option Enables a list of files.
Obj - $ (config_isdn) = isdn.o
Obj - $ (config_isdn_pp_bsdcomp) = ISDN_BSDComp.O
# The global rules.make.
INCLUDE $ (TOPDIR) /Rules.make
7.3, library file objectives
In addition to creating an O_Target target file, you can also create a static connection library for the target files listed for $ (OBJ-Y). It usually does not have to do this, it is only used for LIB, Arch / $ (Arch) / lib directory. 7.4, can load module target
OBJ-M $ (OBJ-M) specifies the target file that can be created as the kernel module. A module can be created from one or more source code files. If it is a source code file, the subdirectory Makefile only adds the file to $ (OBJ-M). For example: OBJ - $ (config_isdn_ppp_bsdcomp) = ISDN_BSDComp.o
If the kernel module is created from multiple source code files, you specify the modules you want to create with the same way as above. However, the creation system must of course you need to know each part of the module you want to create, so you must tell it by setting the variable $ (
ISDN-OBJS: = ISDN_NET.O ISDN_TTTY.O ISDN_V110.O ISDN_COMMON.O
In this example, the module is named ISDN.O. Rules.make will include the files in $ (ISDN-OBJS), follow these files to "$ (LD) -R" to generate ISDN.O. Note: Of course, the above syntax is still valid when you create the target file to the kernel. So, if your config_isdn = y, the creation system will follow you expect, create isDN.o from each part, and then connect it to $ (o_target).
7.5, target file with export symbol
Export-Objs When using the loaded module, not all kernel / other modules are automatically available, your module can only use those explicitly exported symbols. In order to allow modules to use a symbol, "export" it, use export_symbol in the source code.
). In addition, you have to list files for all export symbols (eg, containing the export_symbol () instructions in Makefile Variable $ (Export-Objs).
E.g:
# Objects That Export Symbols.
Export-objs: = ISDN_COMMON.O
This is because ISDN_COMMON.C contains export_symbol (register_isdn);
This allows the underlying ISDN driver to use the function register_isdn.
7.6, compile sign
Extra_cflags, extra_aflags, extra_ldflags, extra_ARFlags $ (extra_cflags) specifies options for compiling C files with $ (c). The options in this variable are used in the current directory to compile the $ (cc) command for all files. For example: # Drivers / Sound / EMU10k1 / Makefile
EXTRA_CFLAGS = -i.
IFDEF Debug
EXTRA_CFLAGS = -demu10k1_debug
ENDIF
The subdirectory of the current directory does not use $ (extra_cflags). In addition, it is not used for files compiled by $ (Hostcc). Since the top Makefile has variable $ (cflags) and the variable is used for the entire source tree, $ (extra_cflags) is required. $ (Extra_aflags) is a similar single directory option string for compiling assembly language source code. Example: When writing this article, there is no example of $ (extra_aflags) in the kernel source code. $ (Extra_ldflags) and $ (extra_arflags) for similar individual directory option strings for $ (ld) and $ (ar). Example: An example of (extra_ldflags) or $ (extra_arflags) is not used in the kernel source code. CFLAGS _ $ @, Aflags _ $ @ $ (cflags _ $ @) Specifies a $ (cc) option for a single file. The value of $ @ part is a string of the file name to specify. For example: # drivers / scsi / makefilecflags_aha152x.o = -daha152x_stat -dautoconf
Cflags_gdth.o = # -ddebug_gdth = 2 -d__serial__ -d__com2__ -dgdth_statistics
Cflags_seagate.o = -darbitrate -dparity -dseagate_use_asm
These three rows are specified in AHA152X.O, GDTH.O and Seagate.o, respectively. $ (Aflags _ $ @) gives a similar option for compiling assembly language source files. For example: # arch / arm / kernel / makefile
AFLAGS_HEAD-ARMV.O: = -dtextaddr = $ (textddr) -traditional
AFLAGS_HEAD-ARMO.O: = -dtextddr = $ (textdr) -traditional
Rules.make has the function of the target file depends on the value used to compile its value of $ (cflags _ $ @). Therefore, if you change the value of $ (cflags _ $ @) for a file, whether editing makefile or otherwise overwriting the original value, Rules.make works correctly and recompiles your new options. Source code. Please note: Due to the defect of Rules.make, the assembly language is not marked dependence. If you edit $ (AFLAGS _ $ @) for a file, you must delete the target file to recreate it from the source file. LD_RFLAG uses but never defined the variable. This seems to be a description of some abandoned trial.
7.7, other variables
Ignore_flags_objs $ (ignore_flags_objs) is a list of target files that cannot be automatically tracked automatically. This is a supplement, which is used to process issues in implementing a dependent flag. (The problem is that the logog-dependent assumption% .o file is created from a matching% .S or%. Sometimes not this). Use_standard_as_rule This is a transition variable. If you define $ (using_standard_as_rule), Rules.make is a% .o file or% .s file (% .s file only) provides standard rules only. If no $ (user_standard_as_rule) is defined, Rules.make does not provide these standard rules. In this case, the subdirectory Makefile must provide its private rules for the compilation% .s file. In the past, all Makefile provided private% .s rules. Newer Makefiles should define Use_standard_as_rule and use standard Rules.make rules. Once all Makefiles in all architectures are used using use_standard_as_rule, Rules.Make can cancel the test of Use_standard_as_rule. Thereafter, all other makefiles can cancel the definition of use_standard_as_rule. 8, new style variable
[This chapter is back to the way Makefile writes the previously described Makefile as "new style". Since other words, it still shows the same thing, so I have kept this saying, this may be some useful.
"New style variable" is more simple and more effective than "old style variable". Therefore, many subdirectory Makefile can be reduced by 60%. The author hopes that all architecture makefile and subdirectories makefile can be converted to new style.
Rules.make does not understand new style variables. Therefore, each new style Makefile has a model code portion to convert new style variables to old-style variables. This is a bit confusing, and people define most variables in "new style" but the last few lines have fallen into the "old style".
8.1, new variable
OBJ-Y OBJ-M OBJ-N OBJ - These variables replace $ (O_OBJS), $ (OX_OBJS), $ (M_OBJS) and $ (MX_OBJS). For example: # drivers / block / makefile
Obj - $ (config_mac_floppy) = Swim3.o
Obj - $ (config_blk_dev_fd) = floppy.o
Obj - $ (config_amiga_floppy) = amiflop.o
Obj - $ (config_atari_floppy) = ataflop.o
Note that this is replaced on the left side of the assignment operator with $ (config _...). This makes the GNU Make have the ability to combine indexes! Each such assignment replaces the eight-row code in the old style Makefile. After performing all assignments, subdirectalog Makefile created four lists: $ (OBJ-Y), $ (OBJ-M), $ (OBJ-N) and $ (OBJ-). $ (OBJ-Y) is a list of files contained in VMLinux. $ (OBJ-M) is a list of files created as a separate module. Ignore $ (OBJ-N) and $ (OBJ-). Each list may contain repetitive items; the deduplicated items will be automatically deleted. The files in $ (OBJ-Y) and $ (OBJ-M) are simultaneously appearing will be automatically removed from the $ (μ) list. Example: # drivers / net / makefile
...
Obj - $ (config_oaknet) = OakNet.O 8390.O
...
Obj - $ (config_ne2k_pci) = ne2k-pci.o 8390.o ...
Obj - $ (config_stnic) = STNIC.O 8390.O
...
Obj - $ (config_mac8390) = daynaport.o 8390.o
...
In this example, four different drivers require code in 8390.o. If one or more of these four drivers To create into VMLinux, even if other drivers are 8390.o as a module, 8390.o is created to VMLinUX instead of becoming a module. (Modular drivers can use services provided by 8390.o code in the VMLinux image). Export-Objs $ (Export-Objs) is a list of files that may export symbols in the subdirectory. The specification method for constructing the list is: grep -l export_symbol * .c
(But see those files that secretly call export_symbol in the introduction of headers!) This is a list of possible lists, independent of kernel configuration. $ (Export-Objs) lists all export symbols. The post-sample code is divided into $ (* _ OBJS) and $ (* x_objs) with $ (export-objs). Experience shows that maintaining a correct X variable in the old style Makefile is difficult and easy to go wrong. Maintenance $ (Export-Objs) in new style makefile is relatively simple and easy to check. $ (foo) -Objs Some kernel modules consist of multiple target file connections. For each multi-segment kernel module, there is a list listing all target files that make up the module. For kernel modules named foo.o, its target file list is Foo-Objs. For example: # Drivers / SCSI / Makefile
List-multi: = SCSI_MOD.O SR_MOD.O INITIO.O A100U2W.O
...
scsi_mod-objs: = hosts.o scsi.o scsi_ioctl.o constants.o scsicam.o scsi_proc.o scsi_error.o scsi_obsolete.o scsi_queue.o scsi_lib.o scsi_merge.o scsi_dma.o scsi_scan.o scsi_syms.o
SR_MOD-OBJS: = Sr.O SR_IOCTL.O SR_VENDOR.O
INITIO-OBJS: = ini9100u.o i91uscsi.o
A100U2W-OBJS: = inia100.o i60uscsi.o
Subdate Makefile will add modules to OBJ- * lists in common configuration: OBJ - $ (config_scsi) = SCSI_MOD.O
Obj - $ (config_blk_dev_sr) = SR_MOD.O
Obj - $ (config_scsi_initio) = INitio.o
Obj - $ (config_scsi_inia100) = a100u2w.o
Suppose config_scsi = y. Then VMLinux needs to connect its 14 components to SCSI_MOD.O. Assume config_blk_dev_sr = m. Then, the three components of SR_MOD.O are connected to the "$ (LD) -r" connection to constitute the kernel module SR_MOD.O. Suppose config_scsi_initio = n. Then Initio.o enters the $ (OBJ-N) list and this is its endpoint. It does not compile its component files, nor does it create a combined file. Subdir-Y Subdir-M Subdir-N Subdir-These variables replace $ (all_sub_dirs), $ (sub_dirs) and $ (MOD_SUB_DIRS). For example: # Drivers / MakeFileSubdir - $ (config_pci) = PCI
Subdir - $ (config_pcmcia) = PCMCIA
Subdir - $ (config_mtd) = MTD
Subdir - $ (config_sbus) = SBUS
These variables operate in a way similar to OBJ- *, but used for subdirectories instead of the target file. After all assignments are completed, the subdirectory makefile consists of four lists: $ (subdir-y), subsidir-m), $ (subdir-n) and $ (subdir-). $ (subDir-y) is a list of subdirectors that should be entered when creating VMLinUX. $ (subdir-m) is a list of subdirectors that should be entered when creating a module. $ (subDir-n) and $ (subdir-) are only used to collect a list of all subdirectories of this directory. Each list other than SUBDIR-Y may contain repetitive items; the repetition item will be automatically deleted. MOD-SUBDIRS $ (MOD-SUBDIRS) is a list of subdirectories that have been added even in $ (subdir-y). For example: # fs / makefile
MOD-SUBDIRS: = NLS
This means that if config_nls = y, NLS should join $ (subDir-y) and $ (subdir-m).
9, thank you
Thanks to members of the Linux-KBUILD mailing list to review this document and give special thanks to Peter Samuelson and Thomas Molina.
