You probably don’t need Yocto, and that’s fine

你可能并不需要 Yocto，这没关系

New customers often look surprised when, during the planning phase, we ask whether they really need Yocto. The unspoken assumption is usually that any serious embedded Linux project these days has to use Yocto. We at sigma star gmbh consider ourselves power users and Yocto experts. That’s exactly why we’re often the ones telling our customers to think twice before reaching for it. So why is Yocto the default, and when is it the wrong default?

当我们在规划阶段询问新客户是否真的需要 Yocto 时，他们通常会感到惊讶。人们往往有一种默认的假设：如今任何严肃的嵌入式 Linux 项目都必须使用 Yocto。我们 sigma star gmbh 的团队自认为是高级用户和 Yocto 专家，正因如此，我们经常建议客户在选择它之前三思而后行。那么，为什么 Yocto 会成为默认选择？又在什么情况下它是不合适的选择呢？

What is Yocto, actually?

到底什么是 Yocto？

People sometimes call it “the Yocto Linux distribution”. That’s not what it is. Yocto is a toolkit for building your own Linux distribution. The Yocto Project itself ships a reference distribution called Poky, built from bitbake, openembedded-core, and meta-yocto.

人们有时称其为“Yocto Linux 发行版”，但事实并非如此。Yocto 是一个用于构建你自己的 Linux 发行版的工具包。Yocto 项目本身提供了一个名为 Poky 的参考发行版，它由 bitbake、openembedded-core 和 meta-yocto 构建而成。

The ability to assemble a Linux system that matches your needs exactly makes Yocto incredibly powerful for embedded projects. You can compile the whole user space for your CPU, apply patches to any component, toggle features on or off in any recipe, and pin or change every version. On top of that, many System on Chip (SoC) vendors and hardware partners publish ready-to-use Board Support Package (BSP) layers, which give you a working starting point on real hardware.

能够组装出完全符合需求的 Linux 系统，使得 Yocto 在嵌入式项目中极其强大。你可以为你的 CPU 编译整个用户空间，为任何组件应用补丁，在任何配方（recipe）中开启或关闭功能，并锁定或更改每个版本。此外，许多片上系统（SoC）供应商和硬件合作伙伴发布了可直接使用的板级支持包（BSP）层，这为你提供了在真实硬件上工作的起点。

That mix of flexibility and vendor support makes Yocto the default choice. The same mix also turns it into a trap when you don’t actually need that much control.

这种灵活性与供应商支持的结合，使 Yocto 成为了默认选择。但当你实际上并不需要那么高的控制权时，同样的组合也会让你陷入陷阱。

Your distribution means your responsibility

你的发行版意味着你的责任

With regulations like the Cyber Resilience Act (CRA), product vendors now have to keep the software they ship secure and provide security updates for the lifetime of the product. That can be a long time to maintain a Linux system.

随着《网络弹性法案》（CRA）等法规的出台，产品供应商现在必须确保其交付的软件安全，并在产品生命周期内提供安全更新。对于维护一个 Linux 系统来说，这可能是一个漫长的过程。

A regular Yocto release lives only about seven months, until the next release lands. Long Term Support (LTS) releases get up to four years of updates, which is the current policy starting with Yocto 5.0 (Scarthgap).

常规的 Yocto 版本生命周期仅约七个月，直到下一个版本发布。长期支持（LTS）版本可获得长达四年的更新，这是从 Yocto 5.0 (Scarthgap) 开始实施的现行政策。

One might ask why four years isn’t enough. But there’s a less obvious problem. To see it, we need to look at what a Yocto LTS release actually maintains.

有人可能会问，为什么四年还不够？但这里有一个不太明显的问题。要理解这一点，我们需要看看 Yocto LTS 版本到底维护了什么。

A Yocto release is a set of bitbake recipes for software components, with specific versions and metadata, plus the reference distribution Poky. During the maintenance period, the Yocto maintainers apply bug and security fixes to those components and to Poky. For software components, those fixes usually take the form of backports from newer upstream versions.

Yocto 版本是一组用于软件组件的 bitbake 配方，包含特定的版本和元数据，以及参考发行版 Poky。在维护期间，Yocto 维护者会对这些组件和 Poky 进行错误修复和安全补丁。对于软件组件，这些修复通常以从较新的上游版本进行反向移植（backport）的形式实现。

And here’s the twist. Since Yocto is a tool to build your own distribution, you’ve most likely made changes like these:

• Non-trivial patches or local tweaks to a handful of components.
• Extra components added on top of what Yocto ships.
• Version bumps or pins to pick up a fix or hold a known-good state.

关键点在于：由于 Yocto 是一个构建你自己的发行版的工具，你很可能已经做了以下改动：

• 对少数组件进行了非平凡的补丁或本地调整。
• 在 Yocto 原有基础上添加了额外的组件。
• 为了获取修复或保持已知良好状态，对版本进行了升级或锁定。

