Android核心驅動開發中的Kconfig檔案結構分析(圖文)

參考文獻:

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和Makefile

毫不誇張地說，Kconfig和Makefile是我們瀏覽核心代碼時最為依仗的兩個檔案。基本上，Linux 核心中每一個目錄下邊都會有一個Kconfig檔案和一個Makefile檔案。Kconfig和Makefile就好似一個城市的地圖，地圖引導我們去 認識一個城市，而Kconfig和Makefile則可以讓我們瞭解一個核心目錄下面的結構。在希望研究核心的某個子系統、某個驅動或其他某個部分時，都 有必要首先仔細閱讀一下相關目錄下的Kconfig和Makefile檔案。

分布到各目錄的Kconfig構成了一個分布式的核心設定資料庫，每個Kconfig分別描述了所屬目錄來源文件相關的核心配置菜單。在核心配置make menuconfig時，從Kconfig中讀出菜單，使用者選擇後儲存到.config的核心配置文檔中。 在核心編譯時間，主Makefile調用這個.config，就知道了使用者的選擇。

假如想使這個驅動被編譯，則要修改Makefile檔案，因此，需要添加新的驅動時，需要修改的檔案有兩個:Kconfig,Makefile.

2 菜單組織圖

一般一個Kconfig檔案表示的就是一個菜單，一個菜單由多個功能表項目組成,其格式如下:

menu 菜單名功能表項目或菜單連結1功能表項目或菜單連結2...功能表項目或菜單連結nendmenu

其中功能表項目就是指菜單的子功能表，所謂菜單連結就是指連結到另一個Kconfig檔案，如此一下，菜單就可以實現隨意嵌套了.

例如:

# 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 "提示字串"  default y  ...endmenu 

2.1 功能表項目

文法:

config <symbol><config options>

<symbol>為一符號，就好像代碼中的局部變數x一樣,可用於後邊的運算式中.

例如:

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.

上面功能表項目的屬性string表示菜單的類型，每一個功能表項目必須有一個類型.

注:每個config功能表項目都會產生一個配置選項CONFIG_XXX, XXX即為<symbol>. 如上，則會產生一個配置項:CONFIG_UEVENT_HELPER_PATH,此配置項的值記錄在核心根目錄下的隱藏檔案.config內， 例:~/WORKING_DIRECTORY/kernel/goldfish/.config檔案內.

2.2 菜單連結

菜單連結的格式如下:

source "路徑"

如:

source "drivers/pnp/Kconfig"

2.3 菜單屬性 2.3.1 類型

類型可以是:bool、tristate、string、hex和int。

bool類型的只能選中或不選中，選中為y,不選中為n.

tristate類型的功能表項目為值可為三種值，多了編譯成核心模組的選項。其值可為y,n,m.

string類型表示需要使用者輸入一串字串。

hex類型則需要使用者輸入一個16進位數。

int類型表示使用者輸入一個整型.

總結:

菜單類型屬性就好比一個控制項，bool相當於單選框，trstate相當於有三種狀態的複選框，string相當於供使用者輸入字串的文本編輯框，hex相當於供使用者輸入16進位數的文本編輯框，而int就相當於供使用者輸入整型數的文本編輯框。

類型關鍵字後邊可跟隨提示字元，也可以不跟隨,取決於情況。如：

string "path to uevent helper"

bool "Prevent firmware from being built"

注:每一個功能表項目必須有類型屬性。

2.3.2 預設值

預設值屬性default一般在類型屬性後邊，如:

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

表示當前功能表項目若使用者沒有選擇或輸入任何值時，所取的預設值.上述所示為當前的預設值為"/sbin/totplug".

2.3.3 依賴

依賴可以是"depends on"或"requires".

文法:

depends on/requires <expr>

<expre>為運算式，可為之前定義的功能表項目名.

如:

depends on HOTPLUG

表示此功能表項目顯示與否取決於另外一個功能表項目HOTPLUG ，只有當功能表項目HOTPLUG這個功能表項目有效顯示，當前功能表項目才會顯示。

例如:

    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 

功能表項目MODVERSIONS的顯示與否取決於功能表項目MODULES。這種信賴關係常用在子功能表項中。

2.3.4 選擇

文法:

choice選擇項..endchoice

2.3.5 提示

文法:

comment "提示資訊字串"comment選項

comment只是用來給使用者提示資訊的，後跟字串，此字串也可以在終端中顯示。

comment選項只可以是deponds on。

2.3.6 協助

文法:

help/---help--- <字串>

例如:

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相當於注釋一樣，在給編輯Kconfig檔案的人看的，這樣可以保持其可讀性.
3 舉例

Kconfig:

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

其對應的make menuconfig介面如所示:

source "drivers/base/Kconfig"中的Kconfig內容如下:即對應著中的第一項"Generic Driver Option"的子功能表內容:

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

顯示效果如所示:

各個目錄下的Kconfig檔案經過最終配置，最終會在核心根目錄下產生一個.config檔案，這是個隱藏檔案，這個檔案記錄著各個選項的配置及值。供Makefile檔案使用.

如:

.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"

每一個CONFIG_xxx記錄著之前Kconfig檔案內的功能表項目的值.