kernel-dev-maint-appx.xml 18 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357
  1. <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
  2. "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
  3. [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
  4. <!--SPDX-License-Identifier: CC-BY-2.0-UK-->
  5. <appendix id='kernel-dev-maint-appx'>
  6. <title>Kernel Maintenance</title>
  7. <section id='tree-construction'>
  8. <title>Tree Construction</title>
  9. <para>
  10. This section describes construction of the Yocto Project kernel
  11. source repositories as accomplished by the Yocto Project team to
  12. create Yocto Linux kernel repositories.
  13. These kernel repositories are found under the heading "Yocto Linux
  14. Kernel" at
  15. <ulink url='&YOCTO_GIT_URL;'>&YOCTO_GIT_URL;</ulink>
  16. and are shipped as part of a Yocto Project release.
  17. The team creates these repositories by compiling and executing the
  18. set of feature descriptions for every BSP and feature in the
  19. product.
  20. Those feature descriptions list all necessary patches,
  21. configurations, branches, tags, and feature divisions found in a
  22. Yocto Linux kernel.
  23. Thus, the Yocto Project Linux kernel repository (or tree) and
  24. accompanying Metadata in the
  25. <filename>yocto-kernel-cache</filename> are built.
  26. </para>
  27. <para>
  28. The existence of these repositories allow you to access and clone a
  29. particular Yocto Project Linux kernel repository and use it to
  30. build images based on their configurations and features.
  31. </para>
  32. <para>
  33. You can find the files used to describe all the valid features and
  34. BSPs in the Yocto Project Linux kernel in any clone of the Yocto
  35. Project Linux kernel source repository and
  36. <filename>yocto-kernel-cache</filename> Git trees.
  37. For example, the following commands clone the Yocto Project
  38. baseline Linux kernel that branches off
  39. <filename>linux.org</filename> version 4.12 and the
  40. <filename>yocto-kernel-cache</filename>, which contains stores of
  41. kernel Metadata:
  42. <literallayout class='monospaced'>
  43. $ git clone git://git.yoctoproject.org/linux-yocto-4.12
  44. $ git clone git://git.yoctoproject.org/linux-kernel-cache
  45. </literallayout>
  46. For more information on how to set up a local Git repository of
  47. the Yocto Project Linux kernel files, see the
  48. "<link linkend='preparing-the-build-host-to-work-on-the-kernel'>Preparing the Build Host to Work on the Kernel</link>"
  49. section.
  50. </para>
  51. <para>
  52. Once you have cloned the kernel Git repository and the
  53. cache of Metadata on your local machine, you can discover the
  54. branches that are available in the repository using the following
  55. Git command:
  56. <literallayout class='monospaced'>
  57. $ git branch -a
  58. </literallayout>
  59. Checking out a branch allows you to work with a particular
  60. Yocto Linux kernel.
  61. For example, the following commands check out the
  62. "standard/beagleboard" branch of the Yocto Linux kernel repository
  63. and the "yocto-4.12" branch of the
  64. <filename>yocto-kernel-cache</filename> repository:
  65. <literallayout class='monospaced'>
  66. $ cd ~/linux-yocto-4.12
  67. $ git checkout -b my-kernel-4.12 remotes/origin/standard/beagleboard
  68. $ cd ~/linux-kernel-cache
  69. $ git checkout -b my-4.12-metadata remotes/origin/yocto-4.12
  70. </literallayout>
  71. <note>
  72. Branches in the <filename>yocto-kernel-cache</filename>
  73. repository correspond to Yocto Linux kernel versions
  74. (e.g. "yocto-4.12", "yocto-4.10", "yocto-4.9", and so forth).
  75. </note>
  76. Once you have checked out and switched to appropriate branches,
  77. you can see a snapshot of all the kernel source files used to
  78. used to build that particular Yocto Linux kernel for a
  79. particular board.
  80. </para>
  81. <para>
  82. To see the features and configurations for a particular Yocto
  83. Linux kernel, you need to examine the
  84. <filename>yocto-kernel-cache</filename> Git repository.
  85. As mentioned, branches in the
  86. <filename>yocto-kernel-cache</filename> repository correspond to
  87. Yocto Linux kernel versions (e.g. <filename>yocto-4.12</filename>).
  88. Branches contain descriptions in the form of
  89. <filename>.scc</filename> and <filename>.cfg</filename> files.
  90. </para>
  91. <para>
  92. You should realize, however, that browsing your local
  93. <filename>yocto-kernel-cache</filename> repository for feature
  94. descriptions and patches is not an effective way to determine what
  95. is in a particular kernel branch.
  96. Instead, you should use Git directly to discover the changes in
  97. a branch.
  98. Using Git is an efficient and flexible way to inspect changes to
  99. the kernel.
  100. <note>
  101. Ground up reconstruction of the complete kernel tree is an
  102. action only taken by the Yocto Project team during an active
  103. development cycle.
  104. When you create a clone of the kernel Git repository, you are
  105. simply making it efficiently available for building and
  106. development.
  107. </note>
  108. </para>
  109. <para>
  110. The following steps describe what happens when the Yocto Project
  111. Team constructs the Yocto Project kernel source Git repository
  112. (or tree) found at
  113. <ulink url='&YOCTO_GIT_URL;'></ulink> given the
  114. introduction of a new top-level kernel feature or BSP.
  115. The following actions effectively provide the Metadata
  116. and create the tree that includes the new feature, patch, or BSP:
  117. <orderedlist>
  118. <listitem><para>
  119. <emphasis>Pass Feature to the OpenEmbedded Build System:</emphasis>
  120. A top-level kernel feature is passed to the kernel build
  121. subsystem.
  122. Normally, this feature is a BSP for a particular kernel
  123. type.
  124. </para></listitem>
  125. <listitem><para>
  126. <emphasis>Locate Feature:</emphasis>
  127. The file that describes the top-level feature is located
  128. by searching these system directories:
  129. <itemizedlist>
  130. <listitem><para>
  131. The in-tree kernel-cache directories, which are
  132. located in the
  133. <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/yocto-kernel-cache/tree/bsp'><filename>yocto-kernel-cache</filename></ulink>
  134. repository organized under the "Yocto Linux Kernel"
  135. heading in the
  136. <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi'>Yocto Project Source Repositories</ulink>.
  137. </para></listitem>
  138. <listitem><para>
  139. Areas pointed to by <filename>SRC_URI</filename>
  140. statements found in kernel recipes
  141. </para></listitem>
  142. </itemizedlist>
  143. For a typical build, the target of the search is a
  144. feature description in an <filename>.scc</filename> file
  145. whose name follows this format (e.g.
  146. <filename>beaglebone-standard.scc</filename> and
  147. <filename>beaglebone-preempt-rt.scc</filename>):
  148. <literallayout class='monospaced'>
  149. <replaceable>bsp_root_name</replaceable>-<replaceable>kernel_type</replaceable>.scc
  150. </literallayout>
  151. </para></listitem>
  152. <listitem><para>
  153. <emphasis>Expand Feature:</emphasis>
  154. Once located, the feature description is either expanded
  155. into a simple script of actions, or into an existing
  156. equivalent script that is already part of the shipped
  157. kernel.
  158. </para></listitem>
  159. <listitem><para>
  160. <emphasis>Append Extra Features:</emphasis>
  161. Extra features are appended to the top-level feature
  162. description.
  163. These features can come from the
  164. <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'><filename>KERNEL_FEATURES</filename></ulink>
  165. variable in recipes.
  166. </para></listitem>
  167. <listitem><para>
  168. <emphasis>Locate, Expand, and Append Each Feature:</emphasis>
  169. Each extra feature is located, expanded and appended to
  170. the script as described in step three.
  171. </para></listitem>
  172. <listitem><para>
  173. <emphasis>Execute the Script:</emphasis>
  174. The script is executed to produce files
  175. <filename>.scc</filename> and <filename>.cfg</filename>
  176. files in appropriate directories of the
  177. <filename>yocto-kernel-cache</filename> repository.
  178. These files are descriptions of all the branches, tags,
  179. patches and configurations that need to be applied to the
  180. base Git repository to completely create the
  181. source (build) branch for the new BSP or feature.
  182. </para></listitem>
  183. <listitem><para>
  184. <emphasis>Clone Base Repository:</emphasis>
  185. The base repository is cloned, and the actions
  186. listed in the <filename>yocto-kernel-cache</filename>
  187. directories are applied to the tree.
  188. </para></listitem>
  189. <listitem><para>
  190. <emphasis>Perform Cleanup:</emphasis>
  191. The Git repositories are left with the desired branches
  192. checked out and any required branching, patching and
  193. tagging has been performed.
  194. </para></listitem>
  195. </orderedlist>
  196. </para>
  197. <para>
  198. The kernel tree and cache are ready for developer consumption to
  199. be locally cloned, configured, and built into a Yocto Project
  200. kernel specific to some target hardware.
  201. <note><title>Notes</title>
  202. <itemizedlist>
  203. <listitem><para>
  204. The generated <filename>yocto-kernel-cache</filename>
  205. repository adds to the kernel as shipped with the Yocto
  206. Project release.
  207. Any add-ons and configuration data are applied to the
  208. end of an existing branch.
  209. The full repository generation that is found in the
  210. official Yocto Project kernel repositories at
  211. <ulink url='&YOCTO_GIT_URL;'>http://git.yoctoproject.org</ulink>
  212. is the combination of all supported boards and
  213. configurations.
  214. </para></listitem>
  215. <listitem><para>
  216. The technique the Yocto Project team uses is flexible
  217. and allows for seamless blending of an immutable
  218. history with additional patches specific to a
  219. deployment.
  220. Any additions to the kernel become an integrated part
  221. of the branches.
  222. </para></listitem>
  223. <listitem><para>
  224. The full kernel tree that you see on
  225. <ulink url='&YOCTO_GIT_URL;'></ulink> is
  226. generated through repeating the above steps for all
  227. valid BSPs.
  228. The end result is a branched, clean history tree that
  229. makes up the kernel for a given release.
  230. You can see the script (<filename>kgit-scc</filename>)
  231. responsible for this in the
  232. <ulink url='&YOCTO_GIT_URL;/cgit.cgi/yocto-kernel-tools/tree/tools'><filename>yocto-kernel-tools</filename></ulink>
  233. repository.
  234. </para></listitem>
  235. <listitem><para>
  236. The steps used to construct the full kernel tree are
  237. the same steps that BitBake uses when it builds a
  238. kernel image.
  239. </para></listitem>
  240. </itemizedlist>
  241. </note>
  242. </para>
  243. </section>
  244. <section id='build-strategy'>
  245. <title>Build Strategy</title>
  246. <para>
  247. Once you have cloned a Yocto Linux kernel repository and the
  248. cache repository (<filename>yocto-kernel-cache</filename>) onto
  249. your development system, you can consider the compilation phase
  250. of kernel development, which is building a kernel image.
  251. Some prerequisites exist that are validated by the build process
  252. before compilation starts:
  253. </para>
  254. <itemizedlist>
  255. <listitem><para>
  256. The
  257. <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
  258. points to the kernel Git repository.
  259. </para></listitem>
  260. <listitem><para>
  261. A BSP build branch with Metadata exists in the
  262. <filename>yocto-kernel-cache</filename> repository.
  263. The branch is based on the Yocto Linux kernel version and
  264. has configurations and features grouped under the
  265. <filename>yocto-kernel-cache/bsp</filename> directory.
  266. For example, features and configurations for the
  267. BeagleBone Board assuming a
  268. <filename>linux-yocto_4.12</filename> kernel reside in the
  269. following area of the <filename>yocto-kernel-cache</filename>
  270. repository:
  271. <literallayout class='monospaced'>
  272. yocto-kernel-cache/bsp/beaglebone
  273. </literallayout>
  274. <note>
  275. In the previous example, the "yocto-4.12" branch is
  276. checked out in the <filename>yocto-kernel-cache</filename>
  277. repository.
  278. </note>
  279. </para></listitem>
  280. </itemizedlist>
  281. <para>
  282. The OpenEmbedded build system makes sure these conditions exist
  283. before attempting compilation.
  284. Other means, however, do exist, such as as bootstrapping a BSP.
  285. </para>
  286. <para>
  287. Before building a kernel, the build process verifies the tree
  288. and configures the kernel by processing all of the
  289. configuration "fragments" specified by feature descriptions
  290. in the <filename>.scc</filename> files.
  291. As the features are compiled, associated kernel configuration
  292. fragments are noted and recorded in the series of directories
  293. in their compilation order.
  294. The fragments are migrated, pre-processed and passed to the
  295. Linux Kernel Configuration subsystem (<filename>lkc</filename>) as
  296. raw input in the form of a <filename>.config</filename> file.
  297. The <filename>lkc</filename> uses its own internal dependency
  298. constraints to do the final processing of that information and
  299. generates the final <filename>.config</filename> file that is used
  300. during compilation.
  301. </para>
  302. <para>
  303. Using the board's architecture and other relevant values from
  304. the board's template, kernel compilation is started and a kernel
  305. image is produced.
  306. </para>
  307. <para>
  308. The other thing that you notice once you configure a kernel is that
  309. the build process generates a build tree that is separate from
  310. your kernel's local Git source repository tree.
  311. This build tree has a name that uses the following form, where
  312. <filename>${MACHINE}</filename> is the metadata name of the
  313. machine (BSP) and "kernel_type" is one of the Yocto Project
  314. supported kernel types (e.g. "standard"):
  315. <literallayout class='monospaced'>
  316. linux-${MACHINE}-<replaceable>kernel_type</replaceable>-build
  317. </literallayout>
  318. </para>
  319. <para>
  320. The existing support in the <filename>kernel.org</filename> tree
  321. achieves this default functionality.
  322. </para>
  323. <para>
  324. This behavior means that all the generated files for a particular
  325. machine or BSP are now in the build tree directory.
  326. The files include the final <filename>.config</filename> file,
  327. all the <filename>.o</filename> files, the <filename>.a</filename>
  328. files, and so forth.
  329. Since each machine or BSP has its own separate
  330. <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
  331. in its own separate branch of the Git repository, you can easily
  332. switch between different builds.
  333. </para>
  334. </section>
  335. </appendix>
  336. <!--
  337. vim: expandtab tw=80 ts=4
  338. -->