modules.dep怎么生成

modules.dep怎么生成

这几天在做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 0xbf
mmc_core 18160 1 sep_mci, Live 0xbf
这样我们就能成功的加载
sep_mci这个模块，并且会自带着加载mmc_core这个依赖的KO文件了

嵌入式linux系统安装时，内核映像只有2m左右，但文件系统却有100m，为什么？ 你说的"文件系统"实际上说的是”根文件系统“，这个根文件系统当中至少包括了一些基本目录，如/etc, /lib,/bin ...等等。 还有一个概念叫”最小（根）文件系统“，他只包括了启动所需要的最基本的文件，例如/etc/init.d/rcs, /bin/busybox, /lib/libc.so ...等等，它的大小实际上也只要几m。如果仅仅是完成最基本的启动，那么这个文件系统已经足够了。 好了，那为什么你用到的根文件系统会有100m，而不是几m呢，因为我们的系统跑起来之后还要运行一系列的应用程序，看你给出的文件系统命名，应该会有一个叫qtopia的图形应用程序。 qtopia是 基于qt的，那么我们要让qtopia跑起来，就需要qt的库文件如libqtcore.so, libqtgui.so等，当然还需要qt所需要的其它库如c++库libc++, 图片库，如libpng 之类的，这些库文件加起来就是几十m。另外qtopia应用程序本身也应该放在文件系统上吧，又需要空间。 当然除了qtopia之外还有很多其它应用程序和所需要的其它库，还有一些以模块方式（moudle,后缀.ko）存在的驱动程序需要放在根文件系统中，当然还有诸如配置文件之类的东西，所以你看到的文件系统从只需要几m的最小根文件系统变成了100m的文件系统。 ========================================================================== 文件系统比如fat32之类只要实现了一种管理存储器文件的函数就行，跟启动方式和功能外设有啥关系？ 如前所述，所有的东西都放在文件系统中，包括以模块方式存在的驱动，那么很明显root_nfs是以nfs(net file system)方式启动，那么你至少需要网络支持吧，其它的几个也是相同的道理，我估计这几个文件系统的主要区别就是驱动模块和配置文件不同而已。