Kconfig file structure analysis in Android kernel driver development (image and text)

References:

Http://www.ylmf.net/zhuanti/zt02/2010/1108/8747.html

Http://www.linuxdiyf.com/viewarticle.php? Id = 107960

Http://wenku.baidu.com/view/9b156d1f650e52ea55189852.html

Http://wenku.baidu.com/view/0f36597f27284b73f2425024.html? From = related & hasrec = 1

1. kconfig and makefile

To put it bluntly, kconfig and makefile are the two most dependent files when we browse kernel code. Basically, there will be a kconfig file and a MAKEFILE file under each directory in the Linux kernel. Kconfig and makefile are like map of a city. Maps guide us to know a city, while kconfig and makefile allow us to understand the structure under a kernel directory. To study a subsystem, driver, or other part of the kernel, you must first carefully read the kconfig and makefile files in the relevant directory.

The kconfig distributed to each directory constitutes a distributed Kernel configuration database. Each kconfig describes the Kernel configuration menus related to the source document of the directory. When you configure make menuconfig in the kernel, read the menu from kconfig and save it to the Kernel configuration document of. config. When the kernel is compiled, the main makefile calls this. config, and the user's choice is known.

If you want to compile the driver, you need to modify the MAKEFILE file. Therefore, when you need to add a new driver, you need to modify two files: kconfig and makefile.

2. menu structure

A kconfig file represents a menu. A menu consists of multiple menu items. The format is as follows:

Menu name menu item or menu link 1 menu item or menu link 2... menu item or menu link nendmenu

The menu item refers to the sub-menu of the menu, and the so-called menu link refers to the link to another kconfig file, so that the menu can be nested at will.

For example:

# Drivers/kconfigmenu "device drivers" Source "Drivers/base/kconfig" Source "Drivers/connector/kconfig" Source "Drivers/MTD/kconfig" Source "Drivers/of/kconfig" source "Drivers/parport/kconfig" Source "Drivers/PNP/kconfig" Source "Drivers/block/kconfig" Source "Drivers/Hello/kconfig" Config test bool "prompt string" default "y... endmenu

2.1 menu items

Syntax:

config <symbol><config options>

<Symbol> it is a symbol, just like the local variable X in the code, which can be used in the following expression.

For example:

config UEVENT_HELPER_PATH       string "path to uevent helper"       depends on HOTPLUG       default "/sbin/hotplug"       help  Path to uevent helper program forked by the kernel for  every uevent.

The property string of the preceding menu item indicates the menu type. Each menu item must have a type.

Note: Each config menu item generates a configuration option config_xxx, Which is <symbol>. as shown above, a configuration item config_uevent_helper_path is generated. The value of this configuration item is recorded in the hidden file under the kernel root directory. in config, for example :~ /Working_directory/kernel/goldfish/. config file.

2.2 menu Link

The menu link format is as follows:

Source "path"

For example:

source "drivers/pnp/Kconfig"

2.3 menu Properties 2.3.1 type

Type: bool, tristate, String, Hex, and Int.

The bool type can only be selected or not. If it is not selected, it is selected as Y. If it is not selected, it is N.

A menu item of the tristate type can be set to three values, with the option of compiling to a kernel module added. The value can be y, n, m.

String type indicates that you need to enter a string.

For the hex type, you must enter a hexadecimal number.

Int type indicates that the user enters an integer.

Summary:

The menu type attribute is like a control. bool is equivalent to a single checkbox, trstate is equivalent to a check box with three states, and string is equivalent to a text edit box for the user to enter a string, hex is equivalent to a text editing box that allows users to enter hexadecimal numbers, while int is equivalent to a text editing box that allows users to enter integer numbers.

Type keywords can follow the prompt characters or do not follow, depending on the situation. For example:

string "path to uevent helper"

bool "Prevent firmware from being built"

Note: Each menu item must have a type attribute.

2.3.2 Default Value

The default value property default is generally behind the type property, for example:

config UEVENT_HELPER_PATHstring "path to uevent helper"default "/sbin/hotplug"

Indicates the default value of the current menu item if you do not select or enter any value. The default value is "/sbin/totplug ".

2.3.3 dependency

The dependency can be "depends on" or "requires ".

Syntax:

depends on/requires <expr>

<Expre> is an expression and can be the name of the previously defined menu item.

For example:

depends on HOTPLUG

Whether or not this menu item is displayed depends on another menu item hotplug. The current menu item is displayed only when the menu item hotplug is effectively displayed.

For example:

    config MODULES          bool "Enable loadable module support"           config MODVERSIONS          bool "Set version information on all module symbols"          depends on MODULES               comment "module support disabled"          depends on !MODULES 

Whether the menu item modversions is displayed depends on the menu item modules. This trust relationship is often used in sub-menu items.

2.3.4 select

Syntax:

Choice selection item. endchoice

2.3.5 prompt

Syntax:

Comment "prompt message string" comment Option

Comment is only used to prompt the user, followed by a string, which can also be displayed on the terminal.

The comment option can only be deponds on.

2.3.6 help

Syntax:

Help/--- help --- <string>

For example:

config EXTRA_FIRMWARE_DIRstring "Firmware blobs root directory"depends on EXTRA_FIRMWARE != ""default "firmware"help  This option controls the directory in which the kernel build system  looks for the firmware files listed in the EXTRA_FIRMWARE option.  The default is the firmware/ directory in the kernel source tree,  but by changing this option you can point it elsewhere, such as  the /lib/firmware/ directory or another separate directory  containing firmware files.

Help is equivalent to comments. It can be viewed by users who edit the kconfig file to ensure readability.
3. Example

Kconfig:

# drivers/Kconfigmenu "Device Drivers"source "drivers/base/Kconfig"source "drivers/connector/Kconfig"source "drivers/mtd/Kconfig"...endmenu

