diff options
Diffstat (limited to 'documentation/ref-manual/terms.rst')
| -rw-r--r-- | documentation/ref-manual/terms.rst | 146 |
1 files changed, 124 insertions, 22 deletions
diff --git a/documentation/ref-manual/terms.rst b/documentation/ref-manual/terms.rst index 1e3f718a8f..b18c4183b6 100644 --- a/documentation/ref-manual/terms.rst +++ b/documentation/ref-manual/terms.rst @@ -4,7 +4,7 @@ Yocto Project Terms ******************* -Following is a list of terms and definitions users new to the Yocto Project +Here is a list of terms and definitions users new to the Yocto Project development environment might find helpful. While some of these terms are universal, the list includes them just in case: @@ -21,7 +21,7 @@ universal, the list includes them just in case: Information in append files extends or overrides the information in the similarly-named recipe file. For an example of an append file in use, see - the ":ref:`dev-manual/common-tasks:appending other layers metadata with your layer`" + the ":ref:`dev-manual/layers:appending other layers metadata with your layer`" section in the Yocto Project Development Tasks Manual. When you name an append file, you can use the "``%``" wildcard character @@ -64,31 +64,31 @@ universal, the list includes them just in case: builds. The area is created when you ``source`` the setup environment script that is found in the Source Directory (i.e. :ref:`ref-manual/structure:\`\`oe-init-build-env\`\``). The - :term:`TOPDIR` variable points to the Build Directory. + :term:`TOPDIR` variable points to the :term:`Build Directory`. - You have a lot of flexibility when creating the Build Directory. - Following are some examples that show how to create the directory. The + You have a lot of flexibility when creating the :term:`Build Directory`. + Here are some examples that show how to create the directory. The examples assume your :term:`Source Directory` is named ``poky``: - - Create the Build Directory inside your Source Directory and let - the name of the Build Directory default to ``build``: + - Create the :term:`Build Directory` inside your Source Directory and let + the name of the :term:`Build Directory` default to ``build``: .. code-block:: shell $ cd poky $ source oe-init-build-env - - Create the Build Directory inside your home directory and + - Create the :term:`Build Directory` inside your home directory and specifically name it ``test-builds``: .. code-block:: shell $ source poky/oe-init-build-env test-builds - - Provide a directory path and specifically name the Build - Directory. Any intermediate folders in the pathname must exist. - This next example creates a Build Directory named - ``YP-&DISTRO;`` within the existing directory ``mybuilds``: + - Provide a directory path and specifically name the + :term:`Build Directory`. Any intermediate folders in the pathname + must exist. This next example creates a :term:`Build Directory` + named ``YP-&DISTRO;`` within the existing directory ``mybuilds``: .. code-block:: shell @@ -96,19 +96,41 @@ universal, the list includes them just in case: .. note:: - By default, the Build Directory contains :term:`TMPDIR`, which is a + By default, the :term:`Build Directory` contains :term:`TMPDIR`, which is a temporary directory the build system uses for its work. :term:`TMPDIR` cannot - be under NFS. Thus, by default, the Build Directory cannot be under - NFS. However, if you need the Build Directory to be under NFS, you can + be under NFS. Thus, by default, the :term:`Build Directory` cannot be under + NFS. However, if you need the :term:`Build Directory` to be under NFS, you can set this up by setting :term:`TMPDIR` in your ``local.conf`` file to use a local drive. Doing so effectively separates :term:`TMPDIR` from :term:`TOPDIR`, which is the - Build Directory. + :term:`Build Directory`. :term:`Build Host` The system used to build images in a Yocto Project Development environment. The build system is sometimes referred to as the development host. + :term:`buildtools` + Build tools in binary form, providing required versions of development + tools (such as Git, GCC, Python and make), to run the OpenEmbedded build + system on a development host without such minimum versions. + + See the ":ref:`system-requirements-buildtools`" paragraph in the + Reference Manual for details about downloading or building an archive + of such tools. + + :term:`buildtools-extended` + A set of :term:`buildtools` binaries extended with additional development + tools, such as a required version of the GCC compiler to run the + OpenEmbedded build system. + + See the ":ref:`system-requirements-buildtools`" paragraph in the + Reference Manual for details about downloading or building an archive + of such tools. + + :term:`buildtools-make` + A variant of :term:`buildtools`, just providing the required + version of ``make`` to run the OpenEmbedded build system. + :term:`Classes` Files that provide for logic encapsulation and inheritance so that commonly used patterns can be defined once and then easily used in @@ -138,14 +160,12 @@ universal, the list includes them just in case: which contains multiple (and typically related) sub-layers which can be included independently in your project's ``bblayers.conf`` file. - In some cases, such as with OpenEmbedded's - `meta-openembedded <https://github.com/openembedded/meta-openembedded>`_ + In some cases, such as with OpenEmbedded's :oe_git:`meta-openembedded </meta-openembedded>` layer, the top level ``meta-openembedded/`` directory is not itself an actual layer, so you would never explicitly include it in a ``bblayers.conf`` file; rather, you would include any number of its layer subdirectories, such as - `meta-openembedded/meta-oe <https://github.com/openembedded/meta-openembedded/tree/master/meta-oe>`_, - `meta-openembedded/meta-python <https://github.com/openembedded/meta-openembedded/tree/master/meta-python>`_ - and so on. + :oe_git:`meta-oe </meta-openembedded/tree/meta-oe>`, :oe_git:`meta-python + </meta-openembedded/tree/meta-python>` and so on. On the other hand, some container layers (such as :yocto_git:`meta-security </meta-security>`) @@ -192,6 +212,48 @@ universal, the list includes them just in case: of the supported image types that the Yocto Project provides, see the ":ref:`ref-manual/images:Images`" chapter. + :term:`Initramfs` + An Initial RAM Filesystem (:term:`Initramfs`) is an optionally compressed + :wikipedia:`cpio <Cpio>` archive which is extracted + by the Linux kernel into RAM in a special :wikipedia:`tmpfs <Tmpfs>` + instance, used as the initial root filesystem. + + This is a replacement for the legacy init RAM disk ("initrd") + technique, booting on an emulated block device in RAM, but being less + efficient because of the overhead of going through a filesystem and + having to duplicate accessed file contents in the file cache in RAM, + as for any block device. + + .. note:: + + As far as bootloaders are concerned, :term:`Initramfs` and "initrd" + images are still copied to RAM in the same way. That's why most + most bootloaders refer to :term:`Initramfs` images as "initrd" + or "init RAM disk". + + This kind of mechanism is typically used for two reasons: + + - For booting the same kernel binary on multiple systems requiring + different device drivers. The :term:`Initramfs` image is then customized + for each type of system, to include the specific kernel modules + necessary to access the final root filesystem. This technique + is used on all GNU / Linux distributions for desktops and servers. + + - For booting faster. As the root filesystem is extracted into RAM, + accessing the first user-space applications is very fast, compared + to having to initialize a block device, to access multiple blocks + from it, and to go through a filesystem having its own overhead. + For example, this allows to display a splashscreen very early, + and to later take care of mounting the final root filesystem and + loading less time-critical kernel drivers. + + This cpio archive can either be loaded to RAM by the bootloader, + or be included in the kernel binary. + + For information on creating and using an :term:`Initramfs`, see the + ":ref:`dev-manual/building:building an initial ram filesystem (Initramfs) image`" + section in the Yocto Project Development Tasks Manual. + :term:`Layer` A collection of related recipes. Layers allow you to consolidate related metadata to customize your build. Layers also isolate information used @@ -205,12 +267,18 @@ universal, the list includes them just in case: ":ref:`overview-manual/yp-intro:The Yocto Project Layer Model`" section in the Yocto Project Overview and Concepts Manual. For more detailed information on layers, see the - ":ref:`dev-manual/common-tasks:Understanding and Creating + ":ref:`dev-manual/layers:Understanding and Creating Layers`" section in the Yocto Project Development Tasks Manual. For a discussion specifically on BSP Layers, see the ":ref:`bsp-guide/bsp:BSP Layers`" section in the Yocto Project Board Support Packages (BSP) Developer's Guide. + :term:`LTS` + This term means "Long Term Support", and in the context of the Yocto + Project, it corresponds to selected stable releases for which bug and + security fixes are provided for at least four years. See + the :ref:`ref-long-term-support-releases` section for details. + :term:`Metadata` A key element of the Yocto Project is the Metadata that is used to construct a Linux distribution and is contained in the @@ -230,6 +298,12 @@ universal, the list includes them just in case: :yocto_git:`yocto-kernel-cache </yocto-kernel-cache>` Git repository. + :term:`Mixin` + A :term:`Mixin` layer is a layer which can be created by the community to + add a specific feature or support a new version of some package for an + :term:`LTS` release. See the :ref:`ref-long-term-support-releases` + section for details. + :term:`OpenEmbedded-Core (OE-Core)` OE-Core is metadata comprised of foundational recipes, classes, and associated files that are meant to @@ -323,6 +397,23 @@ universal, the list includes them just in case: :term:`build host<Build Host>` and other components, that can work on specific hardware. + :term:`SBOM` + This term means *Software Bill of Materials*. When you distribute + software, it offers a description of all the components you used, + their corresponding licenses, their dependencies, the changes that were + applied and the known vulnerabilities that were fixed. + + This can be used by the recipients of the software to assess + their exposure to license compliance and security vulnerability issues. + + See the :wikipedia:`Software Supply Chain <Software_supply_chain>` + article on Wikipedia for more details. + + The OpenEmbedded Build System can generate such documentation for your + project, in :term:`SPDX` format, based on all the metadata it used to + build the software images. See the ":ref:`dev-manual/sbom:creating + a software bill of materials`" section of the Development Tasks manual. + :term:`Source Directory` This term refers to the directory structure created as a result of creating a local copy of the ``poky`` Git @@ -383,6 +474,17 @@ universal, the list includes them just in case: ":ref:`overview-manual/development-environment:repositories, tags, and branches`" section in the Yocto Project Overview and Concepts Manual. + :term:`SPDX` + This term means *Software Package Data Exchange*, and is used as an open + standard for providing a *Software Bill of Materials* (:term:`SBOM`). + This standard is developed through a `Linux Foundation project + <https://spdx.dev/>`__ and is used by the OpenEmbedded Build System to + provide an :term:`SBOM` associated to each software image. + + For details, see Wikipedia's :wikipedia:`SPDX page <Software_Package_Data_Exchange>` + and the ":ref:`dev-manual/sbom:creating a software bill of materials`" + section of the Development Tasks manual. + :term:`Sysroot` When cross-compiling, the target file system may be differently laid out and contain different things compared to the host system. The concept |