aboutsummaryrefslogtreecommitdiffstats
path: root/documentation/kernel-dev
diff options
context:
space:
mode:
authorScott Rifenbark <scott.m.rifenbark@intel.com>2013-01-28 11:18:25 -0600
committerRichard Purdie <richard.purdie@linuxfoundation.org>2013-01-30 14:10:02 +0000
commitd029e786b56b1e38fc5ac7243ba61672f47a7e18 (patch)
tree09f56a4922804d8f227aec1f0e4af7b2422f398f /documentation/kernel-dev
parentb80e98362039281873e2d8df1badb4c223e2d69f (diff)
downloadopenembedded-core-contrib-d029e786b56b1e38fc5ac7243ba61672f47a7e18.tar.gz
kernel-dev: Added new appendix for kernel concepts.
(From yocto-docs rev: e25465c6d177a27d3dee742ebc958ae30f968ffa) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation/kernel-dev')
-rw-r--r--documentation/kernel-dev/kernel-dev-concepts-appx.xml89
1 files changed, 89 insertions, 0 deletions
diff --git a/documentation/kernel-dev/kernel-dev-concepts-appx.xml b/documentation/kernel-dev/kernel-dev-concepts-appx.xml
new file mode 100644
index 0000000000..d78d2dc86c
--- /dev/null
+++ b/documentation/kernel-dev/kernel-dev-concepts-appx.xml
@@ -0,0 +1,89 @@
+<!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
+-->