summaryrefslogtreecommitdiffstats
path: root/documentation/kernel-manual
diff options
context:
space:
mode:
authorScott Rifenbark <scott.m.rifenbark@intel.com>2012-08-15 14:18:51 -0700
committerRichard Purdie <richard.purdie@linuxfoundation.org>2012-09-04 12:54:55 +0100
commit5c44309cfed33a121f0e046ace4af687f3359c16 (patch)
tree99f2d0caf2c05facf4707faee221ff3525243842 /documentation/kernel-manual
parent08b7044311674e4e414b2917fe6bfe161c2d83e5 (diff)
downloadpoky-5c44309cfed33a121f0e046ace4af687f3359c16.tar.gz
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>
Diffstat (limited to 'documentation/kernel-manual')
-rw-r--r--documentation/kernel-manual/kernel-concepts.xml12
-rw-r--r--documentation/kernel-manual/kernel-doc-intro.xml2
-rw-r--r--documentation/kernel-manual/kernel-how-to.xml95
3 files changed, 55 insertions, 54 deletions
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 @@
24 <para> 24 <para>
25 The complexity of embedded kernel design has increased dramatically. 25 The complexity of embedded kernel design has increased dramatically.
26 Whether it is managing multiple implementations of a particular feature or tuning and 26 Whether it is managing multiple implementations of a particular feature or tuning and
27 optimizing board specific features, flexibility and maintainability are key concerns. 27 optimizing board specific features, both flexibility and maintainability are key concerns.
28 The Linux kernels available through the Yocto Project are presented with the embedded 28 The Linux kernels available through the Yocto Project are presented with the embedded
29 developer's needs in mind and have evolved to assist in these key concerns. 29 developer's needs in mind and have evolved to assist in these key concerns.
30 For example, prior methods such as applying hundreds of patches to an extracted 30 For example, prior methods such as applying hundreds of patches to an extracted
@@ -45,7 +45,7 @@
45 management techniques.</para></listitem> 45 management techniques.</para></listitem>
46 <listitem><para>Deliver the most up-to-date kernel possible while still ensuring that 46 <listitem><para>Deliver the most up-to-date kernel possible while still ensuring that
47 the baseline kernel is the most stable official release.</para></listitem> 47 the baseline kernel is the most stable official release.</para></listitem>
48 <listitem><para>Include major technological features as part of Yocto Project's 48 <listitem><para>Include major technological features as part of the Yocto Project's
49 upward revision strategy.</para></listitem> 49 upward revision strategy.</para></listitem>
50 <listitem><para>Present a kernel Git repository that, similar to the upstream 50 <listitem><para>Present a kernel Git repository that, similar to the upstream
51 <filename>kernel.org</filename> tree, 51 <filename>kernel.org</filename> tree,
@@ -86,7 +86,7 @@
86 The ultimate source for kernels available through the Yocto Project are released kernels 86 The ultimate source for kernels available through the Yocto Project are released kernels
87 from <filename>kernel.org</filename>. 87 from <filename>kernel.org</filename>.
88 In addition to a foundational kernel from <filename>kernel.org</filename>, the 88 In addition to a foundational kernel from <filename>kernel.org</filename>, the
89 kernels available through the contain a mix of important new mainline 89 kernels available contain a mix of important new mainline
90 developments, non-mainline developments (when there is no alternative), 90 developments, non-mainline developments (when there is no alternative),
91 Board Support Package (BSP) developments, 91 Board Support Package (BSP) developments,
92 and custom features. 92 and custom features.
@@ -255,7 +255,7 @@
255 In other words, the divisions of the kernel are transparent and are not relevant 255 In other words, the divisions of the kernel are transparent and are not relevant
256 to the developer on a day-to-day basis. 256 to the developer on a day-to-day basis.
257 From the developer's perspective, this path is the "master" branch. 257 From the developer's perspective, this path is the "master" branch.
258 The developer does not need not be aware of the existence of any other branches at all. 258 The developer does not need to be aware of the existence of any other branches at all.
259 Of course, there is value in the existence of these branches 259 Of course, there is value in the existence of these branches
260 in the tree, should a person decide to explore them. 260 in the tree, should a person decide to explore them.
261 For example, a comparison between two BSPs at either the commit level or at the line-by-line 261 For example, a comparison between two BSPs at either the commit level or at the line-by-line
@@ -293,7 +293,7 @@
293 "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>" 293 "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>"
294 section in the Yocto Project Development Manual. 294 section in the Yocto Project Development Manual.
295 These referenced sections overview Git and describe a minimal set of 295 These referenced sections overview Git and describe a minimal set of
296 commands that allow you to be functional using Git. 296 commands that allows you to be functional using Git.
297 <note> 297 <note>
298 You can use as much, or as little, of what Git has to offer to accomplish what 298 You can use as much, or as little, of what Git has to offer to accomplish what
299 you need for your project. 299 you need for your project.
@@ -345,7 +345,7 @@
345 You can see how <filename>menuconfig</filename> is used to change a simple 345 You can see how <filename>menuconfig</filename> is used to change a simple
346 kernel configuration in the 346 kernel configuration in the
347 "<ulink url='&YOCTO_DOCS_DEV_URL;#changing-the-config-smp-configuration-using-menuconfig'>Changing the&nbsp;&nbsp;<filename>CONFIG_SMP</filename> Configuration Using&nbsp;&nbsp;<filename>menuconfig</filename></ulink>" 347 "<ulink url='&YOCTO_DOCS_DEV_URL;#changing-the-config-smp-configuration-using-menuconfig'>Changing the&nbsp;&nbsp;<filename>CONFIG_SMP</filename> Configuration Using&nbsp;&nbsp;<filename>menuconfig</filename></ulink>"
348 section of The Yocto Project Development Manual. 348 section of the Yocto Project Development Manual.
349 For general information on <filename>menuconfig</filename>, see 349 For general information on <filename>menuconfig</filename>, see
350 <ulink url='http://en.wikipedia.org/wiki/Menuconfig'></ulink>. 350 <ulink url='http://en.wikipedia.org/wiki/Menuconfig'></ulink>.
351 </para></listitem> 351 </para></listitem>
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 @@
47 47
48 <para> 48 <para>
49 For more discussion on the Yocto Project kernel, you can see these sections 49 For more discussion on the Yocto Project kernel, you can see these sections
50 in <ulink url='&YOCTO_DOCS_DEV_URL;'>The Yocto Project Development Manual</ulink>: 50 in the Yocto Project Development Manual:
51 <itemizedlist> 51 <itemizedlist>
52 <listitem><para> 52 <listitem><para>
53 "<ulink url='&YOCTO_DOCS_DEV_URL;#kernel-overview'>Kernel Overview</ulink>"</para></listitem> 53 "<ulink url='&YOCTO_DOCS_DEV_URL;#kernel-overview'>Kernel Overview</ulink>"</para></listitem>
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 @@
27 <para> 27 <para>
28 This section describes construction of the Yocto Project kernel source repositories 28 This section describes construction of the Yocto Project kernel source repositories
29 as accomplished by the Yocto Project team to create kernel repositories. 29 as accomplished by the Yocto Project team to create kernel repositories.
30 These kernel repositories are found at 30 These kernel repositories are found under the heading "Yocto Linux Kernel" at
31 <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>&YOCTO_GIT_URL;/cgit.cgi</ulink> 31 <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>&YOCTO_GIT_URL;/cgit.cgi</ulink>
32 and can be shipped as part of a Yocto Project release. 32 and can be shipped as part of a Yocto Project release.
33 The team creates these repositories by 33 The team creates these repositories by
@@ -53,8 +53,8 @@
53 </literallayout> 53 </literallayout>
54 For another example of how to set up a local Git repository of the Yocto Project 54 For another example of how to set up a local Git repository of the Yocto Project
55 kernel files, see the 55 kernel files, see the
56 "<ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink>" bulleted 56 "<ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Yocto Project Kernel</ulink>" bulleted
57 item in The Yocto Project Development Manual. 57 item in the Yocto Project Development Manual.
58 </para> 58 </para>
59 <para> 59 <para>
60 Once you have cloned the kernel Git repository on your local machine, you can 60 Once you have cloned the kernel Git repository on your local machine, you can
@@ -114,8 +114,9 @@
114 of actions, or into an existing equivalent script that is already part of the 114 of actions, or into an existing equivalent script that is already part of the
115 shipped kernel.</para></listitem> 115 shipped kernel.</para></listitem>
116 <listitem><para>Extra features are appended to the top-level feature description. 116 <listitem><para>Extra features are appended to the top-level feature description.
117 These features can come from the <filename>KERNEL_FEATURES</filename> variable in 117 These features can come from the
118 recipes.</para></listitem> 118 <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'><filename>KERNEL_FEATURES</filename></ulink>
119 variable in recipes.</para></listitem>
119 <listitem><para>Each extra feature is located, compiled and appended to the script 120 <listitem><para>Each extra feature is located, compiled and appended to the script
120 as described in step three.</para></listitem> 121 as described in step three.</para></listitem>
121 <listitem><para>The script is executed to produce a series of <filename>meta-*</filename> 122 <listitem><para>The script is executed to produce a series of <filename>meta-*</filename>
@@ -211,7 +212,7 @@
211 </para> 212 </para>
212 213
213 <para> 214 <para>
214 What this means, is that all the generated files for a particular machine or BSP are now in 215 This behavior means that all the generated files for a particular machine or BSP are now in
215 the build tree directory. 216 the build tree directory.
216 The files include the final <filename>.config</filename> file, all the <filename>.o</filename> 217 The files include the final <filename>.config</filename> file, all the <filename>.o</filename>
217 files, the <filename>.a</filename> files, and so forth. 218 files, the <filename>.a</filename> files, and so forth.
@@ -224,7 +225,7 @@
224 <title>Workflow Examples</title> 225 <title>Workflow Examples</title>
225 226
226 <para> 227 <para>
227 As previously noted, the Yocto Project kernel has built in Git integration. 228 As previously noted, the Yocto Project kernel has built-in Git integration.
228 However, these utilities are not the only way to work with the kernel repository. 229 However, these utilities are not the only way to work with the kernel repository.
229 The Yocto Project has not made changes to Git or to other tools that 230 The Yocto Project has not made changes to Git or to other tools that
230 would invalidate alternate workflows. 231 would invalidate alternate workflows.
@@ -240,7 +241,7 @@
240 <ulink url='http://git-scm.com/documentation'></ulink>. 241 <ulink url='http://git-scm.com/documentation'></ulink>.
241 You can find a simple overview of using Git with the Yocto Project in the 242 You can find a simple overview of using Git with the Yocto Project in the
242 "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>" 243 "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>"
243 section of The Yocto Project Development Manual. 244 section of the Yocto Project Development Manual.
244 </para> 245 </para>
245 246
246 <section id='change-inspection-kernel-changes-commits'> 247 <section id='change-inspection-kernel-changes-commits'>
@@ -419,10 +420,10 @@
419 # bulk export of ALL modifications without separation or division 420 # bulk export of ALL modifications without separation or division
420 # of the changes 421 # of the changes
421 422
422 &gt; git add . 423 $ git add .
423 &gt; git commit -s -a -m &gt;commit message&lt; 424 $ git commit -s -a -m &lt;msg&gt;
424 or 425 or
425 &gt; git commit -s -a # and interact with $EDITOR 426 $ git commit -s -a # and interact with $EDITOR
426 </literallayout> 427 </literallayout>
427 </para> 428 </para>
428 429
@@ -459,15 +460,15 @@
459 460
460 <literallayout class='monospaced'> 461 <literallayout class='monospaced'>
461 # edit a file 462 # edit a file
462 &gt; vi &gt;path&lt;/file 463 $ vi &lt;path&gt;/file
463 # stage the change 464 # stage the change
464 &gt; git add &gt;path&lt;/file 465 $ git add &lt;path&gt;/file
465 # commit the change 466 # commit the change
466 &gt; git commit -s 467 $ git commit -s
467 # remove a file 468 # remove a file
468 &gt; git rm &gt;path&lt;/file 469 $ git rm &lt;path&gt;/file
469 # commit the change 470 # commit the change
470 &gt; git commit -s 471 $ git commit -s
471 472
472 ... etc. 473 ... etc.
473 </literallayout> 474 </literallayout>
@@ -494,25 +495,25 @@
494 associated with development by using the following commands: 495 associated with development by using the following commands:
495 496
496 <literallayout class='monospaced'> 497 <literallayout class='monospaced'>
497 &gt; Git add &gt;path&lt;/file 498 $ Git add &lt;path&gt;/file
498 &gt; Git commit --amend 499 $ Git commit --amend
499 &gt; Git rebase or Git rebase -i 500 $ Git rebase or Git rebase -i
500 </literallayout> 501 </literallayout>
501 </para> 502 </para>
502 503
503 <para> 504 <para>
504 Again, assuming that the changes have not been pushed upstream, and that 505 Again, assuming that the changes have not been pushed upstream, and that
505 no pending works-in-progress exists (use <filename>git status</filename> to check), then 506 no pending works-in-progress exist (use <filename>git status</filename> to check), then
506 you can revert (undo) commits by using the following commands: 507 you can revert (undo) commits by using the following commands:
507 508
508 <literallayout class='monospaced'> 509 <literallayout class='monospaced'>
509 # remove the commit, update working tree and remove all 510 # remove the commit, update working tree and remove all
510 # traces of the change 511 # traces of the change
511 &gt; git reset --hard HEAD^ 512 $ git reset --hard HEAD^
512 # remove the commit, but leave the files changed and staged for re-commit 513 # remove the commit, but leave the files changed and staged for re-commit
513 &gt; git reset --soft HEAD^ 514 $ git reset --soft HEAD^
514 # remove the commit, leave file change, but not staged for commit 515 # remove the commit, leave file change, but not staged for commit
515 &gt; git reset --mixed HEAD^ 516 $ git reset --mixed HEAD^
516 </literallayout> 517 </literallayout>
517 </para> 518 </para>
518 519
@@ -540,7 +541,7 @@
540 <para> 541 <para>
541 This section describes how you can extract committed changes from a working directory 542 This section describes how you can extract committed changes from a working directory
542 by exporting them as patches. 543 by exporting them as patches.
543 Once extracted, you can use the patches for upstream submission, 544 Once the changes have been extracted, you can use the patches for upstream submission,
544 place them in a Yocto Project template for automatic kernel patching, 545 place them in a Yocto Project template for automatic kernel patching,
545 or apply them in many other common uses. 546 or apply them in many other common uses.
546 </para> 547 </para>
@@ -560,7 +561,7 @@
560 # began. It can also be the parent branch if a branch was created 561 # began. It can also be the parent branch if a branch was created
561 # before development began. 562 # before development began.
562 563
563 &gt; git format-patch -o &lt;dir&gt; &lt;first commit&gt;..&lt;last commit&gt; 564 $ git format-patch -o &lt;dir&gt; &lt;first commit&gt;..&lt;last commit&gt;
564 </literallayout> 565 </literallayout>
565 </para> 566 </para>
566 567
@@ -570,14 +571,14 @@
570 # Identify commits of interest. 571 # Identify commits of interest.
571 572
572 # If the tree was tagged before development 573 # If the tree was tagged before development
573 &gt; git format-patch -o &lt;save dir&gt; &lt;tag&gt; 574 $ git format-patch -o &lt;save dir&gt; &lt;tag&gt;
574 575
575 # If no tags are available 576 # If no tags are available
576 &gt; git format-patch -o &lt;save dir&gt; HEAD^ # last commit 577 $ git format-patch -o &lt;save dir&gt; HEAD^ # last commit
577 &gt; git format-patch -o &lt;save dir&gt; HEAD^^ # last 2 commits 578 $ git format-patch -o &lt;save dir&gt; HEAD^^ # last 2 commits
578 &gt; git whatchanged # identify last commit 579 $ git whatchanged # identify last commit
579 &gt; git format-patch -o &lt;save dir&gt; &lt;commit id&gt; 580 $ git format-patch -o &lt;save dir&gt; &lt;commit id&gt;
580 &gt; git format-patch -o &lt;save dir&gt; &lt;rev-list&gt; 581 $ git format-patch -o &lt;save dir&gt; &lt;rev-list&gt;
581 </literallayout> 582 </literallayout>
582 </para> 583 </para>
583 </section> 584 </section>
@@ -588,14 +589,14 @@
588 <para> 589 <para>
589 This section describes how you can export changes from a working directory 590 This section describes how you can export changes from a working directory
590 by pushing the changes into a master repository or by making a pull request. 591 by pushing the changes into a master repository or by making a pull request.
591 Once you have pushed the changes in the master repository, you can then 592 Once you have pushed the changes to the master repository, you can then
592 pull those same changes into a new kernel build at a later time. 593 pull those same changes into a new kernel build at a later time.
593 </para> 594 </para>
594 595
595 <para> 596 <para>
596 Use this command form to push the changes: 597 Use this command form to push the changes:
597 <literallayout class='monospaced'> 598 <literallayout class='monospaced'>
598 &gt; git push ssh://&lt;master_server&gt;/&lt;path_to_repo&gt; 599 $ git push ssh://&lt;master_server&gt;/&lt;path_to_repo&gt;
599 &lt;local_branch&gt;:&lt;remote_branch&gt; 600 &lt;local_branch&gt;:&lt;remote_branch&gt;
600 </literallayout> 601 </literallayout>
601 </para> 602 </para>
@@ -605,13 +606,13 @@
605 <filename>yocto/standard/common-pc/base</filename> to the remote branch with the same name 606 <filename>yocto/standard/common-pc/base</filename> to the remote branch with the same name
606 in the master repository <filename>//git.mycompany.com/pub/git/kernel-3.4</filename>. 607 in the master repository <filename>//git.mycompany.com/pub/git/kernel-3.4</filename>.
607 <literallayout class='monospaced'> 608 <literallayout class='monospaced'>
608 &gt; git push ssh://git.mycompany.com/pub/git/kernel-3.4 \ 609 $ git push ssh://git.mycompany.com/pub/git/kernel-3.4 \
609 yocto/standard/common-pc/base:yocto/standard/common-pc/base 610 yocto/standard/common-pc/base:yocto/standard/common-pc/base
610 </literallayout> 611 </literallayout>
611 </para> 612 </para>
612 613
613 <para> 614 <para>
614 A pull request entails using <filename>git request-pull</filename> to compose 615 A pull request entails using the <filename>git request-pull</filename> command to compose
615 an email to the 616 an email to the
616 maintainer requesting that a branch be pulled into the master repository, see 617 maintainer requesting that a branch be pulled into the master repository, see
617 <ulink url='http://github.com/guides/pull-requests'></ulink> for an example. 618 <ulink url='http://github.com/guides/pull-requests'></ulink> for an example.
@@ -673,8 +674,8 @@
673 The following is an example of dumping patches for external submission: 674 The following is an example of dumping patches for external submission:
674 <literallayout class='monospaced'> 675 <literallayout class='monospaced'>
675 # dump the last 4 commits 676 # dump the last 4 commits
676 &gt; git format-patch --thread -n -o ~/rr/ HEAD^^^^ 677 $ git format-patch --thread -n -o ~/rr/ HEAD^^^^
677 &gt; git send-email --compose --subject '[RFC 0/N] &lt;patch series summary&gt;' \ 678 $ git send-email --compose --subject '[RFC 0/N] &lt;patch series summary&gt;' \
678 --to foo@yoctoproject.org --to bar@yoctoproject.org \ 679 --to foo@yoctoproject.org --to bar@yoctoproject.org \
679 --cc list@yoctoproject.org ~/rr 680 --cc list@yoctoproject.org ~/rr
680 # the editor is invoked for the 0/N patch, and when complete the entire 681 # the editor is invoked for the 0/N patch, and when complete the entire
@@ -741,9 +742,9 @@
741 import the <filename>yocto/standard/common-pc/base</filename> 742 import the <filename>yocto/standard/common-pc/base</filename>
742 kernel into a secondary SCM: 743 kernel into a secondary SCM:
743 <literallayout class='monospaced'> 744 <literallayout class='monospaced'>
744 &gt; git checkout yocto/standard/common-pc/base 745 $ git checkout yocto/standard/common-pc/base
745 &gt; cd .. ; echo linux/.git &gt; .cvsignore 746 $ cd .. ; echo linux/.git &gt; .cvsignore
746 &gt; cvs import -m "initial import" linux MY_COMPANY start 747 $ cvs import -m "initial import" linux MY_COMPANY start
747 </literallayout> 748 </literallayout>
748 </para> 749 </para>
749 750
@@ -755,11 +756,11 @@
755 The following commands illustrate how you can condense and merge two BSPs into a 756 The following commands illustrate how you can condense and merge two BSPs into a
756 second SCM: 757 second SCM:
757 <literallayout class='monospaced'> 758 <literallayout class='monospaced'>
758 &gt; git checkout yocto/standard/common-pc/base 759 $ git checkout yocto/standard/common-pc/base
759 &gt; git merge yocto/standard/common-pc-64/base 760 $ git merge yocto/standard/common-pc-64/base
760 # resolve any conflicts and commit them 761 # resolve any conflicts and commit them
761 &gt; cd .. ; echo linux/.git &gt; .cvsignore 762 $ cd .. ; echo linux/.git &gt; .cvsignore
762 &gt; cvs import -m "initial import" linux MY_COMPANY start 763 $ cvs import -m "initial import" linux MY_COMPANY start
763 </literallayout> 764 </literallayout>
764 </para> 765 </para>
765 </section> 766 </section>
@@ -843,7 +844,7 @@
843 string, this simply means that modifications in the source 844 string, this simply means that modifications in the source
844 directory have not been committed. 845 directory have not been committed.
845 <literallayout class='monospaced'> 846 <literallayout class='monospaced'>
846 &gt; git status 847 $ git status
847 </literallayout> 848 </literallayout>
848 </para> 849 </para>
849 850
@@ -857,8 +858,8 @@
857 <para> 858 <para>
858 To brute force pickup and commit all such pending changes, enter the following: 859 To brute force pickup and commit all such pending changes, enter the following:
859 <literallayout class='monospaced'> 860 <literallayout class='monospaced'>
860 &gt; git add . 861 $ git add .
861 &gt; git commit -s -a -m "getting rid of -dirty" 862 $ git commit -s -a -m "getting rid of -dirty"
862 </literallayout> 863 </literallayout>
863 </para> 864 </para>
864 865