3 Yocto Project 术语

以下术语及定义可帮助初次使用 Yocto Project 开发环境的用户。 其中一些术语具有通用含义，为便于查阅，这里也一并列出。

Append Files

向配方文件追加构建信息的文件，也称 BitBake 追加文件或 .bbappend 文件。OpenEmbedded 构建系统要求每个追加文件都有对应的配方（.bb） 文件。此外，追加文件与对应配方必须使用相同的文件名主体， 只能在文件类型后缀上有所不同，例如 formfactor_0.0.bb 和 formfactor_0.0.bbappend。

追加文件中的信息扩展或覆盖同名配方中的信息。 用法示例见《Yocto Project 开发任务手册》的 “通过自己的层追加其他层元数据”一节。

命名追加文件时，可以使用“%”通配符匹配配方名称。 例如，假设追加文件名为:

busybox_1.21.%.bbappend

此文件会匹配任意 busybox_1.21.x.bb 版本的配方， 因而可以匹配以下所有配方名称：

busybox_1.21.1.bb
busybox_1.21.2.bb
busybox_1.21.3.bb
busybox_1.21.10.bb
busybox_1.21.25.bb

备注

“%”字符只能直接放在追加文件名的 .bbappend 部分之前， 不能用于名称中的其他位置。

BitBake

OpenEmbedded 构建系统用于构建镜像的任务执行器和调度器。 更多信息请参阅 BitBake 用户手册。

Board Support Package (BSP)

为特定硬件配置提供支持的一组驱动、定义和其他组件。 有关 BSP 的更多信息，请参阅 Yocto Project 板级支持包（BSP）手册。

Build Directory

指 OpenEmbedded 构建系统执行构建的区域。 通过 source 加载源码目录中的环境设置脚本时创建， 脚本为 oe-init-build-env，或使用 bitbake-setup 时的 init-build-env。TOPDIR 变量指向 Build Directory。

手动设置构建时（见 手动设置 Poky 参考发行版）， 创建 Build Directory 的方式很灵活。 以下示例假设 Source Directory 名为 bitbake-builds：

• 在源码目录中创建 Build Directory，使用默认名称 build：

  $ cd bitbake-builds
  $ source layers/openembedded-core/oe-init-build-env
  

• 也可以在加载 oe-init-build-env 时提供 Build Directory 的路径。路径中的中间目录必须已存在。 以下示例在现有 mybuilds 目录中创建名为 YP-6.1 的 Build Directory：

  $ source bitbake-builds/layers/openembedded-core/oe-init-build-env mybuilds/YP-6.1
  

  也可以使用绝对路径，将其放在当前工作目录之外：

  $ source bitbake-builds/layers/openembedded-core/oe-init-build-env /opt/mybuilds/YP-6.1
  

备注

默认情况下，Build Directory 包含 TMPDIR， 后者是构建系统使用的临时工作目录。TMPDIR 不能位于 NFS 上， 因而 Build Directory 默认也不能位于 NFS 上。 如果确有需要，可以在 build/conf/site.conf 中 将 TMPDIR 设置为本地磁盘上的目录。 这样就将 TMPDIR 与代表 Build Directory 的 TOPDIR 分离。

Build Host

在 Yocto Project 开发环境中用于构建镜像的系统， 有时也称为开发主机。

buildtools

二进制形式的构建工具，提供所需版本的开发工具，例如 Git、GCC、 Python 和 make，使缺少这些最低版本工具的开发主机也能运行 OpenEmbedded 构建系统。

有关下载或构建此类工具归档的详情，请参阅《参考手册》的 “所需的 Git、tar、Python、make 和 gcc 版本”一节。

buildtools-extended

在 buildtools 二进制工具基础上增加额外开发工具的集合， 例如运行 OpenEmbedded 构建系统所需版本的 GCC 编译器。

有关下载或构建此类工具归档的详情，请参阅《参考手册》的 “所需的 Git、tar、Python、make 和 gcc 版本”一节。

buildtools-make

buildtools 的变体，只提供运行 OpenEmbedded 构建系统 所需版本的 make。

