diff options
author | Andrew Geissler <geissonator@yahoo.com> | 2020-12-13 17:44:15 +0300 |
---|---|---|
committer | Andrew Geissler <geissonator@yahoo.com> | 2020-12-15 21:53:47 +0300 |
commit | 09209eec235a35b7089db987561c12e9bd023237 (patch) | |
tree | 2d3580484ffacafe11b72e9abaab50a428dd617d /poky/documentation/kernel-dev/maint-appx.rst | |
parent | f7ba29eda266e04f867e4338b6b8b10c1969419c (diff) | |
download | openbmc-09209eec235a35b7089db987561c12e9bd023237.tar.xz |
poky: subtree update:0ac99625bf..796be0593a
Alexander Kanavin (31):
netbase: upgrade 6.1 -> 6.2
meson: upgrade 0.55.1 -> 0.56.0
vulkan-samples: update to latest revision
libcap: update 2.44 -> 2.45
bind: upgrade 9.16.7 -> 9.16.9
quota: upgrade 4.05 -> 4.06
pango: upgrade 1.46.2 -> 1.48.0
elfutils: upgrade 0.181 -> 0.182
ifupdown: upgrade 0.8.35 -> 0.8.36
createrepo-c: upgrade 0.16.1 -> 0.16.2
acpica: upgrade 20200925 -> 20201113
grep: upgrade 3.5 -> 3.6
man-pages: upgrade 5.08 -> 5.09
stress-ng: upgrade 0.11.23 -> 0.11.24
libhandy: upgrade 1.0.1 -> 1.0.2
piglit: upgrade to latest revision
xkbcomp: upgrade 1.4.3 -> 1.4.4
lz4: upgrade 1.9.2 -> 1.9.3
bison: upgrade 3.7.3 -> 3.7.4
python3-setuptools-scm: fix upstream version check
cantarell-fonts: update 0.0.25 -> 0.201
meta/lib/oe/reproducible.py: gitsm:// works just as fine as git:// for timestamps
llvm: fix reproducibility
ruby: fix reproducibility
webkitgtk: fix reproducibility
ffmpeg: fix reproducibility
piglit: fix reproducibility
serf: do not install the static library
llvm: sort the lists in generated source reproducibibly
kea: fix reproducibility
poky.conf: do not write current date into distro version, use git hash instead
Andrej Valek (1):
kernel-dummy: fix executing unexpected tasks
Anuj Mittal (1):
releases.rst: add gatesgarth to current releases
Brett Warren (1):
libffi: add patch to revert clang VFP workaround
Chandana kalluri (1):
populate_sdk_ext: use SDK_CUSTOM_TEPLATECONF variable to enable custom templateconf.cfg
Changqing Li (1):
buildtools-tarball: add wic dependency into extended buildtools
Diego Sueiro (2):
modutils-initscripts: Fix modules.dep creation when USE_DEPMOD="0"
initscripts: Change execution order between checkroot and modutils
Dmitry Baryshkov (2):
linux-firmware: upgrade 20201022 -> 20201118
linux-firmware: package ath11k firmware
Fabio Berton (1):
mesa: Update 20.2.1 -> 20.2.4
Gratian Crisan (1):
kernel-module-split.bbclass: fix kernel modules getting marked as CONFFILES
Jack Mitchell (3):
Revert "connman: set service to conflict with systemd-networkd"
systemd-conf: add PACKAGECONFIG to enable/disable auto ethernet DHCP
systemd-conf: match ethernet interfaces by type rather than globbing
Joshua Watt (2):
bitbake: hashserv: client: Fix AF_UNIX path length limits
bitbake: hashserv: Fix broken AF_UNIX path length limit
Kai Kang (2):
systemd-systemctl-native: capable to call without argument
systemd.bbclass: update command to check systemctl available
Kevin Hao (1):
tune-octeontx2.inc: Add tune for Marvell OCTEON TX2 core
Li Wang (2):
qemu: CVE-2020-29129 CVE-2020-29130
qemu: CVE-2020-25624
Luca Boccassi (1):
dbus: move messagebus user to dbus-common package
Michael Halstead (1):
releases: conf: add link to 3.1.4, update to include 3.1.4
Nicolas Dechesne (19):
sphinx: add .vscode in .gitignore
{dev,kernel,sdk}-manual: replace hardcoded release version with &DISTRO;
sphinx: replace bitbake labels with references to corresponding title
brief-yoctoprojectqs: replace labels with references to section title
dev-manual: replace labels with references to section title
ref-manual: replace labels with references to section title
sdk-manual: replace labels with references to section title
overview-manual: remove unused labels
dev-manual: remove unused labels
sphinx: rename top level document in each manual
sphinx: use absolute paths for :doc: references
test-manual: remove 'test-manual' from filenames
toaster-manual: remove 'toaster-manual' from filenames
dev-manual: remove 'dev-manual' from filenames
kernel-dev: remove 'kernel-dev' from filenames
profile-manual: remove 'profile-manual' from filenames
overview-manual: remove 'overview-manual' from filenames
sdk-manual: remove 'sdk' from filenames
ref-manual: remove 'ref' from filenames
Paul Barker (5):
documentation: Simplify yocto_wiki links
documentation: Simplify yocto_git links
ref-manual: Simplify oe_git links
poky.conf: Add opensuseleap-15.2 and fedora-33 to tested distros
poky.conf: Drop fedora-30 from tested distros
Peter Kjellerstedt (2):
pseudo: Simplify pseudo_client_ignore_path_chroot()
bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS
Richard Purdie (8):
lz4: Use the new branch naming from upstream
Revert "bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS"
build-appliance-image: Update to master head revision
bitbake: Revert "fetch2: use relative symlinks for anything pulled from PREMIRRORS"
build-appliance-image: Update to master head revision
metadata_scm: Fix signature handling of METADATA_REVISION and METADATA_BRANCH
poky: Set SDK_VERSION explicitly
build-appliance-image: Update to master head revision
Ross Burton (9):
oeqa/devtool: use Yocto mirror for pv-1.5.3 tarball
image_types: remove obsolete tar comment
image_types: sort tarball file listings
package_manager/ipk: neaten OPKGLIBDIR logic
ldconfig-native: don't write auxiliary cache
package_manager/ipk: improve remove_packaging_data
oeqa/selftest/containerimage: update for improved cleanup
coreutils: add SUSE-specific issues to CVE whitelist
bitbake: msg: use safe YAML loader
Sinan Kaya (1):
poky-tiny: enable section removal
Tomasz Dziendzielski (1):
pseudo: Update to print PSEUDO_LOGFILE in abort message on path mismatches
sangeeta jain (1):
meta/lib/oeqa/manual/oe-core.json: Update test_bitbake_devshell
zangrc (3):
libinput: upgrade 1.16.3 -> 1.16.4
lighttpd: upgrade 1.4.55 -> 1.4.56
sysstat: upgrade 12.4.0 -> 12.4.1
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I65f2f1c9d44433f3e62609240012c42256679b51
Diffstat (limited to 'poky/documentation/kernel-dev/maint-appx.rst')
-rw-r--r-- | poky/documentation/kernel-dev/maint-appx.rst | 239 |
1 files changed, 239 insertions, 0 deletions
diff --git a/poky/documentation/kernel-dev/maint-appx.rst b/poky/documentation/kernel-dev/maint-appx.rst new file mode 100644 index 000000000..89f4b4334 --- /dev/null +++ b/poky/documentation/kernel-dev/maint-appx.rst @@ -0,0 +1,239 @@ +.. SPDX-License-Identifier: CC-BY-SA-2.0-UK + +****************** +Kernel Maintenance +****************** + +Tree Construction +================= + +This section describes construction of the Yocto Project kernel source +repositories as accomplished by the Yocto Project team to create Yocto +Linux kernel repositories. These kernel repositories are found under the +heading "Yocto Linux Kernel" at :yocto_git:`/` and +are shipped as part of a Yocto Project release. The team creates these +repositories by compiling and executing the set of feature descriptions +for every BSP and feature in the product. Those feature descriptions +list all necessary patches, configurations, branches, tags, and feature +divisions found in a Yocto Linux kernel. Thus, the Yocto Project Linux +kernel repository (or tree) and accompanying Metadata in the +``yocto-kernel-cache`` are built. + +The existence of these repositories allow you to access and clone a +particular Yocto Project Linux kernel repository and use it to build +images based on their configurations and features. + +You can find the files used to describe all the valid features and BSPs +in the Yocto Project Linux kernel in any clone of the Yocto Project +Linux kernel source repository and ``yocto-kernel-cache`` Git trees. For +example, the following commands clone the Yocto Project baseline Linux +kernel that branches off ``linux.org`` version 4.12 and the +``yocto-kernel-cache``, which contains stores of kernel Metadata: +:: + + $ git clone git://git.yoctoproject.org/linux-yocto-4.12 + $ git clone git://git.yoctoproject.org/linux-kernel-cache + +For more information on +how to set up a local Git repository of the Yocto Project Linux kernel +files, see the +":ref:`kernel-dev/common:preparing the build host to work on the kernel`" +section. + +Once you have cloned the kernel Git repository and the cache of Metadata +on your local machine, you can discover the branches that are available +in the repository using the following Git command: +:: + + $ git branch -a + +Checking out a branch allows you to work with a particular Yocto Linux +kernel. For example, the following commands check out the +"standard/beagleboard" branch of the Yocto Linux kernel repository and +the "yocto-4.12" branch of the ``yocto-kernel-cache`` repository: +:: + + $ cd ~/linux-yocto-4.12 + $ git checkout -b my-kernel-4.12 remotes/origin/standard/beagleboard + $ cd ~/linux-kernel-cache + $ git checkout -b my-4.12-metadata remotes/origin/yocto-4.12 + +.. note:: + + Branches in the ``yocto-kernel-cache`` repository correspond to Yocto Linux + kernel versions (e.g. "yocto-4.12", "yocto-4.10", "yocto-4.9", and so forth). + +Once you have checked out and switched to appropriate branches, you can +see a snapshot of all the kernel source files used to used to build that +particular Yocto Linux kernel for a particular board. + +To see the features and configurations for a particular Yocto Linux +kernel, you need to examine the ``yocto-kernel-cache`` Git repository. +As mentioned, branches in the ``yocto-kernel-cache`` repository +correspond to Yocto Linux kernel versions (e.g. ``yocto-4.12``). +Branches contain descriptions in the form of ``.scc`` and ``.cfg`` +files. + +You should realize, however, that browsing your local +``yocto-kernel-cache`` repository for feature descriptions and patches +is not an effective way to determine what is in a particular kernel +branch. Instead, you should use Git directly to discover the changes in +a branch. Using Git is an efficient and flexible way to inspect changes +to the kernel. + +.. note:: + + Ground up reconstruction of the complete kernel tree is an action + only taken by the Yocto Project team during an active development + cycle. When you create a clone of the kernel Git repository, you are + simply making it efficiently available for building and development. + +The following steps describe what happens when the Yocto Project Team +constructs the Yocto Project kernel source Git repository (or tree) +found at :yocto_git:`/` given the introduction of a new +top-level kernel feature or BSP. The following actions effectively +provide the Metadata and create the tree that includes the new feature, +patch, or BSP: + +1. *Pass Feature to the OpenEmbedded Build System:* A top-level kernel + feature is passed to the kernel build subsystem. Normally, this + feature is a BSP for a particular kernel type. + +2. *Locate Feature:* The file that describes the top-level feature is + located by searching these system directories: + + - The in-tree kernel-cache directories, which are located in the + :yocto_git:`yocto-kernel-cache </yocto-kernel-cache/tree/bsp>` + repository organized under the "Yocto Linux Kernel" heading in the + :yocto_git:`Yocto Project Source Repositories <>`. + + - Areas pointed to by ``SRC_URI`` statements found in kernel recipes. + + For a typical build, the target of the search is a feature + description in an ``.scc`` file whose name follows this format (e.g. + ``beaglebone-standard.scc`` and ``beaglebone-preempt-rt.scc``): + :: + + bsp_root_name-kernel_type.scc + +3. *Expand Feature:* Once located, the feature description is either + expanded into a simple script of actions, or into an existing + equivalent script that is already part of the shipped kernel. + +4. *Append Extra Features:* Extra features are appended to the top-level + feature description. These features can come from the + :term:`KERNEL_FEATURES` + variable in recipes. + +5. *Locate, Expand, and Append Each Feature:* Each extra feature is + located, expanded and appended to the script as described in step + three. + +6. *Execute the Script:* The script is executed to produce files + ``.scc`` and ``.cfg`` files in appropriate directories of the + ``yocto-kernel-cache`` repository. These files are descriptions of + all the branches, tags, patches and configurations that need to be + applied to the base Git repository to completely create the source + (build) branch for the new BSP or feature. + +7. *Clone Base Repository:* The base repository is cloned, and the + actions listed in the ``yocto-kernel-cache`` directories are applied + to the tree. + +8. *Perform Cleanup:* The Git repositories are left with the desired + branches checked out and any required branching, patching and tagging + has been performed. + +The kernel tree and cache are ready for developer consumption to be +locally cloned, configured, and built into a Yocto Project kernel +specific to some target hardware. + +.. note:: + + - The generated ``yocto-kernel-cache`` repository adds to the kernel + as shipped with the Yocto Project release. Any add-ons and + configuration data are applied to the end of an existing branch. + The full repository generation that is found in the official Yocto + Project kernel repositories at :yocto_git:`/` is the + combination of all supported boards and configurations. + + - The technique the Yocto Project team uses is flexible and allows + for seamless blending of an immutable history with additional + patches specific to a deployment. Any additions to the kernel + become an integrated part of the branches. + + - The full kernel tree that you see on :yocto_git:`/` is + generated through repeating the above steps for all valid BSPs. + The end result is a branched, clean history tree that makes up the + kernel for a given release. You can see the script (``kgit-scc``) + responsible for this in the + :yocto_git:`yocto-kernel-tools </yocto-kernel-tools/tree/tools>` + repository. + + - The steps used to construct the full kernel tree are the same + steps that BitBake uses when it builds a kernel image. + +Build Strategy +============== + +Once you have cloned a Yocto Linux kernel repository and the cache +repository (``yocto-kernel-cache``) onto your development system, you +can consider the compilation phase of kernel development, which is +building a kernel image. Some prerequisites exist that are validated by +the build process before compilation starts: + +- The :term:`SRC_URI` points to the + kernel Git repository. + +- A BSP build branch with Metadata exists in the ``yocto-kernel-cache`` + repository. The branch is based on the Yocto Linux kernel version and + has configurations and features grouped under the + ``yocto-kernel-cache/bsp`` directory. For example, features and + configurations for the BeagleBone Board assuming a + ``linux-yocto_4.12`` kernel reside in the following area of the + ``yocto-kernel-cache`` repository: yocto-kernel-cache/bsp/beaglebone + + .. note:: + + In the previous example, the "yocto-4.12" branch is checked out in + the ``yocto-kernel-cache`` repository. + +The OpenEmbedded build system makes sure these conditions exist before +attempting compilation. Other means, however, do exist, such as +bootstrapping a BSP. + +Before building a kernel, the build process verifies the tree and +configures the kernel by processing all of the configuration "fragments" +specified by feature descriptions in the ``.scc`` files. As the features +are compiled, associated kernel configuration fragments are noted and +recorded in the series of directories in their compilation order. The +fragments are migrated, pre-processed and passed to the Linux Kernel +Configuration subsystem (``lkc``) as raw input in the form of a +``.config`` file. The ``lkc`` uses its own internal dependency +constraints to do the final processing of that information and generates +the final ``.config`` file that is used during compilation. + +Using the board's architecture and other relevant values from the +board's template, kernel compilation is started and a kernel image is +produced. + +The other thing that you notice once you configure a kernel is that the +build process generates a build tree that is separate from your kernel's +local Git source repository tree. This build tree has a name that uses +the following form, where ``${MACHINE}`` is the metadata name of the +machine (BSP) and "kernel_type" is one of the Yocto Project supported +kernel types (e.g. "standard"): +:: + + linux-${MACHINE}-kernel_type-build + +The existing support in the ``kernel.org`` tree achieves this default +functionality. + +This behavior means that all the generated files for a particular +machine or BSP are now in the build tree directory. The files include +the final ``.config`` file, all the ``.o`` files, the ``.a`` files, and +so forth. Since each machine or BSP has its own separate +:term:`Build Directory` in its own separate +branch of the Git repository, you can easily switch between different +builds. |