4 files changed, 92 insertions, 100 deletions

diff --git a/documentation/Makefile b/documentation/Makefile
index 3c02a3c2f0..a761c19dba 100644
--- a/documentation/Makefile
+++ b/documentation/Makefile
@@ -131,7 +131,7 @@ TARFILES = dev-style.css dev-manual.html \
 TARFILES = dev-style.css dev-manual.html \
            figures/dev-title.png \
            figures/kernel-dev-flow.png \
-           figures/kernel-overview-1.png figures/kernel-overview-2-generic.png \
+           figures/kernel-overview-2-generic.png \
            figures/recipe-workflow.png \
            figures/devtool-add-flow.png figures/devtool-modify-flow.png \
            figures/devtool-upgrade-flow.png \
@@ -205,7 +205,7 @@ TARFILES = mega-manual.html mega-style.css figures/yocto-environment.png \
         figures/dev-title.png \
         figures/git-workflow.png figures/index-downloads.png \
         figures/kernel-dev-flow.png \
-        figures/kernel-overview-1.png figures/kernel-overview-2-generic.png \
+        figures/kernel-overview-2-generic.png \
         figures/source-repos.png figures/yp-download.png \
         figures/profile-title.png figures/kernelshark-all.png \
         figures/kernelshark-choose-events.png \
diff --git a/documentation/dev-manual/dev-manual-model.xml b/documentation/dev-manual/dev-manual-model.xml
index bd6a85b987..05ff369f5d 100644
--- a/documentation/dev-manual/dev-manual-model.xml
+++ b/documentation/dev-manual/dev-manual-model.xml
@@ -86,67 +86,26 @@
             <title>Kernel Overview</title>
 
             <para>
-                The kernels are maintained using the Git revision control system
-                that structures them using the familiar "tree", "branch", and "leaf" scheme.
-                Branches represent diversions from general code to more specific code, while leaves
-                represent the end-points for a complete and unique kernel whose source files,
-                when gathered from the root of the tree to the leaf, accumulate to create the files
-                necessary for a specific piece of hardware and its features.
-                The following figure displays this concept:
-            <para>
-                <imagedata fileref="figures/kernel-overview-1.png"
-                    width="6in" depth="6in" align="center" scale="100" />
-            </para>
-
-            <para>
-                Within the figure, the "Kernel.org Branch Point" represents the point in the tree
-                where a supported base kernel is modified from the Linux kernel.
-                For example, this could be the branch point for the <filename>linux-yocto-3.19</filename>
-                kernel.
-                Thus, everything further to the right in the structure is based on the
-                <filename>linux-yocto-3.19</filename> kernel.
-                Branch points to the right in the figure represent where the
-                <filename>linux-yocto-3.19</filename> kernel is modified for specific hardware
-                or types of kernels, such as real-time kernels.
-                Each leaf thus represents the end-point for a kernel designed to run on a specific
-                targeted device.
-            </para>
-
-            <para>
-                The overall result is a Git-maintained repository from which all the supported
-                kernel types can be derived for all the supported devices.
-                A big advantage to this scheme is the sharing of common features by keeping them in
-                "larger" branches within the tree.
-                This practice eliminates redundant storage of similar features shared among kernels.
-            </para>
-
-            <note>
-                Keep in mind the figure does not take into account all the supported Yocto
-                Project kernel types, but rather shows a single generic kernel just for conceptual purposes.
-                Also keep in mind that this structure represents the Yocto Project source repositories
-                that are either pulled from during the build or established on the host development system
-                prior to the build by either cloning a particular kernel's Git repository or by
-                downloading and unpacking a tarball.
-            </note>
-
-            <para>
-                Upstream storage of all the available kernel source code is one thing, while
-                representing and using the code on your host development system is another.
-                Conceptually, you can think of the kernel source repositories as all the
-                source files necessary for all the supported kernels.
-                As a developer, you are just interested in the source files for the kernel on
-                which you are working.
+                Upstream storage of all the available kernel source code is
+                one thing, while representing and using the code on your host
+                development system is another.
+                Conceptually, you can think of the kernel source repositories
+                as all the source files necessary for all the supported
+                Yocto Linux kernels.
+                As a developer, you are just interested in the source files
+                for the kernel on which you are working.
                 And, furthermore, you need them available on your host system.
             </para>
 
             <para>