Built-in Fragment

内置片段是一种特殊的 Configuration Fragment， 用于在全局范围内影响单个变量的值。 内置片段 不需要单独的配置文件， 但与标准 Configuration Fragment 一样，可以使用 bitbake-config-build 命令行工具启用或禁用。

声明内置片段时，遵循以下命名约定:

<fragment>:<variable name>

其中：

• <fragment> 为内置片段的名称。

• <variable name> 为该片段要修改的变量名称。

例如:

machine:MACHINE

这会设置 machine 内置片段，用于修改 MACHINE 的值。

通过此片段设置 MACHINE 时，必须采用以下语法:

machine/qemux86-64

这会将 MACHINE 设为 qemux86-64。

在 OpenEmbedded-Core (OE-Core) 中，可以通过 OE_FRAGMENTS_BUILTIN 变量获取可用 内置片段 的列表。

有关片段的更多详情，请参阅：

• 《Yocto Project 参考手册》的 使用配置片段 一节， 其中列出 OpenEmbedded Build System 支持的片段， 并提供片段管理的速查指南。

• 《Yocto Project 开发任务手册》的 在构建中创建新配置片段 一节，其中详细介绍如何为构建创建新片段。

Classes

提供逻辑封装和继承的文件，使常用模式只需定义一次， 就能方便地在多个配方中复用。有关 Yocto Project 类的参考信息， 请参阅“类”章。 类文件使用 .bbclass 扩展名。

Configuration File

保存全局变量定义、用户定义变量和硬件配置信息的文件。 这些文件告诉 OpenEmbedded 构建系统要构建什么， 以及为了支持特定平台应将哪些内容放入镜像。

配置文件使用 .conf 扩展名，存在多种类型，例如：

• Build Directory 中的 build/conf/local.conf 配置文件，包含影响每次构建的用户定义变量。

• meta-poky/conf/distro/poky.conf 定义 Yocto 发行版配置变量， 仅在使用该策略构建时生效。更多信息请参阅《Yocto Project 参考手册》的 创建自己的发行版 一节。

• 机器配置文件位于 BSP 层 中， 定义特定硬件的变量，仅在为该目标构建时使用。 例如 machine/beaglebone.conf 为 Texas Instruments ARM Cortex-A8 开发板定义变量。

• 配置片段，例如 core/yocto/sstate-mirror-cdn， 定义可从命令行启用的配置片段。

更多配置文件示例见《Yocto Project 参考手册》的 源码目录结构 一节。

Configuration Fragment

Configuration Fragment （也称标准 Configuration Fragment） 是包含变量赋值等配置语句的 configuration file。 启用后，其配置在全局范围影响构建。 默认情况下，配置片段位于 Layer 的 conf/fragments/ 目录。

备注

另一类片段是 内置片段， 用于对单个变量进行全局赋值，不要与标准 配置片段 混淆。

片段的 configuration file 必须包含摘要 （BB_CONF_FRAGMENT_SUMMARY）和说明 （BB_CONF_FRAGMENT_DESCRIPTION），解释片段的用途。

在 OpenEmbedded-Core (OE-Core) 中，片段位置及其必需变量 由 bitbake.conf 通过 addfragments 指令，以及 OE_FRAGMENTS、OE_FRAGMENTS_METADATA_VARS 和 OE_FRAGMENTS_BUILTIN 变量指定。

可以使用 bitbake-config-build 命令行工具列出、启用和禁用片段。

有关片段的更多详情，请参阅：

• 《Yocto Project 参考手册》的 使用配置片段 一节， 其中列出 OpenEmbedded Build System 支持的片段， 并提供片段管理的速查指南。

• 《Yocto Project 开发任务手册》的 在构建中创建新配置片段 一节，其中详细介绍如何为构建创建新片段。

Container Layer

一种较灵活的定义，通常指包含多个相关子层的单次 Git 检出。 这些子层可以独立纳入项目的 build/conf/bblayers.conf。

