linux/poky.git/meta/recipes-kernel/perf, branch master-next

debug_build.inc: collect debug build tuning configuration

2025-11-07T13:15:35+00:00

The modern compilers and code seem to require extra steps to avoid DEBUG errors, Move debug tuning configuration from recipes to an include file to address these errors. Drop `:remove' operation on variable, override variables directly Suggested-by: Peter Kjellerstedt (From OE-Core rev: 05c0f9caab3e76f2dfdaebba2fbd6c036f9737c5) Signed-off-by: Hongxu Jia Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

perf: Tweak reproducibility fix

2025-10-16T09:53:10+00:00

Instead of building libperf.a, we should run install_headers as with the other libraries. Hopefully this resolves the remaining race issue around headers. (From OE-Core rev: 647589fab1fb73a985cbba4c1bec2004831508ca) Signed-off-by: Richard Purdie

perf: Bump versions to resolve hashequiv/reproducibility issues

2025-10-15T16:15:46+00:00

(From OE-Core rev: 39ae9a1061fcfe8c30df511b6f00e407b80ffc4c) Signed-off-by: Richard Purdie

perf: Improve build race/reproducibulity fixes

2025-10-13T17:01:03+00:00

The include options shouldn't be needed with the make fix but issues still remained. Looking at the logs, it looks like these are from other header directories and we need to run "make install_headers" for all of the sub components before starting the main build. Update the workaround to do that for each component with internal header copies. (From OE-Core rev: 0b5f0a7b1db9f6923c027719181fa60f8fdb73e4) Signed-off-by: Richard Purdie

perf: fix reproducibility issue occasionally

2025-09-24T10:06:42+00:00

Due to commit [1] applied in kernel v6.16 (such as qemux86-64), perl has reproducibility issue occasionally. Perf's build process generates two copies of its internal headers, one at tools/lib/perf/include/internal and one at libperf/include/internal with files like core.h. Although the files are identical, the binaries including them would see them at different paths and have different debuginfo data. [2] The reason is the order of include dir `tools/lib/perf/include' and `libperf/include' is not stable, such as $ x86_64-poky-linux-gcc ... \ -Ipath-to/tmp/work/qemux86_64-poky-linux/perf/1.0/sources/perf-1.0/tools/lib/perf/include \ -Ipath-to/tmp/work/qemux86_64-poky-linux/perf/1.0/sources/perf-1.0/libperf/include \ -c -o path-to/tmp/work/qemux86_64-poky-linux/perf/1.0/sources/perf-1.0/libperf/core.o core.c $ recipe-sysroot-native/usr/bin/dwarfsrcfiles sources/perf-1.0/libperf/core.o /usr/src/debug/perf/1.0/tools/lib/perf/core.c ... /usr/src/debug/perf/1.0/tools/lib/perf/include/perf/core.h /usr/src/debug/perf/1.0/tools/lib/perf/include/internal/lib.h ... $ x86_64-poky-linux-gcc ... \ -Ipath-to/tmp/work/qemux86_64-poky-linux/perf/1.0/sources/perf-1.0/libperf/include \ -Ipath-to/tmp/work/qemux86_64-poky-linux/perf/1.0/sources/perf-1.0/tools/lib/perf/include \ -c -o path-to/tmp/work/qemux86_64-poky-linux/perf/1.0/sources/perf-1.0/libperf/core.o core.c $ recipe-sysroot-native/usr/bin/dwarfsrcfiles sources/perf-1.0/libperf/core.o /usr/src/debug/perf/1.0/tools/lib/perf/core.c ... /usr/src/debug/perf/1.0/libperf/include/perf/core.h /usr/src/debug/perf/1.0/libperf/include/internal/lib.h ... This commit explicitly sets the order of these two include dirs in EXTRA_CFLAGS. This commit has no regression for kernel v6.6 (such as genericx86-64) Also enable verbose for compile to trace the detail of build [1] https://github.com/torvalds/linux/commit/f5b07010c13c77541e8ade167d05bef3b8a63739 [2] https://git.openembedded.org/openembedded-core/commit/?id=0a886fcacaab0fbce1306c0f99d482f940a8f705 (From OE-Core rev: e18d697e92b55e57124e80234369d46575226386) Signed-off-by: Hongxu Jia Signed-off-by: Richard Purdie

perf: Fix reproducibility issue

2025-09-12T09:30:53+00:00

