linux/poky.git/meta/classes/kernel.bbclass, branch yocto-4.0.29

kernel.bbclass: add original package name to RPROVIDES for -image and -base

2025-06-13T15:42:35+00:00

* -image and -base change PKG to: PKG:${KERNEL_PACKAGE_NAME}-image = "${KERNEL_PACKAGE_NAME}-image-${@legitimize_package_name(d.getVar(KERNEL_VERSION))}" PKG:${KERNEL_PACKAGE_NAME}-base = "${KERNEL_PACKAGE_NAME}-${@legitimize_package_name(d.getVar(KERNEL_VERSION))}" * but only when debian.bbclass is inheritted they add the original package name into RPROVIDES by: https://git.openembedded.org/openembedded-core/commit/?id=3409c4379559afbb1d1d29045582995147a33bbc * fixes the build if some packagegroup or something RDEPENDS on kernel-image or kernel-base and the DISTRO doesn't inherit debian.bbclass * as shown in pkgdata: linux-raspberrypi $ egrep "^(PKG:)|(RPRO)" 6.6.36+git-*/pkgdata/runtime/kernel-image 6.6.36+git-debian/pkgdata/runtime/kernel-image:RPROVIDES:kernel-image: kernel-image (=6.6.36+git@PRSERV_PV_AUTOINC@+733366844f_769634f344) 6.6.36+git-debian/pkgdata/runtime/kernel-image:PKG:kernel-image: kernel-image-6.6.36-v8 6.6.36+git-without-debian/pkgdata/runtime/kernel-image:PKG:kernel-image: kernel-image-6.6.36-v8 linux-raspberrypi $ egrep "^(PKG:)|(RPRO)" 6.6.36+git-*/pkgdata/runtime/kernel-image-image 6.6.36+git-debian/pkgdata/runtime/kernel-image-image:RPROVIDES:kernel-image-image: kernel-image-image (=6.6.36+git@PRSERV_PV_AUTOINC@+733366844f_769634f344) 6.6.36+git-debian/pkgdata/runtime/kernel-image-image:PKG:kernel-image-image: kernel-image-image-6.6.36-v8 6.6.36+git-without-debian/pkgdata/runtime/kernel-image-image:PKG:kernel-image-image: kernel-image-image-6.6.36-v8 (From OE-Core rev: 05498781657a3f8b38b000f91594ecd78850ce47) (From OE-Core rev: 350513959f6800eef6579153c2ae95960ca24ea7) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie (cherry picked from commit 9cb954884bc3905defa1ff533e668dea13e17cba) Signed-off-by: Jörg Sommer Signed-off-by: Steve Sakoman

kernel.bbclass: check, if directory exists before removing empty module directory

2024-05-15T16:44:16+00:00

If the kernel folder does not exist, find will result in an error. This can occur if the kernel has no modules but, for example, custom modules are created. Add check before deleting. (From OE-Core rev: 4e4681b26e0d88ad219d72b75e598e6b81b430fc) Signed-off-by: Heiko Thole Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie (cherry picked from commit 7ef767d84d56b25498e45db83bb8f9d9caebeaf9) Signed-off-by: Steve Sakoman

kernel.bbclass: Set pkg-config variables for building modules

2024-03-07T18:32:54+00:00

[Backport cd2072e5d953 from the master without HOSTPKG_CONFIG setting] The pkg-config workaround has been applied for kernel image building, but not for module building. So pkg-config variables are different between do_compile and do_compile_kernelmodules tasks. It may unnecessary trigger rebuilding of a few host tools at the later task. Especially when CONFIG_DEBUG_INFO_BTF is enabled in the kernel, it may even trigger rebuilding vmlinux at do_compile_kernelmodules due to the rebuilt host tools such as certs/extract-cert or objtool (on x86). This eventually creates an inconsistent set of kernel binaries. Here is the repro steps: - Check out nanbield on x86 - The unexpected rebuild happens on kirkstone or possibly earlier - Ensure that pahole is available (e.g. via meta-oe) - Set KERNEL_DEBUG to "True" to properly set up PAHOLE e.g. $ export KERNEL_DEBUG="True" $ export BB_ENV_PASSTHROUGH_ADDITIONS="${BB_ENV_PASSTHROUGH_ADDITIONS} KERNEL_DEBUG" - Enable CONFIG_DEBUG_INFO_BTF=y e.g. $ bitbake -c menuconfig virtual/kernel -> Kernel hacking -> Compile-time checks and compiler options -> Generate BTF typeinfo - Build the kernel e.g. $ bitbake virtual/kernel The BTF information in the resulting bzImage and kernel modules are inconsistent, because the module's BTF information is generated using the "second" vmlinux that doesn't have the identical BTF to the "first" vmlinux. These modules can't be loaded at runtime due to the BTF mismatch. This also leads to a build-id mismatch between the installed bzImage and vmlinux since the bzImage is created from the first vmlinux, but the installed vmlinux is the second one. $ eu-readelf -n tmp/work/qemux86_64-poky-linux/linux-yocto/6.5.13+git/image/boot/{bzImage*,vmlinux*} | grep "Build ID" Build ID: 4a0d62ee7fef0244950f0f604253729875bea493 Build ID: fb99b3d91399dbe42bf67ddee59e0f5a0c7f74d9 To avoid the unexpected rebuilding that results in such inconsistency, set the same pkg-config variables when building kernel and modules. For kernel 5.19 and above, simply set the HOSTPKG_CONFIG in the make command line. (From OE-Core rev: d63af11e92094487d6e358f27283e5385937e7a8) Signed-off-by: Munehisa Kamata Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

