summaryrefslogtreecommitdiffstats
path: root/documentation/dev-manual/dev-manual-model.xml
diff options
context:
space:
mode:
Diffstat (limited to 'documentation/dev-manual/dev-manual-model.xml')
-rw-r--r--documentation/dev-manual/dev-manual-model.xml75
1 files changed, 18 insertions, 57 deletions
diff --git a/documentation/dev-manual/dev-manual-model.xml b/documentation/dev-manual/dev-manual-model.xml
index bd6a85b987..05ff369f5d 100644
--- a/documentation/dev-manual/dev-manual-model.xml
+++ b/documentation/dev-manual/dev-manual-model.xml
@@ -86,67 +86,26 @@
86 <title>Kernel Overview</title> 86 <title>Kernel Overview</title>
87 87
88 <para> 88 <para>
89 The kernels are maintained using the Git revision control system 89 Upstream storage of all the available kernel source code is
90 that structures them using the familiar "tree", "branch", and "leaf" scheme. 90 one thing, while representing and using the code on your host
91 Branches represent diversions from general code to more specific code, while leaves 91 development system is another.
92 represent the end-points for a complete and unique kernel whose source files, 92 Conceptually, you can think of the kernel source repositories
93 when gathered from the root of the tree to the leaf, accumulate to create the files 93 as all the source files necessary for all the supported
94 necessary for a specific piece of hardware and its features. 94 Yocto Linux kernels.
95 The following figure displays this concept: 95 As a developer, you are just interested in the source files
96 <para> 96 for the kernel on which you are working.
97 <imagedata fileref="figures/kernel-overview-1.png"
98 width="6in" depth="6in" align="center" scale="100" />
99 </para>
100
101 <para>
102 Within the figure, the "Kernel.org Branch Point" represents the point in the tree
103 where a supported base kernel is modified from the Linux kernel.
104 For example, this could be the branch point for the <filename>linux-yocto-3.19</filename>
105 kernel.
106 Thus, everything further to the right in the structure is based on the
107 <filename>linux-yocto-3.19</filename> kernel.
108 Branch points to the right in the figure represent where the
109 <filename>linux-yocto-3.19</filename> kernel is modified for specific hardware
110 or types of kernels, such as real-time kernels.
111 Each leaf thus represents the end-point for a kernel designed to run on a specific
112 targeted device.
113 </para>
114
115 <para>
116 The overall result is a Git-maintained repository from which all the supported
117 kernel types can be derived for all the supported devices.
118 A big advantage to this scheme is the sharing of common features by keeping them in
119 "larger" branches within the tree.
120 This practice eliminates redundant storage of similar features shared among kernels.
121 </para>
122
123 <note>
124 Keep in mind the figure does not take into account all the supported Yocto
125 Project kernel types, but rather shows a single generic kernel just for conceptual purposes.
126 Also keep in mind that this structure represents the Yocto Project source repositories
127 that are either pulled from during the build or established on the host development system
128 prior to the build by either cloning a particular kernel's Git repository or by
129 downloading and unpacking a tarball.
130 </note>
131
132 <para>
133 Upstream storage of all the available kernel source code is one thing, while
134 representing and using the code on your host development system is another.
135 Conceptually, you can think of the kernel source repositories as all the
136 source files necessary for all the supported kernels.
137 As a developer, you are just interested in the source files for the kernel on
138 which you are working.
139 And, furthermore, you need them available on your host system. 97 And, furthermore, you need them available on your host system.
140 </para> 98 </para>
141 99
142 <para> 100 <para>
143 Kernel source code is available on your host system a couple of different 101 Kernel source code is available on your host system a couple
144 ways. 102 of different ways.
145 If you are working in the kernel all the time, you probably would want 103 If you are working in the kernel all the time, you probably
146 to set up your own local Git repository of the kernel tree. 104 would want to set up your own local Git repository of the
147 If you just need to make some patches to the kernel, you can access 105 Yocto Linux kernel tree.
148 temporary kernel source files that were extracted and used 106 If you just need to make some patches to the kernel, you can
149 during a build. 107 access temporary kernel source files that were extracted and
108 used during a build.
150 We will just talk about working with the temporary source code. 109 We will just talk about working with the temporary source code.
151 For more information on how to get kernel source code onto your 110 For more information on how to get kernel source code onto your
152 host system, see the 111 host system, see the
@@ -164,6 +123,8 @@
164 Thus, in a sense, the process constructs a local source tree specific to your 123 Thus, in a sense, the process constructs a local source tree specific to your
165 kernel to generate the new kernel image - a source generator if you will. 124 kernel to generate the new kernel image - a source generator if you will.
166 </para> 125 </para>
126
127 <para>
167 The following figure shows the temporary file structure 128 The following figure shows the temporary file structure
168 created on your host system when the build occurs. 129 created on your host system when the build occurs.
169 This 130 This