Shows the make menuconfig interface:

The content of kconfig in source "Drivers/base/kconfig" is as follows:

menu "Generic Driver Options"config UEVENT_HELPER_PATHstring "path to uevent helper"depends on HOTPLUGdefault "/sbin/hotplug"help  Path to uevent helper program forked by the kernel for  every uevent.config STANDALONEbool "Select only drivers that don't need compile-time external firmware" if EXPERIMENTALdefault yhelp  Select this option if you don't have magic firmware for drivers that  need it.  If unsure, say Y.config PREVENT_FIRMWARE_BUILDbool "Prevent firmware from being built"default yhelp  Say yes to avoid building firmware. Firmware is usually shipped  with the driver, and only when updating the firmware a rebuild  should be made.  If unsure say Y here.config FW_LOADERtristate "Userspace firmware loading support" if EMBEDDEDdepends on HOTPLUGdefault y---help---  This option is provided for the case where no in-kernel-tree modules  require userspace firmware loading support, but a module built outside  the kernel tree does.config FIRMWARE_IN_KERNELbool "Include in-kernel firmware blobs in kernel binary"depends on FW_LOADERdefault yhelp  The kernel source tree includes a number of firmware 'blobs'  which are used by various drivers. The recommended way to  use these is to run "make firmware_install" and to copy the  resulting binary files created in usr/lib/firmware directory  of the kernel tree to the /lib/firmware on your system so  that they can be loaded by userspace helpers on request.  Enabling this option will build each required firmware blob  into the kernel directly, where request_firmware() will find  them without having to call out to userspace. This may be  useful if your root file system requires a device which uses  such firmware, and do not wish to use an initrd.  This single option controls the inclusion of firmware for  every driver which uses request_firmware() and ships its  firmware in the kernel source tree, to avoid a proliferation  of 'Include firmware for xxx device' options.  Say 'N' and let firmware be loaded from userspace.config EXTRA_FIRMWAREstring "External firmware blobs to build into the kernel binary"depends on FW_LOADERhelp  This option allows firmware to be built into the kernel, for the  cases where the user either cannot or doesn't want to provide it from  userspace at runtime (for example, when the firmware in question is  required for accessing the boot device, and the user doesn't want to  use an initrd).  This option is a string, and takes the (space-separated) names of the  firmware files -- the same names which appear in MODULE_FIRMWARE()  and request_firmware() in the source. These files should exist under  the directory specified by the EXTRA_FIRMWARE_DIR option, which is  by default the firmware/ subdirectory of the kernel source tree.  So, for example, you might set CONFIG_EXTRA_FIRMWARE="usb8388.bin",  copy the usb8388.bin file into the firmware/ directory, and build the  kernel. Then any request_firmware("usb8388.bin") will be  satisfied internally without needing to call out to userspace.  WARNING: If you include additional firmware files into your binary  kernel image which are not available under the terms of the GPL,  then it may be a violation of the GPL to distribute the resulting  image -- since it combines both GPL and non-GPL work. You should  consult a lawyer of your own before distributing such an image.config EXTRA_FIRMWARE_DIRstring "Firmware blobs root directory"depends on EXTRA_FIRMWARE != ""default "firmware"help  This option controls the directory in which the kernel build system  looks for the firmware files listed in the EXTRA_FIRMWARE option.  The default is the firmware/ directory in the kernel source tree,  but by changing this option you can point it elsewhere, such as  the /lib/firmware/ directory or another separate directory  containing firmware files.config DEBUG_DRIVERbool "Driver Core verbose debug messages"depends on DEBUG_KERNELhelp  Say Y here if you want the Driver core to produce a bunch of  debug messages to the system log. Select this if you are having a  problem with the driver core and want to see more of what is  going on.  If you are unsure about this, say N here.config DEBUG_DEVRESbool "Managed device resources verbose debug messages"depends on DEBUG_KERNELhelp  This option enables kernel parameter devres.log. If set to  non-zero, devres debug messages are printed. Select this if  you are having a problem with devres or want to debug  resource management for a managed device. devres.log can be  switched on and off from sysfs node.  If you are unsure about this, Say N here.config SYS_HYPERVISORbooldefault nendmenu

Shows the display effect:

After the final configuration of the kconfig file under each directory, A. config file will be generated under the kernel root directory. This is a hidden file, which records the configuration and values of each option. Used by makefile.

For example:

. Config:

## Automatically generated make config: don't edit# Linux kernel version: 2.6.29# Thu Dec 15 21:15:25 2011#CONFIG_ARM=yCONFIG_SYS_SUPPORTS_APM_EMULATION=y# CONFIG_GENERIC_GPIO is not setCONFIG_GENERIC_TIME=yCONFIG_GENERIC_CLOCKEVENTS=yCONFIG_MMU=y# CONFIG_NO_IOPORT is not setCONFIG_GENERIC_HARDIRQS=yCONFIG_STACKTRACE_SUPPORT=yCONFIG_HAVE_LATENCYTOP_SUPPORT=yCONFIG_LOCKDEP_SUPPORT=yCONFIG_TRACE_IRQFLAGS_SUPPORT=yCONFIG_HARDIRQS_SW_RESEND=yCONFIG_GENERIC_IRQ_PROBE=yCONFIG_RWSEM_GENERIC_SPINLOCK=y# CONFIG_ARCH_HAS_ILOG2_U32 is not set# CONFIG_ARCH_HAS_ILOG2_U64 is not setCONFIG_GENERIC_HWEIGHT=yCONFIG_GENERIC_CALIBRATE_DELAY=yCONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=yCONFIG_VECTORS_BASE=0xffff0000CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

Each config_xxx record the value of the menu items in the previous kconfig file.