[PATCH 0/5] Fix single-name single-content rule for kernel packages

[PATCH 0/5] Fix single-name single-content rule for kernel packages

['Felix Moessbauer' via isar-users]

Similar to upstream Debian, our kernel source packages are architecture
specific. By that, we also have to encode the architecture (or machine)
in the name of the package. Otherwise existing packages might get
reused on rebuilds with other targets (or multiarch)

In isar, this has ever been modeled incorrectly (the kernels .dsc file
was arch=any despite being arch specific). This is easy to fix, but
also depending on the kernels was done incorrectly (a KERNEL_NAME =
mainline is not specific enough, as mainline on arm64 is technically a
different kernel (source package) than mainline on amd64.

Patch 5 carries the implementation of option (1) from [1].

[1] https://groups.google.com/g/isar-users/c/JmB2FuEXZBU/m/azKokFVsAwAJ

The series has been tested in -t cross, -t kernel CI.

Best regards,
Felix Moessbauer
Siemens AG

Felix Moessbauer (5):
  testsuite: make test_libc_dev_deploy KERNEL_NAME agnostic
  kernel: bind x86_64_defconfig to amd64 architecture instead of machine
  kernel: make source package architecture specific
  kernel: move common parts of linux-mainline to inc
  kernel: use architecture specific names for kernels

 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          |  5 ++-
 .../recipes-kernel/linux/linux-mainline.inc   | 45 +++++++++++++++++++
 .../linux/linux-mainline_6.12.85.bb           | 39 +---------------
 .../recipes-kernel/linux/linux-phy_6.12.85.bb |  2 +-
 meta/classes-recipe/linux-kernel.bbclass      |  3 +-
 .../linux-module/files/debian/control.tmpl    |  2 +-
 .../linux/files/debian/control.tmpl           | 10 ++---
 testsuite/citest.py                           | 23 +++++++---
 15 files changed, 100 insertions(+), 59 deletions(-)
 create mode 100644 meta-isar/recipes-kernel/linux/linux-mainline.inc

-- 
2.55.0

-- 
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/20260813164500.3092151-1-felix.moessbauer%40siemens.com.

[PATCH 1/5] testsuite: make test_libc_dev_deploy KERNEL_NAME agnostic

['Felix Moessbauer' via isar-users]

We currently hard-code the relation between these targets and the
expected recipes that are built. As a preparation to use target specific
kernel names, we generalize the test to read the actual KERNEL_NAME from
the bitbake vars.

Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
---
 testsuite/citest.py | 21 +++++++++++++++------
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/testsuite/citest.py b/testsuite/citest.py
index fc0c7106..b50b3bc0 100644
--- a/testsuite/citest.py
+++ b/testsuite/citest.py
@@ -636,6 +636,10 @@ class KernelTests(CIBaseTest):
 
     def test_libc_dev_deploy(self):
         """Test that the linux-libc-dev packages are deployed (parse only)."""
+        def kernel_recipe(target):
+            kernel_name = CIUtils.getVars('KERNEL_NAME', target=target)
+            return f'linux-{kernel_name}'
+
         targets = [
             'mc:hikey-bookworm:isar-image-ci',
             'mc:hikey-trixie:isar-image-ci'
@@ -646,23 +650,28 @@ class KernelTests(CIBaseTest):
         self.init()
         buildlist, _ = self.generate_dependency_graph(targets, lines=lines)
 
+        bookworm_kernel = kernel_recipe('mc:hikey-bookworm:isar-image-ci')
+        trixie_kernel = kernel_recipe('mc:hikey-trixie:isar-image-ci')
+
         with open(buildlist, 'r') as f:
             built = set(line.strip() for line in f if line.strip())
 
         # trixie produces arch=all linux-libc-dev packages, which are built by
         # the dedicated -libctarget variant.
         self.assertIn(
-            'mc:hikey-trixie:linux-mainline-libctarget', built,
-            "trixie: linux-mainline-libctarget (linux-libc-dev is not built)")
+            f'mc:hikey-trixie:{trixie_kernel}-libctarget', built,
+            f"trixie: {trixie_kernel}-libctarget "
+            "(linux-libc-dev is not built)")
 
         # bookworm produces an arch-specific linux-libc-dev, built by the base
         # recipe itself; no -libctarget variant is needed.
         self.assertIn(
-            'mc:hikey-bookworm:linux-mainline', built,
-            "bookworm: linux-mainline (linux-libc-dev is not built)")
+            f'mc:hikey-bookworm:{bookworm_kernel}', built,
+            f"bookworm: {bookworm_kernel} (linux-libc-dev is not built)")
         self.assertNotIn(
-            'mc:hikey-bookworm:linux-mainline-libctarget', built,
-            "bookworm: unexpected -libctarget variant is built")
+            f'mc:hikey-bookworm:{bookworm_kernel}-libctarget', built,
+            f"bookworm: unexpected {bookworm_kernel}-libctarget "
+            "variant is built")
 
         # The unrelated cip kernel must not be pulled in as libc-dev provider.
         for target in built:
