Yocto - 使用Yocto开发嵌入式Linux系统_13 创建定制层
Creating Custom Layers
除了使用社区或供应商提供的现有图层外，我们还将在本章中学习如何为我们的产品创建图层。此外，我们还将了解如何创建机器定义和分布，并从中获益，从而更好地组织我们的源代码。
In addition to using existing layers from the community or vendors, we will learn how to create layers for our products in this chapter. Additionally, we will discover how to create a machine definition and distribution and profit from them to organize our source code better.
1，Making a new layer
在创建我们的图层之前，最好先在以下网站查看是否已经有类似的图层：
http://layers.openembedded.org 。
Before creating our layer, it’s always a good idea to check whether a similar one is already available at the following website:
http://layers.openembedded.org .
如果我们仍在寻找适合我们需要的图层，下一步就是创建目录。通常，图层名称以 meta- 开头，但这并不是技术要求。
If we are still looking for a layer suitable for our needs, the next step is to create the directory. Usually, the layer name starts with meta-, but this is not a technical restriction.
<layer>/conf/layer.conf 文件是每个层都需要的层配置文件。可以使用 Poky 中提供的 BitBake 中名为 bitbake-layers 的工具创建新层，如以下命令所示：
The
<layer>/conf/layer.conf file is the layer configuration file required for every layer. The new layer can be created with a tool called
bitbake-layers from BitBake, provided in Poky, as shown in the following command:
[ Figure 12.1 – Creating a new layer using bitbake-layers ]
创建图层后，我们需要使用以下命令将其包含在 build/conf/bblayers.conf 文件中：
After creating the layer, we need to include it in the
build/conf/bblayers.conf file using the following command:
[ Figure 12.2 – Adding meta-newlayer to build/conf/bblayers.conf ]
Tip
默认情况下，bitbake-layers 工具生成的图层优先级为 6。我们仍然可以使用参数自定义优先级。
The
bitbake-layers tool, by default, generates the layer with layer priority 6. We can still customize the priority using parameters.
最后一条命令生成图层，如下图所示：
The last command generates the layer, as shown in the following figure:
[ Figure 12.3 – The meta-newlayer layout when created ]
meta-newlayer 的默认图层配置文件是使图层正常工作的最低配置。不过，也可以对其进行定制，以包含未来所需的配置。
The default layer configuration file for
meta-newlayer is the minimal configuration to get the layer working. However, it can be customized to include configurations required in the future.
下图显示了我们刚刚创建的meta-newlayer层的默认 conf/layer.conf 内容：
The following figure shows the content of default
conf/layer.conf for the
meta-newlayer layer we just created:
[ Figure 12.4 – The meta-newlayer/conf/layer.conf minimal configuration ]
一些可能需要添加或更改的常用变量是 LAYERVERSION 和 LAYERDEPENDS。如果我们的图层需要其他图层才能工作，这两个变量就非常有用。这两个变量的名称必须以图层名称为后缀，如下所示：
Some commonly used variables that may need to be added or changed are
LAYERVERSION and
LAYERDEPENDS. Those are useful if our layer requires other layers to work. Both variables’ names must be suffixed with the layer’s name, as follows:
* LAYERVERSION：这是一个可选变量，用一个数字指定图层的版本。该变量在 LAYERDEPENDS 变量中使用，以取决于特定的层版本--例如，LAYERVERSION_meta-newlayer = “1”。
*
LAYERVERSION: This is an optional variable that specifies the version of the layer in a single number. This variable is used within the
LAYERDEPENDS variable to depend on a specific layer version – for example,
LAYERVERSION_meta-newlayer = "1".
* LAYERDEPENDS: 列出配方所依赖的层，用空格分隔，例如，我们用 LAYERDEPENDS_meta-newlayer += “meta-otherlayer:2” 来添加对 meta-otherlayer 第 2 版的依赖。
*
LAYERDEPENDS: This lists the layers that the recipes depend upon, separated by spaces – for example, we add the dependency for version
2 of
meta-otherlayer with LAYERDEPENDS_meta-newlayer += "meta-otherlayer:2".
如果依赖关系无法满足或版本号不匹配，则会发生错误。现在，层结构的基础已经创建。在接下来的章节中，我们将学习如何对其进行扩展。
An error is incurred if a dependency cannot be satisfied or the version numbers do not match. The base of the layer structure is now created. In the following sections, we will learn how to extend it.
2，Adding metadata to the layer
图层元数据可实现两个目标--添加新软件，或特征化和修改现有元数据。
Layer metadata can serve two goals – add new software, or feature and modify existing metadata.
我们可以在一个新层中包含多个元数据文件，如配方、映像和 bbappend 文件。在 meta-yocto-bsp 和 meta-yocto 上有几个 bbappend 文件的示例。我们将在第 13 章 “自定义现有配方 ”中探讨它们的一些常用用法。
We can include several metadata files on a new layer, such as recipes, images, and
bbappend files. There are several examples of
bbappend files on
meta-yocto-bsp and
meta-yocto. We will explore some of their common uses in Chapter 13, Customizing Existing Recipes.
在接下来的章节中，我们将对图层元数据进行一些常见的修改。
In the next sections, we will go through some common modifications to layer metadata.
Creating an image
从本质上讲，映像文件是一组按目的分组并以受控方式配置的软件包。我们可以从头开始创建镜像文件，也可以通过重复使用现有镜像文件并添加必要的额外软件包来创建镜像文件。
Image files are, in essence, a set of packages grouped for a purpose and configured in a controlled way. We can create an image from scratch or create one by reusing an existing one and adding the extra necessary packages.
在可能的情况下，我们应该重复使用现有的图像，这样可以使代码维护更易于管理，并突出功能差异。例如，我们可能想在 core-image-full-cmdline 图像文件中加入一个应用程序并移除图像功能。在这种情况下，我们可以在 recipes-mine/images/my-image-full-cmdline.bb 文件中创建一个映像，使用下面几行代码：
We should reuse an existing image when possible, making code maintenance more manageable and highlighting the functional differences. For example, we may want to include an application and remove an image feature from the
core-image-full-cmdline image file. In that case, we can create an image in the
recipes-mine/images/my-image-full-cmdline.bb file with the following lines of code:
[ Figure 12.5 – The content of my-image-full-cmdline.bb ]
core-image 类提供的映像功能为常用功能提供了有用的构建模块，从头开始创建图像时应使用该类。例如，我们可以在 recipes-mine/images/my-image-strace.bb 文件中创建一个映像，该文件由以下几行代码组成：
The
core-image class provides image features that offer helpful building blocks of commonly used functionality and should be used when creating an image from scratch. For example, we can create an image in the
recipes-mine/images/my-image-strace.bb file consisting of the following lines of code:
[ Figure 12.6 – The content of my-image-strace.bb ]
Tip
列表追加操作符 (+=) 可确保 build/conf/local.conf 添加新的 EXTRA_IMAGE_FEATURES 变量。
The list appending operator (
+=) guarantees that a new
EXTRA_IMAGE_FEATURES variable can be added by
build/conf/local.conf.
CORE_IMAGE_EXTRA_INSTALL 是一个变量，当我们继承 core-image 类时，应使用该变量在镜像中包含额外的软件包，从而方便镜像的创建。该类增加了对 IMAGE_FEATURES 变量的支持，从而避免了代码的重复。
CORE_IMAGE_EXTRA_INSTALL is the variable we should use to include extra packages in the image when we inherit the
core-image class, which facilitates image creation. The class adds support for the
IMAGE_FEATURES variable, which avoids duplication of code.
目前支持以下映像功能，详见《Yocto 项目参考手册》（
11 Features — The Yocto Project ® 4.0.4 documentation ）中的 “映像功能 ”部分：
Currently, the following image features are supported, as detailed in the Image Features section of the Yocto Project Reference Manual (
11 Features — The Yocto Project ® 4.0.4 documentation ):
* allow-empty-password: Allows Dropbear and OpenSSH to accept logins from accounts that have an empty password string.
* allow-root-login: Allows Dropbear and OpenSSH to accept root logins.
* dbg-pkgs: Installs debug symbol packages for all packages installed in a given image.
* debug-tweaks: Makes an image suitable for development (for example, allows root logins, logins without passwords – including root ones, and enables post-installation logging).
* dev-pkgs: Installs development packages (headers and extra library links) for all packages installed in a given image.
* doc-pkgs: Installs documentation packages for all packages installed in a given image.
* empty-root-password: This feature, or debug-tweaks, is required if you want to allow root login with an empty password.
* hwcodecs: Installs hardware acceleration codecs.
* lic-pkgs: Installs license packages for all packages installed in a given image.
* nfs-server: Installs an NFS server.
* overlayfs-etc: Configures the /etc directory to be in overlayfs. This allows you to store device-specific information elsewhere, especially if the root filesystem is configured as read-only.
* package-management: Installs package management tools and preserves the package manager database.
* perf: Installs profiling tools such as perf, systemtap, and LTTng.
* post-install-logging: Enables you to log postinstall script runs in the /var/log/postinstall.log file on the first boot of the image on the target system.
* ptest-pkgs: Installs ptest packages for all ptest-enabled recipes.
* read-only-rootfs: Creates an image whose root filesystem is read-only.
* read-only-rootfs-delayed-postinsts: When specified in conjunction with read-only-rootfs, it specifies that post-install scripts are still permitted.
* serial-autologin-root: When specified in conjunction with empty-root-password, it will automatically login as root on the serial console.
* splash: Enables you to show a splash screen during boot. By default, this screen is provided by psplash, which does allow customization.
* ssh-server-dropbear: Installs the Dropbear minimal SSH server.
* ssh-server-openssh: Installs the OpenSSH SSH server, which is more full-featured than Dropbear. Note that if both the OpenSSH SSH server and the Dropbear minimal SSH server are present in IMAGE_FEATURES, then OpenSSH will take precedence and Dropbear will not be installed.
* stateless-rootfs: Specifies that an image should be created as stateless – when using systemd, systemctl-native will not be run on the image, leaving the image to be populated at runtime by systemd.
* staticdev-pkgs: Installs static development packages, which are static libraries (for example, *.a files), for all packages installed in a given image.
* tools-debug: Installs debugging tools such as strace and gdb.
* tools-sdk: Installs a full SDK that runs on a device.
* tools-testapps: Installs device testing tools (for example, touchscreen debugging).
* weston: Installs Weston (a reference Wayland environment).
* x11-base: Installs the X server with a minimal environment.
* x11: Installs the X server.
* x11-sato: Installs the OpenedHand Sato environment.
Adding a package recipe
Poky 基于 Autotools、CMake 和 Meson，包含多个类，将最常见的开发工具的流程抽象为项目。软件包配方是我们指示 BitBake 对应用程序、内核模块或项目提供的任何软件执行获取、解包、打补丁、配置、编译和安装任务的方式。此外，Poky 中包含的类列表可以在《Yocto 项目参考手册》（
5 Classes — The Yocto Project ® 4.0.4 documentation ）中的 “类 ”部分查看。
Poky includes several classes that makes the process for the most common development tools as projects abstract, based on Autotools, CMake, and Meson. A package recipe is how we can instruct BitBake to perform the
fetch,
unpack,
patch,
configure,
compile, and
install tasks on our application, kernel module, or any software a project provides. In addition, a list of classes included in Poky can be seen in the Classes section in the Yocto Project Reference Manual (
5 Classes — The Yocto Project ® 4.0.4 documentation ).
下面提供了一个明确执行编译和安装任务的直接配方：
A straightforward recipe that executes the
compile and
install tasks explicitly is provided as follows:
[ Figure 12.7 – A manually crafted helloworld recipe ]
do_compile 和 do_install 代码块为我们提供了 Shell 脚本命令，用于将生成的二进制文件编译并安装到目标目录（引用为 ${D}），目的是将安装目录重定位到 build/tmp/work/ 目录内的路径。假设我们正在开发一个基于 Autotools 的项目。如果是这样，我们可以在剥离的示例中使用 autotools 类，从 poky/meta/recipes-core/dbus-wait/dbus-wait_git.bb 文件中的配方中提取，这样就可以避免大量代码重复：
The
do_compile and
do_install code blocks provide the Shell Script command for us to build and install the resulting binary into the destination directory, referenced as
${D}, which aims to relocate the installation directory to a path inside the
build/tmp/work/ directory. Suppose that we are working on an Autotools-based project. If so, we can avoid a lot of code duplication by using the
autotools class in the stripped example, extracted from the recipe in the
poky/meta/recipes-core/dbus-wait/dbus-wait_git.bb file, as follows:
[ Figure 12.8 – The content of poky/meta/recipes-core/dbus-wait/dbus-wait_git.bb ]
只需继承第 19 行中的 autotools 类，就能提供执行以下任务所需的全部代码：
The simple act of inheriting the autotools class in line 19 is to provide all the code required to do the following tasks:
* 更新 configure 脚本代码和工件
* 更新 libtool 脚本
* 运行 configure 脚本
* 运行 make
* 运行 make install
* Update the
configure script code and artifacts
* Update the
libtool scripts
* Run the
configure script
* Run
make
* Run
make install
同样的概念也适用于其他构建工具，如 CMake 和 Meson。此外，为了支持新的构建系统并避免代码重复，每个版本支持的类的数量都在增加。
The same concepts apply to other building tools, as is the case for
CMake and
Meson. Additionally, the number of supported classes is growing in every release to support new build systems and avoid code duplication.
Automatically creating a base package recipe using devtool
正如我们在第 9 章 Yocto 项目的开发中的 “从外部 Git 仓库创建配方 ”一节所学，devtool 可通过以下命令自动根据现有项目创建配方：
As we learned in the Creating a recipe from an external Git repository section in Chapter 9, Developing with the Yocto Project, devtool automates the process of creating a recipe based on an existing project with the following command:
[ Figure 12.9 – The command line to generate the recipe for bbexample ]
在幕后，devtool 运行 recipetool 生成配方，并自动将所有预置信息配置到新配方文件中。最终结果存储在工作区目录中，这是一个由 devtool 维护的层。要将配方文件复制到目标层，我们可以使用 devtool 命令，如图所示：
Behind the scenes,
devtool ran the
recipetool to generate a recipe and automatically configure all pre-built information into the new recipe file. The end result is stored in the
workspace directory, a layer maintained by
devtool. To copy the recipe file to the target layer, we can use the
devtool command, as shown here:
[ Figure 12.10 – The command line to deploy the bbexample recipe to meta-newlayer ]
创建的 meta-newlayer/recipes-bbexample/bbexample/bbexample_git.bb 文件如下所示：
The created
meta-newlayer/recipes-bbexample/bbexample/bbexample_git.bb file is shown in the following snippet:
[ Figure 12.11 – The content of bbexamle_git.bb ]
devtool 创建了一个基本配方，但不应将其视为最终配方。你应该检查编译选项、额外的元数据信息等。
The devtool has created a base recipe, which should not be taken as a final recipe. You should check for compilation options, extra metadata information, and so on.
Adding support to a new machine definition
尽管创建用于 Poky 的新机器定义是一项简单易行的任务，但也不能小看它。根据我们需要在 BSP 层支持的功能集，可能需要检查引导加载器、内核和硬件支持驱动程序。
Even though creating a new machine definition for use in Poky is a straightforward task, it shouldn’t be underestimated. Depending on the set of features we need to support at the BSP layer, it can involve checking the bootloader, kernel, and hardware support drivers.
Yocto 项目支持 ARM、ARM64、x86、x86-64、PowerPC、PowerPC 64、MIPS、MIPS64、RISC-V 32 和 RISC-V 64，代表了当前最常用的嵌入式体系结构。
The Yocto Project supports ARM, ARM64, x86, x86-64, PowerPC, PowerPC 64, MIPS, MIPS64, RISC-V 32, and RISC-V 64, representing the most currently used embedded architectures.
机器定义中常用的变量集如下：
The prevailing set of variables used in a machine definition is as follows:
* TARGET_ARCH： 设置机器架构，例如 ARM 和 x86-64
* PREFERRED_PROVIDER_virtual/kernel： 如果需要使用特定内核，该选项将覆盖默认内核（linux-yocto）。
* SERIAL_CONSOLES：定义串行控制台及其速度
* MACHINE_FEATURES： 描述硬件特性，因此默认情况下映像中包含了所需的软件栈
* KERNEL_IMAGETYPE： 用于选择内核映像类型，例如 bzImage 或 Image
* IMAGE_FSTYPES： 设置生成的文件系统映像类型--例如，tar.gz、ext4 和 ubifs
* TARGET_ARCH: This sets the machine architecture – for example, ARM and x86-64
* PREFERRED_PROVIDER_virtual/kernel: This overrides the default kernel (linux-yocto) if you need to use a specific one
* SERIAL_CONSOLES: This defines serial consoles and their speeds
* MACHINE_FEATURES: This describes hardware features, so the software stack required is included in the images by default
* KERNEL_IMAGETYPE: This is used to choose the kernel image type – for example, bzImage or Image
* IMAGE_FSTYPES: This sets the generated filesystem image types – for example, tar.gz, ext4, and ubifs
您可以在 Poky 源代码的 meta-yocto-bsp/conf/machine/ 目录中查看机器定义文件的示例。在描述新机器时，我们应特别注意它在 MACHINE_FEATURES 中支持的特定功能。这样，这些功能所需的软件就会被安装到映像中。目前 MACHINE_FEATURES 的可用值如下：
You can see examples of machine definition files inside the Poky source code in the
meta-yocto-bsp/conf/machine/ directory. When describing a new machine, we should pay special attention to specific features supported by it in
MACHINE_FEATURES. This way, the software needed to help these features is installed into the images. The values currently available for
MACHINE_FEATURES are listed as follows:
* acpi: The hardware has ACPI (x86/x86-64 only)
* alsa: The hardware has ALSA audio drivers
* apm: The hardware uses APM (or APM emulation)
* bluetooth: The hardware has integrated BT
* efi: Support for booting through EFI
* ext2: The hardware HDD or microdrive
* keyboard: The hardware has a keyboard
* numa: The hardware has non-uniform memory access
* pcbios: Support for booting through BIOS
* pci: The hardware has a PCI bus
* pcmcia: The hardware has PCMCIA or CompactFlash sockets
* phone: Mobile phone (voice) support
* qemu-usermode: QEMU can support user-mode emulation for this machine
* qvga: The machine has a QVGA (320x240) display
* rtc: The machine has a real-time clock
* screen: The hardware has a screen
* serial: The hardware has serial support (usually RS232)
* touchscreen: The hardware has a touchscreen
* usbgadget: The hardware is USB gadget device-capable
* usbhost: The hardware is USB host-capable
* vfat: FAT filesystem support
* wifi: The hardware has integrated Wi-Fi
Wrapping an image for your machine
在任何 BSP 支持层开发的最后阶段，都应为机器创建即用映像。映像的类型取决于处理器、电路板上的外设和项目限制。
Creating a ready-to-use image for a machine should be addressed at the end of any BSP support layer development. The type of image depends on the processor, peripherals included on the board, and project restrictions.
分区镜像是最常用的直接用于存储的镜像。Yocto 项目有一个名为 wic 的工具，提供了生成这种映像的灵活方法。它允许根据模板文件（.wks）创建分区映像，模板文件是用描述目标映像布局的通用语言编写的。语言定义可在《Yocto 项目参考手册》（
8 OpenEmbedded Kickstart (.wks) Reference — The Yocto Project ® 4.0.4 documentation ）中的 OpenEmbedded Kickstart (.wks) Reference 部分找到。
The partitioned image is the most frequently used image for direct use in the storage. The Yocto Project has a tool called
wic, which provides a flexible way to generate this image. It allows the creation of partitioned images based on a template file (
.wks), written in a common language that describes the target image layout. The language definition can be found in the OpenEmbedded Kickstart (.wks) Reference section from The Yocto Project Reference Manual (
8 OpenEmbedded Kickstart (.wks) Reference — The Yocto Project ® 4.0.4 documentation ).
.wks 文件放置在 wic 目录内的图层中。在该目录中通常有多个文件，以指定不同的图像布局。但必须记住，所选结构必须与机器相匹配--例如，当考虑使用基于 i.MX 的机器时，该机器使用 U-Boot 从 SD 卡启动，SD 卡有两个分区，一个用于引导文件，另一个用于 rootfs。此处显示了相应的 .wks 文件：
The
.wks file is placed in our layer inside the
wic directory. It is common to have multiple files in this directory to specify different image layouts. However, it is essential to remember that the chosen structure must match the machine – for example, when considering the use of an i.MX-based machine that boots using U-Boot from an SD card with two partitions, one for the boot files and the other for
rootfs. The respective
.wks file is shown here:
[ Figure 12.12 – An example of a .wks file for an i.MX device using SPL ]
要启用基于 wic 的图像生成功能，只需在 IMAGE_FSTYPES 中添加 wic 即可。我们还可以通过设置 WKS_FILE 变量来定义要使用的 .wks 文件。
To enable the
wic-based image generation, it is a matter of adding
wic to
IMAGE_FSTYPES. We can also define the
.wks file to be used by setting the
WKS_FILE variable.
Using a custom distribution
发行版的创建既简单又复杂。创建发行版文件简单明了，但会对 Poky 的行为产生重大影响。根据我们的选项，它可能会导致与之前构建的二进制文件不兼容。
The creation of a distribution is a mix of simplicity and complexity. Creating the distribution file is straightforward but significantly impacts Poky’s behavior. Depending on our options, it may cause a binary incompatibility with previously built binaries.
发行版是我们定义全局选项的地方，例如工具链版本、图形后端和对 OpenGL 的支持。只有当 Poky 提供的默认设置无法满足我们的要求时，我们才应该制作一个发行版。
The distribution is where we define global options, such as the toolchain version, graphical backends, and support for OpenGL. We should make a distribution only if the default settings provided by Poky fail to fulfill our requirements.
通常，我们只打算更改 Poky 的一小部分选项。例如，我们要移除 X11 支持，改用帧缓冲器。例如，<layer>/conf/distro/my-distro.conf 文件所代表的示例发行版如下：
Usually, we intend to change a small set of options from Poky. For example, we remove the X11 support to use a framebuffer instead. We can easily accomplish this by reusing the Poky distribution and overriding the necessary variables – for example, the sample distribution represented by the
<layer>/conf/distro/my-distro.conf file is as follows:
[ Figure 12.13 – An example of a custom distribution file ]
要使用刚刚创建的发行版，我们需要在 build/conf/local.conf 文件中添加以下代码：
To use the distribution just created, we need to add the following piece of code to the build/conf/local.conf file:
[ Figure 12.14 – The line to set DISTRO on build/conf/local.conf ]
DISTRO_FEATURES 变量可能会影响配方的配置和软件包在映像中的安装，例如，如果我们想在任何机器和映像中使用声音，alsa 功能必须存在。下面的列表显示了 DISTRO_FEATURES 支持的值的当前状态，详情请参见《Yocto 项目参考手册》（
11 Features — The Yocto Project ® 4.0.4 documentation ）中的 “发行版特性 ”部分：
The DISTRO_FEATURES variable may influence how the recipes are configured and the packages are installed in images – for example, if we want to use sound in any machine and image, the alsa features must be present. The following list shows the present state for the DISTRO_FEATURES-supported values, as detailed in the Distro Features section in the Yocto Project Reference Manual (
11 Features — The Yocto Project ® 4.0.4 documentation ):
* 3g: Includes support for cellular data
* acl: Includes Access Control List support
* alsa: Includes Advanced Linux Sound Architecture support (OSS compatibility kernel modules are installed if available)
* api-documentation: Enables the generation of API documentation during recipe builds
* bluetooth: Includes Bluetooth support (integrated BT only)
* cramfs: Includes CramFS support
* debuginfod: Includes support for getting ELF debugging information through a debuginfod server
* ext2: Includes tools to support devices with an internal HDD/Microdrive for storing files (instead of Flash-only devices)
* gobject-introspection-data: Includes data to support GObject introspection
* ipsec: Includes IPSec support
* ipv4: Includes IPv4 support
* ipv6: Includes IPv6 support
* keyboard: Includes keyboard support
* ldconfig: Includes support for ldconfig and ld.so.conf on the target
* ld-is-gold: Uses the gold linker instead of the standard GNU linker (bfd)
* lto: Enables Link-Time Optimization
* multiarch: Enables you to build applications with multiple architecture support
* nfc: Includes support for Near Field Communication
* nfs: Includes NFS client support
* nls: Includes Native Language Support (NLS)
* opengl: Includes the Open Graphics Library, a cross-language, multi-platform API, used to render two- and three-dimensional graphics
* overlayfs: Includes OverlayFS support
* pam: Includes Pluggable Authentication Module (PAM) support
* pci: Includes PCI bus support
* pcmcia: Includes PCMCIA/CompactFlash support
* polkit: Includes Polkit support
* ppp: Includes PPP dial-up support
* ptest: Enables you to build the package tests that were supported by individual recipes
* pulseaudio: Includes support for PulseAudio
* seccomp: Enables you to build applications with seccomp support, allowing the applications to strictly restrict the system calls that they are allowed to invoke
* selinux: Includes support for Security-Enhanced Linux (SELinux) (requires meta-selinux)
* smbfs: Includes SMB network client support
* systemd: Includes support for this init manager, a full replacement for init, with parallel starting of services, reduced shell overhead, and other features
* usbgadget: Includes USB Gadget Device support
* usbhost: Includes USB Host support
* usrmerge: Merges the /bin, /sbin, /lib, and /lib64 directories into their respective counterparts in the /usr directory to provide better package and application compatibility
* vfat: Includes FAT filesystem support
* vulkan: Includes support for the Vulkan API
* wayland: Includes the Wayland display server protocol and the library that supports it
* wifi: Includes Wi-Fi support (integrated only)
* x11: Includes the X server and libraries
* xattr: Includes support for extended file attributes
* zeroconf: Includes support for zero-configuration networking
3, MACHINE_FEATURES versus DISTRO_FEATURES
DISTRO_FEATURES 和 MACHINE_FEATURES 变量共同为最终系统提供可行的支持。当机器支持某个功能时，并不意味着目标系统也支持该功能，因为发行版必须提供其底层基础。
The DISTRO_FEATURES and MACHINE_FEATURES variables work together to provide feasible support for the final system. When a machine supports a feature, this does not imply that the target system supports it because the distribution must provide its underlying base.
例如，如果一台机器支持 Wi-Fi，但发行版不支持，那么操作系统所使用的应用程序在构建时就会禁用 Wi-Fi，从而导致系统不支持 Wi-Fi。另一方面，如果发行版提供 Wi-Fi 支持，而某台机器不支持，那么为该机器构建的镜像中将不会安装 Wi-Fi 所需的模块和应用程序。不过，操作系统及其模块已启用对 Wi-Fi 的支持。
For example, if a machine supports Wi-Fi but the distribution does not, the applications used by the operating system will be built with Wi-Fi support disabled so that the outcome will be a system without Wi-Fi support. On the other hand, if the distribution provides Wi-Fi support and a machine does not, the modules and applications needed for the Wi-Fi will not be installed in images built for this machine. However, the operating system and its modules have support for Wi-Fi enabled.
4, Understanding the scope of a variable
BitBake 元数据有数千个变量，但这些变量的可用范围取决于其定义的位置。变量有以下两种：
The BitBake metadata has thousands of variables, but the scope where these variables are available depends on where it is defined. There are two kinds of variables, as follows:
-
配置文件中定义的变量是每个配方的全局变量，也称为配置元数据。主要配置文件的解析顺序如下：Variables defined in configuration files are global to every recipe, also referred to as configuration metadata. The parsing order of the main configuration files is shown as follows:
* build/conf/local.conf
* <layer>/conf/machines/<machine>.conf
* <layer>/conf/distro/<distro>.conf
-
在配方文件中定义的变量具有配方可见性范围，该范围仅在特定配方执行任务时才会出现。Variables defined within recipe files have recipe visibility scope that is local to the specific recipe only during the execution of its tasks.
5, Summary
在本章中，我们介绍了如何创建新层和元数据。首先，我们了解了如何创建机器配置、发行版定义和配方文件。然后，我们学习了如何制作图像并将应用程序包含在图像中。
In this chapter, we covered how to create a new layer and metadata. First, we saw how to create a machine configuration, a distribution definition, and recipe files. Then, we learned how to make images and include our application in an image.
在下一章中，我们将举例说明附加层最常用的自定义情况，如修改现有软件包、为 autoconf 添加额外选项、应用新补丁以及为软件包添加新文件。我们将了解如何配置 BusyBox 和 linux-yocto，这两个软件包是制作嵌入式系统时常用的定制软件包。
In the next chapter, we will access some examples of the most common customization cases used by an additional layer, such as modifying existing packages, adding extra options to autoconf, applying a new patch, and including a new file to a package. We will see how to configure BusyBox and linux-yocto, the two packages commonly customized when making an embedded system.