buildroot VS yocto

翻译自Buildroot vs. OpenEmbedded or Yocto Project: A Four Hands Discussion - 2016.pdf

Buildroot 和 yocto的对比

对比内容：
（1） 嵌入式构建系统
    目标是构建一个完整的，客制化的嵌入式Linux系统
    包括root filesystem， toolchain， kernel， bootloader
（2） 从源代码开始
（3） 使用交叉编译工具链
（4） 非常活跃的维护和开发工程
（5） 工业界广泛使用
（6） 有文档和培训课程
（7） 自由软件

buildroot的通用信条
（1） 专注于简单化
（2） 使用简单，理解简单，扩展简单
（3） 通过扩展脚本而不是buildroot本身来处理特殊情况
（4） 使用现存的技术/语言： kconfig， make. (值得投入时间去学习)
（5） 默认小
（6） 目的无关的（Purpose-agnostic）
（7） 开放社区，没有供应商、官僚/公司的管理

yocto的通用信条
（1） 支持主要的CPU架构
    OpenEmbedded：仅qemu
    Yocto Project： 为一小部分机器增加支持
（2） 只提供核心方法，使用layers来支持更多的package和机器
（3） 客户的改动应该在一个单独的layer
（4） 多用途的构建系统：尽可能灵活的处理更多的使用情况
（5） 开放社区，但是该工程被公司赞助商发起的Yocto Project Advisory Board监管
（6） OpenEmbedded 是一个独立社区驱动的工程。

buildroot 输出
（1） 主要是根文件系统镜像
    同时包含：工具链， 内核镜像， bootloader等
（2） 支持多种格式： ext2/3/4， ubifs， iso9600等
（3） 没有二进制包， 没有包管理系统
    一些人称之为一个firmware generator
    通过包不可能更新
    更新需要一个完整的系统更新，像Andorid一样
    认为部分更新是有害的

Yocto 输出
（1） 构建distribution，主要的输出是一个package feed
    包管理系统是可选的
    装载和更新系统的一部分是可能的
（2） 通过安装一些包，也可以产生根文件系统镜像。支持ext2/3/4， ubifs， iso9600等，也支持VM镜像：vmdk，vdi，qcow2
（3） 最终，镜像类或者工具，wic可用来构建磁盘镜像
（4） 生成image时也可以生成SDK，可以让应用开发者编译和测试他们的应用（不用集成到build中）。但是SDK必须要和image匹配。

Buildroot 配置
（1） 和Linux kernel一样使用kconfig
（2） 简单的{menu，x，n，g}配置接口
（3） 整个配置保存在一个文件 .config/defconfig
（4） 定义系统的各个方面：架构，内核版本/内核配置，bootloader，用户空间package等等。
（5） make menuconfig， make
（6） 为不同的机器构建通用的系统：单独处理
    一个可以从fragment中构建出defconfig的工具
    可行的，但是并非超级简单
    每台机器完全独立的构建

Yocto 配置
（1） 配置分成几个部分：
    Distribution 配置 （package配置，toolchain和libc选择...）
    Machine Configuration （定义架构， CPU功能， BSP）
    Image recipe （target安装什么package）
    Local配置 （Distribution和默认machine选择， 编译时使用多少个线程， 是否删除build artifact）
（2） 有必要收集将要被使用的layers，并宣布它们。
（3） 允许为不同的机器构建相同的镜像，或者为同一个机器构建不同的distribution或镜像。


Buildroot layers
（1） 没有layer的概念
（2） 所有的包在官方repository中维护
（3） 添加BR2_EXTERNAL
    允许存储包定义、配置和其他人工文件
    一个BR2_EXTERNAL
    通常用作专有的/客制化的包和配置
    仅增加包，不覆盖buildroot中的包


yocto layers
（1） layer机制允许修改和增加新package或image
（2） core build system， BSP和custome modifications之间明确分离
（3） 第三方提供为它们layers提供BSP，或者一套处理专用应用程序的方法
（4） Layers需要兼容和使用相同的OE branch base
（5） 谨防layer quality， 检查不是系统性的
（6） OpenEmbedded Metadata Index 列出了可用的layers，recipes，machines：http://layers.openembedded.org/layerindex/
（7） 此外，有一个强大的override机制，可以基于machine或者distribution调整recipe variables


buildroot/yocto toolchain
相同的功能：
（1） 构建自己的toolchain，基于gcc、C库（glibc， uClibc， musl）
（2） 使用external toolchain， 对于buildroot更简单，因为内置有这个功能，对于yocto，只有在additional vendor layers正真完全支持。


buildroot new package
涉及三个文件Config.in xxx.mk xxx.hash

yocto new package
涉及一个文件×××.bb


buildroot: complexity
（1） 设计成简单使用
（2） 对于core，每个建议的功能以有用性/复杂度比来分析
（3） core逻辑完全使用make编写，少于1000行的code包含了230行注释： 确实容易理解what、why、how；几乎和一个shell脚本一个接一个地下载、提取、构建、安装软件那样简单。
（4） 文档很充分，有很多资源可用
（5） 一个小时的talk足以描述所有内部实现（ELCE 2014）
（6） IRC上典型的反馈： 来自Yocto，非常惊喜，使用起来这么简单。 这是让我为难的第一件事。

