关于内核autoconf.h



1.老版内核autoconf.h的生成

在make menuconfig时生成.config然后再make zImage时就会由.config生成autoconf.h 都是脚本做的。

2.关于新版的内核

在比较老的版本比如http://lxr.linux.no/linux+v2.6.15.5/mm/filemap.c
会包含config.h，而config.h会包含linux/autoconf.h，在2.6.19以后就不这样了。
今天看3.8.4的内核，发现autoconf.h位置变了，在include/generated/autoconf.h，而且现在源代码好像都不包含autoconf.h
我搜了一下，没有满意的解释，我猜测makefile编译时在源码中遇到CONFIG_xxx会自动在autoconf.h中寻找定义，不知道是不是，谁知道相关代码位于何处？
貌似以前makefile在决定某个文件是否编译进内核时会查找.config，而源码中决定某个功能是否编译的宏依赖于源码文件中直接或间接包含的autoconf.h，难道现在都全自动了？

====
放在这里供有需要的人参考
这里有一个简单的解释：http://lxr.linux.no/linux+v3.8.4/scripts/basic/fixdep.c

在产生的依赖规则文件中会包含文件 include/linux/autoconf.h，这个文件会被内核大多数目标所依赖。
    这里会存在一个问题。假如前后两次的内核编译过程中，区别只在于第一次配置选项 CONFIG_MY_DRIVER 被设置为 =m，而第二次被设置为 =y。在第二次编译过程中 include/linux/autoconf.h 因为配置选项的改变而被更新，导致重新编译依赖这个文件的所有目标
    这是没有必要的严重浪费。因为只是改变了自己所写内部模块对应的那个那个配置选项 CONFIG_MY_DEVICE_DRIVER。换句话讲，这个选项只影响到我自己写的那个内部模块，而其他任何内部模块或者基本内核代码都没有使用这个选项，所以在第二次编译过程中，没有必要去重新remake几乎全部目标，而只需要重新编译那个内部模块即可。
    为了避免这种不必要的额外负担，而达到只编译那些因为配置选项变更而确实受到影响的目标。内核构建系统使用 scripts/basic/fixdep 做了一个小动作。该动作修改依赖规则文件，从中删除对 include/linux/autoconf.h 文件的直接依赖，而代之以对 include/config/ 目录下的空的头文件的依赖。
    配置工具 scripts/kconfig/conf 产生 auto.conf、auto.conf.cmd 和 autoconf.h 等三个文件。与此同时，它会在函数 conf_write_autoconf 中调用conf_split_config 函数，在 include/config/ 下产生一系列的头文件。
    该函数先使用 conf_get_autoconfig_name 取得文件 "include/config/auto.conf" 的名称，然后用 for 循环处理每一个 CONFIG_XXX 的定义。例如针对 CONFIG_MY_DEVICE_DRIVER 配置选项处理的时候，它在字符数组 path 中存储这样的字符串：my/device/driver.h。接下来，它会在后面用 open 系统调用在 include/config 目录下去创建名为此字符串的空文件。从这里可以看出，针对每个配置过的配置选项，都会有这样的头文件产生。
    内核构建系统会将对 include/linux/autoconf.h 文件的依赖转换为对这里的这些头文件的依赖。例如在自己的编写的内部模块中，因为使用到了配置选项 CONFIG_MY_DEVICE_DRIVER，所以 fixdep 会将对 autoconf.h 文件的依赖转换成对 include/config/my/device/driver.h 头文件的依赖。这样下次编译时其它文件不会受到影响。