kernel-dev: Updated kernel configuration section

A lot of rewriting here in this section to get it up to speed.
Also, moved that final section on determining hardware and
non-hardware features into an appendix where it belonged.

(From yocto-docs rev: 752e80d6ae8f81a0de7743b11b010d0ef36b314b)

Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

documentation/kernel-dev/kernel-dev-common.xml

@@ -10,8 +10,8 @@
         work with the Yocto Project Linux kernel.
         These tasks include preparing your host development system for
         kernel development, preparing a layer, modifying an existing recipe,
-        patching the kernel, iterative development, working with your own sources,
-        and incorporating out-of-tree modules.
+        patching the kernel, configuring the kernel, iterative development,
+        working with your own sources, and incorporating out-of-tree modules.
         <note>
             The examples presented in this chapter work with the Yocto Project
             2.4 Release and forward.
@@ -1447,34 +1447,6 @@
         </para>
     </section>
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
     <section id='configuring-the-kernel'>
         <title>Configuring the Kernel</title>
 
@@ -1516,17 +1488,22 @@
             </para>
 
             <para>
-                To use the <filename>menuconfig</filename> tool in the Yocto Project development
-                environment, you must launch it using BitBake.
+                To use the <filename>menuconfig</filename> tool in the Yocto
+                Project development environment, you must launch it using
+                BitBake.
                 Thus, the environment must be set up using the
                 <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
                 script found in the
                 <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>.
-                You must also be sure of the state of your build in the
+                You must also be sure of the state of your build's configuration
+                in the
                 <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>.
-                The following commands run <filename>menuconfig</filename>
-                assuming the Source Directory's top-level folder is
-                <filename>~/poky</filename>:
+                The following commands initialize the BitBake environment,
+                run the
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-kernel_configme'><filename>do_kernel_configme</filename></ulink>
+                task, and launch <filename>menuconfig</filename>.
+                These commands assume the Source Directory's top-level folder
+                is <filename>~/poky</filename>:
                 <literallayout class='monospaced'>
      $ cd poky
      $ source oe-init-build-env
@@ -1542,79 +1519,81 @@
             </para>
 
             <para>
