diff options
author | Scott Rifenbark <scott.m.rifenbark@intel.com> | 2012-12-27 14:50:40 -0600 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2013-01-16 15:59:12 +0000 |
commit | 49166264bd93d2e4c0b4fcf3641468b37ca18b84 (patch) | |
tree | 543bb003e3a9cebc592b97ef58f74e04a1b6aec8 /documentation/kernel-dev/kernel-dev-advanced.xml | |
parent | fe1b20f80a2bd1c8c19b8cdb59c04ec2095794d4 (diff) | |
download | ast2050-yocto-poky-49166264bd93d2e4c0b4fcf3641468b37ca18b84.zip ast2050-yocto-poky-49166264bd93d2e4c0b4fcf3641468b37ca18b84.tar.gz |
kernel-dev: Formatting "Machine Branches" section.
(From yocto-docs rev: 30a0d3c1ef3d91221ce3f90a3fd2f4b93bff1c30)
Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation/kernel-dev/kernel-dev-advanced.xml')
-rw-r--r-- | documentation/kernel-dev/kernel-dev-advanced.xml | 182 |
1 files changed, 182 insertions, 0 deletions
diff --git a/documentation/kernel-dev/kernel-dev-advanced.xml b/documentation/kernel-dev/kernel-dev-advanced.xml index ee90df2..dbc3dfb 100644 --- a/documentation/kernel-dev/kernel-dev-advanced.xml +++ b/documentation/kernel-dev/kernel-dev-advanced.xml @@ -1308,6 +1308,188 @@ the KTYPE has changed, now set to "tiny". </section> </section> + + + +<section id='machine-branches'> + <title>Machine Branches</title> + + <para> + The "<link linkend='using-metadata-in-a-recipe'>Using Metadata in a Recipe</link>" + section introduced the <filename>KBRANCH</filename> variable, which + defines the source branch to use from the Linux kernel Git repository + you are using. + Many linux-yocto-custom derived recipes will be using Linux kernel + sources with only a single branch: "master". + However, when you are working with multiple boards and architectures, + you are likely to run into the situation where a series of patches + are needed for one board to boot. + Sometimes, these patches are works-in-progress or fundamentally wrong, + yet still necessary for specific boards. + In these situations, you most likely do not want to include these + patches in every kernel you build. + You have a couple of options. + </para> + + <para> + First, you could encapsulate these patches in a feature description + and only include them in the BSP description for the board(s) that + require them. + For more information, see the + "<link linkend='patches'>Patches</link>" and + "<link linkend='bsp-descriptions'>BSP Descriptions</link>" sections. + </para> + + <para> + Alternatively, you can create a branch in your Linux kernel sources + and apply the patches there. + You can then specify this new branch as the + <filename>KBRANCH</filename> to use for this board. + You can do this in the recipe with the + <filename>KBRANCH</filename> variable: + <literallayout class='monospaced'> + KBRANCH = "mynewbranch" + </literallayout> + or in the BSP description using the "branch" command: + <literallayout class='monospaced'> + mybsp.scc: + define KMACHINE mybsp + define KTYPE standard + define KARCH i386 + include standard.scc + + branch mynewbranch + + include mybsp.scc + </literallayout> + </para> + + <para> + The approach you take, feature or branch, is entirely up to you + and depends on what works best for your development model. + If you are actively working on board support, you may find that + working within a branch is more practical than trying to continually + reintegrate your patches into a feature. + On the other hand, if you are simply reusing some patches from an + external tree and are not working on them, you may find the + encapsulated feature to be appropriate as it does not require the + additional complexity of branching in your Linux kernel sources. + </para> + + <para> + If you are supporting multiple boards and architectures and find + yourself with numerous branches, you might consider using a + hierarchical branching system similar to what the linux-yocto Linux + kernel repositories use: + <literallayout class='monospaced'> + <common>/<ktype>/<machine> + </literallayout> + </para> + + <para> + If you had two ktypes, standard and small for instance, and three + machines, your Git tree might look like this: + <literallayout class='monospaced'> + common/base + common/standard/base + common/standard/machine_a + common/standard/machine_b + common/standard/machine_c + common/small/base + common/small/machine_a + </literallayout> + </para> + + <para> + This organization can help clarify the relationship of the branches to + each other. + In this case, "common/standard/machine_a" would include everything in + "common/base" and "common/standard/base". + The "standard" and "small" branches add sources specific to those + kernel types that for whatever reason are not appropriate for the + other branches. + <note>The "base" branches are an artifact of the way Git manages + its data internally on the filesystem: it will not allow you to use + "common/standard" and "common/standard/machine_a" because it + would have to create a file and a directory named "standard". + </note> + </para> + + <para> + Original text: + <literallayout class='monospaced'> +Section 3.1 introduced the KBRANCH variable which defines the source branch to +use from the Linux kernel git repository you are using. Many linux-yocto-custom +derived recipes will be using Linux kernel sources with only a single branch: +"master". However, when you are working with multiple boards and architectures, +you are likely to run into the situation where a series of patches are needed +for one board to boot. Sometimes these patches are works in progress or +fundamentally wrong, yet still necessary for specific boards. In these +situations, you most likely do not want to include these patches in every kernel +you build. You have a couple of options. + +First, you could encapsulate these patches in a feature description and only +include them in the BSP description for the board(s) that require them (see +3.3.2 and 3.3.5). + +Alternatively, you can create a branch in your Linux kernel sources and apply +the patches there. You can then specify this new branch as the KBRANCH to use +for this board. You can do this in the recipe with the KBRANCH variable: + + KBRANCH = "mynewbranch" + +or in the BSP description using the "branch" command: + +mybsp.scc: + define KMACHINE mybsp + define KTYPE standard + define KARCH i386 + include standard.scc + + branch mynewbranch + + include mybsp.scc + +The decision of which approach to take, feature or branch, is entirely up to you +and depends on what works best for your development model. If you are actively +working on board support, you may find that working within a branch is more +practical than trying to continually reintegrate your patches into a feature. On +the other hand, if you are simply reusing some patches from an external tree and +are not working on them, you may find the encapsulated feature to be appropriate +as it does not require the additional complexity of branching in your Linux +kernel sources. + +If you are supporting multiple boards and architectures and find yourself with +numerous branches, you might consider using a hierarchical branching system +similar to what the linux-yocto Linux kernel repositories use: + + <common>/<ktype>/<machine> + +If you had two ktypes, standard and small for instance, and three machines, your +git tree might look like this: + + common/base + common/standard/base + common/standard/machine_a + common/standard/machine_b + common/standard/machine_c + common/small/base + common/small/machine_a + +This organization can help clarify the relationship of the branches to +each other. In this case, "common/standard/machine_a" would include everything in +"common/base" and "common/standard/base". The "standard" and "small" branches +add sources specific to those kernel types that for whatever reason are not +appropriate for the other branches. + +Note: The "base" branches are an artifact of the way git manages its data + internally on the filesystem: it will not allow you to use + "common/standard" and "common/standard/machine_a" because it would have to + create a file and a directory named "standard". + </literallayout> + </para> +</section> + </chapter> <!-- vim: expandtab tw=80 ts=4 |