"Learning Notes" compiles the Linux kernel (next)---kconfig, makefile, and the compilation of the Linux kernel on the arm platform __linux

This paper mainly introduces the kernel configuration system of Linxu2.6.

If you browse the source directory, you can see that there are a lot of kconfig files and makefile files in the source directory and its subdirectories. What's the effect of these files? It is these files that make up the Linux2.6 kernel configuration system.

one, make menuconfig behind------the organization of the Kconfig file

Have you ever thought about how the list of menus that were displayed after we make menuconfig.

With this question, let's start with a simple "syntax" for kconfig files.

Source Keyword:

Usage: source <filename>

This keyword is equivalent to the "include" keyword in C, source followed by a filename, which is equivalent to copy the contents of the file to the current location. The following is part of the Kconfig file in the Arch/arm directory of the source directory.

With this source reference, you can introduce kconfig files from many other subdirectories, and in the Kconfig files that you introduce, you can continue to introduce the next level of kconfig files through source. Such a structure can include all the kconfig files in it.

the basic composition of a menu item (or configuration item): Config, bool (tristate), default, prompt, help

A simple menu item:

Where the Config keyword indicates that a new menu item is defined, followed by the name of the item (ARCH_IXP23XX). BOOL identifier This menu item is bool type, that is, this item can only have two values Y and N, in addition there is one of the most commonly used types, tristate, this type can have three values, y/m/n, the meaning of these three values in the (above) chapter has been said. The following "ixp23xx-based" is a description of the menu item, which is what we can see when make menuconfig, as shown here:

In the menu list we can not see the name of a menu item, but only to see its description, because it is more convenient for us to understand the meaning of this menu item, convenient for us to configure. For a description of the menu item, there is also a prompt keyword, illustrating its usage. For example, the following two paragraphs are equivalent

----------------------------------

CONFIG My_menu

bool

Prompt "This is my menu"

----------------------------------

CONFIG My_menu

BOOL "This are my Menu"

----------------------------------

That is, a menu item description can be declared directly after its type (bool), or by the prompt keyword.

With regard to the default keyword, the screenshot does not appear, but is also commonly used, indicating the default value of a menu item. Such as

Default Y

When you go to the menu list, you can see that many menu items have default values that are defined by default in the Kconfig file.

There is also a help keyword, which is followed by helpful information that is displayed when we click on the HEIP in the lower right corner to help with this menu item. The following are help information about the menu items shown in the illustration above:

dependencies between menu items: Select and depends on

Also take the example above to illustrate that the third line "depends on MMU". This line says that the value of the menu item defined now (y/n) depends on the value of the MMU menu item (arch_ixp23xx). When MMU this menu item is N, arch_ixp23xx can only be n. The value of the arch_ixp23xx must be "less than" the MMU value. (for bool type,y>n; for tristate type, y>m>n).

The SELECT keyword works just as opposed to depends on, and it describes an inverse dependency relationship. Take the fifth line, "select PCI," as an example, the value of PCI depends on arch_ixp23xx. When you define a PCI menu item, add the phrase "depends on arch_ixp23xx".

Depending on the dependencies between the menu items, when make menuconfig, the system automatically collates the associated menu items into the form of menu items and submenu items, as shown below

The menu items in the second picture depend on the menu item "Enable The block layer", so the system collates them into submenu items. These submenu items can be configured only if the "Enable" block layer corresponds to a menu item that is not n.

menu and Endmenu keywords

This keyword is designed to group menu items so that the menus are more structured. menu is used to define a submenu that includes some related menu items, which are part of the submenu defined between the menus and the Endmenu keyword. Take the above two graphs for example, "system type--->" under "Enable The Block Layer----->" menu item is the name of a submenu. Expand this submenu to see the menu items that the submenu contains.

Menu ' System type '

Config ...

............

Config ...

............

Config .....

............

............

Endmenu

Here's an extra explanation, in the figure above, "Enable The block layer--->" and "System Type-->", which, although they look alike, can be unfolded, but their nature is different. The former is based on the dependencies between the menu items, "Enable The Block layer" itself corresponds to a menu item or configuration item, it also has its own value (y/m/n), and "system type" is just a submenu name, It contains a number of related configuration items, but he does not itself have a configuration item, so there is no value (so the symbols for "system type--->" In the menu list are not preceded by * or M).

choices and Endchoice keywords

