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 <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
Richard Purdie
parent
08b7044311
commit
5c44309cfe
|
|
@ -24,7 +24,7 @@
|
|||
<para>
|
||||
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.</para></listitem>
|
||||
<listitem><para>Deliver the most up-to-date kernel possible while still ensuring that
|
||||
the baseline kernel is the most stable official release.</para></listitem>
|
||||
<listitem><para>Include major technological features as part of Yocto Project's
|
||||
<listitem><para>Include major technological features as part of the Yocto Project's
|
||||
upward revision strategy.</para></listitem>
|
||||
<listitem><para>Present a kernel Git repository that, similar to the upstream
|
||||
<filename>kernel.org</filename> tree,
|
||||
|
|
@ -86,7 +86,7 @@
|
|||
The ultimate source for kernels available through the Yocto Project are released kernels
|
||||
from <filename>kernel.org</filename>.
|
||||
In addition to a foundational kernel from <filename>kernel.org</filename>, 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 @@
|
|||
"<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>"
|
||||
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.
|
||||
<note>
|
||||
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 <filename>menuconfig</filename> is used to change a simple
|
||||
kernel configuration in the
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#changing-the-config-smp-configuration-using-menuconfig'>Changing the <filename>CONFIG_SMP</filename> Configuration Using <filename>menuconfig</filename></ulink>"
|
||||
section of The Yocto Project Development Manual.
|
||||
section of the Yocto Project Development Manual.
|
||||
For general information on <filename>menuconfig</filename>, see
|
||||
<ulink url='http://en.wikipedia.org/wiki/Menuconfig'></ulink>.
|
||||
</para></listitem>
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@
|
|||
|
||||
<para>
|
||||
For more discussion on the Yocto Project kernel, you can see these sections
|
||||
in <ulink url='&YOCTO_DOCS_DEV_URL;'>The Yocto Project Development Manual</ulink>:
|
||||
in the Yocto Project Development Manual:
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#kernel-overview'>Kernel Overview</ulink>"</para></listitem>
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@
|
|||
<para>
|
||||
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
|
||||
<ulink url='&YOCTO_GIT_URL;/cgit.cgi'>&YOCTO_GIT_URL;/cgit.cgi</ulink>
|
||||
and can be shipped as part of a Yocto Project release.
|
||||
The team creates these repositories by
|
||||
|
|
@ -53,8 +53,8 @@
|
|||
</literallayout>
|
||||
For another example of how to set up a local Git repository of the Yocto Project
|
||||
kernel files, see the
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink>" bulleted
|
||||
item in The Yocto Project Development Manual.
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Yocto Project Kernel</ulink>" bulleted
|
||||
item in the Yocto Project Development Manual.
|
||||
</para>
|
||||
<para>
|
||||
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.</para></listitem>
|
||||
<listitem><para>Extra features are appended to the top-level feature description.
|
||||
These features can come from the <filename>KERNEL_FEATURES</filename> variable in
|
||||
recipes.</para></listitem>
|
||||
These features can come from the
|
||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'><filename>KERNEL_FEATURES</filename></ulink>
|
||||
variable in recipes.</para></listitem>
|
||||
<listitem><para>Each extra feature is located, compiled and appended to the script
|
||||
as described in step three.</para></listitem>
|
||||
<listitem><para>The script is executed to produce a series of <filename>meta-*</filename>
|
||||
|
|
@ -211,7 +212,7 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
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 <filename>.config</filename> file, all the <filename>.o</filename>
|
||||
files, the <filename>.a</filename> files, and so forth.
|
||||
|
|
@ -224,7 +225,7 @@
|
|||
<title>Workflow Examples</title>
|
||||
|
||||
<para>
|
||||
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 @@
|
|||
<ulink url='http://git-scm.com/documentation'></ulink>.
|
||||
You can find a simple overview of using Git with the Yocto Project in the
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>"
|
||||
section of The Yocto Project Development Manual.
|
||||
section of the Yocto Project Development Manual.
|
||||
</para>
|
||||
|
||||
<section id='change-inspection-kernel-changes-commits'>
|
||||
|
|
@ -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
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
|
|
@ -459,15 +460,15 @@
|
|||
|
||||
<literallayout class='monospaced'>
|
||||
# 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.
|
||||
</literallayout>
|
||||
|
|
@ -494,25 +495,25 @@
|
|||
associated with development by using the following commands:
|
||||
|
||||
<literallayout class='monospaced'>
|
||||
> 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
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Again, assuming that the changes have not been pushed upstream, and that
|
||||
no pending works-in-progress exists (use <filename>git status</filename> to check), then
|
||||
no pending works-in-progress exist (use <filename>git status</filename> to check), then
|
||||
you can revert (undo) commits by using the following commands:
|
||||
|
||||
<literallayout class='monospaced'>
|
||||
# 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^
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
|
|
@ -540,7 +541,7 @@
|
|||
<para>
|
||||
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.
|
||||
</para>
|
||||
|
|
@ -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>
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
|
|
@ -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>
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
|
@ -588,14 +589,14 @@
|
|||
<para>
|
||||
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.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Use this command form to push the changes:
|
||||
<literallayout class='monospaced'>
|
||||
> git push ssh://<master_server>/<path_to_repo>
|
||||
$ git push ssh://<master_server>/<path_to_repo>
|
||||
<local_branch>:<remote_branch>
|
||||
</literallayout>
|
||||
</para>
|
||||
|
|
@ -605,13 +606,13 @@
|
|||
<filename>yocto/standard/common-pc/base</filename> to the remote branch with the same name
|
||||
in the master repository <filename>//git.mycompany.com/pub/git/kernel-3.4</filename>.
|
||||
<literallayout class='monospaced'>
|
||||
> 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
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A pull request entails using <filename>git request-pull</filename> to compose
|
||||
A pull request entails using the <filename>git request-pull</filename> command to compose
|
||||
an email to the
|
||||
maintainer requesting that a branch be pulled into the master repository, see
|
||||
<ulink url='http://github.com/guides/pull-requests'></ulink> for an example.
|
||||
|
|
@ -673,8 +674,8 @@
|
|||
The following is an example of dumping patches for external submission:
|
||||
<literallayout class='monospaced'>
|
||||
# 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 <filename>yocto/standard/common-pc/base</filename>
|
||||
kernel into a secondary SCM:
|
||||
<literallayout class='monospaced'>
|
||||
> 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
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
|
|
@ -755,11 +756,11 @@
|
|||
The following commands illustrate how you can condense and merge two BSPs into a
|
||||
second SCM:
|
||||
<literallayout class='monospaced'>
|
||||
> 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
|
||||
</literallayout>
|
||||
</para>
|
||||
</section>
|
||||
|
|
@ -843,7 +844,7 @@
|
|||
string, this simply means that modifications in the source
|
||||
directory have not been committed.
|
||||
<literallayout class='monospaced'>
|
||||
> git status
|
||||
$ git status
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
|
|
@ -857,8 +858,8 @@
|
|||
<para>
|
||||
To brute force pickup and commit all such pending changes, enter the following:
|
||||
<literallayout class='monospaced'>
|
||||
> git add .
|
||||
> git commit -s -a -m "getting rid of -dirty"
|
||||
$ git add .
|
||||
$ git commit -s -a -m "getting rid of -dirty"
|
||||
</literallayout>
|
||||
</para>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue