diff --git a/documentation/Makefile b/documentation/Makefile index 3c02a3c2f0..a761c19dba 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 bd6a85b987..05ff369f5d 100644 --- a/documentation/dev-manual/dev-manual-model.xml +++ b/documentation/dev-manual/dev-manual-model.xml @@ -86,67 +86,26 @@ Kernel Overview - 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: - - - - - - 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 linux-yocto-3.19 - kernel. - Thus, everything further to the right in the structure is based on the - linux-yocto-3.19 kernel. - Branch points to the right in the figure represent where the - linux-yocto-3.19 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. - - - - 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. - - - - 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. - - - - 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. - 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. + + The following figure shows the temporary file structure created on your host system when the build occurs. This diff --git a/documentation/dev-manual/figures/kernel-overview-1.png b/documentation/dev-manual/figures/kernel-overview-1.png deleted file mode 100644 index 116c0b9bd4..0000000000 Binary files a/documentation/dev-manual/figures/kernel-overview-1.png and /dev/null differ diff --git a/documentation/kernel-dev/kernel-dev-concepts-appx.xml b/documentation/kernel-dev/kernel-dev-concepts-appx.xml index 3606301cc7..ee40938b5d 100644 --- a/documentation/kernel-dev/kernel-dev-concepts-appx.xml +++ b/documentation/kernel-dev/kernel-dev-concepts-appx.xml @@ -175,74 +175,105 @@
Kernel Architecture + - 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.
Overview + - 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 kernel.org. + 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 + kernel.org. + - 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 - "Git" section in the - Yocto Project Development Manual. + "Git" section + in the Yocto Project Development Manual. + - 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. - - - 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. + + The following illustration shows the conceptual Yocto + Linux kernel. + - 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. + - 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. + - 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. + - 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. + - 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. + + 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 + 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. +