From 5c44309cfed33a121f0e046ace4af687f3359c16 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Wed, 15 Aug 2012 14:18:51 -0700 Subject: documentation/kernel-manual: Fixed minor problems I did a read-through of the manual and spotted several nits that I fixed. All these are minor fixes. (From yocto-docs rev: 0c8f9c660ecea0b36e2b6af0315d3d239f70a688) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/kernel-manual/kernel-concepts.xml | 12 +-- documentation/kernel-manual/kernel-doc-intro.xml | 2 +- documentation/kernel-manual/kernel-how-to.xml | 95 ++++++++++++------------ 3 files changed, 55 insertions(+), 54 deletions(-) (limited to 'documentation/kernel-manual') diff --git a/documentation/kernel-manual/kernel-concepts.xml b/documentation/kernel-manual/kernel-concepts.xml index fce6bfbffe..8b9e71ff96 100644 --- a/documentation/kernel-manual/kernel-concepts.xml +++ b/documentation/kernel-manual/kernel-concepts.xml @@ -24,7 +24,7 @@ The complexity of embedded kernel design has increased dramatically. Whether it is managing multiple implementations of a particular feature or tuning and - optimizing board specific features, flexibility and maintainability are key concerns. + optimizing board specific features, both flexibility and maintainability are key concerns. The Linux kernels available through the Yocto Project are presented with the embedded developer's needs in mind and have evolved to assist in these key concerns. For example, prior methods such as applying hundreds of patches to an extracted @@ -45,7 +45,7 @@ management techniques. Deliver the most up-to-date kernel possible while still ensuring that the baseline kernel is the most stable official release. - Include major technological features as part of Yocto Project's + Include major technological features as part of the Yocto Project's upward revision strategy. Present a kernel Git repository that, similar to the upstream kernel.org tree, @@ -86,7 +86,7 @@ The ultimate source for kernels available through the Yocto Project are released kernels from kernel.org. In addition to a foundational kernel from kernel.org, the - kernels available through the contain a mix of important new mainline + kernels available contain a mix of important new mainline developments, non-mainline developments (when there is no alternative), Board Support Package (BSP) developments, and custom features. @@ -255,7 +255,7 @@ In other words, the divisions of the kernel are transparent and are not relevant to the developer on a day-to-day basis. From the developer's perspective, this path is the "master" branch. - The developer does not need not be aware of the existence of any other branches at all. + The developer does not need to be aware of the existence of any other branches at all. Of course, there is value in the existence of these branches in the tree, should a person decide to explore them. For example, a comparison between two BSPs at either the commit level or at the line-by-line @@ -293,7 +293,7 @@ "Git" section in the Yocto Project Development Manual. These referenced sections overview Git and describe a minimal set of - commands that allow you to be functional using Git. + commands that allows you to be functional using Git. You can use as much, or as little, of what Git has to offer to accomplish what you need for your project. @@ -345,7 +345,7 @@ You can see how menuconfig is used to change a simple kernel configuration in the "Changing the  CONFIG_SMP Configuration Using  menuconfig" - section of The Yocto Project Development Manual. + section of the Yocto Project Development Manual. For general information on menuconfig, see . diff --git a/documentation/kernel-manual/kernel-doc-intro.xml b/documentation/kernel-manual/kernel-doc-intro.xml index 86dcdb6000..3eec4a6523 100644 --- a/documentation/kernel-manual/kernel-doc-intro.xml +++ b/documentation/kernel-manual/kernel-doc-intro.xml @@ -47,7 +47,7 @@ For more discussion on the Yocto Project kernel, you can see these sections - in The Yocto Project Development Manual: + in the Yocto Project Development Manual: "Kernel Overview" diff --git a/documentation/kernel-manual/kernel-how-to.xml b/documentation/kernel-manual/kernel-how-to.xml index b1916420d6..4086f55c37 100644 --- a/documentation/kernel-manual/kernel-how-to.xml +++ b/documentation/kernel-manual/kernel-how-to.xml @@ -27,7 +27,7 @@ This section describes construction of the Yocto Project kernel source repositories as accomplished by the Yocto Project team to create kernel repositories. - These kernel repositories are found at + These kernel repositories are found under the heading "Yocto Linux Kernel" at &YOCTO_GIT_URL;/cgit.cgi and can be shipped as part of a Yocto Project release. The team creates these repositories by @@ -53,8 +53,8 @@ For another example of how to set up a local Git repository of the Yocto Project kernel files, see the - "Linux Yocto Kernel" bulleted - item in The Yocto Project Development Manual. + "Yocto Project Kernel" bulleted + item in the Yocto Project Development Manual. Once you have cloned the kernel Git repository on your local machine, you can @@ -114,8 +114,9 @@ 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. + 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-* @@ -211,7 +212,7 @@ - What this means, is that all the generated files for a particular machine or BSP are now in + This behavior means that all the generated files for a particular machine or BSP are now in the build tree directory. The files include the final .config file, all the .o files, the .a files, and so forth. @@ -224,7 +225,7 @@ Workflow Examples - As previously noted, the Yocto Project kernel has built in Git integration. + As previously noted, the Yocto Project kernel has built-in Git integration. However, these utilities are not the only way to work with the kernel repository. The Yocto Project has not made changes to Git or to other tools that would invalidate alternate workflows. @@ -240,7 +241,7 @@ . You can find a simple overview of using Git with the Yocto Project in the "Git" - section of The Yocto Project Development Manual. + section of the Yocto Project Development Manual.
@@ -419,10 +420,10 @@ # bulk export of ALL modifications without separation or division # of the changes - > git add . - > git commit -s -a -m >commit message< + $ git add . + $ git commit -s -a -m <msg> or - > git commit -s -a # and interact with $EDITOR + $ git commit -s -a # and interact with $EDITOR @@ -459,15 +460,15 @@ # edit a file - > vi >path</file + $ vi <path>/file # stage the change - > git add >path</file + $ git add <path>/file # commit the change - > git commit -s + $ git commit -s # remove a file - > git rm >path</file + $ git rm <path>/file # commit the change - > git commit -s + $ git commit -s ... etc. @@ -494,25 +495,25 @@ associated with development by using the following commands: - > Git add >path</file - > Git commit --amend - > Git rebase or Git rebase -i + $ Git add <path>/file + $ Git commit --amend + $ Git rebase or Git rebase -i Again, assuming that the changes have not been pushed upstream, and that - no pending works-in-progress exists (use git status to check), then + no pending works-in-progress exist (use git status to check), then you can revert (undo) commits by using the following commands: # remove the commit, update working tree and remove all # traces of the change - > git reset --hard HEAD^ + $ git reset --hard HEAD^ # remove the commit, but leave the files changed and staged for re-commit - > git reset --soft HEAD^ + $ git reset --soft HEAD^ # remove the commit, leave file change, but not staged for commit - > git reset --mixed HEAD^ + $ git reset --mixed HEAD^ @@ -540,7 +541,7 @@ This section describes how you can extract committed changes from a working directory by exporting them as patches. - Once extracted, you can use the patches for upstream submission, + Once the changes have been extracted, you can use the patches for upstream submission, place them in a Yocto Project template for automatic kernel patching, or apply them in many other common uses. @@ -560,7 +561,7 @@ # began. It can also be the parent branch if a branch was created # before development began. - > git format-patch -o <dir> <first commit>..<last commit> + $ git format-patch -o <dir> <first commit>..<last commit> @@ -570,14 +571,14 @@ # Identify commits of interest. # If the tree was tagged before development - > git format-patch -o <save dir> <tag> + $ git format-patch -o <save dir> <tag> # If no tags are available - > git format-patch -o <save dir> HEAD^ # last commit - > git format-patch -o <save dir> HEAD^^ # last 2 commits - > git whatchanged # identify last commit - > git format-patch -o <save dir> <commit id> - > git format-patch -o <save dir> <rev-list> + $ git format-patch -o <save dir> HEAD^ # last commit + $ git format-patch -o <save dir> HEAD^^ # last 2 commits + $ git whatchanged # identify last commit + $ git format-patch -o <save dir> <commit id> + $ git format-patch -o <save dir> <rev-list>
@@ -588,14 +589,14 @@ This section describes how you can export changes from a working directory by pushing the changes into a master repository or by making a pull request. - Once you have pushed the changes in the master repository, you can then + Once you have pushed the changes to the master repository, you can then pull those same changes into a new kernel build at a later time. Use this command form to push the changes: - > git push ssh://<master_server>/<path_to_repo> + $ git push ssh://<master_server>/<path_to_repo> <local_branch>:<remote_branch> @@ -605,13 +606,13 @@ yocto/standard/common-pc/base to the remote branch with the same name in the master repository //git.mycompany.com/pub/git/kernel-3.4. - > git push ssh://git.mycompany.com/pub/git/kernel-3.4 \ + $ git push ssh://git.mycompany.com/pub/git/kernel-3.4 \ yocto/standard/common-pc/base:yocto/standard/common-pc/base - A pull request entails using git request-pull to compose + A pull request entails using the git request-pull command to compose an email to the maintainer requesting that a branch be pulled into the master repository, see for an example. @@ -673,8 +674,8 @@ The following is an example of dumping patches for external submission: # dump the last 4 commits - > git format-patch --thread -n -o ~/rr/ HEAD^^^^ - > git send-email --compose --subject '[RFC 0/N] <patch series summary>' \ + $ git format-patch --thread -n -o ~/rr/ HEAD^^^^ + $ git send-email --compose --subject '[RFC 0/N] <patch series summary>' \ --to foo@yoctoproject.org --to bar@yoctoproject.org \ --cc list@yoctoproject.org ~/rr # the editor is invoked for the 0/N patch, and when complete the entire @@ -741,9 +742,9 @@ import the yocto/standard/common-pc/base kernel into a secondary SCM: - > git checkout yocto/standard/common-pc/base - > cd .. ; echo linux/.git > .cvsignore - > cvs import -m "initial import" linux MY_COMPANY start + $ git checkout yocto/standard/common-pc/base + $ cd .. ; echo linux/.git > .cvsignore + $ cvs import -m "initial import" linux MY_COMPANY start @@ -755,11 +756,11 @@ The following commands illustrate how you can condense and merge two BSPs into a second SCM: - > git checkout yocto/standard/common-pc/base - > git merge yocto/standard/common-pc-64/base + $ git checkout yocto/standard/common-pc/base + $ git merge yocto/standard/common-pc-64/base # resolve any conflicts and commit them - > cd .. ; echo linux/.git > .cvsignore - > cvs import -m "initial import" linux MY_COMPANY start + $ cd .. ; echo linux/.git > .cvsignore + $ cvs import -m "initial import" linux MY_COMPANY start @@ -843,7 +844,7 @@ string, this simply means that modifications in the source directory have not been committed. - > git status + $ git status @@ -857,8 +858,8 @@ To brute force pickup and commit all such pending changes, enter the following: - > git add . - > git commit -s -a -m "getting rid of -dirty" + $ git add . + $ git commit -s -a -m "getting rid of -dirty" -- cgit v1.2.3-54-g00ecf