关于buildroot移植的思考

Posted 2020-09-29 crazy_thb

buildroot是一个成熟的SDK框架，基于它有了openwrt。

 

曾经有一个项目，需要将原有的OpenWrt SDK改造，并且将软件框架重新定义。尝试精简原来的OpenWrt，并且删除所有的软件包，留下rootfs、busybox这些基本的东西，但是还是有很多地方不如人意，难以修改（定制的过于深入）。于是找到它的前身，buildroot，进行修改。

 

拿到buildroot后。发现和OpenWrt的一大区别就是耦合性低。在OpenWrt里面一些自动编译的操作，需要在buildroot里面手动编译。比如make busybox-rebuild。对于linux内核来说，在make linux-menuconfig之后，需要将.config手动拷贝回来，而不是自动同步。虽然麻烦一点，但是我觉得这样是一个比较好的做法，毕竟之前做OpenWrt的时候发现整个流程太过于自动化，修改个内核配置之后一串内核的配置文件被修改合并而让人摸不着头脑。

 

另外，将OpenWrt的SDK移植到buildroot也是令人愉快的，拷贝toolchain，busybox和内核，再花功夫研究文件系统image的生成，写一个post-build脚本，配置CPU架构等一些参数，image就可以下载运行了。当然需要根据自己的需求精简、修改一些东西。比如你想把平台有关的东西塞到一些文件夹里面，再添加一些文件夹作为其他平台的根文件夹，多个-平台存在于同一份SDK里面，这样都是可以的。不过修改的时候不要定制过度，把一些以后有用的东西给删了，到最后要用的时候还是要改回来。当然了，只要你有toolchain、内核和文件系统layout就可以做移植了，不一定要给出很好的原版SDK。

 

buildroot的定制是比较便捷快速的，比如你移动一些文件夹，像fs，arch这些，只需要修改Config.in和makefile就可以了。因为它耦合性程度低的优点，修改起来较为容易，不会出现牵一发而动全身的现象，所以自己修改的时候也不要增加太多的关联，给后续的维护带来麻烦。

 

buildroot的框架比较清晰。首先它软件包的定义和OpenWrt类似，不含有其他的冗余成分，做SDK该做的事，规定软件到哪里编译，传递哪些编译选项，安装到哪里。对于每一个组件，即使是toolchain也是一个软件包，这样一来，只需要修改Config.in和相关的makefile就可以定义自己想要的东西。如果你还不明白，buildroot提供了一个pdf说明文档，仔细看一遍再继续研究。而OpenWrt的文档大而全，这是不可避免的，因为两者的定位不同。

 

buildroot可以让人更加清晰地学习linux。学习linux的编译运行流程，buildroot比当前热门的OpenWrt好得多。OpenWrt这个发行版定制了很多东西，你一个make就完成的事情，可能浑然不知里面发生了什么。当你拿到buildroot，即使是别人做好的，只要你仔细看一下里面的流程就会明白一个linux是怎么生成的，因为它的框架比较简单。当然buildroot也是一个大而全的东西，因为它是一个开源的软件，它支持很多体系结构，可以适当按照自己需要精简。若纯粹自己用，不精简也没关系。

 

buildroot没有暗示你使用什么。对于OpenWrt来说，使用了uhttpd，你可能就需要libubox和luci，lua这一堆东西，如果你不用这些，你使用OpenWrt可能就意义不大了。而使用了buildroot，你会选择自己要用什么，从busybox开始逐渐搭建你自己的王国。当然了你也可以使用uhttpd这一堆东西。