diff --git a/documentation/kernel-dev/kernel-dev-maint-appx.xml b/documentation/kernel-dev/kernel-dev-maint-appx.xml
index 9e6fa99998..4575c90df9 100644
--- a/documentation/kernel-dev/kernel-dev-maint-appx.xml
+++ b/documentation/kernel-dev/kernel-dev-maint-appx.xml
@@ -22,11 +22,13 @@
Those feature descriptions list all necessary patches,
configurations, branches, tags, and feature divisions found in a
Yocto Linux kernel.
- Thus, the Yocto Project Linux kernel repository (or tree) is built.
+ Thus, the Yocto Project Linux kernel repository (or tree) and
+ accompanying Metadata in the
+ yocto-kernel-cache are built.
- The existence of this tree allows you to access and clone a
+ The existence of these repositories allow you to access and clone a
particular Yocto Project Linux kernel repository and use it to
build images based on their configurations and features.
@@ -34,12 +36,16 @@
You can find the files used to describe all the valid features and
BSPs in the Yocto Project Linux kernel in any clone of the Yocto
- Project Linux kernel source repository Git tree.
- For example, the following command clones the Yocto Project
+ Project Linux kernel source repository and
+ yocto-kernel-cache Git trees.
+ For example, the following commands clone the Yocto Project
baseline Linux kernel that branches off
- linux.org version 4.12:
+ linux.org version 4.12 and the
+ yocto-kernel-cache, which contains stores of
+ kernel Metadata:
$ git clone git://git.yoctoproject.org/linux-yocto-4.12
+ $ git clone git://git.yoctoproject.org/linux-kernel-cache
For more information on how to set up a local Git repository of
the Yocto Project Linux kernel files, see the
@@ -48,25 +54,33 @@
- Once you have cloned the kernel Git repository on your local
- machine, you can discover the branches that are avilable in the
- repository using the following Git command:
+ Once you have cloned the kernel Git repository and the
+ cache of Metadata on your local machine, you can discover the
+ branches that are avilable in the repository using the following
+ Git command:
$ git branch -a
Checking out a branch allows you to work with a particular
Yocto Linux kernel.
- For example, the following command checks out the
- standard/beagleboard branch of the
- repository:
+ For example, the following commands check out the
+ "standard/beagleboard" branch of the Yocto Linux kernel repository
+ and the "yocto-4.12" branch of the
+ yocto-kernel-cache repository:
- $ cd linux-yocto-4.12
- $ git checkout -b my-kernel-4.12 standard/beagleboard
+ $ cd ~/linux-yocto-4.12
+ $ git checkout -b my-kernel-4.12 remotes/origin/standard/beagleboard
+ $ cd ~/linux-kernel-cache
+ $ git checkout -b my-4.12-metadata remotes/origin/yocto-4.12
- Once you have checked out and switched to the
- standard/beagleboard branch,
+
+ Branches in the yocto-kernel-cache
+ repository correspond to Yocto Linux kernel versions
+ (e.g. "yocto-4.12", "yocto-4.10", "yocto-4.9", and so forth).
+
+ Once you have checked out and switched to appropriate branches,
you can see a snapshot of all the kernel source files used to
- used to build that particular Yocto Linux kernel for that
+ used to build that particular Yocto Linux kernel for a
particular board.
@@ -74,9 +88,9 @@
To see the features and configurations for a particular Yocto
Linux kernel, you need to examine the
yocto-kernel-cache Git repository.
- Branches in the yocto-kernel-cache repository
- correspond to Yocto Linux kernel versions (e.g.
- yocto-4.12).
+ As mentioned, branches in the
+ yocto-kernel-cache repository correspond to
+ Yocto Linux kernel versions (e.g. yocto-4.12).
Branches contain descriptions in the form of
.scc and .cfg files.
@@ -106,77 +120,106 @@
(or tree) found at
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:
+ These are the actions that effectively provide the Metadata
+ and create the tree that includes the new feature, patch or BSP:
+ Pass Feature to Build Subsystem:
A top-level kernel feature is passed to the kernel build
subsystem.
Normally, this feature is a BSP for a particular kernel
type.
+ Locate Feature:
The file that describes the top-level feature is located
by searching these system directories:
The in-tree kernel-cache directories, which are
- located in
- yocto-kernel-cache/cfg/kernel-cache
+ located in the
+ yocto-kernel-cache
+ repository
Areas pointed to by SRC_URI
- statements found in recipes
+ statements found in kernel recipes
For a typical build, the target of the search is a
feature description in an .scc file
whose name follows this format:
-
-
-I AM HERE
-
-
-
bsp_name-kernel_type.scc
- 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.
+
+ Compile Feature:
+ 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.
+
+
+ Append Extra Features:
+ 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
- as described in step three.
- The script is executed to produce a series of meta-*
- directories.
- These directories are descriptions 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-* directories 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.
+ variable in recipes.
+
+
+ Locate, Compile, and Append Each Feature:
+ Each extra feature is located, compiled and appended to
+ the script as described in step three.
+
+
+ Execute the Script:
+ The script is executed to produce files
+ .scc and .cfg
+ files in appropriate directories of the
+ yocto-kernel-cache repository.
+ These files are descriptions 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.
+
+
+ Clone Base Repository:
+ The base repository is cloned, and the actions
+ listed in the yocto-kernel-cache
+ irectories are applied to the tree.
+
+
+ Perform Cleanup:
+ The Git repositories are left with the desired branches
+ checked out and any required branching, patching and
+ tagging has been performed.
+
+
- The kernel tree is now ready for developer consumption to be locally cloned,
- configured, and built into a Yocto Project kernel specific to some target hardware.
- The generated meta-* directories add 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 kernel tree and cache are ready for developer consumption to
+ be locally cloned, configured, and built into a Yocto Project
+ kernel specific to some target hardware.
+
+ The generated yocto-kernel-cache
+ repository 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 at
http://git.yoctoproject.org/cgit.cgi
- is the combination of all supported boards and configurations.
- The technique the Yocto Project team uses is flexible and allows for seamless
- blending of an immutable history with additional patches specific to a
- deployment.
- Any additions to the kernel become an integrated part of the branches.
+ is the combination of all supported boards and configurations.
+
+
+ The technique the Yocto Project team uses is flexible
+ and allows for seamless blending of an immutable history with
+ additional patches specific to a deployment.
+ Any additions to the kernel become an integrated part of the
+ branches.