622 lines
31 KiB
XML
622 lines
31 KiB
XML
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
|
|
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
|
|
|
|
<appendix id='kernel-dev-concepts-appx'>
|
|
<title>Advanced Kernel Concepts</title>
|
|
|
|
<section id='kernel-big-picture'>
|
|
<title>Yocto Project Kernel Development and Maintenance</title>
|
|
|
|
<para>
|
|
Kernels available through the Yocto Project (Yocto Linux kernels),
|
|
like other kernels, are based off the Linux kernel releases from
|
|
<ulink url='http://www.kernel.org'></ulink>.
|
|
At the beginning of a major Linux kernel development cycle, the
|
|
Yocto Project team chooses a Linux kernel based on factors such as
|
|
release timing, the anticipated release timing of final upstream
|
|
<filename>kernel.org</filename> versions, and Yocto Project
|
|
feature requirements.
|
|
Typically, the Linux kernel chosen is in the final stages of
|
|
development by the Linux community.
|
|
In other words, the Linux kernel is in the release candidate
|
|
or "rc" phase and has yet to reach final release.
|
|
But, by being in the final stages of external development, the
|
|
team knows that the <filename>kernel.org</filename> final release
|
|
will clearly be within the early stages of the Yocto Project
|
|
development window.
|
|
</para>
|
|
|
|
<para>
|
|
This balance allows the Yocto Project team to deliver the most
|
|
up-to-date Yocto Linux kernel possible, while still ensuring that
|
|
the team has a stable official release for the baseline Linux
|
|
kernel version.
|
|
</para>
|
|
|
|
<para>
|
|
As implied earlier, the ultimate source for Yocto Linux kernels
|
|
are released kernels from <filename>kernel.org</filename>.
|
|
In addition to a foundational kernel from
|
|
<filename>kernel.org</filename>, the available Yocto Linux kernels
|
|
contain a mix of important new mainline developments, non-mainline
|
|
developments (when no alternative exists), Board Support Package
|
|
(BSP) developments, and custom features.
|
|
These additions result in a commercially released Yocto
|
|
Project Linux kernel that caters to specific embedded designer
|
|
needs for targeted hardware.
|
|
</para>
|
|
|
|
<para>
|
|
You can find a web interface to the Yocto Linux kernels in the
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#source-repositories'>Source Repositories</ulink>
|
|
at
|
|
<ulink url='&YOCTO_GIT_URL;'></ulink>.
|
|
If you look at the interface, you will see to the left a
|
|
grouping of Git repositories titled "Yocto Linux Kernel".
|
|
Within this group, you will find several Linux Yocto kernels
|
|
developed and included with Yocto Project releases:
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
<emphasis><filename>linux-yocto-4.1</filename>:</emphasis>
|
|
The stable Yocto Project kernel to use with the Yocto
|
|
Project Release 2.0.
|
|
This kernel is based on the Linux 4.1 released kernel.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis><filename>linux-yocto-4.4</filename>:</emphasis>
|
|
The stable Yocto Project kernel to use with the Yocto
|
|
Project Release 2.1.
|
|
This kernel is based on the Linux 4.4 released kernel.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis><filename>linux-yocto-4.6</filename>:</emphasis>
|
|
A temporary kernel that is not tied to any Yocto Project
|
|
release.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis><filename>linux-yocto-4.8</filename>:</emphasis>
|
|
The stable yocto Project kernel to use with the Yocto
|
|
Project Release 2.2.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis><filename>linux-yocto-4.9</filename>:</emphasis>
|
|
The stable Yocto Project kernel to use with the Yocto
|
|
Project Release 2.3.
|
|
This kernel is based on the Linux 4.9 released kernel.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis><filename>linux-yocto-4.10</filename>:</emphasis>
|
|
The default stable Yocto Project kernel to use with the
|
|
Yocto Project Release 2.3.
|
|
This kernel is based on the Linux 4.10 released kernel.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis><filename>linux-yocto-4.12</filename>:</emphasis>
|
|
The default stable Yocto Project kernel to use with the
|
|
Yocto Project Release 2.4.
|
|
This kernel is based on the Linux 4.12 released kernel.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis><filename>yocto-kernel-cache</filename>:</emphasis>
|
|
The <filename>linux-yocto-cache</filename> contains
|
|
patches and configurations for the linux-yocto kernel
|
|
tree.
|
|
This repository is useful when working on the linux-yocto
|
|
kernel.
|
|
For more information on this "Advanced Kernel Metadata",
|
|
see the
|
|
"<link linkend='kernel-dev-advanced'>Working With Advanced Metadata (<filename>yocto-kernel-cache</filename>)</link>"
|
|
Chapter.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis><filename>linux-yocto-dev</filename>:</emphasis>
|
|
A development kernel based on the latest upstream release
|
|
candidate available.
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
<note><title>Notes</title>
|
|
Long Term Support Initiative (LTSI) for Yocto Linux
|
|
kernels is as follows:
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
For Yocto Project releases 1.7, 1.8, and 2.0,
|
|
the LTSI kernel is
|
|
<filename>linux-yocto-3.14</filename>.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
For Yocto Project releases 2.1, 2.2, and 2.3,
|
|
the LTSI kernel is <filename>linux-yocto-4.1</filename>.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
For Yocto Project release 2.4, the LTSI kernel is
|
|
<filename>linux-yocto-4.9</filename>
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<filename>linux-yocto-4.4</filename> is an LTS
|
|
kernel.
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
</note>
|
|
</para>
|
|
|
|
<para>
|
|
Once a Yocto Linux kernel is officially released, the Yocto
|
|
Project team goes into their next development cycle, or upward
|
|
revision (uprev) cycle, while still continuing maintenance on the
|
|
released kernel.
|
|
It is important to note that the most sustainable and stable way
|
|
to include feature development upstream is through a kernel uprev
|
|
process.
|
|
Back-porting hundreds of individual fixes and minor features from
|
|
various kernel versions is not sustainable and can easily
|
|
compromise quality.
|
|
</para>
|
|
|
|
<para>
|
|
During the uprev cycle, the Yocto Project team uses an ongoing
|
|
analysis of Linux kernel development, BSP support, and release
|
|
timing to select the best possible <filename>kernel.org</filename>
|
|
Linux kernel version on which to base subsequent Yocto Linux
|
|
kernel development.
|
|
The team continually monitors Linux community kernel development
|
|
to look for significant features of interest.
|
|
The team does consider back-porting large features if they have a
|
|
significant advantage.
|
|
User or community demand can also trigger a back-port or creation
|
|
of new functionality in the Yocto Project baseline kernel during
|
|
the uprev cycle.
|
|
</para>
|
|
|
|
<para>
|
|
Generally speaking, every new Linux kernel both adds features and
|
|
introduces new bugs.
|
|
These consequences are the basic properties of upstream
|
|
Linux kernel development and are managed by the Yocto Project
|
|
team's Yocto Linux kernel development strategy.
|
|
It is the Yocto Project team's policy to not back-port minor
|
|
features to the released Yocto Linux kernel.
|
|
They only consider back-porting significant technological
|
|
jumps ‐ and, that is done after a complete gap analysis.
|
|
The reason for this policy is that back-porting any small to
|
|
medium sized change from an evolving Linux kernel can easily
|
|
create mismatches, incompatibilities and very subtle errors.
|
|
</para>
|
|
|
|
<para>
|
|
The policies described in this section result in both a stable
|
|
and a cutting edge Yocto Linux kernel that mixes forward ports of
|
|
existing Linux kernel features and significant and critical new
|
|
functionality.
|
|
Forward porting Linux kernel functionality into the Yocto Linux
|
|
kernels available through the Yocto Project can be thought of as
|
|
a "micro uprev."
|
|
The many “micro uprevs” produce a Yocto Linux kernel version with
|
|
a mix of important new mainline, non-mainline, BSP developments
|
|
and feature integrations.
|
|
This Yocto Linux kernel gives insight into new features and
|
|
allows focused amounts of testing to be done on the kernel,
|
|
which prevents surprises when selecting the next major uprev.
|
|
The quality of these cutting edge Yocto Linux kernels is evolving
|
|
and the kernels are used in leading edge feature and BSP
|
|
development.
|
|
</para>
|
|
</section>
|
|
|
|
<section id='yocto-linux-kernel-architecture-and-branching-strategies'>
|
|
<title>Yocto Linux Kernel Architecture and Branching Strategies</title>
|
|
|
|
<para>
|
|
As mentioned earlier, a key goal of the Yocto Project is
|
|
to present the developer with a kernel that has a clear and
|
|
continuous history that is visible to the user.
|
|
The architecture and mechanisms, in particular the branching
|
|
strategies, used achieve that goal in a manner similar to
|
|
upstream Linux kernel development in
|
|
<filename>kernel.org</filename>.
|
|
</para>
|
|
|
|
<para>
|
|
You can think of a Yocto Linux kernel as consisting of a
|
|
baseline Linux kernel with added features logically structured
|
|
on top of the baseline.
|
|
The features are tagged and organized by way of a branching
|
|
strategy implemented by the Yocto Project team using the
|
|
Source Code Manager (SCM) Git.
|
|
<note><title>Notes</title>
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
Git is the obvious SCM for meeting the Yocto Linux
|
|
kernel organizational and structural goals described
|
|
in this section.
|
|
Not only is Git the SCM for Linux kernel development in
|
|
<filename>kernel.org</filename> but, Git continues to
|
|
grow in popularity and supports many different work
|
|
flows, front-ends and management techniques.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
You can find documentation on Git at
|
|
<ulink url='http://git-scm.com/documentation'></ulink>.
|
|
You can also get an introduction to Git as it
|
|
applies to the Yocto Project in the
|
|
"<ulink url='&YOCTO_DOCS_REF_URL;#git'>Git</ulink>"
|
|
section in the Yocto Project Reference Manual.
|
|
The latter reference provides an overview of
|
|
Git and presents a minimal set of Git commands
|
|
that allows you to be functional using Git.
|
|
You can use as much, or as little, of what Git
|
|
has to offer to accomplish what you need for your
|
|
project.
|
|
You do not have to be a "Git Expert" in order to
|
|
use it with the Yocto Project.
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
</note>
|
|
</para>
|
|
|
|
<para>
|
|
Using Git's tagging and branching features, the Yocto Project
|
|
team creates kernel branches at points where functionality is
|
|
no longer shared and thus, needs to be isolated.
|
|
For example, board-specific incompatibilities would require
|
|
different functionality and would require a branch to
|
|
separate the features.
|
|
Likewise, for specific kernel features, the same branching
|
|
strategy is used.
|
|
</para>
|
|
|
|
<para>
|
|
This "tree-like" architecture results in a structure that has
|
|
features organized to be specific for particular functionality,
|
|
single kernel types, or a subset of kernel types.
|
|
Thus, the user has the ability to see the added features and the
|
|
commits that make up those features.
|
|
In addition to being able to see added features, the user
|
|
can also view the history of what made up the baseline
|
|
Linux kernel.
|
|
</para>
|
|
|
|
<para>
|
|
Another consequence of this strategy results in not having to
|
|
store the same feature twice internally in the tree.
|
|
Rather, the kernel team stores the unique differences required
|
|
to apply the feature onto the kernel type in question.
|
|
<note>
|
|
The Yocto Project team strives to place features in the tree
|
|
such that features can be shared by all boards and kernel
|
|
types where possible.
|
|
However, during development cycles or when large features
|
|
are merged, the team cannot always follow this practice.
|
|
In those cases, the team uses isolated branches to merge
|
|
features.
|
|
</note>
|
|
</para>
|
|
|
|
<para>
|
|
BSP-specific code additions are handled in a similar manner to
|
|
kernel-specific additions.
|
|
Some BSPs only make sense given certain kernel types.
|
|
So, for these types, the team creates branches off the end
|
|
of that kernel type for all of the BSPs that are supported on
|
|
that kernel type.
|
|
From the perspective of the tools that create the BSP branch,
|
|
the BSP is really no different than a feature.
|
|
Consequently, the same branching strategy applies to BSPs as
|
|
it does to kernel features.
|
|
So again, rather than store the BSP twice, the team only
|
|
stores the unique differences for the BSP across the supported
|
|
multiple kernels.
|
|
</para>
|
|
|
|
<para>
|
|
While this strategy can result in a tree with a significant number
|
|
of branches, it is important to realize that from the developer's
|
|
point of view, there is a linear path that travels from the
|
|
baseline <filename>kernel.org</filename>, through a select
|
|
group of features and ends with their BSP-specific commits.
|
|
In other words, the divisions of the kernel are transparent and
|
|
are not relevant to the developer on a day-to-day basis.
|
|
From the developer's perspective, this path is the "master" branch
|
|
in Git terms.
|
|
The developer does not need to be aware of the existence of any
|
|
other branches at all.
|
|
Of course, value exists in the having these branches in the tree,
|
|
should a person decide to explore them.
|
|
For example, a comparison between two BSPs at either the commit
|
|
level or at the line-by-line code <filename>diff</filename> level
|
|
is now a trivial operation.
|
|
</para>
|
|
|
|
<para>
|
|
The following illustration shows the conceptual Yocto
|
|
Linux kernel.
|
|
<imagedata fileref="figures/kernel-architecture-overview.png" width="6in" depth="7in" align="center" scale="100" />
|
|
</para>
|
|
|
|
<para>
|
|
In the illustration, the "Kernel.org Branch Point" marks the
|
|
specific spot (or Linux kernel release) from which the
|
|
Yocto Linux kernel is created.
|
|
From this point forward in the tree, features and differences
|
|
are organized and tagged.
|
|
</para>
|
|
|
|
<para>
|
|
The "Yocto Project Baseline Kernel" contains functionality that
|
|
is common to every kernel type and BSP that is organized
|
|
further along in the tree.
|
|
Placing these common features in the tree this way means
|
|
features do not have to be duplicated along individual
|
|
branches of the tree structure.
|
|
</para>
|
|
|
|
<para>
|
|
From the "Yocto Project Baseline Kernel", branch points represent
|
|
specific functionality for individual Board Support Packages
|
|
(BSPs) as well as real-time kernels.
|
|
The illustration represents this through three BSP-specific
|
|
branches and a real-time kernel branch.
|
|
Each branch represents some unique functionality for the BSP
|
|
or for a real-time Yocto Linux kernel.
|
|
</para>
|
|
|
|
<para>
|
|
In this example structure, the "Real-time (rt) Kernel" branch has
|
|
common features for all real-time Yocto Linux kernels and
|
|
contains more branches for individual BSP-specific real-time
|
|
kernels.
|
|
The illustration shows three branches as an example.
|
|
Each branch points the way to specific, unique features for a
|
|
respective real-time kernel as they apply to a given BSP.
|
|
</para>
|
|
|
|
<para>
|
|
The resulting tree structure presents a clear path of markers
|
|
(or branches) to the developer that, for all practical
|
|
purposes, is the Yocto Linux kernel needed for any given set of
|
|
requirements.
|
|
<note>
|
|
Keep in mind the figure does not take into account all the
|
|
supported Yocto Linux kernels, but rather shows a single
|
|
generic kernel just for conceptual purposes.
|
|
Also keep in mind that this structure represents the Yocto
|
|
Project
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#source-repositories'>Source Repositories</ulink>
|
|
that are either pulled from during the build or established
|
|
on the host development system prior to the build by either
|
|
cloning a particular kernel's Git repository or by
|
|
downloading and unpacking a tarball.
|
|
</note>
|
|
</para>
|
|
|
|
<para>
|
|
Working with the kernel as a structured tree follows recognized
|
|
community best practices.
|
|
In particular, the kernel as shipped with the product, should be
|
|
considered an "upstream source" and viewed as a series of
|
|
historical and documented modifications (commits).
|
|
These modifications represent the development and stabilization
|
|
done by the Yocto Project kernel development team.
|
|
</para>
|
|
|
|
<para>
|
|
Because commits only change at significant release points in the
|
|
product life cycle, developers can work on a branch created
|
|
from the last relevant commit in the shipped Yocto Project Linux
|
|
kernel.
|
|
As mentioned previously, the structure is transparent to the
|
|
developer because the kernel tree is left in this state after
|
|
cloning and building the kernel.
|
|
</para>
|
|
</section>
|
|
|
|
<section id='kernel-build-file-hierarchy'>
|
|
<title>Kernel Build File Hierarchy</title>
|
|
|
|
<para>
|
|
Upstream storage of all the available kernel source code is
|
|
one thing, while representing and using the code on your host
|
|
development system is another.
|
|
Conceptually, you can think of the kernel source repositories
|
|
as all the source files necessary for all the supported
|
|
Yocto Linux kernels.
|
|
As a developer, you are just interested in the source files
|
|
for the kernel on which you are working.
|
|
And, furthermore, you need them available on your host system.
|
|
</para>
|
|
|
|
<para>
|
|
Kernel source code is available on your host system several
|
|
different ways:
|
|
<itemizedlist>
|
|
<listitem><para>
|
|
<emphasis>Files Accessed While using <filename>devtool</filename>:</emphasis>
|
|
<filename>devtool</filename>, which is available with the
|
|
Yocto Project, is the preferred method by which to
|
|
modify the kernel.
|
|
See the
|
|
"<link linkend='kernel-modification-workflow'>Kernel Modification Workflow</link>"
|
|
section.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis>Cloned Repository:</emphasis>
|
|
If you are working in the kernel all the time, you probably
|
|
would want to set up your own local Git repository of the
|
|
Yocto Linux kernel tree.
|
|
For information on how to clone a Yocto Linux kernel
|
|
Git repository, see the
|
|
"<link linkend='preparing-the-build-host-to-work-on-the-kernel'>Preparing the Build Host to Work on the Kernel</link>"
|
|
section.
|
|
</para></listitem>
|
|
<listitem><para>
|
|
<emphasis>Temporary Source Files from a Build:</emphasis>
|
|
If you just need to make some patches to the kernel using
|
|
a traditional BitBake workflow (i.e. not using the
|
|
<filename>devtool</filename>), you can access temporary
|
|
kernel source files that were extracted and used during
|
|
a kernel build.
|
|
</para></listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<para>
|
|
The temporary kernel source files resulting from a build using
|
|
BitBake have a particular hierarchy.
|
|
When you build the kernel on your development system, all files
|
|
needed for the build are taken from the source repositories
|
|
pointed to by the
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
|
|
variable and gathered in a temporary work area where they are
|
|
subsequently used to create the unique kernel.
|
|
Thus, in a sense, the process constructs a local source tree
|
|
specific to your kernel from which to generate the new kernel
|
|
image.
|
|
</para>
|
|
|
|
<para>
|
|
The following figure shows the temporary file structure
|
|
created on your host system when you build the kernel using
|
|
Bitbake.
|
|
This
|
|
<ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
|
|
contains all the source files used during the build.
|
|
<imagedata fileref="figures/kernel-overview-2-generic.png"
|
|
width="6in" depth="5in" align="center" scale="100" />
|
|
</para>
|
|
|
|
<para>
|
|
Again, for additional information on the Yocto Project kernel's
|
|
architecture and its branching strategy, see the
|
|
"<link linkend='yocto-linux-kernel-architecture-and-branching-strategies'>Yocto Linux Kernel Architecture and Branching Strategies</link>"
|
|
section.
|
|
You can also reference the
|
|
"<link linkend='using-devtool-to-patch-the-kernel'>Using <filename>devtool</filename> to Patch the Kernel</link>"
|
|
and
|
|
"<link linkend='using-traditional-kernel-development-to-patch-the-kernel'>Using Traditional Kernel Development to Patch the Kernel</link>"
|
|
sections for 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 in
|
|
<filename>yocto-kernel-cache</filename> contains files that
|
|
classify individual or groups of options as either hardware
|
|
or non-hardware.
|
|
To better show this, consider a situation where the
|
|
<filename>yocto-kernel-cache</filename> contains the following
|
|
files:
|
|
<literallayout class='monospaced'>
|
|
yocto-kernel-cache/features/drm-psb/hardware.cfg
|
|
yocto-kernel-cache/features/kgdb/hardware.cfg
|
|
yocto-kernel-cache/ktypes/base/hardware.cfg
|
|
yocto-kernel-cache/bsp/mti-malta32/hardware.cfg
|
|
yocto-kernel-cache/bsp/fsl-mpc8315e-rdb/hardware.cfg
|
|
yocto-kernel-cache/bsp/qemu-ppc32/hardware.cfg
|
|
yocto-kernel-cache/bsp/qemuarma9/hardware.cfg
|
|
yocto-kernel-cache/bsp/mti-malta64/hardware.cfg
|
|
yocto-kernel-cache/bsp/arm-versatile-926ejs/hardware.cfg
|
|
yocto-kernel-cache/bsp/common-pc/hardware.cfg
|
|
yocto-kernel-cache/bsp/common-pc-64/hardware.cfg
|
|
yocto-kernel-cache/features/rfkill/non-hardware.cfg
|
|
yocto-kernel-cache/ktypes/base/non-hardware.cfg
|
|
yocto-kernel-cache/features/aufs/non-hardware.kcf
|
|
yocto-kernel-cache/features/ocf/non-hardware.kcf
|
|
yocto-kernel-cache/ktypes/base/non-hardware.kcf
|
|
yocto-kernel-cache/ktypes/base/hardware.kcf
|
|
yocto-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
|
|
-->
|