Chinaunix首页 | 论坛 | 博客
  • 博客访问: 102170
  • 博文数量: 34
  • 博客积分: 10
  • 博客等级: 民兵
  • 技术积分: 215
  • 用 户 组: 普通用户
  • 注册时间: 2011-02-27 11:21
文章分类
文章存档

2014年(1)

2013年(33)

我的朋友

分类: LINUX

2013-07-12 19:37:15

毫无疑问,这是Linux内核的一个BUG。内核版本是2.6.27.8,将会影响到所有ARM架构。本文所述及的思路、解决方法也都是基于ARM架构的,对其他架构不一定适用!

具体表现为,如果在driver目录下创建了一个新目录,然后在该目录下编写好Kconfig,并在drivers/Kconfig文件中添加了source选项。按道理,内核配置中就应该添加上了这个目录。make menuconfig后就能够找得到。但实际情况确实找不到。更为疯狂的是,即便是把drivers/Kconfig文件胡乱改掉、甚至是删除掉,都不会对内核的配置过程造成任何影响。

因此,我假设,内核在这个时候压根就没有读取drivers/Kconfig,因此删除或者修改该文件对内核配置一点影响都没有。自然,在这个文件中添加的读取自己创建目录下到Kconfig文件,也不会有效果。由内核配置树可见,drivers目录算是顶层目录了。如果这个目录下的Kconfig没有被读取,那么问题肯定出在顶层的Kconfig上。而内核根目录下又没有Kconfig这个文件。那么顶层的Kconfig文件在哪儿呢?

带着这个问题,我检查来内核在执行配置文件的日志输出:

[athurg@nts.gooth.cn ~/nts3250/kernel]
$make menuconfig
  HOSTCC  scripts/basic/fixdep
scripts/basic/fixdep.c: 在函数‘traps’中:
scripts/basic/fixdep.c:377:2: 警告:提领类型双关的指针将破坏强重叠规则
scripts/basic/fixdep.c:379:4: 警告:提领类型双关的指针将破坏强重叠规则
  HOSTCC  scripts/basic/docproc
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/kxgettext.o
  HOSTCC  scripts/kconfig/lxdialog/checklist.o
  HOSTCC  scripts/kconfig/lxdialog/inputbox.o
  HOSTCC  scripts/kconfig/lxdialog/menubox.o
  HOSTCC  scripts/kconfig/lxdialog/textbox.o
  HOSTCC  scripts/kconfig/lxdialog/util.o
  HOSTCC  scripts/kconfig/lxdialog/yesno.o
  HOSTCC  scripts/kconfig/mconf.o
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/mconf
scripts/kconfig/mconf arch/arm/Kconfig

由上面到内容可以分析出:内核(基于ARM架构,下文同)中所有的配置文件,都是由arch/arm/Kconfig包含进去的(其他平台类推,比如x86就是arch/x86/Kconfig)。因此我们打开这个文件,会发现文件中有很多类似下面的代码:

source "drivers/parport/Kconfig"

source "drivers/pnp/Kconfig"

source "drivers/block/Kconfig"

# misc before ide - BLK_DEV_SGIIOC4 depends on SGI_IOC4

source "drivers/misc/Kconfig"

source "drivers/ide/Kconfig"

source "drivers/scsi/Kconfig"

很明显,他们用于将driver下的各个子目录下到Kconfig文件读入。而且同时可以发现,这里把driver下所有的目录都做了source处理。为了防止冲突,就没有处理drivers目录下的Kconfig。这个是可以理解的。因为如果这里处理了子目录,又读取drivers下到Kconfig,就会再次处理drivers下面到子目录,造成前后冲突。

找到这里,就找到了症结所在了。我同时对比了其他的架构,比如x86架构。他们的处理和ARM的不太一样。他们是直接读取的drivers下到Kconfig,而drivers下的子目录,则由drivers下的Kconfig自己去处理。

为什么ARM会这么处理呢?从arch/arm/Kconfig中的内容,我猜测。可能是因为对于某些驱动,ARM架构不支持。为了防止用户误选取,并且尽量不修改drivers下面的内容(很明显,drivers下面的内容ARM架构的开发人员是应当尽量避免整体修改的,因为这些修改会对其他架构造成无法估计到影响)。

问题分析到这里,解决起来自然很简单了。只需要将自己建立的目录下到Kconfig文件通过source命令,在arch/arm/Kconfig即可。

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ede6ef2..ef7039a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1248,6 +1248,8 @@ source "drivers/uio/Kconfig"

 endmenu

+source "drivers/your_path/Kconfig"
+
 source "fs/Kconfig"

 source "arch/arm/Kconfig.debug"
阅读(1410) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~