某些情况下，例如 OpenEmbedded 的 meta-openembedded， 顶层 meta-openembedded/ 目录本身并不是实际的层， 因而不会直接将其写入 build/conf/bblayers.conf。 应纳入所需的层子目录，例如 meta-oe、 meta-python 等。

另一些容器层，例如 meta-security， 其顶层目录本身就是一个实际的层，同时还包含多个子层。 两者都可以纳入 build/conf/bblayers.conf。

无论哪种情况，“容器层”都只是用于描述包含多个有效 OpenEmbedded 层的 目录结构。

Cross-Development Toolchain

通常指在一种架构上运行、用于为另一种目标架构开发软件的一组开发工具。 这些工具链包含针对目标架构的交叉编译器、链接器和调试器。

Yocto Project 支持两种不同的交叉开发工具链：

• 为目标架构构建镜像时，仅由 BitBake 在其内部使用的工具链。

• 开发者在 BitBake 之外使用的可重定位工具链， 用于开发将在目标设备上运行的应用。

这些工具链的创建过程简单且自动化。 有关 Yocto Project 中工具链概念的说明，请参阅《Yocto Project 概览与概念手册》的 “交叉开发工具链生成”一节。 有关可重定位工具链的使用方式，另请参阅 Yocto 项目应用开发与软件开发套件（SDK/eSDK）手册。

Extensible Software Development Kit (eSDK)

面向应用开发者的定制 SDK。eSDK 允许开发者将库和程序的修改 合并回镜像，使其他应用开发者也能使用这些代码。

有关 eSDK 的信息，请参阅 Yocto 项目应用开发与软件开发套件（SDK/eSDK）手册。

Image

镜像是 BitBake 根据一组配方及相关元数据执行构建过程后生成的产物。 它是运行在特定硬件或 QEMU 上、用于特定场景的二进制输出。 Yocto Project 提供的受支持镜像类型列表见 “镜像”章。

Initramfs

初始 RAM 文件系统（Initramfs）是一种可选压缩的 cpio 归档，由 Linux 内核解压到 RAM 中的 特殊 tmpfs 实例，用作初始根文件系统。

它替代了旧的初始 RAM 磁盘（“initrd”）技术。 后者从 RAM 中模拟的块设备启动，效率较低： 与其他块设备一样，它需要经过文件系统层， 并将访问的文件内容复制到 RAM 中的文件缓存，带来额外开销。

备注

对引导加载程序而言，Initramfs 和“initrd”镜像 仍以相同方式复制到 RAM。 因此，大多数引导加载程序将 Initramfs 镜像 称为“initrd”或“init RAM disk”。

通常出于以下两个原因使用这种机制：

• 在需要不同设备驱动的多个系统上启动同一个内核二进制文件。 为每类系统定制 Initramfs 镜像， 包含访问最终根文件系统所需的特定内核模块。 桌面和服务器上的所有 GNU / Linux 发行版都使用这种技术。

• 加快启动。根文件系统解压到 RAM 后，访问最初的用户空间应用很快， 不必先初始化块设备、读取多个块，再经过具有自身开销的文件系统。 例如，可以很早就显示启动画面，稍后再挂载最终根文件系统， 并加载时间要求较低的内核驱动。

该 cpio 归档既可以由引导加载程序加载到 RAM， 也可以直接包含在内核二进制文件中。

有关创建和使用 Initramfs 的信息， 请参阅《Yocto Project 开发任务手册》的 “构建初始 RAM 文件系统（Initramfs）镜像” 一节。

Layer

一组相关配方。层将相关元数据集中起来，用于定制构建， 也能隔离为不同架构构建时使用的信息。 层具有层级关系，可以覆盖先前的定义。 可以纳入任意数量的 Yocto Project 可用层， 再在其后添加自己的层来定制构建。 可以在 Layer Index 中搜索适用于 Yocto Project 的层。

层的入门信息见《Yocto Project 概览与概念手册》的 “Yocto Project 层模型”一节。 更详细的信息见《Yocto Project 开发任务手册》的 “理解和创建层”一节。 BSP 层的专门讨论见《Yocto Project 板级支持包（BSP）开发者指南》的 “BSP 层”一节。

