subtree updates
meta-security: 30e755c592..283a773f24:
Armin Kuster (2):
meta-security: Drop ${PYTHON_PN}
openscap: update to tip to fix new build issue.
Jeremy A. Puhlman (4):
arpwatch: fix misspelling of PACKAGECONFIG
aprwatch: Add path for sendmail
Check for usrmerge before removing /usr/lib
arpwatch: install man8 dir
Kevin Hao (4):
docs: dm-verity.txt: Fix a typo
dm-verity: Adjust the image names according to the oe-core change
dm-verity: Set the IMAGE_FSTYPES correctly when dm-verity is enabled
dm-verity-image-initramfs: Set IMAGE_NAME_SUFFIX to empty
Max Krummenacher (1):
layer.conf: Update for the scarthgap release series
Mingli Yu (1):
python3-pyinotify: Make asyncore support optional for Python 3
poky: 7165c23237..110ee701b3:
Alejandro Hernandez Samaniego (1):
python3-manifest: Sync RDEPENDS with latest version
Alexander Kanavin (11):
meson: correct upstream version check (exclude pre-releases)
cargo-c-native: convert from git fetcher to crate fetcher
cargo-c-native: update 0.9.18 -> 0.9.30
man-pages: use env from coreutils-native
sdk-manual: correctly describe separate build-sysroots tasks in direct sdk workflows
dev/ref-manual: document conf-summary.txt together with conf-notes.txt
dev-manual: improve descriptions of 'bitbake -S printdiff'
wayland: fix upstream version check by asking gitlab directly
python3: correct upstream version check
bitbake: bitbake: improve descriptions of '-S printdiff'
selftest/sstatetests: run CDN check twice, ignoring errors the first time
Alexandre Truong (1):
oeqa/selftest/devtool: fix test_devtool_add_git_style2
Anibal Limon (1):
wic: bootimg-partition allow to set var to get boot files
BELOUARGA Mohamed (1):
ref-manual: add documentation of the variable SPDX_NAMESPACE_PREFIX
Bartosz Golaszewski (1):
linux-firmware: update to 20240312
Baruch Siach (1):
oeqa/selftest/overlayfs: test read-only rootfs
Bruce Ashfield (16):
linux-yocto/6.6: cfg: generic arm64
linux-yocto/6.6: cfg: riscv XHCI
linux-yocto/6.6: update to v6.6.21
linux-yocto/6.6: update CVE exclusions (6.6.21)
linux-yocto/6.6: cfg: drop unsettable options
linux-yocto/6.6: drm/tilcdc: Set preferred depth
linux-yocto/6.6: update to v6.6.22
linux-yocto/6.6: update CVE exclusions (6.6.22)
yocto-bsps: update to v6.6.21
linux-yocto/6.6: cfg: genericarm64 platform/peripheral support
linux-yocto/6.6: cfg: genericarm64 configuration updates
linux-yocto/6.6: nftables: ptest and cleanup tweaks
linux-yocto/6.6: update to v6.6.23
linux-yocto/6.6: update CVE exclusions (6.6.23)
linux-yocto-dev: bump to v6.9
lttng-modules: update to v2.13.12
Changqing Li (1):
dnf: fix Exception handling for class ProcessLock
Chen Qi (1):
ovmf: set CVE_PRODUCT and CVE_VERSION
Christian Taedcke (1):
kernel-fitImage: only include valid compatible line
Derek Erdmann (1):
bitbake: fetch2/git: Install Git LFS in local repository config
Enrico Jörns (3):
cml1: remove needless check for write_taint attribute
cml1: prompt location of updated .config after do_menuconfig()
perf: fix TMPDIR contamination for recent mainline kernels
Enrico Scholz (1):
shadow: fix copydir operation with 'pseudo'
Felix Moessbauer (1):
bitbake: utils: better estimate number of available cpus
Harish Sadineni (3):
gcc: Oe-selftest failure analysis - fix for tcl errors
gcc: Oe-selftest failure analysis - fix for vect-simd test failures
binutils: gprofng - change use of bignum to use of bignint
Jermain Horsman (1):
bblayers/makesetup.py: Move git utility functions to oe.buildcfg module
Joe Slater (1):
systemd: enable mac based names in NamePolicy
Jose Quaresma (5):
go.bbclass: set GOPROXY
elfutils: fix unused variable BUFFER_SIZE
go: keep the patches in order
go: upgrade 1.22.1 -> 1.22.2
sstatesig: fix netrc.NetrcParseError exception
Joshua Watt (4):
sstatesig: Set hash server credentials from bitbake variables
bitbake: siggen: Add support for hashserve credentials
sstatesig: Warn on bad .netrc
bitbake: bitbake-hashclient: Warn on bad .netrc
Jörg Sommer (1):
autotools: update link in comment for cross compiling
Kevin Hao (1):
image-live.bbclass: Adjust the default value for INITRD_LIVE
Khem Raj (13):
systemd: Check for directory before chmod'ing it
llvm: Update to 18.1.1 release
elfutils: Fix build break with clang
glibc: Update to tip of 2.39 branch
pam: Fix build with musl
piglit: Switch to upstreamed patch for musl fix
qemuriscv: Fix kbd and mouse emulation for qemuriscv64
llvm: Upgrade to 18.1.2 bugfix release
glibc: Repace aarch configure patch fix with a backport
valgrind: Backport fixes from 3.22 branch
tcl: Forward port skip logic for musl ptests
readline: Apply patches from readline-8.2-patches
mesa: Drop LLVM-17 patch
Lee Chee Yang (1):
migration-guides: add release notes for 4.0.17
Marcel Ziswiler (1):
mesa: enable imagination powervr support
Markus Volk (11):
mesa: fix opencl-spirv build
vala: merge bb and inc files
vala: fix for gtk4 prior to 4.14
libsoup: enable vapi support
gsettings-desktop-schemas: update 45.0 -> 46.0
libadwaita: update 1.4.4 -> 1.5.0
gtk4: update 4.12.5 -> 4.14.1
systemd: disable mdns feature in resolved for zeroconf
webkitgtk: update 2.42.5 -> 2.44.0
gtk+3: disable wayland without opengl
epiphany: update 45.3 -> 46.0
Martin Jansa (2):
contributor-guide: be more specific about meta-* trees
pixman: explicitly disable openmp in native builds
Max Krummenacher (1):
git: git-replacement-native: depend on ca-certificate
Michael Opdenacker (8):
manuals: add initial stylechecks with Vale
profile-manual: usage.rst: formatting fixes
manuals: use "manual page(s)"
profile-manual: usage.rst: fix reference to bug report
documentation: Makefile: remove releases.rst in "make clean"
migration-guides: draft notes for upcoming release 5.0
manuals: add initial stylechecks with Vale
profile-manual: usage.rst: further style improvements
Oleh Matiusha (3):
bash: improve reproducibility
curl: improve reproducibility
gmp: improve reproducibility
Paul Barker (1):
kernel: Fix check_oldest_kernel
Peter A. Bigot (1):
bitbake: lib/bb: support NO_COLOR
Peter Kjellerstedt (1):
util-linux: Set the license for util-linux-fcntl-lock to MIT
Philippe Rivest (1):
bitbake: bitbake: fetch2/git: Escape parentheses in git src name
Quentin Schulz (1):
u-boot: fix externalsrc not triggering do_configure on defconfig changes
Randy MacLeod (1):
gstreamer: upgrade 1.22.10 -> 1.22.11
Richard Purdie (10):
poky: Update to prepare for scarthgap release
layer.conf: Prepare for release, drop nanbield LAYERSERIES
expat: Upgrade 2.6.1 -> 2.6.2
bash/flex: Ensure BUILD_FLAGS doesn't leak onto target
uninative: Add pthread linking workaround
poky-altcfg: Default to ipk packaging
util-linux: Add missing MIT license
util-linux: Add fcntl-lock
run-postinsts: Add workaround for locking deadlock issue
oeqa/sstatetests: Fix race issue
Ross Burton (22):
genericarm64.wks: reorder partitions
genericarm64: clean up kernel modules and firmware
linux-firmware: add support for deduplicating the firmware
linux-firmware: set LICENSE field for -liquidui and -mellanox
linux-firmware: remove pointless linux-firmware-gplv2-license package
curl: improve run-ptest
curl: increase test timeouts
gstreamer1.0: improve test reliability
linux-yocto: put COMPATIBLE_MACHINE first
linux-yocto: implicitly track oe-core's kernel version for genericarm64
bitbake: fetch2: handle URIs with single-valued query parameters
python3_pip517: just count wheels in the directory, not subdirectories
python-*: don't set PYPI_ARCHIVE_NAME and S when PYPI_PACKAGE is sufficient
tcl: improve run-ptest
tcl: skip I/O channel 46.1
genericarm64: add qemuboot configuration
classes/qemuboot: add depends on qemu-system-native and qemu-helper-native
README.hardware.md: fix Markdown formatting
README.hardware.md: add section on genericarm64 on qemu
glib-2.0: skip a timing sensitive ptest
openssl: fix crash on aarch64 if BTI is enabled but no Crypto instructions
curl: fix quoting when disabling flaky tests
Ryan Eatmon (1):
perf: Fix QA error due to most recent kernel
Sam Van Den Berge (1):
shadow: don't install libattr.so.* when xattr not in DISTRO_FEATURES
Sava Jakovljev (1):
bitbake: bitbake-worker: Fix bug where umask 0 was not being applied to a task
Simone Weiß (1):
gnutls: upgrade 3.8.3 -> 3.8.4
Soumya Sambu (1):
go: Upgrade 1.22.0 -> 1.22.1
Sourav Kumar Pramanik (1):
libseccomp: Add back in PTESTS_SLOW list
Sundeep KOKKONDA (1):
rust: reproducibility issue fix with v1.75
Tim Orling (2):
coreutils: drop obsolete liberror-perl RDEPENDS
liberror-perl: move to meta-perl
Timon Bergelt (1):
populate_sdk_ext.bbclass: only overwirte lsb string if uninative is used
Tom Hochstein (2):
bmaptool: Add bmap-tools runtime alias for compatibility
toolchain-shar-relocate.sh: Add check for missing command 'file'
Trevor Woerner (1):
bmaptool: update to latest
Ulrich Ölmann (1):
ref-manual: classes: update description of class 'image_types'
Viswanath Kraleti (1):
bitbake: fetch2: Fix misleading "no output" msg
Wang Mingyu (1):
libadwaita: upgrade 1.4.3 -> 1.4.4
William Lyu (1):
openssh: Add a workaround for ICE on powerpc64le
Xiangyu Chen (3):
lttng-tools: skip kernel tests if no kernel modules present
ltp: fix missing connectors tests in scenario_groups/default
lttng-tools: fix rotation-destroy-flush test fails if no kernel module present
Yang Xu (1):
bitbake: bitbake-worker: Fix silent hang issue caused by unexpected stdout content
Yannick Rodriguez (1):
linux-firmware: Move Intel 9260 modules firmware.
Yash Shinde (1):
glibc: Skip 2 qemu tests that can hang in oe-selftest
Yi Zhao (1):
libtirpc: drop redundant PACKAGECONFIG
Yoann Congal (6):
cve-update-nvd2-native: Fix typo in comment
cve-update-nvd2-native: Add an age threshold for incremental update
cve-update-nvd2-native: Remove duplicated CVE_CHECK_DB_FILE definition
cve-update-nvd2-native: nvd_request_next: Improve comment
cve-update-nvd2-native: Fix CVE configuration update
cve-update-nvd2-native: Remove rejected CVE from database
Yogesh Tyagi (1):
lttng-modules: fix v6.8+ build
david d zuhn (1):
bitbake: bitbake-worker: allow '=' in environment variable values
lixiaoyong (3):
kernel-module-split.bbclass: enhance objcopy command call for kernel compilation with llvm
utils: enhance readelf command call with llvm
oe/package: enhance objdump command call with llvm
meta-raspberrypi: 92a9b7a012..d072cc8a48:
Khem Raj (9):
linux-raspberrypi: Add recipe for 6.6 LTS kernel
bluez-firmware-rpidistro: Upgrade to 1.2-9+rpt3 release
linux-firmware-rpidistro: Upgrade to bookworm/20230625-2+rpt2
raspberrypi-firmware: Fetch using git URI
rpi-base: Add missing broadcom/ prefix to find DTB files
rpi-default-versions: Switch default kernel to 6.6
linux-raspberrypi_6.6: Bump to 6.6.22
rpi-bootfiles: Resort to github APIs for tarballs
raspberrypi-firmware: Revert to debian archive
Martin Jansa (1):
userland: fix installed-vs-shipped in multilib builds
jdavidsson (1):
rpi-base: Add hifiberry-dacplusadc overlay
meta-arm: aba9250494..d9e18ce792:
Abdellatif El Khlifi (1):
arm-bsp/corstone1000: add documentation disclaimer
Alexander Sverdlin (1):
optee-ftpm: fix EARLY_TA_PATHS passed to optee-os
Ali Can Ozaslan (4):
arm-bsp/trusted-firmware-m: corstone1000: update to 2.0
arm-bsp/trusted-services: corstone1000: Client Id adjustments after TF-M 2.0
arm/trusted-firmware-m: Change GNU Arm compiler version for TF-M 2.0
arm-bsp/trusted-firmware-a: n1sdp: update to 2.10
Anusmita Dutta Mazumder (2):
arm-bsp/n1sdp: Update scp-firmware version
arm-bsp/n1sdp: Update EDK2 version
Bence Balogh (2):
arm-bsp/u-boot: corstone1000: fix SMCCC_ARCH_FEATURES detection in the PSCI driver
arm-bsp/trusted-firmware-a: corstone1000: remove SMCCC_ARCH_FEATURES discovery workaround
Delane Brandy (1):
arm/trusted-firmware-a: fix mbedTLS version
Drew Reed (2):
kas: Corstone-1000 kas files updated
bsp: Corstone-1000 userguide updates
Emekcan Aras (2):
arm-bsp/trusted-firmware-a: Upgrade Corstone1000 to TF-A v2.10
arm/trusted-services: Add recipe for block storage service
Jon Mason (17):
README: Add information about release process and mailing list
arm/linux-yocto: remove unreferenced patch
arm/optee: disable clang due to breakage
arm-bsp/tf-a-tests: remove corstone1000 intermediate SHA
arm-bsp/tfa-tests: move n1sdp patch to platform directory
CI: update kas to 4.3.1
arm/edk2: update to 202402
arm/trusted-firmware-a: update to 2.10.2
arm/sbsa-acs: update to 7.1.4
arm/scp-firmware: update to v2.14.0
arm-toolchain/gcc-arm-none-eabi: remove 11.2
CI: reduce coverage of dev kernel
arm/sbsa-acs: remove unreferenced patch
arm-toolchain: correct UPSTREAM_CHECK
Revert "arm/rmm: Add bitbake, include and patch file for RMM firmware"
arm/sbsa-acs: use UPSTREAM_CHECK_URI for version checking
arm: use UPSTREAM_CHECK_COMMITS for git versioned recipes
Mathieu Poirier (1):
arm/rmm: Add bitbake, include and patch file for RMM firmware
Ross Burton (3):
arm arm-bsp: enable patch-status warnings
Add SECURITY.md
CI: ignore netrc warnings caused by Kas
meta-openembedded: a0237019f5..a6bcdca5b4:
Bartosz Golaszewski (1):
libgpiod: update to v2.1.1
Chad Rockey (1):
cppzmq-dev expects /usr/lib/libzmq.a
Changqing Li (1):
postgresql: fix a runtime error
Chen Qi (1):
tcprelay: fix a minor cross compilation do_configure issue
Christophe Chapuis (9):
lvgl: fix typo in lv-conf.inc
lvgl: install lv_conf.h
lvgl: remove useless FILES include
lvgl: cleanup sed instructions in lv-conf.inc
lvgl: add more variables to lv-conf.inc
lvgl: fix libdrm include
lvgl: lv-conf.inc: generalize sed instructions
lvgl: make libdrm include conditional
lvgl: cleanup sed expression
Dan McGregor (2):
python3-pylint: Update to 3.1.0
python3-pylint: Fix ptest failures
Derek Straka (1):
python3-dbus: re-add recipe with latest patches and add ptest
Etienne Cordonnier (1):
uutils-coreutils: upgrade 0.0.24 -> 0.0.25
Fathi Boudra (1):
python3-django: upgrade 4.2.10 -> 4.2.11
Guðni Már Gilbert (2):
python3-ecdsa: remove python3-pbr
python3-ecdsa: cleanup DEPENDS
Jaeyoon Jung (1):
lvgl: Set resolution prior to buffer
Joe Slater (1):
googletest: allow for shared libraries
Jose Quaresma (1):
ostree: Upgrade 2024.4 -> 2024.5
Jörg Sommer (3):
sngrep: new recipe for ncurses SIP Messages flow viewer
spandsp: new telephony DSP library
bluez-tools: New recipe for bluez5 tools
Kai Kang (2):
Packages depends on libadwaita should require distro feature opengl
thin-provisioning-tools: install binary to ${sbindir}
Khem Raj (55):
squid: Upgrade to 6.8
libosinfo: Fix build with libxml2 v2.12
xmlstarlet: Fix build with API breakage in libxml2 2.12
mariadb: Fix build with libxml2 2.12 ABI changes
libmusicbrainz: Update to tip of trunk
gnome-commander: Fix build with taglib 2.0
gnome-online-accounts: Fix build with libxml2 2.12
vlc: Upgrade to 3.0.20
netcf: Fix build with latest gnulib
php: Upgrade to 8.2.16
vlc: Fix build on 32bit x86
libtinyxml2: Extend for nativesdk
lvgl: Fix dev-elf build QA
layer.conf: Update for the scarthgap release series
dietsplash: Update and fix build with musl
frr: Upgrade to latest on 9.1 stable
frr: Fix build on newer musl
layer.conf: Prepare for release, drop nanbield LAYERSERIES
libcamera: Fix clang support patches
plocate: Fix sys/stat.h and linux/stat.h conflicts with musl
liburing: Upgrade to 2.5
openflow: Delete recipe for 1.0
openflow: Merge .inc into .bb
openflow: Fix build with musl
tracker-miners: Disable seccomp support on musl
libcamera: Fix build on musl systems
ipset: Update to 7.21
ot-daemon: Update to tip of trunk
ot-br-posix: Update to latest
wpantund: Update to latest
xfsdump: Fix build with musl >= 1.2.5
xfstests: Fix build with musl >= 1.2.5
net-snmp: Fix build with musl
rdma-core: Fix build with musl >= 1.2.5
ssmtp: Fix build with musl >= 1.2.5
autofs: Fix build with musl >= 1.2.5
lvm2: Fix build with musl 1.5.2+
sanlock: Fix build with musl >= 1.2.5
ndctl: Fix build issues seen with musl 1.2.5
sdbus-c++-libsystemd: Upgrade to 255.4 release of systemd
sdbus-c++,sdbus-c++-tools: Upgrade to 1.5.0 release
wtmpdb: Upgrade to 0.11.0 release
uftrace: Fix build with musl >= 1.2.5
fio: Upgrade to 3.36+git
i2cdev: Include libgen.h on musl
directfb: Fix build with musl >= 1.2.5
iwd: Upgrade to 2.16
minifi-cpp: Fix libsodium build on aarch64/clang
multipath-tools: Fix build with musl >= 1.2.5
aer-inject: Fix build with latest musl
aer-inject: Replace hardcoded /usr with ${prefix}
microsoft-gsl: Disable disabled-macro-expansion warning as error on clang/musl
meta-python-image-ptest: Use 2G RAM for some demanding tests
python3-pydbus: Add bash dependency for ptests
highway,libjxl: Remove -mfp16-format=ieee when using clang compiler
Leon Anavi (7):
python3-anyio: Upgrade 4.2.0 -> 4.3.0
python3-httpx: Upgrade 0.26.0 -> 0.27.0
python3-multidict: Upgrade 6.0.4 -> 6.0.5
python3-croniter: Upgrade 2.0.1 -> 2.0.3
python3-paho-mqtt: Upgrade 1.6.1 -> 2.0.0
python3-typeguard: Upgrade 4.1.5 -> 4.2.1
python3-cachetools: Upgrade 5.3.2 -> 5.3.3
Marek Vasut (14):
lvgl: Drop dialog-lvgl
lvgl: Upgrade to LVGL 9 series
lvgl: Rename lv-drivers.inc to lv-conf.inc
lvgl: Add SDL2 fullscreen mode configuration option
lvgl: Configure assertions based on DEBUG_BUILD
lvgl: Default to XRGB8888 DRM framebuffer
lvgl: Build shared library
lvgl: Replace sed patching with real patches
lvgl: Generate proper shared libraries with version suffix
lvgl: Reinstate demo configuration settings
lvgl: Update to 9.1.0
lvgl: Drop superfluous ALLOW_EMPTY
lvgl: Drop unnecessary PV append
lvgl: Deduplicate PACKAGECONFIG into lv-conf
Markus Volk (66):
mozjs-115: fix reproducibility issue
webp-pixbuf-loader: update 0.2.5 -> 0.2.7
gnome-control-center: fix reproducibility issue
gnome-disk-utility: fix reproducibility issue
gnome-settings-daemon: fix reproducibility issue
gnome-terminal: fix reproducibility issue
libvncserver: fix reproducibility issue
editorconfig-core-c: fix reproducibility issue
crossguid: fix reproducibility issue
waylandpp: fix reproducibility issue
polkit: remove unneeded workaround
gtk-vnc: fix reproducibility issue
pipewire: update 1.0.3 -> 1.0.4
mutter: remove zenity from rdepends
mutter: update 45.4 -> 46.0
gnome-shell: update 45.4 -> 46.0
gnome-settings-daemon: update 45.0 -> 46.0
gnome-software: update 45.3 -> 46.0
evince: update 45.0 -> 46.0
gnome-online-accounts: update 3.48.0 -> 3.50.0
evolution-data-server: build with webkitgtk4
folks: update 0.15.7 -> 0.15.8
gnome-control-center: update 45.3 -> 46.0
xdg-desktop-portal-gnome: update 45.1 -> 46.0
tracker: update 3.6.0 -> 3.7.0
tracker-miners: update 3.6.2 -> 3.7.0
freerdp3: add recipe
wireplumber: update 0.4.17 -> 0.5.0
tecle: update 45.0 -> 46.0
gnome-calculator: update 45.0.2 -> 46.0
gnome-session: update 45.0 -> 46.0
gnome-remote-desktop: update 45.1 -> 46.0
gnome-calendar: update 45.1 -> 46.0
libgweather4: update 4.4.0 -> 4.4.2
gtksourceview5: update 5.10.0 -> 5.12.0
gnome-control-center: use gcr4 variant
libcloudproviders: update 0.3.5 -> 0.3.6
gnome-themes-extra: build with gtk+3
gtk4mm: add recipe
gnome-system-monitor: update 45.0.1 -> 46.0
gnome-boxes: update 45.0 -> 46.0
eog: update 45.2 -> 45.3
gparted: update 1.5.0 -> 1.6.0
libgtop: update 2.41.1 -> 2.41.3
gnome-bluetooth: update 42.8 -> 46.0
gnome-text-editor: update 45.1 -> 46.0
gnome-chess: update 43.2 -> 46.0
gnome-disk-utility: update 45.0 -> 46.0
gnome-shell-extensions: update 45.2 -> 46.0
msgraph: add recipe
gvfs: update 1.52.2 -> 1.54.0
tracker-miners: drop buildpath from tracker-miner-fs-3
evolution-data-server: disable tests and examples
tracker-miners: fix reproducibility issue for landlock
file-roller: update 43.1 -> 44.0
apache2: preset mpm=prefork by default
gnome-user-share: add recipe
gnome-control-center: update 46.0 -> 46.0.1
gdm: update 45.0.1 -> 46.0
gnome-user-share: remove hardcoded paths
ghex: update 45.1 -> 46.0
libjxl: add recipe
gnome-backgrounds: add runtime depenency for libjxl
highway: add recipe
webkitgtk3: update 2.42.5 -> 2.44.0
gnome-control-center: restore Upstream-Status line
Martin Jansa (5):
unionfs-fuse, dropwatch, postgresql, yasm, multipath-tools, python3-pybind11: add missing Upstream-Status
recipes: Drop remaining PR values from recipes
freerdp3: disable shadow without x11
xfstests: upgrade to v2024.03.03
gtkmm4: add x11 to REQUIRED_DISTRO_FEATURES
Maxin John (7):
tracker: remove unused patch
openal-soft: remove unused patches
libio-pty-perl: remove unsed patch
opengl-es-cts: remove unused patch
emacs: remove unused patch
webkitgtk3: remove unused patch
python3-eth-utils: remove unused patches
Michael Heimpold (1):
ser2net: add a systemd service file
Mingli Yu (4):
gosu: Upgrade to 1.17
googletest: Pass -fPIC to CFLAGS
re2: Upgrade 2023.03.01 -> 2024.03.01
nss: Upgrade 3.74 -> 3.98
Ola x Nilsson (2):
abseil-cpp: Split so-files into separate packages
abseil-cpp: Split so-files into separate packages
Peter Kjellerstedt (3):
abseil-cpp: A little clean-up
libnice: Disable the examples and the tests
abseil-cpp: A little clean-up
Peter Marko (5):
jwt-cpp: fix cmake file install path
soci: fix buildpaths warning
libcpr: add new recipe
python3-grpcio: cleanup dependencies
microsoft-gsl: add new recipe including ptest
Petr Gotthard (2):
libmbim: Revert back to the latest stable 1.30.0
libqmi: Revert back to the latest stable 1.34.0
Randy MacLeod (2):
rsyslog: update from 8.2306.0 to 8.2402.0
nftables: Add DESCRIPTION and HOMEPAGE
Richard Purdie (2):
imagemagick/lcms/fftw: Allow nativesdk versions to exist
buildtools-imagemagick: Add new recipe
Robert P. J. Day (1):
fmt: remove unnecessary "inherit ptest" directive
Robert Yang (6):
yaffs2-utils: Upgrade to 20221209
xfsprogs: 6.5.0 -> 6.6.0
gnulib: 2018-12-18 -> 202401
thin-provisioning-tools: 1.0.9 -> 1.0.12
gperftools: 2.10 -> 2.15
freeradius: 3.0.26 -> 3.2.3
Ross Burton (1):
python3-pydantic-core: just set PYPI_PACKAGE
Sam Van Den Berge (1):
python3-aiohttp: add missing dependencies
Samuli Piippo (1):
geoclue: enable demo agent
Thomas Roos (1):
usrsctp: upgrade to latest version
Tim Orling (1):
liberror-perl: move recipe from oe-core
Tomasz Żyjewski (1):
python: python-libusb1: add recipe
Wang Mingyu (124):
bats: upgrade 1.10.0 -> 1.11.0
c-ares: upgrade 1.26.0 -> 1.27.0
ctags: upgrade 6.1.20240114.0 -> 6.1.20240225.0
dbus-cxx: upgrade 2.5.0 -> 2.5.1
ddrescue: upgrade 1.27 -> 1.28
fetchmail: upgrade 6.4.37 -> 6.4.38
libtalloc: upgrade 2.4.1 -> 2.4.2
libtdb: upgrade 1.4.9 -> 1.4.10
neatvnc: upgrade 0.7.2 -> 0.8.0
ostree: upgrade 2024.3 -> 2024.4
python3-astroid: upgrade 3.0.3 -> 3.1.0
python3-cbor2: upgrade 5.6.1 -> 5.6.2
python3-dnspython: upgrade 2.6.0 -> 2.6.1
python3-eventlet: upgrade 0.35.1 -> 0.35.2
python3-gcovr: upgrade 7.0 -> 7.2
python3-google-api-core: upgrade 2.16.2 -> 2.17.1
python3-google-api-python-client: upgrade 2.118.0 -> 2.120.0
python3-grpcio(-tools): upgrade 1.60.1 -> 1.62.0
python3-ipython: upgrade 8.21.0 -> 8.22.1
python3-pdm: upgrade 2.12.3 -> 2.12.4
python3-pymisp: upgrade 2.4.185 -> 2.4.186
python3-scrypt: upgrade 0.8.20 -> 0.8.24
python3-sentry-sdk: upgrade 1.40.4 -> 1.40.6
smarty: upgrade 4.3.4 -> 4.4.1
stunnel: upgrade 5.69 -> 5.72
abseil-cpp: upgrade 20230802.1 -> 20240116.1
dnf-plugin-tui: upgrade 1.3 -> 1.4
boost-sml: upgrade 1.1.9 -> 1.1.11
ctags: upgrade 6.1.20240225.0 -> 6.1.20240310.0
dialog: upgrade 1.3-20240101 -> 1.3-20240307
flatbuffers: upgrade 23.5.26 -> 24.3.7
gjs: upgrade 1.78.4 -> 1.80.0
hwdata: upgrade 0.379 -> 0.380
iceauth: upgrade 1.0.9 -> 1.0.10
libdnet: upgrade 1.17.0 -> 1.18.0
libopus: upgrade 1.4 -> 1.5.1
libreport: upgrade 2.17.11 -> 2.17.15
libxaw: upgrade 1.0.15 -> 1.0.16
mcelog: upgrade 196 -> 197
networkd-dispatcher: upgrade 2.1 -> 2.2.4
openlldp: upgrade 1.1.0 -> 1.1.1
opensc: upgrade 0.24.0 -> 0.25.0
pcsc-lite: upgrade 2.0.1 -> 2.0.3
python3-a2wsgi: upgrade 1.10.2 -> 1.10.4
python3-apiflask: upgrade 2.1.0 -> 2.1.1
python3-argcomplete: upgrade 3.2.2 -> 3.2.3
python3-bandit: upgrade 1.7.7 -> 1.7.8
python3-blivet: upgrade 3.8.2 -> 3.9.1
python3-blivetgui: upgrade 2.4.2 -> 2.5.0
python3-django: upgrade 5.0.2 -> 5.0.3
python3-elementpath: upgrade 4.3.0 -> 4.4.0
python3-eth-abi: upgrade 5.0.0 -> 5.0.1
python3-eth-rlp: upgrade 1.0.1 -> 2.0.0
python3-flask-migrate: upgrade 4.0.5 -> 4.0.7
python3-google-api-python-client: upgrade 2.120.0 -> 2.122.0
python3-google-auth: upgrade 2.28.1 -> 2.28.2
python3-googleapis-common-protos: upgrade 1.62.0 -> 1.63.0
python3-grpcio-tools: upgrade 1.62.0 -> 1.62.1
python3-grpcio: upgrade 1.62.0 -> 1.62.1
python3-ipython: upgrade 8.22.1 -> 8.22.2
python3-mypy: upgrade 1.8.0 -> 1.9.0
python3-pydantic: upgrade 2.6.3 -> 2.6.4
python3-pymisp: upgrade 2.4.186 -> 2.4.187
python3-pymodbus: upgrade 3.6.4 -> 3.6.6
python3-pyperf: upgrade 2.6.2 -> 2.6.3
python3-pytest-lazy-fixtures: upgrade 1.0.5 -> 1.0.6
python3-pytest-timeout: upgrade 2.2.0 -> 2.3.1
python3-requests-oauthlib: upgrade 1.3.1 -> 1.4.0
python3-sentry-sdk: upgrade 1.40.6 -> 1.42.0
python3-tox: upgrade 4.13.0 -> 4.14.1
python3-traitlets: upgrade 5.14.1 -> 5.14.2
python3-types-psutil: upgrade 5.9.5.20240205 -> 5.9.5.20240316
python3-types-python-dateutil: upgrade 2.8.19.20240106 -> 2.9.0.20240316
tcsh: upgrade 6.24.10 -> 6.24.11
thingsboard-gateway: upgrade 3.4.4 -> 3.4.5
xmessage: upgrade 1.0.6 -> 1.0.7
xrefresh: upgrade 1.0.7 -> 1.1.0
gjs: upgrade 1.80.0 -> 1.80.2
gnome-backgrounds: upgrade 45.0 -> 46.0
gnome-font-viewer: upgrade 45.0 -> 46.0
libblockdev: upgrade 3.1.0 -> 3.1.1
libdeflate: upgrade 1.19 -> 1.20
libmbim: upgrade 1.30.0 -> 1.31.2
libqmi: upgrade 1.34.0 -> 1.35.2
libtommath: upgrade 1.2.1 -> 1.3.0
mcelog: upgrade 197 -> 198
metacity: upgrade 3.50.0 -> 3.52.0
python3-asgiref: upgrade 3.7.2 -> 3.8.1
python3-blivet: upgrade 3.9.1 -> 3.9.2
python3-cassandra-driver: upgrade 3.29.0 -> 3.29.1
python3-djangorestframework: upgrade 3.14.0 -> 3.15.1
python3-eth-rlp: upgrade 2.0.0 -> 2.1.0
python3-eventlet: upgrade 0.35.2 -> 0.36.1
python3-filelock: upgrade 3.13.1 -> 3.13.3
python3-flask-marshmallow: upgrade 1.2.0 -> 1.2.1
python3-flatbuffers: upgrade 24.3.7 -> 24.3.25
python3-google-api-core: upgrade 2.17.1 -> 2.18.0
python3-google-api-python-client: upgrade 2.122.0 -> 2.124.0
python3-google-auth: upgrade 2.28.2 -> 2.29.0
python3-graphviz: upgrade 0.20.1 -> 0.20.3
python3-gspread: upgrade 6.0.2 -> 6.1.0
python3-jdatetime: upgrade 4.1.1 -> 5.0.0
python3-pdm: upgrade 2.12.4 -> 2.13.2
python3-pyasn1-modules: upgrade 0.3.0 -> 0.4.0
python3-pymisp: upgrade 2.4.187 -> 2.4.188
python3-pytest-asyncio: upgrade 0.23.5 -> 0.23.6
python3-pytest-cov: upgrade 4.1.0 -> 5.0.0
python3-pytest-lazy-fixtures: upgrade 1.0.6 -> 1.0.7
python3-pywbem: upgrade 1.6.2 -> 1.6.3
python3-pywbemtools: upgrade 1.2.0 -> 1.2.1
python3-pyzstd: upgrade 0.15.9 -> 0.15.10
python3-requests-oauthlib: upgrade 1.4.0 -> 2.0.0
python3-sentry-sdk: upgrade 1.42.0 -> 1.44.0
python3-socketio: upgrade 5.11.1 -> 5.11.2
python3-thrift: upgrade 0.16.0 -> 0.20.0
python3-tox: upgrade 4.14.1 -> 4.14.2
python3-web3: upgrade 6.15.1 -> 6.16.0
st: upgrade 0.9 -> 0.9.1
thingsboard-gateway: upgrade 3.4.5 -> 3.4.6
thrift: upgrade 0.19.0 -> 0.20.0
tracker-miners: upgrade 3.7.0 -> 3.7.1
tracker: upgrade 3.7.0 -> 3.7.1
wireshark: upgrade 4.2.3 -> 4.2.4
wolfssl: upgrade 5.6.6 -> 5.7.0
William Lyu (3):
nftables: Fix ptest output format issues
nftables: Fix ShellCheck violations in ptest wrapper script "run-ptest"
nftables: Fix failed ptest testcases
Yi Zhao (13):
netplan: upgrade 0.106 -> 1.0
networkmanager: 1.44.0 -> 1.46.0
postfix: upgrade 3.8.5 -> 3.8.6
net-snmp: upgrade 5.9.3 -> 5.9.4
cryptsetup: upgrade 2.7.0 -> 2.7.1
samba: upgrade 4.19.4 -> 4.19.5
civetweb: remove buildpaths from civetweb-targets.cmake
minifi-cpp: upgrade 0.7.0 -> 0.15.0
openvpn: upgrade 2.6.9 -> 2.6.10
rocksdb: upgrade 7.9.2 -> 9.0.0
audit: upgrade 4.0 -> 4.0.1
netplan: add missing config directory
strongswan: upgrade 5.9.13 -> 5.9.14
alperak (15):
python3-icecream: add recipe
python3-invoke: add recipe
python3-traitlets: add ptest and update runtime dependencies
python3-google-auth-oauthlib: add ptest
python3-tomli-w: added recipe which is also include ptest
python3-pytest-localserver: added recipe which is also include ptest
python3-responses: add recipe
python3-google-auth: add ptest and update runtime dependencies
remove obsolete PIP_INSTALL_PACKAGE and PIP_INSTALL_DIST_PATH
python3-a2wsgi: added recipe which is also include ptest
python3-httptools: added recipe which is also include ptest
python3-wsproto: Add recipe
python3-portalocker: enable ptest
python3-validators: upgrade 0.22.0 > 0.24.0 and enable ptest
python3-pydbus: Drop ${PYTHON_PN}
chenheyun (1):
aer-inject:add new recipe
Change-Id: I3cf0e5c87ecdfa18c35d318cb64c0e6559348618
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
diff --git a/poky/documentation/.gitignore b/poky/documentation/.gitignore
index 494b4f4..b23d598 100644
--- a/poky/documentation/.gitignore
+++ b/poky/documentation/.gitignore
@@ -7,3 +7,5 @@
.vscode/
*/svg/*.png
*/svg/*.pdf
+styles/*
+!styles/config
diff --git a/poky/documentation/.vale.ini b/poky/documentation/.vale.ini
new file mode 100644
index 0000000..02042bb
--- /dev/null
+++ b/poky/documentation/.vale.ini
@@ -0,0 +1,7 @@
+StylesPath = styles
+MinAlertLevel = suggestion
+Packages = RedHat, proselint, write-good, alex, Readability, Joblint
+Vocab = Yocto, OpenSource
+[*.rst]
+BasedOnStyles = Vale, RedHat, proselint, write-good, alex, Readability, Joblint
+
diff --git a/poky/documentation/Makefile b/poky/documentation/Makefile
index 9fb6814..c930d2d 100644
--- a/poky/documentation/Makefile
+++ b/poky/documentation/Makefile
@@ -5,6 +5,9 @@
# from the environment for the first two.
SPHINXOPTS ?= -W --keep-going -j auto
SPHINXBUILD ?= sphinx-build
+# Release notes are excluded because they contain contributor names and commit messages which can't be modified
+VALEOPTS ?= --no-wrap --glob '!migration-guides/release-notes-*.rst'
+VALEDOCS ?= .
SOURCEDIR = .
IMAGEDIRS = */svg
BUILDDIR = _build
@@ -20,7 +23,7 @@
help:
@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
-.PHONY: all help Makefile clean publish epub latexpdf
+.PHONY: all help Makefile clean stylecheck publish epub latexpdf
publish: Makefile html singlehtml
rm -rf $(BUILDDIR)/$(DESTDIR)/
@@ -44,7 +47,15 @@
$(SVG2PNG) --export-filename=$@ $<
clean:
- @rm -rf $(BUILDDIR) $(PNGs) $(PDFs) poky.yaml sphinx-static/switchers.js
+ @rm -rf $(BUILDDIR) $(PNGs) $(PDFs) poky.yaml sphinx-static/switchers.js releases.rst
+
+stylecheck:
+ vale sync
+ vale $(VALEOPTS) $(VALEDOCS)
+
+stylecheck:
+ vale sync
+ vale $(VALEOPTS) $(VALEDOCS)
epub: $(PNGs)
$(SOURCEDIR)/set_versions.py
diff --git a/poky/documentation/README b/poky/documentation/README
index 4d31036..8035418 100644
--- a/poky/documentation/README
+++ b/poky/documentation/README
@@ -151,6 +151,20 @@
$ pipenv install
$ pipenv run make html
+Style checking the Yocto Project documentation
+==============================================
+
+The project is starting to use Vale (https://vale.sh/)
+to validate the text style.
+
+To install Vale:
+
+ $ pip install vale
+
+To run Vale:
+
+ $ make stylecheck
+
Sphinx theme and CSS customization
==================================
diff --git a/poky/documentation/contributor-guide/submit-changes.rst b/poky/documentation/contributor-guide/submit-changes.rst
index 59f3c1e..dfeb030 100644
--- a/poky/documentation/contributor-guide/submit-changes.rst
+++ b/poky/documentation/contributor-guide/submit-changes.rst
@@ -432,7 +432,7 @@
:oe_lists:`bitbake-devel </g/bitbake-devel>`
mailing list.
-- *"meta-\*" trees:* These trees contain Metadata. Use the
+- *meta-poky* and *meta-yocto-bsp* trees: These trees contain Metadata. Use the
:yocto_lists:`poky </g/poky>` mailing list.
- *Documentation*: For changes to the Yocto Project documentation, use the
diff --git a/poky/documentation/dev-manual/building.rst b/poky/documentation/dev-manual/building.rst
index 7fcac33..fe50269 100644
--- a/poky/documentation/dev-manual/building.rst
+++ b/poky/documentation/dev-manual/building.rst
@@ -775,10 +775,9 @@
in the script for information on how to use the tool.
- *BitBake's "-S printdiff" Option:* Using this option causes
- BitBake to try to establish the closest signature match it can
- (e.g. in the shared state cache) and then run ``bitbake-diffsigs``
- over the matches to determine the stamps and delta where these two
- stamp trees diverge.
+ BitBake to try to establish the most recent signature match
+ (e.g. in the shared state cache) and then compare matched signatures
+ to determine the stamps and delta where these two stamp trees diverge.
Building Software from an External Source
=========================================
diff --git a/poky/documentation/dev-manual/custom-template-configuration-directory.rst b/poky/documentation/dev-manual/custom-template-configuration-directory.rst
index 9bffef3..06fcada 100644
--- a/poky/documentation/dev-manual/custom-template-configuration-directory.rst
+++ b/poky/documentation/dev-manual/custom-template-configuration-directory.rst
@@ -42,11 +42,11 @@
TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf/templates/default}
If you look at a configuration template directory, you will
-see the ``bblayers.conf.sample``, ``local.conf.sample``, and
+see the ``bblayers.conf.sample``, ``local.conf.sample``, ``conf-summary.txt`` and
``conf-notes.txt`` files. The build system uses these files to form the
respective ``bblayers.conf`` file, ``local.conf`` file, and show
-users a note about the build they're setting up
+users usage information about the build they're setting up
when running the ``oe-init-build-env`` setup script. These can be
edited further if needed to improve or change the build configurations
-available to the users.
+available to the users, and provide useful summaries and detailed usage notes.
diff --git a/poky/documentation/dev-manual/debugging.rst b/poky/documentation/dev-manual/debugging.rst
index ce29815..e20637e 100644
--- a/poky/documentation/dev-manual/debugging.rst
+++ b/poky/documentation/dev-manual/debugging.rst
@@ -339,7 +339,10 @@
:term:`BB_BASEHASH_IGNORE_VARS`
information.
-There is also a ``bitbake-diffsigs`` command for comparing two
+Debugging signature construction and unexpected task executions
+===============================================================
+
+There is a ``bitbake-diffsigs`` command for comparing two
``siginfo`` or ``sigdata`` files. This command can be helpful when
trying to figure out what changed between two versions of a task. If you
call ``bitbake-diffsigs`` with just one file, the command behaves like
@@ -356,8 +359,12 @@
.. note::
Two common values for `SIGNATURE_HANDLER` are "none" and "printdiff", which
- dump only the signature or compare the dumped signature with the cached one,
- respectively.
+ dump only the signature or compare the dumped signature with the most recent one,
+ respectively. "printdiff" will try to establish the most recent
+ signature match (e.g. in the sstate cache) and then
+ compare the matched signatures to determine the stamps and delta
+ where these two stamp trees diverge. This can be used to determine why
+ tasks need to be re-run in situations where that is not expected.
Using BitBake with either of these options causes BitBake to dump out
``sigdata`` files in the ``stamps`` directory for every task it would
diff --git a/poky/documentation/migration-guides/index.rst b/poky/documentation/migration-guides/index.rst
index a3bddb3..d8edd05 100644
--- a/poky/documentation/migration-guides/index.rst
+++ b/poky/documentation/migration-guides/index.rst
@@ -12,6 +12,7 @@
.. toctree::
migration-general
+ release-5.0
release-4.3
release-4.2
release-4.1
diff --git a/poky/documentation/migration-guides/migration-5.0.rst b/poky/documentation/migration-guides/migration-5.0.rst
new file mode 100644
index 0000000..32581d7
--- /dev/null
+++ b/poky/documentation/migration-guides/migration-5.0.rst
@@ -0,0 +1,105 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release 5.0 LTS (scarthgap)
+===========================
+
+Migration notes for 5.0 (scarthgap)
+------------------------------------
+
+This section provides migration information for moving to the Yocto
+Project 5.0 Release (codename "scarthgap") from the prior release.
+
+To migrate from an earlier LTS release, you **also** need to check all
+the previous migration notes from your release to this new one:
+
+- :doc:`/migration-guides/migration-4.3`
+- :doc:`/migration-guides/migration-4.2`
+- :doc:`/migration-guides/migration-4.1`
+- :doc:`/migration-guides/migration-4.0`
+- :doc:`/migration-guides/migration-3.4`
+- :doc:`/migration-guides/migration-3.3`
+- :doc:`/migration-guides/migration-3.2`
+
+.. _migration-5.0-supported-kernel-versions:
+
+Supported kernel versions
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The :term:`OLDEST_KERNEL` setting is still "5.15" in this release, meaning that
+out the box, older kernels are not supported. See :ref:`4.3 migration notes
+<migration-4.3-supported-kernel-versions>` for details.
+
+.. _migration-5.0-supported-distributions:
+
+Supported distributions
+~~~~~~~~~~~~~~~~~~~~~~~
+
+Compared to the previous releases, running BitBake is supported on new
+GNU/Linux distributions:
+
+- Rocky 9
+
+On the other hand, some earlier distributions are no longer supported:
+
+- Fedora 37
+- Ubuntu 22.10
+- OpenSUSE Leap 15.3
+
+See :ref:`all supported distributions <system-requirements-supported-distros>`.
+
+.. _migration-5.0-go-changes:
+
+Go language changes
+~~~~~~~~~~~~~~~~~~~
+
+.. _migration-5.0-systemd-changes:
+
+systemd changes
+~~~~~~~~~~~~~~~
+
+.. _migration-5.0-recipe-changes:
+
+Recipe changes
+~~~~~~~~~~~~~~
+
+- Runtime testing of ptest now fails if no test results are returned by
+ any given ptest.
+
+.. _migration-5.0-deprecated-variables:
+
+Deprecated variables
+~~~~~~~~~~~~~~~~~~~~
+
+The following variables have been deprecated:
+
+.. _migration-5.0-removed-variables:
+
+Removed variables
+~~~~~~~~~~~~~~~~~
+
+The following variables have been removed:
+
+.. _migration-5.0-removed-recipes:
+
+Removed recipes
+~~~~~~~~~~~~~~~
+
+The following recipes have been removed in this release:
+
+.. _migration-5.0-removed-classes:
+
+Removed classes
+~~~~~~~~~~~~~~~
+
+The following classes have been removed in this release:
+
+.. _migration-5.0-qemu-changes:
+
+QEMU changes
+~~~~~~~~~~~~
+
+.. _migration-5.0-misc-changes:
+
+Miscellaneous changes
+~~~~~~~~~~~~~~~~~~~~~
+
diff --git a/poky/documentation/migration-guides/release-4.0.rst b/poky/documentation/migration-guides/release-4.0.rst
index dfe5e18..685799e 100644
--- a/poky/documentation/migration-guides/release-4.0.rst
+++ b/poky/documentation/migration-guides/release-4.0.rst
@@ -23,3 +23,4 @@
release-notes-4.0.14
release-notes-4.0.15
release-notes-4.0.16
+ release-notes-4.0.17
diff --git a/poky/documentation/migration-guides/release-5.0.rst b/poky/documentation/migration-guides/release-5.0.rst
new file mode 100644
index 0000000..bd19b70
--- /dev/null
+++ b/poky/documentation/migration-guides/release-5.0.rst
@@ -0,0 +1,9 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release 5.0 (scarthgap)
+=======================
+
+.. toctree::
+
+ migration-5.0
+ release-notes-5.0
diff --git a/poky/documentation/migration-guides/release-notes-4.0.17.rst b/poky/documentation/migration-guides/release-notes-4.0.17.rst
new file mode 100644
index 0000000..1dfd10c
--- /dev/null
+++ b/poky/documentation/migration-guides/release-notes-4.0.17.rst
@@ -0,0 +1,238 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.0.17 (Kirkstone)
+------------------------------------------
+
+Security Fixes in Yocto-4.0.17
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- bind: Fix :cve:`2023-4408`, :cve:`2023-50387`, :cve:`2023-50868`, :cve:`2023-5517` and :cve:`2023-5679`
+- binutils: Fix :cve:`2023-39129` and :cve:`2023-39130`
+- curl: Fix :cve:`2023-46219`
+- curl: Ignore :cve:`2023-42915`
+- gcc: Ignore :cve:`2023-4039`
+- gdb: Fix :cve:`2023-39129` and :cve:`2023-39130`
+- glibc: Ignore :cve:`2023-0687`
+- go: Fix :cve:`2023-29406`, :cve:`2023-45285`, :cve:`2023-45287`, :cve:`2023-45289`, :cve:`2023-45290`, :cve:`2024-24784` and :cve:`2024-24785`
+- less: Fix :cve:`2022-48624`
+- libgit2: Fix :cve:`2024-24575` and :cve:`2024-24577`
+- libuv: fix :cve:`2024-24806`
+- libxml2: Fix for :cve:`2024-25062`
+- linux-yocto/5.15: Fix :cve:`2022-36402`, :cve:`2022-40982`, :cve:`2022-47940`, :cve:`2023-1193`, :cve:`2023-1194`, :cve:`2023-20569`, :cve:`2023-20588`, :cve:`2023-25775`, :cve:`2023-31085`, :cve:`2023-32247`, :cve:`2023-32250`, :cve:`2023-32252`, :cve:`2023-32254`, :cve:`2023-32257`, :cve:`2023-32258`, :cve:`2023-34324`, :cve:`2023-35827`, :cve:`2023-3772`, :cve:`2023-38427`, :cve:`2023-38430`, :cve:`2023-38431`, :cve_mitre:`2023-3867`, :cve:`2023-39189`, :cve:`2023-39192`, :cve:`2023-39193`, :cve:`2023-39194`, :cve:`2023-39198`, :cve:`2023-40283`, :cve:`2023-4128`, :cve:`2023-4206`, :cve:`2023-4207`, :cve:`2023-4208`, :cve:`2023-4244`, :cve:`2023-4273`, :cve:`2023-42752`, :cve:`2023-42753`, :cve:`2023-42754`, :cve:`2023-42755`, :cve:`2023-4563`, :cve:`2023-4569`, :cve:`2023-45871`, :cve:`2023-4623`, :cve:`2023-46343`, :cve:`2023-46813`, :cve:`2023-46838`, :cve:`2023-46862`, :cve:`2023-4881`, :cve:`2023-4921`, :cve:`2023-51042`, :cve:`2023-5158`, :cve:`2023-51779`, :cve_mitre:`2023-52340`, :cve:`2023-52429`, :cve:`2023-52435`, :cve:`2023-52436`, :cve:`2023-52438`, :cve:`2023-52439`, :cve:`2023-52441`, :cve:`2023-52442`, :cve:`2023-52443`, :cve:`2023-52444`, :cve:`2023-52445`, :cve:`2023-52448`, :cve:`2023-52449`, :cve:`2023-52451`, :cve:`2023-52454`, :cve:`2023-52456`, :cve:`2023-52457`, :cve:`2023-52458`, :cve:`2023-52463`, :cve:`2023-52464`, :cve:`2023-5717`, :cve:`2023-6040`, :cve:`2023-6121`, :cve:`2023-6176`, :cve:`2023-6546`, :cve:`2023-6606`, :cve:`2023-6622`, :cve:`2023-6817`, :cve:`2023-6915`, :cve:`2023-6931`, :cve:`2023-6932`, :cve:`2024-0340`, :cve:`2024-0584`, :cve:`2024-0607`, :cve:`2024-0641`, :cve:`2024-0646`, :cve:`2024-1085`, :cve:`2024-1086`, :cve:`2024-1151`, :cve:`2024-22705`, :cve:`2024-23849`, :cve:`2024-23850`, :cve:`2024-23851`, :cve:`2024-24860`, :cve:`2024-26586`, :cve:`2024-26589`, :cve:`2024-26591`, :cve:`2024-26592`, :cve:`2024-26593`, :cve:`2024-26594`, :cve:`2024-26597` and :cve:`2024-26598`
+- linux-yocto/5.15: Ignore :cve:`2020-27418`, :cve:`2020-36766`, :cve:`2021-33630`, :cve:`2021-33631`, :cve:`2022-48619`, :cve:`2023-2430`, :cve:`2023-40791`, :cve:`2023-42756`, :cve:`2023-44466`, :cve:`2023-45862`, :cve:`2023-45863`, :cve:`2023-45898`, :cve:`2023-4610`, :cve:`2023-4732`, :cve:`2023-5090`, :cve:`2023-51043`, :cve:`2023-5178`, :cve:`2023-51780`, :cve:`2023-51781`, :cve:`2023-51782`, :cve:`2023-5197`, :cve:`2023-52433`, :cve:`2023-52440`, :cve:`2023-52446`, :cve:`2023-52450`, :cve:`2023-52453`, :cve:`2023-52455`, :cve:`2023-52459`, :cve:`2023-52460`, :cve:`2023-52461`, :cve:`2023-52462`, :cve:`2023-5345`, :cve:`2023-5633`, :cve:`2023-5972`, :cve:`2023-6111`, :cve:`2023-6200`, :cve:`2023-6531`, :cve:`2023-6679`, :cve:`2023-7192`, :cve:`2024-0193`, :cve:`2024-0443`, :cve:`2024-0562`, :cve:`2024-0582`, :cve:`2024-0639`, :cve:`2024-0775`, :cve:`2024-26581`, :cve:`2024-26582`, :cve:`2024-26590`, :cve:`2024-26596` and :cve:`2024-26599`
+- linux-yocto/5.10: Fix :cve:`2023-39198`, :cve:`2023-46838`, :cve:`2023-51779`, :cve:`2023-51780`, :cve:`2023-51781`, :cve:`2023-51782`, :cve_mitre:`2023-52340`, :cve:`2023-6040`, :cve:`2023-6121`, :cve:`2023-6606`, :cve:`2023-6817`, :cve:`2023-6915`, :cve:`2023-6931`, :cve:`2023-6932`, :cve:`2024-0584` and :cve:`2024-0646`
+- linux-yocto/5.10: Ignore :cve:`2021-33630`, :cve:`2021-33631`, :cve:`2022-1508`, :cve:`2022-36402`, :cve:`2022-48619`, :cve:`2023-2430`, :cve:`2023-4610`, :cve:`2023-46343`, :cve:`2023-51042`, :cve:`2023-51043`, :cve:`2023-5972`, :cve:`2023-6039`, :cve:`2023-6200`, :cve:`2023-6531`, :cve:`2023-6546`, :cve:`2023-6622`, :cve:`2023-6679`, :cve:`2023-7192`, :cve:`2024-0193`, :cve:`2024-0443`, :cve:`2024-0562`, :cve:`2024-0582`, :cve:`2024-0639`, :cve:`2024-0641`, :cve:`2024-0775`, :cve:`2024-1085` and :cve:`2024-22705`
+- openssl: Fix :cve:`2024-0727`
+- python3-pycryptodome: Fix :cve:`2023-52323`
+- qemu: Fix :cve:`2023-42467`, :cve:`2023-6693` and :cve:`2024-24474`
+- vim: Fix :cve:`2024-22667`
+- xwayland: Fix :cve:`2023-6377` and :cve:`2023-6478`
+
+
+Fixes in Yocto-4.0.17
+~~~~~~~~~~~~~~~~~~~~~
+
+- bind: Upgrade to 9.18.24
+- bitbake: bitbake/codeparser.py: address ast module deprecations in py 3.12
+- bitbake: bitbake/lib/bs4/tests/test_tree.py: python 3.12 regex
+- bitbake: codeparser: replace deprecated ast.Str and 's'
+- bitbake: fetch2: Ensure that git LFS objects are available
+- bitbake: tests/fetch: Add real git lfs tests and decorator
+- bitbake: tests/fetch: git-lfs restore _find_git_lfs
+- bitbake: toaster/toastergui: Bug-fix verify given layer path only if import/add local layer
+- build-appliance-image: Update to kirkstone head revision
+- cmake: Unset CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES
+- contributor-guide: fix lore URL
+- curl: don't enable debug builds
+- cve_check: cleanup logging
+- dbus: Add missing :term:`CVE_PRODUCT`
+- dev-manual: sbom: Rephrase spdx creation
+- dev-manual: runtime-testing: gen-tapdevs need iptables installed
+- dev-manual: packages: clarify shared :term:`PR` service constraint
+- dev-manual: packages: need enough free space
+- dev-manual: start: remove idle line
+- feature-microblaze-versions.inc: python 3.12 regex
+- ghostscript: correct :term:`LICENSE` with AGPLv3
+- image-live.bbclass: LIVE_ROOTFS_TYPE support compression
+- kernel.bbclass: Set pkg-config variables for building modules
+- kernel.bbclass: introduce KERNEL_LOCALVERSION
+- kernel: fix localversion in v6.3+
+- kernel: make LOCALVERSION consistent between recipes
+- ldconfig-native: Fix to point correctly on the DT_NEEDED entries in an ELF file
+- librsvg: Fix do_package_qa error for librsvg
+- linux-firmware: upgrade to 20231211
+- linux-yocto/5.10: update to v5.10.210
+- linux-yocto/5.15: update to v5.15.150
+- manuals: add minimum RAM requirements
+- manuals: suppress excess use of "following" word
+- manuals: update disk space requirements
+- manuals: update references to buildtools
+- manuals: updates for building on Windows (WSL 2)
+- meta/lib/oeqa: python 3.12 regex
+- meta/recipes: python 3.12 regex
+- migration-guide: add release notes for 4.0.16
+- oeqa/selftest/oelib/buildhistory: git default branch
+- oeqa/selftest/recipetool: downgrade meson version to not use pyproject.toml
+- oeqa/selftest/recipetool: expect meson.bb
+- oeqa/selftest/recipetool: fix for python 3.12
+- oeqa/selftest/runtime_test: only run the virgl tests on qemux86-64
+- oeqa: replace deprecated assertEquals
+- openssl: Upgrade to 3.0.13
+- poky.conf: bump version for 4.0.17
+- populate_sdk_ext: use ConfigParser instead of SafeConfigParser
+- python3-jinja2: upgrade to 3.1.3
+- recipetool/create_buildsys_python: use importlib instead of imp
+- ref-manual: system-requirements: recommend buildtools for not supported distros
+- ref-manual: system-requirements: add info on buildtools-make-tarball
+- ref-manual: release-process: grammar fix
+- ref-manual: system-requirements: fix AlmaLinux variable name
+- ref-manual: system-requirements: modify anchor
+- ref-manual: system-requirements: remove outdated note
+- ref-manual: system-requirements: simplify supported distro requirements
+- ref-manual: system-requirements: update packages to build docs
+- scripts/runqemu: add qmp socket support
+- scripts/runqemu: direct mesa to use its own drivers, rather than ones provided by host distro
+- scripts/runqemu: fix regex escape sequences
+- scripts: python 3.12 regex
+- selftest: skip virgl gtk/sdl test on ubuntu 18.04
+- systemd: Only add myhostname to nsswitch.conf if in :term:`PACKAGECONFIG`
+- tzdata : Upgrade to 2024a
+- u-boot: Move UBOOT_INITIAL_ENV back to u-boot.inc
+- useradd-example: do not use unsupported clear text password
+- vim: upgrade to v9.0.2190
+- yocto-bsp: update to v5.15.150
+
+
+Known Issues in Yocto-4.0.17
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.0.17
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- Adrian Freihofer
+- Alassane Yattara
+- Alexander Kanavin
+- Alexander Sverdlin
+- Archana Polampalli
+- Baruch Siach
+- Bruce Ashfield
+- Chen Qi
+- Chris Laplante
+- Deepthi Hemraj
+- Dhairya Nagodra
+- Fabien Mahot
+- Fabio Estevam
+- Hitendra Prajapati
+- Hugo SIMELIERE
+- Jermain Horsman
+- Kai Kang
+- Lee Chee Yang
+- Ludovic Jozeau
+- Michael Opdenacker
+- Ming Liu
+- Munehisa Kamata
+- Narpat Mali
+- Nikhil R
+- Paul Eggleton
+- Paulo Neves
+- Peter Marko
+- Philip Lorenz
+- Poonam Jadhav
+- Priyal Doshi
+- Ross Burton
+- Simone Weiß
+- Soumya Sambu
+- Steve Sakoman
+- Tim Orling
+- Trevor Gamblin
+- Vijay Anusuri
+- Vivek Kumbhar
+- Wang Mingyu
+- Zahir Hussain
+
+
+Repositories / Downloads for Yocto-4.0.17
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+- Repository Location: :yocto_git:`/poky`
+- Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+- Tag: :yocto_git:`yocto-4.0.17 </poky/log/?h=yocto-4.0.17>`
+- Git Revision: :yocto_git:`6d1a878bbf24c66f7186b270f823fcdf82e35383 </poky/commit/?id=6d1a878bbf24c66f7186b270f823fcdf82e35383>`
+- Release Artefact: poky-6d1a878bbf24c66f7186b270f823fcdf82e35383
+- sha: 3bc3010340b674f7b0dd0a7997f0167b2240b794fbd4aa28c0c4217bddd15e30
+- Download Locations:
+ http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.17/poky-6d1a878bbf24c66f7186b270f823fcdf82e35383.tar.bz2
+ http://mirrors.kernel.org/yocto/yocto/yocto-4.0.17/poky-6d1a878bbf24c66f7186b270f823fcdf82e35383.tar.bz2
+
+openembedded-core
+
+- Repository Location: :oe_git:`/openembedded-core`
+- Branch: :oe_git:`kirkstone </openembedded-core/log/?h=kirkstone>`
+- Tag: :oe_git:`yocto-4.0.17 </openembedded-core/log/?h=yocto-4.0.17>`
+- Git Revision: :oe_git:`2501534c9581c6c3439f525d630be11554a57d24 </openembedded-core/commit/?id=2501534c9581c6c3439f525d630be11554a57d24>`
+- Release Artefact: oecore-2501534c9581c6c3439f525d630be11554a57d24
+- sha: 52cc6cce9e920bdce078584b89136e81cc01e0c55616fab5fca6c3e04264c88e
+- Download Locations:
+ http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.17/oecore-2501534c9581c6c3439f525d630be11554a57d24.tar.bz2
+ http://mirrors.kernel.org/yocto/yocto/yocto-4.0.17/oecore-2501534c9581c6c3439f525d630be11554a57d24.tar.bz2
+
+meta-mingw
+
+- Repository Location: :yocto_git:`/meta-mingw`
+- Branch: :yocto_git:`kirkstone </meta-mingw/log/?h=kirkstone>`
+- Tag: :yocto_git:`yocto-4.0.17 </meta-mingw/log/?h=yocto-4.0.17>`
+- Git Revision: :yocto_git:`f6b38ce3c90e1600d41c2ebb41e152936a0357d7 </meta-mingw/commit/?id=f6b38ce3c90e1600d41c2ebb41e152936a0357d7>`
+- Release Artefact: meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7
+- sha: 7d57167c19077f4ab95623d55a24c2267a3a3fb5ed83688659b4c03586373b25
+- Download Locations:
+ http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.17/meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7.tar.bz2
+ http://mirrors.kernel.org/yocto/yocto/yocto-4.0.17/meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7.tar.bz2
+
+meta-gplv2
+
+- Repository Location: :yocto_git:`/meta-gplv2`
+- Branch: :yocto_git:`kirkstone </meta-gplv2/log/?h=kirkstone>`
+- Tag: :yocto_git:`yocto-4.0.17 </meta-gplv2/log/?h=yocto-4.0.17>`
+- Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-gplv2/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>`
+- Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
+- sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
+- Download Locations:
+ http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.17/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+ http://mirrors.kernel.org/yocto/yocto/yocto-4.0.17/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+
+meta-clang
+
+- Repository Location: :yocto_git:`/meta-clang`
+- Branch: :yocto_git:`kirkstone </meta-clang/log/?h=kirkstone>`
+- Tag: :yocto_git:`yocto-4.0.17 </meta-clang/log/?h=yocto-4.0.17>`
+- Git Revision: :yocto_git:`eebe4ff2e539f3ffb01c5060cc4ca8b226ea8b52 </meta-clang/commit/?id=eebe4ff2e539f3ffb01c5060cc4ca8b226ea8b52>`
+- Release Artefact: meta-clang-eebe4ff2e539f3ffb01c5060cc4ca8b226ea8b52
+- sha: 3299e96e069a22c0971e903fbc191f2427efffc83d910ac51bf0237caad01d17
+- Download Locations:
+ http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.17/meta-clang-eebe4ff2e539f3ffb01c5060cc4ca8b226ea8b52.tar.bz2
+ http://mirrors.kernel.org/yocto/yocto/yocto-4.0.17/meta-clang-eebe4ff2e539f3ffb01c5060cc4ca8b226ea8b52.tar.bz2
+
+bitbake
+
+- Repository Location: :oe_git:`/bitbake`
+- Branch: :oe_git:`2.0 </bitbake/log/?h=2.0>`
+- Tag: :oe_git:`yocto-4.0.17 </bitbake/log/?h=yocto-4.0.17>`
+- Git Revision: :oe_git:`40fd5f4eef7460ca67f32cfce8e229e67e1ff607 </bitbake/commit/?id=40fd5f4eef7460ca67f32cfce8e229e67e1ff607>`
+- Release Artefact: bitbake-40fd5f4eef7460ca67f32cfce8e229e67e1ff607
+- sha: 5d20a0e4c5d0fce44bd84778168714a261a30a4b83f67c88df3b8a7e7115e444
+- Download Locations:
+ http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.17/bitbake-40fd5f4eef7460ca67f32cfce8e229e67e1ff607.tar.bz2
+ http://mirrors.kernel.org/yocto/yocto/yocto-4.0.17/bitbake-40fd5f4eef7460ca67f32cfce8e229e67e1ff607.tar.bz2
+
+yocto-docs
+
+- Repository Location: :yocto_git:`/yocto-docs`
+- Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+- Tag: :yocto_git:`yocto-4.0.17 </yocto-docs/log/?h=yocto-4.0.17>`
+- Git Revision: :yocto_git:`08ce7db2aa3a38deb8f5aa59bafc78542986babb </yocto-docs/commit/?id=08ce7db2aa3a38deb8f5aa59bafc78542986babb>`
+
diff --git a/poky/documentation/migration-guides/release-notes-5.0.rst b/poky/documentation/migration-guides/release-notes-5.0.rst
new file mode 100644
index 0000000..e5cdd87
--- /dev/null
+++ b/poky/documentation/migration-guides/release-notes-5.0.rst
@@ -0,0 +1,66 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for 5.0 (scarthgap)
+---------------------------------
+
+New Features / Enhancements in 5.0
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- Linux kernel 6.6, gcc 13.2, glibc 2.39, LLVM 18.1, and over XXX other recipe upgrades
+
+- New variables:
+
+- Architecture-specific enhancements:
+
+- Kernel-related enhancements:
+
+- New core recipes:
+
+- QEMU / ``runqemu`` enhancements:
+
+ - QEMU has been upgraded to version 8.2.1
+
+- Rust improvements:
+
+ - Rust has been upgraded to version 1.75
+
+- wic Image Creator enhancements:
+
+- SDK-related improvements:
+
+- Testing:
+
+- Utility script changes:
+
+- BitBake improvements:
+
+- Packaging changes:
+
+- Security improvements:
+
+- Prominent documentation updates:
+
+- Miscellaneous changes:
+
+Known Issues in 5.0
+~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+Recipe License changes in 5.0
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Security Fixes in 5.0
+~~~~~~~~~~~~~~~~~~~~~
+
+Recipe Upgrades in 5.0
+~~~~~~~~~~~~~~~~~~~~~~
+
+Contributors to 5.0
+~~~~~~~~~~~~~~~~~~~
+
+Thanks to the following people who contributed to this release:
+
+Repositories / Downloads for Yocto-5.0
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
diff --git a/poky/documentation/profile-manual/usage.rst b/poky/documentation/profile-manual/usage.rst
index 6f0b041..2f82137 100644
--- a/poky/documentation/profile-manual/usage.rst
+++ b/poky/documentation/profile-manual/usage.rst
@@ -13,7 +13,7 @@
perf
====
-The 'perf' tool is the profiling and tracing tool that comes bundled
+The perf tool is the profiling and tracing tool that comes bundled
with the Linux kernel.
Don't let the fact that it's part of the kernel fool you into thinking
@@ -26,22 +26,22 @@
In many ways, perf aims to be a superset of all the tracing and
profiling tools available in Linux today, including all the other tools
-covered in this HOWTO. The past couple of years have seen perf subsume a
+covered in this How-to. The past couple of years have seen perf subsume a
lot of the functionality of those other tools and, at the same time,
those other tools have removed large portions of their previous
functionality and replaced it with calls to the equivalent functionality
now implemented by the perf subsystem. Extrapolation suggests that at
-some point those other tools will simply become completely redundant and
+some point those other tools will become completely redundant and
go away; until then, we'll cover those other tools in these pages and in
many cases show how the same things can be accomplished in perf and the
other tools when it seems useful to do so.
The coverage below details some of the most common ways you'll likely
want to apply the tool; full documentation can be found either within
-the tool itself or in the man pages at
+the tool itself or in the manual pages at
`perf(1) <https://linux.die.net/man/1/perf>`__.
-Perf Setup
+perf Setup
----------
For this section, we'll assume you've already performed the basic setup
@@ -54,14 +54,14 @@
perf runs on the target system for the most part. You can archive
profile data and copy it to the host for analysis, but for the rest of
-this document we assume you've ssh'ed to the host and will be running
-the perf commands on the target.
+this document we assume you're connected to the host through SSH and will be
+running the perf commands on the target.
-Basic Perf Usage
+Basic perf Usage
----------------
The perf tool is pretty much self-documenting. To remind yourself of the
-available commands, simply type 'perf', which will show you basic usage
+available commands, just type ``perf``, which will show you basic usage
along with the available perf subcommands::
root@crownbay:~# perf
@@ -97,19 +97,19 @@
Using perf to do Basic Profiling
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-As a simple test case, we'll profile the 'wget' of a fairly large file,
+As a simple test case, we'll profile the ``wget`` of a fairly large file,
which is a minimally interesting case because it has both file and
network I/O aspects, and at least in the case of standard Yocto images,
it's implemented as part of BusyBox, so the methods we use to analyze it
-can be used in a very similar way to the whole host of supported BusyBox
-applets in Yocto. ::
+can be used in a similar way to the whole host of supported BusyBox
+applets in Yocto::
root@crownbay:~# rm linux-2.6.19.2.tar.bz2; \
wget &YOCTO_DL_URL;/mirror/sources/linux-2.6.19.2.tar.bz2
The quickest and easiest way to get some basic overall data about what's
-going on for a particular workload is to profile it using 'perf stat'.
-'perf stat' basically profiles using a few default counters and displays
+going on for a particular workload is to profile it using ``perf stat``.
+This command basically profiles using a few default counters and displays
the summed counts at the end of the run::
root@crownbay:~# perf stat wget &YOCTO_DL_URL;/mirror/sources/linux-2.6.19.2.tar.bz2
@@ -131,13 +131,13 @@
59.836627620 seconds time elapsed
-Many times such a simple-minded test doesn't yield much of
-interest, but sometimes it does (see Real-world Yocto bug (slow
-loop-mounted write speed)).
+Such a simple-minded test doesn't always yield much of interest, but sometimes
+it does (see the :yocto_bugs:`Slow write speed on live images with denzil
+</show_bug.cgi?id=3049>` bug report).
-Also, note that 'perf stat' isn't restricted to a fixed set of counters
-- basically any event listed in the output of 'perf list' can be tallied
-by 'perf stat'. For example, suppose we wanted to see a summary of all
+Also, note that ``perf stat`` isn't restricted to a fixed set of counters
+--- basically any event listed in the output of ``perf list`` can be tallied
+by ``perf stat``. For example, suppose we wanted to see a summary of all
the events related to kernel memory allocation/freeing along with cache
hits and misses::
@@ -164,22 +164,22 @@
44.831023415 seconds time elapsed
-So 'perf stat' gives us a nice easy
+As you can see, ``perf stat`` gives us a nice easy
way to get a quick overview of what might be happening for a set of
events, but normally we'd need a little more detail in order to
understand what's going on in a way that we can act on in a useful way.
-To dive down into a next level of detail, we can use 'perf record'/'perf
-report' which will collect profiling data and present it to use using an
-interactive text-based UI (or simply as text if we specify ``--stdio`` to
-'perf report').
+To dive down into a next level of detail, we can use ``perf record`` /
+``perf report`` which will collect profiling data and present it to use using an
+interactive text-based UI (or just as text if we specify ``--stdio`` to
+``perf report``).
-As our first attempt at profiling this workload, we'll simply run 'perf
-record', handing it the workload we want to profile (everything after
-'perf record' and any perf options we hand it --- here none, will be
+As our first attempt at profiling this workload, we'll just run ``perf
+record``, handing it the workload we want to profile (everything after
+``perf record`` and any perf options we hand it --- here none, will be
executed in a new shell). perf collects samples until the process exits
-and records them in a file named 'perf.data' in the current working
-directory. ::
+and records them in a file named ``perf.data`` in the current working
+directory::
root@crownbay:~# perf record wget &YOCTO_DL_URL;/mirror/sources/linux-2.6.19.2.tar.bz2
@@ -189,7 +189,7 @@
[ perf record: Captured and wrote 0.176 MB perf.data (~7700 samples) ]
To see the results in a
-'text-based UI' (tui), simply run 'perf report', which will read the
+"text-based UI" (tui), just run ``perf report``, which will read the
perf.data file in the current working directory and display the results
in an interactive UI::
@@ -199,26 +199,26 @@
:align: center
:width: 70%
-The above screenshot displays a 'flat' profile, one entry for each
-'bucket' corresponding to the functions that were profiled during the
+The above screenshot displays a "flat" profile, one entry for each
+"bucket" corresponding to the functions that were profiled during the
profiling run, ordered from the most popular to the least (perf has
options to sort in various orders and keys as well as display entries
only above a certain threshold and so on --- see the perf documentation
-for details). Note that this includes both userspace functions (entries
-containing a [.]) and kernel functions accounted to the process (entries
-containing a [k]). (perf has command-line modifiers that can be used to
-restrict the profiling to kernel or userspace, among others).
+for details). Note that this includes both user space functions (entries
+containing a ``[.]``) and kernel functions accounted to the process (entries
+containing a ``[k]``). perf has command-line modifiers that can be used to
+restrict the profiling to kernel or user space, among others.
-Notice also that the above report shows an entry for 'busybox', which is
-the executable that implements 'wget' in Yocto, but that instead of a
+Notice also that the above report shows an entry for ``busybox``, which is
+the executable that implements ``wget`` in Yocto, but that instead of a
useful function name in that entry, it displays a not-so-friendly hex
value instead. The steps below will show how to fix that problem.
Before we do that, however, let's try running a different profile, one
which shows something a little more interesting. The only difference
-between the new profile and the previous one is that we'll add the -g
+between the new profile and the previous one is that we'll add the ``-g``
option, which will record not just the address of a sampled function,
-but the entire callchain to the sampled function as well::
+but the entire call chain to the sampled function as well::
root@crownbay:~# perf record -g wget &YOCTO_DL_URL;/mirror/sources/linux-2.6.19.2.tar.bz2
Connecting to downloads.yoctoproject.org (140.211.169.59:80)
@@ -233,45 +233,45 @@
:align: center
:width: 70%
-Using the callgraph view, we can actually see not only which functions
+Using the call graph view, we can actually see not only which functions
took the most time, but we can also see a summary of how those functions
were called and learn something about how the program interacts with the
kernel in the process.
-Notice that each entry in the above screenshot now contains a '+' on the
-left-hand side. This means that we can expand the entry and drill down
-into the callchains that feed into that entry. Pressing 'enter' on any
-one of them will expand the callchain (you can also press 'E' to expand
-them all at the same time or 'C' to collapse them all).
+Notice that each entry in the above screenshot now contains a ``+`` on the
+left side. This means that we can expand the entry and drill down
+into the call chains that feed into that entry. Pressing ``Enter`` on any
+one of them will expand the call chain (you can also press ``E`` to expand
+them all at the same time or ``C`` to collapse them all).
In the screenshot above, we've toggled the ``__copy_to_user_ll()`` entry
-and several subnodes all the way down. This lets us see which callchains
+and several subnodes all the way down. This lets us see which call chains
contributed to the profiled ``__copy_to_user_ll()`` function which
contributed 1.77% to the total profile.
-As a bit of background explanation for these callchains, think about
-what happens at a high level when you run wget to get a file out on the
+As a bit of background explanation for these call chains, think about
+what happens at a high level when you run ``wget`` to get a file out on the
network. Basically what happens is that the data comes into the kernel
-via the network connection (socket) and is passed to the userspace
-program 'wget' (which is actually a part of BusyBox, but that's not
+via the network connection (socket) and is passed to the user space
+program ``wget`` (which is actually a part of BusyBox, but that's not
important for now), which takes the buffers the kernel passes to it and
writes it to a disk file to save it.
The part of this process that we're looking at in the above call stacks
is the part where the kernel passes the data it has read from the socket
-down to wget i.e. a copy-to-user.
+down to wget i.e. a ``copy-to-user``.
Notice also that here there's also a case where the hex value is
-displayed in the callstack, here in the expanded ``sys_clock_gettime()``
-function. Later we'll see it resolve to a userspace function call in
-busybox.
+displayed in the call stack, here in the expanded ``sys_clock_gettime()``
+function. Later we'll see it resolve to a user space function call in
+BusyBox.
.. image:: figures/perf-wget-g-copy-from-user-expanded-stripped.png
:align: center
:width: 70%
-The above screenshot shows the other half of the journey for the data -
-from the wget program's userspace buffers to disk. To get the buffers to
+The above screenshot shows the other half of the journey for the data ---
+from the ``wget`` program's user space buffers to disk. To get the buffers to
disk, the wget program issues a ``write(2)``, which does a ``copy-from-user`` to
the kernel, which then takes care via some circuitous path (probably
also present somewhere in the profile data), to get it safely to disk.
@@ -281,8 +281,8 @@
task at hand and see if we can get some basic idea about where the time
is spent in the program we're profiling, wget. Remember that wget is
actually implemented as an applet in BusyBox, so while the process name
-is 'wget', the executable we're actually interested in is BusyBox. So
-let's expand the first entry containing BusyBox:
+is ``wget``, the executable we're actually interested in is ``busybox``.
+Therefore, let's expand the first entry containing BusyBox:
.. image:: figures/perf-wget-busybox-expanded-stripped.png
:align: center
@@ -293,7 +293,7 @@
Expanding the BusyBox entry doesn't make it any better.
The problem is that perf can't find the symbol information for the
-busybox binary, which is actually stripped out by the Yocto build
+``busybox`` binary, which is actually stripped out by the Yocto build
system.
One way around that is to put the following in your ``local.conf`` file
@@ -303,40 +303,39 @@
However, we already have an image with the binaries stripped, so
what can we do to get perf to resolve the symbols? Basically we need to
-install the debuginfo for the BusyBox package.
+install the debugging information for the BusyBox package.
To generate the debug info for the packages in the image, we can add
``dbg-pkgs`` to :term:`EXTRA_IMAGE_FEATURES` in ``local.conf``. For example::
EXTRA_IMAGE_FEATURES = "debug-tweaks tools-profile dbg-pkgs"
-Additionally, in order to generate the type of debuginfo that perf
-understands, we also need to set
-:term:`PACKAGE_DEBUG_SPLIT_STYLE`
+Additionally, in order to generate the type of debugging information that perf
+understands, we also need to set :term:`PACKAGE_DEBUG_SPLIT_STYLE`
in the ``local.conf`` file::
PACKAGE_DEBUG_SPLIT_STYLE = 'debug-file-directory'
-Once we've done that, we can install the
-debuginfo for BusyBox. The debug packages once built can be found in
-``build/tmp/deploy/rpm/*`` on the host system. Find the busybox-dbg-...rpm
-file and copy it to the target. For example::
+Once we've done that, we can install the debugging information for BusyBox. The
+debug packages once built can be found in ``build/tmp/deploy/rpm/*``
+on the host system. Find the ``busybox-dbg-...rpm`` file and copy it
+to the target. For example::
[trz@empanada core2]$ scp /home/trz/yocto/crownbay-tracing-dbg/build/tmp/deploy/rpm/core2_32/busybox-dbg-1.20.2-r2.core2_32.rpm root@192.168.1.31:
busybox-dbg-1.20.2-r2.core2_32.rpm 100% 1826KB 1.8MB/s 00:01
-Now install the debug rpm on the target::
+Now install the debug RPM on the target::
root@crownbay:~# rpm -i busybox-dbg-1.20.2-r2.core2_32.rpm
-Now that the debuginfo is installed, we see that the BusyBox entries now display
+Now that the debugging information is installed, we see that the BusyBox entries now display
their functions symbolically:
.. image:: figures/perf-wget-busybox-debuginfo.png
:align: center
:width: 70%
-If we expand one of the entries and press 'enter' on a leaf node, we're
+If we expand one of the entries and press ``Enter`` on a leaf node, we're
presented with a menu of actions we can take to get more information
related to that entry:
@@ -346,17 +345,17 @@
One of these actions allows us to show a view that displays a
busybox-centric view of the profiled functions (in this case we've also
-expanded all the nodes using the 'E' key):
+expanded all the nodes using the ``E`` key):
.. image:: figures/perf-wget-busybox-dso-zoom.png
:align: center
:width: 70%
-Finally, we can see that now that the BusyBox debuginfo is installed,
+Finally, we can see that now that the BusyBox debugging information is installed,
the previously unresolved symbol in the ``sys_clock_gettime()`` entry
mentioned previously is now resolved, and shows that the
-sys_clock_gettime system call that was the source of 6.75% of the
-copy-to-user overhead was initiated by the ``handle_input()`` BusyBox
+``sys_clock_gettime`` system call that was the source of 6.75% of the
+``copy-to-user`` overhead was initiated by the ``handle_input()`` BusyBox
function:
.. image:: figures/perf-wget-g-copy-to-user-expanded-debuginfo.png
@@ -365,15 +364,15 @@
At the lowest level of detail, we can dive down to the assembly level
and see which instructions caused the most overhead in a function.
-Pressing 'enter' on the 'udhcpc_main' function, we're again presented
+Pressing ``Enter`` on the ``udhcpc_main`` function, we're again presented
with a menu:
.. image:: figures/perf-wget-busybox-annotate-menu.png
:align: center
:width: 70%
-Selecting 'Annotate udhcpc_main', we get a detailed listing of
-percentages by instruction for the udhcpc_main function. From the
+Selecting ``Annotate udhcpc_main``, we get a detailed listing of
+percentages by instruction for the ``udhcpc_main`` function. From the
display, we can see that over 50% of the time spent in this function is
taken up by a couple tests and the move of a constant (1) to a register:
@@ -382,17 +381,17 @@
:width: 70%
As a segue into tracing, let's try another profile using a different
-counter, something other than the default 'cycles'.
+counter, something other than the default ``cycles``.
The tracing and profiling infrastructure in Linux has become unified in
a way that allows us to use the same tool with a completely different
set of counters, not just the standard hardware counters that
-traditional tools have had to restrict themselves to (of course the
-traditional tools can also make use of the expanded possibilities now
+traditional tools have had to restrict themselves to (the
+traditional tools can now actually make use of the expanded possibilities now
available to them, and in some cases have, as mentioned previously).
We can get a list of the available events that can be used to profile a
-workload via 'perf list'::
+workload via ``perf list``::
root@crownbay:~# perf list
@@ -528,14 +527,14 @@
.. admonition:: Tying it Together
These are exactly the same set of events defined by the trace event
- subsystem and exposed by ftrace/tracecmd/kernelshark as files in
- /sys/kernel/debug/tracing/events, by SystemTap as
+ subsystem and exposed by ftrace / trace-cmd / KernelShark as files in
+ ``/sys/kernel/debug/tracing/events``, by SystemTap as
kernel.trace("tracepoint_name") and (partially) accessed by LTTng.
Only a subset of these would be of interest to us when looking at this
workload, so let's choose the most likely subsystems (identified by the
-string before the colon in the Tracepoint events) and do a 'perf stat'
-run using only those wildcarded subsystems::
+string before the colon in the ``Tracepoint`` events) and do a ``perf stat``
+run using only those subsystem wildcards::
root@crownbay:~# perf stat -e skb:* -e net:* -e napi:* -e sched:* -e workqueue:* -e irq:* -e syscalls:* wget &YOCTO_DL_URL;/mirror/sources/linux-2.6.19.2.tar.bz2
Performance counter stats for 'wget &YOCTO_DL_URL;/mirror/sources/linux-2.6.19.2.tar.bz2':
@@ -607,8 +606,8 @@
The screenshot above shows the results of running a profile using
sched:sched_switch tracepoint, which shows the relative costs of various
-paths to sched_wakeup (note that sched_wakeup is the name of the
-tracepoint --- it's actually defined just inside ttwu_do_wakeup(), which
+paths to ``sched_wakeup`` (note that ``sched_wakeup`` is the name of the
+tracepoint --- it's actually defined just inside ``ttwu_do_wakeup()``, which
accounts for the function name actually displayed in the profile:
.. code-block:: c
@@ -626,15 +625,15 @@
}
A couple of the more interesting
-callchains are expanded and displayed above, basically some network
-receive paths that presumably end up waking up wget (busybox) when
+call chains are expanded and displayed above, basically some network
+receive paths that presumably end up waking up wget (BusyBox) when
network data is ready.
Note that because tracepoints are normally used for tracing, the default
-sampling period for tracepoints is 1 i.e. for tracepoints perf will
-sample on every event occurrence (this can be changed using the -c
+sampling period for tracepoints is ``1`` i.e. for tracepoints perf will
+sample on every event occurrence (this can be changed using the ``-c``
option). This is in contrast to hardware counters such as for example
-the default 'cycles' hardware counter used for normal profiling, where
+the default ``cycles`` hardware counter used for normal profiling, where
sampling periods are much higher (in the thousands) because profiling
should have as low an overhead as possible and sampling on every cycle
would be prohibitively expensive.
@@ -645,10 +644,10 @@
Profiling is a great tool for solving many problems or for getting a
high-level view of what's going on with a workload or across the system.
It is however by definition an approximation, as suggested by the most
-prominent word associated with it, 'sampling'. On the one hand, it
+prominent word associated with it, ``sampling``. On the one hand, it
allows a representative picture of what's going on in the system to be
-cheaply taken, but on the other hand, that cheapness limits its utility
-when that data suggests a need to 'dive down' more deeply to discover
+cheaply taken, but alternatively, that cheapness limits its utility
+when that data suggests a need to "dive down" more deeply to discover
what's really going on. In such cases, the only way to see what's really
going on is to be able to look at (or summarize more intelligently) the
individual steps that go into the higher-level behavior exposed by the
@@ -661,7 +660,7 @@
-e syscalls:sys_enter_read -e syscalls:sys_exit_read -e syscalls:sys_enter_write -e syscalls:sys_exit_write
wget &YOCTO_DL_URL;/mirror/sources/linux-2.6.19.2.tar.bz2
-We can look at the raw trace output using 'perf script' with no
+We can look at the raw trace output using ``perf script`` with no
arguments::
root@crownbay:~# perf script
@@ -692,7 +691,7 @@
This gives us a detailed timestamped sequence of events that occurred within the
workload with respect to those events.
-In many ways, profiling can be viewed as a subset of tracing -
+In many ways, profiling can be viewed as a subset of tracing ---
theoretically, if you have a set of trace events that's sufficient to
capture all the important aspects of a workload, you can derive any of
the results or views that a profiling run can.
@@ -712,23 +711,23 @@
Another way to look at it is that there are only so many ways that the
'primitive' counters can be used on their own to generate interesting
output; to get anything more complicated than simple counts requires
-some amount of additional logic, which is typically very specific to the
+some amount of additional logic, which is typically specific to the
problem at hand. For example, if we wanted to make use of a 'counter'
that maps to the value of the time difference between when a process was
scheduled to run on a processor and the time it actually ran, we
wouldn't expect such a counter to exist on its own, but we could derive
-one called say 'wakeup_latency' and use it to extract a useful view of
+one called say ``wakeup_latency`` and use it to extract a useful view of
that metric from trace data. Likewise, we really can't figure out from
standard profiling tools how much data every process on the system reads
and writes, along with how many of those reads and writes fail
completely. If we have sufficient trace data, however, we could with the
right tools easily extract and present that information, but we'd need
-something other than pre-canned profiling tools to do that.
+something other than ready-made profiling tools to do that.
Luckily, there is a general-purpose way to handle such needs, called
-'programming languages'. Making programming languages easily available
+"programming languages". Making programming languages easily available
to apply to such problems given the specific format of data is called a
-'programming language binding' for that data and language. Perf supports
+'programming language binding' for that data and language. perf supports
two programming language bindings, one for Python and one for Perl.
.. admonition:: Tying it Together
@@ -738,21 +737,21 @@
DProbes dpcc compiler, an ANSI C compiler which targeted a low-level
assembly language running on an in-kernel interpreter on the target
system. This is exactly analogous to what Sun's DTrace did, except
- that DTrace invented its own language for the purpose. Systemtap,
+ that DTrace invented its own language for the purpose. SystemTap,
heavily inspired by DTrace, also created its own one-off language,
but rather than running the product on an in-kernel interpreter,
created an elaborate compiler-based machinery to translate its
language into kernel modules written in C.
-Now that we have the trace data in perf.data, we can use 'perf script
--g' to generate a skeleton script with handlers for the read/write
-entry/exit events we recorded::
+Now that we have the trace data in ``perf.data``, we can use ``perf script
+-g`` to generate a skeleton script with handlers for the read / write
+entry / exit events we recorded::
root@crownbay:~# perf script -g python
generated Python script: perf-script.py
-The skeleton script simply creates a Python function for each event type in the
-perf.data file. The body of each function simply prints the event name along
+The skeleton script just creates a Python function for each event type in the
+``perf.data`` file. The body of each function just prints the event name along
with its parameters. For example:
.. code-block:: python
@@ -766,7 +765,7 @@
print "skbaddr=%u, len=%u, name=%s\n" % (skbaddr, len, name),
We can run that script directly to print all of the events contained in the
-perf.data file::
+``perf.data`` file::
root@crownbay:~# perf script -s perf-script.py
@@ -795,8 +794,8 @@
syscalls__sys_exit_read 1 11624.859944032 1262 wget nr=3, ret=1024
That in itself isn't very useful; after all, we can accomplish pretty much the
-same thing by simply running 'perf script' without arguments in the same
-directory as the perf.data file.
+same thing by just running ``perf script`` without arguments in the same
+directory as the ``perf.data`` file.
We can however replace the print statements in the generated function
bodies with whatever we want, and thereby make it infinitely more
@@ -817,8 +816,8 @@
Each event handler function in the generated code
is modified to do this. For convenience, we define a common function
-called inc_counts() that each handler calls; inc_counts() simply tallies
-a count for each event using the 'counts' hash, which is a specialized
+called ``inc_counts()`` that each handler calls; ``inc_counts()`` just tallies
+a count for each event using the ``counts`` hash, which is a specialized
hash function that does Perl-like autovivification, a capability that's
extremely useful for kinds of multi-level aggregation commonly used in
processing traces (see perf's documentation on the Python language
@@ -836,7 +835,7 @@
Finally, at the end of the trace processing run, we want to print the
result of all the per-event tallies. For that, we use the special
-'trace_end()' function:
+``trace_end()`` function:
.. code-block:: python
@@ -865,7 +864,7 @@
syscalls__sys_exit_write 8990
Note that this is
-pretty much exactly the same information we get from 'perf stat', which
+pretty much exactly the same information we get from ``perf stat``, which
goes a little way to support the idea mentioned previously that given
the right kind of trace data, higher-level profiling-type summaries can
be derived from it.
@@ -877,44 +876,44 @@
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The examples so far have focused on tracing a particular program or
-workload --- in other words, every profiling run has specified the program
-to profile in the command-line e.g. 'perf record wget ...'.
+workload --- that is, every profiling run has specified the program
+to profile in the command-line e.g. ``perf record wget ...``.
It's also possible, and more interesting in many cases, to run a
system-wide profile or trace while running the workload in a separate
shell.
-To do system-wide profiling or tracing, you typically use the -a flag to
-'perf record'.
+To do system-wide profiling or tracing, you typically use the ``-a`` flag to
+``perf record``.
To demonstrate this, open up one window and start the profile using the
--a flag (press Ctrl-C to stop tracing)::
+``-a`` flag (press ``Ctrl-C`` to stop tracing)::
root@crownbay:~# perf record -g -a
^C[ perf record: Woken up 6 times to write data ]
[ perf record: Captured and wrote 1.400 MB perf.data (~61172 samples) ]
-In another window, run the wget test::
+In another window, run the ``wget`` test::
root@crownbay:~# wget &YOCTO_DL_URL;/mirror/sources/linux-2.6.19.2.tar.bz2
Connecting to downloads.yoctoproject.org (140.211.169.59:80)
linux-2.6.19.2.tar.b 100% \|*******************************\| 41727k 0:00:00 ETA
-Here we see entries not only for our wget load, but for
+Here we see entries not only for our ``wget`` load, but for
other processes running on the system as well:
.. image:: figures/perf-systemwide.png
:align: center
:width: 70%
-In the snapshot above, we can see callchains that originate in libc, and
-a callchain from Xorg that demonstrates that we're using a proprietary X
-driver in userspace (notice the presence of 'PVR' and some other
-unresolvable symbols in the expanded Xorg callchain).
+In the snapshot above, we can see call chains that originate in ``libc``, and
+a call chain from ``Xorg`` that demonstrates that we're using a proprietary X
+driver in user space (notice the presence of ``PVR`` and some other
+unresolvable symbols in the expanded ``Xorg`` call chain).
-Note also that we have both kernel and userspace entries in the above
-snapshot. We can also tell perf to focus on userspace but providing a
-modifier, in this case 'u', to the 'cycles' hardware counter when we
+Note also that we have both kernel and user space entries in the above
+snapshot. We can also tell perf to focus on user space but providing a
+modifier, in this case ``u``, to the ``cycles`` hardware counter when we
record a profile::
root@crownbay:~# perf record -g -a -e cycles:u
@@ -925,25 +924,25 @@
:align: center
:width: 70%
-Notice in the screenshot above, we see only userspace entries ([.])
+Notice in the screenshot above, we see only user space entries (``[.]``)
-Finally, we can press 'enter' on a leaf node and select the 'Zoom into
-DSO' menu item to show only entries associated with a specific DSO. In
-the screenshot below, we've zoomed into the 'libc' DSO which shows all
-the entries associated with the libc-xxx.so DSO.
+Finally, we can press ``Enter`` on a leaf node and select the ``Zoom into
+DSO`` menu item to show only entries associated with a specific DSO. In
+the screenshot below, we've zoomed into the ``libc`` DSO which shows all
+the entries associated with the ``libc-xxx.so`` DSO.
.. image:: figures/perf-systemwide-libc.png
:align: center
:width: 70%
-We can also use the system-wide -a switch to do system-wide tracing.
+We can also use the system-wide ``-a`` switch to do system-wide tracing.
Here we'll trace a couple of scheduler events::
root@crownbay:~# perf record -a -e sched:sched_switch -e sched:sched_wakeup
^C[ perf record: Woken up 38 times to write data ]
[ perf record: Captured and wrote 9.780 MB perf.data (~427299 samples) ]
-We can look at the raw output using 'perf script' with no arguments::
+We can look at the raw output using ``perf script`` with no arguments::
root@crownbay:~# perf script
@@ -961,11 +960,11 @@
Filtering
^^^^^^^^^
-Notice that there are a lot of events that don't really have anything to
-do with what we're interested in, namely events that schedule 'perf'
+Notice that there are many events that don't really have anything to
+do with what we're interested in, namely events that schedule ``perf``
itself in and out or that wake perf up. We can get rid of those by using
-the '--filter' option --- for each event we specify using -e, we can add a
---filter after that to filter out trace events that contain fields with
+the ``--filter`` option --- for each event we specify using ``-e``, we can add a
+``--filter`` after that to filter out trace events that contain fields with
specific values::
root@crownbay:~# perf record -a -e sched:sched_switch --filter 'next_comm != perf && prev_comm != perf' -e sched:sched_wakeup --filter 'comm != perf'
@@ -991,16 +990,16 @@
kworker/0:3 1209 [000] 7932.326214: sched_switch: prev_comm=kworker/0:3 prev_pid=1209 prev_prio=120 prev_state=S ==> next_comm=swapper/0 next_pid=0 next_prio=120
In this case, we've filtered out all events that have
-'perf' in their 'comm' or 'comm_prev' or 'comm_next' fields. Notice that
+``perf`` in their ``comm``, ``comm_prev`` or ``comm_next`` fields. Notice that
there are still events recorded for perf, but notice that those events
-don't have values of 'perf' for the filtered fields. To completely
+don't have values of ``perf`` for the filtered fields. To completely
filter out anything from perf will require a bit more work, but for the
purpose of demonstrating how to use filters, it's close enough.
.. admonition:: Tying it Together
These are exactly the same set of event filters defined by the trace
- event subsystem. See the ftrace/tracecmd/kernelshark section for more
+ event subsystem. See the ftrace / trace-cmd / KernelShark section for more
discussion about these event filters.
.. admonition:: Tying it Together
@@ -1010,14 +1009,14 @@
indispensable part of the perf design as it relates to tracing.
kernel-based event filters provide a mechanism to precisely throttle
the event stream that appears in user space, where it makes sense to
- provide bindings to real programming languages for postprocessing the
+ provide bindings to real programming languages for post-processing the
event stream. This architecture allows for the intelligent and
flexible partitioning of processing between the kernel and user
space. Contrast this with other tools such as SystemTap, which does
all of its processing in the kernel and as such requires a special
project-defined language in order to accommodate that design, or
- LTTng, where everything is sent to userspace and as such requires a
- super-efficient kernel-to-userspace transport mechanism in order to
+ LTTng, where everything is sent to user space and as such requires a
+ super-efficient kernel-to-user space transport mechanism in order to
function properly. While perf certainly can benefit from for instance
advances in the design of the transport, it doesn't fundamentally
depend on them. Basically, if you find that your perf tracing
@@ -1028,9 +1027,9 @@
~~~~~~~~~~~~~~~~~~~~~~~~~
perf isn't restricted to the fixed set of static tracepoints listed by
-'perf list'. Users can also add their own 'dynamic' tracepoints anywhere
-in the kernel. For instance, suppose we want to define our own
-tracepoint on do_fork(). We can do that using the 'perf probe' perf
+``perf list``. Users can also add their own "dynamic" tracepoints anywhere
+in the kernel. For example, suppose we want to define our own
+tracepoint on ``do_fork()``. We can do that using the ``perf probe`` perf
subcommand::
root@crownbay:~# perf probe do_fork
@@ -1042,8 +1041,8 @@
perf record -e probe:do_fork -aR sleep 1
Adding a new tracepoint via
-'perf probe' results in an event with all the expected files and format
-in /sys/kernel/debug/tracing/events, just the same as for static
+``perf probe`` results in an event with all the expected files and format
+in ``/sys/kernel/debug/tracing/events``, just the same as for static
tracepoints (as discussed in more detail in the trace events subsystem
section::
@@ -1076,7 +1075,7 @@
probe:do_fork (on do_fork)
probe:schedule (on schedule)
-Let's record system-wide ('sleep 30' is a
+Let's record system-wide (``sleep 30`` is a
trick for recording system-wide but basically do nothing and then wake
up after 30 seconds)::
@@ -1084,7 +1083,7 @@
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.087 MB perf.data (~3812 samples) ]
-Using 'perf script' we can see each do_fork event that fired::
+Using ``perf script`` we can see each ``do_fork`` event that fired::
root@crownbay:~# perf script
@@ -1125,8 +1124,8 @@
matchbox-deskto 1311 [001] 34237.114106: do_fork: (c1028460)
gaku 1312 [000] 34237.202388: do_fork: (c1028460)
-And using 'perf report' on the same file, we can see the
-callgraphs from starting a few programs during those 30 seconds:
+And using ``perf report`` on the same file, we can see the
+call graphs from starting a few programs during those 30 seconds:
.. image:: figures/perf-probe-do_fork-profile.png
:align: center
@@ -1141,57 +1140,57 @@
.. admonition:: Tying it Together
- Dynamic tracepoints are implemented under the covers by kprobes and
- uprobes. kprobes and uprobes are also used by and in fact are the
+ Dynamic tracepoints are implemented under the covers by Kprobes and
+ Uprobes. Kprobes and Uprobes are also used by and in fact are the
main focus of SystemTap.
-Perf Documentation
+perf Documentation
------------------
-Online versions of the man pages for the commands discussed in this
+Online versions of the manual pages for the commands discussed in this
section can be found here:
-- The `'perf stat' manpage <https://linux.die.net/man/1/perf-stat>`__.
+- The `'perf stat' manual page <https://linux.die.net/man/1/perf-stat>`__.
- The `'perf record'
- manpage <https://linux.die.net/man/1/perf-record>`__.
+ manual page <https://linux.die.net/man/1/perf-record>`__.
- The `'perf report'
- manpage <https://linux.die.net/man/1/perf-report>`__.
+ manual page <https://linux.die.net/man/1/perf-report>`__.
-- The `'perf probe' manpage <https://linux.die.net/man/1/perf-probe>`__.
+- The `'perf probe' manual page <https://linux.die.net/man/1/perf-probe>`__.
- The `'perf script'
- manpage <https://linux.die.net/man/1/perf-script>`__.
+ manual page <https://linux.die.net/man/1/perf-script>`__.
- Documentation on using the `'perf script' Python
binding <https://linux.die.net/man/1/perf-script-python>`__.
-- The top-level `perf(1) manpage <https://linux.die.net/man/1/perf>`__.
+- The top-level `perf(1) manual page <https://linux.die.net/man/1/perf>`__.
-Normally, you should be able to invoke the man pages via perf itself
-e.g. 'perf help' or 'perf help record'.
+Normally, you should be able to open the manual pages via perf itself
+e.g. ``perf help`` or ``perf help record``.
-To have the perf manpages installed on your target, modify your
+To have the perf manual pages installed on your target, modify your
configuration as follows::
IMAGE_INSTALL:append = " perf perf-doc"
DISTRO_FEATURES:append = " api-documentation"
-The man pages in text form, along with some other files, such as a set
-of examples, can also be found in the 'perf' directory of the kernel tree::
+The manual pages in text form, along with some other files, such as a set
+of examples, can also be found in the ``perf`` directory of the kernel tree::
tools/perf/Documentation
There's also a nice perf tutorial on the perf
-wiki that goes into more detail than we do here in certain areas: `Perf
+wiki that goes into more detail than we do here in certain areas: `perf
Tutorial <https://perf.wiki.kernel.org/index.php/Tutorial>`__
ftrace
======
-'ftrace' literally refers to the 'ftrace function tracer' but in reality
-this encompasses a number of related tracers along with the
+"ftrace" literally refers to the "ftrace function tracer" but in reality
+this encompasses several related tracers along with the
infrastructure that they all make use of.
ftrace Setup
@@ -1200,20 +1199,20 @@
For this section, we'll assume you've already performed the basic setup
outlined in the ":ref:`profile-manual/intro:General Setup`" section.
-ftrace, trace-cmd, and kernelshark run on the target system, and are
+ftrace, trace-cmd, and KernelShark run on the target system, and are
ready to go out-of-the-box --- no additional setup is necessary. For the
-rest of this section we assume you've ssh'ed to the host and will be
-running ftrace on the target. kernelshark is a GUI application and if
-you use the '-X' option to ssh you can have the kernelshark GUI run on
+rest of this section we assume you're connected to the host through SSH and
+will be running ftrace on the target. KernelShark is a GUI application and if
+you use the ``-X`` option to ``ssh`` you can have the KernelShark GUI run on
the target but display remotely on the host if you want.
Basic ftrace usage
------------------
-'ftrace' essentially refers to everything included in the /tracing
+"ftrace" essentially refers to everything included in the ``/tracing``
directory of the mounted debugfs filesystem (Yocto follows the standard
-convention and mounts it at /sys/kernel/debug). Here's a listing of all
-the files found in /sys/kernel/debug/tracing on a Yocto system::
+convention and mounts it at ``/sys/kernel/debug``). All the files found in
+``/sys/kernel/debug/tracing`` on a Yocto system are::
root@sugarbay:/sys/kernel/debug/tracing# ls
README kprobe_events trace
@@ -1229,7 +1228,7 @@
free_buffer set_graph_function
The files listed above are used for various purposes
-- some relate directly to the tracers themselves, others are used to set
+--- some relate directly to the tracers themselves, others are used to set
tracing options, and yet others actually contain the tracing output when
a tracer is in effect. Some of the functions can be guessed from their
names, others need explanation; in any case, we'll cover some of the
@@ -1238,30 +1237,30 @@
We'll start by looking at some of the available built-in tracers.
-cat'ing the 'available_tracers' file lists the set of available tracers::
+The ``available_tracers`` file lists the set of available tracers::
root@sugarbay:/sys/kernel/debug/tracing# cat available_tracers
blk function_graph function nop
-The 'current_tracer' file contains the tracer currently in effect::
+The ``current_tracer`` file contains the tracer currently in effect::
root@sugarbay:/sys/kernel/debug/tracing# cat current_tracer
nop
-The above listing of current_tracer shows that the
-'nop' tracer is in effect, which is just another way of saying that
+The above listing of ``current_tracer`` shows that the
+``nop`` tracer is in effect, which is just another way of saying that
there's actually no tracer currently in effect.
-echo'ing one of the available_tracers into current_tracer makes the
+Writing one of the available tracers into ``current_tracer`` makes the
specified tracer the current tracer::
root@sugarbay:/sys/kernel/debug/tracing# echo function > current_tracer
root@sugarbay:/sys/kernel/debug/tracing# cat current_tracer
function
-The above sets the current tracer to be the 'function tracer'. This tracer
+The above sets the current tracer to be the ``function`` tracer. This tracer
traces every function call in the kernel and makes it available as the
-contents of the 'trace' file. Reading the 'trace' file lists the
+contents of the ``trace`` file. Reading the ``trace`` file lists the
currently buffered function calls that have been traced by the function
tracer::
@@ -1308,7 +1307,7 @@
.
Each line in the trace above shows what was happening in the kernel on a given
-cpu, to the level of detail of function calls. Each entry shows the function
+CPU, to the level of detail of function calls. Each entry shows the function
called, followed by its caller (after the arrow).
The function tracer gives you an extremely detailed idea of what the
@@ -1318,11 +1317,11 @@
.. admonition:: Tying it Together
The ftrace function tracer is also available from within perf, as the
- ftrace:function tracepoint.
+ ``ftrace:function`` tracepoint.
It is a little more difficult to follow the call chains than it needs to
be --- luckily there's a variant of the function tracer that displays the
-callchains explicitly, called the 'function_graph' tracer::
+call chains explicitly, called the ``function_graph`` tracer::
root@sugarbay:/sys/kernel/debug/tracing# echo function_graph > current_tracer
root@sugarbay:/sys/kernel/debug/tracing# cat trace | less
@@ -1437,11 +1436,11 @@
3) + 13.784 us | }
3) | sys_ioctl() {
-As you can see, the function_graph display is much easier
+As you can see, the ``function_graph`` display is much easier
to follow. Also note that in addition to the function calls and
associated braces, other events such as scheduler events are displayed
in context. In fact, you can freely include any tracepoint available in
-the trace events subsystem described in the next section by simply
+the trace events subsystem described in the next section by just
enabling those events, and they'll appear in context in the function
graph display. Quite a powerful tool for understanding kernel dynamics.
@@ -1455,9 +1454,9 @@
----------------------------
One especially important directory contained within the
-/sys/kernel/debug/tracing directory is the 'events' subdirectory, which
+``/sys/kernel/debug/tracing`` directory is the ``events`` subdirectory, which
contains representations of every tracepoint in the system. Listing out
-the contents of the 'events' subdirectory, we see mainly another set of
+the contents of the ``events`` subdirectory, we see mainly another set of
subdirectories::
root@sugarbay:/sys/kernel/debug/tracing# cd events
@@ -1505,9 +1504,9 @@
drwxr-xr-x 26 root root 0 Nov 14 23:19 writeback
Each one of these subdirectories
-corresponds to a 'subsystem' and contains yet again more subdirectories,
+corresponds to a "subsystem" and contains yet again more subdirectories,
each one of those finally corresponding to a tracepoint. For example,
-here are the contents of the 'kmem' subsystem::
+here are the contents of the ``kmem`` subsystem::
root@sugarbay:/sys/kernel/debug/tracing/events# cd kmem
root@sugarbay:/sys/kernel/debug/tracing/events/kmem# ls -al
@@ -1529,7 +1528,7 @@
drwxr-xr-x 2 root root 0 Nov 14 23:19 mm_page_pcpu_drain
Let's see what's inside the subdirectory for a
-specific tracepoint, in this case the one for kmalloc::
+specific tracepoint, in this case the one for ``kmalloc``::
root@sugarbay:/sys/kernel/debug/tracing/events/kmem# cd kmalloc
root@sugarbay:/sys/kernel/debug/tracing/events/kmem/kmalloc# ls -al
@@ -1540,12 +1539,12 @@
-r--r--r-- 1 root root 0 Nov 14 23:19 format
-r--r--r-- 1 root root 0 Nov 14 23:19 id
-The 'format' file for the
+The ``format`` file for the
tracepoint describes the event in memory, which is used by the various
tracing tools that now make use of these tracepoint to parse the event
-and make sense of it, along with a 'print fmt' field that allows tools
-like ftrace to display the event as text. Here's what the format of the
-kmalloc event looks like::
+and make sense of it, along with a ``print fmt`` field that allows tools
+like ftrace to display the event as text. The format of the
+``kmalloc`` event looks like::
root@sugarbay:/sys/kernel/debug/tracing/events/kmem/kmalloc# cat format
name: kmalloc
@@ -1580,11 +1579,11 @@
long)(( gfp_t)0x08u), "GFP_MOVABLE"}, {(unsigned long)(( gfp_t)0), "GFP_NOTRACK"}, {(unsigned long)(( gfp_t)0x400000u), "GFP_NO_KSWAPD"},
{(unsigned long)(( gfp_t)0x800000u), "GFP_OTHER_NODE"} ) : "GFP_NOWAIT"
-The 'enable' file
+The ``enable`` file
in the tracepoint directory is what allows the user (or tools such as
-trace-cmd) to actually turn the tracepoint on and off. When enabled, the
-corresponding tracepoint will start appearing in the ftrace 'trace' file
-described previously. For example, this turns on the kmalloc tracepoint::
+``trace-cmd``) to actually turn the tracepoint on and off. When enabled, the
+corresponding tracepoint will start appearing in the ftrace ``trace`` file
+described previously. For example, this turns on the ``kmalloc`` tracepoint::
root@sugarbay:/sys/kernel/debug/tracing/events/kmem/kmalloc# echo 1 > enable
@@ -1596,8 +1595,8 @@
root@sugarbay:/sys/kernel/debug/tracing# echo nop > current_tracer
root@sugarbay:/sys/kernel/debug/tracing# echo 1 > tracing_on
-Now, if we look at the 'trace' file, we see nothing
-but the kmalloc events we just turned on::
+Now, if we look at the ``trace`` file, we see nothing
+but the ``kmalloc`` events we just turned on::
root@sugarbay:/sys/kernel/debug/tracing# cat trace | less
# tracer: nop
@@ -1643,17 +1642,17 @@
<idle>-0 [000] ..s3 18156.400660: kmalloc: call_site=ffffffff81619b36 ptr=ffff88006d554800 bytes_req=512 bytes_alloc=512 gfp_flags=GFP_ATOMIC
matchbox-termin-1361 [001] ...1 18156.552800: kmalloc: call_site=ffffffff81614050 ptr=ffff88006db34800 bytes_req=576 bytes_alloc=1024 gfp_flags=GFP_KERNEL|GFP_REPEAT
-To again disable the kmalloc event, we need to send 0 to the enable file::
+To again disable the ``kmalloc`` event, we need to send ``0`` to the ``enable`` file::
root@sugarbay:/sys/kernel/debug/tracing/events/kmem/kmalloc# echo 0 > enable
You can enable any number of events or complete subsystems (by
-using the 'enable' file in the subsystem directory) and get an
+using the ``enable`` file in the subsystem directory) and get an
arbitrarily fine-grained idea of what's going on in the system by
enabling as many of the appropriate tracepoints as applicable.
-A number of the tools described in this HOWTO do just that, including
-trace-cmd and kernelshark in the next section.
+Several tools described in this How-to do just that, including
+``trace-cmd`` and KernelShark in the next section.
.. admonition:: Tying it Together
@@ -1661,41 +1660,40 @@
ftrace, but by many of the other tools covered in this document and
they form a central point of integration for the various tracers
available in Linux. They form a central part of the instrumentation
- for the following tools: perf, lttng, ftrace, blktrace and SystemTap
+ for the following tools: perf, LTTng, ftrace, blktrace and SystemTap
.. admonition:: Tying it Together
Eventually all the special-purpose tracers currently available in
- /sys/kernel/debug/tracing will be removed and replaced with
- equivalent tracers based on the 'trace events' subsystem.
+ ``/sys/kernel/debug/tracing`` will be removed and replaced with
+ equivalent tracers based on the "trace events" subsystem.
-trace-cmd/kernelshark
----------------------
+trace-cmd / KernelShark
+-----------------------
-trace-cmd is essentially an extensive command-line 'wrapper' interface
+trace-cmd is essentially an extensive command-line "wrapper" interface
that hides the details of all the individual files in
-/sys/kernel/debug/tracing, allowing users to specify specific particular
-events within the /sys/kernel/debug/tracing/events/ subdirectory and to
+``/sys/kernel/debug/tracing``, allowing users to specify specific particular
+events within the ``/sys/kernel/debug/tracing/events/`` subdirectory and to
collect traces and avoid having to deal with those details directly.
-As yet another layer on top of that, kernelshark provides a GUI that
+As yet another layer on top of that, KernelShark provides a GUI that
allows users to start and stop traces and specify sets of events using
an intuitive interface, and view the output as both trace events and as
-a per-CPU graphical display. It directly uses 'trace-cmd' as the
+a per-CPU graphical display. It directly uses trace-cmd as the
plumbing that accomplishes all that underneath the covers (and actually
displays the trace-cmd command it uses, as we'll see).
-To start a trace using kernelshark, first start kernelshark::
+To start a trace using KernelShark, first start this tool::
root@sugarbay:~# kernelshark
-Then bring up the 'Capture' dialog by
-choosing from the kernelshark menu::
+Then open up the ``Capture`` dialog by choosing from the KernelShark menu::
Capture | Record
That will display the following dialog, which allows you to choose one or more
-events (or even one or more complete subsystems) to trace:
+events (or even entire subsystems) to trace:
.. image:: figures/kernelshark-choose-events.png
:align: center
@@ -1703,41 +1701,41 @@
Note that these are exactly the same sets of events described in the
previous trace events subsystem section, and in fact is where trace-cmd
-gets them for kernelshark.
+gets them for KernelShark.
In the above screenshot, we've decided to explore the graphics subsystem
a bit and so have chosen to trace all the tracepoints contained within
-the 'i915' and 'drm' subsystems.
+the ``i915`` and ``drm`` subsystems.
-After doing that, we can start and stop the trace using the 'Run' and
-'Stop' button on the lower right corner of the dialog (the same button
+After doing that, we can start and stop the trace using the ``Run`` and
+``Stop`` button on the lower right corner of the dialog (the same button
will turn into the 'Stop' button after the trace has started):
.. image:: figures/kernelshark-output-display.png
:align: center
:width: 70%
-Notice that the right-hand pane shows the exact trace-cmd command-line
+Notice that the right pane shows the exact trace-cmd command-line
that's used to run the trace, along with the results of the trace-cmd
run.
-Once the 'Stop' button is pressed, the graphical view magically fills up
-with a colorful per-cpu display of the trace data, along with the
+Once the ``Stop`` button is pressed, the graphical view magically fills up
+with a colorful per-CPU display of the trace data, along with the
detailed event listing below that:
.. image:: figures/kernelshark-i915-display.png
:align: center
:width: 70%
-Here's another example, this time a display resulting from tracing 'all
-events':
+Here's another example, this time a display resulting from tracing ``all
+events``:
.. image:: figures/kernelshark-all.png
:align: center
:width: 70%
The tool is pretty self-explanatory, but for more detailed information
-on navigating through the data, see the `kernelshark
+on navigating through the data, see the `KernelShark
website <https://kernelshark.org/Documentation.html>`__.
ftrace Documentation
@@ -1753,41 +1751,41 @@
Documentation/trace/events.txt
-There is a nice series of articles on using ftrace and trace-cmd at LWN:
+A nice series of articles on using ftrace and trace-cmd are available at LWN:
-- `Debugging the kernel using Ftrace - part
+- `Debugging the kernel using ftrace - part
1 <https://lwn.net/Articles/365835/>`__
-- `Debugging the kernel using Ftrace - part
+- `Debugging the kernel using ftrace - part
2 <https://lwn.net/Articles/366796/>`__
-- `Secrets of the Ftrace function
+- `Secrets of the ftrace function
tracer <https://lwn.net/Articles/370423/>`__
- `trace-cmd: A front-end for
- Ftrace <https://lwn.net/Articles/410200/>`__
+ ftrace <https://lwn.net/Articles/410200/>`__
See also `KernelShark's documentation <https://kernelshark.org/Documentation.html>`__
for further usage details.
-An amusing yet useful README (a tracing mini-HOWTO) can be found in
+An amusing yet useful README (a tracing mini-How-to) can be found in
``/sys/kernel/debug/tracing/README``.
-systemtap
+SystemTap
=========
SystemTap is a system-wide script-based tracing and profiling tool.
SystemTap scripts are C-like programs that are executed in the kernel to
-gather/print/aggregate data extracted from the context they end up being
-invoked under.
+gather / print / aggregate data extracted from the context they end up being
+called under.
For example, this probe from the `SystemTap
-tutorial <https://sourceware.org/systemtap/tutorial/>`__ simply prints a
-line every time any process on the system open()s a file. For each line,
+tutorial <https://sourceware.org/systemtap/tutorial/>`__ just prints a
+line every time any process on the system runs ``open()`` on a file. For each line,
it prints the executable name of the program that opened the file, along
-with its PID, and the name of the file it opened (or tried to open),
-which it extracts from the open syscall's argstr.
+with its PID, and the name of the file it opened (or tried to open), which it
+extracts from the argument string (``argstr``) of the ``open`` system call.
.. code-block:: none
@@ -1802,48 +1800,48 @@
}
Normally, to execute this
-probe, you'd simply install systemtap on the system you want to probe,
+probe, you'd just install SystemTap on the system you want to probe,
and directly run the probe on that system e.g. assuming the name of the
-file containing the above text is trace_open.stp::
+file containing the above text is ``trace_open.stp``::
# stap trace_open.stp
-What systemtap does under the covers to run this probe is 1) parse and
-convert the probe to an equivalent 'C' form, 2) compile the 'C' form
+What SystemTap does under the covers to run this probe is 1) parse and
+convert the probe to an equivalent "C" form, 2) compile the "C" form
into a kernel module, 3) insert the module into the kernel, which arms
it, and 4) collect the data generated by the probe and display it to the
user.
-In order to accomplish steps 1 and 2, the 'stap' program needs access to
+In order to accomplish steps 1 and 2, the ``stap`` program needs access to
the kernel build system that produced the kernel that the probed system
-is running. In the case of a typical embedded system (the 'target'), the
+is running. In the case of a typical embedded system (the "target"), the
kernel build system unfortunately isn't typically part of the image
-running on the target. It is normally available on the 'host' system
+running on the target. It is normally available on the "host" system
that produced the target image however; in such cases, steps 1 and 2 are
executed on the host system, and steps 3 and 4 are executed on the
-target system, using only the systemtap 'runtime'.
+target system, using only the SystemTap "runtime".
-The systemtap support in Yocto assumes that only steps 3 and 4 are run
+The SystemTap support in Yocto assumes that only steps 3 and 4 are run
on the target; it is possible to do everything on the target, but this
section assumes only the typical embedded use-case.
-So basically what you need to do in order to run a systemtap script on
+Therefore, what you need to do in order to run a SystemTap script on
the target is to 1) on the host system, compile the probe into a kernel
module that makes sense to the target, 2) copy the module onto the
target system and 3) insert the module into the target kernel, which
arms it, and 4) collect the data generated by the probe and display it
to the user.
-systemtap Setup
+SystemTap Setup
---------------
-Those are a lot of steps and a lot of details, but fortunately Yocto
-includes a script called 'crosstap' that will take care of those
-details, allowing you to simply execute a systemtap script on the remote
+Those are many steps and details, but fortunately Yocto
+includes a script called ``crosstap`` that will take care of those
+details, allowing you to just execute a SystemTap script on the remote
target, with arguments if necessary.
In order to do this from a remote host, however, you need to have access
-to the build for the image you booted. The 'crosstap' script provides
+to the build for the image you booted. The ``crosstap`` script provides
details on how to do this if you run the script on the host without
having done a build::
@@ -1852,29 +1850,35 @@
Error: No target kernel build found.
Did you forget to create a local build of your image?
- 'crosstap' requires a local sdk build of the target system
- (or a build that includes 'tools-profile') in order to build
- kernel modules that can probe the target system.
+'crosstap' requires a local SDK build of the target system
+(or a build that includes 'tools-profile') in order to build
+kernel modules that can probe the target system.
- Practically speaking, that means you need to do the following:
- - If you're running a pre-built image, download the release
- and/or BSP tarballs used to build the image.
- - If you're working from git sources, just clone the metadata
- and BSP layers needed to build the image you'll be booting.
- - Make sure you're properly set up to build a new image (see
- the BSP README and/or the widely available basic documentation
- that discusses how to build images).
- - Build an -sdk version of the image e.g.:
- $ bitbake core-image-sato-sdk
- OR
- - Build a non-sdk image but include the profiling tools:
- [ edit local.conf and add 'tools-profile' to the end of
- the EXTRA_IMAGE_FEATURES variable ]
- $ bitbake core-image-sato
+Practically speaking, that means you need to do the following:
+
+- If you're running a pre-built image, download the release
+ and/or BSP tarballs used to build the image.
+
+- If you're working from git sources, just clone the metadata
+ and BSP layers needed to build the image you'll be booting.
+
+- Make sure you're properly set up to build a new image (see
+ the BSP README and/or the widely available basic documentation
+ that discusses how to build images).
+
+- Build an ``-sdk`` version of the image e.g.::
+
+ $ bitbake core-image-sato-sdk
+
+- Or build a non-SDK image but include the profiling tools
+ (edit ``local.conf`` and add ``tools-profile`` to the end of
+ :term:``EXTRA_IMAGE_FEATURES`` variable)::
+
+ $ bitbake core-image-sato
Once you've build the image on the host system, you're ready to
- boot it (or the equivalent pre-built image) and use 'crosstap'
- to probe it (you need to source the environment as usual first):
+ boot it (or the equivalent pre-built image) and use ``crosstap``
+ to probe it (you need to source the environment as usual first)::
$ source oe-init-build-env
$ cd ~/my/systemtap/scripts
@@ -1882,29 +1886,27 @@
.. note::
- SystemTap, which uses 'crosstap', assumes you can establish an ssh
+ SystemTap, which uses ``crosstap``, assumes you can establish an SSH
connection to the remote target. Please refer to the crosstap wiki
- page for details on verifying ssh connections at
- . Also, the ability to ssh into the target system is not enabled by
- default in \*-minimal images.
+ page for details on verifying SSH connections. Also, the ability to SSH
+ into the target system is not enabled by default in ``*-minimal`` images.
-So essentially what you need to
-do is build an SDK image or image with 'tools-profile' as detailed in
-the ":ref:`profile-manual/intro:General Setup`" section of this
-manual, and boot the resulting target image.
+Therefore, what you need to do is build an SDK image or image with
+``tools-profile`` as detailed in the ":ref:`profile-manual/intro:General Setup`"
+section of this manual, and boot the resulting target image.
.. note::
If you have a :term:`Build Directory` containing multiple machines, you need
- to have the :term:`MACHINE` you're connecting to selected in local.conf, and
+ to have the :term:`MACHINE` you're connecting to selected in ``local.conf``, and
the kernel in that machine's :term:`Build Directory` must match the kernel on
- the booted system exactly, or you'll get the above 'crosstap' message
- when you try to invoke a script.
+ the booted system exactly, or you'll get the above ``crosstap`` message
+ when you try to call a script.
Running a Script on a Target
----------------------------
-Once you've done that, you should be able to run a systemtap script on
+Once you've done that, you should be able to run a SystemTap script on
the target::
$ cd /path/to/yocto
@@ -1922,8 +1924,8 @@
You can also run generated QEMU images with a command like 'runqemu qemux86-64'
-Once you've done that, you can cd to whatever
-directory contains your scripts and use 'crosstap' to run the script::
+Once you've done that, you can ``cd`` to whatever
+directory contains your scripts and use ``crosstap`` to run the script::
$ cd /path/to/my/systemap/script
$ crosstap root@192.168.7.2 trace_open.stp
@@ -1933,13 +1935,12 @@
$ crosstap root@192.168.7.2 trace_open.stp
error establishing ssh connection on remote 'root@192.168.7.2'
-Try ssh'ing to the target and see what happens::
+Try connecting to the target through SSH and see what happens::
$ ssh root@192.168.7.2
-A lot of the time, connection
-problems are due specifying a wrong IP address or having a 'host key
-verification error'.
+Connection problems are often due specifying a wrong IP address or having a ``host key
+verification error``.
If everything worked as planned, you should see something like this
(enter the password when prompted, or press enter if it's set up to use
@@ -1952,7 +1953,7 @@
matchbox-termin(1036) open ("/tmp/vte3FS2LW", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600)
matchbox-termin(1036) open ("/tmp/vteJMC7LW", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600)
-systemtap Documentation
+SystemTap Documentation
-----------------------
The SystemTap language reference can be found here: `SystemTap Language
@@ -1965,7 +1966,7 @@
Sysprof
=======
-Sysprof is a very easy to use system-wide profiler that consists of a
+Sysprof is an easy to use system-wide profiler that consists of a
single window with three panes and a few buttons which allow you to
start, stop, and view the profile from one place.
@@ -1975,18 +1976,18 @@
For this section, we'll assume you've already performed the basic setup
outlined in the ":ref:`profile-manual/intro:General Setup`" section.
-Sysprof is a GUI-based application that runs on the target system. For
-the rest of this document we assume you've ssh'ed to the host and will
-be running Sysprof on the target (you can use the '-X' option to ssh and
+Sysprof is a GUI-based application that runs on the target system. For the rest
+of this document we assume you're connected to the host through SSH and will be
+running Sysprof on the target (you can use the ``-X`` option to ``ssh`` and
have the Sysprof GUI run on the target but display remotely on the host
if you want).
Basic Sysprof Usage
-------------------
-To start profiling the system, you simply press the 'Start' button. To
+To start profiling the system, you just press the ``Start`` button. To
stop profiling and to start viewing the profile data in one easy step,
-press the 'Profile' button.
+press the ``Profile`` button.
Once you've pressed the profile button, the three panes will fill up
with profiling data:
@@ -1998,11 +1999,11 @@
The left pane shows a list of functions and processes. Selecting one of
those expands that function in the right pane, showing all its callees.
Note that this caller-oriented display is essentially the inverse of
-perf's default callee-oriented callchain display.
+perf's default callee-oriented call chain display.
In the screenshot above, we're focusing on ``__copy_to_user_ll()`` and
-looking up the callchain we can see that one of the callers of
-``__copy_to_user_ll`` is sys_read() and the complete callpath between them.
+looking up the call chain we can see that one of the callers of
+``__copy_to_user_ll`` is ``sys_read()`` and the complete call path between them.
Notice that this is essentially a portion of the same information we saw
in the perf display shown in the perf section of this page.
@@ -2011,7 +2012,7 @@
:width: 70%
Similarly, the above is a snapshot of the Sysprof display of a
-copy-from-user callchain.
+``copy-from-user`` call chain.
Finally, looking at the third Sysprof pane in the lower left, we can see
a list of all the callers of a particular function selected in the top
@@ -2027,18 +2028,17 @@
.. admonition:: Tying it Together
- If you like sysprof's 'caller-oriented' display, you may be able to
- approximate it in other tools as well. For example, 'perf report' has
- the -g (--call-graph) option that you can experiment with; one of the
- options is 'caller' for an inverted caller-based callgraph display.
+ If you like Sysprof's ``caller-oriented`` display, you may be able to
+ approximate it in other tools as well. For example, ``perf report`` has
+ the ``-g`` (``--call-graph``) option that you can experiment with; one of the
+ options is ``caller`` for an inverted caller-based call graph display.
Sysprof Documentation
---------------------
There doesn't seem to be any documentation for Sysprof, but maybe that's
-because it's pretty self-explanatory. The Sysprof website, however, is
-here: `Sysprof, System-wide Performance Profiler for
-Linux <http://sysprof.com/>`__
+because it's pretty self-explanatory. The Sysprof website, however, is here:
+`Sysprof, System-wide Performance Profiler for Linux <http://sysprof.com/>`__
LTTng (Linux Trace Toolkit, next generation)
============================================
@@ -2048,20 +2048,20 @@
For this section, we'll assume you've already performed the basic setup
outlined in the ":ref:`profile-manual/intro:General Setup`" section.
-LTTng is run on the target system by ssh'ing to it.
+LTTng is run on the target system by connecting to it through SSH.
Collecting and Viewing Traces
-----------------------------
Once you've applied the above commits and built and booted your image
-(you need to build the core-image-sato-sdk image or use one of the other
+(you need to build the ``core-image-sato-sdk`` image or use one of the other
methods described in the ":ref:`profile-manual/intro:General Setup`" section), you're ready to start
tracing.
Collecting and viewing a trace on the target (inside a shell)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-First, from the host, ssh to the target::
+First, from the host, connect to the target through SSH::
$ ssh -l root 192.168.1.47
The authenticity of host '192.168.1.47 (192.168.1.47)' can't be established.
@@ -2139,30 +2139,30 @@
You can now safely destroy the trace
session (note that this doesn't delete the trace --- it's still there in
-~/lttng-traces)::
+``~/lttng-traces``)::
root@crownbay:~# lttng destroy
Session auto-20121015-232120 destroyed at /home/root
Note that the trace is saved in a directory of the same name as returned by
-'lttng create', under the ~/lttng-traces directory (note that you can change this by
-supplying your own name to 'lttng create')::
+``lttng create``, under the ``~/lttng-traces`` directory (note that you can change this by
+supplying your own name to ``lttng create``)::
root@crownbay:~# ls -al ~/lttng-traces
drwxrwx--- 3 root root 1024 Oct 15 23:21 .
drwxr-xr-x 5 root root 1024 Oct 15 23:57 ..
drwxrwx--- 3 root root 1024 Oct 15 23:21 auto-20121015-232120
-Collecting and viewing a userspace trace on the target (inside a shell)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Collecting and viewing a user space trace on the target (inside a shell)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-For LTTng userspace tracing, you need to have a properly instrumented
-userspace program. For this example, we'll use the 'hello' test program
-generated by the lttng-ust build.
+For LTTng user space tracing, you need to have a properly instrumented
+user space program. For this example, we'll use the ``hello`` test program
+generated by the ``lttng-ust`` build.
-The 'hello' test program isn't installed on the root filesystem by the lttng-ust
-build, so we need to copy it over manually. First cd into the build
-directory that contains the hello executable::
+The ``hello`` test program isn't installed on the root filesystem by the ``lttng-ust``
+build, so we need to copy it over manually. First ``cd`` into the build
+directory that contains the ``hello`` executable::
$ cd build/tmp/work/core2_32-poky-linux/lttng-ust/2.0.5-r0/git/tests/hello/.libs
@@ -2170,10 +2170,10 @@
$ scp hello root@192.168.1.20:
-You now have the instrumented lttng 'hello world' test program on the
+You now have the instrumented LTTng "hello world" test program on the
target, ready to test.
-First, from the host, ssh to the target::
+First, from the host, connect to the target through SSH::
$ ssh -l root 192.168.1.47
The authenticity of host '192.168.1.47 (192.168.1.47)' can't be established.
@@ -2188,7 +2188,7 @@
Session auto-20190303-021943 created.
Traces will be written in /home/root/lttng-traces/auto-20190303-021943
-Enable the events you want to trace (in this case all userspace events)::
+Enable the events you want to trace (in this case all user space events)::
root@crownbay:~# lttng enable-event --userspace --all
All UST events are enabled in channel channel0
@@ -2198,7 +2198,7 @@
root@crownbay:~# lttng start
Tracing started for session auto-20190303-021943
-Run the instrumented hello world program::
+Run the instrumented "hello world" program::
root@crownbay:~# ./hello
Hello, World!
@@ -2222,7 +2222,7 @@
.
You can now safely destroy the trace session (note that this doesn't delete the
-trace --- it's still there in ~/lttng-traces)::
+trace --- it's still there in ``~/lttng-traces``)::
root@crownbay:~# lttng destroy
Session auto-20190303-021943 destroyed at /home/root
@@ -2260,27 +2260,27 @@
blktrace in 'listen' mode on the target and have blktrace and blkparse
collect and analyze the data on the host (see the
":ref:`profile-manual/usage:Using blktrace Remotely`" section
-below). For the rest of this section we assume you've ssh'ed to the host and
-will be running blkrace on the target.
+below). For the rest of this section we assume you've to the host through SSH
+and will be running blktrace on the target.
Basic blktrace Usage
--------------------
-To record a trace, simply run the 'blktrace' command, giving it the name
+To record a trace, just run the ``blktrace`` command, giving it the name
of the block device you want to trace activity on::
root@crownbay:~# blktrace /dev/sdc
-In another shell, execute a workload you want to trace. ::
+In another shell, execute a workload you want to trace::
root@crownbay:/media/sdc# rm linux-2.6.19.2.tar.bz2; wget &YOCTO_DL_URL;/mirror/sources/linux-2.6.19.2.tar.bz2; sync
Connecting to downloads.yoctoproject.org (140.211.169.59:80)
linux-2.6.19.2.tar.b 100% \|*******************************\| 41727k 0:00:00 ETA
-Press Ctrl-C in the blktrace shell to stop the trace. It
+Press ``Ctrl-C`` in the blktrace shell to stop the trace. It
will display how many events were logged, along with the per-cpu file
-sizes (blktrace records traces in per-cpu kernel buffers and simply
-dumps them to userspace for blkparse to merge and sort later). ::
+sizes (blktrace records traces in per-cpu kernel buffers and just
+dumps them to user space for blkparse to merge and sort later)::
^C=== sdc ===
CPU 0: 7082 events, 332 KiB data
@@ -2296,7 +2296,7 @@
-rw-r--r-- 1 root root 339938 Oct 27 22:40 sdc.blktrace.0
-rw-r--r-- 1 root root 75753 Oct 27 22:40 sdc.blktrace.1
-To view the trace events, simply invoke 'blkparse' in the directory
+To view the trace events, just call ``blkparse`` in the directory
containing the trace files, giving it the device name that forms the
first part of the filenames::
@@ -2388,15 +2388,15 @@
The report shows each event that was
found in the blktrace data, along with a summary of the overall block
I/O traffic during the run. You can look at the
-`blkparse <https://linux.die.net/man/1/blkparse>`__ manpage to learn the
+`blkparse <https://linux.die.net/man/1/blkparse>`__ manual page to learn the
meaning of each field displayed in the trace listing.
Live Mode
~~~~~~~~~
blktrace and blkparse are designed from the ground up to be able to
-operate together in a 'pipe mode' where the stdout of blktrace can be
-fed directly into the stdin of blkparse::
+operate together in a "pipe mode" where the standard output of blktrace can be
+fed directly into the standard input of blkparse::
root@crownbay:~# blktrace /dev/sdc -o - | blkparse -i -
@@ -2441,13 +2441,13 @@
server: connection from 192.168.1.43
-In another shell, execute a workload you want to trace. ::
+In another shell, execute a workload you want to trace::
root@crownbay:/media/sdc# rm linux-2.6.19.2.tar.bz2; wget &YOCTO_DL_URL;/mirror/sources/linux-2.6.19.2.tar.bz2; sync
Connecting to downloads.yoctoproject.org (140.211.169.59:80)
linux-2.6.19.2.tar.b 100% \|*******************************\| 41727k 0:00:00 ETA
-When it's done, do a Ctrl-C on the target system to stop the
+When it's done, do a ``Ctrl-C`` on the target system to stop the
trace::
^C=== sdc ===
@@ -2465,14 +2465,14 @@
Total: 11800 events (dropped 0), 554 KiB data
The blktrace instance on the host will
-save the target output inside a hostname-timestamp directory::
+save the target output inside a ``<hostname>-<timestamp>`` directory::
$ ls -al
drwxr-xr-x 10 root root 1024 Oct 28 02:40 .
drwxr-sr-x 4 root root 1024 Oct 26 18:24 ..
drwxr-xr-x 2 root root 1024 Oct 28 02:40 192.168.1.43-2012-10-28-02:40:56
-cd into that directory to see the output files::
+``cd`` into that directory to see the output files::
$ ls -l
-rw-r--r-- 1 root root 369193 Oct 28 02:44 sdc.blktrace.0
@@ -2537,16 +2537,16 @@
It's also possible to trace block I/O using only
:ref:`profile-manual/usage:The 'trace events' Subsystem`, which
can be useful for casual tracing if you don't want to bother dealing with the
-userspace tools.
+user space tools.
-To enable tracing for a given device, use /sys/block/xxx/trace/enable,
-where xxx is the device name. This for example enables tracing for
-/dev/sdc::
+To enable tracing for a given device, use ``/sys/block/xxx/trace/enable``,
+where ``xxx`` is the device name. This for example enables tracing for
+``/dev/sdc``::
root@crownbay:/sys/kernel/debug/tracing# echo 1 > /sys/block/sdc/trace/enable
Once you've selected the device(s) you want
-to trace, selecting the 'blk' tracer will turn the blk tracer on::
+to trace, selecting the ``blk`` tracer will turn the blk tracer on::
root@crownbay:/sys/kernel/debug/tracing# cat available_tracers
blk function_graph function nop
@@ -2557,7 +2557,7 @@
root@crownbay:/sys/kernel/debug/tracing# cat /media/sdc/testfile.txt
-And look at the output (note here that we're using 'trace_pipe' instead of
+And look at the output (note here that we're using ``trace_pipe`` instead of
trace to capture this trace --- this allows us to wait around on the pipe
for data to appear)::
@@ -2585,7 +2585,7 @@
blktrace Documentation
----------------------
-Online versions of the man pages for the commands discussed in this
+Online versions of the manual pages for the commands discussed in this
section can be found here:
- https://linux.die.net/man/8/blktrace
@@ -2594,8 +2594,8 @@
- https://linux.die.net/man/8/btrace
-The above manpages, along with manpages for the other blktrace utilities
-(btt, blkiomon, etc) can be found in the /doc directory of the blktrace
-tools git repo::
+The above manual pages, along with manuals for the other blktrace utilities
+(``btt``, ``blkiomon``, etc) can be found in the ``/doc`` directory of the blktrace
+tools git repository::
$ git clone git://git.kernel.dk/blktrace.git
diff --git a/poky/documentation/ref-manual/classes.rst b/poky/documentation/ref-manual/classes.rst
index 5aaf8ec..ab71cbe 100644
--- a/poky/documentation/ref-manual/classes.rst
+++ b/poky/documentation/ref-manual/classes.rst
@@ -421,7 +421,7 @@
``compress_doc``
================
-Enables compression for man pages and info pages. This class is intended
+Enables compression for manual and info pages. This class is intended
to be inherited globally. The default compression mechanism is gz (gzip)
but you can select an alternative mechanism by setting the
:term:`DOC_COMPRESS` variable.
@@ -1184,13 +1184,17 @@
``IMGCLASSES`` variable as follows::
IMGCLASSES = "rootfs_${IMAGE_PKGTYPE} image_types ${IMAGE_CLASSES}"
- IMGCLASSES += "${@['populate_sdk_base', 'populate_sdk_ext']['linux' in d.getVar("SDK_OS")]}"
+ # Only Linux SDKs support populate_sdk_ext, fall back to populate_sdk_base
+ # in the non-Linux SDK_OS case, such as mingw32
+ inherit populate_sdk_base
+ IMGCLASSES += "${@['', 'populate_sdk_ext']['linux' in d.getVar("SDK_OS")]}"
IMGCLASSES += "${@bb.utils.contains_any('IMAGE_FSTYPES', 'live iso hddimg', 'image-live', '', d)}"
IMGCLASSES += "${@bb.utils.contains('IMAGE_FSTYPES', 'container', 'image-container', '', d)}"
IMGCLASSES += "image_types_wic"
IMGCLASSES += "rootfs-postcommands"
IMGCLASSES += "image-postinst-intercepts"
- inherit ${IMGCLASSES}
+ IMGCLASSES += "overlayfs-etc"
+ inherit_defer ${IMGCLASSES}
The :ref:`ref-classes-image_types` class also handles conversion and compression of images.
diff --git a/poky/documentation/ref-manual/structure.rst b/poky/documentation/ref-manual/structure.rst
index acadd5e..e4d8b54 100644
--- a/poky/documentation/ref-manual/structure.rst
+++ b/poky/documentation/ref-manual/structure.rst
@@ -172,10 +172,11 @@
You can also run generated QEMU images with a command like 'runqemu qemux86-64'
The default output of the ``oe-init-build-env`` script is from the
-``conf-notes.txt`` file, which is found in the ``meta-poky`` directory
+``conf-summary.txt`` and ``conf-notes.txt`` files, which are found in the ``meta-poky`` directory
within the :term:`Source Directory`. If you design a
-custom distribution, you can include your own version of this
-configuration file to mention the targets defined by your distribution.
+custom distribution, you can include your own versions of these
+configuration files where you can provide a brief summary and detailed usage
+notes, such as a list of the targets defined by your distribution.
See the
":ref:`dev-manual/custom-template-configuration-directory:creating a custom template configuration directory`"
section in the Yocto Project Development Tasks Manual for more
diff --git a/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst
index 6e66dc7..435481c 100644
--- a/poky/documentation/ref-manual/variables.rst
+++ b/poky/documentation/ref-manual/variables.rst
@@ -2292,7 +2292,7 @@
:term:`DOC_COMPRESS`
When inheriting the :ref:`ref-classes-compress_doc`
class, this variable sets the compression policy used when the
- OpenEmbedded build system compresses man pages and info pages. By
+ OpenEmbedded build system compresses manual and info pages. By
default, the compression method used is gz (gzip). Other policies
available are xz and bz2.
@@ -7911,6 +7911,11 @@
image), compared to just using the :ref:`ref-classes-create-spdx` class
with no option.
+ :term:`SPDX_NAMESPACE_PREFIX`
+ This option could be used in order to change the prefix of ``spdxDocument``
+ and the prefix of ``documentNamespace``. It is set by default to
+ ``http://spdx.org/spdxdoc``.
+
:term:`SPDX_PRETTY`
This option makes the SPDX output more human-readable, using
identation and newlines, instead of the default output in a
diff --git a/poky/documentation/sdk-manual/extensible.rst b/poky/documentation/sdk-manual/extensible.rst
index 05dd527..3f6a754 100644
--- a/poky/documentation/sdk-manual/extensible.rst
+++ b/poky/documentation/sdk-manual/extensible.rst
@@ -76,7 +76,7 @@
$ bitbake meta-ide-support
$ bitbake -c populate_sysroot gtk+3
# or any other target or native item that the application developer would need
- $ bitbake build-sysroots
+ $ bitbake build-sysroots -c build_native_sysroot && bitbake build-sysroots -c build_target_sysroot
Setting up the Extensible SDK from a standalone installer
---------------------------------------------------------
@@ -1507,8 +1507,12 @@
is directly accessible to build additional items, and it
can simply be executed directly::
+ $ bitbake curl-native
+ # Add newly built native items to native sysroot
+ $ bitbake build-sysroots -c build_native_sysroot
$ bitbake mesa
- $ bitbake build-sysroots
+ # Add newly built target items to target sysroot
+ $ bitbake build-sysroots -c build_target_sysroot
When using a standalone installer for the Extensible SDK
--------------------------------------------------------
diff --git a/poky/documentation/standards.md b/poky/documentation/standards.md
index 9f4771e..e0c0cba 100644
--- a/poky/documentation/standards.md
+++ b/poky/documentation/standards.md
@@ -5,6 +5,21 @@
It is currently a work in progress.
+## Automatic style validation
+
+There is an ongoing effort to automate style validation
+through the [Vale](https://vale.sh/). To try it, run:
+
+ $ make stylecheck
+
+Note that this just applies to text. Therefore, the syntax
+conventions described below still apply.
+
+If you wish to add a new word to an "accept.txt" file
+(./styles/config/vocabularies/<Vocab>/accept.txt),
+make sure the spelling and capitalization matches
+what Wikipedia or the project defining this word uses.
+
## Text standards
### Bulleted lists
diff --git a/poky/documentation/styles/config/vocabularies/OpenSource/accept.txt b/poky/documentation/styles/config/vocabularies/OpenSource/accept.txt
new file mode 100644
index 0000000..e378fbf
--- /dev/null
+++ b/poky/documentation/styles/config/vocabularies/OpenSource/accept.txt
@@ -0,0 +1,20 @@
+autovivification
+blkparse
+blktrace
+callee
+debugfs
+ftrace
+KernelShark
+Kprobe
+LTTng
+perf
+profiler
+subcommand
+subnode
+superset
+Sysprof
+systemd
+toolchain
+tracepoint
+Uprobe
+wget
diff --git a/poky/documentation/styles/config/vocabularies/Yocto/accept.txt b/poky/documentation/styles/config/vocabularies/Yocto/accept.txt
new file mode 100644
index 0000000..ca622ba
--- /dev/null
+++ b/poky/documentation/styles/config/vocabularies/Yocto/accept.txt
@@ -0,0 +1,5 @@
+BitBake
+BSP
+crosstap
+OpenEmbedded
+Yocto