kernel: make LOCALVERSION consistent between recipes

2024-03-01T15:19:54+00:00

The initial fix for localversion setting in 6.3+ broke older recipes and also broke recipes setting localversion in a kernel recipe, as make-mod-scripts (and other locations) can trigger a regeneration of files and don't have access to the variable. Moving the setting of this variable to the global namespace doesn't make sense, so we follow the example of the kernel-abiversion and save a kernel-localversion to the build artifacts. Recipes that may regenerate scripts/dynamic files, must depend on the do_shared_workedir of the kernel and use the helper function to read the file storing the localversion. (From OE-Core rev: cca0971a7d92d823cc0c2b16cf14a7b2ed8ecb61) Signed-off-by: Bruce Ashfield Signed-off-by: Alexandre Belloni cherry-picked from master b378eec156998eea55ba61e59103cb34fab0d07c Signed-off-by: Andreas Helbech Kleist Acked-by: Ryan Eatmon Signed-off-by: Steve Sakoman

kernel: fix localversion in v6.3+

2024-03-01T15:19:54+00:00

During testing of the v6.4 reference kernel, it was noticed that on-target modules no longer matched the magic value of the running kernel. This was due to a different localversion in the cross built kernel and the scripts / resources created on target. This was due to changes in the setlocalversion script introduced in the v6.3 series. The .scmversion file is no longer used (or packaged) to inhibit the addition of a "+" (through querying of the git status of the kernel) or the setting of a local version. We recently introduced the KERNEL_LOCALVERSION variable to allow recipes to place a value in .scmversion, so we extend the use of that variable to kernel-arch.bbclass and use it to set the exported variable LOCALVERSION. We must do it at the kernel-arch level, as the variable must be exported in any kernel build to ensure that setlocalversion always correctly sets the localversion. (From OE-Core rev: 74897e505db19a23a5b864a48a4fa97d657605c8) Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie cherry-picked from master 765b13b7305c8d2f222cfc66d77c02e6a088c691 Signed-off-by: Andreas Helbech Kleist Signed-off-by: Steve Sakoman

kernel.bbclass: introduce KERNEL_LOCALVERSION

2024-03-01T15:19:54+00:00

Just like UBOOT_LOCALVERSION, an end user can set KERNEL_LOCALVERSION to append a string to the name of the local version of the kernel image. (From OE-Core rev: 29a0d2a49df8e24f3948a2ddf03743f0cb5d09dd) Signed-off-by: Ming Liu Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie cherry-picked from master 229435a52f36ddec5f85fb6d5ccd42044b688397 Signed-off-by: Andreas Helbech Kleist Signed-off-by: Steve Sakoman

Revert "kernel: fix localversion in v6.3+"

2024-02-16T01:49:52+00:00

This reverts commit d9273edae80978c34f8426f34f991b9598828aa9. This commit is causing breakage for some vendor kernel builds. (From OE-Core rev: 59cc2e75c15f8c6371a4c4a3b7bd2e6c3f145fbc) Signed-off-by: Steve Sakoman

kernel: fix localversion in v6.3+

2024-02-15T13:51:57+00:00

During testing of the v6.4 reference kernel, it was noticed that on-target modules no longer matched the magic value of the running kernel. This was due to a different localversion in the cross built kernel and the scripts / resources created on target. This was due to changes in the setlocalversion script introduced in the v6.3 series. The .scmversion file is no longer used (or packaged) to inhibit the addition of a "+" (through querying of the git status of the kernel) or the setting of a local version. We recently introduced the KERNEL_LOCALVERSION variable to allow recipes to place a value in .scmversion, so we extend the use of that variable to kernel-arch.bbclass and use it to set the exported variable LOCALVERSION. We must do it at the kernel-arch level, as the variable must be exported in any kernel build to ensure that setlocalversion always correctly sets the localversion. (From OE-Core rev: d9273edae80978c34f8426f34f991b9598828aa9) Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie Cherry-picked from master 765b13b7305c8d2f222cfc66d77c02e6a088c691 Signed-off-by: Andreas Helbech Kleist Signed-off-by: Steve Sakoman

kernel.bbclass: Add force flag to rm calls

2023-09-30T19:43:59+00:00

The latest 6.5 kernels do not appear to create the source file in ${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source so the recipe errors out when trying to remove it. Simple fix is to add the -f (force) flag to the call. (From OE-Core rev: 2e669bf797b15d803e7d6a700e449bdc467a4bcc) (From OE-Core rev: 7e177848f97eb9958619c28b5e5dadee12f67507) Signed-off-by: Ryan Eatmon Signed-off-by: Richard Purdie Signed-off-by: Alexander Sverdlin Signed-off-by: Steve Sakoman

kernel: Fix path comparison in kernel staging dir symlinking

2023-08-26T14:24:02+00:00

Due to an oversight in the do_symlink_kernsrc function, the path comparison between "S" and "STAGING_KERNEL_DIR" is broken. The code obtains both variables, but modifies the local copy of "S" before comparing them, causing the comparison to always return false. This can cause the build to fail when the EXTERNALSRC flag is enabled, since the code will try to create a symlink even if one already exists. This patch resolves the issue by comparing the variables before they are modified. (From OE-Core rev: cf2267f80ec44b24c627347df7efbd492a07dcfa) Signed-off-by: Staffan Rydén Signed-off-by: Alexandre Belloni (cherry picked from commit afd2038ef8a66a5e6433be31a14e1eb0d9f9a1d3) Signed-off-by: Steve Sakoman