Lines Matching full:kernel
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
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
34 Yocto Project Linux kernel that caters to specific embedded designer
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
87 - For Yocto Project releases 2.1, 2.2, and 2.3, the LTSI kernel is
90 - For Yocto Project release 2.4, the LTSI kernel is
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.
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
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
119 Linux kernel. They only consider back-porting significant technological
122 from an evolving Linux kernel can easily create mismatches,
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
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,
138 Yocto Linux Kernel Architecture and Branching Strategies
142 developer with a kernel that has a clear and continuous history that is
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
157 only is Git the SCM for Linux kernel development in ``kernel.org``
172 creates kernel branches at points where functionality is no longer
175 require a branch to separate the features. Likewise, for specific kernel
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
183 history of what made up the baseline Linux kernel.
186 same feature twice internally in the tree. Rather, the kernel team
188 kernel type in question.
193 that features can be shared by all boards and kernel types where
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.
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
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
231 The "Yocto Project Baseline Kernel" contains functionality that is
232 common to every kernel type and BSP that is organized further along in
237 From the "Yocto Project Baseline Kernel", branch points represent
240 three BSP-specific branches and a real-time kernel branch. Each branch
242 Yocto Linux kernel.
244 In this example structure, the "Real-time (rt) Kernel" branch has common
248 specific, unique features for a respective real-time kernel as they
253 Yocto Linux kernel needed for any given set of requirements.
258 Yocto Linux kernels, but rather shows a single generic kernel just
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.
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
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
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`"
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
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.
351 included in the final kernel configuration.
359 "non-hardware", the kernel Metadata in ``yocto-kernel-cache`` contains
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
390 - ``hardware.cfg``: Specifies a list of kernel ``CONFIG_`` options that
395 - ``non-hardware.cfg``: Specifies a list of kernel ``CONFIG_`` options
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,