嵌入式Linux中文站

Linux模块驱动开发的那点事


 
modules.dep文件记录了内核模块间的依赖关系,此文件是使用module-init-tools套件中的depmod命令时自动生成的。
每个内核版本都有一个对应的modules.dep文件,存放在/lib/modules/kernel-version目录下。
此文件中内核的依赖关系使用  "filename: [filename]*" 这样的形式描述。
空行和"#"开头的行会被忽略掉。
整个文件中的依赖关系是降序描述的,举例来说:

假如模块/lib/modules/2.5.53/kernel/a.ko依赖于同目录下的b.ko和c.ko,而c.ko又依赖于b.ko,那么这三者的依赖关系描述就是如下这样:

# "#"号开头行是注释
/lib/modules/2.5.53/kernel/a.ko: /lib/modules/2.5.53/kernel/c.ko /lib/modules/2.5.53/kernel/b.ko
/lib/modules/2.5.53/kernel/b.ko:
/lib/modules/2.5.53/kernel/c.ko: /lib/modules/2.5.53/kernel/b.ko

modprobe命令就是依照这个顺序来载入模块的。

下图是我画的一个大概示意图。

modules.dep,modprobe,depmod,mkinitrd之间的关系

 

modprobe与depmod

1.modprobe

 modprobe - program to add and remove modules from the Linux Kernel 

modprobe和insmod类似,是用来动态加载模块的,区别在于

modprobe可以解决load module时的依赖关系,它是通过/lib/modules/<kernel-version>/modules.dep(.bb)文件来查找依赖关系的;而insmod不能解决依赖问题。

如有2个模块g_file_storage.ko和udc.ko,g_file_storage.ko依赖于udc.ko,在加载g_file_storage.ko前必须先加载udc.ko,如果使用insmod加载,必须按顺序一个一个加载:

insmod udc.ko

insmode g_file_storage.ko file=/dev/mtdblock3

如果使用modprobe加载则执行:

modprobe g_file_storage file=/dev/mtdblock3/*此处的加载对象写为g_file_storage,非g_file_storage.ko*/

PS:modules.dep(.bb)文件内容如下:

 

g_file_storage.ko

udc

udc.ko symbol:usb_gadget_unregister_driver symbol:usb_gadget_register_driver

 

 

2.depmod

depmod - program to generate modules.dep and map files

当把模块文件放到/lib/module/`uname -r`/目录下,运行depmod,则会在/lib/modules/<kernel-version>/目录下生成modules.dep(.bb)文件,表明了模块的依赖关系

 

3. 对于在使用"modprobe xxx"动态加载过程中出现“modprobe XXX not found”

若出现此问题,需确认:

1. modules.dep(.bb)文件是否生成,若没有,则可以运行depmod,生成此依赖关系文件

2. 若有依赖关系文件,仍出现此问题,把modprobe xxx.ko改为执行modprobe xxx


本文永久更新链接:http://embeddedlinux.org.cn/emb-linux/kernel-driver/201701/09-6111.html



分享:

评论