Makefile, Kconfig, .config, kbuild makefiles involved in kernel compilation in linux

Preface

There are generally two files in the kernel source directory, one is the Makefile file, and the other is the Kconfig file. What about the .config file? In fact, it is an intermediate product. This file will be generated after make menuconfig. The menuconfig option is actually written in the Kconfig file, and the Makefile tells the compiler how to compile and how to generate the modules or results we want.

relationship:

  • Makefile: A text file containing some rules to tell make which files to compile and how to compile these files.
  • .config: The file is the kernel compilation reference file generated after configuration during kernel configuration.
  • Kconfig: A file in text form, which is mainly used as a configuration option when configuring the kernel.
  • make: make is a program software under linux. Makefile is equivalent to the configuration file for make program. When we execute the make command, make will look for the Makefile in the current directory, and then compile the source file according to the configuration of the Makefile.
  • kbuild makefiles: Each module is compiled separately and then linked, so this kind of kbiuld makefile exists in almost every module. In these module files (subdirectories), you can also use Kbuild files instead of Makefiles. When the two exist at the same time, the Kbuild file is preferred for compilation, but the user habitually uses the Makefile to name it.

The approximate sequence relationship of the three:

  • We have written Kconfig—>make menuconfig---->generate.config----->write Makefile---->compile according to Makefile compilation rules---->compile successfully

Instance

Let's take an example to analyze:
Let 's cat the Kconfig file:

config SCSI_UFS_CRYPTO_QTI
	tristate " specific UFS Crypto Engine Support"
	depends on SCSI_UFS_CRYPTO
	help
	 Enable  Support in UFS
	 Enabling this allows kernel to use UFS crypto operations defined
	 and implemented by QTI.
	 
source "driver/vfio/pci/Kconfig”

From the above information, we can see the file name , purpose , dependent modules , help information, etc. Of course, this information is not general and comprehensive. When we enter make menuconfig under the shell, we can see the SCSI_UFS_CRYPTO_QTI option. , Input y means to compile the kernel; input n means not to compile; input m means to write a module.
In the tristate part, it belongs to option, and there are other options:

bool:布尔类型, tristate三态:内建、模块、移除, string:字符串, hex:十六进制, integer:整型

Example 1:

config hello
bool "hello test module"

For options of tristate type, if you choose to compile into a kernel module, a CONFIG_HELLO=m configuration will be generated in .config. If you choose built-in, it will be directly compiled into the kernel, and a CONFIG_HELLO=y will be generated in .config Configuration.
Example 2:
Dependent definition depends on or requires refers to whether the appearance of this menu depends on another definition

config HELLO_MODULE
bool "hello test module"
depends on ARCH_PXA

The menu item HELLO_MODULE is only visible (configurable) when ARCH_PXA is selected.
Example 3: Kconfig directory hierarchy iteration
in Kconfig

source "driver/vfio/pci/Kconfig”

Such statements are used to nest Kconfig files in subdirectories or other directories. The advantage of this is that different directories manage their own configuration options instead of writing them all in the same file.
Example 4:
Help definition, add the help keyword help or —help—

help
	 Enable  Support in UFS
	 Enabling this allows kernel to use UFS crypto operations defined
	 and implemented by QTI.


Let's cat the Makefile :