-- 
2.55.0

-- 
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/20260813164500.3092151-2-felix.moessbauer%40siemens.com.

[PATCH 2/5] kernel: bind x86_64_defconfig to amd64 architecture instead of machine

['Felix Moessbauer' via isar-users]

This defconfig is a reasonable default for all amd64 machines. We now
make it the default for that architecture for linux-cip and
linux-mainline. Further, we only add it to the SRC_URI if actually
needed.

Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
---
 meta-isar/recipes-kernel/linux/linux-cip_4.4.166-cip29.bb | 3 ++-
 meta-isar/recipes-kernel/linux/linux-mainline_6.12.85.bb  | 4 ++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta-isar/recipes-kernel/linux/linux-cip_4.4.166-cip29.bb b/meta-isar/recipes-kernel/linux/linux-cip_4.4.166-cip29.bb
index 1f4d75bc..e2775c8d 100644
--- a/meta-isar/recipes-kernel/linux/linux-cip_4.4.166-cip29.bb
+++ b/meta-isar/recipes-kernel/linux/linux-cip_4.4.166-cip29.bb
@@ -13,4 +13,5 @@ SRC_URI += " \
 
 SRCREV = "af3adf9f9c633ac0e1d68487d7fad22285dda8a3"
 
-KERNEL_DEFCONFIG:qemuamd64-cip = "x86_64_defconfig"
+SRC_URI:append:amd64 = " file://${KERNEL_DEFCONFIG}"
+KERNEL_DEFCONFIG:amd64 = "x86_64_defconfig"
diff --git a/meta-isar/recipes-kernel/linux/linux-mainline_6.12.85.bb b/meta-isar/recipes-kernel/linux/linux-mainline_6.12.85.bb
index 10444680..786a9db8 100644
--- a/meta-isar/recipes-kernel/linux/linux-mainline_6.12.85.bb
+++ b/meta-isar/recipes-kernel/linux/linux-mainline_6.12.85.bb
@@ -11,7 +11,6 @@ ARCHIVE_VERSION = "${@ d.getVar('PV')[:-2] if d.getVar('PV').endswith('.0') else
 
 SRC_URI += " \
     https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-${ARCHIVE_VERSION}.tar.xz \
-    file://x86_64_defconfig \
     file://ftpm-module.cfg \
     file://subdir \
     file://no-root-nfs.cfg;apply=no"
@@ -20,7 +19,8 @@ SRC_URI[sha256sum] = "e35ac999f40a6874493d8d60f33f1150d7a89ae5841c428da82257fbcd
 
 S = "${WORKDIR}/linux-${ARCHIVE_VERSION}"
 
-KERNEL_DEFCONFIG:qemuamd64 = "x86_64_defconfig"
+SRC_URI:append:amd64 = " file://${KERNEL_DEFCONFIG}"
+KERNEL_DEFCONFIG:amd64 = "x86_64_defconfig"
 
 LINUX_VERSION_EXTENSION = "-isar"
 
-- 
2.55.0

-- 
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/20260813164500.3092151-3-felix.moessbauer%40siemens.com.

[PATCH 3/5] kernel: make source package architecture specific

['Felix Moessbauer' via isar-users]

Currently we mark our kernel source packages as Arch=any all, despite
the content of the package is architecture specific. Here, we make the
package architecture specific by avoiding any Arch=any identifier in the
control file. This results in having Architecture: ${DISTRO_ARCH} all in
the generated .dsc file. The same applies to the custom kernel modules.

A special case is the "linux-kbuild-${KERNEL_NAME_PROVIDED}-
${DISTRO_ARCH}-cross" package, which is specific to the BUILD_ARCH, as
it contains host tooling binaries for the host, which are derived from
the target specific kernel.