LTS

表示“长期支持”。在 Yocto Project 中，指选定的稳定版本， 为其提供至少四年的缺陷修复和安全修复。 详情见 长期支持版本 一节。

Metadata

元数据是 Yocto Project 的核心组成部分，用于构建 Linux 发行版。 它位于 OpenEmbedded Build System 构建镜像时解析的文件中。 通常包括配方、配置文件，以及与构建指令本身相关的其他信息， 还包括控制构建内容和构建效果的数据。 元数据也包含用于指定软件版本、获取位置的命令和数据， 以及对软件本身的修改或补充（补丁或辅助文件）， 用来修复缺陷或为特定场景定制软件。 OpenEmbedded-Core 是一组重要的、经过验证的元数据。

在内核上下文中，“内核元数据”指 yocto-kernel-cache Git 仓库中 的内核配置片段和功能。

Mixin

Mixin 层是社区可创建的一种层，用于为 LTS 版本 添加特定功能，或支持某个软件包的新版本。 详情见 长期支持版本 一节。

OpenEmbedded Build System

Yocto Project 使用的构建系统，以 Bitbake 为任务执行器。 在 Yocto Project 文档中，有时简称“构建系统”。 如果提及主机或目标自身的其他构建系统，文档会明确区分。

备注

Poky 的历史信息见 Poky 术语。

OpenEmbedded-Core (OE-Core)

OE-Core 是由基础配方、类及相关文件组成的元数据， 旨在供包括 Yocto Project 在内的多种 OpenEmbedded 派生系统共用。 它从 OpenEmbedded 社区开发的原始仓库中精选并精简而来， 形成规模较小、持续验证的核心配方集合， 受到严格管理并具有质量保证。

可以在 openembedded-core 浏览 OpenEmbedded-Core (OE-Core) 的源码。

Package

在 Yocto Project 中，指 BitBake 根据配方产生的打包输出， 即“烘焙完成的配方”。软件包通常包含由配方源码编译得到的二进制文件。 将内容交给 BitBake 运行，就是对其进行“烘焙”。

“软件包”一词在一般语境下的含义可能略有差异。 例如，“构建主机所需的软件包” 一节中的软件包指已编译的二进制文件，安装后可为 Linux 发行版增加功能。

另需注意，Yocto Project 历史上曾将配方称为软件包， 因此有些 BitBake 变量名称看起来不太准确， 例如 PR、PV 和 PE。

Package Groups

可任意组合的软件配方组。通常用于集合构建后共同完成某项任务的配方。 例如，一个软件包组可以包含公司的专有软件或增值软件配方， 也可以包含启用图形功能的配方。 软件包组本质上也是配方，因此文件同样使用 .bb 扩展名。

Poky

Poky 发音为 Pock-ee，是参考嵌入式发行版和参考测试配置。 它提供：

• 具有基本功能的发行版，用于展示如何定制发行版。

• 测试 Yocto Project 组件的方式，即用 Poky 验证 Yocto Project。

Poky 不是产品级发行版，而是进行定制的良好起点。

备注

Poky 曾经也是一个仓库，其中组合了 BitBake、 OpenEmbedded-Core (OE-Core)、 meta-yocto 仓库和 Yocto Project 文档， 这些内容通过 combo-layer 工具合并。

此仓库仍托管于 https://git.yoctoproject.org/poky，对于早于 Whinlatter（5.3） 且仍在维护的版本，仍会继续更新。 较新的版本改用 bitbake-setup 克隆并设置初始 OpenEmbedded Build System 环境。 用法见 Yocto Project 快速构建。 也可以按照《Yocto Project 开发任务手册》的 手动设置 Poky 参考发行版 一节手动设置上述仓库。

备注

Poky 最初是 OpenedHand 开发的开源项目。 OpenedHand 基于已有的 OpenEmbedded 构建系统开发 Poky， 旨在创建可提供商业支持的嵌入式 Linux 构建系统。 Intel Corporation 收购 OpenedHand 后，Poky 项目成为 Yocto Project 构建系统的基础。

Recipe