With every Yocto maintenance release, you’ll have to check whether your changes still apply cleanly on top of the new state. On top of that, you need to confirm that the components you added or pinned still receive fixes from somewhere, because Yocto’s maintainers don’t know about them. At the end of the day, it’s your maintenance work.

在每次 Yocto 维护版本发布时，你都必须检查你的改动是否仍能干净地应用于新状态之上。此外，你还需要确认你添加或锁定的组件是否仍能从某处获得修复，因为 Yocto 的维护者并不了解它们。归根结底，这是你自己的维护工作。

If you take Poky and use it almost unchanged, a fair question to ask is: Why are you using Yocto in the first place?

如果你直接使用 Poky 且几乎不做改动，那么一个合理的问题是：你当初为什么要使用 Yocto？

The elephant in the room: the Linux kernel

显而易见的问题：Linux 内核

Yocto ships a Linux kernel and maintains it as part of each release. But you probably won’t use it unmodified. You almost always have to apply at least your vendor’s patches, and run a kernel new enough to include the drivers and fixes you depend on. So once you factor in CVE tracking, the kernel alone is a big part of your maintenance work, whether you use Yocto or not.

Yocto 提供了一个 Linux 内核，并将其作为每个版本的一部分进行维护。但你很可能不会直接使用它。你几乎总是需要至少应用供应商的补丁，并运行一个足够新的内核，以包含你所依赖的驱动程序和修复。因此，一旦考虑到 CVE 跟踪，无论你是否使用 Yocto，内核本身都是你维护工作中的重要部分。

There’s a way to keep that work under control. We strongly advise our customers to build on top of an LTS kernel from kernel.org and keep all their changes in a tidy patch queue. To stay current on security fixes, move to each new stable release and re-apply the patch queue. kernel.org maintains LTS kernels for years, so your patch queue usually applies cleanly and only needs real work when you jump to a new LTS release.

有一种方法可以控制这项工作。我们强烈建议客户基于 kernel.org 的 LTS 内核进行构建，并将所有改动保持在一个整洁的补丁队列中。为了保持安全修复的及时性，请迁移到每个新的稳定版本并重新应用补丁队列。kernel.org 会维护 LTS 内核多年，因此你的补丁队列通常可以干净地应用，只有在跳转到新的 LTS 版本时才需要进行实际的调整。

Depending on your setup and security requirements, the same applies to the bootloader, which is usually just as vendor-specific.

根据你的设置和安全要求，同样的方法也适用于引导加载程序（bootloader），它通常也具有同样的供应商特定性。

And for completeness: sticking with the kernel your vendor ships is usually a bad idea. Vendor kernels sit years behind kernel.org, rarely receive updates, and miss almost all security fixes. Exceptions prove the rule.

顺便提一下：坚持使用供应商提供的内核通常是个坏主意。供应商内核往往落后于 kernel.org 多年，很少收到更新，并且几乎错过了所有的安全修复。例外情况只是证明了这一规则。

The hidden cost of a custom distribution

定制发行版的隐形成本

Building “your own distribution” sounds great in a slide deck. In practice, it costs real engineering time.

在演示文稿中，“构建你自己的发行版”听起来很棒。但在实践中，它需要耗费大量的工程时间。

• Build times. Yocto compiles practically everything from source. A clean build of a non-trivial image takes hours on a fast workstation.

• Disk and CI cost. A working Yocto build directory easily reaches 100 GiB or more. CI runners need beefy storage and a way to share sstate between jobs.

• Learning curve. bitbake recipes, layers, dynamic layers, classes, overrides, bbappend files, PACKAGECONFIG… the list of things you need to internalise before you can ship a Yocto image is long.

• BSP layer quality varies. Some SoC vendors ship clean, well-maintained BSP layers. Others ship a meta-vendor layer that pins a five-year-old kernel or bootloader, and breaks every time you bump Poky.

• 构建时间： Yocto 几乎从源代码编译所有内容。在快速工作站上，构建一个非简单的镜像也需要数小时。

• 磁盘和 CI 成本： 一个工作的 Yocto 构建目录很容易达到 100 GiB 或更多。CI 运行器需要强大的存储空间，以及在作业之间共享 sstate 的方法。

• 学习曲线： bitbake 配方、层、动态层、类、覆盖、bbappend 文件、PACKAGECONFIG……在你能发布 Yocto 镜像之前，需要掌握的知识列表非常长。

• BSP 层质量参差不齐： 一些 SoC 供应商提供干净、维护良好的 BSP 层。而另一些则提供一个 meta-vendor 层，锁定五年前的内核或引导加载程序，并且每次你升级 Poky 时都会崩溃。

None of this is a reason to avoid Yocto. It’s a reason to make sure you actually need it before you commit.

以上这些都不是拒绝 Yocto 的理由。它们只是提醒你，在投入使用之前，请确保你确实需要它。

An alternative: reuse an established distribution

另一种选择：复用成熟的发行版

If all you really need is a solid Linux foundation to run your application on, an established distribution…

如果你真正需要的只是一个坚实的 Linux 基础来运行你的应用程序，那么一个成熟的发行版……