modules.dep文件记录了内核模块间的依赖关系，此文件是使用module-init-tools套件中的depmod命令时自动生成的。

每个内核版本都有一个对应的modules.dep文件，存放在/lib/modules/kernel-ve     rs   ion目录下。
此文件中内核的依赖关系使用  "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 - prog     ram   to add and remove modules f     rom   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_unregis     te   r_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