Ensuring that we do not generate multiple kernel packages with different
content but the same name (for multiple architectures) will be done in
later commits.

Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
---
 meta/classes-recipe/linux-kernel.bbclass               |  3 ++-
 .../linux-module/files/debian/control.tmpl             |  2 +-
 meta/recipes-kernel/linux/files/debian/control.tmpl    | 10 +++++-----
 3 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/meta/classes-recipe/linux-kernel.bbclass b/meta/classes-recipe/linux-kernel.bbclass
index ac587b17..74a49aa8 100644
--- a/meta/classes-recipe/linux-kernel.bbclass
+++ b/meta/classes-recipe/linux-kernel.bbclass
@@ -78,6 +78,7 @@ TEMPLATE_FILES += "                  \
 
 TEMPLATE_VARS += "                \
     BPN                           \
+    BUILD_ARCH                    \
     KBUILD_DEPENDS                \
     KERNEL_ARCH                   \
     KERNEL_DEBIAN_DEPENDS         \
@@ -274,7 +275,7 @@ def get_additional_build_profiles(d):
         profiles += ' pkg.{}.libcdev-arch-all'.format(d.getVar('BPN'))
     return profiles
 
-KERNEL_LIBC_DEV_ARCH = "${@ bb.utils.contains('DEB_BUILD_PROFILES', 'pkg.{}.libcdev-arch-all'.format(d.getVar('BPN')), 'all\nMulti-Arch: foreign', 'any', d) }"
+KERNEL_LIBC_DEV_ARCH = "${@ bb.utils.contains('DEB_BUILD_PROFILES', 'pkg.{}.libcdev-arch-all'.format(d.getVar('BPN')), 'all\nMulti-Arch: foreign', d.getVar('DISTRO_ARCH'), d) }"
 DEB_BUILD_PROFILES += "${@get_additional_build_profiles(d)}"
 
 do_prepare_build[cleandirs] += "${S}/debian"
diff --git a/meta/recipes-kernel/linux-module/files/debian/control.tmpl b/meta/recipes-kernel/linux-module/files/debian/control.tmpl
index d8f4aded..3c222979 100644
--- a/meta/recipes-kernel/linux-module/files/debian/control.tmpl
+++ b/meta/recipes-kernel/linux-module/files/debian/control.tmpl
@@ -7,6 +7,6 @@ Maintainer: ${MAINTAINER}
 Rules-Requires-Root: no
 
 Package: ${PN}
-Architecture: any
+Architecture: ${DISTRO_ARCH}
 Depends: ${KERNEL_IMAGE_PKG}, kmod
 Description: ${DESCRIPTION}
diff --git a/meta/recipes-kernel/linux/files/debian/control.tmpl b/meta/recipes-kernel/linux/files/debian/control.tmpl
index 77c4048b..f89a1f56 100644
--- a/meta/recipes-kernel/linux/files/debian/control.tmpl
+++ b/meta/recipes-kernel/linux/files/debian/control.tmpl
@@ -8,7 +8,7 @@ Rules-Requires-Root: no
 
 Package: linux-image-${KERNEL_NAME_PROVIDED}
 Build-Profiles: <pkg.${BPN}.kernel>
-Architecture: any
+Architecture: ${DISTRO_ARCH}
 Depends: ${KERNEL_DEBIAN_DEPENDS}
 Description: ${KERNEL_NAME_PROVIDED} Linux kernel, version @KR@
  This package contains the Linux kernel, modules and corresponding other
@@ -16,7 +16,7 @@ Description: ${KERNEL_NAME_PROVIDED} Linux kernel, version @KR@
 
 Package: linux-headers-${KERNEL_NAME_PROVIDED}
 Build-Profiles: <pkg.${BPN}.kernel>
-Architecture: any
+Architecture: ${DISTRO_ARCH}
 Depends: ${KERNEL_HEADERS_DEBIAN_DEPENDS}, ${perl:Depends}, ${shlibs:Depends}
 Description: ${KERNEL_NAME_PROVIDED} Linux kernel headers for @KR@
  This package provides kernel header files for @KR@ on ${DISTRO_ARCH}
@@ -47,14 +47,14 @@ Description: Linux Kernel Headers for development (for cross-compiling)
 Package: linux-image-${KERNEL_NAME_PROVIDED}-dbg
 Build-Profiles: <pkg.${BPN}.kernel>
 Section: debug
-Architecture: any
+Architecture: ${DISTRO_ARCH}
 Description: Linux kernel debugging symbols for @KR@
  This package will come in handy if you need to debug the kernel. It provides
  all the necessary debug symbols for the kernel and its modules.
 
 Package: linux-kbuild-${KERNEL_NAME_PROVIDED}
 Build-Profiles: <pkg.${BPN}.kbuild !pkg.${BPN}.cross>
