如何在根文件系统中使用modprobe

这 几天在做4020的快速启动，本来想将网络模块化这样，能够将内核大概缩小0.5M（这个还是zImage），这样无论在uboot阶段搬运，还是在 zImage段的解压缩，还是在最后的启动都可以大大减少linux的启动时间，然而这中间有个很重要的问题是怎样在nfs中实现modprobe的命 令，我在原来的busybox1.10.4中敲入modprobe命令出现如下错误： 
/quick_start # modprobe sep_mci.ko  
modprobe: cannot parse modules.dep                                 否则会出现这个错误，因为没有生成这个文件 
/quick_start # depmod    
-/bin/sh: depmod: not found 
这个可能是由于我在编译buxybox的时候没有将这几个命令放进去，现在也不准备重新编译了，直接拿了个1.13.3的buxybox来用，要想用起modprobe需要如下步骤： 
（1）在这里我是将linux的SD卡的驱动编译成模块ko形式，这样会在内核的/driver.mmc/目录下面生成三个文件： 
mmc_block.ko  mmc_core.ko   sep_mci.ko 
把这保存起来，等会会用； 
（2）启动了uboot，内核，加载buxybox1.13.3文件系统，然后我们需要在/lib/下面创建modules,然后进 modules下面创建2.6.16这个文件夹，接着把上面的3个ko文件通过虚拟机上挂载的网络文件系统拷贝到/nfs/lib/modules /2.6.16下面，然后我们就可以使用modprobe命令了，但使用modprobe命令之间需要先用depmod命令分析下各个模块的依赖关系，具 体操作如下： 
/lib # mkdir modules 
/lib # cd modules/ 
/lib/modules # ls 
/lib/modules # uname -r  
2.6.16 
/lib/modules # mkdir 2.6.16 
/lib/modules # cd /quick_start/ 
/quick_start # cd / 
/ # depmod 
/ # cat /lib/modules/2.6.16/modules.dep .bb  
mmc_core.ko symbol:mmc_request_done symbol:mmc_detect_change symbol:mmc_release_host symbol:mmc_remove_host symbol:mmc_free_host symbol:mmc_wait_for_cmd symbol:mmc_start_request symbol:__mmc_claim_host symbol:mmc_wait_for_app_cmd symbol:mmc_alloc_host symbol:mmc_add_host symbol:mmc_wait_for_req symbol:mmc_init_queue symbol:mmc_queue_suspend symbol:mmc_cleanup_queue symbol:mmc_queue_resume symbol:mmc_register_driver symbol:mmc_unregister_driver symbol:mmc_free_host symbol:mmc_remove_host symbol:mmc_add_host symbol:mmc_alloc_host symbol:mmc_detect_change symbol:mmc_release_host symbol:__mmc_claim_host symbol:mmc_wait_for_app_cmd symbol:mmc_wait_for_cmd symbol:mmc_wait_for_req symbol:mmc_start_request symbol:mmc_request_done symbol:mmc_queue_resume symbol:mmc_queue_suspend symbol:mmc_cleanup_queue symbol:mmc_init_queue symbol:mmc_unregister_driver symbol:mmc_register_driver 


mmc_block.ko 
mmc_core 


sep_mci.ko 
mmc_core 


/ # modprobe sep_mci 
/ # lsmod 
sep_mci 5952 0 - Live 0xbf006000 
mmc_core 18160 1 sep_mci, Live 0xbf000000 
这样我们就能成功的加载 
sep_mci这个模块，并且会自带着加载mmc_core这个依赖的KO文件了

 

用这个方法解决libertas(sdio)的模块加载问题。

原文地址：http://blog.csdn.net/zqgtiger/article/details/5320630

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

2013-03-07 10:37:00|  分类： linux|字号 订阅

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

 

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/<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