Perf's build process generates two copies of its internal headers, one at tools/lib/perf/include/internal and one at libperf/include/internal with files like xyarray.h. Although the files are identical, the binaries including them would see them at different paths and have different debuginfo data. To avoid this, build libperf.a first, which will ensure the libperf headers directory exists. This is used in preference to the other by the build process and results in consistent binaries. (From OE-Core rev: 0a886fcacaab0fbce1306c0f99d482f940a8f705) Signed-off-by: Richard Purdie

perf: enable coresight if enabled in MACHINE_FEATURES

2025-09-08T17:02:39+00:00

Enable the CoreSight[1] functionality in perf[2] if 'coresight' is in the MACHINE_FEATURES. Note that enabling this will mean a dependency on the opencsd recipe, which is currently part of meta-arm[3]. I don't think this is a problem as this recipe is Arm-specific, and as this is a new feature the behaviour is opt-in so shouldn't break any existing machines. [1] https://docs.kernel.org/trace/coresight/coresight.html [2] https://docs.kernel.org/trace/coresight/coresight-perf.html [3] https://git.yoctoproject.org/meta-arm/tree/meta-arm/recipes-devtools/opencsd (From OE-Core rev: c455bd039104466b26a959a6495dbb5a642b4533) Signed-off-by: Ross Burton Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

kernelsrc/perf: clean up package version while using kernel source

2025-07-03T09:40:17+00:00

If recipe inherits bbclass kernelsrc to use kernel sources, the recipe should explicitly set ${KERNEL_VERSION} to ${PKGV} in task do_package, otherwise package version (${PV} is usually default 1.0) is not consistent with kernel source. For example, there are 5 recipes in meta-openembedded to inherit kernelsrc, but 4 recipes explicitly set PKGV. meta-openembedded$ grep -e "setVar(.*PKGV.*KERNEL_VERSION" -e kernelsrc -rn * meta-oe/recipes-kernel/intel-speed-select/intel-speed-select.bb:9:inherit kernelsrc meta-oe/recipes-kernel/bpftool/bpftool.bb:8:inherit bash-completion kernelsrc kernel-arch meta-oe/recipes-kernel/bpftool/bpftool.bb:44: d.setVar('PKGV', d.getVar("KERNEL_VERSION").split("-")[0]) meta-oe/recipes-kernel/cpupower/cpupower.bb:8:inherit kernelsrc kernel-arch bash-completion meta-oe/recipes-kernel/cpupower/cpupower.bb:32: d.setVar('PKGV', d.getVar("KERNEL_VERSION").split("-")[0]) meta-oe/recipes-kernel/turbostat/turbostat.bb:98: d.setVar('PKGV', d.getVar("KERNEL_VERSION").split("-")[0]) meta-oe/recipes-kernel/usbip-tools/usbip-tools.bb:25:inherit kernelsrc autotools-brokensep meta-oe/recipes-kernel/usbip-tools/usbip-tools.bb:68: d.setVar('PKGV', d.getVar("KERNEL_VERSION").split("-")[0]) meta-oe/recipes-kernel/spidev-test/spidev-test.bb:7:inherit bash-completion kernelsrc kernel-arch meta-oe/recipes-kernel/spidev-test/spidev-test.bb:26: d.setVar('PKGV', d.getVar("KERNEL_VERSION").split("-")[0]) This commit clean up the setting of PKGV, move it to kernelsrc.bbclass for common use, the recipe (such as intel-speed-select) that inherited kernelsrc will not be required to explicitly set ${PKGV} with ${KERNEL_VERSION} (From OE-Core rev: 77a93e8cf1da4231341c56f64f9d4d474f9f2bb7) Signed-off-by: Hongxu Jia Signed-off-by: Richard Purdie

meta: remove consecutive blank lines

2025-06-20T11:07:27+00:00

Some of them were introduced by mass-removal of S = WORKDIR/git assignments; rather than try to fix up (or redo) just these, I've run this sed command over the whole tree: sed -i -z -E 's/([ \t\f\v\r]*\n){3,}/\n\n/g' `find . -name *.bb -o -name *.inc` The rationale is that more than one empty line is wasting vertical screen space, and does nothing for readability. (From OE-Core rev: cedc4ff7c9bcfb22a20e43e47f9759f4007a4f1a) Signed-off-by: Alexander Kanavin Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

meta: set S to be in UNPACKDIR in recipes that explicitly set S

2025-06-20T11:07:26+00:00

(From OE-Core rev: 7321cc17ae5483f17fe9cdffea7b62acd9d9c3a2) Signed-off-by: Alexander Kanavin Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie