diff options
author | Scott Rifenbark <scott.m.rifenbark@intel.com> | 2013-01-28 11:18:25 -0600 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2013-01-30 14:10:02 +0000 |
commit | d029e786b56b1e38fc5ac7243ba61672f47a7e18 (patch) | |
tree | 09f56a4922804d8f227aec1f0e4af7b2422f398f /documentation/kernel-dev | |
parent | b80e98362039281873e2d8df1badb4c223e2d69f (diff) | |
download | openembedded-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.xml | 89 |
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 +--> |