documentation/kernel-dev/concepts-appx.rst

1 .. SPDX-License-Identifier: CC-BY-SA-2.0-UK
11 other kernels, are based off the Linux kernel releases from
13 development cycle, the Yocto Project team chooses a Linux kernel based
24 up-to-date Yocto Linux kernel possible, while still ensuring that the
31 mix of important new mainline developments, non-mainline developments
38 :ref:`overview-manual/development-environment:yocto project source repositories`
44 -  *linux-yocto-4.1:* The stable Yocto Project kernel to use with
45    the Yocto Project Release 2.0. This kernel is based on the Linux 4.1
48 -  *linux-yocto-4.4:* The stable Yocto Project kernel to use with
49    the Yocto Project Release 2.1. This kernel is based on the Linux 4.4
52 -  *linux-yocto-4.6:* A temporary kernel that is not tied to any
55 -  *linux-yocto-4.8:* The stable yocto Project kernel to use with
58 -  *linux-yocto-4.9:* The stable Yocto Project kernel to use with
59    the Yocto Project Release 2.3. This kernel is based on the Linux 4.9
62 -  *linux-yocto-4.10:* The default stable Yocto Project kernel to
63    use with the Yocto Project Release 2.3. This kernel is based on the
66 -  *linux-yocto-4.12:* The default stable Yocto Project kernel to
67    use with the Yocto Project Release 2.4. This kernel is based on the
70 -  *yocto-kernel-cache:* The ``linux-yocto-cache`` contains patches
71    and configurations for the linux-yocto kernel tree. This repository
72    is useful when working on the linux-yocto kernel. For more
74    ":doc:`/kernel-dev/advanced`" Chapter.
76 -  *linux-yocto-dev:* A development kernel based on the latest
84    -  For Yocto Project releases 1.7, 1.8, and 2.0, the LTSI kernel is
85       ``linux-yocto-3.14``.
87    -  For Yocto Project releases 2.1, 2.2, and 2.3, the LTSI kernel is
88       ``linux-yocto-4.1``.
90    -  For Yocto Project release 2.4, the LTSI kernel is
91       ``linux-yocto-4.9``
93    -  ``linux-yocto-4.4`` is an LTS kernel.
100 Back-porting hundreds of individual fixes and minor features from
109 interest. The team does consider back-porting large features if they
111 a back-port or creation of new functionality in the Yocto Project
118 team's policy to not back-port minor features to the released Yocto
119 Linux kernel. They only consider back-porting significant technological
120 jumps - and, that is done after a complete gap analysis. The reason
121 for this policy is that back-porting any small to medium sized change
131 with a mix of important new mainline, non-mainline, BSP developments and
155    -  Git is the obvious SCM for meeting the Yocto Linux kernel
159       different work flows, front-ends and management techniques.
161    -  You can find documentation on Git at https://git-scm.com/doc. You can
163       ":ref:`overview-manual/development-environment:git`" section in the Yocto Project
173 shared and thus, needs to be isolated. For example, board-specific
178 This "tree-like" architecture results in a structure that has features
198 BSP-specific code additions are handled in a similar manner to
199 kernel-specific additions. Some BSPs only make sense given certain
212 BSP-specific commits. In other words, the divisions of the kernel are
213 transparent and are not relevant to the developer on a day-to-day basis.
219 the line-by-line code ``diff`` level is now a trivial operation.
223 .. image:: figures/kernel-architecture-overview.png
239 well as real-time kernels. The illustration represents this through
240 three BSP-specific branches and a real-time kernel branch. Each branch
241 represents some unique functionality for the BSP or for a real-time
244 In this example structure, the "Real-time (rt) Kernel" branch has common
245 features for all real-time Yocto Linux kernels and contains more
246 branches for individual BSP-specific real-time kernels. The illustration
248 specific, unique features for a respective real-time kernel as they
261    :ref:`overview-manual/development-environment:yocto project source repositories`
286 as all the source files necessary for all the supported Yocto Linux
287 kernels. As a developer, you are just interested in the source files for
294 -  *Files Accessed While using devtool:* ``devtool``, which is
296    modify the kernel. See the ":ref:`kernel-dev/intro:kernel modification workflow`" section.
298 -  *Cloned Repository:* If you are working in the kernel all the time,
302    ":ref:`kernel-dev/common:preparing the build host to work on the kernel`"
305 -  *Temporary Source Files from a Build:* If you just need to make some
307    using the ``devtool``), you can access temporary kernel source files
310 The temporary kernel source files resulting from a build using BitBake
312 development system, all files needed for the build are taken from the
323 source files used during the build.
325 .. image:: figures/kernel-overview-2-generic.png
330 ":ref:`kernel-dev/concepts-appx:yocto linux kernel architecture and branching strategies`"
332 ":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
334 ":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
337 Determining Hardware and Non-Hardware Features for the Kernel Configuration Audit Phase
342 configuration including ``menuconfig``, ``defconfig`` files, and
344 ":ref:`kernel-dev/common:configuring the kernel`" section.
349 user-specified configuration elements. Regardless of their origin, the
359 "non-hardware", the kernel Metadata in ``yocto-kernel-cache`` contains
360 files that classify individual or groups of options as either hardware
361 or non-hardware. To better show this, consider a situation where the
362 ``yocto-kernel-cache`` contains the following files::
364    yocto-kernel-cache/features/drm-psb/hardware.cfg
365    yocto-kernel-cache/features/kgdb/hardware.cfg
366    yocto-kernel-cache/ktypes/base/hardware.cfg
367    yocto-kernel-cache/bsp/mti-malta32/hardware.cfg
368    yocto-kernel-cache/bsp/qemu-ppc32/hardware.cfg
369    yocto-kernel-cache/bsp/qemuarma9/hardware.cfg
370    yocto-kernel-cache/bsp/mti-malta64/hardware.cfg
371    yocto-kernel-cache/bsp/arm-versatile-926ejs/hardware.cfg
372    yocto-kernel-cache/bsp/common-pc/hardware.cfg
373    yocto-kernel-cache/bsp/common-pc-64/hardware.cfg
374    yocto-kernel-cache/features/rfkill/non-hardware.cfg
375    yocto-kernel-cache/ktypes/base/non-hardware.cfg
376    yocto-kernel-cache/features/aufs/non-hardware.kcf
377    yocto-kernel-cache/features/ocf/non-hardware.kcf
378    yocto-kernel-cache/ktypes/base/non-hardware.kcf
379    yocto-kernel-cache/ktypes/base/hardware.kcf
380    yocto-kernel-cache/bsp/qemu-ppc32/hardware.kcf
382 Here are explanations for the various files:
384 -  ``hardware.kcf``: Specifies a list of kernel Kconfig files that
387 -  ``non-hardware.kcf``: Specifies a list of kernel Kconfig files that
388    contain non-hardware options only.
390 -  ``hardware.cfg``: Specifies a list of kernel ``CONFIG_`` options that
392    file specified by a hardware or non-hardware Kconfig file (i.e.
393    ``hardware.kcf`` or ``non-hardware.kcf``).
395 -  ``non-hardware.cfg``: Specifies a list of kernel ``CONFIG_`` options
397    Kconfig file specified by a hardware or non-hardware Kconfig file
398    (i.e. ``hardware.kcf`` or ``non-hardware.kcf``).
401 ``kernel-cache/bsp/mti-malta32/hardware.cfg``::
412 these files (hence the names must be exactly the ones discussed here),
416 A user-specified kernel Metadata repository, or recipe space feature,
417 can use these same files to classify options that are found within its
418 ``.cfg`` files as hardware or non-hardware, to prevent the OpenEmbedded