As with menu and endmenu usage, the only difference is that multiple menu items in a choices defined "submenu" (which should be called an option table) can only be selected, which is equivalent to a menu that defines a selectable submenu, choices defines a single submenu. Space limit, no more screenshots in detail.

if and endif keywords

These two really do not need to explain, forgive me directly skip.

Comment keyword

Used to insert a line of text into a menu list, also to optimize the menu structure.

As the fourth to fifth line in the previous illustration, it is inserted by comment "Processor Type" and comment "Processor Features". These two lines can neither be expanded nor configured, they are just a line of text that is segmented for the menu list.

Finally put the key words in the kconfig the interpretation of the word is finished, so tired ah. (Many textbooks and blogs on the introduction of these keywords are only text descriptions, and do not combine make menuconfig after the appearance of the menu interface to explain that the reading is not intuitive, and now I put these out for beginners to quickly grasp and understand the role of these keywords). You can now try to read a kconfig file.

OK, now that we have an understanding of these keywords, let's take a look at the formation of this menu list. After running make menuconfig, the system's configuration tool first analyzes the/arch/arch/kconfig corresponding to the architecture
The file (the Arch argument that appears here is at the end of this article). It actually refers to the <cpu> that is used, and the/arch/arch/kconfig file defines a main menu MainMenu, which, in addition to some configuration items and configuration menus, Kconfig files in a series of other subdirectories are also referenced through the source statement, and the Kconfig file referenced inside may again introduce kconfig in the next level of directory through source. The system creates a menu list based on the menu items (configuration items) contained in all of these kconfig files, and then builds the. config file based on the values that the user sets for each menu item.

second, another important role------introduction of Kbuild Makefile

The Kconfig file helps the user complete the configuration process, while the true compilation kernel is done in a series of makefile in each subdirectory. The important grammar in Makefile is three, it is better to understand, here directly refers to the contents of the book. I marked the places needing attention in bold.

From the Huaqing Vision Embedded Training Center Song Baohua authored the "Linux Device Driver Development detailed" (This book is really good, need the electronic version of colleagues can directly contact me):

(1) Target definition.
A goal definition is used to define which content to compile as a module and which to compile and connect to the kernel.
For example:
Obj-y + + FOO.O
Represents the foo.o to be compiled by a foo.c or Foo.s file and connected to the kernel, while obj-m indicates that the
Files are compiled as modules. Targets in obj-x form other than Y and M are not compiled.
The more common approach is to determine how the file is compiled based on the config_ variable of the. config file, such as
Shown below:
obj-$ (CONFIG_ISDN) + + ISDN.O
obj-$ (Config_isdn_ppp_bsdcomp) + + ISDN_BSDCOMP.O
In addition to the obj-form of the target, there are lib-y library, hostprogs-y host program, and other targets, but
are basically applied to specific directories and situations.
(2) The definition of multi-file module.
If a module consists of multiple files, this should take the form of a module name plus a-objs suffix or a-y suffix.
To define a module's constituent file. As shown in the following example:
obj-$ (CONFIG_EXT2_FS) + + EXT2.O
Ext2-y: = BALLOC.O BITMAP.O
ext2-$ (config_ext2_fs_xattr) + + XATTR.O
The module is named Ext2, and the final connection of the BALLOC.O and BITMAP.O two target files is generated ext2.o straight
To Ext2.ko file, whether including XATTR.O depends on the configuration of the kernel configuration file. If
The value of CONFIG_EXT2_FS is not related to Y, and the ext2.o generated during this process will be connected into
The BUILT-IN.O is eventually connected to the kernel. One thing to be aware of here is thatin the directory where the Kbuild makefile resides
Source files, such as EXT2.C/EXT2.S, that are the same as the module name can no longer be included.
Or in a form as-OBJS:
obj-$ (CONFIG_ISDN) + + ISDN.O
ISDN-OBJS: = ISDN_NET_LIB.O isdn_v110.o ISDN_COMMON.O
(3) An iteration of the directory hierarchy.
Example:
obj-$ (CONFIG_EXT2_FS) + + ext2/
When the value of Config_ext2_fs is Y or M, Kbuild will include the Ext2 directory in the next iteration of the
Target, the file in the specific ext2 directory is to be compiled as a module or chained to the kernel by the ext2 directory
The content of the makefile file is decided.

End of reference.

