kernel-dev-maint-appx.xml 18 KB

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