rootfs 文件系统裁剪的思考 - 基于make menuconfig

最近在做关于rootfs 文件系统的裁剪，对其中裁剪的方法和尽量减少人工裁剪的可能做了一些思考。

 

首先，应该明确一些裁剪的粒度：

a. 模块级裁剪，去掉不用的模块支持；

b. 应用级裁剪，去掉不用的app；

c. 库级裁剪，去掉不用的库；

d. 函数级裁剪，去掉不用的函数，甚至库函数；

 

以上裁剪，粒度由粗到细，从粗调到细调，是一个从见效明显到见效慢的精心打磨过程；其中，我主要思考了应用和库的依赖问题。

 

关于应用和库的依赖问题，目前的sdk里，依赖关系普遍没有建立，即，如果编译app A，除了选中编译app A的 config flag 之外，一些依赖的库需要额外的选中。我认为，应该充分利用编译系统的依赖关系，建立依赖。我用的sdk 应用的编译系统，是移植的Linux kernel 中类似的编译系统，即可以利用make menuconfig 来选中编译选项，对应会有类似于Kconfig编译控制文件的Uconfig，即用户空间的config，其中select 和depends on 关键字控制依赖关系。

理想的依赖关系应该是这样的，由于所有库的使用者最终都是应用程序，且我们默认选中编译应用程序时，是所选即所得，在顶层选中一个应用程序，应该利用依赖关系select 自动选中直接依赖的自定义库及第三方库的编译；而库的编译选中又自动选中他们直接依赖的编译项的选中。这样达到的效果就是，我选中需要的功能app，测试app，debug app，linux 工具app，所有依赖的库即全部选中。因为全部选中保存后，再次去掉app，依赖的库可能还是选中状态，这个时候，可以从全部不选中配置状态，从新选中需要的app；也可以在menuconfig 中，将没有锁定的选项去掉。因为我们的依赖关系建立的目的是，只有应用层次可以选中和去掉，其余的库和配置是根据依赖关系自动选中：这种依赖关系可以在长期维护中来建立，或者由专人来梳理一遍。

目前，不足的地方是，不清楚是否有方式在去掉选中的app时，自动去掉可去掉，即不同时被其他app选中的库；替代方法是通过Kconfig 查找该app的依赖库，手动去掉menuconfig 中的选中。

 

为什么要明确依赖关系？

1.依赖关系是必然存在的，只是存在于配置写固定的形式，还是存在于编译报错，人工手动查找修复依赖方式的问题上。我认为，一个app，可以锁定他所有的依赖关系，如果有不同的依赖选项，可以根据该app下的编译选项的不同来决定。

2.目前业界对Linux 系统上应用程序的依赖关系建立，很多没有做好。如果做好依赖关系，理论上，根据功能即可配置最小的库级rootfs。当然，如果有对应的feature 控制，可以做的更好。这样就避免了很多人工分析依赖关系，来手动裁剪。

所有人工可重复做的事情，都需要也必然要工具化，因为重复不创造价值，只有创新才创造价值。不能完全工具化的东西，可以将可工具化的部分交给工具，必须由人来做的交给人做。尘归尘，土归土。让正确的事，用正确的方式来做。

 

在第一次，可以根据需求，梳理一些需要的功能app，测试app，debug app，Linux 系统命令，在后面开发过程中可以方便的增减，调整。