如何给Linux操作系统减肥下
|
根文件系统 对于许多新转到嵌入式Linux的工程师而言，他们认为在一个嵌入式设备上的根文件系统是一个外部概念，在Linux之前的嵌入式解决方案通过直接连接应用程序代码到内核中进行工作，因为Linux在内核和根文件系统之间有一个非常好的分割，最小化系统工作不是以缩小内核为终止点，在优化之前，根文件系统的大小与内核相比要小得多，无论如何，对于传统的Linux而言，系统部分有许多需要调整的部分，调整它们以减少系统的大小。 第一个需要回答的问题是“我究竟需不需要根文件系统？”简单地说，需要。在内核启动进程的结尾，它要查找根文件系统，由它再加载并运行第一个进程（通常是init，执行ps aux|head -2将告诉你在你系统上是什么进程），缺少根文件系统或初始化程序中的任何一个，内核将启动不了。 最小的根文件系统可以是一个文件：设备应用程序。假如这样，内核要指定一个文件，它是用户空间的第一个进程。只要那个进程在运行，系统就能工作，但是，如果这个程序基于任何原因退出了，内核将挂起，设备将需要重新启动。大多数空间有限的系统也会选择一个初始化程序，因为内务消耗小，初始化包括重新生成进程已死的代码，预防遇到应用程序崩溃时内核挂起。 大多数Linux系统非常复杂，包括很多可执行文件和常用共享库（包含运行在该设备上的应用程序共享库代码），对于这些文件系统，有很多选项存在用于减少RFS的大小。 改变C库 结合GCC，大多数用户都不想c库作为一个独立的实体，c语言包括32个关键字（give、take等），因此c程序的大多数字节来自这些标准库，权威的c库（glibc）被设计成高度兼容、国际化和跨平台支持，但它也比较大，有很多可选择的比较小的c库： uClibc：这个项目是为没有内存管理单元（MMU-less）的处理器实现的c库。uClibc从开始创建就很小，它提供与c库相同的功能，但删除了如国际化、大字符集支持和二进制兼容性等特征。而且，uClibc配置工具给用户很大自由选择什么代码进入库，允许用户进一步减小大小。 uClibc++：对于那些使用c++的程序而言，这个库是在相同设计原则下的实现，支持标准c++库的大部分功能，工程师可以很容易地在板子上部署基于c++的应用程序，仅需要几兆字节空间。 Newlib：Newlib出自Red Hat，它有一个非常完整的数学库实现，有很多做控制和测量应用程序的用户喜欢它。 dietlibc：dietlibc是glibc的最佳代替品，它仍然是最小的分支，非常小，实际上只有70K，它删除了如动态链接库等特征。它对ARM和MIPS支持得很好 Newlib和dietlibc通过提供一个包装的脚本调用编译器使用正确的参数集，忽略包括在编译器中的标准c库，使用一个替换的c库。uClibc有点不同，它需要工具链。 一旦你知道如何调用GCC，接下来就要为项目更新Makefile文件或建立脚本，大多数情况下，为项目在Makefile文件中使用下面这样一行： CC=CROSS_COMPILE-gcc 回到根文件系统 在选择了c库后，所有在根文件系统中的代码需要用新的编译器编译，那样代码就可以使用最近的、更小的c库。在这一点上，值得对静态与共享库进行评估，对于目标究竟该选择哪个，如果设备将运行任意的代码，而且在部署时该代码是未知的，共享库是最好的选择。如：设备可能暴露一个API允许最终用户或专业工程师编写模块。假如这样，设备上的库应该为这些新特征实现提供最大的灵活性。 如果系统包括许多分隔的程序共享库也是最佳的选择，假如这样，共享代码的拷贝将比复制几个文件的相同代码更小。 当只有几个程序在使用时，最佳做法是为每种用途创建一个系统然后比较最后的大小，大多数情况下，较小的系统是没有共享库的，而且还有一个额外的受益，没有共享库的系统载入和启动程序时更快（因为没有连接这一步了），因此用户从效率角度来说也受益了。 总结 尽管没有象魔术一样的工具使系统变得更小，但也不缺少工具帮助使系统仅可能变得更小，而且，使Linux变小比减小内核大小更困难，根文件系统需要严格检查，因为这个部件比内核消耗得更多空间，本文主要叙述了可执行映像大小，减少运行中程序内存需求。 资源 1、Linux-tiny补丁: www.selenic.com/linux-tiny.一系列减少内核映射大小和运行时资源消耗的小补丁，这里面的许多补丁已经集成到内核中了。 |
