summaryrefslogtreecommitdiffstats
path: root/documentation/kernel-manual/kernel-how-to.xml
diff options
context:
space:
mode:
authorScott Rifenbark <scott.m.rifenbark@intel.com>2011-07-14 07:47:26 -0700
committerRichard Purdie <richard.purdie@linuxfoundation.org>2011-07-21 10:59:20 +0100
commit74c120f2737d09b30d75e828b7ab0eeb8460a68e (patch)
tree4564e5428286de77a253446eaaf02f25009c44b4 /documentation/kernel-manual/kernel-how-to.xml
parent65d74d6a9ddd263dbd7dca5cf74be4b592d65c32 (diff)
downloadpoky-74c120f2737d09b30d75e828b7ab0eeb8460a68e.tar.gz
documentation/kernel-manual/kernel-how-to.xml: changed git to Git as needed (From yocto-docs rev: 65a839ea3d8decd1dd3e95bfeeeb3f95cfa77ef4)
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/kernel-how-to.xml')
-rw-r--r--documentation/kernel-manual/kernel-how-to.xml144
1 files changed, 72 insertions, 72 deletions
diff --git a/documentation/kernel-manual/kernel-how-to.xml b/documentation/kernel-manual/kernel-how-to.xml
index 0e344c44a9..0f7e03f23f 100644
--- a/documentation/kernel-manual/kernel-how-to.xml
+++ b/documentation/kernel-manual/kernel-how-to.xml
@@ -41,16 +41,16 @@
41 </para> 41 </para>
42 <para> 42 <para>
43 You can find the files used to describe all the valid features and BSPs in the Yocto Project 43 You can find the files used to describe all the valid features and BSPs in the Yocto Project
44 kernel in any clone of the kernel git tree. 44 kernel in any clone of the kernel Git tree.
45 The directory <filename>meta/cfg/kernel-cache/</filename> is a snapshot of all the kernel 45 The directory <filename>meta/cfg/kernel-cache/</filename> is a snapshot of all the kernel
46 configuration and feature descriptions (.scc) used to build the kernel repository. 46 configuration and feature descriptions (.scc) used to build the kernel repository.
47 You should realize, however, that browsing the snapshot of feature 47 You should realize, however, that browsing the snapshot of feature
48 descriptions and patches is not an effective way to determine what is in a 48 descriptions and patches is not an effective way to determine what is in a
49 particular kernel branch. 49 particular kernel branch.
50 Instead, you should use git directly to discover the changes 50 Instead, you should use Git directly to discover the changes
51 in a branch. 51 in a branch.
52 Using git is an efficient and flexible way to inspect changes to the kernel. 52 Using Git is an efficient and flexible way to inspect changes to the kernel.
53 For examples showing how to use git to inspect kernel commits, see the following sections 53 For examples showing how to use Git to inspect kernel commits, see the following sections
54 in this chapter. 54 in this chapter.
55 </para> 55 </para>
56 <note><para> 56 <note><para>
@@ -91,13 +91,13 @@
91 91
92 <listitem><para>The script is executed, and a meta-series is produced. 92 <listitem><para>The script is executed, and a meta-series is produced.
93 The meta-series is a description of all the branches, tags, patches and configurations that 93 The meta-series is a description of all the branches, tags, patches and configurations that
94 need to be applied to the base git repository to completely create the 94 need to be applied to the base Git repository to completely create the
95 BSP source (build) branch.</para></listitem> 95 BSP source (build) branch.</para></listitem>
96 96
97 <listitem><para>The base repository is cloned, and the actions 97 <listitem><para>The base repository is cloned, and the actions
98 listed in the meta-series are applied to the tree.</para></listitem> 98 listed in the meta-series are applied to the tree.</para></listitem>
99 99
100 <listitem><para>The git repository is left with the desired branch checked out and any 100 <listitem><para>The Git repository is left with the desired branch checked out and any
101 required branching, patching and tagging has been performed.</para></listitem> 101 required branching, patching and tagging has been performed.</para></listitem>
102 </orderedlist> 102 </orderedlist>
103 </para> 103 </para>
@@ -137,7 +137,7 @@ A summary of end user tree construction activities follow:
137<itemizedlist> 137<itemizedlist>
138 <listitem><para>compile and link a full top-down kernel description from feature descriptions</para></listitem> 138 <listitem><para>compile and link a full top-down kernel description from feature descriptions</para></listitem>
139 <listitem><para>execute the complete description to generate a meta-series</para></listitem> 139 <listitem><para>execute the complete description to generate a meta-series</para></listitem>
140 <listitem><para>interpret the meta-series to create a customized git repository for the 140 <listitem><para>interpret the meta-series to create a customized Git repository for the
141 board</para></listitem> 141 board</para></listitem>
142 <listitem><para>migrate configuration fragments and configure the kernel</para></listitem> 142 <listitem><para>migrate configuration fragments and configure the kernel</para></listitem>
143 <listitem><para>checkout the BSP branch and build</para></listitem> 143 <listitem><para>checkout the BSP branch and build</para></listitem>
@@ -153,7 +153,7 @@ A summary of end user tree construction activities follow:
153 </para> 153 </para>
154 154
155 <itemizedlist> 155 <itemizedlist>
156 <listitem><para>There must be a kernel git repository indicated in the SRC_URI.</para></listitem> 156 <listitem><para>There must be a kernel Git repository indicated in the SRC_URI.</para></listitem>
157 <listitem><para>There must be a BSP build branch - &lt;bsp name&gt;-&lt;kernel type&gt; in 0.9 or 157 <listitem><para>There must be a BSP build branch - &lt;bsp name&gt;-&lt;kernel type&gt; in 0.9 or
158 &lt;kernel type&gt;/&lt;bsp name&gt; in 1.0.</para></listitem> 158 &lt;kernel type&gt;/&lt;bsp name&gt; in 1.0.</para></listitem>
159 </itemizedlist> 159 </itemizedlist>
@@ -186,7 +186,7 @@ A summary of end user tree construction activities follow:
186 </para> 186 </para>
187 187
188 <para>The other thing that you will first see once you configure a kernel is that 188 <para>The other thing that you will first see once you configure a kernel is that
189 it will generate a build tree that is separate from your git source tree. 189 it will generate a build tree that is separate from your Git source tree.
190 This build tree has the name using the following form: 190 This build tree has the name using the following form:
191 <literallayout class='monospaced'> 191 <literallayout class='monospaced'>
192 linux-&lt;BSPname&gt;-&lt;kerntype&gt;-build 192 linux-&lt;BSPname&gt;-&lt;kerntype&gt;-build
@@ -203,7 +203,7 @@ A summary of end user tree construction activities follow:
203 The files include the final <filename>.config</filename>, all the <filename>.o</filename> 203 The files include the final <filename>.config</filename>, all the <filename>.o</filename>
204 files, the <filename>.a</filename> files, and so forth. 204 files, the <filename>.a</filename> files, and so forth.
205 Since each BSP has its own separate build directory in its own separate branch 205 Since each BSP has its own separate build directory in its own separate branch
206 of the git tree you can easily switch between different BSP builds. 206 of the Git tree you can easily switch between different BSP builds.
207 </para> 207 </para>
208 </section> 208 </section>
209 209
@@ -222,7 +222,7 @@ to be used or not. The 2.0 release already made use of some stateful
222construction of series files, but since the delivery mechanism was unchanged 222construction of series files, but since the delivery mechanism was unchanged
223(tar + patches + series files), most people were not aware of anything really 223(tar + patches + series files), most people were not aware of anything really
224different. The 3.0 release continues with this stateful construction of 224different. The 3.0 release continues with this stateful construction of
225series files, but since the delivery mechanism is changed (git + branches) it 225series files, but since the delivery mechanism is changed (Git + branches) it
226now is more apparent to people. 226now is more apparent to people.
227</para> 227</para>
228<para> 228<para>
@@ -231,7 +231,7 @@ compiler". Its role is to combine feature descriptions into a format that can
231be used to generate a meta-series. A meta series contains all the required 231be used to generate a meta-series. A meta series contains all the required
232information to construct a complete set of branches that are required to 232information to construct a complete set of branches that are required to
233build a desired board and feature set. The meta series is interpreted by the 233build a desired board and feature set. The meta series is interpreted by the
234kgit tools to create a git repository that could be built. 234kgit tools to create a Git repository that could be built.
235</para> 235</para>
236<para> 236<para>
237To illustrate how scc works, a feature description must first be understood. 237To illustrate how scc works, a feature description must first be understood.
@@ -248,7 +248,7 @@ Each feature description can use any of the following valid scc commands:
248 <listitem><para>shell constructs: bash conditionals and other utilities can be used in a feature 248 <listitem><para>shell constructs: bash conditionals and other utilities can be used in a feature
249 description. During compilation, the working directory is the feature 249 description. During compilation, the working directory is the feature
250 description itself, so any command that is "raw shell" and not from the 250 description itself, so any command that is "raw shell" and not from the
251 list of supported commands, can not directly modify a git repository.</para></listitem> 251 list of supported commands, can not directly modify a Git repository.</para></listitem>
252 252
253 <listitem><para>patch &lt;relative path&gt;/&lt;patch name&gt;: outputs a patch to be included in a feature's patch set. Only the name of 253 <listitem><para>patch &lt;relative path&gt;/&lt;patch name&gt;: outputs a patch to be included in a feature's patch set. Only the name of
254 the patch is supplied, the path is calculated from the currently set 254 the patch is supplied, the path is calculated from the currently set
@@ -299,9 +299,9 @@ Each feature description can use any of the following valid scc commands:
299 include is processed, so is normally only used by a new top level feature 299 include is processed, so is normally only used by a new top level feature
300 to modify the order of features in something it is including.</para></listitem> 300 to modify the order of features in something it is including.</para></listitem>
301 301
302 <listitem><para>git &lt;command&gt;: Issues any git command during tree construction. Note: this command is 302 <listitem><para>git &lt;command&gt;: Issues any Git command during tree construction. Note: this command is
303 not validated/sanitized so care must be taken to not damage the 303 not validated/sanitized so care must be taken to not damage the
304 tree. This can be used to script branching, tagging, pulls or other git 304 tree. This can be used to script branching, tagging, pulls or other Git
305 operations.</para></listitem> 305 operations.</para></listitem>
306 306
307 <listitem><para>dir &lt;directory&gt;: changes the working directory for "patch" directives. This can be used to 307 <listitem><para>dir &lt;directory&gt;: changes the working directory for "patch" directives. This can be used to
@@ -351,17 +351,17 @@ kgit-meta is the actual application of feature description(s) to a kernel repo.
351In other words, it is responsible for interpreting the meta series generated 351In other words, it is responsible for interpreting the meta series generated
352from a scc compiled script. As a result, kgit-meta is coupled to the set of 352from a scc compiled script. As a result, kgit-meta is coupled to the set of
353commands permitted in a .scc feature description (listed in the scc section). 353commands permitted in a .scc feature description (listed in the scc section).
354kgit-meta understands both the meta series format and how to use git and 354kgit-meta understands both the meta series format and how to use Git and
355guilt to modify a base git repository. It processes a meta-series line by 355guilt to modify a base Git repository. It processes a meta-series line by
356line, branching, tagging, patching and tracking changes that are made to the 356line, branching, tagging, patching and tracking changes that are made to the
357base git repository. 357base Git repository.
358</para> 358</para>
359<para> 359<para>
360Once kgit-meta has processed a meta-series, it leaves the repository with the 360Once kgit-meta has processed a meta-series, it leaves the repository with the
361last branch checked out, and creates the necessary guilt infrastructure to 361last branch checked out, and creates the necessary guilt infrastructure to
362inspect the tree, or add to it via using guilt. As was previously mentioned, 362inspect the tree, or add to it via using guilt. As was previously mentioned,
363guilt is not required, but is provided as a convenience. Other utilities such 363guilt is not required, but is provided as a convenience. Other utilities such
364as quilt, stgit, git or others can also be used to manipulate the git 364as quilt, stgit, Git or others can also be used to manipulate the Git
365repository. 365repository.
366</para> 366</para>
367 </section> --> 367 </section> -->
@@ -370,12 +370,12 @@ repository.
370 <title>Workflow Examples</title> 370 <title>Workflow Examples</title>
371 371
372 <para> 372 <para>
373 As previously noted, the Yocto Project kernel has built in git integration. 373 As previously noted, the Yocto Project kernel has built in Git integration.
374 However, these utilities are not the only way to work with the kernel repository. 374 However, these utilities are not the only way to work with the kernel repository.
375 Yocto Project has not made changes to git or to other tools that 375 Yocto Project has not made changes to Git or to other tools that
376 would invalidate alternate workflows. 376 would invalidate alternate workflows.
377 Additionally, the way the kernel repository is constructed results in using 377 Additionally, the way the kernel repository is constructed results in using
378 only core git functionality thus allowing any number of tools or front ends to use the 378 only core Git functionality thus allowing any number of tools or front ends to use the
379 resulting tree. 379 resulting tree.
380 </para> 380 </para>
381 381
@@ -404,7 +404,7 @@ repository.
404 404
405 <para> 405 <para>
406 A more efficient way to determine what has changed in the kernel is to use 406 A more efficient way to determine what has changed in the kernel is to use
407 git and inspect or search the kernel tree. 407 Git and inspect or search the kernel tree.
408 This method gives you a full view of not only the source code modifications, 408 This method gives you a full view of not only the source code modifications,
409 but also provides the reasons for the changes. 409 but also provides the reasons for the changes.
410 </para> 410 </para>
@@ -413,8 +413,8 @@ repository.
413 <title>What Changed in a BSP?</title> 413 <title>What Changed in a BSP?</title>
414 414
415 <para> 415 <para>
416 Following are a few examples that show how to use git to examine changes. 416 Following are a few examples that show how to use Git to examine changes.
417 Note that because the Yocto Project git repository does not break existing git 417 Note that because the Yocto Project Git repository does not break existing Git
418 functionality and because there exists many permutations of these types of 418 functionality and because there exists many permutations of these types of
419 commands there are many more methods to discover changes. 419 commands there are many more methods to discover changes.
420 </para> 420 </para>
@@ -477,7 +477,7 @@ repository.
477 <para> 477 <para>
478 You can use many other comparisons to isolate BSP changes. 478 You can use many other comparisons to isolate BSP changes.
479 For example, you can compare against kernel.org tags (e.g. v2.6.27.18, etc), or 479 For example, you can compare against kernel.org tags (e.g. v2.6.27.18, etc), or
480 you can compare against subsystems (e.g. git whatchanged mm). 480 you can compare against subsystems (e.g. <filename>git whatchanged mm</filename>).
481 </para> 481 </para>
482 </section> 482 </section>
483 </section> 483 </section>
@@ -492,9 +492,9 @@ repository.
492 </para> 492 </para>
493 493
494 <para> 494 <para>
495 Since the Yocto Project kernel source tree is backed by git, this activity is 495 Since the Yocto Project kernel source tree is backed by Git, this activity is
496 much easier as compared to with previous releases. 496 much easier as compared to with previous releases.
497 Because git tracks file modifications, additions and deletions, it is easy 497 Because Git tracks file modifications, additions and deletions, it is easy
498 to modify the code and later realize that the changes should be saved. 498 to modify the code and later realize that the changes should be saved.
499 It is also easy to determine what has changed. 499 It is also easy to determine what has changed.
500 This method also provides many tools to commit, undo and export those modifications. 500 This method also provides many tools to commit, undo and export those modifications.
@@ -507,7 +507,7 @@ repository.
507 507
508 <itemizedlist> 508 <itemizedlist>
509 <listitem><para>Bulk storage</para></listitem> 509 <listitem><para>Bulk storage</para></listitem>
510 <listitem><para>Internal sharing either through patches or by using git</para></listitem> 510 <listitem><para>Internal sharing either through patches or by using Git</para></listitem>
511 <listitem><para>External submissions</para></listitem> 511 <listitem><para>External submissions</para></listitem>
512 <listitem><para>Exporting for integration into another SCM</para></listitem> 512 <listitem><para>Exporting for integration into another SCM</para></listitem>
513 </itemizedlist> 513 </itemizedlist>
@@ -555,7 +555,7 @@ repository.
555 555
556 <para> 556 <para>
557 The previous operations capture all the local changes in the project source 557 The previous operations capture all the local changes in the project source
558 tree in a single git commit. 558 tree in a single Git commit.
559 And, that commit is also stored in the project's source tree. 559 And, that commit is also stored in the project's source tree.
560 </para> 560 </para>
561 561
@@ -575,12 +575,12 @@ repository.
575 The examples in this section assume that changes have been incrementally committed 575 The examples in this section assume that changes have been incrementally committed
576 to the tree during development and now need to be exported. The sections that follow 576 to the tree during development and now need to be exported. The sections that follow
577 describe how you can export your changes internally through either patches or by 577 describe how you can export your changes internally through either patches or by
578 using git commands. 578 using Git commands.
579 </para> 579 </para>
580 580
581 <para> 581 <para>
582 During development the following commands are of interest. 582 During development the following commands are of interest.
583 For full git documentation, refer to the git man pages or to an online resource such 583 For full Git documentation, refer to the Git man pages or to an online resource such
584 as <ulink url='http://github.com'></ulink>. 584 as <ulink url='http://github.com'></ulink>.
585 585
586 <literallayout class='monospaced'> 586 <literallayout class='monospaced'>
@@ -619,15 +619,15 @@ repository.
619 associated with development by using the following commands: 619 associated with development by using the following commands:
620 620
621 <literallayout class='monospaced'> 621 <literallayout class='monospaced'>
622 &gt; git add &gt;path&lt;/file 622 &gt; Git add &gt;path&lt;/file
623 &gt; git commit --amend 623 &gt; Git commit --amend
624 &gt; git rebase or git rebase -i 624 &gt; Git rebase or Git rebase -i
625 </literallayout> 625 </literallayout>
626 </para> 626 </para>
627 627
628 <para> 628 <para>
629 Again, assuming that the changes have not been pushed upstream, and that 629 Again, assuming that the changes have not been pushed upstream, and that
630 no pending works-in-progress exist (use "git status" to check) then 630 no pending works-in-progress exist (use <filename>git status</filename> to check) then
631 you can revert (undo) commits by using the following commands: 631 you can revert (undo) commits by using the following commands:
632 632
633 <literallayout class='monospaced'> 633 <literallayout class='monospaced'>
@@ -642,13 +642,13 @@ repository.
642 </para> 642 </para>
643 643
644 <para> 644 <para>
645 You can create branches, "cherry-pick" changes or perform any number of git 645 You can create branches, "cherry-pick" changes or perform any number of Git
646 operations until the commits are in good order for pushing upstream 646 operations until the commits are in good order for pushing upstream
647 or for pull requests. 647 or for pull requests.
648 After a push or pull, commits are normally considered 648 After a push or pull, commits are normally considered
649 "permanent" and you should not modify them. 649 "permanent" and you should not modify them.
650 If they need to be changed you can incrementally do so with new commits. 650 If they need to be changed you can incrementally do so with new commits.
651 These practices follow the standard "git" workflow and the kernel.org best 651 These practices follow the standard Git workflow and the kernel.org best
652 practices, which Yocto Project recommends. 652 practices, which Yocto Project recommends.
653 </para> 653 </para>
654 654
@@ -717,7 +717,7 @@ repository.
717 </section> 717 </section>
718 718
719 <section id='export-internally-via-git'> 719 <section id='export-internally-via-git'>
720 <title>Exporting Changes Internally by Using git</title> 720 <title>Exporting Changes Internally by Using Git</title>
721 721
722 <para> 722 <para>
723 This section describes how you can export changes from a working directory 723 This section describes how you can export changes from a working directory
@@ -743,20 +743,20 @@ repository.
743 </para> 743 </para>
744 744
745 <para> 745 <para>
746 A pull request entails using "git request-pull" to compose an email to the 746 A pull request entails using <filename>git request-pull</filename> to compose an email to the
747 maintainer requesting that a branch be pulled into the master repository, see 747 maintainer requesting that a branch be pulled into the master repository, see
748 <ulink url='http://github.com/guides/pull-requests'></ulink> for an example. 748 <ulink url='http://github.com/guides/pull-requests'></ulink> for an example.
749 </para> 749 </para>
750 750
751 <note><para> 751 <note><para>
752 Other commands such as 'git stash' or branching can also be used to save 752 Other commands such as <filename>git stash</filename> or branching can also be used to save
753 changes, but are not covered in this document. 753 changes, but are not covered in this document.
754 </para></note> 754 </para></note>
755 755
756 <!--<para> 756 <!--<para>
757 See the section "importing from another SCM" for how a git push to the 757 See the section "importing from another SCM" for how a Git push to the
758 default_kernel, can be used to automatically update the builds of all users 758 default_kernel, can be used to automatically update the builds of all users
759 of a central git repository. 759 of a central Git repository.
760 </para>--> 760 </para>-->
761 </section> 761 </section>
762 </section> 762 </section>
@@ -787,7 +787,7 @@ repository.
787 The messages used to commit changes are a large part of these standards. 787 The messages used to commit changes are a large part of these standards.
788 Consequently, be sure that the headers for each commit have the required information. 788 Consequently, be sure that the headers for each commit have the required information.
789 If the initial commits were not properly documented or do not meet those standards, 789 If the initial commits were not properly documented or do not meet those standards,
790 you can re-base by using the "git rebase -i" command to manipulate the commits and 790 you can re-base by using the <filename>git rebase -i</filename> command to manipulate the commits and
791 get them into the required format. 791 get them into the required format.
792 Other techniques such as branching and cherry-picking commits are also viable options. 792 Other techniques such as branching and cherry-picking commits are also viable options.
793 </para> 793 </para>
@@ -795,7 +795,7 @@ repository.
795 <para> 795 <para>
796 Once you complete the commits, you can generate the email that sends the patches 796 Once you complete the commits, you can generate the email that sends the patches
797 to the maintainer(s) or lists that review and integrate changes. 797 to the maintainer(s) or lists that review and integrate changes.
798 The command "git send-email" is commonly used to ensure that patches are properly 798 The command <filename>git send-email</filename> is commonly used to ensure that patches are properly
799 formatted for easy application and avoid mailer-induced patch damage. 799 formatted for easy application and avoid mailer-induced patch damage.
800 </para> 800 </para>
801 801
@@ -827,7 +827,7 @@ repository.
827 </para> 827 </para>
828 828
829 <para> 829 <para>
830 Many SCMs can directly import git commits, or can translate git patches so that 830 Many SCMs can directly import Git commits, or can translate Git patches so that
831 information is not lost. 831 information is not lost.
832 Those facilities are SCM-dependent and you should use them whenever possible. 832 Those facilities are SCM-dependent and you should use them whenever possible.
833 </para> 833 </para>
@@ -856,7 +856,7 @@ repository.
856 856
857 <para> 857 <para>
858 Depending on the SCM it might be possible to export the entire Yocto Project 858 Depending on the SCM it might be possible to export the entire Yocto Project
859 kernel git repository, branches and all, into a new environment. 859 kernel Git repository, branches and all, into a new environment.
860 This method is preferred because it has the most flexibility and potential to maintain 860 This method is preferred because it has the most flexibility and potential to maintain
861 the meta data associated with each commit. 861 the meta data associated with each commit.
862 </para> 862 </para>
@@ -902,14 +902,14 @@ repository.
902 automatically apply them to the kernel during patching. 902 automatically apply them to the kernel during patching.
903 </para> 903 </para>
904<!--<para> 904<!--<para>
905If changes are imported directly into git, they must be propagated to the 905If changes are imported directly into Git, they must be propagated to the
906wrll-linux-2.6.27/git/default_kernel bare clone of each individual build 906wrll-linux-2.6.27/git/default_kernel bare clone of each individual build
907to be present when the kernel is checked out. 907to be present when the kernel is checked out.
908</para> 908</para>
909<para> 909<para>
910The following example illustrates one variant of this workflow: 910The following example illustrates one variant of this workflow:
911<literallayout class='monospaced'> 911<literallayout class='monospaced'>
912 # on master git repository 912 # on master Git repository
913 &gt; cd linux-2.6.27 913 &gt; cd linux-2.6.27
914 &gt; git tag -d common_pc-standard-mark 914 &gt; git tag -d common_pc-standard-mark
915 &gt; git pull ssh://&lt;foo&gt;@&lt;bar&gt;/pub/git/kernel-2.6.27 common_pc-standard:common_pc-standard 915 &gt; git pull ssh://&lt;foo&gt;@&lt;bar&gt;/pub/git/kernel-2.6.27 common_pc-standard:common_pc-standard
@@ -930,7 +930,7 @@ The following example illustrates one variant of this workflow:
930<!-- <section id='bsp-template-migration-from-2'> 930<!-- <section id='bsp-template-migration-from-2'>
931 <title>BSP: Template Migration from 2.0</title> 931 <title>BSP: Template Migration from 2.0</title>
932<para> 932<para>
933The move to a git-backed kernel build system in 3.0 introduced a small new 933The move to a Git-backed kernel build system in 3.0 introduced a small new
934requirement for any BSP that is not integrated into the GA release of the 934requirement for any BSP that is not integrated into the GA release of the
935product: branching information. 935product: branching information.
936</para> 936</para>
@@ -1097,13 +1097,13 @@ That's it. Configure and build.
1097 </para></listitem> 1097 </para></listitem>
1098 1098
1099 <listitem><para> 1099 <listitem><para>
1100 Create a machine branch for your machine in a the Yocto Project git repository. 1100 Create a machine branch for your machine in a the Yocto Project Git repository.
1101 </para> 1101 </para>
1102 1102
1103 <para> 1103 <para>
1104 For the kernel to compile successfully, you need to create a branch in the 1104 For the kernel to compile successfully, you need to create a branch in the
1105 Yocto Project git repository that is specifically named for your machine. 1105 Yocto Project Git repository that is specifically named for your machine.
1106 To create this branch, first create a bare clone of the Yocto Project git repository. 1106 To create this branch, first create a bare clone of the Yocto Project Git repository.
1107 Then, create a local clone of that bare clone. 1107 Then, create a local clone of that bare clone.
1108 Here are the commands: 1108 Here are the commands:
1109 <literallayout class='monospaced'> 1109 <literallayout class='monospaced'>
@@ -1123,7 +1123,7 @@ That's it. Configure and build.
1123 <listitem><para> 1123 <listitem><para>
1124 In your new layer you need to edit the <filename>linux-yocto_git.bbappend</filename> 1124 In your new layer you need to edit the <filename>linux-yocto_git.bbappend</filename>
1125 file so that the compatible machine is "mymachine". 1125 file so that the compatible machine is "mymachine".
1126 It is also convenient to point to a cloned Yocto Project git repository that is local 1126 It is also convenient to point to a cloned Yocto Project Git repository that is local
1127 to your system for development purposes. 1127 to your system for development purposes.
1128 Thus, change the <filename>linux-yocto_git.bbappend</filename> file in your 1128 Thus, change the <filename>linux-yocto_git.bbappend</filename> file in your
1129 <filename>meta-mymachine</filename> layer to the following: 1129 <filename>meta-mymachine</filename> layer to the following:
@@ -1217,7 +1217,7 @@ That's it. Configure and build.
1217 <para> 1217 <para>
1218 Practically speaking, to generate the patches, you'd go to the source in the build tree: 1218 Practically speaking, to generate the patches, you'd go to the source in the build tree:
1219 <literallayout class='monospaced'> 1219 <literallayout class='monospaced'>
1220 build/tmp/work/mymachine-poky-linux/linux-yocto-2.6.37+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+ 1220 build/tmp/work/mymachine-poky-linux/linux-yocto-2.6.37+Git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+
12210431115c9d720fee5bb105f6a7411efb4f851d26-r13/linux 12210431115c9d720fee5bb105f6a7411efb4f851d26-r13/linux
1222 </literallayout> 1222 </literallayout>
1223 </para> 1223 </para>
@@ -1234,7 +1234,7 @@ That's it. Configure and build.
1234 Once you have the final patch from quilt, copy it to the 1234 Once you have the final patch from quilt, copy it to the
1235 SRC_URI location. 1235 SRC_URI location.
1236 The patch is applied the next time you do a clean build. 1236 The patch is applied the next time you do a clean build.
1237 Of course, since you have a branch for the BSP in git, it would be better to put it there instead. 1237 Of course, since you have a branch for the BSP in Git, it would be better to put it there instead.
1238 For example, in this case, commit the patch to the "yocto/standard/mymachine" branch, and during the 1238 For example, in this case, commit the patch to the "yocto/standard/mymachine" branch, and during the
1239 next build it is applied from there. 1239 next build it is applied from there.
1240 </para></listitem> 1240 </para></listitem>
@@ -1467,7 +1467,7 @@ In this technique the .scc file in the board template is slightly different
1467<para> 1467<para>
1468The previous examples created the board templates and configured a build 1468The previous examples created the board templates and configured a build
1469before beginning work on a new BSP. It is also possible for advanced users to 1469before beginning work on a new BSP. It is also possible for advanced users to
1470simply treat the Yocto Project git repository as an upstream source and begin 1470simply treat the Yocto Project Git repository as an upstream source and begin
1471BSP development directly on the repository. This is the closest match to how 1471BSP development directly on the repository. This is the closest match to how
1472the kernel community at large would operate. 1472the kernel community at large would operate.
1473</para> 1473</para>
@@ -1717,7 +1717,7 @@ Or you can do this:
1717</para> 1717</para>
1718<para> 1718<para>
1719For details on conflict resolution and patch application, see the 1719For details on conflict resolution and patch application, see the
1720git manual, or other suitable online references. 1720Git manual, or other suitable online references.
1721<literallayout class='monospaced'> 1721<literallayout class='monospaced'>
1722 &gt; git am &lt;mbox&gt; 1722 &gt; git am &lt;mbox&gt;
1723 # conflict 1723 # conflict
@@ -1845,8 +1845,8 @@ Other guilt operations of interest are:
1845</literallayout> 1845</literallayout>
1846</para> 1846</para>
1847<note><para> 1847<note><para>
1848Guilt only uses git commands and git plumbing to perform its operations, 1848Guilt only uses Git commands and Git plumbing to perform its operations,
1849anything that guilt does can also be done using git directly. It is provided 1849anything that guilt does can also be done using Git directly. It is provided
1850as a convenience utility, but is not required and the developer can use whatever 1850as a convenience utility, but is not required and the developer can use whatever
1851tools or workflow they wish. 1851tools or workflow they wish.
1852</para></note> 1852</para></note>
@@ -1855,7 +1855,7 @@ The following builds from the above instructions to show how guilt can be
1855used to assist in getting your BSP kernel patches ready. You should follow 1855used to assist in getting your BSP kernel patches ready. You should follow
1856the above instructions up to and including 'make linux.config'. In this 1856the above instructions up to and including 'make linux.config'. In this
1857example I will create a new commit (patch) from scratch and import another 1857example I will create a new commit (patch) from scratch and import another
1858fictitious patch from some external public git tree (ie, a commit with full 1858fictitious patch from some external public Git tree (ie, a commit with full
1859message, signoff etc.). Please ensure you have host-cross/bin in your path. 1859message, signoff etc.). Please ensure you have host-cross/bin in your path.
1860<literallayout class='monospaced'> 1860<literallayout class='monospaced'>
1861 %> cd linux 1861 %> cd linux
@@ -1873,7 +1873,7 @@ message, signoff etc.). Please ensure you have host-cross/bin in your path.
1873Here are a few notes about the above: 1873Here are a few notes about the above:
1874<itemizedlist> 1874<itemizedlist>
1875 <listitem><para>guilt-header -e &dash;&dash; this will open editing of the patch header in 1875 <listitem><para>guilt-header -e &dash;&dash; this will open editing of the patch header in
1876 EDITOR. As with a git commit the first line is the short log and 1876 EDITOR. As with a Git commit the first line is the short log and
1877 should be just that short and concise message about the commit. Follow 1877 should be just that short and concise message about the commit. Follow
1878 the short log with lines of text that will be the long description but 1878 the short log with lines of text that will be the long description but
1879 note Do not put a blank line after the short log. As usual you will 1879 note Do not put a blank line after the short log. As usual you will
@@ -1887,7 +1887,7 @@ Here are a few notes about the above:
1887 review comment in the first patch (first_one.patch in the case of this 1887 review comment in the first patch (first_one.patch in the case of this
1888 example) it is very easy to use guilt to pop the other patches off 1888 example) it is very easy to use guilt to pop the other patches off
1889 allowing you to make the necessary changes without having to use more 1889 allowing you to make the necessary changes without having to use more
1890 inventive git type strategies.</para></listitem> 1890 inventive Git type strategies.</para></listitem>
1891</itemizedlist> 1891</itemizedlist>
1892</para> 1892</para>
1893 </section> 1893 </section>
@@ -1992,7 +1992,7 @@ This section shows an example of transforms:
1992 </para> 1992 </para>
1993 1993
1994 <para> 1994 <para>
1995 You can use the git command above to report modified, removed, or added files. 1995 You can use the Git command above to report modified, removed, or added files.
1996 You should commit those changes to the tree regardless of whether they will be saved, 1996 You should commit those changes to the tree regardless of whether they will be saved,
1997 exported, or used. 1997 exported, or used.
1998 Once you commit the changes you need to rebuild the kernel. 1998 Once you commit the changes you need to rebuild the kernel.
@@ -2019,7 +2019,7 @@ This section shows an example of transforms:
2019 2019
2020 <orderedlist> 2020 <orderedlist>
2021 <listitem><para>Create a custom kernel layer.</para></listitem> 2021 <listitem><para>Create a custom kernel layer.</para></listitem>
2022 <listitem><para>Create a git repository of the transition kernel.</para></listitem> 2022 <listitem><para>Create a Git repository of the transition kernel.</para></listitem>
2023 </orderedlist> 2023 </orderedlist>
2024 </para> 2024 </para>
2025 2025
@@ -2061,12 +2061,12 @@ patches. If a custom BSP is being used, this is not required.
2061 </section> --> 2061 </section> -->
2062 2062
2063 <!-- <section id='git-repo-of-the-transition-kernel'> 2063 <!-- <section id='git-repo-of-the-transition-kernel'>
2064 <title>git Repo of the Transition Kernel</title> 2064 <title>Git Repo of the Transition Kernel</title>
2065<para> 2065<para>
2066The kernel build system requires a base kernel repository to 2066The kernel build system requires a base kernel repository to
2067seed the build process. This repository must be found in the 2067seed the build process. This repository must be found in the
2068same layer as the build infrastructure (i.e wrll-linux-2.6.27) 2068same layer as the build infrastructure (i.e wrll-linux-2.6.27)
2069in the 'git' subdir, with the name 'default_kernel' 2069in the <filename>.git</filename> subdir, with the name 'default_kernel'
2070</para> 2070</para>
2071<para>Since Yocto Project Linux ships with a default_kernel 2071<para>Since Yocto Project Linux ships with a default_kernel
2072(the validated Yocto Project kernel) in the wrll-linux-2.6.27 2072(the validated Yocto Project kernel) in the wrll-linux-2.6.27
@@ -2075,15 +2075,15 @@ transition kernel.
2075</para> 2075</para>
2076<para>If the Yocto Project install cannot be directly modified 2076<para>If the Yocto Project install cannot be directly modified
2077with the new default kernel, then the path to the transition 2077with the new default kernel, then the path to the transition
2078kernel layer's 'git' subdir must be passed to the build 2078kernel layer's <filename>.git</filename> subdir must be passed to the build
2079process via: 2079process via:
2080<programlisting> 2080<programlisting>
2081linux_GIT_BASE=&lt;absolute path to layer&gt;/git 2081linux_GIT_BASE=&lt;absolute path to layer&gt;/git
2082</programlisting> 2082</programlisting>
2083</para> 2083</para>
2084<para> 2084<para>
2085If the transition kernel has not been delivered via git, 2085If the transition kernel has not been delivered via Git,
2086then a git repo should be created, and bare cloned into 2086then a Git repo should be created, and bare cloned into
2087place. Creating this repository is as simple as: 2087place. Creating this repository is as simple as:
2088<literallayout class='monospaced'> 2088<literallayout class='monospaced'>
2089 &gt; tar zxvf temp_kernel.tgz 2089 &gt; tar zxvf temp_kernel.tgz
@@ -2156,7 +2156,7 @@ To build the kernel:
2156</para> 2156</para>
2157<para> 2157<para>
2158If this is to build without some user intervention (passing of the 2158If this is to build without some user intervention (passing of the
2159GIT_BASE), you must do the clone into the wrll-linux-2.6.27/git directory. 2159GIT_BASE), you must do the clone into the <filename>wrll-linux-2.6.27/.git</filename> directory.
2160</para> 2160</para>
2161<note><para>Unless you define valid "hardware.kcf" and "non-hardware.kcf" some 2161<note><para>Unless you define valid "hardware.kcf" and "non-hardware.kcf" some
2162non fatal warnings will be seen. They can be fixed by populating these 2162non fatal warnings will be seen. They can be fixed by populating these
@@ -2206,7 +2206,7 @@ options.
2206 <listitem><para>Building a 'dirty' image.</para></listitem> 2206 <listitem><para>Building a 'dirty' image.</para></listitem>
2207 <listitem><para>Temporarily using a different base kernel.</para></listitem> 2207 <listitem><para>Temporarily using a different base kernel.</para></listitem>
2208 <listitem><para>Creating a custom kernel layer.</para></listitem> 2208 <listitem><para>Creating a custom kernel layer.</para></listitem>
2209 <listitem><para>Creating the git repository of the transition kernel.</para></listitem> 2209 <listitem><para>Creating the Git repository of the transition kernel.</para></listitem>
2210 </itemizedlist> --> 2210 </itemizedlist> -->
2211 2211
2212 2212