Yocto Project: complexity
（1） 有点陡峭的学习曲线
（2） 核心是bitbake， 一个用python编写的单独项目（60千行代码）
（3） 一套class定义common task
（4） recipe 使用 bitbake specific language， python 和 shell 混合编写
（5） 日志和调试可帮助理解每个task具体做了什么
（6） 详细的文档，但是有很多不同的配置变量
（7） 并不总是容易理解最佳实践（比如， Poky 不能用于 production， distro/image 修改不能在local.conf中做， 删除tmp/）
（8） 人们依然对一些术语感到疑惑（Yocto Project， Poky， OpenEmbedded， bitbake）


Buildroot packages
（1） 1800+ packages
（2） Graphics: X.org, Wayland, Qt4/Qt5, Gtk2/Gtk3, EFL
（3） Multimedia: Gstreamer 0.10/1.x, ffmpeg, Kodi, OpenGL
（4） Languages: Python2/3, PHP, Lua, Perl, Erlang, Mono, Ruby, Node.js
（5） Networking: Apache, Samba, Dovecot, Exim, CUPS, lots of servers/tools
（6） Init systems: Busybox(default), initsysv, systemd
（7） No support for a toolchain on the target


Yocto Project packages
（1） 几千个recipes: 对于oe-core， meta-openembedded， meta-qt5大约2200个。通过Metadata Index知道多余8400
（2） 大部分和buildroot一样
（3） 更多的语言: Java, Go, Rust, smalltalk
（4） 对于Qt3仍有一个起作用的layer
（5） meta-virtualization（Docker， KVM， LXC， Xen）和 meta-openstack layers


Buildroot 依赖方法
（1） 极简依赖， 如果一个功能可以关闭，那么默认关闭
（2） 很多自动依赖，比如，如果你开启OpenSSL，将自动从其他可提供SSL支持的enabled的包中获得SSL支持
（3） 默认毫不费力的的得到小的根文件系统


Yocto Project 依赖方法
（1） 在distribution级进行package 配置
    开启OpenSSL将对所有package打开，但是可以对一些package关闭，相反，也可以对选定的pacakge开启一些功能。
（2） 可以在machine级进行修改，但是应该避免这样做
（3） 每个recipe可以定义自己的默认功能集，一个稳健的默认配置。


Buildroot 更新/安全
（1） 每三个月release，两个月开发，一个月稳定
（2） release包含package版本更新： security 更新和major 更新
（3） 核心架构也可能潜在性的发生改变
（4） 没有LTS版本，用于需要自己处理
（5） 正在提供一个脚本来评估给定buildroot配置中未解决的CVE （Common Vulnerabilities & Exposures）


Yocto Project 更新/安全
（1） 每6个月release，一次在4月，一次在10月
（2） 可通过wiki: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.1_Status了解planning和roadmap
（3） 在M1和最终release之间的三个月内包含4个milestone
（4） 至少先前和当前release的版本有指定维护者，他们获取安全和重要的解决方法，但是没有recipe更新
（5） 旧版本由社区维护


Buildroot 检测配置修改
（1） Buildroot不很智能
（2） 当修改配置是，它不尝试检测哪些需要rebuild
（3） 一旦build一个package，buildroot将不rebuild它，除非你强制
（4） 大的配置修改需要full rebuild
（5） 小的配置修改可以不需要full rebuild
（6） 一个配置，一个build，不能配置间不能分享


Yocto Project 检测配置修改
（1） bitbake 维护一个shared State Cache允许增加的builds
（2） 它通过创建inputs的checksum检测task的input修改
（3） 该cache可在所有的builds间共享， 对于类似的machines，build很快
（4） 可以跨主机分享该cache，比如一个夜间服务器和一个开发机，大大加快full build


Buildroot: architecture support
（1） 支持很多架构
（2） ARM（64）， MIPS， PowerPC（64）， x86/x86-64
（3） 也支持很多更专用的架构： Xtensa, Blackfin, ARC, m68k, SPARC, Microblaze, NIOSII; ARM noMMU, especially ARMv7-M
（4） 架构供应商提供援助: Imagination Technologies的MIPS, IBM的PowerPC64， Synopsys的ARC， Analog Devices的Blackfin


Yocto Project: architecture support
（1） core中， ARM， MIPS， PowerPC， X86，以及它们64bit 系列
（2） separate layers： Microblaze， NIOSII
（3） 通常芯片厂商维护他们自己的BSP layer： meta-intell， meta-altera （ARM & NIOSII）， meta-atmel， meta-fsl， meta-ti， mtea-xilinx ...
（4） 社区提供： meta-rockchip， meta-sunxi


Buildroot: minimal build
最小的build花费15分25秒，image size 2.2MB

yocto project: minimal build
最小build花费50分47秒， image size为4.9MB。 如果有存在的sstate-cache，花费1分21秒



License
（1） 都可以创建一个使用许可证的列表
（2） 都能够检测到许可证更改
（3） Yocto项目可以剔除GPLv3


Buildroot & Yocto 选择

Buildroot
（1） 非常专用的CPU架构
（2） 非常小的rootfs < 8M
（3） 对工程师没有很大的要求
（4） 不支持各种mechines或者类似的系统
（5） 不需要包/部分系统的更新
（6） 小系统

yocto
（1） 不是非常特殊的CPU架构，不是非常小的rootfs，需要有经验的工程师。
（2） 不是非常特殊的CPU架构，不是非常小的rootfs，需要有经验的工程师。支持几种类似的系统
（3） 不是非常特殊的CPU架构，不是非常小的rootfs，需要有经验的工程师。需要更新包和部分系统
（4） 不是非常特殊的CPU架构，不是非常小的rootfs，需要有经验的工程师。非常大的系统