如何从openwrt移植软件包到entware

Posted 2023-04-02

参考技术A 因为要把fastd移到entware，找了一下发现entware并没有提供完整的文档说明，在这里整理一下我的心得。各种错误疏漏在所难免，欢迎指正。

背景：

Broadcom方案的路由一般将系统设置保存在NVRAM，文件系统的根卷采用只读的SquashFS，意味着你虽然看得到/etc/下的各种配置，但其实无法修改，除非重新编译安装固件。由此派生出来的dd-wrt和Tomato也是照办。
对于额外可用的Flash，dd-wrt和Tomato都支持格式化为JFFS2卷(JFFS2以下也统一简称JFFS)，并一般挂载到/jffs路径。
而主要支持Atheros方案路由的openwrt则一般采用SquashFS + JFFS overlay的方案，即根卷仍然是只读的SquashFS卷，但在其上覆盖可读写的JFFS卷，看起来就好像你可以自由修改文件系统一样，但其实只是JFFS卷的内容覆盖在SquashFS上。这样既方便，又保留了只读SquashFS的灾难恢复功能。
作为对比，下面是r6300v2运行Tomato的mount表:

rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /tmp type tmpfs (rw,relatime)
devfs on /dev type tmpfs (rw,noatime)
sysfs on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
usbfs on /proc/bus/usb type usbfs (rw,relatime)
/dev/mtdblock6 on /jffs type jffs2 (rw,noatime)
在r6300v2上登录到ssh以后，我的home目录是跑在tmpfs上的/tmp/home/root，相当于是ramdisk里面。真正可以写入内容并且重启后不丢失的位置只有 /jffs。在r6300v2 + Tomato上面，/jffs是利用系统64MB空闲的flash。

下面是WNDR3700v4运行openwrt的mount表:

rootfs on / type rootfs (rw)
/dev/root on /rom type squashfs (ro,relatime)
proc on /proc type proc (rw,noatime)
sysfs on /sys type sysfs (rw,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
/dev/ubi0_1 on /overlay type ubifs (rw,noatime)
overlayfs:/overlay on / type overlayfs (rw,noatime,lowerdir=/,upperdir=/overlay)
tmpfs on /dev type tmpfs (rw,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)

WNDR3700v4有128M NAND flash，大概90多MB空闲。从上面可以看出和Tomato的区别在于这些空间(/dev/ubi0_1)被作为overlayfs，透明覆盖于 / 之上。我在WNDR3700v4的/etc/下所作的修改都保存到了overlay中，遮蔽了原有存在于SquashFS中的文件。另外WNDR3700v4是使用廉价的NAND flash，因此openwrt专门为其使用UBIFS文件系统，而不是上文所说的JFFS。

说了这么多看似无关的，是为了解释openwrt/opkg和entware之间一个重要的区别：openwrt默认把opkg包安装到/usr/，而作为移植版的entware默认安装到/opt/。因为ddwrt/Tomato根卷只读，/usr/不像openwrt上面那样可以写入，所以只能另选一个通常根卷上没有的路径，因此就有了/opt/。别忘了entware的前身就是optware。

所以ddwrt/Tomato的用户常常会需要将/jffs重新bind到/opt，或者挂外接硬盘/U盘到/opt上，openwrt用户则不需要。当然路由内置空间太小的openwrt是另外一回事。

那么把一个软件包从openwrt移植到entware所要做的工作就很直观了：把各种约定好的路径统统改到/opt！

/usr/bin? 改到 /opt/bin
/usr/sbin? 改到 /opt/bin
/etc/配置文件? 改到 /opt/etc/配置文件
使用openwrt UCI配置系统的 /etc/config/配置文件？还有openwrt风格的 /etc/init.d/启动脚本？对不起，这些和ddwrt/Tomato不兼容，只能case by case修改
实际上entware仓库中你可以找到大量的fix-path.patch文件，就是针对各个软件包修改Makefile中的路径。当然，由于内核版本不同(openwrt BB是3.10，CC已经升到3.18，tomato仍然沿用2.26系列)和其他种种原因，总有一些软件包还需要修改其他地方。

关于buildroot移植的思考

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这一堆东西。