The above mentioned (3) is particularly critical, the directory-level iteration makes the entire makefile system a tree-like structure, clear, and load the new compilation directory is also very convenient.

third, the preliminary examination

If we have developed a new module ourselves, how can we add our own modules to the configuration system? The basic syntax for kconfig and makefile files is described above, and to make sure that we have a way to configure the two files, we'd better do some practice. Here I want to be lazy again, directly copy the contents of the book.

Reference start:

Here is a comprehensive example, assuming that we want to be in the kernel source code drivers directory for the arm system knot
Add the following tree directory for test driver:
|--test
|--CPU
| --CPU.C
|--TEST.C
|--TEST_CLIENT.C
|--TEST_IOCTL.C
|--TEST_PROC.C
|--TEST_QUEUE.C
Adding directories and subdirectories to the kernel, we need to create kconfig and makefile for the corresponding new directories
Files, and the Kconfig and makefile files in the parent directory of the new directory also need to be modified so that the new
Kconfig and Makefile files can be referenced.
Under the new test directory, you should include the following kconfig files:
#
# TEST Driver Configuration
#
Menu "TEST Driver"
Comment "TEST Driver"
Config config_test
BOOL "TEST Support"
Config Config_test_user
TriState "TEST User-space Interface"
Depends on Config_test
Endmenu
Since test driver is a new feature for the kernel, you first need to create a menu test
Driver, then displays "Test support", waits for the user to select, and then determines whether the user chooses test
Driver, if it is (config_test=y), further displays the Sub function: User interface and CPU functional support
Because the user interface function can be compiled into a kernel module, the query statement here uses TriState.
To make this kconfig file work, you need to modify the Arch/arm/kconfig file to add the following
Capacity:
SOURCE "Drivers/test/kconfig"
Source in the script means that the new Kconfig file is referenced.
Under the new test directory, you should include the following makefile files:
# Drivers/test/makefile
#
# Makefile for the TEST.
#
obj-$ (config_test) + = TEST.O TEST_QUEUE.O TEST_CLIENT.O
obj-$ (Config_test_user) + + TEST_IOCTL.O
obj-$ (CONFIG_PROC_FS) + + TEST_PROC.O
obj-$ (CONFIG_TEST_CPU) + + cpu/
The script builds the obj-* list based on the value of the configuration variable. Because the test directory contains a subdirectory CPU,
When Config_ test_cpu=y, you need to add the CPU directory to the list.
The CPU subdirectory in the test directory also needs to include the following makefile file:
# Drivers/test/test/makefile
#
# Makefile for the TEST CPU
#
obj-$ (CONFIG_TEST_CPU) + + CPU.O
To enable the entire test directory to be compiled, the makefile text in the parent directory of the test directory
Pieces also need to add the following script:
obj-$ (config_test) + + test/
Add obj-$ (config_test) + = test/in Drivers/makefile to enable the user to make the kernel
Can enter the test catalogue when translating.
The new test tree directory after adding the Kconfig and makefile files is as follows:
|--test
|--CPU
| --CPU.C
| --Makefile
|--TEST.C
|--TEST_CLIENT.C
|--TEST_IOCTL.C
|--TEST_PROC.C
|--TEST_QUEUE.C
|--Makefile
|--Kconfig

attached: (Arch parameter in top makefile, method of compiling arm platform Linux kernel)

The makefile file in the top-level directory of the source code directory is called the top-level makefile, which involves an arch parameter and a cross_compile parameter corresponding to the processor kernel architecture and the crossover compiler. In general, arch defaults to x86,cross_compile the default is the cross compiler on the x86 platform. When you perform commands such as make Menuconfig,make bzimage,make modules, the system first analyzes the value of arch and performs the action according to the selected platform. Therefore, if you want to compile the Linux kernel of the ARM platform, add the schema and the cross compiler option when you enter the command, as

Make Arch=arm Cross_compile=arm-linux-menuconfig

Make Arch=arm Cross_compile=arm-linux-bzimage

Make Arch=arm Cross_compile=arm-linux-modules

If you direct the

Arch=arm

cross_compile=arm-linux-

These two lines add the beginning of the top-level makefile, and you can change the arch and Cross_compile defaults to "arm" and "arm-linux-". When you compile the Linux kernel of the arm platform later, you can use the commands such as make menuconfig/bzimage/modules, without adding "Arch=arm cross_compile=arm-linux-".