90 lines
5.1 KiB
XML
90 lines
5.1 KiB
XML
|
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
||
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
||
|
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
||
|
|
||
|
<appendix id='kernel-dev-concepts-appx'>
|
||
|
<title>Advanced Kernel Concepts</title>
|
||
|
|
||
|
<section id='kernel-big-picture'>
|
||
|
<title>Yocto Project Kernel Development and Maintenance</title>
|
||
|
<para>
|
||
|
Kernels available through the Yocto Project, like other kernels, are based off the Linux
|
||
|
kernel releases from <ulink url='http://www.kernel.org'></ulink>.
|
||
|
At the beginning of a major development cycle, the Yocto Project team
|
||
|
chooses its kernel based on factors such as release timing, the anticipated release
|
||
|
timing of final upstream <filename>kernel.org</filename> versions, and Yocto Project
|
||
|
feature requirements.
|
||
|
Typically, the kernel chosen is in the
|
||
|
final stages of development by the community.
|
||
|
In other words, the kernel is in the release
|
||
|
candidate or "rc" phase and not yet a final release.
|
||
|
But, by being in the final stages of external development, the team knows that the
|
||
|
<filename>kernel.org</filename> final release will clearly be within the early stages of
|
||
|
the Yocto Project development window.
|
||
|
</para>
|
||
|
<para>
|
||
|
This balance allows the team to deliver the most up-to-date kernel
|
||
|
possible, while still ensuring that the team has a stable official release for
|
||
|
the baseline Linux kernel version.
|
||
|
</para>
|
||
|
<para>
|
||
|
The ultimate source for kernels available through the Yocto Project are released kernels
|
||
|
from <filename>kernel.org</filename>.
|
||
|
In addition to a foundational kernel from <filename>kernel.org</filename>, the
|
||
|
kernels available contain a mix of important new mainline
|
||
|
developments, non-mainline developments (when there is no alternative),
|
||
|
Board Support Package (BSP) developments,
|
||
|
and custom features.
|
||
|
These additions result in a commercially released Yocto Project Linux kernel that caters
|
||
|
to specific embedded designer needs for targeted hardware.
|
||
|
</para>
|
||
|
<para>
|
||
|
Once a kernel is officially released, the Yocto Project team goes into
|
||
|
their next development cycle, or upward revision (uprev) cycle, while still
|
||
|
continuing maintenance on the released kernel.
|
||
|
It is important to note that the most sustainable and stable way
|
||
|
to include feature development upstream is through a kernel uprev process.
|
||
|
Back-porting hundreds of individual fixes and minor features from various
|
||
|
kernel versions is not sustainable and can easily compromise quality.
|
||
|
</para>
|
||
|
<para>
|
||
|
During the uprev cycle, the Yocto Project team uses an ongoing analysis of
|
||
|
kernel development, BSP support, and release timing to select the best
|
||
|
possible <filename>kernel.org</filename> version.
|
||
|
The team continually monitors community kernel
|
||
|
development to look for significant features of interest.
|
||
|
The team does consider back-porting large features if they have a significant advantage.
|
||
|
User or community demand can also trigger a back-port or creation of new
|
||
|
functionality in the Yocto Project baseline kernel during the uprev cycle.
|
||
|
</para>
|
||
|
<para>
|
||
|
Generally speaking, every new kernel both adds features and introduces new bugs.
|
||
|
These consequences are the basic properties of upstream kernel development and are
|
||
|
managed by the Yocto Project team's kernel strategy.
|
||
|
It is the Yocto Project team's policy to not back-port minor features to the released kernel.
|
||
|
They only consider back-porting significant technological jumps - and, that is done
|
||
|
after a complete gap analysis.
|
||
|
The reason for this policy is that back-porting any small to medium sized change
|
||
|
from an evolving kernel can easily create mismatches, incompatibilities and very
|
||
|
subtle errors.
|
||
|
</para>
|
||
|
<para>
|
||
|
These policies result in both a stable and a cutting
|
||
|
edge kernel that mixes forward ports of existing features and significant and critical
|
||
|
new functionality.
|
||
|
Forward porting functionality in the kernels available through the Yocto Project kernel
|
||
|
can be thought of as a "micro uprev."
|
||
|
The many “micro uprevs” produce a kernel version with a mix of
|
||
|
important new mainline, non-mainline, BSP developments and feature integrations.
|
||
|
This kernel gives insight into new features and allows focused
|
||
|
amounts of testing to be done on the kernel, which prevents
|
||
|
surprises when selecting the next major uprev.
|
||
|
The quality of these cutting edge kernels is evolving and the kernels are used in leading edge
|
||
|
feature and BSP development.
|
||
|
</para>
|
||
|
</section>
|
||
|
</appendix>
|
||
|
<!--
|
||
|
vim: expandtab tw=80 ts=4
|
||
|
-->
|