From b663741f7fa93af2953a7546ac1951f8f4952546 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Thu, 10 Jan 2013 08:48:27 -0800 Subject: kernel-dev: Edits in the Branch section. simple edits. (From yocto-docs rev: 3f73e53c9bdbe71f04400aedc042f19a48ea62bb) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/kernel-dev/kernel-dev-advanced.xml | 105 +++++++++++------------ 1 file changed, 50 insertions(+), 55 deletions(-) (limited to 'documentation') diff --git a/documentation/kernel-dev/kernel-dev-advanced.xml b/documentation/kernel-dev/kernel-dev-advanced.xml index d02654f13a..0c9808c35e 100644 --- a/documentation/kernel-dev/kernel-dev-advanced.xml +++ b/documentation/kernel-dev/kernel-dev-advanced.xml @@ -1377,54 +1377,39 @@ the KTYPE has changed, now set to "tiny". Working with Branches - We need a top-level section here that introduces branches in general. - There is information that can be pulled from the embedded machine - and feature sections to introduce this stuff. - The two subsections should deal with each type of specific branch - that can be used. + 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. -
- Machine Branches - - - The "Using Kernel Metadata in a Recipe" - section 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. - For more information, see the - "Patches" and - "BSP Descriptions" sections. - + + 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 + "Patches" and + "BSP Descriptions" sections. + - - 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: - + + 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: - + + or in the BSP description using the "branch" command: + mybsp.scc: define KMACHINE mybsp define KTYPE standard @@ -1434,19 +1419,29 @@ the KTYPE has changed, now set to "tiny". branch mynewbranch include mybsp-hw.scc - - + + + + + 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. + + +
+ Machine Branches - 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. + The "Using Kernel Metadata in a Recipe" + section introduced the KBRANCH variable, which + defines the source branch to use from the Linux kernel Git repository + you are using. -- cgit v1.2.3-54-g00ecf