-                Consider an example that configures the <filename>linux-yocto-3.14</filename>
-                kernel.
-                The OpenEmbedded build system recognizes this kernel as
-                <filename>linux-yocto</filename>.
-                Thus, the following commands from the shell in which you previously sourced the
-                environment initialization script cleans the shared state cache and the
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink>
-                directory and then runs <filename>menuconfig</filename>:
-                <literallayout class='monospaced'>
-     $ bitbake linux-yocto -c menuconfig
-                </literallayout>
-            </para>
-
-            <para>
-                Once <filename>menuconfig</filename> launches, use the interface
-                to navigate through the selections to find the configuration settings in
-                which you are interested.
-                For example, consider the <filename>CONFIG_SMP</filename> configuration setting.
-                You can find it at <filename>Processor Type and Features</filename> under
-                the configuration selection <filename>Symmetric Multi-processing Support</filename>.
-                After highlighting the selection, use the arrow keys to select or deselect
-                the setting.
-                When you are finished with all your selections, exit out and save them.
-            </para>
-
-            <para>
-                Saving the selections updates the <filename>.config</filename> configuration file.
-                This is the file that the OpenEmbedded build system uses to configure the
-                kernel during the build.
+                Consider an example that configures the "CONFIG_SMP" setting
+                for the <filename>linux-yocto-4.12</filename> kernel.
+                <note>
+                    The OpenEmbedded build system recognizes this kernel as
+                    <filename>linux-yocto</filename> through Metadata (e.g.
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_VERSION'><filename>PREFERRED_VERSION</filename></ulink><filename>_linux-yocto ?= "12.4%"</filename>).
+                </note>
+                Once <filename>menuconfig</filename> launches, use the
+                interface to navigate through the selections to find the
+                configuration settings in which you are interested.
+                For this example, you deselect "CONFIG_SMP" by clearing the
+                "Symmetric Multi-Processing Support" option.
+                Using the interface, you can find the option under
+                "Processor Type and Features".
+                To deselect "CONFIG_SMP", use the arrow keys to
+                highlight "Symmetric Multi-Processing Support" and enter "N"
+                to clear the asterisk.
+                When you are finished, exit out and save the change.
+            </para>
+
+            <para>
+                Saving the selections updates the <filename>.config</filename>
+                configuration file.
+                This is the file that the OpenEmbedded build system uses to
+                configure the kernel during the build.
                 You can find and examine this file in the Build Directory in
                 <filename>tmp/work/</filename>.
-                The actual <filename>.config</filename> is located in the area where the
-                specific kernel is built.
-                For example, if you were building a Linux Yocto kernel based on the
-                Linux 3.14 kernel and you were building a QEMU image targeted for
+                The actual <filename>.config</filename> is located in the
+                area where the specific kernel is built.
+                For example, if you were building a Linux Yocto kernel based
+                on the <filename>linux-yocto-4.12</filename> kernel and you
+                were building a QEMU image targeted for
                 <filename>x86</filename> architecture, the
-                <filename>.config</filename> file would be located here:
+                <filename>.config</filename> file would be:
                 <literallayout class='monospaced'>
-     poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.14.11+git1+84f...
-        ...656ed30-r1/linux-qemux86-standard-build
+     poky/build/tmp/work/qemux86-poky-linux/linux-yocto/4.12.12+gitAUTOINC+eda4d18...
+     ...967-r0/linux-qemux86-standard-build/.config
                 </literallayout>
                 <note>
-                    The previous example directory is artificially split and many of the characters
-                    in the actual filename are omitted in order to make it more readable.
-                    Also, depending on the kernel you are using, the exact pathname
-                    for <filename>linux-yocto-3.14...</filename> might differ.
+                    The previous example directory is artificially split and
+                    many of the characters in the actual filename are omitted
+                    in order to make it more readable.
+                    Also, depending on the kernel you are using, the exact
+                    pathname might differ.
                 </note>
             </para>
 
             <para>
-                Within the <filename>.config</filename> file, you can see the kernel settings.
-                For example, the following entry shows that symmetric multi-processor support
-                is not set:
+                Within the <filename>.config</filename> file, you can see the
+                kernel settings.
+                For example, the following entry shows that symmetric
+                multi-processor support is not set:
                 <literallayout class='monospaced'>
      # CONFIG_SMP is not set
                 </literallayout>
             </para>
 
             <para>
-                A good method to isolate changed configurations is to use a combination of the
-                <filename>menuconfig</filename> tool and simple shell commands.
-                Before changing configurations with <filename>menuconfig</filename>, copy the
-                existing <filename>.config</filename> and rename it to something else,
-                use <filename>menuconfig</filename> to make
-                as many changes as you want and save them, then compare the renamed configuration
+                A good method to isolate changed configurations is to use a
+                combination of the <filename>menuconfig</filename> tool and
+                simple shell commands.
+                Before changing configurations with
+                <filename>menuconfig</filename>, copy the existing
+                <filename>.config</filename> and rename it to something else,
+                use <filename>menuconfig</filename> to make as many changes as
+                you want and save them, then compare the renamed configuration
                 file against the newly created file.
-                You can use the resulting differences as your base to create configuration fragments
-                to permanently save in your kernel layer.
+                You can use the resulting differences as your base to create
+                configuration fragments to permanently save in your kernel
+                layer.
                 <note>
-                    Be sure to make a copy of the <filename>.config</filename> and don't just
-                    rename it.
-                    The build system needs an existing <filename>.config</filename>
-                    from which to work.
+                    Be sure to make a copy of the <filename>.config</filename>
+                    file and do not just rename it.
+                    The build system needs an existing
+                    <filename>.config</filename> file from which to work.
                 </note>
             </para>
         </section>
@@ -1647,7 +1626,8 @@
                 <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>
                 directory in your layer's
                 <filename>recipes-kernel/linux</filename> directory, and rename
-                the copied file to "defconfig".
+                the copied file to "defconfig" (e.g.
+                <filename>~/meta-mylayer/recipes-kernel/linux/linux-yocto/defconfig</filename>).
                 Then, add the following lines to the linux-yocto
                 <filename>.bbappend</filename> file in your layer:
                 <literallayout class='monospaced'>
@@ -1678,8 +1658,7 @@
                 "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#changing-the-configuration'>Changing the Configuration</ulink>"
                 and
                 "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#generating-configuration-files'>Generating Configuration Files</ulink>"
-                sections, both in the Yocto Project Linux Kernel Development
-                Manual.
+                sections.
             </para>
         </section>
 
@@ -1687,21 +1666,39 @@
             <title>Creating Configuration Fragments</title>
 
             <para>
-                Configuration fragments are simply kernel options that appear in a file
-                placed where the OpenEmbedded build system can find and apply them.
-                Syntactically, the configuration statement is identical to what would appear
-                in the <filename>.config</filename> file, which is in the
-                <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>:
-                <literallayout class='monospaced'>
-     tmp/work/<replaceable>arch</replaceable>-poky-linux/linux-yocto-<replaceable>release_specific_string</replaceable>/linux-<replaceable>arch</replaceable>-<replaceable>build_type</replaceable>
-                </literallayout>
+                Configuration fragments are simply kernel options that
+                appear in a file placed where the OpenEmbedded build system
+                can find and apply them.
+                The build system applies configuration fragments after
+                applying configurations from a <filename>defconfig</filename>
+                file.
+                Thus, the final kernel configuration is a combination of the
+                configurations in the <filename>defconfig</filename>
+                file and then any configuration fragments you provide.
+                The build system applies fragments on top of and
+                after applying the existing defconfig file configurations.
+            </para>
+
+            <para>
+                Syntactically, the configuration statement is identical to
+                what would appear in the <filename>.config</filename> file,
+                which is in the
+                <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>.
+                <note>
+                    For more information about where the
+                    <filename>.config</filename> file is located, see the
+                    example in the
+                    "<link linkend='using-menuconfig'>Using <filename>menuconfig</filename></link>"
+                    section.
+                </note>
             </para>
 
             <para>
                 It is simple to create a configuration fragment.
-                For example, issuing the following from the shell creates a configuration fragment
-                file named <filename>my_smp.cfg</filename> that enables multi-processor support
-                within the kernel:
+                For example, issuing the following from the shell creates a
+                configuration fragment file named
+                <filename>my_smp.cfg</filename> that enables multi-processor
+                support within the kernel:
                 <literallayout class='monospaced'>
      $ echo "CONFIG_SMP=y" >> my_smp.cfg
                 </literallayout>
@@ -1715,29 +1712,34 @@
 
             <para>
                 Where do you put your configuration fragment files?
-                You can place these files in the same area pointed to by
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>.
+                You can place these files in an area pointed to by
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                as directed by your <filename>bblayers.conf</filename> file,
+                which is located in your layer.
                 The OpenEmbedded build system picks up the configuration and
                 adds it to the kernel's configuration.
                 For example, suppose you had a set of configuration options
                 in a file called <filename>myconfig.cfg</filename>.
                 If you put that file inside a directory named
                 <filename>linux-yocto</filename> that resides in the same
-                directory as the kernel's append file and then add a
-                <filename>SRC_URI</filename> statement such as the following
-                to the kernel's append file, those configuration options
-                will be picked up and applied when the kernel is built.
+                directory as the kernel's append file within your layer
+                and then add the following statements to the kernel's append
+                file, those configuration options will be picked up and applied
+                when the kernel is built:
                 <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
      SRC_URI += "file://myconfig.cfg"
                 </literallayout>
             </para>
 
             <para>
-                As mentioned earlier, you can group related configurations into multiple files and
-                name them all in the <filename>SRC_URI</filename> statement as well.
-                For example, you could group separate configurations specifically for Ethernet and graphics
-                into their own files and add those by using a <filename>SRC_URI</filename> statement like the
-                following in your append file:
+                As mentioned earlier, you can group related configurations
+                into multiple files and name them all in the
+                <filename>SRC_URI</filename> statement as well.
+                For example, you could group separate configurations
+                specifically for Ethernet and graphics into their own files
+                and add those by using a <filename>SRC_URI</filename> statement
+                like the following in your append file:
                 <literallayout class='monospaced'>
      SRC_URI += "file://myconfig.cfg \
             file://eth.cfg \
@@ -1797,7 +1799,11 @@
                         </para></listitem>
                     <listitem><para>Separately run the
                         <filename>do_kernel_configme</filename> and
-                        <filename>do_kernel_configcheck</filename> tasks.
+                        <filename>do_kernel_configcheck</filename> tasks:
+                        <literallayout class='monospaced'>
+     $ bitbake linux-yocto -c kernel_configme -f
+     $ bitbake linux-yocto -c kernel_configcheck -f
+                        </literallayout>
                         </para></listitem>
                     <listitem><para>Take the resulting list of files from the
                         <filename>do_kernel_configcheck</filename> task
@@ -1834,135 +1840,14 @@
             </para>
 
             <para>
-                Iteratively working through steps two through four eventually yields
-                a minimal, streamlined configuration file.
-                Once you have the best <filename>.config</filename>, you can build the Linux
-                Yocto kernel.
-            </para>
-        </section>
-
-        <section id='determining-hardware-and-non-hardware-features-for-the-kernel-configuration-audit-phase'>
-            <title>Determining Hardware and Non-Hardware Features for the Kernel Configuration Audit Phase</title>
-
-            <para>
-                This section describes part of the kernel configuration audit
-                phase that most developers can ignore.
-                During this part of the audit phase, the contents of the final
-                <filename>.config</filename> file are compared against the
-                fragments specified by the system.
-                These fragments can be system fragments, distro fragments,
-                or user specified configuration elements.
-                Regardless of their origin, the OpenEmbedded build system
-                warns the user if a specific option is not included in the
-                final kernel configuration.
-            </para>
-
-            <para>
-                In order to not overwhelm the user with configuration warnings,
-                by default the system only reports on missing "hardware"
-                options because a missing hardware option could mean a boot
-                failure or that important hardware is not available.
-            </para>
-
-            <para>
-                To determine whether or not a given option is "hardware" or
-                "non-hardware", the kernel Metadata contains files that
-                classify individual or groups of options as either hardware
-                or non-hardware.
-                To better show this, consider a situation where the
-                Yocto Project kernel cache contains the following files:
-                <literallayout class='monospaced'>
-     kernel-cache/features/drm-psb/hardware.cfg
-     kernel-cache/features/kgdb/hardware.cfg
-     kernel-cache/ktypes/base/hardware.cfg
-     kernel-cache/bsp/mti-malta32/hardware.cfg
-     kernel-cache/bsp/fsl-mpc8315e-rdb/hardware.cfg
-     kernel-cache/bsp/qemu-ppc32/hardware.cfg
-     kernel-cache/bsp/qemuarma9/hardware.cfg
-     kernel-cache/bsp/mti-malta64/hardware.cfg
-     kernel-cache/bsp/arm-versatile-926ejs/hardware.cfg
-     kernel-cache/bsp/common-pc/hardware.cfg
-     kernel-cache/bsp/common-pc-64/hardware.cfg
-     kernel-cache/features/rfkill/non-hardware.cfg
-     kernel-cache/ktypes/base/non-hardware.cfg
-     kernel-cache/features/aufs/non-hardware.kcf
-     kernel-cache/features/ocf/non-hardware.kcf
-     kernel-cache/ktypes/base/non-hardware.kcf
-     kernel-cache/ktypes/base/hardware.kcf
-     kernel-cache/bsp/qemu-ppc32/hardware.kcf
-                </literallayout>
-                The following list provides explanations for the various
-                files:
-                <itemizedlist>
-                    <listitem><para><filename>hardware.kcf</filename>:
-                        Specifies a list of kernel Kconfig files that contain
-                        hardware options only.
-                        </para></listitem>
-                    <listitem><para><filename>non-hardware.kcf</filename>:
-                        Specifies a list of kernel Kconfig files that contain
-                        non-hardware options only.
-                        </para></listitem>
-                    <listitem><para><filename>hardware.cfg</filename>:
-                        Specifies a list of kernel
-                        <filename>CONFIG_</filename> options that are hardware,
-                        regardless of whether or not they are within a Kconfig
-                        file specified by a hardware or non-hardware
-                        Kconfig file (i.e. <filename>hardware.kcf</filename> or
-                        <filename>non-hardware.kcf</filename>).
-                        </para></listitem>
-                    <listitem><para><filename>non-hardware.cfg</filename>:
-                        Specifies a list of kernel
-                        <filename>CONFIG_</filename> options that are
-                        not hardware, regardless of whether or not they are
-                        within a Kconfig file specified by a hardware or
-                        non-hardware Kconfig file (i.e.
-                        <filename>hardware.kcf</filename> or
-                        <filename>non-hardware.kcf</filename>).
-                        </para></listitem>
-                </itemizedlist>
-                Here is a specific example using the
-                <filename>kernel-cache/bsp/mti-malta32/hardware.cfg</filename>:
-                <literallayout class='monospaced'>
-     CONFIG_SERIAL_8250
-     CONFIG_SERIAL_8250_CONSOLE
-     CONFIG_SERIAL_8250_NR_UARTS
-     CONFIG_SERIAL_8250_PCI
-     CONFIG_SERIAL_CORE
-     CONFIG_SERIAL_CORE_CONSOLE
-     CONFIG_VGA_ARB
-                </literallayout>
-                The kernel configuration audit automatically detects these
-                files (hence the names must be exactly the ones discussed here),
-                and uses them as inputs when generating warnings about the
-                final <filename>.config</filename> file.
-            </para>
-
-            <para>
-                A user-specified kernel Metadata repository, or recipe space
-                feature, can use these same files to classify options that are
-                found within its <filename>.cfg</filename> files as hardware
-                or non-hardware, to prevent the OpenEmbedded build system from
-                producing an error or warning when an option is not in the
-                final <filename>.config</filename> file.
+                Iteratively working through steps two through four eventually
+                yields a minimal, streamlined configuration file.
+                Once you have the best <filename>.config</filename>, you can
+                build the Linux Yocto kernel.
             </para>
         </section>
     </section>
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
     <section id='using-an-iterative-development-process'>
         <title>Using an Iterative Development Process</title>
 

documentation/kernel-dev/kernel-dev-concepts-appx.xml

@@ -479,6 +479,123 @@
             section for a detailed example that modifies the kernel.
         </para>
     </section>
+
+    <section id='determining-hardware-and-non-hardware-features-for-the-kernel-configuration-audit-phase'>
+        <title>Determining Hardware and Non-Hardware Features for the Kernel Configuration Audit Phase</title>
+
+        <para>
+            This section describes part of the kernel configuration audit
+            phase that most developers can ignore.
+            For general information on kernel configuration including
+            <filename>menuconfig</filename>, <filename>defconfig</filename>
+            files, and configuration fragments, see the
+            "<link linkend='configuring-the-kernel'>Configuring the Kernel</link>"
+            section.
+        </para>
+
+        <para>
+            During this part of the audit phase, the contents of the final
+            <filename>.config</filename> file are compared against the
+            fragments specified by the system.
+            These fragments can be system fragments, distro fragments,
+            or user-specified configuration elements.
+            Regardless of their origin, the OpenEmbedded build system
+            warns the user if a specific option is not included in the
+            final kernel configuration.
+        </para>
+
+        <para>
+            By default, in order to not overwhelm the user with
+            configuration warnings, the system only reports missing
+            "hardware" options as they could result in a boot
+            failure or indicate that important hardware is not available.
+        </para>
+
+        <para>
+            To determine whether or not a given option is "hardware" or
+            "non-hardware", the kernel Metadata contains files that
+            classify individual or groups of options as either hardware
+            or non-hardware.
+            To better show this, consider a situation where the
+            Yocto Project kernel cache contains the following files:
+            <literallayout class='monospaced'>
+     kernel-cache/features/drm-psb/hardware.cfg
+     kernel-cache/features/kgdb/hardware.cfg
+     kernel-cache/ktypes/base/hardware.cfg
+     kernel-cache/bsp/mti-malta32/hardware.cfg
+     kernel-cache/bsp/fsl-mpc8315e-rdb/hardware.cfg
+     kernel-cache/bsp/qemu-ppc32/hardware.cfg
+     kernel-cache/bsp/qemuarma9/hardware.cfg
+     kernel-cache/bsp/mti-malta64/hardware.cfg
+     kernel-cache/bsp/arm-versatile-926ejs/hardware.cfg
+     kernel-cache/bsp/common-pc/hardware.cfg
+     kernel-cache/bsp/common-pc-64/hardware.cfg
+     kernel-cache/features/rfkill/non-hardware.cfg
+     kernel-cache/ktypes/base/non-hardware.cfg
+     kernel-cache/features/aufs/non-hardware.kcf
+     kernel-cache/features/ocf/non-hardware.kcf
+     kernel-cache/ktypes/base/non-hardware.kcf
+     kernel-cache/ktypes/base/hardware.kcf
+     kernel-cache/bsp/qemu-ppc32/hardware.kcf
+            </literallayout>
+            The following list provides explanations for the various
+            files:
+            <itemizedlist>
+                <listitem><para>
+                    <filename>hardware.kcf</filename>:
+                    Specifies a list of kernel Kconfig files that contain
+                    hardware options only.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>non-hardware.kcf</filename>:
+                    Specifies a list of kernel Kconfig files that contain
+                    non-hardware options only.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>hardware.cfg</filename>:
+                    Specifies a list of kernel <filename>CONFIG_</filename>
+                    options that are hardware, regardless of whether or not
+                    they are within a Kconfig file specified by a hardware
+                    or non-hardware Kconfig file (i.e.
+                    <filename>hardware.kcf</filename> or
+                    <filename>non-hardware.kcf</filename>).
+                    </para></listitem>
+                <listitem><para>
+                    <filename>non-hardware.cfg</filename>:
+                    Specifies a list of kernel <filename>CONFIG_</filename>
+                    options that are not hardware, regardless of whether or
+                    not they are within a Kconfig file specified by a
+                    hardware or non-hardware Kconfig file (i.e.
+                    <filename>hardware.kcf</filename> or
+                    <filename>non-hardware.kcf</filename>).
+                    </para></listitem>
+            </itemizedlist>
+            Here is a specific example using the
+            <filename>kernel-cache/bsp/mti-malta32/hardware.cfg</filename>:
+            <literallayout class='monospaced'>
+     CONFIG_SERIAL_8250
+     CONFIG_SERIAL_8250_CONSOLE
+     CONFIG_SERIAL_8250_NR_UARTS
+     CONFIG_SERIAL_8250_PCI
+     CONFIG_SERIAL_CORE
+     CONFIG_SERIAL_CORE_CONSOLE
+     CONFIG_VGA_ARB
+            </literallayout>
+            The kernel configuration audit automatically detects these
+            files (hence the names must be exactly the ones discussed here),
+            and uses them as inputs when generating warnings about the
+            final <filename>.config</filename> file.
+        </para>
+
+        <para>
+            A user-specified kernel Metadata repository, or recipe space
+            feature, can use these same files to classify options that are
+            found within its <filename>.cfg</filename> files as hardware
+            or non-hardware, to prevent the OpenEmbedded build system from
+            producing an error or warning when an option is not in the
+            final <filename>.config</filename> file.
+        </para>
+    </section>
 </appendix>
 <!--
 vim: expandtab tw=80 ts=4