From 5b10a72004e3474bbab7fe7f0474b40f45e9aed8 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Wed, 24 Nov 2010 13:23:46 -0800 Subject: documentation/kernel-manual/yocto-project-kernel-manual.xml: Removed sections not fit for 0.9 release. These sections were commented out after a review by Bruce Ashfield. They need to be revisited as we continue with the 1.0 work. Signed-off-by: Scott Rifenbark --- .../kernel-manual/yocto-project-kernel-manual.xml | 94 +++++++++++----------- 1 file changed, 47 insertions(+), 47 deletions(-) (limited to 'documentation') diff --git a/documentation/kernel-manual/yocto-project-kernel-manual.xml b/documentation/kernel-manual/yocto-project-kernel-manual.xml index b1693500fc..6d93975019 100644 --- a/documentation/kernel-manual/yocto-project-kernel-manual.xml +++ b/documentation/kernel-manual/yocto-project-kernel-manual.xml @@ -332,7 +332,7 @@ kernel are: the presentation of a seamless git repository that blends Yocto Project value with the kernel.org history and development - + @@ -367,18 +367,18 @@ kernel toolkit: Tree construction Build strategies - Series & Configuration Compiler - kgit + Workflow examples Source Code Manager (SCM) - Board Support Package (BSP) template migration + BSP creation Patching Updating BSP patches and configuration - guilt - scc file example + "dirty" string - Transition kernel layer + @@ -404,7 +404,7 @@ following sections. As a reminder, it is envisioned that a ground up reconstruction of the -complete kernel tree is an action only taken by Yocto Project staff during an +complete kernel tree is an action only taken by Yocto Project team during an active development cycle. When an end user creates a project, it takes advantage of this complete tree in order to efficiently place a git tree within their project. @@ -420,8 +420,9 @@ The general flow of the project specific kernel tree construction is as follows: the kernel-cache under linux/wrs/cfg/kernel-cache - kernel-*-cache directories in layers - configured and default templates + + recipe SRC_URIs + In a typical build a feature description of the format: @@ -433,8 +434,7 @@ The general flow of the project specific kernel tree construction is as follows: shipped kernel is located. extra features are appended to the top level feature description. Extra - features can come from the command line, the configure script or - templates. + features can come from the KERNEL_FEATURES variable in recipes. each extra feature is located, compiled and appended to the script from step #3 @@ -444,7 +444,7 @@ The general flow of the project specific kernel tree construction is as follows: need to be applied to the base git repository to completely create the "bsp_name-kernel_type". - the base repository (normally kernel.org) is cloned, and the actions + 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 @@ -470,7 +470,7 @@ history with additional deployment specific patches. Any additions to the kernel become an integrated part of the branches. -It is key that feature descriptions indicate if any branches are + A summary of end user tree construction activities follow: @@ -532,8 +532,7 @@ relevant values from the board template, and a kernel image is produced. The other thing that you will first see once you configure a kernel is that it will generate a build tree that is separate from your git source tree. This build dir will be called "linux-<BSPname>-<kerntype>-build" where -kerntype is one of standard, cg`` -e, etc. This functionality is done by making +kerntype is one of standard kernel types. This functionality is done by making use of the existing support that is within the kernel.org tree by default. @@ -545,7 +544,7 @@ has their own separate build directory. -
+ -
+
Workflow Examples @@ -724,7 +723,7 @@ This section contains several workflow examples. A common question when working with a BSP/kernel is: "What changes have been applied to this tree?" -In previous Yocto Project releases, there were a collection of directories that +In some projects, where a collection of directories that contained patches to the kernel, those patches could be inspected, grep'd or otherwise used to get a general feeling for changes. This sort of patch inspection is not an efficient way to determine what has been done to the @@ -981,10 +980,10 @@ preserved. Note that new commit IDs will be generated upon reapplication, reflecting that the commit is now applied to an underlying commit with a different ID. - +
@@ -998,7 +997,7 @@ same change can then be pulled into a new kernel build at a later time using thi For example: - > push ssh://openlinux.windriver.com/pub/git/kernel-2.6.27 common_pc-standard:common_pc-standard + > push ssh://git.mycompany.com/pub/git/kernel-2.6.27 common_pc-standard:common_pc-standard A pull request entails using "git request-pull" to compose an email to the maintainer requesting that a branch be pulled into the master repository, see @@ -1136,14 +1135,15 @@ Once development has reached a suitable point in the second development environment, changes can either be exported as patches or imported into git directly (if a conversion/import mechanism is available for the SCM). -If changes are exported as patches, they can be placed in a template and -automatically applied to the kernel during patching. See the template patch -example for details. +If changes are exported as patches, they can be placed in a recipe and +automatically applied to the kernel during patching. +
-
+
-
+
BSP: Creating a New BSP @@ -1326,7 +1326,7 @@ development.
-
+ -
+
-
+
"-dirty" String @@ -1995,7 +1995,7 @@ integrated and validated Yocto Project kernel. The next few sections describe the process: -
+ -
+ -
+ -
+
-- cgit v1.2.3-54-g00ecf