[gnome-continuous-yocto/gnomeostree-3.28-rocko: 6706/8267] dev-manual, kernel-dev: Moved kernel branch concepts to kernel-dev
- From: Emmanuele Bassi <ebassi src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [gnome-continuous-yocto/gnomeostree-3.28-rocko: 6706/8267] dev-manual, kernel-dev: Moved kernel branch concepts to kernel-dev
- Date: Sun, 17 Dec 2017 05:13:17 +0000 (UTC)
commit 64f0f60b3fba36ff87fe78ec1e27e6398d206c51
Author: Scott Rifenbark <srifenbark gmail com>
Date: Thu Jun 29 13:06:27 2017 -0700
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>
documentation/Makefile | 4 +-
documentation/dev-manual/dev-manual-model.xml | 75 +++----------
.../dev-manual/figures/kernel-overview-1.png | Bin 35839 -> 0 bytes
.../kernel-dev/kernel-dev-concepts-appx.xml | 113 +++++++++++++-------
4 files changed, 92 insertions(+), 100 deletions(-)
---
diff --git a/documentation/Makefile b/documentation/Makefile
index 3c02a3c..a761c19 100644
--- a/documentation/Makefile
+++ b/documentation/Makefile
@@ -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 \
diff --git a/documentation/dev-manual/dev-manual-model.xml b/documentation/dev-manual/dev-manual-model.xml
index bd6a85b..05ff369 100644
--- a/documentation/dev-manual/dev-manual-model.xml
+++ b/documentation/dev-manual/dev-manual-model.xml
@@ -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
diff --git a/documentation/kernel-dev/kernel-dev-concepts-appx.xml
b/documentation/kernel-dev/kernel-dev-concepts-appx.xml
index 3606301..ee40938 100644
--- a/documentation/kernel-dev/kernel-dev-concepts-appx.xml
+++ b/documentation/kernel-dev/kernel-dev-concepts-appx.xml
@@ -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.
- </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.
+ "<ulink url='&YOCTO_DOCS_REF_URL;#git'>Git</ulink>" section
+ in the Yocto Project Development Manual.
</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>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