obj-$(CONFIG_UFS_DWC_TC_PCI) += tc-dwc-g210-pci.o ufshcd-dwc.o tc-dwc-g210.o
obj-$(CONFIG_UFS_DWC_TC_PLATFORM) += tc-dwc-g210-pltfrm.o ufshcd-dwc.o tc-dwc-g210.o
obj-$(CONFIG_UFS_QCOM) += ufs-qcom.o
obj-$(CONFIG_UFSHCD) += ufshcd-core.o
ufshcd-core-y := ufshcd.o
obj-$(CONFIG_UFSHCD_PCI) += ufshcd-pci.o
obj-$(CONFIG_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
obj-$(CONFIG_UFS_TEST) += ufs_test.o
obj-$(CONFIG_FOO) += foo/ 
obj-$(CONFIG_MEMORY_SYSFS) 	+= memory.o
mi_memory-$(CONFIG_MEMORY) += memory_sysfs.o
mi_memory-$(CONFIG_MEMORY) += ufs_info.o
mi_memory-$(CONFIG_MEMORY) += dram_info.o

Seeing the confusion above, we disassemble it and analyze it:
If it is a simple module compilation:

obj-$(CONFIG_UFS_TEST) += ufs_test.o

There is no problem writing this way.
If the module we compile needs to rely on multiple source files, such as this:

obj-$(CONFIG_MEMORY_SYSFS) 	+= memory.o
mi_memory-$(CONFIG_MEMORY) += memory_sysfs.o
mi_memory-$(CONFIG_MEMORY) += ufs_info.o
mi_memory-$(CONFIG_MEMORY) += dram_info.o

According to the configuration attribute of CONFIG_MEMORY to decide whether to generate memory.o, and then according to the attribute of CONFIG_MEMORY_SYSFS to decide whether to incorporate the memory.o module into the kernel or as a module.
If CONFIG_MEMORY_SYSFS has been configured as y (programmed into the kernel), the code can be written like this:

obj-y += memory.o
mi_memory-$(CONFIG_MEMORY) += memory_sysfs.o
mi_memory-$(CONFIG_MEMORY) += ufs_info.o
mi_memory-$(CONFIG_MEMORY) += dram_info.o

If the same conditions permit, you can also write:

obj-y += memory.o
mi_memory-m += memory_sysfs.o
mi_memory-m += ufs_info.o
mi_memory-m += dram_info.o

There is a principle that needs to be understood: makefile is only responsible for processing the compilation relationship in this directory, and the compilation of files in other directories is responsible for the makefiles in other directories. The makefile of the entire linux kernel forms a tree structure. For the subdirectories of the upper makefile, only You need to let kbuild know how it should enter the directory recursively.

There is also such a statement: kbuild uses directory designation to perform directory designation operations

obj-$(CONFIG_FOO) += foo/ 

When CONFIG_FOO is configured as y or m, kbuild will enter the foo/ directory, but it should be noted that this information only tells kbuild which directory should be entered, and does not give any guidance on the compilation in the directory.

Add a bsp source file

  • The first step: add the hello.c file to the ~bin/kernel/following:
  • Step 2: Modify ~bin/kernel/Kconfig in the directory:
config HELLO 
 tristate “HELL"

So when make menuconfig, the HELL option will appear, if you choose this option. The selection will be saved in the .config file.

  • Step 3: Modify the ~bin/kernel/Makefile:
obj-$(CONFIG_HELLO ) +=hello.o

When you compile the kernel, you will read the .config file. When the hello option is found to be yes, the system ~bin/kernel/will add hello.o to the kernel when the makefile is called .

Add a bsp folder and add source files in the folder

If you ~bin/kernel/create a file folder HELLO, folder and add hello.c and Makefile Kconfig how to add it?

  • Through the above explanation, you should be able to add it yourself, that is, you can add the configuration and compilation paths to the Makefile and Kconfig at this level, and create your own Makefile and Kconfig in the newly created folder.

In a description of a wide range of Makefile :
The Makefile of the 2.6 kernel is divided into 5 parts:

        * 最顶层的Makefile(在编译之前可更改上面几行版本名字,这样生成的新内核就是特定的名字)
        * 内核的.config配置文件

        * 在arch/$(ARCH)目录下的体系结构相关的Makefile

        * 在s目录下的Makefile.*文件,是一些Makefile的通用规则

        * 各级目录下的大概约500个kbuild Makefile文件

      顶层的Makefile文件读取.config文件的内容,并总体上负责build内核和模块,各级体系架构的

      Makefile负责架构相关的信息。s目录下的Makefile文件包含了所有用来根据kbuild Makefile

      构建内核所需要的定义和规则。

Guess you like

Origin blog.csdn.net/weixin_42271802/article/details/109459354