-Architecture: any
+Architecture: ${DISTRO_ARCH}
 Depends: ${perl:Depends}, ${shlibs:Depends}
 Description: ${KERNEL_NAME_PROVIDED} Linux kbuild scripts and tools for @KR@
  This package provides kernel kbuild scripts and tools for @KR@
@@ -62,7 +62,7 @@ Description: ${KERNEL_NAME_PROVIDED} Linux kbuild scripts and tools for @KR@
 
 Package: linux-kbuild-${KERNEL_NAME_PROVIDED}-${DISTRO_ARCH}-cross
 Build-Profiles: <pkg.${BPN}.kbuild pkg.${BPN}.cross>
-Architecture: any
+Architecture: ${BUILD_ARCH}
 Multi-Arch: foreign
 Depends: ${perl:Depends}, ${shlibs:Depends}
 Conflicts: linux-kbuild-${KERNEL_NAME_PROVIDED}
-- 
2.55.0

-- 
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/20260813164500.3092151-4-felix.moessbauer%40siemens.com.

[PATCH 4/5] kernel: move common parts of linux-mainline to inc

['Felix Moessbauer' via isar-users]

As a preparation to provide linux-mainline for multiple targets, we move
the common parts (currently everything) to an .inc file and include that
in the kernel recipes.

No functional change.

Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com>
---
 .../recipes-kernel/linux/linux-mainline.inc   | 45 +++++++++++++++++++
 .../linux/linux-mainline_6.12.85.bb           | 39 +---------------
 .../recipes-kernel/linux/linux-phy_6.12.85.bb |  2 +-
 3 files changed, 47 insertions(+), 39 deletions(-)
 create mode 100644 meta-isar/recipes-kernel/linux/linux-mainline.inc

diff --git a/meta-isar/recipes-kernel/linux/linux-mainline.inc b/meta-isar/recipes-kernel/linux/linux-mainline.inc
new file mode 100644
index 00000000..d93c8e51
--- /dev/null
+++ b/meta-isar/recipes-kernel/linux/linux-mainline.inc
@@ -0,0 +1,45 @@
+# Example recipe for building the mainline kernel
+#
+# This software is a part of Isar.
+# Copyright (c) Siemens AG, 2026
+#
+# SPDX-License-Identifier: MIT
+
+inherit linux-kernel
+
+ARCHIVE_VERSION = "${@ d.getVar('PV')[:-2] if d.getVar('PV').endswith('.0') else d.getVar('PV') }"
+
+SRC_URI += " \
+    https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-${ARCHIVE_VERSION}.tar.xz \
+    file://ftpm-module.cfg \
+    file://subdir \
+    file://no-root-nfs.cfg;apply=no"
+
+SRC_URI[sha256sum] = "e35ac999f40a6874493d8d60f33f1150d7a89ae5841c428da82257fbcd070aed"
+
+S = "${WORKDIR}/linux-${ARCHIVE_VERSION}"
+
+SRC_URI:append:amd64 = " file://${KERNEL_DEFCONFIG}"
+KERNEL_DEFCONFIG:amd64 = "x86_64_defconfig"
+
+LINUX_VERSION_EXTENSION = "-isar"
+
+KERNEL_CONFIG_FRAGMENTS = "subdir/no-ubifs-fs.cfg"
+
+check_fragments_applied() {
+    grep -q "# CONFIG_MTD is not set" ${S}/debian/rules ||
+        cat << EOF | sed -i '/^override_dh_auto_build/ r /dev/stdin' ${S}/debian/rules
+	if ! grep "# CONFIG_MTD is not set" \$(O)/.config && \\
+	   ! grep "# CONFIG_MTD_UBI is not set" \$(O)/.config; then \\
+	    grep "# CONFIG_UBIFS_FS is not set" \$(O)/.config || \\
+	        (echo "Self-check failed: CONFIG_UBIFS_FS still enabled" && exit 1); \\
+	fi
+	grep "CONFIG_ROOT_NFS=y" \$(O)/.config || \\
+	    (echo "Self-check failed: CONFIG_ROOT_NFS not enabled" && exit 1)
+EOF
+}
+
+# For testing purposes only
+dpkg_configure_kernel:append() {
+    check_fragments_applied
+}
diff --git a/meta-isar/recipes-kernel/linux/linux-mainline_6.12.85.bb b/meta-isar/recipes-kernel/linux/linux-mainline_6.12.85.bb
index 786a9db8..11b90127 100644
--- a/meta-isar/recipes-kernel/linux/linux-mainline_6.12.85.bb
+++ b/meta-isar/recipes-kernel/linux/linux-mainline_6.12.85.bb
@@ -5,41 +5,4 @@
 #
 # SPDX-License-Identifier: MIT
 
