diff options
Diffstat (limited to 'documentation')
| -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 @@ | |||
| 1 | <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" | ||
| 2 | "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" | ||
| 3 | [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > | ||
| 4 | |||
| 5 | <appendix id='kernel-dev-concepts-appx'> | ||
| 6 | <title>Advanced Kernel Concepts</title> | ||
| 7 | |||
| 8 | <section id='kernel-big-picture'> | ||
| 9 | <title>Yocto Project Kernel Development and Maintenance</title> | ||
| 10 | <para> | ||
| 11 | Kernels available through the Yocto Project, like other kernels, are based off the Linux | ||
| 12 | kernel releases from <ulink url='http://www.kernel.org'></ulink>. | ||
| 13 | At the beginning of a major development cycle, the Yocto Project team | ||
| 14 | chooses its kernel based on factors such as release timing, the anticipated release | ||
| 15 | timing of final upstream <filename>kernel.org</filename> versions, and Yocto Project | ||
| 16 | feature requirements. | ||
| 17 | Typically, the kernel chosen is in the | ||
| 18 | final stages of development by the community. | ||
| 19 | In other words, the kernel is in the release | ||
| 20 | candidate or "rc" phase and not yet a final release. | ||
| 21 | But, by being in the final stages of external development, the team knows that the | ||
| 22 | <filename>kernel.org</filename> final release will clearly be within the early stages of | ||
| 23 | the Yocto Project development window. | ||
| 24 | </para> | ||
| 25 | <para> | ||
| 26 | This balance allows the team to deliver the most up-to-date kernel | ||
| 27 | possible, while still ensuring that the team has a stable official release for | ||
| 28 | the baseline Linux kernel version. | ||
| 29 | </para> | ||
| 30 | <para> | ||
| 31 | The ultimate source for kernels available through the Yocto Project are released kernels | ||
| 32 | from <filename>kernel.org</filename>. | ||
| 33 | In addition to a foundational kernel from <filename>kernel.org</filename>, the | ||
| 34 | kernels available contain a mix of important new mainline | ||
| 35 | developments, non-mainline developments (when there is no alternative), | ||
| 36 | Board Support Package (BSP) developments, | ||
| 37 | and custom features. | ||
| 38 | These additions result in a commercially released Yocto Project Linux kernel that caters | ||
| 39 | to specific embedded designer needs for targeted hardware. | ||
| 40 | </para> | ||
| 41 | <para> | ||
| 42 | Once a kernel is officially released, the Yocto Project team goes into | ||
| 43 | their next development cycle, or upward revision (uprev) cycle, while still | ||
| 44 | continuing maintenance on the released kernel. | ||
| 45 | It is important to note that the most sustainable and stable way | ||
| 46 | to include feature development upstream is through a kernel uprev process. | ||
| 47 | Back-porting hundreds of individual fixes and minor features from various | ||
| 48 | kernel versions is not sustainable and can easily compromise quality. | ||
| 49 | </para> | ||
| 50 | <para> | ||
| 51 | During the uprev cycle, the Yocto Project team uses an ongoing analysis of | ||
| 52 | kernel development, BSP support, and release timing to select the best | ||
| 53 | possible <filename>kernel.org</filename> version. | ||
| 54 | The team continually monitors community kernel | ||
| 55 | development to look for significant features of interest. | ||
| 56 | The team does consider back-porting large features if they have a significant advantage. | ||
| 57 | User or community demand can also trigger a back-port or creation of new | ||
| 58 | functionality in the Yocto Project baseline kernel during the uprev cycle. | ||
| 59 | </para> | ||
| 60 | <para> | ||
| 61 | Generally speaking, every new kernel both adds features and introduces new bugs. | ||
| 62 | These consequences are the basic properties of upstream kernel development and are | ||
| 63 | managed by the Yocto Project team's kernel strategy. | ||
| 64 | It is the Yocto Project team's policy to not back-port minor features to the released kernel. | ||
| 65 | They only consider back-porting significant technological jumps - and, that is done | ||
| 66 | after a complete gap analysis. | ||
| 67 | The reason for this policy is that back-porting any small to medium sized change | ||
| 68 | from an evolving kernel can easily create mismatches, incompatibilities and very | ||
| 69 | subtle errors. | ||
| 70 | </para> | ||
| 71 | <para> | ||
| 72 | These policies result in both a stable and a cutting | ||
| 73 | edge kernel that mixes forward ports of existing features and significant and critical | ||
| 74 | new functionality. | ||
| 75 | Forward porting functionality in the kernels available through the Yocto Project kernel | ||
| 76 | can be thought of as a "micro uprev." | ||
| 77 | The many “micro uprevs” produce a kernel version with a mix of | ||
| 78 | important new mainline, non-mainline, BSP developments and feature integrations. | ||
| 79 | This kernel gives insight into new features and allows focused | ||
| 80 | amounts of testing to be done on the kernel, which prevents | ||
| 81 | surprises when selecting the next major uprev. | ||
| 82 | The quality of these cutting edge kernels is evolving and the kernels are used in leading edge | ||
| 83 | feature and BSP development. | ||
| 84 | </para> | ||
| 85 | </section> | ||
| 86 | </appendix> | ||
| 87 | <!-- | ||
| 88 | vim: expandtab tw=80 ts=4 | ||
| 89 | --> | ||