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

["'Jan Kiszka' via isar-users" <isar-users@googlegroups.com>]

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.