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 (#240820): https://lists.openembedded.org/g/openembedded-core/message/240820 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]] -=-=-=-=-=-=-=-=-=-=-=-
