From 000f052765577826907ff1e3f758bab3a0724d74 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Wed, 24 Nov 2010 08:31:55 -0800 Subject: documentation/kerenl-manual: New directory and files for kernel manual. This is the first draft of the Yocto Project Kernel manual. The manual consists of two sections: concepts and a practical section that has examples. It is based of Bruce Ashfield's kernel theory paper. This first draft has been re-written and organized through the concepts section. The remainder was just placed in as-is due to time constraints for getting some kernel documentation up on the website. The manual still needs scrubbing and organization in the latter half. Signed-off-by: Scott Rifenbark --- documentation/kernel-manual/Makefile | 32 + .../figures/kernel-architecture-overview.png | Bin 0 -> 40778 bytes .../kernel-manual/figures/kernel-big-picture.png | Bin 0 -> 173130 bytes .../kernel-manual/figures/yocto-project-transp.png | Bin 0 -> 8626 bytes documentation/kernel-manual/style.css | 967 +++++++++ .../yocto-project-kernal-manual-customization.xsl | 8 + .../kernel-manual/yocto-project-kernal-manual.xml | 2175 ++++++++++++++++++++ 7 files changed, 3182 insertions(+) create mode 100644 documentation/kernel-manual/Makefile create mode 100755 documentation/kernel-manual/figures/kernel-architecture-overview.png create mode 100755 documentation/kernel-manual/figures/kernel-big-picture.png create mode 100755 documentation/kernel-manual/figures/yocto-project-transp.png create mode 100644 documentation/kernel-manual/style.css create mode 100644 documentation/kernel-manual/yocto-project-kernal-manual-customization.xsl create mode 100644 documentation/kernel-manual/yocto-project-kernal-manual.xml diff --git a/documentation/kernel-manual/Makefile b/documentation/kernel-manual/Makefile new file mode 100644 index 0000000000..701bddfa77 --- /dev/null +++ b/documentation/kernel-manual/Makefile @@ -0,0 +1,32 @@ +XSLTOPTS = --stringparam html.stylesheet style.css \ + --xinclude + +XSL_BASE_URI = http://docbook.sourceforge.net/release/xsl/current +XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl + +all: html tarball + +## +# These URI should be rewritten by your distribution's xml catalog to +# match your localy installed XSL stylesheets. + +html: +# See http://www.sagehill.net/docbookxsl/HtmlOutput.html + +# xsltproc $(XSLTOPTS) -o yocto-project-qs.html $(XSL_XHTML_URI) yocto-project-qs.xml + xsltproc $(XSLTOPTS) -o yocto-project-kernal-manual.html yocto-project-kernal-manual-customization.xsl yocto-project-kernal-manual.xml + +tarball: html + tar -cvzf yocto-project-kernal-manual.tgz yocto-project-kernal-manual.html style.css figures/yocto-project-transp.png figures/kernel-big-picture.png figures/kernel-architecture-overview.png + +validate: + xmllint --postvalid --xinclude --noout yocto-project-kernal-manual.xml + +OUTPUTS = yocto-project-kernal-manual.tgz yocto-project-kernal-manual.html +SOURCES = *.png *.xml *.css + +publish: + scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/ + +clean: + rm -f $(OUTPUTS) diff --git a/documentation/kernel-manual/figures/kernel-architecture-overview.png b/documentation/kernel-manual/figures/kernel-architecture-overview.png new file mode 100755 index 0000000000..cdf908526f Binary files /dev/null and b/documentation/kernel-manual/figures/kernel-architecture-overview.png differ diff --git a/documentation/kernel-manual/figures/kernel-big-picture.png b/documentation/kernel-manual/figures/kernel-big-picture.png new file mode 100755 index 0000000000..49bac618ec Binary files /dev/null and b/documentation/kernel-manual/figures/kernel-big-picture.png differ diff --git a/documentation/kernel-manual/figures/yocto-project-transp.png b/documentation/kernel-manual/figures/yocto-project-transp.png new file mode 100755 index 0000000000..31d2b147fd Binary files /dev/null and b/documentation/kernel-manual/figures/yocto-project-transp.png differ diff --git a/documentation/kernel-manual/style.css b/documentation/kernel-manual/style.css new file mode 100644 index 0000000000..d100b69fc9 --- /dev/null +++ b/documentation/kernel-manual/style.css @@ -0,0 +1,967 @@ +/* + Generic XHTML / DocBook XHTML CSS Stylesheet. + + Browser wrangling and typographic design by + Oyvind Kolas / pippin@gimp.org + + Customised for Poky by + Matthew Allum / mallum@o-hand.com + + Thanks to: + Liam R. E. Quin + William Skaggs + Jakub Steiner + + Structure + --------- + + The stylesheet is divided into the following sections: + + Positioning + Margins, paddings, width, font-size, clearing. + Decorations + Borders, style + Colors + Colors + Graphics + Graphical backgrounds + Nasty IE tweaks + Workarounds needed to make it work in internet explorer, + currently makes the stylesheet non validating, but up until + this point it is validating. + Mozilla extensions + Transparency for footer + Rounded corners on boxes + +*/ + + + /*************** / + / Positioning / +/ ***************/ + +body { + font-family: Verdana, Sans, sans-serif; + + min-width: 640px; + width: 80%; + margin: 0em auto; + padding: 2em 5em 5em 5em; + color: #333; +} + +.reviewer { + color: red; +} + +h1,h2,h3,h4,h5,h6,h7 { + font-family: Arial, Sans; + color:#999999; + clear: both; +} + +h1 { + font-size: 2em; + text-align: left; + padding: 0em 0em 0em 0em; + margin: 2em 0em 0em 0em; +} + +h2.subtitle { + margin: 0.10em 0em 3.0em 0em; + padding: 0em 0em 0em 0em; + font-size: 1.8em; + padding-left: 20%; + font-weight: normal; + font-style: italic; +} + +h2 { + margin: 2em 0em 0.66em 0em; + padding: 0.5em 0em 0em 0em; + font-size: 1.5em; + font-weight: normal; +} + +h3.subtitle { + margin: 0em 0em 1em 0em; + padding: 0em 0em 0em 0em; + font-size: 142.14%; + text-align: right; +} + +h3 { + margin: 1em 0em 0.5em 0em; + padding: 1em 0em 0em 0em; + font-size: 140%; + font-weight: normal; +} + +h4 { + margin: 1em 0em 0.5em 0em; + padding: 1em 0em 0em 0em; + font-size: 120%; + font-weight: normal; +} + +h5 { + margin: 1em 0em 0.5em 0em; + padding: 1em 0em 0em 0em; + font-size: 110.000%; + border-bottom: 1px solid black; +} + +h6 { + margin: 1em 0em 0em 0em; + padding: 1em 0em 0em 0em; + font-size: 100%; + font-weight: bold; +} + +.authorgroup { + background-color: transparent; + background-repeat: no-repeat; + padding-top: 256px; + background-image: url("../figures/yocto-project-bw.png"); + background-position: top; + margin-top: -256px; + padding-right: 50px; + margin-left: 50px; + text-align: center; + width: 600px; +} + +h3.author { + margin: 0em 0me 0em 0em; + padding: 0em 0em 0em 0em; + font-weight: normal; + font-size: 100%; + clear: both; +} + +.author tt.email { + font-size: 66%; +} + +.titlepage hr { + width: 0em; + clear: both; +} + +.revhistory { + padding-top: 2em; + clear: both; +} + +.toc, +.list-of-tables, +.list-of-examples, +.list-of-figures { + padding: 1.33em 0em 2.5em 0em; +} + +.toc p, +.list-of-tables p, +.list-of-figures p, +.list-of-examples p { + padding: 0em 0em 0em 0em; + padding: 0em 0em 0.3em; + margin: 1.5em 0em 0em 0em; +} + +.toc p b, +.list-of-tables p b, +.list-of-figures p b, +.list-of-examples p b{ + font-size: 100.0%; + font-weight: bold; +} + +.toc dl, +.list-of-tables dl, +.list-of-figures dl, +.list-of-examples dl { + margin: 0em 0em 0.5em 0em; + padding: 0em 0em 0em 0em; +} + +.toc dt { + margin: 0em 0em 0em 0em; + padding: 0em 0em 0em 0em; +} + +.toc dd { + margin: 0em 0em 0em 2.6em; + padding: 0em 0em 0em 0em; +} + +div.glossary dl, +div.variablelist dl { +} + +.glossary dl dt, +.variablelist dl dt, +.variablelist dl dt span.term { + font-weight: normal; + width: 20em; + text-align: right; +} + +.variablelist dl dt { + margin-top: 0.5em; +} + +.glossary dl dd, +.variablelist dl dd { + margin-top: -1em; + margin-left: 25.5em; +} + +.glossary dd p, +.variablelist dd p { + margin-top: 0em; + margin-bottom: 1em; +} + + +div.calloutlist table td { + padding: 0em 0em 0em 0em; + margin: 0em 0em 0em 0em; +} + +div.calloutlist table td p { + margin-top: 0em; + margin-bottom: 1em; +} + +div p.copyright { + text-align: left; +} + +div.legalnotice p.legalnotice-title { + margin-bottom: 0em; +} + +p { + line-height: 1.5em; + margin-top: 0em; + color: black; font-size: 100%; + +} + +dl { + padding-top: 0em; +} + +hr { + border: solid 1px; +} + + +.mediaobject, +.mediaobjectco { + text-align: center; +} + +img { + border: none; +} + +ul { + padding: 0em 0em 0em 1.5em; +} + +ul li { + padding: 0em 0em 0em 0em; +} + +ul li p { + text-align: left; +} + +table { + width :100%; +} + +th { + padding: 0.25em; + text-align: left; + font-weight: normal; + vertical-align: top; +} + +td { + padding: 0.25em; + vertical-align: top; +} + +p a[id] { + margin: 0px; + padding: 0px; + display: inline; + background-image: none; +} + +a { + text-decoration: underline; + color: #444; +} + +pre { + overflow: auto; +} + +a:hover { + text-decoration: underline; + /*font-weight: bold;*/ +} + + +div.informalfigure, +div.informalexample, +div.informaltable, +div.figure, +div.table, +div.example { + margin: 1em 0em; + padding: 1em; + page-break-inside: avoid; +} + + +div.informalfigure p.title b, +div.informalexample p.title b, +div.informaltable p.title b, +div.figure p.title b, +div.example p.title b, +div.table p.title b{ + padding-top: 0em; + margin-top: 0em; + font-size: 100%; + font-weight: normal; +} + +.mediaobject .caption, +.mediaobject .caption p { + text-align: center; + font-size: 80%; + padding-top: 0.5em; + padding-bottom: 0.5em; +} + +.epigraph { + padding-left: 55%; + margin-bottom: 1em; +} + +.epigraph p { + text-align: left; +} + +.epigraph .quote { + font-style: italic; +} +.epigraph .attribution { + font-style: normal; + text-align: right; +} + +span.application { + font-style: italic; +} + +.programlisting { + font-family: monospace; + font-size: 80%; + white-space: pre; + margin: 1.33em 0em; + padding: 1.33em; +} + +.tip, +.warning, +.caution, +.note { + margin-top: 1em; + margin-bottom: 1em; + +} + +/* force full width of table within div */ +.tip table, +.warning table, +.caution table, +.note table { + border: none; + width: 100%; +} + + +.tip table th, +.warning table th, +.caution table th, +.note table th { + padding: 0.8em 0.0em 0.0em 0.0em; + margin : 0em 0em 0em 0em; +} + +.tip p, +.warning p, +.caution p, +.note p { + margin-top: 0.5em; + margin-bottom: 0.5em; + padding-right: 1em; + text-align: left; +} + +.acronym { + text-transform: uppercase; +} + +b.keycap, +.keycap { + padding: 0.09em 0.3em; + margin: 0em; +} + +.itemizedlist li { + clear: none; +} + +.filename { + font-size: medium; + font-family: Courier, monospace; +} + + +div.navheader, div.heading{ + position: absolute; + left: 0em; + top: 0em; + width: 100%; + background-color: #cdf; + width: 100%; +} + +div.navfooter, div.footing{ + position: fixed; + left: 0em; + bottom: 0em; + background-color: #eee; + width: 100%; +} + + +div.navheader td, +div.navfooter td { + font-size: 66%; +} + +div.navheader table th { + /*font-family: Georgia, Times, serif;*/ + /*font-size: x-large;*/ + font-size: 80%; +} + +div.navheader table { + border-left: 0em; + border-right: 0em; + border-top: 0em; + width: 100%; +} + +div.navfooter table { + border-left: 0em; + border-right: 0em; + border-bottom: 0em; + width: 100%; +} + +div.navheader table td a, +div.navfooter table td a { + color: #777; + text-decoration: none; +} + +/* normal text in the footer */ +div.navfooter table td { + color: black; +} + +div.navheader table td a:visited, +div.navfooter table td a:visited { + color: #444; +} + + +/* links in header and footer */ +div.navheader table td a:hover, +div.navfooter table td a:hover { + text-decoration: underline; + background-color: transparent; + color: #33a; +} + +div.navheader hr, +div.navfooter hr { + display: none; +} + + +.qandaset tr.question td p { + margin: 0em 0em 1em 0em; + padding: 0em 0em 0em 0em; +} + +.qandaset tr.answer td p { + margin: 0em 0em 1em 0em; + padding: 0em 0em 0em 0em; +} +.answer td { + padding-bottom: 1.5em; +} + +.emphasis { + font-weight: bold; +} + + + /************* / + / decorations / +/ *************/ + +.titlepage { +} + +.part .title { +} + +.subtitle { + border: none; +} + +/* +h1 { + border: none; +} + +h2 { + border-top: solid 0.2em; + border-bottom: solid 0.06em; +} + +h3 { + border-top: 0em; + border-bottom: solid 0.06em; +} + +h4 { + border: 0em; + border-bottom: solid 0.06em; +} + +h5 { + border: 0em; +} +*/ + +.programlisting { + border: solid 1px; +} + +div.figure, +div.table, +div.informalfigure, +div.informaltable, +div.informalexample, +div.example { + border: 1px solid; +} + + + +.tip, +.warning, +.caution, +.note { + border: 1px solid; +} + +.tip table th, +.warning table th, +.caution table th, +.note table th { + border-bottom: 1px solid; +} + +.question td { + border-top: 1px solid black; +} + +.answer { +} + + +b.keycap, +.keycap { + border: 1px solid; +} + + +div.navheader, div.heading{ + border-bottom: 1px solid; +} + + +div.navfooter, div.footing{ + border-top: 1px solid; +} + + /********* / + / colors / +/ *********/ + +body { + color: #333; + background: white; +} + +a { + background: transparent; +} + +a:hover { + background-color: #dedede; +} + + +h1, +h2, +h3, +h4, +h5, +h6, +h7, +h8 { + background-color: transparent; +} + +hr { + border-color: #aaa; +} + + +.tip, .warning, .caution, .note { + border-color: #aaa; +} + + +.tip table th, +.warning table th, +.caution table th, +.note table th { + border-bottom-color: #aaa; +} + + +.warning { + background-color: #fea; +} + +.caution { + background-color: #fea; +} + +.tip { + background-color: #eff; +} + +.note { + background-color: #dfc; +} + +.glossary dl dt, +.variablelist dl dt, +.variablelist dl dt span.term { + color: #044; +} + +div.figure, +div.table, +div.example, +div.informalfigure, +div.informaltable, +div.informalexample { + border-color: #aaa; +} + +pre.programlisting { + color: black; + background-color: #fff; + border-color: #aaa; + border-width: 2px; +} + +.guimenu, +.guilabel, +.guimenuitem { + background-color: #eee; +} + + +b.keycap, +.keycap { + background-color: #eee; + border-color: #999; +} + + +div.navheader { + border-color: black; +} + + +div.navfooter { + border-color: black; +} + + + /*********** / + / graphics / +/ ***********/ + +/* +body { + background-image: url("images/body_bg.jpg"); + background-attachment: fixed; +} + +.navheader, +.note, +.tip { + background-image: url("images/note_bg.jpg"); + background-attachment: fixed; +} + +.warning, +.caution { + background-image: url("images/warning_bg.jpg"); + background-attachment: fixed; +} + +.figure, +.informalfigure, +.example, +.informalexample, +.table, +.informaltable { + background-image: url("images/figure_bg.jpg"); + background-attachment: fixed; +} + +*/ +h1, +h2, +h3, +h4, +h5, +h6, +h7{ +} + +/* +Example of how to stick an image as part of the title. + +div.article .titlepage .title +{ + background-image: url("figures/white-on-black.png"); + background-position: center; + background-repeat: repeat-x; +} +*/ + +div.preface .titlepage .title, +div.colophon .title, +div.chapter .titlepage .title, +div.article .titlepage .title +{ +} + +div.section div.section .titlepage .title, +div.sect2 .titlepage .title { + background: none; +} + + +h1.title { + background-color: transparent; + background-image: url("figures/yocto-project-bw.png"); + background-repeat: no-repeat; + height: 256px; + text-indent: -9000px; + overflow:hidden; +} + +h2.subtitle { + background-color: transparent; + text-indent: -9000px; + overflow:hidden; + width: 0px; + display: none; +} + + /*************************************** / + / pippin.gimp.org specific alterations / +/ ***************************************/ + +/* +div.heading, div.navheader { + color: #777; + font-size: 80%; + padding: 0; + margin: 0; + text-align: left; + position: absolute; + top: 0px; + left: 0px; + width: 100%; + height: 50px; + background: url('/gfx/heading_bg.png') transparent; + background-repeat: repeat-x; + background-attachment: fixed; + border: none; +} + +div.heading a { + color: #444; +} + +div.footing, div.navfooter { + border: none; + color: #ddd; + font-size: 80%; + text-align:right; + + width: 100%; + padding-top: 10px; + position: absolute; + bottom: 0px; + left: 0px; + + background: url('/gfx/footing_bg.png') transparent; +} +*/ + + + + /****************** / + / nasty ie tweaks / +/ ******************/ + +/* +div.heading, div.navheader { + width:expression(document.body.clientWidth + "px"); +} + +div.footing, div.navfooter { + width:expression(document.body.clientWidth + "px"); + margin-left:expression("-5em"); +} +body { + padding:expression("4em 5em 0em 5em"); +} +*/ + + /**************************************** / + / mozilla vendor specific css extensions / +/ ****************************************/ +/* +div.navfooter, div.footing{ + -moz-opacity: 0.8em; +} + +div.figure, +div.table, +div.informalfigure, +div.informaltable, +div.informalexample, +div.example, +.tip, +.warning, +.caution, +.note { + -moz-border-radius: 0.5em; +} + +b.keycap, +.keycap { + -moz-border-radius: 0.3em; +} +*/ + +table tr td table tr td { + display: none; +} + + +hr { + display: none; +} + +table { + border: 0em; +} + + .photo { + float: right; + margin-left: 1.5em; + margin-bottom: 1.5em; + margin-top: 0em; + max-width: 17em; + border: 1px solid gray; + padding: 3px; + background: white; +} + .seperator { + padding-top: 2em; + clear: both; + } + + #validators { + margin-top: 5em; + text-align: right; + color: #777; + } + @media print { + body { + font-size: 8pt; + } + .noprint { + display: none; + } + } + + +.tip, +.note { + background: #91ae35; + color: #fff; + padding: 20px; + margin: 20px; +} + +.tip h3, +.note h3 { + padding: 0em; + margin: 0em; + font-size: 2em; + font-weight: bold; + color: #fff; +} + +.tip a, +.note a { + color: #fff; + text-decoration: underline; +} diff --git a/documentation/kernel-manual/yocto-project-kernal-manual-customization.xsl b/documentation/kernel-manual/yocto-project-kernal-manual-customization.xsl new file mode 100644 index 0000000000..8e6ea34dd4 --- /dev/null +++ b/documentation/kernel-manual/yocto-project-kernal-manual-customization.xsl @@ -0,0 +1,8 @@ + + + + + + + + diff --git a/documentation/kernel-manual/yocto-project-kernal-manual.xml b/documentation/kernel-manual/yocto-project-kernal-manual.xml new file mode 100644 index 0000000000..b1693500fc --- /dev/null +++ b/documentation/kernel-manual/yocto-project-kernal-manual.xml @@ -0,0 +1,2175 @@ + + +
+ + +
+ Yocto Project Kernel Architecture and Use Manual +
+ +
+ Introduction + + Yocto Project presents the kernel as a fully patched, history-clean git + repository. + The git tree represents the selected features, board support, + and configurations extensively tested by Yocto Project. + The Yocto Project kernel allows the end user to leverage community + best practices to seamlessly manage the development, build and debug cycles. + + + This manual describes the Yocto Project kernel by providing information + on its history, organization, benefits, and use. + The manual consists of two sections: + + Concepts - Describes concepts behind the kernel. + You will understand how the kernel is organized and why it is organized in + the way it is. You will understand the benefits of the kernel's organization + and the mechanisms used to work with the kernel and how to apply it in your + design process. + Using the Kernel - Describes best practices and "how-to" information + that lets you put the kernel to practical use. Some examples are "How to Build a + Project Specific Tree", "How to Examine Changes in a Branch", and "Saving Kernel + Modifications." + + + + For more information on the kernel, see the following links: + + + + + + + You can find more information on Yocto Project by visiting the website at + . + + +
+ +
+ Concepts + + This section provides conceptual information about the Yocto Project kernel: + + Kernel Goals + Yocto Project Kernel Development and Maintenance Overview + Kernel Architecture + Kernel Tools + + +
+ Kernel Goals + + The complexity of embedded kernel design has increased dramatically. + Whether it is managing multiple implementations of a particular feature or tuning and + optimizing board specific features, flexibility and maintainability are key concerns. + The Yocto Project Linux kernel is presented with the embedded + developer's needs in mind and has evolved to assist in these key concerns. + For example, prior methods such as applying hundreds of patches to an extracted + tarball have been replaced with proven techniques that allow easy inspection, + bisection and analysis of changes. + Application of these techniques also creates a platform for performing integration and + collaboration with the thousands of upstream development projects. + + + With all these considerations in mind, the Yocto Project kernel and development team + strives to attain these goals: + + Allow the end user to leverage community best practices to seamlessly + manage the development, build and debug cycles. + Create a platform for performing integration and collaboration with the + thousands of upstream development projects that exist. + Provide mechanisms that support many different work flows, front-ends and + management techniques. + Deliver the most up-to-date kernel possible while still ensuring that + the baseline kernel is the the most stable official release. + Include major technological features as part of Yocto Project's up-rev + strategy. + Present a git tree, that just like the upstream kernel.org tree, has a + clear and continuous history. + Deliver a key set of supported kernel types, where each type is tailored + to a specific use case (i.g. networking, consumer, devices, and so forth). + Employ a git branching strategy that from a customer's point of view + results in a linear path from the baseline kernel.org, through a select group of features and + ends with their BSP-specific commits. + + +
+ +
+ Yocto Project Kernel Development and Maintenance Overview + + Yocto Project kernel, like other kernels, is based off the Linux kernel release + from . + At the beginning of our major development cycle, we choose our Yocto Project kernel + based on factors like release timing, the anticipated release timing of "final" (i.e. non "rc") + upstream kernel.org versions, and Yocto Project feature requirements. + Typically this will be a kernel that is in the + final stages of development by the community (i.e. still in the release + candidate or "rc" phase) and not yet a final release. + But by being in the final stages of external development, we know that the + kernel.org final release will clearly land within the early stages of + the Yocto Project development window. + + + This balance allows us to deliver the most up-to-date kernel + as possible, while still ensuring that we have a stable official release as + our baseline kernel version. + + + The following figure represents the overall place the Yocto Project kernel fills. + + + + + + In the figure the ultimate source for the Yocto Project kernel is a released kernel + from kernel.org. + In addition to a foundational kernel from kernel.org the commercially released + Yocto Project kernel contains a mix of important new mainline + developments, non-mainline developments, Board Support Package (BSP) developments, + and custom features. + These additions result in a commercially released Yocto Project kernel that caters + to specific embedded designer needs for targeted hardware. + + + Once a Yocto Project kernel is officially released the Yocto Project team goes into + their next development cycle, or "uprev" cycle. + 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 of hundreds of individual fixes and minor features from various + kernel versions is not sustainable and can easily compromise quality. + 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 kernel.org version. + The team continually monitors community kernel + development to look for significant features of interest. + The illustration depicts this by showing the team looking back to kernel.org for new features, + BSP features, and significant bug fixes. + 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. + + + 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 simply back-porting any small to medium sized change + from an evolving kernel can easily create mismatches, incompatibilities and very + subtle errors. + + + 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 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 very special + cases for BSP and feature development. + +
+ +
+ Kernel Architecture + + This section describes the architecture of the Yocto Project kernel and provides information + on the mechanisms used to achieve that architecture. + + +
+ Overview + + As mentioned earlier, a key goal of Yocto Project is to present the developer with + a kernel that has a clear and continuous history that is visible to the user. + The architecture and mechanisms used achieve that goal in a manner similar to the + upstream kernel.org. + + + + You can think of the Yocto Project kernel as consisting of a baseline kernel with + added features logically structured on top of the baseline. + The features are tagged and organized by way of a branching strategy implemented by the + source code manager (SCM) git. + The result is that the user has the ability to see the added features and + the commits that make up those features. + In addition to being able to see added features, the user can also view the history of what + made up the baseline kernel as well. + + + The following illustration shows the conceptual Yocto Project kernel. + + + + + + In the illustration, the "kernel.org Branch Point" marks the specific spot (or release) from + which the Yocto Project kernel is created. From this point "up" in the tree features and + differences are organized and tagged. + + + The "Yocto Project Baseline Kernel" contains functionality that is common to every kernel + type and BSP that is organized further up the tree. Placing these common features in the + tree this way means features don't have to be duplicated along individual branches of the + structure. + + + From the Yocto Project Baseline Kernel branch points represent specific functionality + for individual BSPs as well as real-time kernels. + The illustration represents this through three BSP-specific branches and a real-time + kernel branch. + Each branch represents some unique functionality for the BSP or a real-time kernel. + + + The real-time kernel branch has common features for all real-time kernels and contains + more branches for individual BSP-specific real-time kernels. + The illustration shows three branches as an example. + Each branch points the way to specific, unique features for a respective real-time + kernel as they apply to a given BSP. + + + The resulting tree structure presents a clear path of markers (or branches) to the user + that for all practical purposes is the kernel needed for any given set of requirements. + +
+ +
+ Branching Strategy and Workflow + + The Yocto Project team creates kernel branches at points where functionality is + no longer shared and thus, needs to be isolated. + For example, board-specific incompatibilities would require different functionality + and would require a branch to separate the features. + Likewise, for specific kernel features the same branching strategy is used. + This branching strategy results in a tree that has features organized to be specific + for particular functionality, single kernel types, or a subset of kernel types. + This strategy results in not having to store the same feature twice internally in the + tree. + Rather we store the unique differences required to apply the feature onto the kernel type + in question. + + + BSP-specific code additions are handled in a similar manner to kernel-specific additions. + Some BSPs only make sense given certain kernel types. + So, for these types, we create branches off the end of that kernel type for all + of the BSPs that are supported on that kernel type. + From the perspective of the tools that create the BSP branch, the BSP is really no + different than a feature. + Consequently, the same branching strategy applies to BSPs as it does to features. + So again, rather than store the BSP twice, only the unique differences for the BSP across + the supported multiple kernels are uniquely stored. + + + While this strategy results in a tree with a significant number of branches, it is + important to realize that from the customer's point of view, there is a linear + path that travels from the baseline kernel.org, through a select group of features and + ends with their BSP-specific commits. + In other words, the divisions of the kernel are transparent and are not relevant + to the developer on a day-to-day basis. + From the customer's perspective, this is the "master" branch. + They do not need not be aware of the existence of any other branches at all. + Of course there is value in the existence of these branches + in the tree, should a person decide to explore them. + For example, a comparison between two BSPs at either the commit level or at the line-by-line + code diff level is now a trivial operation. + + + Working with the kernel as a structured tree follows recognized community best practices. + In particular, the kernel as shipped with the product should be + considered an 'upstream source' and viewed as a series of + historical and documented modifications (commits). + These modifications represent the development and stabilization done + by the Yocto Project kernel development team. + + + Because commits only change at significant release points in the product life cycle, + developers can work on a branch created + from the last relevant commit in the shipped Yocto Project kernel. + As mentioned previously, the structure is transparent to the user + because the kernel tree is left in this state after cloning and building the kernel. + +
+ +
+ Source Code Manager - git + + The Source Code Manager (SCM) is git and it is the obvious mechanism for meeting the + previously mentioned goals. + Not only is it the SCM for kernel.org but git continues to grow in popularity and + supports many different work flows, front-ends and management techniques. + + + It should be noted that you can use as much, or as little, of what git has to offer + as is appropriate to your project. + +
+
+ +
+ Kernel Tools + +Since most standard workflows involve moving forward with an existing tree by +continuing to add and alter the underlying baseline, the tools that manage +Yocto Project's kernel construction are largely hidden from the developer to +present a simplified view of the kernel for ease of use. + + +The fundamental properties of the tools that manage and construct the +kernel are: + + the ability to group patches into named, reusable features + to allow top down control of included features + the binding of kernel configuration to kernel patches/features + the presentation of a seamless git repository that blends Yocto Project value with the kernel.org history and development + + + +The tools that construct a kernel tree will be discussed later in this +document. The following tools form the foundation of the Yocto Project +kernel toolkit: + + git : distributed revision control system created by Linus Torvalds + guilt: quilt on top of git + *cfg : kernel configuration management and classification + kgit*: Yocto Project kernel tree creation and management tools + scc : series & configuration compiler + + +
+
+ + + + + + +
+ How to get things accomplished with the kernel + + This section describes how to accomplish tasks involving the kernel's tree structure. + The information covers the following: + + Tree construction + Build strategies + Series & Configuration Compiler + kgit + Workflow examples + Source Code Manager (SCM) + Board Support Package (BSP) template migration + BSP creation + Patching + Updating BSP patches and configuration + guilt + scc file example + "dirty" string + Transition kernel layer + + + +
+ Tree Construction + +The Yocto Project kernel repository, as shipped with the product, is created by +compiling and executing the set of feature descriptions for every BSP/feature +in the product. Those feature descriptions list all necessary patches, +configuration, branching, tagging and feature divisions found in the kernel. + + +The files used to describe all the valid features and BSPs in the Yocto Project +kernel can be found in any clone of the kernel git tree. The directory +wrs/cfg/kernel-cache/ is a snapshot of all the kernel configuration and +feature descriptions (.scc) that were used to build the kernel repository. +It should however be noted, that browsing the snapshot of feature +descriptions and patches is not an effective way to determine what is in a +particular kernel branch. Using git directly to get insight into the changes +in a branch is more efficient and a more flexible way to inspect changes to +the kernel. Examples of using git to inspect kernel commits are in the +following sections. + + +As a reminder, it is envisioned that a ground up reconstruction of the +complete kernel tree is an action only taken by Yocto Project staff during an +active development cycle. When an end user creates a project, it takes +advantage of this complete tree in order to efficiently place a git tree +within their project. + + +The general flow of the project specific kernel tree construction is as follows: + + a top level kernel feature is passed to the kernel build subsystem, + normally this is a BSP for a particular kernel type. + + the file that describes the top level feature is located by searching + system directories: + + + the kernel-cache under linux/wrs/cfg/kernel-cache + kernel-*-cache directories in layers + configured and default templates + + + In a typical build a feature description of the format: + <bsp name>-<kernel type>.scc is the target of the search. + + + once located, the feature description is compiled into a simple script + of actions, or an existing equivalent script which was part of the + shipped kernel is located. + + extra features are appended to the top level feature description. Extra + features can come from the command line, the configure script or + templates. + + each extra feature is located, compiled and appended to the script from + step #3 + + the script is executed, and a meta-series is produced. The meta-series + is a description of all the branches, tags, patches and configuration that + need to be applied to the base git repository to completely create the + "bsp_name-kernel_type". + + the base repository (normally kernel.org) is cloned, and the actions + listed in the meta-series are applied to the tree. + + the git repository is left with the desired branch checked out and any + required branching, patching and tagging has been performed. + + + + +The tree is now ready for configuration and compilation. Those two topics will +be covered below. + + +The end user generated meta-series adds to the kernel as shipped with + the Yocto Project release. Any add-ons and configuration data are applied + to the end of an existing branch. The full repository generation that + is found in the linux-2.6-windriver.git is the combination of all + supported boards and configurations. + + + +This technique is flexible and allows the seamless blending of an immutable +history with additional deployment specific patches. Any additions to the +kernel become an integrated part of the branches. + + +It is key that feature descriptions indicate if any branches are + required, since the build system cannot automatically decide where a + BSP should branch or if that branch point needs a name with + significance. There is a single restriction enforced by the compilation + phase: + + A BSP must create a branch of the format <bsp name>-<kernel type>. + + This means that all merged/support BSPs must indicate where to start + its branch from, with the right name, in its .scc files. The scc + section describes the available branching commands in more detail. + + + + +A summary of end user tree construction activities follow: + + compile and link a full top-down kernel description from feature descriptions + execute the complete description to generate a meta-series + interpret the meta-series to create a customized git repository for the + board + migrate configuration fragments and configure the kernel + checkout the BSP branch and build + + +
+ +
+ Build Strategy + +There are some prerequisites that must be met before starting the compilation +phase of the kernel build system: + + + There must be a kernel git repository indicated in the SRC_URI. + There must be a branch <bsp name>-<kernel type>. + + + +These are typically met by running tree construction/patching phase of the +build system, but can be achieved by other means. Examples of alternate work +flows such as bootstrapping a BSP are provided below. + + +Before building a kernel it is configured by processing all of the +configuration "fragments" specified by the scc feature descriptions. As the +features are compiled, associated kernel configuration fragments are noted +and recorded in the meta-series in their compilation order. The +fragments are migrated, pre-processed and passed to the Linux Kernel +Configuration subsystem (lkc) as raw input in the form of a .config file. +The lkc uses its own internal dependency constraints to do the final +processing of that information and generates the final .config that will +be used during compilation. + + +Kernel compilation is started, using the board's architecture and other +relevant values from the board template, and a kernel image is produced. + + +The other thing that you will first see once you configure a kernel is that +it will generate a build tree that is separate from your git source tree. +This build dir will be called "linux-<BSPname>-<kerntype>-build" where +kerntype is one of standard, cg`` +e, etc. This functionality is done by making +use of the existing support that is within the kernel.org tree by default. + + +What this means, is that all the generated files (that includes the final +".config" itself, all ".o" and ".a" etc) are now in this directory. Since +the git source tree can contain any number of BSPs, all on their own branch, +you now can easily switch between builds of BSPs as well, since each one also +has their own separate build directory. + +
+ +
+ Series & Configuration Compiler (SCC) + +In early versions of the product, kernel patches were simply listed in a flat +file called "patches.list", and then quilt was added as a tool to help +traverse this list, which in quilt terms was called a "series" file. + + +Before the 2.0 release, it was already apparent that a static series file was +too inflexible, and that the series file had to become more dynamic and rely +on certain state (like kernel type) in order to determine whether a patch was +to be used or not. The 2.0 release already made use of some stateful +construction of series files, but since the delivery mechanism was unchanged +(tar + patches + series files), most people were not aware of anything really +different. The 3.0 release continues with this stateful construction of +series files, but since the delivery mechanism is changed (git + branches) it +now is more apparent to people. + + +As was previously mentioned, scc is a "series and configuration +compiler". Its role is to combine feature descriptions into a format that can +be used to generate a meta-series. A meta series contains all the required +information to construct a complete set of branches that are required to +build a desired board and feature set. The meta series is interpreted by the +kgit tools to create a git repository that could be built. + + +To illustrate how scc works, a feature description must first be understood. +A feature description is simply a small bash shell script that is executed by +scc in a controlled environment. Each feature description describes a set of +operations that add patches, modify existing patches or configure the +kernel. It is key that feature descriptions can include other features, and +hence allow the division of patches and configuration into named, reusable +containers. + + +Each feature description can use any of the following valid scc commands: + + shell constructs: bash conditionals and other utilities can be used in a feature + description. During compilation, the working directory is the feature + description itself, so any command that is "raw shell" and not from the + list of supported commands, can not directly modify a git repository. + + patch <relative path>/<patch name>: outputs a patch to be included in a feature's patch set. Only the name of + the patch is supplied, the path is calculated from the currently set + patch directory, which is normally the feature directory itself. + + patch_trigger >condition< >action< <tgt>: indicate that a trigger should be set to perform an action on a + patch. + +The conditions can be: + + + arch:<comma separated arch list or "all"> + plat:<comma separated platform list or "all"> + +The action can be: + + exclude: This is used in exceptional situations where a patch + cannot be applied for certain reasons (arch or platform). + When the trigger is satisfied the patch will be removed from + the patch list. + include: This is used to include a patch only for a specific trigger. + Like exclude, this should only be used when necessary. + It takes 1 argument, the patch to include. + + + include <feature name> [after <feature>]: includes a feature for processing. The feature is "expanded" at the + position of the include directive. This means that any patches, + configuration or sub-includes of the feature will appear in the final + series before the commands that follow the include. + + include searches the include directories for a matching feature name, + include directories are passed to scc by the caller using -I <path> and + is transparent to the feature script. This means that <feature name> must + be relative to one of the search paths. For example, if + /opt/kernel-cache/feat/sched.scc is to be included and scc is invoked + with -I /opt/kernel-cache, then a feature would issue "include + feat/sched.scc" to include the feature. + + + The optional "after" directive allows a feature to modify the existing + order of includes and insert a feature after the named feature is + processed. Note: the "include foo after bar" must be issued before "bar" + is processed, so is normally only used by a new top level feature to + modify the order of features in something it is including. + + exclude <feature name>: Indicates that a particular feature should *not* be included even if an + 'include' directive is found. The exclude must be issued before the + include is processed, so is normally only used by a new top level feature + to modify the order of features in something it is including. + + git <command>: Issues any git command during tree construction. Note: this command is + not validated/sanitized so care must be taken to not damage the + tree. This can be used to script branching, tagging, pulls or other git + operations. + + dir <directory>: changes the working directory for "patch" directives. This can be used to + shorten a long sequence of patches by not requiring a common relative + directory to be issued each time. + + kconf <type> <fragment name>: associates a kernel config frag with the feature. + <type> can be + "hardware" or "non-hardware" and is used by the kernel configuration + subsystem to audit configuration. <fragment name> is the name of a file + in the current feature directory that contains a series of kernel + configuration options. There is no restriction on the chosen fragment + name, although a suffix of ".cfg" is recommended. Multiple fragment + specifications are supported. + + branch <branch name>: creates a branch in the tree. All subsequent patch commands will be + applied to the new branch and changes isolated from the rest of the + repository. + + scc_leaf <base feature> <branch name>: Performs a combination feature include and branch. This is mainly a + convenience directive, but has significance to some build system bindings + as a sentinel to indicate that this intends to create a branch that is + valid for kernel compilation. + + tag <tag name>: Tags the tree. The tag will be applied in processing order, so will + be after already applied patches and precede patches yet to be applied. + + define <var> <value>: Creates a variable with a particular value that can be used in subsequent + feature descriptions. + + + +
+ +
+ kgit Tools + +The kgit tools are responsible for constructing and maintaining the Wind +River kernel repository. These activities include importing, exporting, and +applying patches as well as sanity checking and branch management. From the +developers perspective, the kgit tools are hidden and rarely require +interactive use. But one tool in particular that warrants further description +is "kgit-meta". + + +kgit-meta is the actual application of feature description(s) to a kernel repo. +In other words, it is responsible for interpreting the meta series generated +from a scc compiled script. As a result, kgit-meta is coupled to the set of +commands permitted in a .scc feature description (listed in the scc section). +kgit-meta understands both the meta series format and how to use git and +guilt to modify a base git repository. It processes a meta-series line by +line, branching, tagging, patching and tracking changes that are made to the +base git repository. + + +Once kgit-meta has processed a meta-series, it leaves the repository with the +last branch checked out, and creates the necessary guilt infrastructure to +inspect the tree, or add to it via using guilt. As was previously mentioned, +guilt is not required, but is provided as a convenience. Other utilities such +as quilt, stgit, git or others can also be used to manipulate the git +repository. + +
+ +
+ Workflow Examples + + +As previously noted, the Yocto Project kernel has built in git/guilt +integration, but these utilities are not the only way to work with the kernel +repository. Yocto Project has not made changes to git, or other tools that +invalidate alternate workflows. Additionally, the way the kernel repository +is constructed uses only core git functionality allowing any number of tools +or front ends to use the resulting tree. + +This section contains several workflow examples. + + +
+ Change Inspection: Kernel Changes/Commits + +A common question when working with a BSP/kernel is: "What changes have been applied to this tree?" + + +In previous Yocto Project releases, there were a collection of directories that +contained patches to the kernel, those patches could be inspected, grep'd or +otherwise used to get a general feeling for changes. This sort of patch +inspection is not an efficient way to determine what has been done to the +kernel, since there are many optional patches that are selected based on the +kernel type and feature description, not to mention patches that are actually +in directories that are not being searched. + + +A more effective way to determine what has changed in the kernel is to use +git and inspect / search the kernel tree. This is a full view of not only the +source code modifications, but the reasoning behind the changes. + +
+ What Changed in a BSP? + +These examples could continue for some time, since the Yocto Project git +repository doesn't break existing git functionality and there are nearly +endless permutations of those commands. Also note that unless a commit range +is given (<kernel type>..<bsp>-<kernel type>), kernel.org history is blended +with Yocto Project changes + + + # full description of the changes + > git whatchanged <kernel type>..<bsp>-<kernel type> + > eg: git whatchanged standard..common_pc-standard + + # summary of the changes + > git log ‐‐pretty=oneline ‐‐abbrev-commit <kernel type>..<bsp>-<kernel type> + + # source code changes (one combined diff) + > git diff <kernel type>..<bsp>-<kernel type> + > git show <kernel type>..<bsp>-<kernel type> + + # dump individual patches per commit + > git format-patch -o <dir> <kernel type>..<bsp>-<kernel type> + + # determine the change history of a particular file + > git whatchanged <path to file> + + # determine the commits which touch each line in a file + > git blame <path to file> + +
+ +
+ Show a Particular Feature or Branch Change + +Significant features or branches are tagged in the Yocto Project tree to divide +changes. Remember to first determine (or add) the tag of interest. Note: +there will be many tags, since each BSP branch is tagged, kernel.org tags and +feature tags are all present. + + + # show the changes tagged by a feature + > git show <tag> + > eg: git show yaffs2 + + # determine which branches contain a feature + > git branch ‐‐contains <tag> + + # show the changes in a kernel type + > git whatchanged wrs_base..<kernel type> + > eg: git whatchanged wrs_base..standard + + +Many other comparisons can be done to isolate BSP changes, such as comparing +to kernel.org tags (v2.6.27.18, etc), per subsystem comparisons (git +whatchanged mm) or many other types of checks. + +
+
+ +
+ Development: Saving Kernel Modifications + +Another common operation is to build a Yocto Project supplied BSP, make some +changes, rebuild and test. Those local changes often need to be exported, +shared or otherwise maintained. + + +Since the Yocto Project kernel source tree is backed by git, this activity is +greatly simplified and is much easier than in previous releases. git tracks +file modifications, additions and deletions, which allows the developer to +modify the code and later realize that the changes should be saved, and +easily determine what was changed. It also provides many tools to commit, +undo and export those modifications. + + +There are many ways to perform this action, and the technique employed +depends on the destination for the patches, which could be any of: + + bulk storage + internal sharing either through patches or using git + external submission + export for integration into another SCM + + + +The destination of the patches also incluences the method of gathering them +due to issues such as: + + bisectability + commit headers + division of subsystems for separate submission / review + + + +
+ Bulk Export + +If patches are simply being stored outside of the kernel source repository, +either permanently or temporarily, then t