kernel-dev: Edits to the introduction chapter.

I did some re-writing for better understanding based on what I
know.

(From yocto-docs rev: fc3adb037ac07a90dfbba6b76643391480e0bce5)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

documentation/kernel-dev/kernel-dev-advanced.xml

@@ -7,14 +7,14 @@
 <title>Working with Advanced Metadata</title>
 
     <para>
-        In addition to configuration fragments and patches, the
+        In addition to supporting configuration fragments and patches, the
-        Yocto Project kernel tools support rich metadata that you can
+        Yocto Project kernel tools also support rich
-        use to define complex policies and BSP support.
+        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> that you can
-        The purpose of the metadata and the tools to manage it, known as
+        use to define complex policies and Board Support Package (BSP) support.
+        The purpose of the Metadata and the tools that manage it, known as
         the kern-tools (<filename>kern-tools-native_git.bb</filename>), is
-        to assist in managing the complexity of the configuration and sources
+        to help you manage the complexity of the configuration and sources
-        in support of multiple Board Support Packages (BSPs) and Linux kernel
+        used to support multiple BSPs and Linux kernel types.
-        types.
     </para>
 
     <para>
@@ -602,7 +602,7 @@ git repository:
         or <filename>meta/cfg/kernel-cache/</filename> if you are creating
         metadata in-tree as described in
         the "<link linkend='in-tree-metadata'>In-Tree Metadata</link>" section.
-    </para>            
+    </para>
 
     <para>
         Original text:
@@ -920,12 +920,12 @@ will want to specify in the KERNEL_FEATURES variable of the Linux kernel recipe
             <literallayout class='monospaced'>
      # Include this kernel type fragment to get the standard features and
      # configuration values.
-	
+
      # Include all standard features
      include standard-nocfg.scc
-	
+
      kconf non-hardware standard.cfg
-	
+
      # individual cfg block section
      include cfg/fs/devtmpfs.scc
      include cfg/fs/debugfs.scc
@@ -933,7 +933,7 @@ will want to specify in the KERNEL_FEATURES variable of the Linux kernel recipe
      include cfg/fs/ext2.scc
      include cfg/fs/ext3.scc
      include cfg/fs/ext4.scc
-	
+
      include cfg/net/ipv6.scc
      include cfg/net/ip_nf.scc
      include cfg/net/ip6_nf.scc
@@ -967,7 +967,7 @@ fragments together with any patches you want to use for all Linux kernel builds
 of the specified ktype. In short, ktypes are where you define a high-level
 kernel policy. Syntactically, however, they are no different than features (see
 3.3.3).  preempt-rt, and tiny. The ktype is selected by the LINUX_KERNEL_TYPE
-variable in the recipe (see 3.1). 
+variable in the recipe (see 3.1).
 
 By way of example, the linux-yocto-3.4 tree defines three ktypes: standard,
 tiny, and preempt-rt. The standard kernel type includes the generic Linux kernel
@@ -983,12 +983,12 @@ not currently include any source changes, but it may in the future.
 The standard ktype is defined by standard.scc:
 	# Include this kernel type fragment to get the standard features and
 	# configuration values.
-	
+
 	# Include all standard features
 	include standard-nocfg.scc
-	
+
 	kconf non-hardware standard.cfg
-	
+
 	# individual cfg block section
 	include cfg/fs/devtmpfs.scc
 	include cfg/fs/debugfs.scc
@@ -996,7 +996,7 @@ The standard ktype is defined by standard.scc:
 	include cfg/fs/ext2.scc
 	include cfg/fs/ext3.scc
 	include cfg/fs/ext4.scc
-	
+
 	include cfg/net/ipv6.scc
 	include cfg/net/ip_nf.scc
 	include cfg/net/ip6_nf.scc
@@ -1092,7 +1092,7 @@ Note: It is not strictly necessary to create a ktype scc file. The BSP file can
             <literallayout class='monospaced'>
      fri2.scc:
         kconf hardware fri2.cfg
-	
+
         include cfg/x86.scc
         include features/eg20t/eg20t.scc
         include cfg/dmaengine.scc
@@ -1119,19 +1119,19 @@ Note: It is not strictly necessary to create a ktype scc file. The BSP file can
         define KMACHINE fri2
         define KTYPE standard
         define KARCH i386
-	
+
         include ktypes/standard/standard.scc
         branch fri2
-	
+
         git merge emgd-1.14
-	
+
         include fri2.scc
-	
+
         # Extra fri2 configs above the minimal defined in fri2.scc
         include cfg/efi-ext.scc
         include features/drm-emgd/drm-emgd.scc
         include cfg/vesafb.scc
-	
+
         # default policy for standard kernels
         include cfg/usb-mass-storage.scc
             </literallayout>
@@ -1162,10 +1162,10 @@ Note: It is not strictly necessary to create a ktype scc file. The BSP file can
         define KMACHINE fri2
         define KTYPE tiny
         define KARCH i386
-	
+
         include ktypes/tiny/tiny.scc
         branch fri2
-	
+
         include fri2.scc
             </literallayout>
             As you might expect, the tiny description includes quite a bit less.
@@ -1236,7 +1236,7 @@ BSP definitions from the linux-yocto-3.4 repository:
 
 fri2.scc:
 	kconf hardware fri2.cfg
-	
+
 	include cfg/x86.scc
 	include features/eg20t/eg20t.scc
 	include cfg/dmaengine.scc
@@ -1257,19 +1257,19 @@ fri2-standard.scc:
 	define KMACHINE fri2
 	define KTYPE standard
 	define KARCH i386
-	
+
 	include ktypes/standard/standard.scc
 	branch fri2
-	
+
 	git merge emgd-1.14
-	
+
 	include fri2.scc
