Patrick Williams | c124f4f | 2015-09-15 14:41:29 -0500 | [diff] [blame] | 1 | <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" |
| 2 | "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" |
| 3 | [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] > |
| 4 | |
| 5 | <chapter id='kernel-dev-advanced'> |
| 6 | <title>Working with Advanced Metadata</title> |
| 7 | |
| 8 | <section id='kernel-dev-advanced-overview'> |
| 9 | <title>Overview</title> |
| 10 | |
| 11 | <para> |
| 12 | In addition to supporting configuration fragments and patches, the |
| 13 | Yocto Project kernel tools also support rich |
| 14 | <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink> that you can |
| 15 | use to define complex policies and Board Support Package (BSP) support. |
| 16 | The purpose of the Metadata and the tools that manage it, known as |
| 17 | the kern-tools (<filename>kern-tools-native_git.bb</filename>), is |
| 18 | to help you manage the complexity of the configuration and sources |
| 19 | used to support multiple BSPs and Linux kernel types. |
| 20 | </para> |
| 21 | </section> |
| 22 | |
| 23 | <section id='using-kernel-metadata-in-a-recipe'> |
| 24 | <title>Using Kernel Metadata in a Recipe</title> |
| 25 | |
| 26 | <para> |
| 27 | The kernel sources in the Yocto Project contain kernel Metadata, which |
| 28 | is located in the <filename>meta</filename> branches of the kernel |
| 29 | source Git repositories. |
| 30 | This Metadata defines Board Support Packages (BSPs) that |
| 31 | correspond to definitions in linux-yocto recipes for the same BSPs. |
| 32 | A BSP consists of an aggregation of kernel policy and hardware-specific |
| 33 | feature enablements. |
| 34 | The BSP can be influenced from within the linux-yocto recipe. |
| 35 | <note> |
| 36 | Linux kernel source that contains kernel Metadata is said to be |
| 37 | "linux-yocto style" kernel source. |
| 38 | A Linux kernel recipe that inherits from the |
| 39 | <filename>linux-yocto.inc</filename> include file is said to be a |
| 40 | "linux-yocto style" recipe. |
| 41 | </note> |
| 42 | </para> |
| 43 | |
| 44 | <para> |
| 45 | Every linux-yocto style recipe must define the |
| 46 | <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink> |
| 47 | variable. |
| 48 | This variable is typically set to the same value as the |
| 49 | <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink> |
| 50 | variable, which is used by |
| 51 | <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>. |
| 52 | However, in some cases, the variable might instead refer to the |
| 53 | underlying platform of the <filename>MACHINE</filename>. |
| 54 | </para> |
| 55 | |
| 56 | <para> |
| 57 | Multiple BSPs can reuse the same <filename>KMACHINE</filename> |
| 58 | name if they are built using the same BSP description. |
| 59 | The "ep108-zynqmp" and "qemuzynqmp" BSP combination |
| 60 | in the <filename>meta-xilinx</filename> |
| 61 | layer is a good example of two BSPs using the same |
| 62 | <filename>KMACHINE</filename> value (i.e. "zynqmp"). |
| 63 | See the <link linkend='bsp-descriptions'>BSP Descriptions</link> section |
| 64 | for more information. |
| 65 | </para> |
| 66 | |
| 67 | <para> |
| 68 | Every linux-yocto style recipe must also indicate the Linux kernel |
| 69 | source repository branch used to build the Linux kernel. |
| 70 | The <ulink url='&YOCTO_DOCS_REF_URL;#var-KBRANCH'><filename>KBRANCH</filename></ulink> |
| 71 | variable must be set to indicate the branch. |
| 72 | <note> |
| 73 | You can use the <filename>KBRANCH</filename> value to define an |
| 74 | alternate branch typically with a machine override as shown here |
| 75 | from the <filename>meta-emenlow</filename> layer: |
| 76 | <literallayout class='monospaced'> |
| 77 | KBRANCH_emenlow-noemgd = "standard/base" |
| 78 | </literallayout> |
| 79 | </note> |
| 80 | </para> |
| 81 | |
| 82 | <para> |
| 83 | The linux-yocto style recipes can optionally define the following |
| 84 | variables: |
| 85 | <literallayout class='monospaced'> |
| 86 | <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'>KERNEL_FEATURES</ulink> |
| 87 | <ulink url='&YOCTO_DOCS_REF_URL;#var-LINUX_KERNEL_TYPE'>LINUX_KERNEL_TYPE</ulink> |
| 88 | </literallayout> |
| 89 | </para> |
| 90 | |
| 91 | <para> |
| 92 | <filename>LINUX_KERNEL_TYPE</filename> defines the kernel type to be |
| 93 | used in assembling the configuration. |
| 94 | If you do not specify a <filename>LINUX_KERNEL_TYPE</filename>, |
| 95 | it defaults to "standard". |
| 96 | Together with |
| 97 | <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>, |
| 98 | <filename>LINUX_KERNEL_TYPE</filename> defines the search |
| 99 | arguments used by the kernel tools to find the |
| 100 | appropriate description within the kernel Metadata with which to |
| 101 | build out the sources and configuration. |
| 102 | The linux-yocto recipes define "standard", "tiny", and "preempt-rt" |
| 103 | kernel types. |
| 104 | See the "<link linkend='kernel-types'>Kernel Types</link>" section |
| 105 | for more information on kernel types. |
| 106 | </para> |
| 107 | |
| 108 | <para> |
| 109 | During the build, the kern-tools search for the BSP description |
| 110 | file that most closely matches the <filename>KMACHINE</filename> |
| 111 | and <filename>LINUX_KERNEL_TYPE</filename> variables passed in from the |
| 112 | recipe. |
| 113 | The tools use the first BSP description it finds that match |
| 114 | both variables. |
| 115 | If the tools cannot find a match, they issue a warning such as |
| 116 | the following: |
| 117 | <literallayout class='monospaced'> |
| 118 | WARNING: Can't find any BSP hardware or required configuration fragments. |
| 119 | WARNING: Looked at meta/cfg/broken/emenlow-broken/hdw_frags.txt and |
| 120 | meta/cfg/broken/emenlow-broken/required_frags.txt in directory: |
| 121 | meta/cfg/broken/emenlow-broken |
| 122 | </literallayout> |
| 123 | In this example, <filename>KMACHINE</filename> was set to "emenlow-broken" |
| 124 | and <filename>LINUX_KERNEL_TYPE</filename> was set to "broken". |
| 125 | </para> |
| 126 | |
| 127 | <para> |
| 128 | The tools first search for the <filename>KMACHINE</filename> and |
| 129 | then for the <filename>LINUX_KERNEL_TYPE</filename>. |
| 130 | If the tools cannot find a partial match, they will use the |
| 131 | sources from the <filename>KBRANCH</filename> and any configuration |
| 132 | specified in the |
| 133 | <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>. |
| 134 | </para> |
| 135 | |
| 136 | <para> |
| 137 | You can use the <filename>KERNEL_FEATURES</filename> variable |
| 138 | to include features (configuration fragments, patches, or both) that |
| 139 | are not already included by the <filename>KMACHINE</filename> and |
| 140 | <filename>LINUX_KERNEL_TYPE</filename> variable combination. |
| 141 | For example, to include a feature specified as |
| 142 | "features/netfilter/netfilter.scc", |
| 143 | specify: |
| 144 | <literallayout class='monospaced'> |
| 145 | KERNEL_FEATURES += "features/netfilter/netfilter.scc" |
| 146 | </literallayout> |
| 147 | To include a feature called "cfg/sound.scc" just for the |
| 148 | <filename>qemux86</filename> machine, specify: |
| 149 | <literallayout class='monospaced'> |
| 150 | KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc" |
| 151 | </literallayout> |
| 152 | The value of the entries in <filename>KERNEL_FEATURES</filename> |
| 153 | are dependent on their location within the kernel Metadata itself. |
| 154 | The examples here are taken from the <filename>meta</filename> |
| 155 | branch of the <filename>linux-yocto-3.19</filename> repository. |
| 156 | Within that branch, "features" and "cfg" are subdirectories of the |
| 157 | <filename>meta/cfg/kernel-cache</filename> directory. |
| 158 | For more information, see the |
| 159 | "<link linkend='kernel-metadata-syntax'>Kernel Metadata Syntax</link>" section. |
| 160 | <note> |
| 161 | The processing of the these variables has evolved some between the |
| 162 | 0.9 and 1.3 releases of the Yocto Project and associated |
| 163 | kern-tools sources. |
| 164 | The descriptions in this section are accurate for 1.3 and later |
| 165 | releases of the Yocto Project. |
| 166 | </note> |
| 167 | </para> |
| 168 | </section> |
| 169 | |
| 170 | <section id='kernel-metadata-location'> |
| 171 | <title>Kernel Metadata Location</title> |
| 172 | |
| 173 | <para> |
| 174 | Kernel Metadata can be defined in either the kernel recipe |
| 175 | (recipe-space) or in the kernel tree (in-tree). |
| 176 | Where you choose to define the Metadata depends on what you want |
| 177 | to do and how you intend to work. |
| 178 | Regardless of where you define the kernel Metadata, the syntax used |
| 179 | applies equally. |
| 180 | </para> |
| 181 | |
| 182 | <para> |
| 183 | If you are unfamiliar with the Linux kernel and only wish |
| 184 | to apply a configuration and possibly a couple of patches provided to |
| 185 | you by others, the recipe-space method is recommended. |
| 186 | This method is also a good approach if you are working with Linux kernel |
| 187 | sources you do not control or if you just do not want to maintain a |
| 188 | Linux kernel Git repository on your own. |
| 189 | For partial information on how you can define kernel Metadata in |
| 190 | the recipe-space, see the |
| 191 | "<link linkend='modifying-an-existing-recipe'>Modifying an Existing Recipe</link>" |
| 192 | section. |
| 193 | </para> |
| 194 | |
| 195 | <para> |
| 196 | Conversely, if you are actively developing a kernel and are already |
| 197 | maintaining a Linux kernel Git repository of your own, you might find |
| 198 | it more convenient to work with the kernel Metadata in the same |
| 199 | repository as the Linux kernel sources. |
| 200 | This method can make iterative development of the Linux kernel |
| 201 | more efficient outside of the BitBake environment. |
| 202 | </para> |
| 203 | |
| 204 | <section id='recipe-space-metadata'> |
| 205 | <title>Recipe-Space Metadata</title> |
| 206 | |
| 207 | <para> |
| 208 | When stored in recipe-space, the kernel Metadata files reside in a |
| 209 | directory hierarchy below |
| 210 | <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>. |
| 211 | For a linux-yocto recipe or for a Linux kernel recipe derived |
| 212 | by copying and modifying |
| 213 | <filename>oe-core/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb</filename> |
| 214 | to a recipe in your layer, <filename>FILESEXTRAPATHS</filename> |
| 215 | is typically set to |
| 216 | <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-THISDIR'><filename>THISDIR</filename></ulink><filename>}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>. |
| 217 | See the "<link linkend='modifying-an-existing-recipe'>Modifying an Existing Recipe</link>" |
| 218 | section for more information. |
| 219 | </para> |
| 220 | |
| 221 | <para> |
| 222 | Here is an example that shows a trivial tree of kernel Metadata |
| 223 | stored in recipe-space within a BSP layer: |
| 224 | <literallayout class='monospaced'> |
| 225 | meta-<replaceable>my_bsp_layer</replaceable>/ |
| 226 | `-- recipes-kernel |
| 227 | `-- linux |
| 228 | `-- linux-yocto |
| 229 | |-- bsp-standard.scc |
| 230 | |-- bsp.cfg |
| 231 | `-- standard.cfg |
| 232 | </literallayout> |
| 233 | </para> |
| 234 | |
| 235 | <para> |
| 236 | When the Metadata is stored in recipe-space, you must take |
| 237 | steps to ensure BitBake has the necessary information to decide |
| 238 | what files to fetch and when they need to be fetched again. |
| 239 | It is only necessary to specify the <filename>.scc</filename> |
| 240 | files on the |
| 241 | <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>. |
| 242 | BitBake parses them and fetches any files referenced in the |
| 243 | <filename>.scc</filename> files by the <filename>include</filename>, |
| 244 | <filename>patch</filename>, or <filename>kconf</filename> commands. |
| 245 | Because of this, it is necessary to bump the recipe |
| 246 | <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink> |
| 247 | value when changing the content of files not explicitly listed |
| 248 | in the <filename>SRC_URI</filename>. |
| 249 | </para> |
| 250 | </section> |
| 251 | |
| 252 | <section id='in-tree-metadata'> |
| 253 | <title>In-Tree Metadata</title> |
| 254 | |
| 255 | <para> |
| 256 | When stored in-tree, the kernel Metadata files reside in the |
| 257 | <filename>meta</filename> directory of the Linux kernel sources. |
| 258 | The <filename>meta</filename> directory can be present in the |
| 259 | same repository branch as the sources, |
| 260 | such as "master", or <filename>meta</filename> can be its own |
| 261 | orphan branch. |
| 262 | <note> |
| 263 | An orphan branch in Git is a branch with unique history and |
| 264 | content to the other branches in the repository. |
| 265 | Orphan branches are useful to track Metadata changes |
| 266 | independently from the sources of the Linux kernel, while |
| 267 | still keeping them together in the same repository. |
| 268 | </note> |
| 269 | For the purposes of this document, we will discuss all |
| 270 | in-tree Metadata as residing below the |
| 271 | <filename>meta/cfg/kernel-cache</filename> directory. |
| 272 | </para> |
| 273 | |
| 274 | <para> |
| 275 | Following is an example that shows how a trivial tree of Metadata |
| 276 | is stored in a custom Linux kernel Git repository: |
| 277 | <literallayout class='monospaced'> |
| 278 | meta/ |
| 279 | `-- cfg |
| 280 | `-- kernel-cache |
| 281 | |-- bsp-standard.scc |
| 282 | |-- bsp.cfg |
| 283 | `-- standard.cfg |
| 284 | </literallayout> |
| 285 | </para> |
| 286 | |
| 287 | <para> |
| 288 | To use a branch different from where the sources reside, |
| 289 | specify the branch in the <filename>KMETA</filename> variable |
| 290 | in your Linux kernel recipe. |
| 291 | Here is an example: |
| 292 | <literallayout class='monospaced'> |
| 293 | KMETA = "meta" |
| 294 | </literallayout> |
| 295 | To use the same branch as the sources, set |
| 296 | <filename>KMETA</filename> to an empty string: |
| 297 | <literallayout class='monospaced'> |
| 298 | KMETA = "" |
| 299 | </literallayout> |
| 300 | If you are working with your own sources and want to create an |
| 301 | orphan <filename>meta</filename> branch, use these commands |
| 302 | from within your Linux kernel Git repository: |
| 303 | <literallayout class='monospaced'> |
| 304 | $ git checkout --orphan meta |
| 305 | $ git rm -rf . |
| 306 | $ git commit --allow-empty -m "Create orphan meta branch" |
| 307 | </literallayout> |
| 308 | </para> |
| 309 | |
| 310 | <para> |
| 311 | If you modify the Metadata in the linux-yocto |
| 312 | <filename>meta</filename> branch, you must not forget to update |
| 313 | the |
| 314 | <ulink url='&YOCTO_DOCS_REF_URL;#var-SRCREV'><filename>SRCREV</filename></ulink> |
| 315 | statements in the kernel's recipe. |
| 316 | In particular, you need to update the |
| 317 | <filename>SRCREV_meta</filename> variable to match the commit in |
| 318 | the <filename>KMETA</filename> branch you wish to use. |
| 319 | Changing the data in these branches and not updating the |
| 320 | <filename>SRCREV</filename> statements to match will cause the |
| 321 | build to fetch an older commit. |
| 322 | </para> |
| 323 | </section> |
| 324 | </section> |
| 325 | |
| 326 | <section id='kernel-metadata-syntax'> |
| 327 | <title>Kernel Metadata Syntax</title> |
| 328 | |
| 329 | <para> |
| 330 | The kernel Metadata consists of three primary types of files: |
| 331 | <filename>scc</filename> |
| 332 | <footnote> |
| 333 | <para> |
| 334 | <filename>scc</filename> stands for Series Configuration |
| 335 | Control, but the naming has less significance in the |
| 336 | current implementation of the tooling than it had in the |
| 337 | past. |
| 338 | Consider <filename>scc</filename> files to be description files. |
| 339 | </para> |
| 340 | </footnote> |
| 341 | description files, configuration fragments, and patches. |
| 342 | The <filename>scc</filename> files define variables and include or |
| 343 | otherwise reference any of the three file types. |
| 344 | The description files are used to aggregate all types of kernel |
| 345 | Metadata into |
| 346 | what ultimately describes the sources and the configuration required |
| 347 | to build a Linux kernel tailored to a specific machine. |
| 348 | </para> |
| 349 | |
| 350 | <para> |
| 351 | The <filename>scc</filename> description files are used to define two |
| 352 | fundamental types of kernel Metadata: |
| 353 | <itemizedlist> |
| 354 | <listitem><para>Features</para></listitem> |
| 355 | <listitem><para>Board Support Packages (BSPs)</para></listitem> |
| 356 | </itemizedlist> |
| 357 | </para> |
| 358 | |
| 359 | <para> |
| 360 | Features aggregate sources in the form of patches and configuration |
| 361 | fragments into a modular reusable unit. |
| 362 | You can use features to implement conceptually separate kernel |
| 363 | Metadata descriptions such as pure configuration fragments, |
| 364 | simple patches, complex features, and kernel types. |
| 365 | <link linkend='kernel-types'>Kernel types</link> define general |
| 366 | kernel features and policy to be reused in the BSPs. |
| 367 | </para> |
| 368 | |
| 369 | <para> |
| 370 | BSPs define hardware-specific features and aggregate them with kernel |
| 371 | types to form the final description of what will be assembled and built. |
| 372 | </para> |
| 373 | |
| 374 | <para> |
| 375 | While the kernel Metadata syntax does not enforce any logical |
| 376 | separation of configuration fragments, patches, features or kernel |
| 377 | types, best practices dictate a logical separation of these types |
| 378 | of Metadata. |
| 379 | The following Metadata file hierarchy is recommended: |
| 380 | <literallayout class='monospaced'> |
| 381 | <replaceable>base</replaceable>/ |
| 382 | bsp/ |
| 383 | cfg/ |
| 384 | features/ |
| 385 | ktypes/ |
| 386 | patches/ |
| 387 | </literallayout> |
| 388 | </para> |
| 389 | |
| 390 | <para> |
| 391 | The <filename>bsp</filename> directory contains the |
| 392 | <link linkend='bsp-descriptions'>BSP descriptions</link>. |
| 393 | The remaining directories all contain "features". |
| 394 | Separating <filename>bsp</filename> from the rest of the structure |
| 395 | aids conceptualizing intended usage. |
| 396 | </para> |
| 397 | |
| 398 | <para> |
| 399 | Use these guidelines to help place your <filename>scc</filename> |
| 400 | description files within the structure: |
| 401 | <itemizedlist> |
| 402 | <listitem><para>If your file contains |
| 403 | only configuration fragments, place the file in the |
| 404 | <filename>cfg</filename> directory.</para></listitem> |
| 405 | <listitem><para>If your file contains |
| 406 | only source-code fixes, place the file in the |
| 407 | <filename>patches</filename> directory.</para></listitem> |
| 408 | <listitem><para>If your file encapsulates |
| 409 | a major feature, often combining sources and configurations, |
| 410 | place the file in <filename>features</filename> directory. |
| 411 | </para></listitem> |
| 412 | <listitem><para>If your file aggregates |
| 413 | non-hardware configuration and patches in order to define a |
| 414 | base kernel policy or major kernel type to be reused across |
| 415 | multiple BSPs, place the file in <filename>ktypes</filename> |
| 416 | directory. |
| 417 | </para></listitem> |
| 418 | </itemizedlist> |
| 419 | </para> |
| 420 | |
| 421 | <para> |
| 422 | These distinctions can easily become blurred - especially as |
| 423 | out-of-tree features slowly merge upstream over time. |
| 424 | Also, remember that how the description files are placed is |
| 425 | a purely logical organization and has no impact on the functionality |
| 426 | of the kernel Metadata. |
| 427 | There is no impact because all of <filename>cfg</filename>, |
| 428 | <filename>features</filename>, <filename>patches</filename>, and |
| 429 | <filename>ktypes</filename>, contain "features" as far as the kernel |
| 430 | tools are concerned. |
| 431 | </para> |
| 432 | |
| 433 | <para> |
| 434 | Paths used in kernel Metadata files are relative to |
| 435 | <filename><base></filename>, which is either |
| 436 | <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink> |
| 437 | if you are creating Metadata in |
| 438 | <link linkend='recipe-space-metadata'>recipe-space</link>, |
| 439 | or <filename>meta/cfg/kernel-cache/</filename> if you are creating |
| 440 | Metadata <link linkend='in-tree-metadata'>in-tree</link>. |
| 441 | </para> |
| 442 | |
| 443 | <section id='configuration'> |
| 444 | <title>Configuration</title> |
| 445 | |
| 446 | <para> |
| 447 | The simplest unit of kernel Metadata is the configuration-only |
| 448 | feature. |
| 449 | This feature consists of one or more Linux kernel configuration |
| 450 | parameters in a configuration fragment file |
| 451 | (<filename>.cfg</filename>) and a <filename>.scc</filename> file |
| 452 | that describes the fragment. |
| 453 | </para> |
| 454 | |
| 455 | <para> |
| 456 | The Symmetric Multi-Processing (SMP) fragment included in the |
| 457 | <filename>linux-yocto-3.19</filename> Git repository |
| 458 | consists of the following two files: |
| 459 | <literallayout class='monospaced'> |
| 460 | cfg/smp.scc: |
| 461 | define KFEATURE_DESCRIPTION "Enable SMP" |
| 462 | define KFEATURE_COMPATIBILITY all |
| 463 | |
| 464 | kconf hardware smp.cfg |
| 465 | |
| 466 | cfg/smp.cfg: |
| 467 | CONFIG_SMP=y |
| 468 | CONFIG_SCHED_SMT=y |
| 469 | # Increase default NR_CPUS from 8 to 64 so that platform with |
| 470 | # more than 8 processors can be all activated at boot time |
| 471 | CONFIG_NR_CPUS=64 |
| 472 | </literallayout> |
| 473 | You can find information on configuration fragment files in the |
| 474 | "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-config-fragments'>Creating Configuration Fragments</ulink>" |
| 475 | section of the Yocto Project Development Manual and in |
| 476 | the "<link linkend='generating-configuration-files'>Generating Configuration Files</link>" |
| 477 | section earlier in this manual. |
| 478 | </para> |
| 479 | |
| 480 | <para> |
| 481 | <ulink url='&YOCTO_DOCS_REF_URL;#var-KFEATURE_DESCRIPTION'><filename>KFEATURE_DESCRIPTION</filename></ulink> |
| 482 | provides a short description of the fragment. |
| 483 | Higher level kernel tools use this description. |
| 484 | </para> |
| 485 | |
| 486 | <para> |
| 487 | The <filename>kconf</filename> command is used to include the |
| 488 | actual configuration fragment in an <filename>.scc</filename> |
| 489 | file, and the "hardware" keyword identifies the fragment as |
| 490 | being hardware enabling, as opposed to general policy, |
| 491 | which would use the "non-hardware" keyword. |
| 492 | The distinction is made for the benefit of the configuration |
| 493 | validation tools, which warn you if a hardware fragment |
| 494 | overrides a policy set by a non-hardware fragment. |
| 495 | <note> |
| 496 | The description file can include multiple |
| 497 | <filename>kconf</filename> statements, one per fragment. |
| 498 | </note> |
| 499 | </para> |
| 500 | |
| 501 | <para> |
| 502 | As described in the |
| 503 | "<link linkend='generating-configuration-files'>Generating Configuration Files</link>" |
| 504 | section, you can use the following BitBake command to audit your |
| 505 | configuration: |
| 506 | <literallayout class='monospaced'> |
| 507 | $ bitbake linux-yocto -c kernel_configcheck -f |
| 508 | </literallayout> |
| 509 | </para> |
| 510 | </section> |
| 511 | |
| 512 | <section id='patches'> |
| 513 | <title>Patches</title> |
| 514 | |
| 515 | <para> |
| 516 | Patch descriptions are very similar to configuration fragment |
| 517 | descriptions, which are described in the previous section. |
| 518 | However, instead of a <filename>.cfg</filename> file, these |
| 519 | descriptions work with source patches. |
| 520 | </para> |
| 521 | |
| 522 | <para> |
| 523 | A typical patch includes a description file and the patch itself: |
| 524 | <literallayout class='monospaced'> |
| 525 | patches/mypatch.scc: |
| 526 | patch mypatch.patch |
| 527 | |
| 528 | patches/mypatch.patch: |
| 529 | <replaceable>typical-patch</replaceable> |
| 530 | </literallayout> |
| 531 | You can create the typical <filename>.patch</filename> |
| 532 | file using <filename>diff -Nurp</filename> or |
| 533 | <filename>git format-patch</filename>. |
| 534 | </para> |
| 535 | |
| 536 | <para> |
| 537 | The description file can include multiple patch statements, |
| 538 | one per patch. |
| 539 | </para> |
| 540 | </section> |
| 541 | |
| 542 | <section id='features'> |
| 543 | <title>Features</title> |
| 544 | |
| 545 | <para> |
| 546 | Features are complex kernel Metadata types that consist |
| 547 | of configuration fragments (<filename>kconf</filename>), patches |
| 548 | (<filename>patch</filename>), and possibly other feature |
| 549 | description files (<filename>include</filename>). |
| 550 | </para> |
| 551 | |
| 552 | <para> |
| 553 | Here is an example that shows a feature description file: |
| 554 | <literallayout class='monospaced'> |
| 555 | features/myfeature.scc |
| 556 | define KFEATURE_DESCRIPTION "Enable myfeature" |
| 557 | |
| 558 | patch 0001-myfeature-core.patch |
| 559 | patch 0002-myfeature-interface.patch |
| 560 | |
| 561 | include cfg/myfeature_dependency.scc |
| 562 | kconf non-hardware myfeature.cfg |
| 563 | </literallayout> |
| 564 | This example shows how the <filename>patch</filename> and |
| 565 | <filename>kconf</filename> commands are used as well as |
| 566 | how an additional feature description file is included. |
| 567 | </para> |
| 568 | |
| 569 | <para> |
| 570 | Typically, features are less granular than configuration |
| 571 | fragments and are more likely than configuration fragments |
| 572 | and patches to be the types of things you want to specify |
| 573 | in the <filename>KERNEL_FEATURES</filename> variable of the |
| 574 | Linux kernel recipe. |
| 575 | See the "<link linkend='using-kernel-metadata-in-a-recipe'>Using Kernel Metadata in a Recipe</link>" |
| 576 | section earlier in the manual. |
| 577 | </para> |
| 578 | </section> |
| 579 | |
| 580 | <section id='kernel-types'> |
| 581 | <title>Kernel Types</title> |
| 582 | |
| 583 | <para> |
| 584 | A kernel type defines a high-level kernel policy by |
| 585 | aggregating non-hardware configuration fragments with |
| 586 | patches you want to use when building a Linux kernels of a |
| 587 | specific type. |
| 588 | Syntactically, kernel types are no different than features |
| 589 | as described in the "<link linkend='features'>Features</link>" |
| 590 | section. |
| 591 | The <filename>LINUX_KERNEL_TYPE</filename> variable in the kernel |
| 592 | recipe selects the kernel type. |
| 593 | See the "<link linkend='using-kernel-metadata-in-a-recipe'>Using Kernel Metadata in a Recipe</link>" |
| 594 | section for more information. |
| 595 | </para> |
| 596 | |
| 597 | <para> |
| 598 | As an example, the <filename>linux-yocto-3.19</filename> |
| 599 | tree defines three kernel types: "standard", |
| 600 | "tiny", and "preempt-rt": |
| 601 | <itemizedlist> |
| 602 | <listitem><para>"standard": |
| 603 | Includes the generic Linux kernel policy of the Yocto |
| 604 | Project linux-yocto kernel recipes. |
| 605 | This policy includes, among other things, which file |
| 606 | systems, networking options, core kernel features, and |
| 607 | debugging and tracing options are supported. |
| 608 | </para></listitem> |
| 609 | <listitem><para>"preempt-rt": |
| 610 | Applies the <filename>PREEMPT_RT</filename> |
| 611 | patches and the configuration options required to |
| 612 | build a real-time Linux kernel. |
| 613 | This kernel type inherits from the "standard" kernel type. |
| 614 | </para></listitem> |
| 615 | <listitem><para>"tiny": |
| 616 | Defines a bare minimum configuration meant to serve as a |
| 617 | base for very small Linux kernels. |
| 618 | The "tiny" kernel type is independent from the "standard" |
| 619 | configuration. |
| 620 | Although the "tiny" kernel type does not currently include |
| 621 | any source changes, it might in the future. |
| 622 | </para></listitem> |
| 623 | </itemizedlist> |
| 624 | </para> |
| 625 | |
| 626 | <para> |
| 627 | The "standard" kernel type is defined by |
| 628 | <filename>standard.scc</filename>: |
| 629 | <literallayout class='monospaced'> |
| 630 | # Include this kernel type fragment to get the standard features and |
| 631 | # configuration values. |
| 632 | |
| 633 | # Include all standard features |
| 634 | include standard-nocfg.scc |
| 635 | |
| 636 | kconf non-hardware standard.cfg |
| 637 | |
| 638 | # individual cfg block section |
| 639 | include cfg/fs/devtmpfs.scc |
| 640 | include cfg/fs/debugfs.scc |
| 641 | include cfg/fs/btrfs.scc |
| 642 | include cfg/fs/ext2.scc |
| 643 | include cfg/fs/ext3.scc |
| 644 | include cfg/fs/ext4.scc |
| 645 | |
| 646 | include cfg/net/ipv6.scc |
| 647 | include cfg/net/ip_nf.scc |
| 648 | include cfg/net/ip6_nf.scc |
| 649 | include cfg/net/bridge.scc |
| 650 | </literallayout> |
| 651 | </para> |
| 652 | |
| 653 | <para> |
| 654 | As with any <filename>.scc</filename> file, a |
| 655 | kernel type definition can aggregate other |
| 656 | <filename>.scc</filename> files with |
| 657 | <filename>include</filename> commands. |
| 658 | These definitions can also directly pull in |
| 659 | configuration fragments and patches with the |
| 660 | <filename>kconf</filename> and <filename>patch</filename> |
| 661 | commands, respectively. |
| 662 | </para> |
| 663 | |
| 664 | <note> |
| 665 | It is not strictly necessary to create a kernel type |
| 666 | <filename>.scc</filename> file. |
| 667 | The Board Support Package (BSP) file can implicitly define |
| 668 | the kernel type using a <filename>define |
| 669 | <ulink url='&YOCTO_DOCS_REF_URL;#var-KTYPE'>KTYPE</ulink> myktype</filename> |
| 670 | line. |
| 671 | See the "<link linkend='bsp-descriptions'>BSP Descriptions</link>" |
| 672 | section for more information. |
| 673 | </note> |
| 674 | </section> |
| 675 | |
| 676 | <section id='bsp-descriptions'> |
| 677 | <title>BSP Descriptions</title> |
| 678 | |
| 679 | <para> |
| 680 | BSP descriptions combine kernel types with hardware-specific |
| 681 | features. |
| 682 | The hardware-specific portion is typically defined |
| 683 | independently, and then aggregated with each supported kernel |
| 684 | type. |
| 685 | Consider this simple BSP description that supports the |
| 686 | <replaceable>mybsp</replaceable> machine: |
| 687 | <literallayout class='monospaced'> |
| 688 | <replaceable>mybsp</replaceable>.scc: |
| 689 | define KMACHINE <replaceable>mybsp</replaceable> |
| 690 | define KTYPE standard |
| 691 | define KARCH i386 |
| 692 | |
| 693 | kconf <replaceable>mybsp</replaceable>.cfg |
| 694 | </literallayout> |
| 695 | Every BSP description should define the |
| 696 | <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>, |
| 697 | <ulink url='&YOCTO_DOCS_REF_URL;#var-KTYPE'><filename>KTYPE</filename></ulink>, |
| 698 | and <ulink url='&YOCTO_DOCS_REF_URL;#var-KARCH'><filename>KARCH</filename></ulink> |
| 699 | variables. |
| 700 | These variables allow the OpenEmbedded build system to identify |
| 701 | the description as meeting the criteria set by the recipe being |
| 702 | built. |
| 703 | This simple example supports the "mybsp" machine for the "standard" |
| 704 | kernel and the "i386" architecture. |
| 705 | </para> |
| 706 | |
| 707 | <para> |
| 708 | Be aware that a hard link between the |
| 709 | <filename>KTYPE</filename> variable and a kernel type |
| 710 | description file does not exist. |
| 711 | Thus, if you do not have kernel types defined in your kernel |
| 712 | Metadata, you only need to ensure that the kernel recipe's |
| 713 | <ulink url='&YOCTO_DOCS_REF_URL;#var-LINUX_KERNEL_TYPE'><filename>LINUX_KERNEL_TYPE</filename></ulink> |
| 714 | variable and the <filename>KTYPE</filename> variable in the |
| 715 | BSP description file match. |
| 716 | <note> |
| 717 | Future versions of the tooling make the specification of |
| 718 | <filename>KTYPE</filename> in the BSP optional. |
| 719 | </note> |
| 720 | </para> |
| 721 | |
| 722 | <para> |
| 723 | If you did want to separate your kernel policy from your |
| 724 | hardware configuration, you could do so by specifying a kernel |
| 725 | type, such as "standard" and including that description file |
| 726 | in the BSP description file. |
| 727 | See the "<link linkend='kernel-types'>Kernel Types</link>" section |
| 728 | for more information. |
| 729 | </para> |
| 730 | |
| 731 | <para> |
| 732 | You might also have multiple hardware configurations that you |
| 733 | aggregate into a single hardware description file that you |
| 734 | could include in the BSP description file, rather than referencing |
| 735 | a single <filename>.cfg</filename> file. |
| 736 | Consider the following: |
| 737 | <literallayout class='monospaced'> |
| 738 | <replaceable>mybsp</replaceable>.scc: |
| 739 | define KMACHINE mybsp |
| 740 | define KTYPE standard |
| 741 | define KARCH i386 |
| 742 | |
| 743 | include standard.scc |
| 744 | include <replaceable>mybsp</replaceable>-hw.scc |
| 745 | </literallayout> |
| 746 | </para> |
| 747 | |
| 748 | <para> |
| 749 | In the above example, <filename>standard.scc</filename> |
| 750 | aggregates all the configuration fragments, patches, and |
| 751 | features that make up your standard kernel policy whereas |
| 752 | <replaceable>mybsp</replaceable><filename>-hw.scc</filename> |
| 753 | aggregates all those necessary |
| 754 | to support the hardware available on the |
| 755 | <replaceable>mybsp</replaceable> machine. |
| 756 | For information on how to break a complete |
| 757 | <filename>.config</filename> file into the various |
| 758 | configuration fragments, see the |
| 759 | "<link linkend='generating-configuration-files'>Generating Configuration Files</link>" |
| 760 | section. |
| 761 | </para> |
| 762 | |
| 763 | <para> |
| 764 | Many real-world examples are more complex. |
| 765 | Like any other <filename>.scc</filename> file, BSP |
| 766 | descriptions can aggregate features. |
| 767 | Consider the Minnow BSP definition from the |
| 768 | <filename>linux-yocto-3.19</filename> |
| 769 | Git repository: |
| 770 | <literallayout class='monospaced'> |
| 771 | minnow.scc: |
| 772 | include cfg/x86.scc |
| 773 | include features/eg20t/eg20t.scc |
| 774 | include cfg/dmaengine.scc |
| 775 | include features/power/intel.scc |
| 776 | include cfg/efi.scc |
| 777 | include features/usb/ehci-hcd.scc |
| 778 | include features/usb/ohci-hcd.scc |
| 779 | include features/usb/usb-gadgets.scc |
| 780 | include features/usb/touchscreen-composite.scc |
| 781 | include cfg/timer/hpet.scc |
| 782 | include cfg/timer/rtc.scc |
| 783 | include features/leds/leds.scc |
| 784 | include features/spi/spidev.scc |
| 785 | include features/i2c/i2cdev.scc |
| 786 | |
| 787 | # Earlyprintk and port debug requires 8250 |
| 788 | kconf hardware cfg/8250.cfg |
| 789 | |
| 790 | kconf hardware minnow.cfg |
| 791 | kconf hardware minnow-dev.cfg |
| 792 | </literallayout> |
| 793 | </para> |
| 794 | |
| 795 | <para> |
| 796 | The <filename>minnow.scc</filename> description file includes |
| 797 | a hardware configuration fragment |
| 798 | (<filename>minnow.cfg</filename>) specific to the Minnow |
| 799 | BSP as well as several more general configuration |
| 800 | fragments and features enabling hardware found on the |
| 801 | machine. |
| 802 | This description file is then included in each of the three |
| 803 | "minnow" description files for the supported kernel types |
| 804 | (i.e. "standard", "preempt-rt", and "tiny"). |
| 805 | Consider the "minnow" description for the "standard" kernel |
| 806 | type: |
| 807 | <literallayout class='monospaced'> |
| 808 | minnow-standard.scc: |
| 809 | define KMACHINE minnow |
| 810 | define KTYPE standard |
| 811 | define KARCH i386 |
| 812 | |
| 813 | include ktypes/standard |
| 814 | |
| 815 | include minnow.scc |
| 816 | |
| 817 | # Extra minnow configs above the minimal defined in minnow.scc |
| 818 | include cfg/efi-ext.scc |
| 819 | include features/media/media-all.scc |
| 820 | include features/sound/snd_hda_intel.scc |
| 821 | |
| 822 | # The following should really be in standard.scc |
| 823 | # USB live-image support |
| 824 | include cfg/usb-mass-storage.scc |
| 825 | include cfg/boot-live.scc |
| 826 | |
| 827 | # Basic profiling |
| 828 | include features/latencytop/latencytop.scc |
| 829 | include features/profiling/profiling.scc |
| 830 | |
| 831 | # Requested drivers that don't have an existing scc |
| 832 | kconf hardware minnow-drivers-extra.cfg |
| 833 | </literallayout> |
| 834 | The <filename>include</filename> command midway through the file |
| 835 | includes the <filename>minnow.scc</filename> description that |
| 836 | defines all hardware enablements for the BSP that is common to all |
| 837 | kernel types. |
| 838 | Using this command significantly reduces duplication. |
| 839 | </para> |
| 840 | |
| 841 | <para> |
| 842 | Now consider the "minnow" description for the "tiny" kernel type: |
| 843 | <literallayout class='monospaced'> |
| 844 | minnow-tiny.scc: |
| 845 | define KMACHINE minnow |
| 846 | define KTYPE tiny |
| 847 | define KARCH i386 |
| 848 | |
| 849 | include ktypes/tiny |
| 850 | |
| 851 | include minnow.scc |
| 852 | </literallayout> |
| 853 | As you might expect, the "tiny" description includes quite a |
| 854 | bit less. |
| 855 | In fact, it includes only the minimal policy defined by the |
| 856 | "tiny" kernel type and the hardware-specific configuration required |
| 857 | for booting the machine along with the most basic functionality of |
| 858 | the system as defined in the base "minnow" description file. |
| 859 | </para> |
| 860 | |
| 861 | <para> |
| 862 | Notice again the three critical variables: |
| 863 | <filename>KMACHINE</filename>, <filename>KTYPE</filename>, |
| 864 | and <filename>KARCH</filename>. |
| 865 | Of these variables, only the <filename>KTYPE</filename> has changed. |
| 866 | It is now set to "tiny". |
| 867 | </para> |
| 868 | </section> |
| 869 | </section> |
| 870 | |
| 871 | <section id='organizing-your-source'> |
| 872 | <title>Organizing Your Source</title> |
| 873 | |
| 874 | <para> |
| 875 | Many recipes based on the <filename>linux-yocto-custom.bb</filename> |
| 876 | recipe use Linux kernel sources that have only a single |
| 877 | branch - "master". |
| 878 | This type of repository structure is fine for linear development |
| 879 | supporting a single machine and architecture. |
| 880 | However, if you work with multiple boards and architectures, |
| 881 | a kernel source repository with multiple branches is more |
| 882 | efficient. |
| 883 | For example, suppose you need a series of patches for one board to boot. |
| 884 | Sometimes, these patches are works-in-progress or fundamentally wrong, |
| 885 | yet they are still necessary for specific boards. |
| 886 | In these situations, you most likely do not want to include these |
| 887 | patches in every kernel you build (i.e. have the patches as part of |
| 888 | the lone "master" branch). |
| 889 | It is situations like these that give rise to multiple branches used |
| 890 | within a Linux kernel sources Git repository. |
| 891 | </para> |
| 892 | |
| 893 | <para> |
| 894 | Repository organization strategies exist that maximize source reuse, |
| 895 | remove redundancy, and logically order your changes. |
| 896 | This section presents strategies for the following cases: |
| 897 | <itemizedlist> |
| 898 | <listitem><para>Encapsulating patches in a feature description |
| 899 | and only including the patches in the BSP descriptions of |
| 900 | the applicable boards.</para></listitem> |
| 901 | <listitem><para>Creating a machine branch in your |
| 902 | kernel source repository and applying the patches on that |
| 903 | branch only.</para></listitem> |
| 904 | <listitem><para>Creating a feature branch in your |
| 905 | kernel source repository and merging that branch into your |
| 906 | BSP when needed.</para></listitem> |
| 907 | </itemizedlist> |
| 908 | </para> |
| 909 | |
| 910 | <para> |
| 911 | The approach you take is entirely up to you |
| 912 | and depends on what works best for your development model. |
| 913 | </para> |
| 914 | |
| 915 | <section id='encapsulating-patches'> |
| 916 | <title>Encapsulating Patches</title> |
| 917 | |
| 918 | <para> |
| 919 | if you are reusing patches from an external tree and are not |
| 920 | working on the patches, you might find the encapsulated feature |
| 921 | to be appropriate. |
| 922 | Given this scenario, you do not need to create any branches in the |
| 923 | source repository. |
| 924 | Rather, you just take the static patches you need and encapsulate |
| 925 | them within a feature description. |
| 926 | Once you have the feature description, you simply include that into |
| 927 | the BSP description as described in the |
| 928 | "<link linkend='bsp-descriptions'>BSP Descriptions</link>" |
| 929 | section. |
| 930 | </para> |
| 931 | |
| 932 | <para> |
| 933 | You can find information on how to create patches and BSP |
| 934 | descriptions in the "<link linkend='patches'>Patches</link>" and |
| 935 | "<link linkend='bsp-descriptions'>BSP Descriptions</link>" |
| 936 | sections. |
| 937 | </para> |
| 938 | </section> |
| 939 | |
| 940 | <section id='machine-branches'> |
| 941 | <title>Machine Branches</title> |
| 942 | |
| 943 | <para> |
| 944 | When you have multiple machines and architectures to support, |
| 945 | or you are actively working on board support, it is more |
| 946 | efficient to create branches in the repository based on |
| 947 | individual machines. |
| 948 | Having machine branches allows common source to remain in the |
| 949 | "master" branch with any features specific to a machine stored |
| 950 | in the appropriate machine branch. |
| 951 | This organization method frees you from continually reintegrating |
| 952 | your patches into a feature. |
| 953 | </para> |
| 954 | |
| 955 | <para> |
| 956 | Once you have a new branch, you can set up your kernel Metadata |
| 957 | to use the branch a couple different ways. |
| 958 | In the recipe, you can specify the new branch as the |
| 959 | <filename>KBRANCH</filename> to use for the board as |
| 960 | follows: |
| 961 | <literallayout class='monospaced'> |
| 962 | KBRANCH = "mynewbranch" |
| 963 | </literallayout> |
| 964 | Another method is to use the <filename>branch</filename> command |
| 965 | in the BSP description: |
| 966 | <literallayout class='monospaced'> |
| 967 | mybsp.scc: |
| 968 | define KMACHINE mybsp |
| 969 | define KTYPE standard |
| 970 | define KARCH i386 |
| 971 | include standard.scc |
| 972 | |
| 973 | branch mynewbranch |
| 974 | |
| 975 | include mybsp-hw.scc |
| 976 | </literallayout> |
| 977 | </para> |
| 978 | |
| 979 | <para> |
| 980 | If you find |
| 981 | yourself with numerous branches, you might consider using a |
| 982 | hierarchical branching system similar to what the linux-yocto Linux |
| 983 | kernel repositories use: |
| 984 | <literallayout class='monospaced'> |
| 985 | <replaceable>common</replaceable>/<replaceable>kernel_type</replaceable>/<replaceable>machine</replaceable> |
| 986 | </literallayout> |
| 987 | </para> |
| 988 | |
| 989 | <para> |
| 990 | If you had two kernel types, "standard" and "small" for |
| 991 | instance, three machines, and <replaceable>common</replaceable> |
| 992 | as <filename>mydir</filename>, the branches in your |
| 993 | Git repository might look like this: |
| 994 | <literallayout class='monospaced'> |
| 995 | mydir/base |
| 996 | mydir/standard/base |
| 997 | mydir/standard/machine_a |
| 998 | mydir/standard/machine_b |
| 999 | mydir/standard/machine_c |
| 1000 | mydir/small/base |
| 1001 | mydir/small/machine_a |
| 1002 | </literallayout> |
| 1003 | </para> |
| 1004 | |
| 1005 | <para> |
| 1006 | This organization can help clarify the branch relationships. |
| 1007 | In this case, <filename>mydir/standard/machine_a</filename> |
| 1008 | includes everything in <filename>mydir/base</filename> and |
| 1009 | <filename>mydir/standard/base</filename>. |
| 1010 | The "standard" and "small" branches add sources specific to those |
| 1011 | kernel types that for whatever reason are not appropriate for the |
| 1012 | other branches. |
| 1013 | <note>The "base" branches are an artifact of the way Git manages |
| 1014 | its data internally on the filesystem: Git will not allow you |
| 1015 | to use <filename>mydir/standard</filename> and |
| 1016 | <filename>mydir/standard/machine_a</filename> because it |
| 1017 | would have to create a file and a directory named "standard". |
| 1018 | </note> |
| 1019 | </para> |
| 1020 | </section> |
| 1021 | |
| 1022 | <section id='feature-branches'> |
| 1023 | <title>Feature Branches</title> |
| 1024 | |
| 1025 | <para> |
| 1026 | When you are actively developing new features, it can be more |
| 1027 | efficient to work with that feature as a branch, rather than |
| 1028 | as a set of patches that have to be regularly updated. |
| 1029 | The Yocto Project Linux kernel tools provide for this with |
| 1030 | the <filename>git merge</filename> command. |
| 1031 | </para> |
| 1032 | |
| 1033 | <para> |
| 1034 | To merge a feature branch into a BSP, insert the |
| 1035 | <filename>git merge</filename> command after any |
| 1036 | <filename>branch</filename> commands: |
| 1037 | <literallayout class='monospaced'> |
| 1038 | mybsp.scc: |
| 1039 | define KMACHINE mybsp |
| 1040 | define KTYPE standard |
| 1041 | define KARCH i386 |
| 1042 | include standard.scc |
| 1043 | |
| 1044 | branch mynewbranch |
| 1045 | git merge myfeature |
| 1046 | |
| 1047 | include mybsp-hw.scc |
| 1048 | </literallayout> |
| 1049 | </para> |
| 1050 | </section> |
| 1051 | </section> |
| 1052 | |
| 1053 | <section id='scc-reference'> |
| 1054 | <title>SCC Description File Reference</title> |
| 1055 | |
| 1056 | <para> |
| 1057 | This section provides a brief reference for the commands you can use |
| 1058 | within an SCC description file (<filename>.scc</filename>): |
| 1059 | <itemizedlist> |
| 1060 | <listitem><para><filename>branch [ref]</filename>: |
| 1061 | Creates a new branch relative to the current branch |
| 1062 | (typically <filename>${KTYPE}</filename>) using |
| 1063 | the currently checked-out branch, or "ref" if specified. |
| 1064 | </para></listitem> |
| 1065 | <listitem><para><filename>define</filename>: |
| 1066 | Defines variables, such as <filename>KMACHINE</filename>, |
| 1067 | <filename>KTYPE</filename>, <filename>KARCH</filename>, |
| 1068 | and <filename>KFEATURE_DESCRIPTION</filename>.</para></listitem> |
| 1069 | <listitem><para><filename>include SCC_FILE</filename>: |
| 1070 | Includes an SCC file in the current file. |
| 1071 | The file is parsed as if you had inserted it inline. |
| 1072 | </para></listitem> |
| 1073 | <listitem><para><filename>kconf [hardware|non-hardware] CFG_FILE</filename>: |
| 1074 | Queues a configuration fragment for merging into the final |
| 1075 | Linux <filename>.config</filename> file.</para></listitem> |
| 1076 | <listitem><para><filename>git merge GIT_BRANCH</filename>: |
| 1077 | Merges the feature branch into the current branch. |
| 1078 | </para></listitem> |
| 1079 | <listitem><para><filename>patch PATCH_FILE</filename>: |
| 1080 | Applies the patch to the current Git branch.</para></listitem> |
| 1081 | </itemizedlist> |
| 1082 | </para> |
| 1083 | </section> |
| 1084 | |
| 1085 | </chapter> |
| 1086 | <!-- |
| 1087 | vim: expandtab tw=80 ts=4 |
| 1088 | --> |