-inherit linux-kernel
-
-ARCHIVE_VERSION = "${@ d.getVar('PV')[:-2] if d.getVar('PV').endswith('.0') else d.getVar('PV') }"
-
-SRC_URI += " \
-    https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-${ARCHIVE_VERSION}.tar.xz \
-    file://ftpm-module.cfg \
-    file://subdir \
-    file://no-root-nfs.cfg;apply=no"
-
-SRC_URI[sha256sum] = "e35ac999f40a6874493d8d60f33f1150d7a89ae5841c428da82257fbcd070aed"
-
-S = "${WORKDIR}/linux-${ARCHIVE_VERSION}"
-
-SRC_URI:append:amd64 = " file://${KERNEL_DEFCONFIG}"
-KERNEL_DEFCONFIG:amd64 = "x86_64_defconfig"
-
-LINUX_VERSION_EXTENSION = "-isar"
-
-KERNEL_CONFIG_FRAGMENTS = "subdir/no-ubifs-fs.cfg"
-
-check_fragments_applied() {
-    grep -q "# CONFIG_MTD is not set" ${S}/debian/rules ||
-        cat << EOF | sed -i '/^override_dh_auto_build/ r /dev/stdin' ${S}/debian/rules
-	if ! grep "# CONFIG_MTD is not set" \$(O)/.config && \\
-	   ! grep "# CONFIG_MTD_UBI is not set" \$(O)/.config; then \\
-	    grep "# CONFIG_UBIFS_FS is not set" \$(O)/.config || \\
-	        (echo "Self-check failed: CONFIG_UBIFS_FS still enabled" && exit 1); \\
-	fi
-	grep "CONFIG_ROOT_NFS=y" \$(O)/.config || \\
-	    (echo "Self-check failed: CONFIG_ROOT_NFS not enabled" && exit 1)
-EOF
-}
-
-# For testing purposes only
-dpkg_configure_kernel:append() {
-    check_fragments_applied
-}
+require recipes-kernel/linux/linux-mainline.inc
diff --git a/meta-isar/recipes-kernel/linux/linux-phy_6.12.85.bb b/meta-isar/recipes-kernel/linux/linux-phy_6.12.85.bb
index a61befe2..33265f6b 100644
--- a/meta-isar/recipes-kernel/linux/linux-phy_6.12.85.bb
+++ b/meta-isar/recipes-kernel/linux/linux-phy_6.12.85.bb
@@ -1,4 +1,4 @@
-require recipes-kernel/linux/linux-mainline_${PV}.bb
+require recipes-kernel/linux/linux-mainline.inc
 
 SRC_URI:remove = "file://ftpm-module.cfg"
 SRC_URI:remove = "file://subdir/no-ubifs-fs.cfg"
-- 
2.55.0

-- 
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/20260813164500.3092151-5-felix.moessbauer%40siemens.com.

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

['Felix Moessbauer' via isar-users]

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
+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.
+
 ### Add Hyper-V machine support
 
 A new machine `hyper-v` has been introduced for building images
diff --git a/meta-isar/conf/machine/beagleplay.conf b/meta-isar/conf/machine/beagleplay.conf
index d030256d..8cefd939 100644
--- a/meta-isar/conf/machine/beagleplay.conf
+++ b/meta-isar/conf/machine/beagleplay.conf
@@ -5,7 +5,7 @@
 
 DISTRO_ARCH ?= "arm64"
 
-KERNEL_NAME ?= "mainline"
+KERNEL_NAME ?= "mainline-${DISTRO_ARCH}"
 
 IMAGE_FSTYPES ?= "wic"
 WKS_FILE ?= "beagleplay.wks.in"
diff --git a/meta-isar/conf/machine/de0-nano-soc.conf b/meta-isar/conf/machine/de0-nano-soc.conf
index 78f841df..7059822a 100644
--- a/meta-isar/conf/machine/de0-nano-soc.conf
+++ b/meta-isar/conf/machine/de0-nano-soc.conf
@@ -5,7 +5,7 @@
 
 DISTRO_ARCH ?= "armhf"
 
