diff options
Diffstat (limited to 'documentation/kernel-manual')
-rw-r--r-- | documentation/kernel-manual/kernel-concepts.xml | 224 |
1 files changed, 112 insertions, 112 deletions
diff --git a/documentation/kernel-manual/kernel-concepts.xml b/documentation/kernel-manual/kernel-concepts.xml index 9bbd964e88..ec9ac950b7 100644 --- a/documentation/kernel-manual/kernel-concepts.xml +++ b/documentation/kernel-manual/kernel-concepts.xml | |||
@@ -22,38 +22,38 @@ | |||
22 | <section id='kernel-goals'> | 22 | <section id='kernel-goals'> |
23 | <title>Kernel Goals</title> | 23 | <title>Kernel Goals</title> |
24 | <para> | 24 | <para> |
25 | The complexity of embedded kernel design has increased dramatically. | 25 | The complexity of embedded kernel design has increased dramatically. |
26 | Whether it is managing multiple implementations of a particular feature or tuning and | 26 | Whether it is managing multiple implementations of a particular feature or tuning and |
27 | optimizing board specific features, both flexibility and maintainability are key concerns. | 27 | optimizing board specific features, both flexibility and maintainability are key concerns. |
28 | The Linux kernels available through the Yocto Project are presented with the embedded | 28 | The Linux kernels available through the Yocto Project are presented with the embedded |
29 | developer's needs in mind and have evolved to assist in these key concerns. | 29 | developer's needs in mind and have evolved to assist in these key concerns. |
30 | For example, prior methods such as applying hundreds of patches to an extracted | 30 | For example, prior methods such as applying hundreds of patches to an extracted |
31 | tarball have been replaced with proven techniques that allow easy inspection, | 31 | tarball have been replaced with proven techniques that allow easy inspection, |
32 | bisection and analysis of changes. | 32 | bisection and analysis of changes. |
33 | Application of these techniques also creates a platform for performing integration and | 33 | Application of these techniques also creates a platform for performing integration and |
34 | collaboration with the thousands of upstream development projects. | 34 | collaboration with the thousands of upstream development projects. |
35 | </para> | 35 | </para> |
36 | <para> | 36 | <para> |
37 | With all these considerations in mind, the Yocto Project's kernel and development team | 37 | With all these considerations in mind, the Yocto Project's kernel and development team |
38 | strives to attain these goals: | 38 | strives to attain these goals: |
39 | <itemizedlist> | 39 | <itemizedlist> |
40 | <listitem><para>Allow the end user to leverage community best practices to seamlessly | 40 | <listitem><para>Allow the end user to leverage community best practices to seamlessly |
41 | manage the development, build and debug cycles.</para></listitem> | 41 | manage the development, build and debug cycles.</para></listitem> |
42 | <listitem><para>Create a platform for performing integration and collaboration with the | 42 | <listitem><para>Create a platform for performing integration and collaboration with the |
43 | thousands of upstream development projects that exist.</para></listitem> | 43 | thousands of upstream development projects that exist.</para></listitem> |
44 | <listitem><para>Provide mechanisms that support many different work flows, front-ends and | 44 | <listitem><para>Provide mechanisms that support many different work flows, front-ends and |
45 | management techniques.</para></listitem> | 45 | management techniques.</para></listitem> |
46 | <listitem><para>Deliver the most up-to-date kernel possible while still ensuring that | 46 | <listitem><para>Deliver the most up-to-date kernel possible while still ensuring that |
47 | the baseline kernel is the most stable official release.</para></listitem> | 47 | the baseline kernel is the most stable official release.</para></listitem> |
48 | <listitem><para>Include major technological features as part of the Yocto Project's | 48 | <listitem><para>Include major technological features as part of the Yocto Project's |
49 | upward revision strategy.</para></listitem> | 49 | upward revision strategy.</para></listitem> |
50 | <listitem><para>Present a kernel Git repository that, similar to the upstream | 50 | <listitem><para>Present a kernel Git repository that, similar to the upstream |
51 | <filename>kernel.org</filename> tree, | 51 | <filename>kernel.org</filename> tree, |
52 | has a clear and continuous history.</para></listitem> | 52 | has a clear and continuous history.</para></listitem> |
53 | <listitem><para>Deliver a key set of supported kernel types, where each type is tailored | 53 | <listitem><para>Deliver a key set of supported kernel types, where each type is tailored |
54 | to meet a specific use (e.g. networking, consumer, devices, and so forth).</para></listitem> | 54 | to meet a specific use (e.g. networking, consumer, devices, and so forth).</para></listitem> |
55 | <listitem><para>Employ a Git branching strategy that, from a developer's point of view, | 55 | <listitem><para>Employ a Git branching strategy that, from a developer's point of view, |
56 | results in a linear path from the baseline <filename>kernel.org</filename>, | 56 | results in a linear path from the baseline <filename>kernel.org</filename>, |
57 | through a select group of features and | 57 | through a select group of features and |
58 | ends with their BSP-specific commits.</para></listitem> | 58 | ends with their BSP-specific commits.</para></listitem> |
59 | </itemizedlist> | 59 | </itemizedlist> |
@@ -63,78 +63,78 @@ | |||
63 | <section id='kernel-big-picture'> | 63 | <section id='kernel-big-picture'> |
64 | <title>Yocto Project Kernel Development and Maintenance Overview</title> | 64 | <title>Yocto Project Kernel Development and Maintenance Overview</title> |
65 | <para> | 65 | <para> |
66 | Kernels available through the Yocto Project, like other kernels, are based off the Linux | 66 | Kernels available through the Yocto Project, like other kernels, are based off the Linux |
67 | kernel releases from <ulink url='http://www.kernel.org'></ulink>. | 67 | kernel releases from <ulink url='http://www.kernel.org'></ulink>. |
68 | At the beginning of a major development cycle, the Yocto Project team | 68 | At the beginning of a major development cycle, the Yocto Project team |
69 | chooses its kernel based on factors such as release timing, the anticipated release | 69 | chooses its kernel based on factors such as release timing, the anticipated release |
70 | timing of final upstream <filename>kernel.org</filename> versions, and Yocto Project | 70 | timing of final upstream <filename>kernel.org</filename> versions, and Yocto Project |
71 | feature requirements. | 71 | feature requirements. |
72 | Typically, the kernel chosen is in the | 72 | Typically, the kernel chosen is in the |
73 | final stages of development by the community. | 73 | final stages of development by the community. |
74 | In other words, the kernel is in the release | 74 | In other words, the kernel is in the release |
75 | candidate or "rc" phase and not yet a final release. | 75 | candidate or "rc" phase and not yet a final release. |
76 | But, by being in the final stages of external development, the team knows that the | 76 | But, by being in the final stages of external development, the team knows that the |
77 | <filename>kernel.org</filename> final release will clearly be within the early stages of | 77 | <filename>kernel.org</filename> final release will clearly be within the early stages of |
78 | the Yocto Project development window. | 78 | the Yocto Project development window. |
79 | </para> | 79 | </para> |
80 | <para> | 80 | <para> |
81 | This balance allows the team to deliver the most up-to-date kernel | 81 | This balance allows the team to deliver the most up-to-date kernel |
82 | as possible, while still ensuring that the team has a stable official release for | 82 | possible, while still ensuring that the team has a stable official release for |
83 | the baseline Linux kernel version. | 83 | the baseline Linux kernel version. |
84 | </para> | 84 | </para> |
85 | <para> | 85 | <para> |
86 | The ultimate source for kernels available through the Yocto Project are released kernels | 86 | The ultimate source for kernels available through the Yocto Project are released kernels |
87 | from <filename>kernel.org</filename>. | 87 | from <filename>kernel.org</filename>. |
88 | In addition to a foundational kernel from <filename>kernel.org</filename>, the | 88 | In addition to a foundational kernel from <filename>kernel.org</filename>, the |
89 | kernels available contain a mix of important new mainline | 89 | kernels available contain a mix of important new mainline |
90 | developments, non-mainline developments (when there is no alternative), | 90 | developments, non-mainline developments (when there is no alternative), |
91 | Board Support Package (BSP) developments, | 91 | Board Support Package (BSP) developments, |
92 | and custom features. | 92 | and custom features. |
93 | These additions result in a commercially released Yocto Project Linux kernel that caters | 93 | These additions result in a commercially released Yocto Project Linux kernel that caters |
94 | to specific embedded designer needs for targeted hardware. | 94 | to specific embedded designer needs for targeted hardware. |
95 | </para> | 95 | </para> |
96 | <para> | 96 | <para> |
97 | Once a kernel is officially released, the Yocto Project team goes into | 97 | Once a kernel is officially released, the Yocto Project team goes into |
98 | their next development cycle, or upward revision (uprev) cycle, while still | 98 | their next development cycle, or upward revision (uprev) cycle, while still |
99 | continuing maintenance on the released kernel. | 99 | continuing maintenance on the released kernel. |
100 | It is important to note that the most sustainable and stable way | 100 | It is important to note that the most sustainable and stable way |
101 | to include feature development upstream is through a kernel uprev process. | 101 | to include feature development upstream is through a kernel uprev process. |
102 | Back-porting hundreds of individual fixes and minor features from various | 102 | Back-porting hundreds of individual fixes and minor features from various |
103 | kernel versions is not sustainable and can easily compromise quality. | 103 | kernel versions is not sustainable and can easily compromise quality. |
104 | </para> | 104 | </para> |
105 | <para> | 105 | <para> |
106 | During the uprev cycle, the Yocto Project team uses an ongoing analysis of | 106 | During the uprev cycle, the Yocto Project team uses an ongoing analysis of |
107 | kernel development, BSP support, and release timing to select the best | 107 | kernel development, BSP support, and release timing to select the best |
108 | possible <filename>kernel.org</filename> version. | 108 | possible <filename>kernel.org</filename> version. |
109 | The team continually monitors community kernel | 109 | The team continually monitors community kernel |
110 | development to look for significant features of interest. | 110 | development to look for significant features of interest. |
111 | The team does consider back-porting large features if they have a significant advantage. | 111 | The team does consider back-porting large features if they have a significant advantage. |
112 | User or community demand can also trigger a back-port or creation of new | 112 | User or community demand can also trigger a back-port or creation of new |
113 | functionality in the Yocto Project baseline kernel during the uprev cycle. | 113 | functionality in the Yocto Project baseline kernel during the uprev cycle. |
114 | </para> | 114 | </para> |
115 | <para> | 115 | <para> |
116 | Generally speaking, every new kernel both adds features and introduces new bugs. | 116 | Generally speaking, every new kernel both adds features and introduces new bugs. |
117 | These consequences are the basic properties of upstream kernel development and are | 117 | These consequences are the basic properties of upstream kernel development and are |
118 | managed by the Yocto Project team's kernel strategy. | 118 | managed by the Yocto Project team's kernel strategy. |
119 | It is the Yocto Project team's policy to not back-port minor features to the released kernel. | 119 | It is the Yocto Project team's policy to not back-port minor features to the released kernel. |
120 | They only consider back-porting significant technological jumps - and, that is done | 120 | They only consider back-porting significant technological jumps - and, that is done |
121 | after a complete gap analysis. | 121 | after a complete gap analysis. |
122 | The reason for this policy is that back-porting any small to medium sized change | 122 | The reason for this policy is that back-porting any small to medium sized change |
123 | from an evolving kernel can easily create mismatches, incompatibilities and very | 123 | from an evolving kernel can easily create mismatches, incompatibilities and very |
124 | subtle errors. | 124 | subtle errors. |
125 | </para> | 125 | </para> |
126 | <para> | 126 | <para> |
127 | These policies result in both a stable and a cutting | 127 | These policies result in both a stable and a cutting |
128 | edge kernel that mixes forward ports of existing features and significant and critical | 128 | edge kernel that mixes forward ports of existing features and significant and critical |
129 | new functionality. | 129 | new functionality. |
130 | Forward porting functionality in the kernels available through the Yocto Project kernel | 130 | Forward porting functionality in the kernels available through the Yocto Project kernel |
131 | can be thought of as a "micro uprev." | 131 | can be thought of as a "micro uprev." |
132 | The many “micro uprevs” produce a kernel version with a mix of | 132 | The many “micro uprevs” produce a kernel version with a mix of |
133 | important new mainline, non-mainline, BSP developments and feature integrations. | 133 | important new mainline, non-mainline, BSP developments and feature integrations. |
134 | This kernel gives insight into new features and allows focused | 134 | This kernel gives insight into new features and allows focused |
135 | amounts of testing to be done on the kernel, which prevents | 135 | amounts of testing to be done on the kernel, which prevents |
136 | surprises when selecting the next major uprev. | 136 | surprises when selecting the next major uprev. |
137 | The quality of these cutting edge kernels is evolving and the kernels are used in leading edge | 137 | The quality of these cutting edge kernels is evolving and the kernels are used in leading edge |
138 | feature and BSP development. | 138 | feature and BSP development. |
139 | </para> | 139 | </para> |
140 | </section> | 140 | </section> |
@@ -142,7 +142,7 @@ | |||
142 | <section id='kernel-architecture'> | 142 | <section id='kernel-architecture'> |
143 | <title>Kernel Architecture</title> | 143 | <title>Kernel Architecture</title> |
144 | <para> | 144 | <para> |
145 | This section describes the architecture of the kernels available through the | 145 | This section describes the architecture of the kernels available through the |
146 | Yocto Project and provides information | 146 | Yocto Project and provides information |
147 | on the mechanisms used to achieve that architecture. | 147 | on the mechanisms used to achieve that architecture. |
148 | </para> | 148 | </para> |
@@ -150,25 +150,25 @@ | |||
150 | <section id='architecture-overview'> | 150 | <section id='architecture-overview'> |
151 | <title>Overview</title> | 151 | <title>Overview</title> |
152 | <para> | 152 | <para> |
153 | As mentioned earlier, a key goal of the Yocto Project is to present the | 153 | As mentioned earlier, a key goal of the Yocto Project is to present the |
154 | developer with | 154 | developer with |
155 | a kernel that has a clear and continuous history that is visible to the user. | 155 | a kernel that has a clear and continuous history that is visible to the user. |
156 | The architecture and mechanisms used achieve that goal in a manner similar to the | 156 | The architecture and mechanisms used achieve that goal in a manner similar to the |
157 | upstream <filename>kernel.org</filename>. | 157 | upstream <filename>kernel.org</filename>. |
158 | </para> | 158 | </para> |
159 | <para> | 159 | <para> |
160 | You can think of a Yocto Project kernel as consisting of a baseline Linux kernel with | 160 | You can think of a Yocto Project kernel as consisting of a baseline Linux kernel with |
161 | added features logically structured on top of the baseline. | 161 | added features logically structured on top of the baseline. |
162 | The features are tagged and organized by way of a branching strategy implemented by the | 162 | The features are tagged and organized by way of a branching strategy implemented by the |
163 | source code manager (SCM) Git. | 163 | source code manager (SCM) Git. |
164 | For information on Git as applied to the Yocto Project, see the | 164 | For information on Git as applied to the Yocto Project, see the |
165 | "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>" section in the | 165 | "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>" section in the |
166 | Yocto Project Development Manual. | 166 | Yocto Project Development Manual. |
167 | </para> | 167 | </para> |
168 | <para> | 168 | <para> |
169 | The result is that the user has the ability to see the added features and | 169 | The result is that the user has the ability to see the added features and |
170 | the commits that make up those features. | 170 | the commits that make up those features. |
171 | In addition to being able to see added features, the user can also view the history of what | 171 | In addition to being able to see added features, the user can also view the history of what |
172 | made up the baseline kernel. | 172 | made up the baseline kernel. |
173 | </para> | 173 | </para> |
174 | <para> | 174 | <para> |
@@ -178,73 +178,73 @@ | |||
178 | <imagedata fileref="figures/kernel-architecture-overview.png" width="6in" depth="7in" align="center" scale="100" /> | 178 | <imagedata fileref="figures/kernel-architecture-overview.png" width="6in" depth="7in" align="center" scale="100" /> |
179 | </para> | 179 | </para> |
180 | <para> | 180 | <para> |
181 | In the illustration, the "Kernel.org Branch Point" | 181 | In the illustration, the "Kernel.org Branch Point" |
182 | marks the specific spot (or release) from | 182 | marks the specific spot (or release) from |
183 | which the Yocto Project kernel is created. | 183 | which the Yocto Project kernel is created. |
184 | From this point "up" in the tree, features and differences are organized and tagged. | 184 | From this point "up" in the tree, features and differences are organized and tagged. |
185 | </para> | 185 | </para> |
186 | <para> | 186 | <para> |
187 | The "Yocto Project Baseline Kernel" contains functionality that is common to every kernel | 187 | The "Yocto Project Baseline Kernel" contains functionality that is common to every kernel |
188 | type and BSP that is organized further up the tree. | 188 | type and BSP that is organized further up the tree. |
189 | Placing these common features in the | 189 | Placing these common features in the |
190 | tree this way means features don't have to be duplicated along individual branches of the | 190 | tree this way means features don't have to be duplicated along individual branches of the |
191 | structure. | 191 | structure. |
192 | </para> | 192 | </para> |
193 | <para> | 193 | <para> |
194 | From the Yocto Project Baseline Kernel, branch points represent specific functionality | 194 | From the Yocto Project Baseline Kernel, branch points represent specific functionality |
195 | for individual BSPs as well as real-time kernels. | 195 | for individual BSPs as well as real-time kernels. |
196 | The illustration represents this through three BSP-specific branches and a real-time | 196 | The illustration represents this through three BSP-specific branches and a real-time |
197 | kernel branch. | 197 | kernel branch. |
198 | Each branch represents some unique functionality for the BSP or a real-time kernel. | 198 | Each branch represents some unique functionality for the BSP or a real-time kernel. |
199 | </para> | 199 | </para> |
200 | <para> | 200 | <para> |
201 | In this example structure, the real-time kernel branch has common features for all | 201 | In this example structure, the real-time kernel branch has common features for all |
202 | real-time kernels and contains | 202 | real-time kernels and contains |
203 | more branches for individual BSP-specific real-time kernels. | 203 | more branches for individual BSP-specific real-time kernels. |
204 | The illustration shows three branches as an example. | 204 | The illustration shows three branches as an example. |
205 | Each branch points the way to specific, unique features for a respective real-time | 205 | Each branch points the way to specific, unique features for a respective real-time |
206 | kernel as they apply to a given BSP. | 206 | kernel as they apply to a given BSP. |
207 | </para> | 207 | </para> |
208 | <para> | 208 | <para> |
209 | The resulting tree structure presents a clear path of markers (or branches) to the | 209 | The resulting tree structure presents a clear path of markers (or branches) to the |
210 | developer that, for all practical purposes, is the kernel needed for any given set | 210 | developer that, for all practical purposes, is the kernel needed for any given set |
211 | of requirements. | 211 | of requirements. |
212 | </para> | 212 | </para> |
213 | </section> | 213 | </section> |
214 | 214 | ||
215 | <section id='branching-and-workflow'> | 215 | <section id='branching-and-workflow'> |
216 | <title>Branching Strategy and Workflow</title> | 216 | <title>Branching Strategy and Workflow</title> |
217 | <para> | 217 | <para> |
218 | The Yocto Project team creates kernel branches at points where functionality is | 218 | The Yocto Project team creates kernel branches at points where functionality is |
219 | no longer shared and thus, needs to be isolated. | 219 | no longer shared and thus, needs to be isolated. |
220 | For example, board-specific incompatibilities would require different functionality | 220 | For example, board-specific incompatibilities would require different functionality |
221 | and would require a branch to separate the features. | 221 | and would require a branch to separate the features. |
222 | Likewise, for specific kernel features, the same branching strategy is used. | 222 | Likewise, for specific kernel features, the same branching strategy is used. |
223 | </para> | 223 | </para> |
224 | <para> | 224 | <para> |
225 | This branching strategy results in a tree that has features organized to be specific | 225 | This branching strategy results in a tree that has features organized to be specific |
226 | for particular functionality, single kernel types, or a subset of kernel types. | 226 | for particular functionality, single kernel types, or a subset of kernel types. |
227 | This strategy also results in not having to store the same feature twice | 227 | This strategy also results in not having to store the same feature twice |
228 | internally in the tree. | 228 | internally in the tree. |
229 | Rather, the kernel team stores the unique differences required to apply the | 229 | Rather, the kernel team stores the unique differences required to apply the |
230 | feature onto the kernel type in question. | 230 | feature onto the kernel type in question. |
231 | <note> | 231 | <note> |
232 | The Yocto Project team strives to place features in the tree such that they can be | 232 | The Yocto Project team strives to place features in the tree such that they can be |
233 | shared by all boards and kernel types where possible. | 233 | shared by all boards and kernel types where possible. |
234 | However, during development cycles or when large features are merged, | 234 | However, during development cycles or when large features are merged, |
235 | the team cannot always follow this practice. | 235 | the team cannot always follow this practice. |
236 | In those cases, the team uses isolated branches to merge features. | 236 | In those cases, the team uses isolated branches to merge features. |
237 | </note> | 237 | </note> |
238 | </para> | 238 | </para> |
239 | <para> | 239 | <para> |
240 | BSP-specific code additions are handled in a similar manner to kernel-specific additions. | 240 | BSP-specific code additions are handled in a similar manner to kernel-specific additions. |
241 | Some BSPs only make sense given certain kernel types. | 241 | Some BSPs only make sense given certain kernel types. |
242 | So, for these types, the team creates branches off the end of that kernel type for all | 242 | So, for these types, the team creates branches off the end of that kernel type for all |
243 | of the BSPs that are supported on that kernel type. | 243 | of the BSPs that are supported on that kernel type. |
244 | From the perspective of the tools that create the BSP branch, the BSP is really no | 244 | From the perspective of the tools that create the BSP branch, the BSP is really no |
245 | different than a feature. | 245 | different than a feature. |
246 | Consequently, the same branching strategy applies to BSPs as it does to features. | 246 | Consequently, the same branching strategy applies to BSPs as it does to features. |
247 | So again, rather than store the BSP twice, the team only stores the unique | 247 | So again, rather than store the BSP twice, the team only stores the unique |
248 | differences for the BSP across the supported multiple kernels. | 248 | differences for the BSP across the supported multiple kernels. |
249 | </para> | 249 | </para> |
250 | <para> | 250 | <para> |
@@ -252,47 +252,47 @@ | |||
252 | important to realize that from the developer's point of view, there is a linear | 252 | important to realize that from the developer's point of view, there is a linear |
253 | path that travels from the baseline <filename>kernel.org</filename>, through a select | 253 | path that travels from the baseline <filename>kernel.org</filename>, through a select |
254 | group of features and ends with their BSP-specific commits. | 254 | group of features and ends with their BSP-specific commits. |
255 | In other words, the divisions of the kernel are transparent and are not relevant | 255 | In other words, the divisions of the kernel are transparent and are not relevant |
256 | to the developer on a day-to-day basis. | 256 | to the developer on a day-to-day basis. |
257 | From the developer's perspective, this path is the "master" branch. | 257 | From the developer's perspective, this path is the "master" branch. |
258 | The developer does not need to be aware of the existence of any other branches at all. | 258 | The developer does not need to be aware of the existence of any other branches at all. |
259 | Of course, there is value in the existence of these branches | 259 | Of course, there is value in the existence of these branches |
260 | in the tree, should a person decide to explore them. | 260 | in the tree, should a person decide to explore them. |
261 | For example, a comparison between two BSPs at either the commit level or at the line-by-line | 261 | For example, a comparison between two BSPs at either the commit level or at the line-by-line |
262 | code <filename>diff</filename> level is now a trivial operation. | 262 | code <filename>diff</filename> level is now a trivial operation. |
263 | </para> | 263 | </para> |
264 | <para> | 264 | <para> |
265 | Working with the kernel as a structured tree follows recognized community best practices. | 265 | Working with the kernel as a structured tree follows recognized community best practices. |
266 | In particular, the kernel as shipped with the product, should be | 266 | In particular, the kernel as shipped with the product, should be |
267 | considered an "upstream source" and viewed as a series of | 267 | considered an "upstream source" and viewed as a series of |
268 | historical and documented modifications (commits). | 268 | historical and documented modifications (commits). |
269 | These modifications represent the development and stabilization done | 269 | These modifications represent the development and stabilization done |
270 | by the Yocto Project kernel development team. | 270 | by the Yocto Project kernel development team. |
271 | </para> | 271 | </para> |
272 | <para> | 272 | <para> |
273 | Because commits only change at significant release points in the product life cycle, | 273 | Because commits only change at significant release points in the product life cycle, |
274 | developers can work on a branch created | 274 | developers can work on a branch created |
275 | from the last relevant commit in the shipped Yocto Project kernel. | 275 | from the last relevant commit in the shipped Yocto Project kernel. |
276 | As mentioned previously, the structure is transparent to the developer | 276 | As mentioned previously, the structure is transparent to the developer |
277 | because the kernel tree is left in this state after cloning and building the kernel. | 277 | because the kernel tree is left in this state after cloning and building the kernel. |
278 | </para> | 278 | </para> |
279 | </section> | 279 | </section> |
280 | 280 | ||
281 | <section id='source-code-manager-git'> | 281 | <section id='source-code-manager-git'> |
282 | <title>Source Code Manager - Git</title> | 282 | <title>Source Code Manager - Git</title> |
283 | <para> | 283 | <para> |
284 | The Source Code Manager (SCM) is Git. | 284 | The Source Code Manager (SCM) is Git. |
285 | This SCM is the obvious mechanism for meeting the previously mentioned goals. | 285 | This SCM is the obvious mechanism for meeting the previously mentioned goals. |
286 | Not only is it the SCM for <filename>kernel.org</filename> but, | 286 | Not only is it the SCM for <filename>kernel.org</filename> but, |
287 | Git continues to grow in popularity and supports many different work flows, | 287 | Git continues to grow in popularity and supports many different work flows, |
288 | front-ends and management techniques. | 288 | front-ends and management techniques. |
289 | </para> | 289 | </para> |
290 | <para> | 290 | <para> |
291 | You can find documentation on Git at <ulink url='http://git-scm.com/documentation'></ulink>. | 291 | You can find documentation on Git at <ulink url='http://git-scm.com/documentation'></ulink>. |
292 | You can also get an introduction to Git as it applies to the Yocto Project in the | 292 | You can also get an introduction to Git as it applies to the Yocto Project in the |
293 | "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>" | 293 | "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>" |
294 | section in the Yocto Project Development Manual. | 294 | section in the Yocto Project Development Manual. |
295 | These referenced sections overview Git and describe a minimal set of | 295 | These referenced sections overview Git and describe a minimal set of |
296 | commands that allows you to be functional using Git. | 296 | commands that allows you to be functional using Git. |
297 | <note> | 297 | <note> |
298 | You can use as much, or as little, of what Git has to offer to accomplish what | 298 | You can use as much, or as little, of what Git has to offer to accomplish what |
@@ -307,11 +307,11 @@ | |||
307 | <title>Kernel Configuration</title> | 307 | <title>Kernel Configuration</title> |
308 | <para> | 308 | <para> |
309 | Kernel configuration, along with kernel features, defines how a kernel | 309 | Kernel configuration, along with kernel features, defines how a kernel |
310 | image is built for the Yocto Project. | 310 | image is built for the Yocto Project. |
311 | Through configuration settings, you can customize a Yocto Project kernel to be | 311 | Through configuration settings, you can customize a Yocto Project kernel to be |
312 | specific to particular hardware. | 312 | specific to particular hardware. |
313 | For example, you can specify sound support or networking support. | 313 | For example, you can specify sound support or networking support. |
314 | This section describes basic concepts behind Kernel configuration within the | 314 | This section describes basic concepts behind Kernel configuration within the |
315 | Yocto Project and references you to other areas for specific configuration | 315 | Yocto Project and references you to other areas for specific configuration |
316 | applications. | 316 | applications. |
317 | </para> | 317 | </para> |
@@ -319,52 +319,52 @@ | |||
319 | <para> | 319 | <para> |
320 | Conceptually, configuration of a Yocto Project kernel occurs similarly to that needed for any | 320 | Conceptually, configuration of a Yocto Project kernel occurs similarly to that needed for any |
321 | Linux kernel. | 321 | Linux kernel. |
322 | The build process for a Yocto Project kernel uses a <filename>.config</filename> file, which | 322 | The build process for a Yocto Project kernel uses a <filename>.config</filename> file, which |
323 | is created through the Linux Kernel Configuration (LKC) tool. | 323 | is created through the Linux Kernel Configuration (LKC) tool. |
324 | You can directly set various configurations in the | 324 | You can directly set various configurations in the |
325 | <filename>.config</filename> file by using the <filename>menuconfig</filename> | 325 | <filename>.config</filename> file by using the <filename>menuconfig</filename> |
326 | tool as built by BitBake. | 326 | tool as built by BitBake. |
327 | You can also define configurations in the file by using configuration fragments. | 327 | You can also define configurations in the file by using configuration fragments. |
328 | <note> | 328 | <note> |
329 | It is not recommended that you edit the <filename>.config</filename> file directly. | 329 | It is not recommended that you edit the <filename>.config</filename> file directly. |
330 | </note> | 330 | </note> |
331 | Here are some brief descriptions of the ways you can affect the | 331 | Here are some brief descriptions of the ways you can affect the |
332 | <filename>.config</filename> file: | 332 | <filename>.config</filename> file: |
333 | <itemizedlist> | 333 | <itemizedlist> |
334 | <listitem><para><emphasis>The <filename>menuconfig</filename> Tool:</emphasis> | 334 | <listitem><para><emphasis>The <filename>menuconfig</filename> Tool:</emphasis> |
335 | One of many front-ends that allows you to define kernel configurations. | 335 | One of many front-ends that allows you to define kernel configurations. |
336 | Some others are <filename>make config</filename>, | 336 | Some others are <filename>make config</filename>, |
337 | <filename>make nconfig</filename>, and <filename>make gconfig</filename>. | 337 | <filename>make nconfig</filename>, and <filename>make gconfig</filename>. |
338 | In the Yocto Project environment, you must use BitBake to build the | 338 | In the Yocto Project environment, you must use BitBake to build the |
339 | <filename>menuconfig</filename> tool before you can use it to define | 339 | <filename>menuconfig</filename> tool before you can use it to define |
340 | configurations: | 340 | configurations: |
341 | <literallayout class='monospaced'> | 341 | <literallayout class='monospaced'> |
342 | $ bitbake linux-yocto -c menuconfig | 342 | $ bitbake linux-yocto -c menuconfig |
343 | </literallayout> | 343 | </literallayout> |
344 | After the tool is built, you can interact with it normally. | 344 | After the tool is built, you can interact with it normally. |
345 | You can see how <filename>menuconfig</filename> is used to change a simple | 345 | You can see how <filename>menuconfig</filename> is used to change a simple |
346 | kernel configuration in the | 346 | kernel configuration in the |
347 | "<ulink url='&YOCTO_DOCS_DEV_URL;#configuring-the-kernel'>Configuring the Kernel</ulink>" | 347 | "<ulink url='&YOCTO_DOCS_DEV_URL;#configuring-the-kernel'>Configuring the Kernel</ulink>" |
348 | section of the Yocto Project Development Manual. | 348 | section of the Yocto Project Development Manual. |
349 | For general information on <filename>menuconfig</filename>, see | 349 | For general information on <filename>menuconfig</filename>, see |
350 | <ulink url='http://en.wikipedia.org/wiki/Menuconfig'></ulink>. | 350 | <ulink url='http://en.wikipedia.org/wiki/Menuconfig'></ulink>. |
351 | </para></listitem> | 351 | </para></listitem> |
352 | <listitem><para><emphasis>Configuration Fragments:</emphasis> A file with a | 352 | <listitem><para><emphasis>Configuration Fragments:</emphasis> A file with a |
353 | list of kernel options just as they would appear syntactically in the | 353 | list of kernel options just as they would appear syntactically in the |
354 | <filename>.config</filename> file. | 354 | <filename>.config</filename> file. |
355 | Configuration fragments are typically logical groupings and are assembled | 355 | Configuration fragments are typically logical groupings and are assembled |
356 | by the OpenEmbedded build system to produce input used by the LKC | 356 | by the OpenEmbedded build system to produce input used by the LKC |
357 | that ultimately generates the <filename>.config</filename> file.</para> | 357 | that ultimately generates the <filename>.config</filename> file.</para> |
358 | <para>The | 358 | <para>The |
359 | <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'>KERNEL_FEATURES</ulink></filename> | 359 | <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'>KERNEL_FEATURES</ulink></filename> |
360 | variable can be used to list configuration fragments. | 360 | variable can be used to list configuration fragments. |
361 | For further discussion on applying configuration fragments, see the | 361 | For further discussion on applying configuration fragments, see the |
362 | "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-kernel'>Linux Kernel Configuration</ulink>" | 362 | "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-kernel'>Linux Kernel Configuration</ulink>" |
363 | section in the Yocto Project Board Support Package (BSP) Guide. | 363 | section in the Yocto Project Board Support Package (BSP) Guide. |
364 | </para></listitem> | 364 | </para></listitem> |
365 | </itemizedlist> | 365 | </itemizedlist> |
366 | </para> | 366 | </para> |
367 | </section> | 367 | </section> |
368 | 368 | ||
369 | <section id='kernel-tools'> | 369 | <section id='kernel-tools'> |
370 | <title>Kernel Tools</title> | 370 | <title>Kernel Tools</title> |
@@ -381,11 +381,11 @@ | |||
381 | <listitem><para>Group patches into named, reusable features.</para></listitem> | 381 | <listitem><para>Group patches into named, reusable features.</para></listitem> |
382 | <listitem><para>Allow top-down control of included features.</para></listitem> | 382 | <listitem><para>Allow top-down control of included features.</para></listitem> |
383 | <listitem><para>Bind kernel configurations to kernel patches and features.</para></listitem> | 383 | <listitem><para>Bind kernel configurations to kernel patches and features.</para></listitem> |
384 | <listitem><para>Present a seamless Git repository that blends Yocto Project value | 384 | <listitem><para>Present a seamless Git repository that blends Yocto Project value |
385 | with the <filename>kernel.org</filename> history and development.</para></listitem> | 385 | with the <filename>kernel.org</filename> history and development.</para></listitem> |
386 | </itemizedlist> | 386 | </itemizedlist> |
387 | </para> | 387 | </para> |
388 | </section> | 388 | </section> |
389 | </chapter> | 389 | </chapter> |
390 | <!-- | 390 | <!-- |
391 | vim: expandtab tw=80 ts=4 | 391 | vim: expandtab tw=80 ts=4 |