Re: [PATCH 5/5] kernel: use architecture specific names for kernels

["'MOESSBAUER, Felix' via isar-users" <isar-users@googlegroups.com>]

On Thu, 2026-08-13 at 21:08 +0200, Jan Kiszka wrote:
> On 13.08.26 20:46, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> > On Thu, 2026-08-13 at 19:47 +0200, Jan Kiszka wrote:
> > > On 13.08.26 18:45, Felix Moessbauer wrote:
> > > > The kernel source packages are architecture specific. By that, we also
> > > > have to encode the architecture in the KERNEL_NAME, if that is not
> > > > already implicitly the case (e.g. when building a kernel for a specific
> > > > machine).
> > > > 
> > > > For the kernel recipes which are generic (like mainline and cip), we
> > > > simply extend the PN with -${DISTRO_ARCH}, so bitbake can find the
> > > > dependency and instanciate an architecture specific variant.
> > > > 
> > > > By that, we also need to adapt the default in test_per_kernel, which
> > > > explicitly builds the module for the kernel that corresponds to the
> > > > multiconfig target.
> > > > 
> > > > Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
> > > > ---
> > > >  RECIPE-API-CHANGELOG.md                        | 18 ++++++++++++++++++
> > > >  meta-isar/conf/machine/beagleplay.conf         |  2 +-
> > > >  meta-isar/conf/machine/de0-nano-soc.conf       |  2 +-
> > > >  meta-isar/conf/machine/hikey.conf              |  2 +-
> > > >  meta-isar/conf/machine/qemuamd64-cip.conf      |  2 +-
> > > >  meta-isar/conf/machine/sifive-fu540.conf       |  2 +-
> > > >  meta-isar/conf/machine/stm32mp15x.conf         |  2 +-
> > > >  .../linux/linux-cip_4.4.166-cip29.bb           |  2 ++
> > > >  .../linux/linux-mainline_6.12.85.bb            |  2 ++
> > > >  testsuite/citest.py                            |  2 +-
> > > >  10 files changed, 29 insertions(+), 7 deletions(-)
> > > > 
> > > > diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md
> > > > index 2db05169..c13a3b3f 100644
> > > > --- a/RECIPE-API-CHANGELOG.md
> > > > +++ b/RECIPE-API-CHANGELOG.md
> > > > @@ -1175,6 +1175,24 @@ DPKG_ARCH ?= "${DISTRO_ARCH}"
> > > >  
> > > >  Firmware packages are an exception because they are built for only one architecture.
> > > >  
> > > > +### Kernel source packages are architecture specific
> > > > +
> > > > +Kernel source packages have always contained architecture-specific content, but
> > > 
> > > See my comment on the cover letter: architecture or even
> > > machine-specific content.
> > 
> > This does not invalidate this statement. It just means there could be
> > even more differences. Anyways, just a cover letter ;)
> > 
> > > 
> > > > +this was not previously enforced. As a result, builds for multiple architectures
> > > > +could publish different source packages with the same name and version.
> > > > +
> > > > +Generic kernel recipes can append `${DISTRO_ARCH}` to `PN`, to provide the
> > > > +kernel for all architectures.
> > > > +
> > > > +```
> > > > +PN .= "-${DISTRO_ARCH}"
> > > > +```
> > > > +
> > > > +For a kernel built for only one target, the name may remain unchanged. When
> > > > +building multiple instances of a kernel selected by the same `KERNEL_NAME`, use
> > > > +`${DISTRO_ARCH}` in the name for architecture-specific kernels, or `${MACHINE}`
> > > > +for machine-specific kernels.
> > > > +
> > > 
> > > This is not written like a recipe API change. This way, it looks like
> > > something that belongs into the user manual, kernel section, as it
> > > provides guidance on how to model that special case. You need to
> > > explain, when this is now required while it was not before.
> > > 
> > > But I would rather suggest modelling that more transparently, via
> > > PROVIDES: The KERNEL_NAME should remain "mainline", e.g., and the
> > > recipes should PROVIDE that generic name while actually building
> > > "mainline-$DISTRO_ARCH".
> > 
> > And this is exactly what "option 2" from [1] proposes, which I tried
> > and which does not work for two reasons:
> > 
> > 1. on bitbake side, the provides and depends need to be fiddled through
> > the multiarch classes (-native), which I did not manage to implement.
> > For the kernel it worked, but not for the module recipes. It also gets
> > super messy on multiconfig builds with two different kernels (e.g. a
> > hardened one for the image and a "open" one for the installer).
> > 
> > 2. We need provides on the debian package names as well, but resolving
> > multiple provides in the dependency install stages (sbuild and rootfs
> > install) is tricky, as we already know from other tries in this
> > direction.
> 
> Let's better address the root cause: needless templating, rather than
> build-time config selection (provided we have no problems with native
> kbuild packages vs. configs).

Having it arch specific is required anyways as we have the arch-
specific build dependency to linux-image-
${KERNEL_NAME_PROVIDED}:${DISTRO_ARCH} for the kbuild target.

But AFAIK it does not necessarily be machine specific, if all needed
defconfigs are present in the image. However, currently we modify the
debian/isar/configure isar part to in inject the KERNEL_DEFCONFIG (in
dpkg_configure_kernel), which again binds the source package to a
DEFCONFIG.

To split this, we would have to move this sed-replace to the dpkg-
buildpackage / sbuild part and switch defconfigs based on pre-set build
profiles. That's tricky and even further diverges from how debian is
doing it.

I prefer a slight API break over over-complicated magics. Let's just
follow how Debian is doing it: encode your specifics into the package
name (source package, binary packages), controlled by the KERNEL_NAME.

If you know your kernel is only architecture specific, name it -
${DISTRO_ARCH}. If it is machine specific, name it -${MACHINE}.

Keep in mind, that just renaming the source package just shifts the
issue. Then we likely get conflicts on the binary packages.

Felix

> 
> Jan
> 
> -- 
> Siemens AG, Foundational Technologies
> Linux Expert Center

-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/isar-users/d9f8fb50a4df33e7ebf674a4a751bc55c6ab61f2.camel%40siemens.com.