-KERNEL_NAME ?= "mainline"
+KERNEL_NAME ?= "mainline-${DISTRO_ARCH}"
 
 U_BOOT_CONFIG:de0-nano-soc = "socfpga_de0_nano_soc_defconfig"
 U_BOOT_BIN:de0-nano-soc = "u-boot-with-spl.sfp"
diff --git a/meta-isar/conf/machine/hikey.conf b/meta-isar/conf/machine/hikey.conf
index 019e1910..1e696b4d 100644
--- a/meta-isar/conf/machine/hikey.conf
+++ b/meta-isar/conf/machine/hikey.conf
@@ -5,7 +5,7 @@
 
 DISTRO_ARCH = "arm64"
 
-KERNEL_NAME ?= "mainline"
+KERNEL_NAME ?= "mainline-${DISTRO_ARCH}"
 
 IMAGE_FSTYPES = "wic"
 WKS_FILE ?= "hikey"
diff --git a/meta-isar/conf/machine/qemuamd64-cip.conf b/meta-isar/conf/machine/qemuamd64-cip.conf
index e7eaa2d6..9d633362 100644
--- a/meta-isar/conf/machine/qemuamd64-cip.conf
+++ b/meta-isar/conf/machine/qemuamd64-cip.conf
@@ -5,4 +5,4 @@
 
 include conf/machine/qemuamd64.conf
 
-KERNEL_NAME = "cip"
+KERNEL_NAME = "cip-${DISTRO_ARCH}"
diff --git a/meta-isar/conf/machine/sifive-fu540.conf b/meta-isar/conf/machine/sifive-fu540.conf
index c9bbc57b..07846f99 100644
--- a/meta-isar/conf/machine/sifive-fu540.conf
+++ b/meta-isar/conf/machine/sifive-fu540.conf
@@ -5,7 +5,7 @@
 
 DISTRO_ARCH = "riscv64"
 
-KERNEL_NAME ?= "mainline"
+KERNEL_NAME ?= "mainline-${DISTRO_ARCH}"
 
 IMAGE_FSTYPES ?= "wic"
 WKS_FILE ?= "sifive-fu540"
diff --git a/meta-isar/conf/machine/stm32mp15x.conf b/meta-isar/conf/machine/stm32mp15x.conf
index 7aa410a5..aa453d8f 100644
--- a/meta-isar/conf/machine/stm32mp15x.conf
+++ b/meta-isar/conf/machine/stm32mp15x.conf
@@ -5,7 +5,7 @@
 
 DISTRO_ARCH ?= "armhf"
 
-KERNEL_NAME ?= "mainline"
+KERNEL_NAME ?= "mainline-${DISTRO_ARCH}"
 
 U_BOOT_CONFIG:stm32mp15x = "stm32mp15_trusted_defconfig"
 U_BOOT_BIN:stm32mp15x = "u-boot.stm32"
diff --git a/meta-isar/recipes-kernel/linux/linux-cip_4.4.166-cip29.bb b/meta-isar/recipes-kernel/linux/linux-cip_4.4.166-cip29.bb
index e2775c8d..bb196b5a 100644
--- a/meta-isar/recipes-kernel/linux/linux-cip_4.4.166-cip29.bb
+++ b/meta-isar/recipes-kernel/linux/linux-cip_4.4.166-cip29.bb
@@ -5,6 +5,8 @@
 #
 # SPDX-License-Identifier: MIT
 
+PN .= "-${DISTRO_ARCH}"
+
 inherit linux-kernel
 
 SRC_URI += " \
diff --git a/meta-isar/recipes-kernel/linux/linux-mainline_6.12.85.bb b/meta-isar/recipes-kernel/linux/linux-mainline_6.12.85.bb
index 11b90127..13c694b0 100644
--- a/meta-isar/recipes-kernel/linux/linux-mainline_6.12.85.bb
+++ b/meta-isar/recipes-kernel/linux/linux-mainline_6.12.85.bb
@@ -5,4 +5,6 @@
 #
 # SPDX-License-Identifier: MIT
 
+PN .= "-${DISTRO_ARCH}"
+
 require recipes-kernel/linux/linux-mainline.inc
diff --git a/testsuite/citest.py b/testsuite/citest.py
index b50b3bc0..a87e1160 100644
--- a/testsuite/citest.py
+++ b/testsuite/citest.py
@@ -623,7 +623,7 @@ class KernelTests(CIBaseTest):
         """Test per-kernel recipe variants for external kernel modules."""
 
         targets = ['mc:qemuarm64-bookworm:isar-image-ci']
