diff --git a/documentation/kernel-manual/kernel-how-to.xml b/documentation/kernel-manual/kernel-how-to.xml
index 852fbb1a90..bf45ae1729 100644
--- a/documentation/kernel-manual/kernel-how-to.xml
+++ b/documentation/kernel-manual/kernel-how-to.xml
@@ -40,12 +40,24 @@
in the product.
Those feature descriptions list all necessary patches,
configuration, branching, tagging and feature divisions found in the kernel.
+ Thus, the Yocto Project kernel repository (or tree) is built.
+ The existence of this tree allows you to build images based on your configurations
+ and features.
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 meta/cfg/kernel-cache/ is a snapshot of all the kernel
- configuration and feature descriptions (.scc) used to build the kernel repository.
+ kernel in any clone of the kernel Git tree.
+ For example, the following command clones the Yocto Project baseline kernel that
+ branched off of linux.org version 2.6.37:
+
+ $ git clone http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37
+
+ After you switch to the meta branch within the repository
+ you can see a snapshot of all the kernel configuration and feature descriptions that are
+ used to build the kernel repository.
+ These descriptions are in the form of .scc files.
+
+
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.
@@ -62,46 +74,56 @@
and development.
- The general flow for constructing a project-specific kernel tree 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 following steps describe what happens during tree construction given the introduction
+ of a new top-level kernel feature or BSP.
+ These are the actions that effectively create the tree that includes the new feature, patch,
+ or BSP:
+
+ 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
- these system directories:
+ The file that describes the top-level feature is located by searching
+ these system directories:
-
- The in-tree kernel-cache directories
+
+ The in-tree kernel-cache directories, which are located
+ in meta/cfg/kernel-cache
- Recipe SRC_URIs
+ Areas pointed to by SRC_URI statements
+ found in recipes
-
+
- For a typical build a feature description of the format:
- <bsp name>-<kernel type>.scc is the target of the search.
-
+ For a typical build, the target of the search is a
+ feature description in an .scc file
+ whose name follows this format:
+
+ <bsp_name>-<kernel_type>.scc
+
+
- 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.
+ Once located, the feature description is either compiled into a simple script
+ of actions, or into an existing equivalent script that is already part of the
+ shipped kernel.
- Extra features are appended to the top-level feature description.
- These features can come from the KERNEL_FEATURES variable in recipes.
+ Extra features are appended to the top-level feature description.
+ These features can come from the KERNEL_FEATURES variable in
+ recipes.
- Each extra feature is located, compiled and appended to the script from
- step #3
+ Each extra feature is located, compiled and appended to the script
+ as described in step three.
- The script is executed, and a meta-series is produced.
- The meta-series is a description of all the branches, tags, patches and configurations that
- need to be applied to the base Git repository to completely create the
- BSP source (build) branch.
+ The script is executed to produce a meta-series.
+ The meta-series is a description of all the branches, tags, patches and configurations that
+ need to be applied to the base Git repository to completely create the
+ source (build) branch for the new BSP or feature.
- The base repository is cloned, and the actions
- listed in the meta-series are applied to the tree.
+ The base repository 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 Git repository is left with the desired branch checked out and any
+ required branching, patching and tagging has been performed.
+