From 972dcfcdbfe75dcfeb777150c136576cf1a71e99 Mon Sep 17 00:00:00 2001 From: Tudor Florea Date: Fri, 9 Oct 2015 22:59:03 +0200 Subject: initial commit for Enea Linux 5.0 arm Signed-off-by: Tudor Florea --- documentation/kernel-dev/kernel-dev-advanced.xml | 1074 ++++++++++++++++++++++ 1 file changed, 1074 insertions(+) create mode 100644 documentation/kernel-dev/kernel-dev-advanced.xml (limited to 'documentation/kernel-dev/kernel-dev-advanced.xml') diff --git a/documentation/kernel-dev/kernel-dev-advanced.xml b/documentation/kernel-dev/kernel-dev-advanced.xml new file mode 100644 index 0000000000..283f483112 --- /dev/null +++ b/documentation/kernel-dev/kernel-dev-advanced.xml @@ -0,0 +1,1074 @@ + %poky; ] > + + +Working with Advanced Metadata + +
+ Overview + + + In addition to supporting configuration fragments and patches, the + Yocto Project kernel tools also support rich + Metadata that you can + use to define complex policies and Board Support Package (BSP) support. + The purpose of the Metadata and the tools that manage it, known as + the kern-tools (kern-tools-native_git.bb), is + to help you manage the complexity of the configuration and sources + used to support multiple BSPs and Linux kernel types. + +
+ +
+ Using Kernel Metadata in a Recipe + + + The kernel sources in the Yocto Project contain kernel Metadata, which is + located in the meta branches of the kernel source + Git repositories. + This Metadata defines Board Support Packages (BSPs) that + correspond to definitions in linux-yocto recipes for the same BSPs. + A BSP consists of an aggregation of kernel policy and hardware-specific + feature enablements. + The BSP can be influenced from within the linux-yocto recipe. + + Linux kernel source that contains kernel Metadata is said to be + "linux-yocto style" kernel source. + A Linux kernel recipe that inherits from the + linux-yocto.inc include file is said to be a + "linux-yocto style" recipe. + + + + + Every linux-yocto style recipe must define the + KMACHINE + variable. + This variable is typically set to the same value as the + MACHINE + variable, which is used by + BitBake + (e.g. "edgerouter" or "fri2"). + Multiple BSPs can reuse the same KMACHINE + name if they are built using the same BSP description. + The "fri2" and "fri2-noemgd" BSP combination + in the meta-intel + layer is a good example of two BSPs using the same + KMACHINE value (i.e. "fri2"). + See the BSP Descriptions section + for more information. + + + + The linux-yocto style recipes can optionally define the following + variables: + + KBRANCH + KERNEL_FEATURES + KBRANCH_DEFAULT + LINUX_KERNEL_TYPE + + KBRANCH_DEFAULT defines the Linux kernel source + repository's default branch to use to build the Linux kernel. + The value is used as the default for KBRANCH, which + can define an alternate branch typically with a machine override as + follows: + + KBRANCH_fri2 = "standard/fri2" + + Unless you specify otherwise, KBRANCH_DEFAULT + initializes to "master". + + + + LINUX_KERNEL_TYPE defines the kernel type to be + used in assembling the configuration. + If you do not specify a LINUX_KERNEL_TYPE, + it defaults to "standard". + Together with + KMACHINE, + LINUX_KERNEL_TYPE defines the search + arguments used by the kernel tools to find the + appropriate description within the kernel Metadata with which to + build out the sources and configuration. + The linux-yocto recipes define "standard", "tiny", and "preempt-rt" + kernel types. + See the Kernel Types section + for more information on kernel types. + + + + During the build, the kern-tools search for the BSP description + file that most closely matches the KMACHINE + and LINUX_KERNEL_TYPE variables passed in from the + recipe. + The tools use the first BSP description it finds that match + both variables. + If the tools cannot find a match, they issue a warning such as + the following: + + WARNING: Can't find any BSP hardware or required configuration fragments. + WARNING: Looked at meta/cfg/broken/fri2-broken/hdw_frags.txt and + meta/cfg/broken/fri2-broken/required_frags.txt in directory: + meta/cfg/broken/fri2-broken + + In this example, KMACHINE was set to "fri2-broken" + and LINUX_KERNEL_TYPE was set to "broken". + + + + The tools first search for the KMACHINE and + then for the LINUX_KERNEL_TYPE. + If the tools cannot find a partial match, they will use the + sources from the KBRANCH and any configuration + specified in the + SRC_URI. + + + + You can use the KERNEL_FEATURES variable + to include features (configuration fragments, patches, or both) that + are not already included by the KMACHINE and + LINUX_KERNEL_TYPE variable combination. + For example, to include a feature specified as "features/netfilter.scc", + specify: + + KERNEL_FEATURES += "features/netfilter.scc" + + To include a feature called "cfg/sound.scc" just for the + qemux86 machine, specify: + + KERNEL_FEATURES_append_qemux86 = "cfg/sound.scc" + + The value of the entries in KERNEL_FEATURES + are dependent on their location within the kernel Metadata itself. + The examples here are taken from the + linux-yocto-3.4 repository where "features" + and "cfg" are subdirectories within the + meta/cfg/kernel-cache directory. + For more information, see the + "Kernel Metadata Syntax" section. + + The processing of the these variables has evolved some between the + 0.9 and 1.3 releases of the Yocto Project and associated + kern-tools sources. + The descriptions in this section are accurate for 1.3 and later + releases of the Yocto Project. + + +
+ +
+ Kernel Metadata Location + + + Kernel Metadata can be defined in either the kernel recipe + (recipe-space) or in the kernel tree (in-tree). + Where you choose to define the Metadata depends on what you want + to do and how you intend to work. + Regardless of where you define the kernel Metadata, the syntax used + applies equally. + + + + If you are unfamiliar with the Linux kernel and only wish + to apply a configuration and possibly a couple of patches provided to + you by others, the recipe-space method is recommended. + This method is also a good approach if you are working with Linux kernel + sources you do not control or if you just do not want to maintain a + Linux kernel Git repository on your own. + For partial information on how you can define kernel Metadata in + the recipe-space, see the + "Modifying an Existing Recipe" + section. + + + + Conversely, if you are actively developing a kernel and are already + maintaining a Linux kernel Git repository of your own, you might find + it more convenient to work with the kernel Metadata in the same + repository as the Linux kernel sources. + This method can make iterative development of the Linux kernel + more efficient outside of the BitBake environment. + + +
+ Recipe-Space Metadata + + + When stored in recipe-space, the kernel Metadata files reside in a + directory hierarchy below + FILESEXTRAPATHS. + For a linux-yocto recipe or for a Linux kernel recipe derived + by copying and modifying + oe-core/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb + to a recipe in your layer, FILESEXTRAPATHS + is typically set to + ${THISDIR}/${PN}. + See the "Modifying an Existing Recipe" + section for more information. + + + + Here is an example that shows a trivial tree of kernel Metadata + stored in recipe-space within a BSP layer: + + meta-my_bsp_layer/ + `-- recipes-kernel + `-- linux + `-- linux-yocto + |-- bsp-standard.scc + |-- bsp.cfg + `-- standard.cfg + + + + + When the Metadata is stored in recipe-space, you must take + steps to ensure BitBake has the necessary information to decide + what files to fetch and when they need to be fetched again. + It is only necessary to specify the .scc + files on the + SRC_URI. + BitBake parses them and fetches any files referenced in the + .scc files by the include, + patch, or kconf commands. + Because of this, it is necessary to bump the recipe + PR + value when changing the content of files not explicitly listed + in the SRC_URI. + +
+ +
+ In-Tree Metadata + + + When stored in-tree, the kernel Metadata files reside in the + meta directory of the Linux kernel sources. + The meta directory can be present in the + same repository branch as the sources, + such as "master", or meta can be its own + orphan branch. + + An orphan branch in Git is a branch with unique history and + content to the other branches in the repository. + Orphan branches are useful to track Metadata changes + independently from the sources of the Linux kernel, while + still keeping them together in the same repository. + + For the purposes of this document, we will discuss all + in-tree Metadata as residing below the + meta/cfg/kernel-cache directory. + + + + Following is an example that shows how a trivial tree of Metadata + is stored in a custom Linux kernel Git repository: + + meta/ + `-- cfg + `-- kernel-cache + |-- bsp-standard.scc + |-- bsp.cfg + `-- standard.cfg + + + + + To use a branch different from where the sources reside, + specify the branch in the KMETA variable + in your Linux kernel recipe. + Here is an example: + + KMETA = "meta" + + To use the same branch as the sources, set + KMETA to an empty string: + + KMETA = "" + + If you are working with your own sources and want to create an + orphan meta branch, use these commands + from within your Linux kernel Git repository: + + $ git checkout --orphan meta + $ git rm -rf . + $ git commit --allow-empty -m "Create orphan meta branch" + + + + + If you modify the Metadata in the linux-yocto + meta branch, you must not forget to update + the + SRCREV + statements in the kernel's recipe. + In particular, you need to update the + SRCREV_meta variable to match the commit in + the KMETA branch you wish to use. + Changing the data in these branches and not updating the + SRCREV statements to match will cause the + build to fetch an older commit. + +
+
+ +
+ Kernel Metadata Syntax + + + The kernel Metadata consists of three primary types of files: + scc + + + scc stands for Series Configuration + Control, but the naming has less significance in the + current implementation of the tooling than it had in the + past. + Consider scc files to be description files. + + + description files, configuration fragments, and patches. + The scc files define variables and include or + otherwise reference any of the three file types. + The description files are used to aggregate all types of kernel + Metadata into + what ultimately describes the sources and the configuration required + to build a Linux kernel tailored to a specific machine. + + + + The scc description files are used to define two + fundamental types of kernel Metadata: + + Features + Board Support Packages (BSPs) + + + + + Features aggregate sources in the form of patches and configuration + fragments into a modular reusable unit. + You can use features to implement conceptually separate kernel + Metadata descriptions such as pure configuration fragments, + simple patches, complex features, and kernel types. + Kernel types define general + kernel features and policy to be reused in the BSPs. + + + + BSPs define hardware-specific features and aggregate them with kernel + types to form the final description of what will be assembled and built. + + + + While the kernel Metadata syntax does not enforce any logical + separation of configuration fragments, patches, features or kernel + types, best practices dictate a logical separation of these types + of Metadata. + The following Metadata file hierarchy is recommended: + + base/ + bsp/ + cfg/ + features/ + ktypes/ + patches/ + + + + + The bsp directory contains the + BSP descriptions. + The remaining directories all contain "features". + Separating bsp from the rest of the structure + aids conceptualizing intended usage. + + + + Use these guidelines to help place your scc + description files within the structure: + + If your file contains + only configuration fragments, place the file in the + cfg directory. + If your file contains + only source-code fixes, place the file in the + patches directory. + If your file encapsulates + a major feature, often combining sources and configurations, + place the file in features directory. + + If your file aggregates + non-hardware configuration and patches in order to define a + base kernel policy or major kernel type to be reused across + multiple BSPs, place the file in ktypes + directory. + + + + + + These distinctions can easily become blurred - especially as + out-of-tree features slowly merge upstream over time. + Also, remember that how the description files are placed is + a purely logical organization and has no impact on the functionality + of the kernel Metadata. + There is no impact because all of cfg, + features, patches, and + ktypes, contain "features" as far as the kernel + tools are concerned. + + + + Paths used in kernel Metadata files are relative to + <base>, which is either + FILESEXTRAPATHS + if you are creating Metadata in + recipe-space, + or meta/cfg/kernel-cache/ if you are creating + Metadata in-tree. + + +
+ Configuration + + + The simplest unit of kernel Metadata is the configuration-only + feature. + This feature consists of one or more Linux kernel configuration + parameters in a configuration fragment file + (.cfg) and an .scc file + that describes the fragment. + + + + The Symmetric Multi-Processing (SMP) fragment included in the + linux-yocto-3.4 Git repository + consists of the following two files: + + cfg/smp.scc: + define KFEATURE_DESCRIPTION "Enable SMP" + kconf hardware smp.cfg + + cfg/smp.cfg: + CONFIG_SMP=y + CONFIG_SCHED_SMT=y + + You can find information on configuration fragment files in the + "Creating Configuration Fragments" + section of the Yocto Project Development Manual and in + the "Generating Configuration Files" + section earlier in this manual. + + + + KFEATURE_DESCRIPTION + provides a short description of the fragment. + Higher level kernel tools use this description. + + + + The kconf command is used to include the + actual configuration fragment in an .scc + file, and the "hardware" keyword identifies the fragment as + being hardware enabling, as opposed to general policy, + which would use the "non-hardware" keyword. + The distinction is made for the benefit of the configuration + validation tools, which warn you if a hardware fragment + overrides a policy set by a non-hardware fragment. + + The description file can include multiple + kconf statements, one per fragment. + + + + + As described in the + "Generating Configuration Files" + section, you can use the following BitBake command to audit your + configuration: + + $ bitbake linux-yocto -c kernel_configcheck -f + + +
+ +
+ Patches + + + Patch descriptions are very similar to configuration fragment + descriptions, which are described in the previous section. + However, instead of a .cfg file, these + descriptions work with source patches. + + + + A typical patch includes a description file and the patch itself: + + patches/mypatch.scc: + patch mypatch.patch + + patches/mypatch.patch: + typical-patch + + You can create the typical .patch + file using diff -Nurp or + git format-patch. + + + + The description file can include multiple patch statements, + one per patch. + +
+ +
+ Features + + + Features are complex kernel Metadata types that consist + of configuration fragments (kconf), patches + (patch), and possibly other feature + description files (include). + + + + Here is an example that shows a feature description file: + + features/myfeature.scc + define KFEATURE_DESCRIPTION "Enable myfeature" + + patch 0001-myfeature-core.patch + patch 0002-myfeature-interface.patch + + include cfg/myfeature_dependency.scc + kconf non-hardware myfeature.cfg + + This example shows how the patch and + kconf commands are used as well as + how an additional feature description file is included. + + + + Typically, features are less granular than configuration + fragments and are more likely than configuration fragments + and patches to be the types of things you want to specify + in the KERNEL_FEATURES variable of the + Linux kernel recipe. + See the "Using Kernel Metadata in a Recipe" + section earlier in the manual. + +
+ +
+ Kernel Types + + + A kernel type defines a high-level kernel policy by + aggregating non-hardware configuration fragments with + patches you want to use when building a Linux kernels of a + specific type. + Syntactically, kernel types are no different than features + as described in the "Features" + section. + The LINUX_KERNEL_TYPE variable in the kernel + recipe selects the kernel type. + See the "Using Kernel Metadata in a Recipe" + section for more information. + + + + As an example, the linux-yocto-3.4 + tree defines three kernel types: "standard", + "tiny", and "preempt-rt": + + "standard": + Includes the generic Linux kernel policy of the Yocto + Project linux-yocto kernel recipes. + This policy includes, among other things, which file + systems, networking options, core kernel features, and + debugging and tracing options are supported. + + "preempt-rt": + Applies the PREEMPT_RT + patches and the configuration options required to + build a real-time Linux kernel. + This kernel type inherits from the "standard" kernel type. + + "tiny": + Defines a bare minimum configuration meant to serve as a + base for very small Linux kernels. + The "tiny" kernel type is independent from the "standard" + configuration. + Although the "tiny" kernel type does not currently include + any source changes, it might in the future. + + + + + + The "standard" kernel type is defined by + standard.scc: + + # Include this kernel type fragment to get the standard features and + # configuration values. + + # Include all standard features + include standard-nocfg.scc + + kconf non-hardware standard.cfg + + # individual cfg block section + include cfg/fs/devtmpfs.scc + include cfg/fs/debugfs.scc + include cfg/fs/btrfs.scc + include cfg/fs/ext2.scc + include cfg/fs/ext3.scc + include cfg/fs/ext4.scc + + include cfg/net/ipv6.scc + include cfg/net/ip_nf.scc + include cfg/net/ip6_nf.scc + include cfg/net/bridge.scc + + + + + As with any .scc file, a + kernel type definition can aggregate other + .scc files with + include commands. + These definitions can also directly pull in + configuration fragments and patches with the + kconf and patch + commands, respectively. + + + + It is not strictly necessary to create a kernel type + .scc file. + The Board Support Package (BSP) file can implicitly define + the kernel type using a define + KTYPE myktype + line. + See the "BSP Descriptions" + section for more information. + +
+ +
+ BSP Descriptions + + + BSP descriptions combine kernel types with hardware-specific + features. + The hardware-specific portion is typically defined + independently, and then aggregated with each supported kernel + type. + Consider this simple BSP description that supports the "mybsp" + machine: + + mybsp.scc: + define KMACHINE mybsp + define KTYPE standard + define KARCH i386 + + kconf mybsp.cfg + + Every BSP description should define the + KMACHINE, + KTYPE, + and KARCH + variables. + These variables allow the OpenEmbedded build system to identify + the description as meeting the criteria set by the recipe being + built. + This simple example supports the "mybsp" machine for the "standard" + kernel and the "i386" architecture. + + + + Be aware that a hard link between the + KTYPE variable and a kernel type + description file does not exist. + Thus, if you do not have kernel types defined in your kernel + Metadata, you only need to ensure that the kernel recipe's + LINUX_KERNEL_TYPE + variable and the KTYPE variable in the + BSP description file match. + + Future versions of the tooling make the specification of + KTYPE in the BSP optional. + + + + + If you did want to separate your kernel policy from your + hardware configuration, you could do so by specifying a kernel + type, such as "standard" and including that description file + in the BSP description file. + See the "Kernel Types" section + for more information. + + + + You might also have multiple hardware configurations that you + aggregate into a single hardware description file that you + could include in the BSP description file, rather than referencing + a single .cfg file. + Consider the following: + + mybsp.scc: + define KMACHINE mybsp + define KTYPE standard + define KARCH i386 + + include standard.scc + include mybsp-hw.scc + + + + + In the above example, standard.scc + aggregates all the configuration fragments, patches, and + features that make up your standard kernel policy whereas + mybsp-hw.scc aggregates all those necessary + to support the hardware available on the "mybsp" machine. + For information on how to break a complete + .config file into the various + configuration fragments, see the + "Generating Configuration Files" + section. + + + + Many real-world examples are more complex. + Like any other .scc file, BSP + descriptions can aggregate features. + Consider the Fish River Island 2 (fri2) + BSP definition from the linux-yocto-3.4 + Git repository: + + fri2.scc: + kconf hardware fri2.cfg + + include cfg/x86.scc + include features/eg20t/eg20t.scc + include cfg/dmaengine.scc + include features/ericsson-3g/f5521gw.scc + include features/power/intel.scc + include cfg/efi.scc + include features/usb/ehci-hcd.scc + include features/usb/ohci-hcd.scc + include features/iwlwifi/iwlwifi.scc + + + + + The fri2.scc description file includes + a hardware configuration fragment + (fri2.cfg) specific to the Fish River + Island 2 BSP as well as several more general configuration + fragments and features enabling hardware found on the + machine. + This description file is then included in each of the three + "fri2" description files for the supported kernel types + (i.e. "standard", "preempt-rt", and "tiny"). + Consider the "fri2" description for the "standard" kernel + type: + + fri2-standard.scc: + define KMACHINE fri2 + define KTYPE standard + define KARCH i386 + + include ktypes/standard/standard.scc + branch fri2 + + git merge emgd-1.14 + + include fri2.scc + + # Extra fri2 configs above the minimal defined in fri2.scc + include cfg/efi-ext.scc + include features/drm-emgd/drm-emgd.scc + include cfg/vesafb.scc + + # default policy for standard kernels + include cfg/usb-mass-storage.scc + + The include command midway through the file + includes the fri2.scc description that + defines all hardware enablements for the BSP that is common to all + kernel types. + Using this command significantly reduces duplication. + + + + This "fri2" standard description introduces a few more variables + and commands that are worth further discussion. + Notice the branch fri2 command, which creates + a machine-specific branch into which source changes are applied. + With this branch set up, the git merge command + uses Git to merge in a feature branch named "emgd-1.14". + You could also handle this with the patch + command. + However, for commonly used features such as this, feature branches + are a convenient mechanism. + See the "Feature Branches" + section for more information. + + + + Now consider the "fri2" description for the "tiny" kernel type: + + fri2-tiny.scc: + define KMACHINE fri2 + define KTYPE tiny + define KARCH i386 + + include ktypes/tiny/tiny.scc + branch fri2 + + include fri2.scc + + As you might expect, the "tiny" description includes quite a + bit less. + In fact, it includes only the minimal policy defined by the + "tiny" kernel type and the hardware-specific configuration required + for booting the machine along with the most basic functionality of + the system as defined in the base "fri2" description file. + + + + Notice again the three critical variables: + KMACHINE, KTYPE, + and KARCH. + Of these variables, only the KTYPE has changed. + It is now set to "tiny". + +
+
+ +
+ Organizing Your Source + + + Many recipes based on the linux-yocto-custom.bb + recipe use Linux kernel sources that have only a single + branch - "master". + This type of repository structure is fine for linear development + supporting a single machine and architecture. + However, if you work with multiple boards and architectures, + a kernel source repository with multiple branches is more + efficient. + For example, suppose you need a series of patches for one board to boot. + Sometimes, these patches are works-in-progress or fundamentally wrong, + yet they are still necessary for specific boards. + In these situations, you most likely do not want to include these + patches in every kernel you build (i.e. have the patches as part of + the lone "master" branch). + It is situations like these that give rise to multiple branches used + within a Linux kernel sources Git repository. + + + + Repository organization strategies exist that maximize source reuse, + remove redundancy, and logically order your changes. + This section presents strategies for the following cases: + + Encapsulating patches in a feature description + and only including the patches in the BSP descriptions of + the applicable boards. + Creating a machine branch in your + kernel source repository and applying the patches on that + branch only. + Creating a feature branch in your + kernel source repository and merging that branch into your + BSP when needed. + + + + + The approach you take is entirely up to you + and depends on what works best for your development model. + + +
+ Encapsulating Patches + + + if you are reusing patches from an external tree and are not + working on the patches, you might find the encapsulated feature + to be appropriate. + Given this scenario, you do not need to create any branches in the + source repository. + Rather, you just take the static patches you need and encapsulate + them within a feature description. + Once you have the feature description, you simply include that into + the BSP description as described in the + "BSP Descriptions" + section. + + + + You can find information on how to create patches and BSP + descriptions in the "Patches" and + "BSP Descriptions" + sections. + +
+ +
+ Machine Branches + + + When you have multiple machines and architectures to support, + or you are actively working on board support, it is more + efficient to create branches in the repository based on + individual machines. + Having machine branches allows common source to remain in the + "master" branch with any features specific to a machine stored + in the appropriate machine branch. + This organization method frees you from continually reintegrating + your patches into a feature. + + + + Once you have a new branch, you can set up your kernel Metadata + to use the branch a couple different ways. + In the recipe, you can specify the new branch as the + KBRANCH to use for the board as + follows: + + KBRANCH = "mynewbranch" + + Another method is to use the branch command + in the BSP description: + + mybsp.scc: + define KMACHINE mybsp + define KTYPE standard + define KARCH i386 + include standard.scc + + branch mynewbranch + + include mybsp-hw.scc + + + + + If you find + yourself with numerous branches, you might consider using a + hierarchical branching system similar to what the linux-yocto Linux + kernel repositories use: + + common/kernel_type/machine + + + + + If you had two kernel types, "standard" and "small" for + instance, three machines, and common + as mydir, the branches in your + Git repository might look like this: + + mydir/base + mydir/standard/base + mydir/standard/machine_a + mydir/standard/machine_b + mydir/standard/machine_c + mydir/small/base + mydir/small/machine_a + + + + + This organization can help clarify the branch relationships. + In this case, mydir/standard/machine_a + includes everything in mydir/base and + mydir/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. + The "base" branches are an artifact of the way Git manages + its data internally on the filesystem: Git will not allow you + to use mydir/standard and + mydir/standard/machine_a because it + would have to create a file and a directory named "standard". + + +
+ +
+ Feature Branches + + + When you are actively developing new features, it can be more + efficient to work with that feature as a branch, rather than + as a set of patches that have to be regularly updated. + The Yocto Project Linux kernel tools provide for this with + the git merge command. + + + + To merge a feature branch into a BSP, insert the + git merge command after any + branch commands: + + mybsp.scc: + define KMACHINE mybsp + define KTYPE standard + define KARCH i386 + include standard.scc + + branch mynewbranch + git merge myfeature + + include mybsp-hw.scc + + +
+
+ +
+ SCC Description File Reference + + + This section provides a brief reference for the commands you can use + within an SCC description file (.scc): + + branch [ref]: + Creates a new branch relative to the current branch + (typically ${KTYPE}) using + the currently checked-out branch, or "ref" if specified. + + define: + Defines variables, such as KMACHINE, + KTYPE, KARCH, + and KFEATURE_DESCRIPTION. + include SCC_FILE: + Includes an SCC file in the current file. + The file is parsed as if you had inserted it inline. + + kconf [hardware|non-hardware] CFG_FILE: + Queues a configuration fragment for merging into the final + Linux .config file. + git merge GIT_BRANCH: + Merges the feature branch into the current branch. + + patch PATCH_FILE: + Applies the patch to the current Git branch. + + +
+ + + -- cgit v1.2.3-54-g00ecf