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

[Felix Moessbauer]

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

[Jan Kiszka]

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

[Jan Kiszka]

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

[Jan Kiszka]

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.