-        kernel_names = self.params.get('kernel_names', default='mainline')
+        kernel_names = self.params.get('kernel_names', default='mainline-arm64')
         kernel_names = [k.strip() for k in kernel_names.split(',') if k.strip()]
         modules = [f"example-module-{k}" for k in kernel_names]
         modules.append('example-module-${KERNEL_NAME}')
-- 
2.55.0

-- 
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/20260813164500.3092151-6-felix.moessbauer%40siemens.com.

Re: [PATCH 0/5] Fix single-name single-content rule for kernel packages

['Jan Kiszka' via isar-users]

On 13.08.26 18:44, Felix Moessbauer wrote:
> Similar to upstream Debian, our kernel source packages are architecture
> specific. By that, we also have to encode the architecture (or machine)
> in the name of the package. Otherwise existing packages might get
> reused on rebuilds with other targets (or multiarch)
> 
> In isar, this has ever been modeled incorrectly (the kernels .dsc file
> was arch=any despite being arch specific). This is easy to fix, but
> also depending on the kernels was done incorrectly (a KERNEL_NAME =
> mainline is not specific enough, as mainline on arm64 is technically a
> different kernel (source package) than mainline on amd64.
> 

It is more complicated than this:

A source packages becomes architecture or even machine-specific if we
bundle the concretely built config file with it. If KERNEL_DEFCONFIG is
empty (default), a kernel source package is actually buildable for any
architecture, thus remains generic.

Now, if the user of our linux-kernel class decides to add a specific
config to the sources, it is now the the question how generic that
config is: only specific to the currently built architecture or even
specific to the selected machine? It is misleading to say, though, that
a source package which carries a machine-specific config is only
arch-specific. It's machine-specific. But hardly anyone would try to
build such a kernel for incompatible machines or even for a different
architectures.

Theoretically, we could even stick multiple configs into the source
package, e.g. the whole cip-kernel-config repo, and select the one used
for a particular target build based on DISTRO_ARCH. That would resolve
the source package issue for such kernels as well.

But I suspect it would still not help us with the native kbuild packages
if they have dependencies on the specific config. Then they would need
to carry the DISTRO_ARCH (the config selector) in their names. Would be
interesting to understand if that already bits us today with the
KERNEL_DEFCONFIG="" case. Did you check?

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/a60e3e68-1a80-4a23-af1a-01f4aff040c9%40siemens.com.

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

['Jan Kiszka' via isar-users]

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 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".

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/5cb44a40-b33e-4b1e-8ec3-f93cf278f107%40siemens.com.

Re: [PATCH 0/5] Fix single-name single-content rule for kernel packages

['Jan Kiszka' via isar-users]

On 13.08.26 19:45, Jan Kiszka wrote:
> On 13.08.26 18:44, Felix Moessbauer wrote:
>> Similar to upstream Debian, our kernel source packages are architecture
>> specific. By that, we also have to encode the architecture (or machine)
>> in the name of the package. Otherwise existing packages might get
>> reused on rebuilds with other targets (or multiarch)
>>
>> In isar, this has ever been modeled incorrectly (the kernels .dsc file
>> was arch=any despite being arch specific). This is easy to fix, but
>> also depending on the kernels was done incorrectly (a KERNEL_NAME =
>> mainline is not specific enough, as mainline on arm64 is technically a
>> different kernel (source package) than mainline on amd64.
>>
> 
> It is more complicated than this:
> 
> A source packages becomes architecture or even machine-specific if we
> bundle the concretely built config file with it. If KERNEL_DEFCONFIG is
> empty (default), a kernel source package is actually buildable for any
> architecture, thus remains generic.

Correction: KERNEL_DEFCONFIG can even be set. The question is whether we
have a conditionally added external config file, and that condition
depends on the architecture or machine. Only that latter step makes the
source package arch or machine-specific. And that is a recipe author
decision...

Jan

> 
> Now, if the user of our linux-kernel class decides to add a specific
> config to the sources, it is now the the question how generic that
> config is: only specific to the currently built architecture or even
> specific to the selected machine? It is misleading to say, though, that
> a source package which carries a machine-specific config is only
> arch-specific. It's machine-specific. But hardly anyone would try to
> build such a kernel for incompatible machines or even for a different
> architectures.
> 
> Theoretically, we could even stick multiple configs into the source
> package, e.g. the whole cip-kernel-config repo, and select the one used
> for a particular target build based on DISTRO_ARCH. That would resolve
> the source package issue for such kernels as well.
> 
> But I suspect it would still not help us with the native kbuild packages
> if they have dependencies on the specific config. Then they would need
> to carry the DISTRO_ARCH (the config selector) in their names. Would be
> interesting to understand if that already bits us today with the
> KERNEL_DEFCONFIG="" case. Did you check?
> 
> 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/6e33f06a-0f15-46aa-90ea-ddea597b57aa%40siemens.com.

Re: [PATCH 0/5] Fix single-name single-content rule for kernel packages

['Jan Kiszka' via isar-users]

On 13.08.26 19:50, Jan Kiszka wrote:
> On 13.08.26 19:45, Jan Kiszka wrote:
>> On 13.08.26 18:44, Felix Moessbauer wrote:
>>> Similar to upstream Debian, our kernel source packages are architecture
>>> specific. By that, we also have to encode the architecture (or machine)
>>> in the name of the package. Otherwise existing packages might get
>>> reused on rebuilds with other targets (or multiarch)
>>>
>>> In isar, this has ever been modeled incorrectly (the kernels .dsc file
>>> was arch=any despite being arch specific). This is easy to fix, but
>>> also depending on the kernels was done incorrectly (a KERNEL_NAME =
>>> mainline is not specific enough, as mainline on arm64 is technically a
>>> different kernel (source package) than mainline on amd64.
>>>
>>
>> It is more complicated than this:
>>
>> A source packages becomes architecture or even machine-specific if we
>> bundle the concretely built config file with it. If KERNEL_DEFCONFIG is
>> empty (default), a kernel source package is actually buildable for any
>> architecture, thus remains generic.
> 
> Correction: KERNEL_DEFCONFIG can even be set. The question is whether we
> have a conditionally added external config file, and that condition
> depends on the architecture or machine. Only that latter step makes the
> source package arch or machine-specific. And that is a recipe author
> decision...
> 

Wait - it's actually arch or machine specific templating that bites us
here: If KERNEL_DEFCONFIG or any other bitbake variable that influences
the source package content (including the debian/ folder) if differing
across builds while having the same name for the source package, that
will obviously cause a mess. This is also where the CIP kernel from
isar-cip-core gets different source-wise although it has identical
configs on board.

So, the better solution for such multi-purpose kernels is to introduce
build-time config selection, rather than templating.

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/3c580394-d803-4d10-80de-6e1c9186fe3a%40siemens.com.

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

['MOESSBAUER, Felix' via isar-users]

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.

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/d5f813bdf0d016b85db13977de3380b02f9e5498.camel%40siemens.com.

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

['Jan Kiszka' via isar-users]

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).

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/e4e31361-8f47-475f-9acf-a2021de0fa53%40siemens.com.

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

['MOESSBAUER, Felix' via isar-users]

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.

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

['Jan Kiszka' via isar-users]

On 14.08.26 09:01, Moessbauer, Felix (FT RPD CED OES-DE) wrote:
> 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.
> 

Conceptually, that is the point here, the sources can provide all what
is needed for all architectures without templating. They would simply
have to unroll, e.g., the templated

Package: linux-kbuild-${KERNEL_NAME_PROVIDED}-${DISTRO_ARCH}-cross

for all compatible archs and select what is actually built via profiles.

> But AFAIK it does not necessarily be machine specific, if all needed
> defconfigs are present in the image. However, currently we modify the

But only then. Most kernels that are built by isar are very
machine-specific due to their configs. The kernels we have in meta-isar
and isar-cip-core are the special cases. When defining a mitigation, we
need to keep that in mind so that 99% of the users are not suffering
from such 1%.

> 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.

Debian is special as they build only few kernels, and then only from
very generic configs. We want to keep drop-in compatibility on binary
package level, for sure, but we cannot emulate their build process for
the customized kernels Isar enables.

> 
> 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.

This is just like the issue with false-sharing around multiconfig (once
stamps of
https://github.com/ilbers/isar/blob/master/meta/classes-global/isar-events.bbclass):
How will Isar support users that do not care about that, do not realize
what is making their kernel specific, and do not encode that into the
KERNEL_NAME because it was also not needed so far?

> 
> 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.

I'm still a bigger fan of either properly addressing the root cause or
working around it internally. Any warm recommendations will not help
when there is no tooling to reveal real problems early enough.

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/54549f17-4538-4f76-b04a-f25b1ce4da6e%40siemens.com.