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命令就是依照这个顺序来载入模块的。
下图是我画的一个大概示意图。
modprobe与depmod
1.modprobe
modprobe - program to add and remove modules from the Linux Kernel
modprobe和insmod类似,是用来动态加载模块的,区别在于
modprobe可以解决load module时的依赖关系,它是通过/lib/modules//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//目录下生成modules.dep(.bb)文件,表明了模块的依赖关系
3. 对于在使用"modprobe xxx"动态加载过程中出现“modprobe XXX not found”
若出现此问题,需确认:
1. modules.dep(.bb)文件是否生成,若没有,则可以运行depmod,生成此依赖关系文件
2. 若有依赖关系文件,仍出现此问题,把modprobe xxx.ko改为执行modprobe xxx
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)