-                Kernel source code is available on your host system a couple of different
-                ways.
-                If you are working in the kernel all the time, you probably would want
-                to set up your own local Git repository of the kernel tree.
-                If you just need to make some patches to the kernel, you can access
-                temporary kernel source files that were extracted and used
-                during a build.
+                Kernel source code is available on your host system a couple
+                of different ways.
+                If you are working in the kernel all the time, you probably
+                would want to set up your own local Git repository of the
+                Yocto Linux kernel tree.
+                If you just need to make some patches to the kernel, you can
+                access temporary kernel source files that were extracted and
+                used during a build.
                 We will just talk about working with the temporary source code.
                 For more information on how to get kernel source code onto your
                 host system, see the
@@ -164,6 +123,8 @@
                 Thus, in a sense, the process constructs a local source tree specific to your
                 kernel to generate the new kernel image - a source generator if you will.
             </para>
+
+            <para>
                 The following figure shows the temporary file structure
                 created on your host system when the build occurs.
                 This
diff --git a/documentation/dev-manual/figures/kernel-overview-1.png b/documentation/dev-manual/figures/kernel-overview-1.png
deleted file mode 100644
index 116c0b9bd4..0000000000
--- a/documentation/dev-manual/figures/kernel-overview-1.png
+++ /dev/null
diff --git a/documentation/kernel-dev/kernel-dev-concepts-appx.xml b/documentation/kernel-dev/kernel-dev-concepts-appx.xml
index 3606301cc7..ee40938b5d 100644
--- a/documentation/kernel-dev/kernel-dev-concepts-appx.xml
+++ b/documentation/kernel-dev/kernel-dev-concepts-appx.xml
@@ -175,74 +175,105 @@
 
     <section id='kernel-architecture'>
         <title>Kernel Architecture</title>
+
         <para>
-            This section describes the architecture of the kernels available through the
-            Yocto Project and provides information
+            This section describes the architecture of the Yocto Linux kernels
+            available through the Yocto Project 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 the 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 <filename>kernel.org</filename>.
+                As mentioned earlier, a key goal of the 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 upstream Linux kernel development in
+                <filename>kernel.org</filename>.
             </para>
+
             <para>
-                You can think of a Yocto Project kernel as consisting of a baseline Linux 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
+                You can think of a Yocto Linux kernel as consisting of a
+                baseline Linux 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 Yocto Project team using the
                 source code manager (SCM) Git.
                 For information on Git as applied to the Yocto Project, see the
-                "<ulink url='&YOCTO_DOCS_REF_URL;#git'>Git</ulink>" section in the
-                Yocto Project Development Manual.
-            </para>
-            <para>
-                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.
+                "<ulink url='&YOCTO_DOCS_REF_URL;#git'>Git</ulink>" section
+                in the Yocto Project Development Manual.
             </para>
+
             <para>
-                The following illustration shows the conceptual Yocto Project kernel.
+                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
+                Linux kernel.
             </para>
+
             <para>
+                The following illustration shows the conceptual Yocto
+                Linux kernel.
                 <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.
+                In the illustration, the "Kernel.org Branch Point" marks the
+                specific spot (or Linux kernel release) from which the
+                Yocto Linux kernel is created.
+                From this point forward 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 do not have to be duplicated along individual branches of the
-                structure.
+                The "Yocto Project Baseline Kernel" contains functionality that
+                is common to every kernel type and BSP that is organized
+                further along in the tree.
+                Placing these common features in the tree this way means
+                features do not have to be duplicated along individual
+                branches of the tree 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.
+                From the Yocto Project Baseline Kernel, branch points represent
+                specific functionality for individual Board Support Packages
+                (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 for a real-time Yocto Linux 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.
+                In this example structure, the real-time kernel branch has
+                common features for all real-time Yocto Linux 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.
+                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
-                developer that, for all practical purposes, is the kernel needed for any given set
-                of requirements.
+                The resulting tree structure presents a clear path of markers
+                (or branches) to the developer that, for all practical
+                purposes, is the Yocto Linux kernel needed for any given set of
+                requirements.
+                <note>
+                    Keep in mind the figure does not take into account all the
+                    supported Yocto Linux kernels, but rather shows a single
+                    generic kernel just for conceptual purposes.
+                    Also keep in mind that this structure represents the Yocto
+                    Project
+                    <ulink url='&YOCTO_DOCS_REF_URL;#source-repositories'>Source Repositories</ulink>
+                    that are either pulled from during the build or established
+                    on the host development system prior to the build by either
+                    cloning a particular kernel's Git repository or by
+                    downloading and unpacking a tarball.
+                </note>
             </para>
         </section>