-	
+
 	# Extra fri2 configs above the minimal defined in fri2.scc
 	include cfg/efi-ext.scc
 	include features/drm-emgd/drm-emgd.scc
 	include cfg/vesafb.scc
-	
+
 	# default policy for standard kernels
 	include cfg/usb-mass-storage.scc
 
@@ -1291,10 +1291,10 @@ fri2-tiny.scc:
 	define KMACHINE fri2
 	define KTYPE tiny
 	define KARCH i386
-	
+
 	include ktypes/tiny/tiny.scc
 	branch fri2
-	
+
 	include fri2.scc
 
 As you might expect, the tiny description includes quite a bit less. In fact,
@@ -1435,9 +1435,9 @@ include them in the BSP description for the board(s) that require them (see
 Alternatively, you can create a branch in your Linux kernel sources and apply
 the patches there. You can then specify this new branch as the KBRANCH to use
 for this board. You can do this in the recipe with the KBRANCH variable:
-	
+
 	KBRANCH = "mynewbranch"
-	
+
 or in the BSP description using the "branch" command:
 
 mybsp.scc:

documentation/kernel-dev/kernel-dev-intro.xml

@@ -3,44 +3,69 @@
 [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='kernel-dev-intro'>
-
 <title>Introduction</title>
 
-    <para>
+    <section id='kernel-dev-overview'>
-        Regardless of how you intend to make use of the Yocto Project,
+        <title>Overview</title>
-        chances are you are going to need to work with the Linux kernel.
-        The Yocto Project provides a powerful set of tools for managing
-        Linux kernel sources and configuration data.
-        You can use this tooling to help you make a single configuration change,
-        apply a couple of patches, or work with your own sources.
-    </para>
-
-    <para>
-        The Yocto Project Kernel Development Manual describes common tasks
-        you can perform using the kernel tooling as well as provides information
-        about the metadata needed to work with the kernel inside the
-        Yocto Project.
-    </para>
-
-    <section id='kernel-dev-background'>
-        <title>Background</title>
 
         <para>
-            Each Yocto Project release introduces a new set of linux-yocto
+            Regardless of how you intend to make use of the Yocto Project,
-            kernel recipes that tracks the latest upstream developments and
+            chances are you will work with the Linux kernel.
-            introduces newly supported platforms.
+            This manual provides background information on the Yocto Linux kernel
-            In addition to the new kernel recipes, the previous recipes are
+            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>,
-            refreshed and supported for at least one additional release.
+            describes common tasks you can perform using the kernel tools,
+            and shows you how to use the Metadata needed to work with
+            the kernel inside the Yocto Project.
+       </para>
+
+       <para>
+            Each Yocto Project release has a set of linux-yocto recipes, whose
+            Git repositories you can view in the Yocto
+            <ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink> under
+            the "Yocto Linux Kernel" heading.
+            New recipes for the release track the latest upstream developments
+            and introduce newly supported platforms.
+            Previous recipes in the release are refreshed and supported for at
+            least one additional release.
             As they align, these previous releases are updated to include the
             latest from the Long Term Support Initiative (LTSI) project.
-            Besides these recipes, a <filename>linux-yocto-dev.bb</filename>
+            Also included is a linux-yocto development recipe
-            recipe is available for working with the very latest in upstream
+            (<filename>linux-yocto-dev.bb</filename>) should you want to work
-            Linux kernel development as well as metadata development.
+            with the very latest in upstream Linux kernel development and
+            Metadata development.
+        </para>
+
+        <para>
+            The Yocto Project also provides a powerful set of kernel
+            tools for managing Linux kernel sources and configuration data.
+            You can use these tools to make a single configuration change,
+            apply multiple patches, or work with your own kernel sources.
+        </para>
+
+        <para>
+            In particular, the kernel tools allow you to generate configuration
+            fragments that specify only what you must, and nothing more.
+            Configuration fragments only need to contain the highest level
+            visible <filename>CONFIG</filename> options as presented by the Linux
+            kernel <filename>menuconfig</filename> system.
+            Contrast this against a complete Linux kernel
+            <filename>.config</filename>, which includes all the automatically
+            selected <filename>CONFIG</filename> options.
+            This efficiency reduces your maintenance effort and allows you
+            to further separate your configuration in ways that make sense for
+            your project.
+            A common split separates policy and hardware.
+            For example, all your kernels might support
+            the <filename>proc</filename> and <filename>sys</filename> filesystems,
+            but only specific boards require sound, USB, or specific drivers.
+            Specifying these configurations individually allows you to aggregate
+            them together as needed, but maintains them in only one place.
+            Similar logic applies to separating source changes.
         </para>
 
         <para>
             If you do not maintain your own kernel sources and need to make
-            only minimal changes to the sources, these recipes provide a
+            only minimal changes to the sources, the released recipes provide a
             vetted base upon which to layer your changes.
             Doing so allows you to benefit from the continual kernel
             integration and testing performed during development of the
@@ -50,8 +75,8 @@
         <para>
             If, instead, you have a very specific Linux kernel source tree
             and are unable to align with one of the many official linux-yocto
-            releases, an alternative exists by which you can use the Yocto
+            recipes, an alternative exists by which you can use the Yocto
-            Project Linux kernel tools with your own sources.
+            Project Linux kernel tools with your own kernel sources.
         </para>
     </section>
 
@@ -61,7 +86,7 @@
         <para>
             The sections that follow provide instructions for completing
             specific Linux kernel development tasks.
-            These instructions assume you are familiar with working with
+            These instructions assume you are comfortable working with
             <ulink url='http://developer.berlios.de/projects/bitbake/'>BitBake</ulink>
             recipes and basic open-source development tools.
             Understanding these concepts will facilitate the process of working