Drop documentation directory, this is replaced by the new yocto-docs repository

11 files changed, 0 insertions, 3660 deletions

diff --git a/documentation/kernel-manual/Makefile b/documentation/kernel-manual/Makefile
deleted file mode 100644
index a2eaced586..0000000000
--- a/documentation/kernel-manual/Makefile
+++ /dev/null
@@ -1,42 +0,0 @@
-XSLTOPTS = --stringparam html.stylesheet style.css \
-           --stringparam  chapter.autolabel 1 \
-           --stringparam  appendix.autolabel A \
-           --stringparam  section.autolabel 1 \
-           --stringparam  section.label.includes.component.label 1 \
-         --xinclude
-
-##
-# These URI should be rewritten by your distribution's xml catalog to
-# match your localy installed XSL stylesheets.
-XSL_BASE_URI  = http://docbook.sourceforge.net/release/xsl/current
-XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl
-
-all: html pdf tarball
-
-pdf:
-	../tools/poky-docbook-to-pdf kernel-manual.xml ../template
-
-##
-# 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 kernel-manual.html yocto-project-kernel-manual-customization.xsl kernel-manual.xml
-
-tarball: html
-	tar -cvzf kernel-manual.tgz kernel-manual.html kernel-manual.pdf style.css figures/kernel-title.png figures/kernel-big-picture.png figures/kernel-architecture-overview.png
-
-validate:
-	xmllint --postvalid --xinclude --noout kernel-manual.xml
-
-OUTPUTS = kernel-manual.tgz kernel-manual.html kernel-manual.pdf
-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
deleted file mode 100755
index 2aad172db3..0000000000
--- a/documentation/kernel-manual/figures/kernel-architecture-overview.png
+++ /dev/null
diff --git a/documentation/kernel-manual/figures/kernel-big-picture.png b/documentation/kernel-manual/figures/kernel-big-picture.png
deleted file mode 100755
index 49bac618ec..0000000000
--- a/documentation/kernel-manual/figures/kernel-big-picture.png
+++ /dev/null
diff --git a/documentation/kernel-manual/figures/kernel-title.png b/documentation/kernel-manual/figures/kernel-title.png
deleted file mode 100644
index 965264ccc5..0000000000
--- a/documentation/kernel-manual/figures/kernel-title.png
+++ /dev/null
diff --git a/documentation/kernel-manual/figures/yocto-project-transp.png b/documentation/kernel-manual/figures/yocto-project-transp.png
deleted file mode 100755
index 31d2b147fd..0000000000
--- a/documentation/kernel-manual/figures/yocto-project-transp.png
+++ /dev/null
diff --git a/documentation/kernel-manual/kernel-concepts.xml b/documentation/kernel-manual/kernel-concepts.xml
deleted file mode 100644
index f26e2903eb..0000000000
--- a/documentation/kernel-manual/kernel-concepts.xml
+++ /dev/null
@@ -1,335 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<chapter id='kernel-concepts'>
-
-<title>Yocto Project Kernel Concepts</title>
-
-<section id='concepts-org'>
-    <title>Introduction</title>
-    <para>
-        This chapter provides conceptual information about the Yocto Project kernel:
-        <itemizedlist>
-            <listitem><para>Kernel Goals</para></listitem>
-            <listitem><para>Yocto Project Kernel Development and Maintenance Overview</para></listitem>
-            <listitem><para>Kernel Architecture</para></listitem>
-            <listitem><para>Kernel Tools</para></listitem>
-        </itemizedlist>
-    </para>
-</section>
-
-    <section id='kernel-goals'>
-        <title>Kernel Goals</title>
-        <para>
-            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.
-        </para>
-        <para>
-            With all these considerations in mind, the Yocto Project kernel and development team
-            strives to attain these goals:
-        <itemizedlist>
-            <listitem><para>Allow the end user to leverage community best practices to seamlessly 
-            manage the development, build and debug cycles.</para></listitem>
-            <listitem><para>Create a platform for performing integration and collaboration with the 
-            thousands of upstream development projects that exist.</para></listitem>
-            <listitem><para>Provide mechanisms that support many different work flows, front-ends and 
-            management techniques.</para></listitem>
-            <listitem><para>Deliver the most up-to-date kernel possible while still ensuring that 
-            the baseline kernel is the most stable official release.</para></listitem>
-            <listitem><para>Include major technological features as part of Yocto Project's up-rev 
-            strategy.</para></listitem>
-            <listitem><para>Present a git tree, that just like the upstream kernel.org tree, has a 
-            clear and continuous history.</para></listitem>
-            <listitem><para>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).</para></listitem>
-            <listitem><para>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.</para></listitem>
-        </itemizedlist>
-        </para>
-    </section>
-
-    <section id='kernel-big-picture'>
-        <title>Yocto Project Kernel Development and Maintenance Overview</title>
-        <para>
-            Yocto Project kernel, like other kernels, is based off the Linux kernel release
-            from <ulink url='http://www.kernel.org'></ulink>.  
-            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.
-        </para>
-        <para>
-            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.
-        </para>
-        <para>
-            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 released 
-            Yocto Project kernel contains 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 kernel that caters 
-            to specific embedded designer needs for targeted hardware.
-        </para>
-<!--        <para>
-            The following figure represents the overall place the Yocto Project kernel fills.
-        </para>
-        <para>
-        <imagedata fileref="figures/kernel-big-picture.png" width="6in" depth="6in" align="center" scale="100" />
-        </para>
-        <para>
-            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. 
-        </para> -->
-        <para>
-            Once a Yocto Project kernel is officially released the Yocto Project team goes into 
-            their next development cycle, or "uprev" cycle while 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 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. 
-        </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 simply 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 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>
-
-    <section id='kernel-architecture'>
-        <title>Kernel Architecture</title>
-        <para>
-            This section describes the architecture of the Yocto Project kernel and provides information
-            on the mechanisms used to achieve that architecture.
-        </para>
-        
-        <section id='architecture-overview'>
-            <title>Overview</title>
-            <para>
-                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.
-                
-            </para>
-            <para>
-                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.
-            </para>
-            <para>
-                The following illustration shows the conceptual Yocto Project kernel.
-            </para>
-            <para>
-                <imagedata fileref="figures/kernel-architecture-overview.png" width="6in" depth="7in" align="center" scale="100" />
-            </para>
-            <para>
-                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.
-            </para>
-            <para>
-                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.
-            </para>
-            <para>
-                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.
-            </para>
-            <para>
-                In this example structure, 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.
-            </para>
-            <para>
-                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.
-            </para>
-        </section>
- 
-        <section id='branching-and-workflow'>
-            <title>Branching Strategy and Workflow</title>
-            <para>
-                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.
-            </para>
-            <note><para>
-                The Yocto Project team strives to place features in the tree such that they can be 
-                shared by all boards and kernel types where possible.
-                However, during development cycles or when large features are merged this practice 
-                cannot always be followed. 
-                In those cases isolated branches are used for feature merging.
-            </para></note>
-            <para>
-                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.
-            </para>
-            <para>
-                While this strategy can result in a tree with a significant number of branches, it is
-                important to realize that from the user'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 user'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.
-            </para>
-            <para>
-                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.
-            </para>
-            <para>
-                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.
-            </para>
-        </section>
-     
-        <section id='source-code-manager-git'>
-            <title>Source Code Manager - git</title>
-            <para>
-                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.
-            </para>
-            <note><para> 
-                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.
-            </para></note>
-        </section>
-    </section>
-
-    <section id='kernel-tools'>
-        <title>Kernel Tools</title>
-        <para>
-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.
-</para>
-<para>
-The fundamental properties of the tools that manage and construct the
-kernel are:
-<itemizedlist>
-    <listitem><para>the ability to group patches into named, reusable features</para></listitem>
-    <listitem><para>to allow top down control of included features</para></listitem>
-    <listitem><para>the binding of kernel configuration to kernel patches/features</para></listitem>
-    <listitem><para>the presentation of a seamless git repository that blends Yocto Project value with the kernel.org history and development</para></listitem>
-</itemizedlist>
-</para>
-<!--<para>
-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:
-<itemizedlist>
-    <listitem><para>git  : distributed revision control system created by Linus Torvalds</para></listitem>
-    <listitem><para>guilt: quilt on top of git</para></listitem>
-    <listitem><para>*cfg : kernel configuration management and classification</para></listitem>
-    <listitem><para>kgit*: Yocto Project kernel tree creation and management tools</para></listitem>
-    <listitem><para>scc  : series &amp; configuration compiler</para></listitem>
-</itemizedlist>
-</para> -->
-    </section> 
-
-
-
-
-
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
--->
diff --git a/documentation/kernel-manual/kernel-doc-intro.xml b/documentation/kernel-manual/kernel-doc-intro.xml
deleted file mode 100644
index 05e5443b85..0000000000
--- a/documentation/kernel-manual/kernel-doc-intro.xml
+++ /dev/null
@@ -1,57 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<chapter id='kernel-doc-intro'>
-
-<title>Yocto Project Kernel Architecture and Use Manual</title>
-
-<section id='book-intro'>
-    <title>Introduction</title>
-    <para>
-        The 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.
-    </para>
-    <para>
-        This manual describes the Yocto Project kernel by providing information
-        on its history, organization, benefits, and use.
-        The manual consists of two sections:
-        <itemizedlist>
-            <listitem><para>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.</para></listitem>
-            <listitem><para>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."</para></listitem>
-        </itemizedlist>
-    </para>
-    <para>
-        For more information on the kernel, see the following links:
-        <itemizedlist>
-            <listitem><para><ulink url='http://ldn.linuxfoundation.org/book/1-a-guide-kernel-development-process'></ulink></para></listitem>
-            <listitem><para><ulink url='http://userweb.kernel.org/~akpm/stuff/tpp.txt'></ulink></para></listitem>
-            <listitem><para><ulink url='http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/HOWTO;hb=HEAD'></ulink></para></listitem> 
-        </itemizedlist>
-        <para> 
-        You can find more information on Yocto Project by visiting the website at
-        <ulink url='http://www.yoctoproject.org'></ulink>.
-        </para>
-    </para>
-</section>
-
-
-
-
-
-
-
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
--->
diff --git a/documentation/kernel-manual/kernel-how-to.xml b/documentation/kernel-manual/kernel-how-to.xml
deleted file mode 100644
index 96325fe2a5..0000000000
--- a/documentation/kernel-manual/kernel-how-to.xml
+++ /dev/null
@@ -1,2178 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<chapter id='kernel-how-to'>
-
-<title>Working with the Yocto Project Kernel</title>
-
-
-<section id='actions-org'>
-    <title>Introduction</title>
-    <para>
-        This chapter describes how to accomplish tasks involving the kernel's tree structure. 
-        The information covers the following:
-        <itemizedlist> 
-            <listitem><para>Tree construction</para></listitem>
-            <listitem><para>Build strategies</para></listitem>
-<!--            <listitem><para>Series &amp; Configuration Compiler</para></listitem> 
-            <listitem><para>kgit</para></listitem> -->
-            <listitem><para>Workflow examples</para></listitem>
-<!--            <listitem><para>Source Code Manager (SCM)</para></listitem>
-            <listitem><para>Board Support Package (BSP) template migration</para></listitem> 
-            <listitem><para>BSP creation</para></listitem>
-            <listitem><para>Patching</para></listitem>
-            <listitem><para>Updating BSP patches and configuration</para></listitem>
-            <listitem><para>guilt</para></listitem>
-            <listitem><para>scc file example</para></listitem> 
-            <listitem><para>"dirty" string</para></listitem>
-            <listitem><para>Transition kernel layer</para></listitem> -->
-        </itemizedlist>
-    </para>
-</section>
-
-    <section id='tree-construction'>
-        <title>Tree Construction</title>
-        <para>
-            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.
-        </para>
-        <para>
-            You can find the files used to describe all the valid features and BSPs in the Yocto Project
-            kernel in any clone of the kernel git tree.  
-            The directory <filename>meta/cfg/kernel-cache/</filename> is a snapshot of all the kernel
-            configuration and feature descriptions (.scc) used to build the kernel repository.
-            You should realize, however, that browsing the snapshot of feature
-            descriptions and patches is not an effective way to determine what is in a
-            particular kernel branch. 
-            Instead, you should use git directly to discover the changes
-            in a branch.
-            Using git is a efficient and flexible way to inspect changes to the kernel.  
-            For examples showing how to use git to inspect kernel commits, see the following sections
-            in this chapter.
-        </para>
-        <note><para>
-            Ground up reconstruction of the complete kernel tree is an action only taken by the 
-            Yocto Project team during an active development cycle.  
-            Creating a project simply clones this tree to make it efficiently available for building
-            and development.
-        </para></note>
-        <para>
-            The general flow for constructing a project-specific kernel tree is as follows:
-        <orderedlist>
-            <listitem><para>A top-level kernel feature is passed to the kernel build subsystem.
-            Normally, this is a BSP for a particular kernel type.</para></listitem>
-
-            <listitem><para>The file that describes the top-level feature is located by searching
-            these system directories:</para>
-
-                <itemizedlist>
-                    <listitem><para>The in-tree kernel-cache directories</para></listitem>
-<!--            <listitem><para>kernel-*-cache directories in layers</para></listitem> -->
-                    <listitem><para>Recipe SRC_URIs</para></listitem>
-<!--            <listitem><para>configured and default templates</para></listitem> -->
-                </itemizedlist>
-
-            <para>For a typical build a feature description of the format:
-            &lt;bsp name&gt;-&lt;kernel type&gt;.scc is the target of the search.
-            </para></listitem>
-
-            <listitem><para>Once located, the feature description is either compiled into a simple script
-            of actions, or an existing equivalent script that was part of the
-            shipped kernel is located.</para></listitem>
-
-            <listitem><para>Extra features are appended to the top-level feature description. 
-            These features can come from the KERNEL_FEATURES variable in recipes.</para></listitem>
-
-            <listitem><para>Each extra feature is located, compiled and appended to the script from
-            step #3</para></listitem>
-
-            <listitem><para>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
-            needs to be applied to the base git repository to completely create the
-            BSP source (build) branch.</para></listitem>
-
-            <listitem><para>The base repository is cloned, and the actions
-            listed in the meta-series are applied to the tree.</para></listitem>
-
-            <listitem><para>The git repository is left with the desired branch checked out and any
-            required branching, patching and tagging has been performed.</para></listitem>
-        </orderedlist>
-        </para>
-
-        <para>
-            The tree is now ready for configuration and compilation. 
-        </para>
-
-        <note><para>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 
-            official Yocto Project kernel repositories is the combination of all
-            supported boards and configurations.</para>
-  
-            <para>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.
-        </para></note>
-
-<!-- <note><para>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:
-    </para>
-    <para>A BSP must create a branch of the format &lt;bsp name&gt;-&lt;kernel type&gt;.</para>
-
-    <para>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.
-    </para>
-</note> -->
-
-<!-- <para>
-A summary of end user tree construction activities follow:
-<itemizedlist>
-    <listitem><para>compile and link a full top-down kernel description from feature descriptions</para></listitem>
-    <listitem><para>execute the complete description to generate a meta-series</para></listitem>
-    <listitem><para>interpret the meta-series to create a customized git repository for the
-    board</para></listitem>
-    <listitem><para>migrate configuration fragments and configure the kernel</para></listitem>
-    <listitem><para>checkout the BSP branch and build</para></listitem>
-</itemizedlist>
-</para> -->
-    </section>
-
-    <section id='build-strategy'>
-        <title>Build Strategy</title>
-        <para>
-            There are some prerequisites that must be met before starting the compilation
-            phase of the kernel build system:
-        </para>
-
-        <itemizedlist>
-            <listitem><para>There must be a kernel git repository indicated in the SRC_URI.</para></listitem>
-            <listitem><para>There must be a BSP build branch - &lt;bsp name&gt;-&lt;kernel type&gt; in 0.9 or 
-            &lt;kernel type&gt;/&lt;bsp name&gt; in 1.0.</para></listitem>
-        </itemizedlist>
-
-        <para>
-            You can typically meet these prerequisites by running the tree construction/patching phase 
-            of the build system.
-            However, other means do exist.
-            For examples of alternate workflows such as bootstrapping a BSP, see 
-            the<link linkend='workflow-examples'> Workflow Examples</link> section in this manual.
-        </para>
-
-        <para>
-            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