mirror of
https://git.yoctoproject.org/poky
synced 2026-04-21 03:32:12 +02:00
dev-manual, kernel-dev: Moved kernel branch concepts to kernel-dev
Fixes [YOCTO #11630] The information in the dev-manual kernel overview area really neeeds to be in the Appendix on kernel structure in the kernel-dev manual. I moved that informtaion to the appendix. Removal of one redundant image was necessary from the dev-manual. The figure was literally repeated in the kernel manual already under a different file name. (From yocto-docs rev: 00ca68e760e41448c225fb1ca4a77f5201434b93) Signed-off-by: Scott Rifenbark <srifenbark@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
committed by
Richard Purdie
Richard Purdie
parent
bdeb6db2fb
commit
64f0f60b3f
@@ -131,7 +131,7 @@ TARFILES = dev-style.css dev-manual.html \
|
||||
TARFILES = dev-style.css dev-manual.html \
|
||||
figures/dev-title.png \
|
||||
figures/kernel-dev-flow.png \
|
||||
figures/kernel-overview-1.png figures/kernel-overview-2-generic.png \
|
||||
figures/kernel-overview-2-generic.png \
|
||||
figures/recipe-workflow.png \
|
||||
figures/devtool-add-flow.png figures/devtool-modify-flow.png \
|
||||
figures/devtool-upgrade-flow.png \
|
||||
@@ -205,7 +205,7 @@ TARFILES = mega-manual.html mega-style.css figures/yocto-environment.png \
|
||||
figures/dev-title.png \
|
||||
figures/git-workflow.png figures/index-downloads.png \
|
||||
figures/kernel-dev-flow.png \
|
||||
figures/kernel-overview-1.png figures/kernel-overview-2-generic.png \
|
||||
figures/kernel-overview-2-generic.png \
|
||||
figures/source-repos.png figures/yp-download.png \
|
||||
figures/profile-title.png figures/kernelshark-all.png \
|
||||
figures/kernelshark-choose-events.png \
|
||||
|
||||
@@ -86,67 +86,26 @@
|
||||
<title>Kernel Overview</title>
|
||||
|
||||
<para>
|
||||
The kernels are maintained using the Git revision control system
|
||||
that structures them using the familiar "tree", "branch", and "leaf" scheme.
|
||||
Branches represent diversions from general code to more specific code, while leaves
|
||||
represent the end-points for a complete and unique kernel whose source files,
|
||||
when gathered from the root of the tree to the leaf, accumulate to create the files
|
||||
necessary for a specific piece of hardware and its features.
|
||||
The following figure displays this concept:
|
||||
<para>
|
||||
<imagedata fileref="figures/kernel-overview-1.png"
|
||||
width="6in" depth="6in" align="center" scale="100" />
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Within the figure, the "Kernel.org Branch Point" represents the point in the tree
|
||||
where a supported base kernel is modified from the Linux kernel.
|
||||
For example, this could be the branch point for the <filename>linux-yocto-3.19</filename>
|
||||
kernel.
|
||||
Thus, everything further to the right in the structure is based on the
|
||||
<filename>linux-yocto-3.19</filename> kernel.
|
||||
Branch points to the right in the figure represent where the
|
||||
<filename>linux-yocto-3.19</filename> kernel is modified for specific hardware
|
||||
or types of kernels, such as real-time kernels.
|
||||
Each leaf thus represents the end-point for a kernel designed to run on a specific
|
||||
targeted device.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The overall result is a Git-maintained repository from which all the supported
|
||||
kernel types can be derived for all the supported devices.
|
||||
A big advantage to this scheme is the sharing of common features by keeping them in
|
||||
"larger" branches within the tree.
|
||||
This practice eliminates redundant storage of similar features shared among kernels.
|
||||
</para>
|
||||
|
||||
<note>
|
||||
Keep in mind the figure does not take into account all the supported Yocto
|
||||
Project kernel types, but rather shows a single generic kernel just for conceptual purposes.
|
||||
Also keep in mind that this structure represents the Yocto Project source repositories
|
||||
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>
|
||||
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 kernels.
|
||||
As a developer, you are just interested in the source files for the kernel on
|
||||
which you are working.
|
||||
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 a couple of different
|
||||
ways.
|
||||
If you are working in the kernel all the time, you probably would want
|
||||
to set up your own local Git repository of the kernel tree.
|
||||
If you just need to make some patches to the kernel, you can access
|
||||
temporary kernel source files that were extracted and used
|
||||
during a build.
|
||||
Kernel source code is available on your host system a couple
|
||||
of different ways.
|
||||
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.
|
||||
If you just need to make some patches to the kernel, you can
|
||||
access temporary kernel source files that were extracted and
|
||||
used during a build.
|
||||
We will just talk about working with the temporary source code.
|
||||
For more information on how to get kernel source code onto your
|
||||
host system, see the
|
||||
@@ -164,6 +123,8 @@
|
||||
Thus, in a sense, the process constructs a local source tree specific to your
|
||||
kernel to generate the new kernel image - a source generator if you will.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The following figure shows the temporary file structure
|
||||
created on your host system when the build occurs.
|
||||
This
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 35 KiB |
@@ -175,74 +175,105 @@
|
||||
|
||||
<section id='kernel-architecture'>
|
||||
<title>Kernel Architecture</title>
|
||||
|
||||
<para>
|
||||
This section describes the architecture of the kernels available through the
|
||||
Yocto Project and provides information
|
||||
This section describes the architecture of the Yocto Linux kernels
|
||||
available through the Yocto Project and provides information
|
||||
on the mechanisms used to achieve that architecture.
|
||||
</para>
|
||||
|
||||
<section id='architecture-overview'>
|
||||
<title>Overview</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 used achieve that goal in a manner similar to the
|
||||
upstream <filename>kernel.org</filename>.
|
||||
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 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 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
|
||||
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.
|
||||
For information on Git as applied to the Yocto Project, see the
|
||||
"<ulink url='&YOCTO_DOCS_REF_URL;#git'>Git</ulink>" section in the
|
||||
Yocto Project Development Manual.
|
||||
"<ulink url='&YOCTO_DOCS_REF_URL;#git'>Git</ulink>" section
|
||||
in the Yocto Project Development Manual.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The result is that 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 kernel.
|
||||
</para>
|
||||
<para>
|
||||
The following illustration shows the conceptual Yocto Project kernel.
|
||||
The result is that 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>
|
||||
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 release) from
|
||||
which the Yocto Project kernel is created.
|
||||
From this point "up" in the tree, features and differences are organized and tagged.
|
||||
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 up the tree.
|
||||
Placing these common features in the
|
||||
tree this way means features do not have to be duplicated along individual branches of the
|
||||
structure.
|
||||
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 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 a real-time kernel.
|
||||
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 kernel branch has common features for all
|
||||
real-time kernels and contains
|
||||
more branches for individual BSP-specific real-time kernels.
|
||||
In this example structure, the real-time 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.
|
||||
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 kernel needed for any given set
|
||||
of requirements.
|
||||
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>
|
||||
</section>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user