summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorScott Rifenbark <scott.m.rifenbark@intel.com>2013-01-10 08:48:27 -0800
committerRichard Purdie <richard.purdie@linuxfoundation.org>2013-01-16 15:59:18 +0000
commitb663741f7fa93af2953a7546ac1951f8f4952546 (patch)
treef71619874a4811bea0a330a180a105af774224b2
parent7eccfa6849a3ee870ceb59a28f590f6cfcb305fb (diff)
downloadpoky-b663741f7fa93af2953a7546ac1951f8f4952546.tar.gz
kernel-dev: Edits in the Branch section.
simple edits. (From yocto-docs rev: 3f73e53c9bdbe71f04400aedc042f19a48ea62bb) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
-rw-r--r--documentation/kernel-dev/kernel-dev-advanced.xml105
1 files changed, 50 insertions, 55 deletions
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".
1377 <title>Working with Branches</title> 1377 <title>Working with Branches</title>
1378 1378
1379 <para> 1379 <para>
1380 We need a top-level section here that introduces branches in general. 1380 Many linux-yocto-custom derived recipes will be using Linux kernel
1381 There is information that can be pulled from the embedded machine 1381 sources with only a single branch: "master".
1382 and feature sections to introduce this stuff. 1382 However, when you are working with multiple boards and architectures,
1383 The two subsections should deal with each type of specific branch 1383 you are likely to run into the situation where a series of patches
1384 that can be used. 1384 are needed for one board to boot.
1385 Sometimes, these patches are works-in-progress or fundamentally wrong,
1386 yet still necessary for specific boards.
1387 In these situations, you most likely do not want to include these
1388 patches in every kernel you build.
1389 You have a couple of options.
1385 </para> 1390 </para>
1386 1391
1387 <section id='machine-branches'> 1392 <para>
1388 <title>Machine Branches</title> 1393 First, you could encapsulate these patches in a feature description
1389 1394 and only include them in the BSP description for the board(s) that
1390 <para> 1395 require them.
1391 The "<link linkend='using-kernel-metadata-in-a-recipe'>Using Kernel Metadata in a Recipe</link>" 1396 For more information, see the
1392 section introduced the <filename>KBRANCH</filename> variable, which 1397 "<link linkend='patches'>Patches</link>" and
1393 defines the source branch to use from the Linux kernel Git repository 1398 "<link linkend='bsp-descriptions'>BSP Descriptions</link>" sections.
1394 you are using. 1399 </para>
1395 Many linux-yocto-custom derived recipes will be using Linux kernel
1396 sources with only a single branch: "master".
1397 However, when you are working with multiple boards and architectures,
1398 you are likely to run into the situation where a series of patches
1399 are needed for one board to boot.
1400 Sometimes, these patches are works-in-progress or fundamentally wrong,
1401 yet still necessary for specific boards.
1402 In these situations, you most likely do not want to include these
1403 patches in every kernel you build.
1404 You have a couple of options.
1405 </para>
1406
1407 <para>
1408 First, you could encapsulate these patches in a feature description
1409 and only include them in the BSP description for the board(s) that
1410 require them.
1411 For more information, see the
1412 "<link linkend='patches'>Patches</link>" and
1413 "<link linkend='bsp-descriptions'>BSP Descriptions</link>" sections.
1414 </para>
1415 1400
1416 <para> 1401 <para>
1417 Alternatively, you can create a branch in your Linux kernel sources 1402 Alternatively, you can create a branch in your Linux kernel sources
1418 and apply the patches there. 1403 and apply the patches there.
1419 You can then specify this new branch as the 1404 You can then specify this new branch as the
1420 <filename>KBRANCH</filename> to use for this board. 1405 <filename>KBRANCH</filename> to use for this board.
1421 You can do this in the recipe with the 1406 You can do this in the recipe with the
1422 <filename>KBRANCH</filename> variable: 1407 <filename>KBRANCH</filename> variable:
1423 <literallayout class='monospaced'> 1408 <literallayout class='monospaced'>
1424 KBRANCH = "mynewbranch" 1409 KBRANCH = "mynewbranch"
1425 </literallayout> 1410 </literallayout>
1426 or in the BSP description using the "branch" command: 1411 or in the BSP description using the "branch" command:
1427 <literallayout class='monospaced'> 1412 <literallayout class='monospaced'>
1428 mybsp.scc: 1413 mybsp.scc:
1429 define KMACHINE mybsp 1414 define KMACHINE mybsp
1430 define KTYPE standard 1415 define KTYPE standard
@@ -1434,19 +1419,29 @@ the KTYPE has changed, now set to "tiny".
1434 branch mynewbranch 1419 branch mynewbranch
1435 1420
1436 include mybsp-hw.scc 1421 include mybsp-hw.scc
1437 </literallayout> 1422 </literallayout>
1438 </para> 1423 </para>
1424
1425 <para>
1426 The approach you take, feature or branch, is entirely up to you
1427 and depends on what works best for your development model.
1428 If you are actively working on board support, you may find that
1429 working within a branch is more practical than trying to continually
1430 reintegrate your patches into a feature.
1431 On the other hand, if you are simply reusing some patches from an
1432 external tree and are not working on them, you may find the
1433 encapsulated feature to be appropriate as it does not require the
1434 additional complexity of branching in your Linux kernel sources.
1435 </para>
1436
1437 <section id='machine-branches'>
1438 <title>Machine Branches</title>
1439 1439
1440 <para> 1440 <para>
1441 The approach you take, feature or branch, is entirely up to you 1441 The "<link linkend='using-kernel-metadata-in-a-recipe'>Using Kernel Metadata in a Recipe</link>"
1442 and depends on what works best for your development model. 1442 section introduced the <filename>KBRANCH</filename> variable, which
1443 If you are actively working on board support, you may find that 1443 defines the source branch to use from the Linux kernel Git repository
1444 working within a branch is more practical than trying to continually 1444 you are using.
1445 reintegrate your patches into a feature.
1446 On the other hand, if you are simply reusing some patches from an
1447 external tree and are not working on them, you may find the
1448 encapsulated feature to be appropriate as it does not require the
1449 additional complexity of branching in your Linux kernel sources.
1450 </para> 1445 </para>
1451 1446
1452 <para> 1447 <para>