diff options
Diffstat (limited to 'documentation/ref-manual/terms.rst')
-rw-r--r-- | documentation/ref-manual/terms.rst | 232 |
1 files changed, 189 insertions, 43 deletions
diff --git a/documentation/ref-manual/terms.rst b/documentation/ref-manual/terms.rst index bf46148876..b18c4183b6 100644 --- a/documentation/ref-manual/terms.rst +++ b/documentation/ref-manual/terms.rst | |||
@@ -4,7 +4,7 @@ | |||
4 | Yocto Project Terms | 4 | Yocto Project Terms |
5 | ******************* | 5 | ******************* |
6 | 6 | ||
7 | Following is a list of terms and definitions users new to the Yocto Project | 7 | Here is a list of terms and definitions users new to the Yocto Project |
8 | development environment might find helpful. While some of these terms are | 8 | development environment might find helpful. While some of these terms are |
9 | universal, the list includes them just in case: | 9 | universal, the list includes them just in case: |
10 | 10 | ||
@@ -21,18 +21,17 @@ universal, the list includes them just in case: | |||
21 | 21 | ||
22 | Information in append files extends or overrides the information in the | 22 | Information in append files extends or overrides the information in the |
23 | similarly-named recipe file. For an example of an append file in use, see | 23 | similarly-named recipe file. For an example of an append file in use, see |
24 | the ":ref:`dev-manual/common-tasks:Using .bbappend Files in | 24 | the ":ref:`dev-manual/layers:appending other layers metadata with your layer`" |
25 | Your Layer`" section in the Yocto Project Development Tasks Manual. | 25 | section in the Yocto Project Development Tasks Manual. |
26 | 26 | ||
27 | When you name an append file, you can use the "``%``" wildcard character | 27 | When you name an append file, you can use the "``%``" wildcard character |
28 | to allow for matching recipe names. For example, suppose you have an | 28 | to allow for matching recipe names. For example, suppose you have an |
29 | append file named as follows: | 29 | append file named as follows:: |
30 | :: | 30 | |
31 | |||
32 | busybox_1.21.%.bbappend | 31 | busybox_1.21.%.bbappend |
33 | 32 | ||
34 | That append file | 33 | That append file |
35 | would match any ``busybox_1.21.``\ x\ ``.bb`` version of the recipe. So, | 34 | would match any ``busybox_1.21.x.bb`` version of the recipe. So, |
36 | the append file would match any of the following recipe names: | 35 | the append file would match any of the following recipe names: |
37 | 36 | ||
38 | .. code-block:: shell | 37 | .. code-block:: shell |
@@ -65,54 +64,73 @@ universal, the list includes them just in case: | |||
65 | builds. The area is created when you ``source`` the setup environment | 64 | builds. The area is created when you ``source`` the setup environment |
66 | script that is found in the Source Directory | 65 | script that is found in the Source Directory |
67 | (i.e. :ref:`ref-manual/structure:\`\`oe-init-build-env\`\``). The | 66 | (i.e. :ref:`ref-manual/structure:\`\`oe-init-build-env\`\``). The |
68 | :term:`TOPDIR` variable points to the Build Directory. | 67 | :term:`TOPDIR` variable points to the :term:`Build Directory`. |
69 | 68 | ||
70 | You have a lot of flexibility when creating the Build Directory. | 69 | You have a lot of flexibility when creating the :term:`Build Directory`. |
71 | Following are some examples that show how to create the directory. The | 70 | Here are some examples that show how to create the directory. The |
72 | examples assume your :term:`Source Directory` is named ``poky``: | 71 | examples assume your :term:`Source Directory` is named ``poky``: |
73 | 72 | ||
74 | - Create the Build Directory inside your Source Directory and let | 73 | - Create the :term:`Build Directory` inside your Source Directory and let |
75 | the name of the Build Directory default to ``build``: | 74 | the name of the :term:`Build Directory` default to ``build``: |
76 | 75 | ||
77 | .. code-block:: shell | 76 | .. code-block:: shell |
78 | 77 | ||
79 | $ cd $HOME/poky | 78 | $ cd poky |
80 | $ source oe-init-build-env | 79 | $ source oe-init-build-env |
81 | 80 | ||
82 | - Create the Build Directory inside your home directory and | 81 | - Create the :term:`Build Directory` inside your home directory and |
83 | specifically name it ``test-builds``: | 82 | specifically name it ``test-builds``: |
84 | 83 | ||
85 | .. code-block:: shell | 84 | .. code-block:: shell |
86 | 85 | ||
87 | $ cd $HOME | ||
88 | $ source poky/oe-init-build-env test-builds | 86 | $ source poky/oe-init-build-env test-builds |
89 | 87 | ||
90 | - Provide a directory path and specifically name the Build | 88 | - Provide a directory path and specifically name the |
91 | Directory. Any intermediate folders in the pathname must exist. | 89 | :term:`Build Directory`. Any intermediate folders in the pathname |
92 | This next example creates a Build Directory named | 90 | must exist. This next example creates a :term:`Build Directory` |
93 | ``YP-&POKYVERSION;`` in your home directory within the existing | 91 | named ``YP-&DISTRO;`` within the existing directory ``mybuilds``: |
94 | directory ``mybuilds``: | ||
95 | 92 | ||
96 | .. code-block:: shell | 93 | .. code-block:: shell |
97 | 94 | ||
98 | $ cd $HOME | 95 | $ source poky/oe-init-build-env mybuilds/YP-&DISTRO; |
99 | $ source $HOME/poky/oe-init-build-env $HOME/mybuilds/YP-&POKYVERSION; | ||
100 | 96 | ||
101 | .. note:: | 97 | .. note:: |
102 | 98 | ||
103 | By default, the Build Directory contains :term:`TMPDIR`, which is a | 99 | By default, the :term:`Build Directory` contains :term:`TMPDIR`, which is a |
104 | temporary directory the build system uses for its work. ``TMPDIR`` cannot | 100 | temporary directory the build system uses for its work. :term:`TMPDIR` cannot |
105 | be under NFS. Thus, by default, the Build Directory cannot be under | 101 | be under NFS. Thus, by default, the :term:`Build Directory` cannot be under |
106 | NFS. However, if you need the Build Directory to be under NFS, you can | 102 | NFS. However, if you need the :term:`Build Directory` to be under NFS, you can |
107 | set this up by setting ``TMPDIR`` in your ``local.conf`` file to use a local | 103 | set this up by setting :term:`TMPDIR` in your ``local.conf`` file to use a local |
108 | drive. Doing so effectively separates ``TMPDIR`` from :term:`TOPDIR`, which is the | 104 | drive. Doing so effectively separates :term:`TMPDIR` from :term:`TOPDIR`, which is the |
109 | Build Directory. | 105 | :term:`Build Directory`. |
110 | 106 | ||
111 | :term:`Build Host` | 107 | :term:`Build Host` |
112 | The system used to build images in a Yocto Project Development | 108 | The system used to build images in a Yocto Project Development |
113 | environment. The build system is sometimes referred to as the development | 109 | environment. The build system is sometimes referred to as the development |
114 | host. | 110 | host. |
115 | 111 | ||
112 | :term:`buildtools` | ||
113 | Build tools in binary form, providing required versions of development | ||
114 | tools (such as Git, GCC, Python and make), to run the OpenEmbedded build | ||
115 | system on a development host without such minimum versions. | ||
116 | |||
117 | See the ":ref:`system-requirements-buildtools`" paragraph in the | ||
118 | Reference Manual for details about downloading or building an archive | ||
119 | of such tools. | ||
120 | |||
121 | :term:`buildtools-extended` | ||
122 | A set of :term:`buildtools` binaries extended with additional development | ||
123 | tools, such as a required version of the GCC compiler to run the | ||
124 | OpenEmbedded build system. | ||
125 | |||
126 | See the ":ref:`system-requirements-buildtools`" paragraph in the | ||
127 | Reference Manual for details about downloading or building an archive | ||
128 | of such tools. | ||
129 | |||
130 | :term:`buildtools-make` | ||
131 | A variant of :term:`buildtools`, just providing the required | ||
132 | version of ``make`` to run the OpenEmbedded build system. | ||
133 | |||
116 | :term:`Classes` | 134 | :term:`Classes` |
117 | Files that provide for logic encapsulation and inheritance so that | 135 | Files that provide for logic encapsulation and inheritance so that |
118 | commonly used patterns can be defined once and then easily used in | 136 | commonly used patterns can be defined once and then easily used in |
@@ -138,10 +156,25 @@ universal, the list includes them just in case: | |||
138 | the Texas Instruments ARM Cortex-A8 development board). | 156 | the Texas Instruments ARM Cortex-A8 development board). |
139 | 157 | ||
140 | :term:`Container Layer` | 158 | :term:`Container Layer` |
141 | Layers that hold other layers. An example of a container layer is | 159 | A flexible definition that typically refers to a single Git checkout |
142 | OpenEmbedded's `meta-openembedded | 160 | which contains multiple (and typically related) sub-layers which can |
143 | <https://github.com/openembedded/meta-openembedded>`_ layer. The | 161 | be included independently in your project's ``bblayers.conf`` file. |
144 | ``meta-openembedded`` layer contains many ``meta-*`` layers. | 162 | |
163 | In some cases, such as with OpenEmbedded's :oe_git:`meta-openembedded </meta-openembedded>` | ||
164 | layer, the top level ``meta-openembedded/`` directory is not itself an actual layer, | ||
165 | so you would never explicitly include it in a ``bblayers.conf`` file; | ||
166 | rather, you would include any number of its layer subdirectories, such as | ||
167 | :oe_git:`meta-oe </meta-openembedded/tree/meta-oe>`, :oe_git:`meta-python | ||
168 | </meta-openembedded/tree/meta-python>` and so on. | ||
169 | |||
170 | On the other hand, some container layers (such as | ||
171 | :yocto_git:`meta-security </meta-security>`) | ||
172 | have a top-level directory that is itself an actual layer, as well as | ||
173 | a variety of sub-layers, both of which could be included in your | ||
174 | ``bblayers.conf`` file. | ||
175 | |||
176 | In either case, the phrase "container layer" is simply used to describe | ||
177 | a directory structure which contains multiple valid OpenEmbedded layers. | ||
145 | 178 | ||
146 | :term:`Cross-Development Toolchain` | 179 | :term:`Cross-Development Toolchain` |
147 | In general, a cross-development toolchain is a collection of software | 180 | In general, a cross-development toolchain is a collection of software |
@@ -179,6 +212,48 @@ universal, the list includes them just in case: | |||
179 | of the supported image types that the Yocto Project provides, see the | 212 | of the supported image types that the Yocto Project provides, see the |
180 | ":ref:`ref-manual/images:Images`" chapter. | 213 | ":ref:`ref-manual/images:Images`" chapter. |
181 | 214 | ||
215 | :term:`Initramfs` | ||
216 | An Initial RAM Filesystem (:term:`Initramfs`) is an optionally compressed | ||
217 | :wikipedia:`cpio <Cpio>` archive which is extracted | ||
218 | by the Linux kernel into RAM in a special :wikipedia:`tmpfs <Tmpfs>` | ||
219 | instance, used as the initial root filesystem. | ||
220 | |||
221 | This is a replacement for the legacy init RAM disk ("initrd") | ||
222 | technique, booting on an emulated block device in RAM, but being less | ||
223 | efficient because of the overhead of going through a filesystem and | ||
224 | having to duplicate accessed file contents in the file cache in RAM, | ||
225 | as for any block device. | ||
226 | |||
227 | .. note:: | ||
228 | |||
229 | As far as bootloaders are concerned, :term:`Initramfs` and "initrd" | ||
230 | images are still copied to RAM in the same way. That's why most | ||
231 | most bootloaders refer to :term:`Initramfs` images as "initrd" | ||
232 | or "init RAM disk". | ||
233 | |||
234 | This kind of mechanism is typically used for two reasons: | ||
235 | |||
236 | - For booting the same kernel binary on multiple systems requiring | ||
237 | different device drivers. The :term:`Initramfs` image is then customized | ||
238 | for each type of system, to include the specific kernel modules | ||
239 | necessary to access the final root filesystem. This technique | ||
240 | is used on all GNU / Linux distributions for desktops and servers. | ||
241 | |||
242 | - For booting faster. As the root filesystem is extracted into RAM, | ||
243 | accessing the first user-space applications is very fast, compared | ||
244 | to having to initialize a block device, to access multiple blocks | ||
245 | from it, and to go through a filesystem having its own overhead. | ||
246 | For example, this allows to display a splashscreen very early, | ||
247 | and to later take care of mounting the final root filesystem and | ||
248 | loading less time-critical kernel drivers. | ||
249 | |||
250 | This cpio archive can either be loaded to RAM by the bootloader, | ||
251 | or be included in the kernel binary. | ||
252 | |||
253 | For information on creating and using an :term:`Initramfs`, see the | ||
254 | ":ref:`dev-manual/building:building an initial ram filesystem (Initramfs) image`" | ||
255 | section in the Yocto Project Development Tasks Manual. | ||
256 | |||
182 | :term:`Layer` | 257 | :term:`Layer` |
183 | A collection of related recipes. Layers allow you to consolidate related | 258 | A collection of related recipes. Layers allow you to consolidate related |
184 | metadata to customize your build. Layers also isolate information used | 259 | metadata to customize your build. Layers also isolate information used |
@@ -192,12 +267,18 @@ universal, the list includes them just in case: | |||
192 | ":ref:`overview-manual/yp-intro:The Yocto Project Layer | 267 | ":ref:`overview-manual/yp-intro:The Yocto Project Layer |
193 | Model`" section in the Yocto Project Overview and Concepts Manual. For | 268 | Model`" section in the Yocto Project Overview and Concepts Manual. For |
194 | more detailed information on layers, see the | 269 | more detailed information on layers, see the |
195 | ":ref:`dev-manual/common-tasks:Understanding and Creating | 270 | ":ref:`dev-manual/layers:Understanding and Creating |
196 | Layers`" section in the Yocto Project Development Tasks Manual. For a | 271 | Layers`" section in the Yocto Project Development Tasks Manual. For a |
197 | discussion specifically on BSP Layers, see the ":ref:`bsp-guide/bsp:BSP | 272 | discussion specifically on BSP Layers, see the ":ref:`bsp-guide/bsp:BSP |
198 | Layers`" section in the Yocto Project Board Support Packages (BSP) | 273 | Layers`" section in the Yocto Project Board Support Packages (BSP) |
199 | Developer's Guide. | 274 | Developer's Guide. |
200 | 275 | ||
276 | :term:`LTS` | ||
277 | This term means "Long Term Support", and in the context of the Yocto | ||
278 | Project, it corresponds to selected stable releases for which bug and | ||
279 | security fixes are provided for at least four years. See | ||
280 | the :ref:`ref-long-term-support-releases` section for details. | ||
281 | |||
201 | :term:`Metadata` | 282 | :term:`Metadata` |
202 | A key element of the Yocto Project is the Metadata that | 283 | A key element of the Yocto Project is the Metadata that |
203 | is used to construct a Linux distribution and is contained in the | 284 | is used to construct a Linux distribution and is contained in the |
@@ -217,6 +298,12 @@ universal, the list includes them just in case: | |||
217 | :yocto_git:`yocto-kernel-cache </yocto-kernel-cache>` | 298 | :yocto_git:`yocto-kernel-cache </yocto-kernel-cache>` |
218 | Git repository. | 299 | Git repository. |
219 | 300 | ||
301 | :term:`Mixin` | ||
302 | A :term:`Mixin` layer is a layer which can be created by the community to | ||
303 | add a specific feature or support a new version of some package for an | ||
304 | :term:`LTS` release. See the :ref:`ref-long-term-support-releases` | ||
305 | section for details. | ||
306 | |||
220 | :term:`OpenEmbedded-Core (OE-Core)` | 307 | :term:`OpenEmbedded-Core (OE-Core)` |
221 | OE-Core is metadata comprised of | 308 | OE-Core is metadata comprised of |
222 | foundational recipes, classes, and associated files that are meant to | 309 | foundational recipes, classes, and associated files that are meant to |
@@ -257,7 +344,7 @@ universal, the list includes them just in case: | |||
257 | your Linux distribution. | 344 | your Linux distribution. |
258 | 345 | ||
259 | Another point worth noting is that historically within the Yocto | 346 | Another point worth noting is that historically within the Yocto |
260 | Project, recipes were referred to as packages - thus, the existence | 347 | Project, recipes were referred to as packages --- thus, the existence |
261 | of several BitBake variables that are seemingly mis-named, (e.g. | 348 | of several BitBake variables that are seemingly mis-named, (e.g. |
262 | :term:`PR`, :term:`PV`, and | 349 | :term:`PR`, :term:`PV`, and |
263 | :term:`PE`). | 350 | :term:`PE`). |
@@ -310,6 +397,23 @@ universal, the list includes them just in case: | |||
310 | :term:`build host<Build Host>` and other components, that can | 397 | :term:`build host<Build Host>` and other components, that can |
311 | work on specific hardware. | 398 | work on specific hardware. |
312 | 399 | ||
400 | :term:`SBOM` | ||
401 | This term means *Software Bill of Materials*. When you distribute | ||
402 | software, it offers a description of all the components you used, | ||
403 | their corresponding licenses, their dependencies, the changes that were | ||
404 | applied and the known vulnerabilities that were fixed. | ||
405 | |||
406 | This can be used by the recipients of the software to assess | ||
407 | their exposure to license compliance and security vulnerability issues. | ||
408 | |||
409 | See the :wikipedia:`Software Supply Chain <Software_supply_chain>` | ||
410 | article on Wikipedia for more details. | ||
411 | |||
412 | The OpenEmbedded Build System can generate such documentation for your | ||
413 | project, in :term:`SPDX` format, based on all the metadata it used to | ||
414 | build the software images. See the ":ref:`dev-manual/sbom:creating | ||
415 | a software bill of materials`" section of the Development Tasks manual. | ||
416 | |||
313 | :term:`Source Directory` | 417 | :term:`Source Directory` |
314 | This term refers to the directory structure | 418 | This term refers to the directory structure |
315 | created as a result of creating a local copy of the ``poky`` Git | 419 | created as a result of creating a local copy of the ``poky`` Git |
@@ -344,19 +448,19 @@ universal, the list includes them just in case: | |||
344 | repository results in a local Git repository whose top-level folder | 448 | repository results in a local Git repository whose top-level folder |
345 | is also named "poky". | 449 | is also named "poky". |
346 | 450 | ||
347 | While it is not recommended that you use tarball expansion to set up | 451 | While it is not recommended that you use tarball extraction to set up |
348 | the Source Directory, if you do, the top-level directory name of the | 452 | the Source Directory, if you do, the top-level directory name of the |
349 | Source Directory is derived from the Yocto Project release tarball. | 453 | Source Directory is derived from the Yocto Project release tarball. |
350 | For example, downloading and unpacking | 454 | For example, downloading and unpacking poky tarballs from |
351 | :yocto_dl:`/releases/yocto/&DISTRO_REL_TAG;/&YOCTO_POKY;.tar.bz2` | 455 | :yocto_dl:`/releases/yocto/&DISTRO_REL_TAG;/` |
352 | results in a Source Directory whose root folder is named | 456 | results in a Source Directory whose root folder is named poky. |
353 | ``&YOCTO_POKY;``. | 457 | |
354 | 458 | ||
355 | It is important to understand the differences between the Source | 459 | It is important to understand the differences between the Source |
356 | Directory created by unpacking a released tarball as compared to | 460 | Directory created by unpacking a released tarball as compared to |
357 | cloning ``git://git.yoctoproject.org/poky``. When you unpack a | 461 | cloning ``git://git.yoctoproject.org/poky``. When you unpack a |
358 | tarball, you have an exact copy of the files based on the time of | 462 | tarball, you have an exact copy of the files based on the time of |
359 | release - a fixed release point. Any changes you make to your local | 463 | release --- a fixed release point. Any changes you make to your local |
360 | files in the Source Directory are on top of the release and will | 464 | files in the Source Directory are on top of the release and will |
361 | remain local only. On the other hand, when you clone the ``poky`` Git | 465 | remain local only. On the other hand, when you clone the ``poky`` Git |
362 | repository, you have an active development repository with access to | 466 | repository, you have an active development repository with access to |
@@ -370,11 +474,53 @@ universal, the list includes them just in case: | |||
370 | ":ref:`overview-manual/development-environment:repositories, tags, and branches`" | 474 | ":ref:`overview-manual/development-environment:repositories, tags, and branches`" |
371 | section in the Yocto Project Overview and Concepts Manual. | 475 | section in the Yocto Project Overview and Concepts Manual. |
372 | 476 | ||
477 | :term:`SPDX` | ||
478 | This term means *Software Package Data Exchange*, and is used as an open | ||
479 | standard for providing a *Software Bill of Materials* (:term:`SBOM`). | ||
480 | This standard is developed through a `Linux Foundation project | ||
481 | <https://spdx.dev/>`__ and is used by the OpenEmbedded Build System to | ||
482 | provide an :term:`SBOM` associated to each software image. | ||
483 | |||
484 | For details, see Wikipedia's :wikipedia:`SPDX page <Software_Package_Data_Exchange>` | ||
485 | and the ":ref:`dev-manual/sbom:creating a software bill of materials`" | ||
486 | section of the Development Tasks manual. | ||
487 | |||
488 | :term:`Sysroot` | ||
489 | When cross-compiling, the target file system may be differently laid | ||
490 | out and contain different things compared to the host system. The concept | ||
491 | of a *sysroot* is directory which looks like the target filesystem and | ||
492 | can be used to cross-compile against. | ||
493 | |||
494 | In the context of cross-compiling toolchains, a *sysroot* | ||
495 | typically contains C library and kernel headers, plus the | ||
496 | compiled binaries for the C library. A *multilib toolchain* | ||
497 | can contain multiple variants of the C library binaries, | ||
498 | each compiled for a target instruction set (such as ``armv5``, | ||
499 | ``armv7`` and ``armv8``), and possibly optimized for a specific CPU core. | ||
500 | |||
501 | In the more specific context of the OpenEmbedded build System and | ||
502 | of the Yocto Project, each recipe has two sysroots: | ||
503 | |||
504 | - A *target sysroot* contains all the **target** libraries and headers | ||
505 | needed to build the recipe. | ||
506 | |||
507 | - A *native sysroot* contains all the **host** files and executables | ||
508 | needed to build the recipe. | ||
509 | |||
510 | See the :term:`SYSROOT_* <SYSROOT_DESTDIR>` variables controlling | ||
511 | how sysroots are created and stored. | ||
512 | |||
373 | :term:`Task` | 513 | :term:`Task` |
374 | A unit of execution for BitBake (e.g. | 514 | A per-recipe unit of execution for BitBake (e.g. |
375 | :ref:`ref-tasks-compile`, | 515 | :ref:`ref-tasks-compile`, |
376 | :ref:`ref-tasks-fetch`, | 516 | :ref:`ref-tasks-fetch`, |
377 | :ref:`ref-tasks-patch`, and so forth). | 517 | :ref:`ref-tasks-patch`, and so forth). |
518 | One of the major benefits of the build system is that, since each | ||
519 | recipe will typically spawn the execution of numerous tasks, | ||
520 | it is entirely possible that many tasks can execute in parallel, | ||
521 | either tasks from separate recipes or independent tasks within | ||
522 | the same recipe, potentially up to the parallelism of your | ||
523 | build system. | ||
378 | 524 | ||
379 | :term:`Toaster` | 525 | :term:`Toaster` |
380 | A web interface to the Yocto Project's :term:`OpenEmbedded Build System`. | 526 | A web interface to the Yocto Project's :term:`OpenEmbedded Build System`. |
@@ -385,7 +531,7 @@ universal, the list includes them just in case: | |||
385 | 531 | ||
386 | :term:`Upstream` | 532 | :term:`Upstream` |
387 | A reference to source code or repositories that are not | 533 | A reference to source code or repositories that are not |
388 | local to the development system but located in a master area that is | 534 | local to the development system but located in a remote area that is |
389 | controlled by the maintainer of the source code. For example, in | 535 | controlled by the maintainer of the source code. For example, in |
390 | order for a developer to work on a particular piece of code, they | 536 | order for a developer to work on a particular piece of code, they |
391 | need to first get a copy of it from an "upstream" source. | 537 | need to first get a copy of it from an "upstream" source. |