Lines Matching +full:in +full:- +full:kernel
1 .. SPDX-License-Identifier: CC-BY-SA-2.0-UK
4 Advanced Kernel Concepts
7 Yocto Project Kernel Development and Maintenance
11 other kernels, are based off the Linux kernel releases from
12 https://www.kernel.org. At the beginning of a major Linux kernel
13 development cycle, the Yocto Project team chooses a Linux kernel based
15 final upstream ``kernel.org`` versions, and Yocto Project feature
16 requirements. Typically, the Linux kernel chosen is in the final stages
17 of development by the Linux community. In other words, the Linux kernel
18 is in the release candidate or "rc" phase and has yet to reach final
19 release. But, by being in the final stages of external development, the
20 team knows that the ``kernel.org`` final release will clearly be within
24 up-to-date Yocto Linux kernel possible, while still ensuring that the
25 team has a stable official release for the baseline Linux kernel
29 released kernels from ``kernel.org``. In addition to a foundational
30 kernel from ``kernel.org``, the available Yocto Linux kernels contain a
31 mix of important new mainline developments, non-mainline developments
33 and custom features. These additions result in a commercially released
34 Yocto Project Linux kernel that caters to specific embedded designer
37 You can find a web interface to the Yocto Linux kernels in the
38 :ref:`overview-manual/development-environment:yocto project source repositories`
40 the left a grouping of Git repositories titled "Yocto Linux Kernel".
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
46 released kernel.
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
50 released kernel.
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
60 released kernel.
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
64 Linux 4.10 released kernel.
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
68 Linux 4.12 released kernel.
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
73 information on this "Advanced Kernel Metadata", see the
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.
95 Once a Yocto Linux kernel is officially released, the Yocto Project team
97 cycle, while still continuing maintenance on the released kernel. It is
99 feature development upstream is through a kernel uprev process.
100 Back-porting hundreds of individual fixes and minor features from
101 various kernel versions is not sustainable and can easily compromise
105 of Linux kernel development, BSP support, and release timing to select
106 the best possible ``kernel.org`` Linux kernel version on which to base
107 subsequent Yocto Linux kernel development. The team continually monitors
108 Linux community kernel development to look for significant features of
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
112 baseline kernel during the uprev cycle.
114 Generally speaking, every new Linux kernel both adds features and
116 upstream Linux kernel development and are managed by the Yocto Project
117 team's Yocto Linux kernel development strategy. It is 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
122 from an evolving Linux kernel can easily create mismatches,
125 The policies described in this section result in both a stable and a
126 cutting edge Yocto Linux kernel that mixes forward ports of existing
127 Linux kernel features and significant and critical new functionality.
128 Forward porting Linux kernel functionality into the Yocto Linux kernels
130 uprev". The many "micro uprevs" produce a Yocto Linux kernel version
131 with a mix of important new mainline, non-mainline, BSP developments and
132 feature integrations. This Yocto Linux kernel gives insight into new
133 features and allows focused amounts of testing to be done on the kernel,
136 kernels are used in leading edge feature and BSP development.
138 Yocto Linux Kernel Architecture and Branching Strategies
142 developer with a kernel that has a clear and continuous history that is
143 visible to the user. The architecture and mechanisms, in particular the
144 branching strategies, used achieve that goal in a manner similar to
145 upstream Linux kernel development in ``kernel.org``.
147 You can think of a Yocto Linux kernel as consisting of a baseline Linux
148 kernel with added features logically structured on top of the baseline.
155 - Git is the obvious SCM for meeting the Yocto Linux kernel
156 organizational and structural goals described in this section. Not
157 only is Git the SCM for Linux kernel development in ``kernel.org``
158 but, Git continues to grow in popularity and supports many
159 different work flows, front-ends and management techniques.
161 - You can find documentation on Git at https://git-scm.com/doc. You can
162 also get an introduction to Git as it applies to the Yocto Project in the
163 ":ref:`overview-manual/development-environment:git`" section in the Yocto Project
168 your project. You do not have to be a "Git Expert" in order to use
172 creates kernel branches at points where functionality is no longer
173 shared and thus, needs to be isolated. For example, board-specific
175 require a branch to separate the features. Likewise, for specific kernel
178 This "tree-like" architecture results in a structure that has features
179 organized to be specific for particular functionality, single kernel
180 types, or a subset of kernel types. Thus, the user has the ability to
181 see the added features and the commits that make up those features. In
183 history of what made up the baseline Linux kernel.
185 Another consequence of this strategy results in not having to store the
186 same feature twice internally in the tree. Rather, the kernel team
188 kernel type in question.
192 The Yocto Project team strives to place features in the tree such
193 that features can be shared by all boards and kernel types where
195 are merged, the team cannot always follow this practice. In those
198 BSP-specific code additions are handled in a similar manner to
199 kernel-specific additions. Some BSPs only make sense given certain
200 kernel types. So, for these types, the team creates branches off the end
201 of that kernel type for all of the BSPs that are supported on that
202 kernel type. From the perspective of the tools that create the BSP
204 same branching strategy applies to BSPs as it does to kernel features.
208 While this strategy can result in a tree with a significant number of
211 ``kernel.org``, through a select group of features and ends with their
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.
217 branches in the tree, should a person decide to explore them. For
219 the line-by-line code ``diff`` level is now a trivial operation.
221 The following illustration shows the conceptual Yocto Linux kernel.
223 .. image:: figures/kernel-architecture-overview.png
226 In the illustration, the "Kernel.org Branch Point" marks the specific
227 spot (or Linux kernel release) from which the Yocto Linux kernel is
228 created. From this point forward in the tree, features and differences
231 The "Yocto Project Baseline Kernel" contains functionality that is
232 common to every kernel type and BSP that is organized further along in
233 the tree. Placing these common features in the tree this way means
237 From the "Yocto Project Baseline Kernel", branch points represent
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
242 Yocto Linux kernel.
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
253 Yocto Linux kernel needed for any given set of requirements.
257 Keep in mind the figure does not take into account all the supported
258 Yocto Linux kernels, but rather shows a single generic kernel just
259 for conceptual purposes. Also keep in mind that this structure
261 :ref:`overview-manual/development-environment:yocto project source repositories`
264 particular kernel's Git repository or by downloading and unpacking a
267 Working with the kernel as a structured tree follows recognized
268 community best practices. In particular, the kernel as shipped with the
272 Yocto Project kernel development team.
274 Because commits only change at significant release points in the product
276 relevant commit in the shipped Yocto Project Linux kernel. As mentioned
278 kernel tree is left in this state after cloning and building the kernel.
280 Kernel Build File Hierarchy
283 Upstream storage of all the available kernel source code is one thing,
285 another. Conceptually, you can think of the kernel source repositories
287 kernels. As a developer, you are just interested in the source files for
288 the kernel on which you are working. And, furthermore, you need them
291 Kernel source code is available on your host system several different
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,
300 the Yocto Linux kernel tree. For information on how to clone a Yocto
301 Linux kernel Git repository, see the
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
306 patches to the kernel using a traditional BitBake workflow (i.e. not
307 using the ``devtool``), you can access temporary kernel source files
308 that were extracted and used during a kernel build.
310 The temporary kernel source files resulting from a build using BitBake
311 have a particular hierarchy. When you build the kernel on your
315 in a temporary work area where they are subsequently used to create the
316 unique kernel. Thus, in a sense, the process constructs a local source
317 tree specific to your kernel from which to generate the new kernel
321 host system when you build the kernel using Bitbake. This
325 .. image:: figures/kernel-overview-2-generic.png
328 Again, for additional information on the Yocto Project kernel's
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`"
335 sections for detailed example that modifies the kernel.
337 Determining Hardware and Non-Hardware Features for the Kernel Configuration Audit Phase
340 This section describes part of the kernel configuration audit phase that
341 most developers can ignore. For general information on kernel
344 ":ref:`kernel-dev/common:configuring the kernel`" section.
349 user-specified configuration elements. Regardless of their origin, the
351 included in the final kernel configuration.
353 By default, in order to not overwhelm the user with configuration
355 could result in a boot failure or indicate that important hardware is
359 "non-hardware", the kernel Metadata in ``yocto-kernel-cache`` contains
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
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``::
411 The kernel configuration audit automatically detects
416 A user-specified kernel Metadata repository, or recipe space feature,
418 ``.cfg`` files as hardware or non-hardware, to prevent the OpenEmbedded
419 build system from producing an error or warning when an option is not in