documentation/kernel-manual: Scrubbed the Yocto Project term
Changed all occurrences of "Yocto Project" to terms better suited to reality. (From yocto-docs rev: fdd7b8c2bcbaf566cad336c67c582c2a24aa9dc1) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
parent
d779c83e71
commit
e70dc3ab99
|
@ -9,10 +9,10 @@
|
|||
<section id='concepts-org'>
|
||||
<title>Introduction</title>
|
||||
<para>
|
||||
This chapter provides conceptual information about the Yocto Project kernel:
|
||||
This chapter provides conceptual information about the kernel:
|
||||
<itemizedlist>
|
||||
<listitem><para>Kernel Goals</para></listitem>
|
||||
<listitem><para>Yocto Project Kernel Development and Maintenance Overview</para></listitem>
|
||||
<listitem><para>Kernel Development and Maintenance Overview</para></listitem>
|
||||
<listitem><para>Kernel Architecture</para></listitem>
|
||||
<listitem><para>Kernel Tools</para></listitem>
|
||||
</itemizedlist>
|
||||
|
@ -25,8 +25,8 @@
|
|||
The complexity of embedded kernel design has increased dramatically.
|
||||
Whether it is managing multiple implementations of a particular feature or tuning and
|
||||
optimizing board specific features, flexibility and maintainability are key concerns.
|
||||
The Yocto Project Linux kernel is presented with the embedded
|
||||
developer's needs in mind and has evolved to assist in these key concerns.
|
||||
The Linux kernels available through the Yocto Project are presented with the embedded
|
||||
developer's needs in mind and have evolved to assist in these key concerns.
|
||||
For example, prior methods such as applying hundreds of patches to an extracted
|
||||
tarball have been replaced with proven techniques that allow easy inspection,
|
||||
bisection and analysis of changes.
|
||||
|
@ -34,7 +34,7 @@
|
|||
collaboration with the thousands of upstream development projects.
|
||||
</para>
|
||||
<para>
|
||||
With all these considerations in mind, the Yocto Project kernel and development team
|
||||
With all these considerations in mind, the Yocto Project's kernel and development team
|
||||
strives to attain these goals:
|
||||
<itemizedlist>
|
||||
<listitem><para>Allow the end user to leverage community best practices to seamlessly
|
||||
|
@ -63,12 +63,12 @@
|
|||
<section id='kernel-big-picture'>
|
||||
<title>Yocto Project Kernel Development and Maintenance Overview</title>
|
||||
<para>
|
||||
The Yocto Project kernel, like other kernels, is based off the Linux kernel release
|
||||
from <ulink url='http://www.kernel.org'></ulink>.
|
||||
Kernels available through the Yocto Project, like other kernels, are based off the Linux
|
||||
kernel releases from <ulink url='http://www.kernel.org'></ulink>.
|
||||
At the beginning of a major development cycle, the Yocto Project team
|
||||
chooses its Yocto Project kernel
|
||||
based on factors like release timing, the anticipated release timing of final
|
||||
upstream <filename>kernel.org</filename> versions, and Yocto Project feature requirements.
|
||||
chooses its 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 kernel chosen is in the
|
||||
final stages of development by the community.
|
||||
In other words, the kernel is in the release
|
||||
|
@ -80,21 +80,21 @@
|
|||
<para>
|
||||
This balance allows the team to deliver the most up-to-date kernel
|
||||
as possible, while still ensuring that the team has a stable official release for
|
||||
the baseline kernel version.
|
||||
the baseline Linux kernel version.
|
||||
</para>
|
||||
<para>
|
||||
The ultimate source for the Yocto Project kernel is a released kernel
|
||||
The ultimate source for kernels available through the Yocto Project are released kernels
|
||||
from <filename>kernel.org</filename>.
|
||||
In addition to a foundational kernel from <filename>kernel.org</filename>, the released
|
||||
Yocto Project kernel contains a mix of important new mainline
|
||||
In addition to a foundational kernel from <filename>kernel.org</filename>, the
|
||||
kernels available through the contain a mix of important new mainline
|
||||
developments, non-mainline developments (when there is no alternative),
|
||||
Board Support Package (BSP) developments,
|
||||
and custom features.
|
||||
These additions result in a commercially released Yocto Project kernel that caters
|
||||
These additions result in a commercially released Yocto Project Linux kernel that caters
|
||||
to specific embedded designer needs for targeted hardware.
|
||||
</para>
|
||||
<para>
|
||||
Once a Yocto Project kernel is officially released, the Yocto Project team goes into
|
||||
Once a 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
|
||||
|
@ -127,8 +127,8 @@
|
|||
These policies result in both a stable and a cutting
|
||||
edge kernel that mixes forward ports of existing features and significant and critical
|
||||
new functionality.
|
||||
Forward porting functionality in the Yocto Project kernel can be thought of as a
|
||||
"micro uprev."
|
||||
Forward porting functionality in the kernels available through the Yocto Project kernel
|
||||
can be thought of as a "micro uprev."
|
||||
The many “micro uprevs” produce a kernel version with a mix of
|
||||
important new mainline, non-mainline, BSP developments and feature integrations.
|
||||
This kernel gives insight into new features and allows focused
|
||||
|
@ -142,7 +142,8 @@
|
|||
<section id='kernel-architecture'>
|
||||
<title>Kernel Architecture</title>
|
||||
<para>
|
||||
This section describes the architecture of the Yocto Project kernel and provides information
|
||||
This section describes the architecture of the kernels available through the
|
||||
Yocto Project and provides information
|
||||
on the mechanisms used to achieve that architecture.
|
||||
</para>
|
||||
|
||||
|
@ -156,7 +157,7 @@
|
|||
upstream <filename>kernel.org</filename>.
|
||||
</para>
|
||||
<para>
|
||||
You can think of the Yocto Project kernel as consisting of a baseline kernel with
|
||||
You can think of a Yocto Project 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
|
||||
source code manager (SCM) Git.
|
||||
|
@ -305,9 +306,9 @@
|
|||
<section id='kernel-configuration'>
|
||||
<title>Kernel Configuration</title>
|
||||
<para>
|
||||
Kernel configuration, along with kernel features, defines how a Linux Yocto
|
||||
kernel image is built.
|
||||
Through configuration settings, you can customize a Linux Yocto kernel to be
|
||||
Kernel configuration, along with kernel features, defines how a kernel
|
||||
image is built for the Yocto Project.
|
||||
Through configuration settings, you can customize a Yocto Project kernel to be
|
||||
specific to particular hardware.
|
||||
For example, you can specify sound support or networking support.
|
||||
This section describes basic concepts behind Kernel configuration within the
|
||||
|
@ -316,9 +317,9 @@
|
|||
</para>
|
||||
|
||||
<para>
|
||||
Conceptually, Linux Yocto kernel configuration occurs similarly to that needed for any
|
||||
Conceptually, configuration of a Yocto Project kernel occurs similarly to that needed for any
|
||||
Linux kernel.
|
||||
The Linux Yocto kernel build process uses a <filename>.config</filename> file, which
|
||||
The build process for a Yocto Project kernel uses a <filename>.config</filename> file, which
|
||||
is created through the Linux Kernel Coinfiguration (LKC) tool.
|
||||
You can directly set various configurations in the
|
||||
<filename>.config</filename> file by using the <filename>menuconfig</filename>
|
||||
|
@ -352,7 +353,7 @@
|
|||
list of kernel options just as they would appear syntactically in the
|
||||
<filename>.config</filename> file.
|
||||
Configuration fragments are typically logical groupings and are assembled
|
||||
by the Yocto Project build system to produce input used by the LKC
|
||||
by the OpenEmbedded build system to produce input used by the LKC
|
||||
that ultimately generates the <filename>.config</filename> file.</para>
|
||||
<para>The
|
||||
<filename><ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'>KERNEL_FEATURES</ulink></filename>
|
||||
|
@ -384,20 +385,6 @@
|
|||
with the <filename>kernel.org</filename> history and development.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
<!--<para>
|
||||
WRITER NOTE: Put this in for post 1.1 if possible:
|
||||
|
||||
The tools that construct a kernel tree will be discussed later in this
|
||||
document. The following tools form the foundation of the Yocto Project
|
||||
kernel toolkit:
|
||||
<itemizedlist>
|
||||
<listitem><para>git : distributed revision control system created by Linus Torvalds</para></listitem>
|
||||
<listitem><para>guilt: quilt on top of git</para></listitem>
|
||||
<listitem><para>*cfg : kernel configuration management and classification</para></listitem>
|
||||
<listitem><para>kgit*: Yocto Project kernel tree creation and management tools</para></listitem>
|
||||
<listitem><para>scc : series & configuration compiler</para></listitem>
|
||||
</itemizedlist>
|
||||
</para> -->
|
||||
</section>
|
||||
</chapter>
|
||||
<!--
|
||||
|
|
|
@ -9,26 +9,26 @@
|
|||
<section id='book-intro'>
|
||||
<title>Introduction</title>
|
||||
<para>
|
||||
The Yocto Project presents the kernel as a fully patched, history-clean Git
|
||||
repository.
|
||||
The Git tree represents the selected features, board support,
|
||||
The Yocto Project presents kernels as a fully patched, history-clean Git
|
||||
repositories.
|
||||
Each repository represents selected features, board support,
|
||||
and configurations extensively tested by the Yocto Project.
|
||||
The Yocto Project kernel allows the end user to leverage community
|
||||
Yocto Project kernels allow the end user to leverage community
|
||||
best practices to seamlessly manage the development, build and debug cycles.
|
||||
</para>
|
||||
<para>
|
||||
This manual describes the Yocto Project kernel by providing information
|
||||
on its history, organization, benefits, and use.
|
||||
This manual describes Yocto Project kernels by providing information
|
||||
on history, organization, benefits, and use.
|
||||
The manual consists of two sections:
|
||||
<itemizedlist>
|
||||
<listitem><para><emphasis>Concepts:</emphasis> Describes concepts behind the kernel.
|
||||
You will understand how the kernel is organized and why it is organized in
|
||||
the way it is. You will understand the benefits of the kernel's organization
|
||||
<listitem><para><emphasis>Concepts:</emphasis> Describes concepts behind a kernel.
|
||||
You will understand how a kernel is organized and why it is organized in
|
||||
the way it is. You will understand the benefits of a kernel's organization
|
||||
and the mechanisms used to work with the kernel and how to apply it in your
|
||||
design process.</para></listitem>
|
||||
<listitem><para><emphasis>Using the Kernel:</emphasis> Describes best practices
|
||||
<listitem><para><emphasis>Using a Kernel:</emphasis> Describes best practices
|
||||
and "how-to" information
|
||||
that lets you put the kernel to practical use.
|
||||
that lets you put a kernel to practical use.
|
||||
Some examples are how to examine changes in a branch and how to
|
||||
save kernel modifications.</para></listitem>
|
||||
</itemizedlist>
|
||||
|
|
|
@ -10,7 +10,7 @@
|
|||
<section id='actions-org'>
|
||||
<title>Introduction</title>
|
||||
<para>
|
||||
This chapter describes how to accomplish tasks involving the kernel's tree structure.
|
||||
This chapter describes how to accomplish tasks involving a kernel's tree structure.
|
||||
The information is designed to help the developer that wants to modify the Yocto
|
||||
Project kernel and contribute changes upstream to the Yocto Project.
|
||||
The information covers the following:
|
||||
|
@ -25,7 +25,7 @@
|
|||
<section id='tree-construction'>
|
||||
<title>Tree Construction</title>
|
||||
<para>
|
||||
This section describes construction of the Yocto Project kernel repositories
|
||||
This section describes construction of the Yocto Project kernel source repositories
|
||||
as accomplished by the Yocto Project team to create kernel repositories.
|
||||
These kernel repositories are found at
|
||||
<ulink url='&YOCTO_GIT_URL;/cgit.cgi'>&YOCTO_GIT_URL;/cgit.cgi</ulink>
|
||||
|
@ -34,25 +34,27 @@
|
|||
compiling and executing the set of feature descriptions for every BSP/feature
|
||||
in the product.
|
||||
Those feature descriptions list all necessary patches,
|
||||
configuration, branching, tagging and feature divisions found in the kernel.
|
||||
configuration, branching, tagging and feature divisions found in a kernel.
|
||||
Thus, the Yocto Project kernel repository (or tree) is built.
|
||||
</para>
|
||||
<para>
|
||||
The existence of this tree allows you to access and clone a particular
|
||||
Linux Yocto kernel repository and use it to build images based on their configurations
|
||||
Yocto Project kernel repository and use it to build images based on their configurations
|
||||
and features.
|
||||
</para>
|
||||
<para>
|
||||
You can find the files used to describe all the valid features and BSPs
|
||||
in the Yocto Project kernel in any clone of the Linux Yocto kernel source repository Git tree.
|
||||
in the Yocto Project kernel in any clone of the Yocto Project kernel source repository
|
||||
Git tree.
|
||||
For example, the following command clones the Yocto Project baseline kernel that
|
||||
branched off of <filename>linux.org</filename> version 3.4:
|
||||
<literallayout class='monospaced'>
|
||||
$ git clone git://git.yoctoproject.org/linux-yocto-3.4
|
||||
</literallayout>
|
||||
For another example of how to set up a local Git repository of the Linux Yocto
|
||||
For another example of how to set up a local Git repository of the Yocto Project
|
||||
kernel files, see the
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink>" bulleted item in The Yocto Project Development Manual.
|
||||
"<ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink>" bulleted
|
||||
item in The Yocto Project Development Manual.
|
||||
</para>
|
||||
<para>
|
||||
Once you have cloned the kernel Git repository on your local machine, you can
|
||||
|
@ -85,7 +87,7 @@
|
|||
</para>
|
||||
<para>
|
||||
The following steps describe what happens when the Yocto Project Team constructs
|
||||
the Yocto Linux kernel source Git repository (or tree) found at
|
||||
the Yocto Project kernel source Git repository (or tree) found at
|
||||
<ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink> given the
|
||||
introduction of a new top-level kernel feature or BSP.
|
||||
These are the actions that effectively create the tree
|
||||
|
@ -130,7 +132,7 @@
|
|||
</para>
|
||||
<para>
|
||||
The kernel tree is now ready for developer consumption to be locally cloned,
|
||||
configured, and built into a Linux Yocto kernel specific to some target hardware.
|
||||
configured, and built into a Yocto Project kernel specific to some target hardware.
|
||||
<note><para>The generated <filename>meta-*</filename> directories add to the kernel
|
||||
as shipped with the Yocto Project release.
|
||||
Any add-ons and configuration data are applied to the end of an existing branch.
|
||||
|
@ -149,7 +151,7 @@
|
|||
<section id='build-strategy'>
|
||||
<title>Build Strategy</title>
|
||||
<para>
|
||||
Once a local Git repository of the Linux Yocto kernel exists on a development system,
|
||||
Once a local Git repository of the Yocto Project kernel exists on a development system,
|
||||
you can consider the compilation phase of kernel development - building a kernel image.
|
||||
Some prerequisites exist that are validated by the build process before compilation
|
||||
starts:
|
||||
|
@ -166,7 +168,7 @@
|
|||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
The Yocto Project makes sure these conditions exist before attempting compilation.
|
||||
The OpenEmbedded build system makes sure these conditions exist before attempting compilation.
|
||||
Other means, however, do exist, such as as bootstrapping a BSP, see
|
||||
the "<link linkend='workflow-examples'>Workflow Examples</link>".
|
||||
</para>
|
||||
|
@ -308,7 +310,7 @@
|
|||
<title>Show a Particular Feature or Branch Change</title>
|
||||
|
||||
<para>
|
||||
Developers use tags in the Yocto Project tree to divide changes for significant
|
||||
Developers use tags in the Yocto Project kernel tree to divide changes for significant
|
||||
features or branches.
|
||||
Once you know a particular tag, you can use Git commands
|
||||
to show changes associated with the tag and find the branches that contain
|
||||
|
@ -523,7 +525,7 @@
|
|||
"permanent" and you should not modify them.
|
||||
If the commits need to be changed, you can incrementally do so with new commits.
|
||||
These practices follow standard Git workflow and the <filename>kernel.org</filename> best
|
||||
practices, which Yocto Project recommends.
|
||||
practices, which is recommended.
|
||||
<note>
|
||||
It is recommended to tag or branch before adding changes to a Yocto Project
|
||||
BSP or before creating a new one.
|
||||
|
@ -691,7 +693,7 @@
|
|||
However, if the patches are manually applied to a secondary tree and then
|
||||
that tree is checked into the SCM, you can lose change information such as
|
||||
commit logs.
|
||||
The Yocto Project does not recommend this process.
|
||||
This process is not recommended.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
@ -708,14 +710,14 @@
|
|||
<para>
|
||||
This section describes kernel development in an SCM other than Git,
|
||||
which is not the same as exporting changes to another SCM described earlier.
|
||||
For this scenario, you use the Yocto Project build system to
|
||||
For this scenario, you use the OpenEmbedded build system to
|
||||
develop the kernel in a different SCM.
|
||||
The following must be true for you to accomplish this:
|
||||
<itemizedlist>
|
||||
<listitem><para>The delivered Yocto Project kernel must be exported into the second
|
||||
SCM.</para></listitem>
|
||||
<listitem><para>Development must be exported from that secondary SCM into a
|
||||
format that can be used by the Yocto Project build system.</para></listitem>
|
||||
format that can be used by the OpenEmbedded build system.</para></listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
|
||||
|
@ -791,9 +793,10 @@
|
|||
<para>
|
||||
The basic steps you need to follow are:
|
||||
<orderedlist>
|
||||
<listitem><para><emphasis>Make sure you have the Yocto Project source tree available:</emphasis>
|
||||
You should either create a Yocto Project Git repository (recommended), or
|
||||
you should get the Yocto Project release tarball and extract it.</para></listitem>
|
||||
<listitem><para><emphasis>Make sure you have set up a local source directory:</emphasis>
|
||||
You must create a local <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source
|
||||
directory</ulink> by either creating a Git repository (recommended) or
|
||||
extracting a Yocto Project release tarball.</para></listitem>
|
||||
<listitem><para><emphasis>Choose an existing BSP available with the Yocto Project:</emphasis>
|
||||
Try to map your board features as closely to the features of a BSP that is
|
||||
already supported and exists in the Yocto Project.
|
||||
|
@ -803,12 +806,12 @@
|
|||
on the Yocto Project's Download page at
|
||||
<ulink url='&YOCTO_HOME_URL;/download'></ulink>.</para></listitem>
|
||||
<listitem><para><emphasis>Be sure you have the Base BSP:</emphasis>
|
||||
You need to either have the Yocto Project Git repository set up or download
|
||||
the tarball of the base BSP.
|
||||
You need to either have a local Git repository of the base BSP set up or
|
||||
have downloaded and extracted the files from a release BSP tarball.
|
||||
Either method gives you access to the BSP source files.</para></listitem>
|
||||
<listitem><para><emphasis>Make a copy of the existing BSP, thus isolating your new
|
||||
BSP work:</emphasis>
|
||||
Copying the existing BSP structure gives you a new area in which to work.</para></listitem>
|
||||
Copying the existing BSP file structure gives you a new area in which to work.</para></listitem>
|
||||
<listitem><para><emphasis>Make configuration and recipe changes to your new BSP:</emphasis>
|
||||
Configuration changes involve the files in the BSP's <filename>conf</filename>
|
||||
directory.
|
||||
|
@ -824,7 +827,7 @@
|
|||
changes to the <filename>local.conf</filename> and <filename>bblayers.conf</filename>
|
||||
files.</para></listitem>
|
||||
<listitem><para><emphasis>Build the image:</emphasis>
|
||||
The Yocto Project uses the BitBake tool to create the image.
|
||||
The OpenEmbedded build system uses BitBake to create the image.
|
||||
You need to decide on the type of image you are going to build (e.g. minimal, base,
|
||||
core, sato, and so forth) and then start the build using the <filename>bitbake</filename>
|
||||
command.</para></listitem>
|
||||
|
|
Loading…
Reference in New Issue