[gnome-continuous-yocto/gnomeostree-3.28-rocko: 7917/8267] kernel-dev: Updated kernel configuration section
- From: Emmanuele Bassi <ebassi src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [gnome-continuous-yocto/gnomeostree-3.28-rocko: 7917/8267] kernel-dev: Updated kernel configuration section
- Date: Sun, 17 Dec 2017 06:55:15 +0000 (UTC)
commit b8dfb037646c4ccbfda61241e654a703a16cf14b
Author: Scott Rifenbark <srifenbark gmail com>
Date: Tue Sep 26 14:33:56 2017 -0700
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 | 363 +++++++-------------
.../kernel-dev/kernel-dev-concepts-appx.xml | 117 +++++++
2 files changed, 241 insertions(+), 239 deletions(-)
---
diff --git a/documentation/kernel-dev/kernel-dev-common.xml b/documentation/kernel-dev/kernel-dev-common.xml
index 0614414..310e223 100644
--- a/documentation/kernel-dev/kernel-dev-common.xml
+++ b/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>
diff --git a/documentation/kernel-dev/kernel-dev-concepts-appx.xml
b/documentation/kernel-dev/kernel-dev-concepts-appx.xml
index 4cacdd1..6d23685 100644
--- a/documentation/kernel-dev/kernel-dev-concepts-appx.xml
+++ b/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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