构建软件包的一组指令。配方描述从哪里获取源码、应用哪些补丁、 如何配置和编译源码等，也描述对库或其他配方的依赖。 配方表示逻辑执行单元、待构建的软件或镜像，使用 .bb 文件扩展名。

Reference Kit

能在特定硬件上运行的完整系统示例，包含 BSP、 构建主机 和其他组件。

SBOM

表示 软件物料清单。分发软件时，它描述使用的全部组件、 对应许可证、依赖关系、应用的修改，以及已经修复的已知漏洞。

软件接收者可以据此评估许可证合规问题和安全漏洞风险。

更多详情见维基百科的 软件供应链 条目。

OpenEmbedded 构建系统可根据构建软件镜像时使用的全部元数据， 以 SPDX 格式为项目生成此类文档。 请参阅《开发任务手册》的 “创建软件物料清单”一节。

Source Directory

指为使用 Yocto Project 构建镜像而设置环境后创建的目录结构， 可以通过两种方式得到：

• 使用 bitbake-setup 命令行工具，见 使用 bitbake-setup 设置环境。

• 手动设置 层，见 手动设置 Poky 参考发行版。

两种方式最终都会得到一组 层 和一个 Build Directory， 它们共同组成构建的源码目录。文档通常用“bitbake-builds”表示该目录。

Source Directory 的典型布局为：

bitbake-builds/
├── build/
└── layers/

其中，layers/ 包含项目的 层， build/ 对应 Build Directory。

《Yocto Project 参考手册》的 源码目录结构 一节 详细介绍 Source Directory 的结构及其组成部分。

备注

OpenEmbedded 构建系统不支持文件名或目录名中的空格。 请确保使用的源码目录不包含此类名称。

Source Directory 包含 BitBake、 OpenEmbedded-Core (OE-Core) 和其他支持 Yocto Project 的文件。

因此，要使用 Yocto Project 进行任何开发， 必须先在开发系统上准备好 Source Directory。

SPDX

表示 软件包数据交换，是用于提供 软件物料清单 （SBOM） 的开放标准。它由 Linux Foundation 项目 制定， OpenEmbedded 构建系统使用它为每个软件镜像提供对应的 SBOM。

详情见维基百科的 SPDX 页面， 以及《开发任务手册》的 “创建软件物料清单”一节。

SPDX License Expression

SPDX 定义的标准，用于表达一个或多个许可证如何适用于某项作品。

SPDX 许可证表达式的语法定义见 SPDX 规范。

Sysroot

交叉编译时，目标文件系统的布局和内容可能与主机系统不同。 系统根目录 （sysroot）是一个结构类似目标文件系统的目录， 可作为交叉编译所针对的环境。

在交叉编译工具链中，系统根目录通常包含 C 库和内核头文件， 以及 C 库的已编译二进制文件。 multilib 工具链 可以包含多个 C 库二进制变体， 分别为某种目标指令集（如 armv5、armv7、armv8）编译， 并可能针对特定 CPU 核心优化。

具体到 OpenEmbedded 构建系统和 Yocto Project，每个配方有两个系统根目录：

• 目标系统根目录 包含构建配方所需的全部 目标端 库和头文件。

• native 系统根目录 包含构建配方所需的全部 主机端 文件和可执行文件。

控制系统根目录创建和存储方式的变量见 SYSROOT_*。

Task

BitBake 中属于某个配方的执行单元，例如 do_compile、 do_fetch 和 do_patch 等。 构建系统的一项主要优势是：每个配方通常会产生许多任务， 其中大量任务可以并行执行，包括不同配方的任务， 或同一配方中相互独立的任务，能够充分利用构建系统的并行能力。

Toaster

Yocto Project 的 OpenEmbedded Build System 的 Web 界面， 可以用来配置和运行构建。构建信息会被收集并保存到数据库中。 有关 Toaster 的信息，请参阅 Toaster 用户手册。

Upstream

指不位于本地开发系统，而位于源码维护者控制的远程位置的源码或仓库。 例如，开发者要修改某段代码，首先需要从“上游”源获取一份副本。