Correction KERNEL_PACKAGE_NAME KERNEL_ARTIFACT_NAME
Are set in the multiconfig files. On Sun, Jul 12, 2026, 5:57 PM Vincent Davis Jr via lists.openembedded.org <[email protected]> wrote: > To explain why anyone would ever want two or more different types of > kernels on a single partition. > > Let's say a company requires you keep swupdate on a separate rootfs from > normal operation apps. You'd have to create 2 separate DISTRO's to define > separate kernel per DISTRO. Making it harder to place both rootfs > (kernel+initramfs is really what I mean) in the same wic. > > If you can build multiple different kernels + initramfs in the same DISTRO > you avoid the problem entirely. > > Can create a repo with mockup ideal of what I'm trying to achieve. If need > be. > > On Sun, Jul 12, 2026, 5:38 PM Vincent Davis Jr via lists.openembedded.org > <[email protected]> wrote: > >> Hey, >> >> There are 2 use cases the first being if the caller simply wants to >> change KERNEL_PACKAGE_NAME in their distro. They'll run into the runtime >> error described in patch description. This can be tested by just changing >> the name in the kernel.bbclass. >> >> The second being if you want to build 2 or more kernels with different >> initramfs contained in each kernel using one DISTRO. >> >> You'd have to define >> >> 1. Multiple kernel recipes with variables bellow so not to name mangle >> >> INITRAMFS_IMAGE_BUNDLE = "1" >> >> INITRAMFS_IMAGE = "<recipe name>" >> INITRAMFS_IMAGE_NAME = "<recipe image name>" >> >> KERNEL_PACKAGE_NAME = "<pkn>" >> KERNEL_ARTIFACT_NAME = "<artifact name>" >> >> 2. Multiple multiconfigs that have different >> >> PREFFERRED_PROVIDER_virtual/kernel >> >> Of course assigned to the different kernels. >> >> 3. Wic image or image recipes that pull in all the kernels >> >> do_rootfs[depends] += "\ >> virtual/kernel:do_bundle_initramfs \ >> virtual/kernel:do_deploy" >> >> do_rootfs[mcdepends] += "\ >> mc:from_distro:to_distro:virtual/kernel:do_bundle_initramfs \ >> mc:from_distro:to_distro:virtual/kernel:do_deploy" >> >> This patch series gives us the best opportunity for the cases above >> without brittle special cases. If you don't replace each kernel- prefix >> with a variable you end up with build time errors. >> >> Can update the description to explain use cases and why this change is >> needed, but are the above statements okay with you before I submit more >> patches? Or do we need to work out more of a justification for the patch >> series? >> >> On Sun, Jul 12, 2026, 4:40 PM Bruce Ashfield <[email protected]> >> wrote: >> >>> On Sun, Jul 12, 2026 at 2:43 PM Vincent Davis Jr via >>> lists.openembedded.org <[email protected]> >>> wrote: >>> > >>> > A number of recipes rely on hard coded >>> > kernel prefix set by KERNEL_PACKAGE_NAME >>> > when including modules. This leads to build >>> > time failures such as. >>> > >>> > ERROR: Nothing RPROVIDES 'kernel-module-*' >>> > >>> > Commit globally defines variable so that >>> > recipes aren't reliant on hardcoded 'kernel' >>> > prefix. >>> > >>> > Commit also updates variables >>> > >>> > STAGING_KERNEL_DIR >>> > STAGING_KERNEL_BUILDDIR >>> > >>> > STAGING_KERNEL_DIR and STAGING_KERNEL_BUILDDIR get >>> > changed from default defined in bitbake.conf in >>> > the kernel.bbclass. The reason was to set these >>> > variables to directories under WORKDIR in alternate >>> > kernel recipes (I.e. where KERNEL_PACKAGE_NAME != kernel) >>> > so that they may build in parallel with the default >>> > kernel without clobbering. The issue is that the variables >>> > only get changed in kernel recipes. So, other recipes >>> > such as perf and make-mod-scripts don't know the >>> > location of virtual/kernel WORKDIR. >>> > >>> > Solution is to include KERNEL_PACKAGE_NAME in >>> > STAGING_KERNEL_DIR and STAGING_KERNEL_BUILDDIR >>> > so recipes like perf and make-mod-scripts can >>> > find virtual/kernel source and solve the >>> > clobbering of build artifacts issue. >>> >>> These descriptions cover what you've changed, and >>> how they are cooredinated .. but you haven't explained *why* >>> >>> What problem does this solve? This introduces >>> complexity throughout the code base, so there has to be an >>> appropriately significant use case to justify it. >>> >>> and "We are changing the kernel package name" is not a sufficient >>> justification. >>> a reason, that is obviously something you are doing. >>> >>> Bruce >>> >>> > >>> > Signed-off-by: Vincent Davis Jr <[email protected]> >>> > --- >>> > meta/conf/bitbake.conf | 7 +++++-- >>> > 1 file changed, 5 insertions(+), 2 deletions(-) >>> > >>> > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf >>> > index bdf37d0da2..569b83a138 100644 >>> > --- a/meta/conf/bitbake.conf >>> > +++ b/meta/conf/bitbake.conf >>> > @@ -479,6 +479,9 @@ SDKPATHINSTALL = >>> "/usr/local/${SDK_NAME_PREFIX}-${SDK_ARCH}" >>> > # Kernel info. >>> > ################################################################## >>> > >>> > +# Globally define base string for kernel packages >>> > +KERNEL_PACKAGE_NAME ??= "kernel" >>> > + >>> > OLDEST_KERNEL = "5.15" >>> > >>> > # SDK_OLDEST_KERNEL can't be set using overrides since there are >>> > @@ -490,8 +493,8 @@ SDK_OLDEST_KERNEL = "3.2.0" >>> > # they are staged. >>> > KERNEL_SRC_PATH = "/usr/src/kernel" >>> > >>> > -STAGING_KERNEL_DIR = "${TMPDIR}/work-shared/${MACHINE}/kernel-source" >>> > -STAGING_KERNEL_BUILDDIR = >>> "${TMPDIR}/work-shared/${MACHINE}/kernel-build-artifacts" >>> > +STAGING_KERNEL_DIR = >>> "${TMPDIR}/work-shared/${MACHINE}/${KERNEL_PACKAGE_NAME}/kernel-source" >>> > +STAGING_KERNEL_BUILDDIR = >>> "${TMPDIR}/work-shared/${MACHINE}/${KERNEL_PACKAGE_NAME}/kernel-build-artifacts" >>> > >>> > ################################################################## >>> > # Specific image creation and rootfs population info. >>> > -- >>> > 2.43.0 >>> > >>> > >>> > >>> > >>> >>> >>> -- >>> - Thou shalt not follow the NULL pointer, for chaos and madness await >>> thee at its end >>> - "Use the force Harry" - Gandalf, Star Trek II >>> >> >> >> >> > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#240821): https://lists.openembedded.org/g/openembedded-core/message/240821 Mute This Topic: https://lists.openembedded.org/mt/120238087/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
