| Message ID | 20260813164500.3092151-6-felix.moessbauer@siemens.com |
|---|---|
| State | Under Review |
| Headers | show |
| Series | Fix single-name single-content rule for kernel packages | expand |
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
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
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
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
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
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}')
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(-)