[PATCH 0/2] Add support for per-kernel recipe variants

[chris....@siemens.com]

From: Christopher Larson <chris....@siemens.com>

Add support for per-kernel recipe variants. This aids in the ability for a
MACHINE to support multiple kernels, by allowing us to generate per-kernel
variants in recipes like external kernel modules.

A new variable KERNEL_NAMES will list the kernels for which variants will be
generated. It defaults to KERNEL_NAME. While this variable lists all supported
kernels for the current machine, a variant will not be generated for
KERNEL_NAME, assuming that's the recipe's baseline. Each variant listed in
KERNEL_NAMES will add kernel-<kernel_name> to the OVERRIDES variable, and
per-kernel:<kernel_name> to the BBCLASSEXTEND variable. In addition,
KERNEL_NAME will be set to the kernel name for the current variant.

In a recipe that already uses KERNEL_NAME and appends it to its PN, all you
need to do to use this is to inherit per-kernel, and add any additional kernels
you want to support to KERNEL_NAMES. The second patch in this series
does so for external kernel modules by default, but this will have no effect
on existing recipes unless KERNEL_NAMES is set to something other than
KERNEL_NAME.

Christopher Larson (2):
per-kernel.bbclass: add class
linux-module: inherit per-kernel

meta/classes/per-kernel.bbclass | 35 +++++++++++++++++++++
meta/recipes-kernel/linux-module/module.inc | 2 +-
2 files changed, 36 insertions(+), 1 deletion(-)
create mode 100644 meta/classes/per-kernel.bbclass

--
2.47.2

[chris....@siemens.com]

From: Christopher Larson <chris....@siemens.com>

Add support for per-kernel recipe variants. This aids in the ability for a
MACHINE to support multiple kernels, by allowing us to generate per-kernel
variants in recipes like external kernel modules.

A new variable KERNEL_NAMES will list the kernels for which variants will be
generated. It defaults to KERNEL_NAME. While this variable lists all supported
kernels for the current machine, a variant will not be generated for
KERNEL_NAME, assuming that's the recipe's baseline. Each variant listed in
KERNEL_NAMES will add kernel-<kernel_name> to the OVERRIDES variable, and
per-kernel:<kernel_name> to the BBCLASSEXTEND variable. In addition,
KERNEL_NAME will be set to the kernel name for the current variant.

Signed-off-by: Christopher Larson <chris....@siemens.com>
---
meta/classes/per-kernel.bbclass | 35 +++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
create mode 100644 meta/classes/per-kernel.bbclass

diff --git a/meta/classes/per-kernel.bbclass b/meta/classes/per-kernel.bbclass
new file mode 100644
index 00000000..8abe117f
--- /dev/null
+++ b/meta/classes/per-kernel.bbclass
@@ -0,0 +1,35 @@
+# Generate per-kernel recipe variants
+#
+# Recipes which are specific to a specific kernel currently append KERNEL_NAME to the PN,
+# and depend on and target that specific kernel. For a machine which supports and builds
+# multiple kernel images, there is a need to generate a variant of the recipe for each
+# kernel image.
+#
+# Each variant listed in KERNEL_NAMES will add `kernel-<kernel_name>` to the OVERRIDES variable, and
+# `per-kernel:<kernel_name>` to the BBCLASSEXTEND variable. In addition, KERNEL_NAME will be
+# set to the kernel name for the current variant.
+#
+# Copyright (c) Siemens AG, 2025
+# SPDX-License-Identifier: MIT
+
+OVERRIDES .= ":kernel-${KERNEL_NAME}"
+
+KERNEL_NAMES ?= "${KERNEL_NAME}"
+BBCLASSEXTEND += "${@' '.join(f'per-kernel:{kernel}' for kernel in d.getVar('KERNEL_NAMES').split() if kernel != d.getVar('KERNEL_NAME'))}"
+
+python per_kernel_virtclass_handler() {
+ orig_pn = d.getVar('PN')
+
+ d = e.data
+ extend = d.getVar('BBEXTENDCURR') or ''
+ variant = d.getVar('BBEXTENDVARIANT') or ''
+ if extend != 'per-kernel':
+ return
+ elif variant == '':
+ d.appendVar('PROVIDES', f' {orig_pn}')
+ return
+
+ d.setVar('KERNEL_NAME', variant)
+}
+addhandler per_kernel_virtclass_handler
+per_kernel_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
--
2.47.2

[chris....@siemens.com]

From: Christopher Larson <chris....@siemens.com>

This ensures that it's possible to build the kernel module for all kernels which
are supported by the current MACHINE. This will have no effect unless the
KERNEL_NAMES variable is adjusted to add more than just KERNEL_NAME.

Signed-off-by: Christopher Larson <chris....@siemens.com>
---

meta/recipes-kernel/linux-module/module.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux-module/module.inc b/meta/recipes-kernel/linux-module/module.inc
index 3b0ceae7..47086158 100644
--- a/meta/recipes-kernel/linux-module/module.inc
+++ b/meta/recipes-kernel/linux-module/module.inc
@@ -42,7 +42,7 @@ python() {
d.setVar('ISAR_CROSS_COMPILE', '0')
}

-inherit dpkg
+inherit dpkg per-kernel

TEMPLATE_FILES = "debian/control.tmpl \
debian/rules.tmpl"
--
2.47.2

[cedric.h...@siemens.com]

On Mon, 2025-04-07 at 09:01 -0700, chris....@siemens.com wrote:
> From: Christopher Larson <chris....@siemens.com>
>
> This ensures that it's possible to build the kernel module for all
> kernels which
> are supported by the current MACHINE. This will have no effect unless
> the
> KERNEL_NAMES variable is adjusted to add more than just KERNEL_NAME.
>
>

Tested-by: Cedric Hombourger <cedric.h...@siemens.com>

[Florian Bezdeka]

AFAIR the rest of the code base uses one inherit statement per class.

[Florian Bezdeka]

On Mon, 2025-04-07 at 09:01 -0700, chris.larson via isar-users wrote:

> From: Christopher Larson <chris....@siemens.com>
>
> Add support for per-kernel recipe variants. This aids in the ability for a
> MACHINE to support multiple kernels, by allowing us to generate per-kernel
> variants in recipes like external kernel modules.
>
> A new variable KERNEL_NAMES will list the kernels for which variants will be
> generated. It defaults to KERNEL_NAME. While this variable lists all supported
> kernels for the current machine, a variant will not be generated for
> KERNEL_NAME, assuming that's the recipe's baseline. Each variant listed in
> KERNEL_NAMES will add kernel-<kernel_name> to the OVERRIDES variable, and
> per-kernel:<kernel_name> to the BBCLASSEXTEND variable. In addition,
> KERNEL_NAME will be set to the kernel name for the current variant.

I'm missing the documentation for the new `KERNEL_NAMES` variable.

In addition you explained how this works, but what is the use case
behind? I can build multiple kernels per machine now, but when is this
needed?

[cedric.h...@siemens.com]

Correct (just checked). On the other hand, meta-openembedded uses
multiple the above construct very often (more often than not as far as
I can tell).

I understand that isar and meta-openembedded are not the same projects
but I would not nitpick on that as I don't think it hurts readability
IMHO (it would if we had a dozen classes imported)

>
> >  
> >  TEMPLATE_FILES = "debian/control.tmpl \
> >                    debian/rules.tmpl"
> > --
> > 2.47.2
>

--
Cedric Hombourger
Siemens AG
www.siemens.com

[cedric.h...@siemens.com]

If you are wanting a concrete use-case noted in the documentation, it
can certainly be added: no harm.

Concretely there are machine-supporting layers offering multiple
kernels. Examples: "normal" kernel, PREEMPT_RT kernel. Another use-case
until we get a .deb for each .ko (like in Yocto you can get an ipk for
each ko), you may need a footprint-optimized kernel for e.g. a recovery
image.

I hope that explains. Do let us know if the use-cases should be listed
in the documentation. It would not be an issue to add them

[Florian Bezdeka]

On Tue, 2025-04-08 at 08:18 +0000, Hombourger, Cedric (FT FDS CES LX)
wrote:

I think it's worth to document KERNEL_NAMES with a complete example.

As I understand KERNEL_NAMES for now it's for building. So you can
build / select different kernels for your machine. OK, but where is the
decision taken which kernel is installed into which image?

That's the missing part for me.

[cedric.h...@siemens.com]

Good question. And probably worth noting in the documentation as well.
As I have tested this patch on my setup, KERNEL_NAME remains the kernel
that goes into your image. Hopefully IMAGE_INSTALL directives for out-
of-tree kernel modules would be of the form "my-custom-module-
${KERNEL_NAME}" and not e.g. "my-custom-module-${MACHINE}" or some
other hard-coded value but that's independent from this change.

In other words, I don't think Chris has changed any "APIs" but indeed
added some variables that should be documented as you suggested
earlier.

Let's wait for Chris to come online and chime in.

[Jan Kiszka]

It's more than that: New features need demos and test cases.

Isar is not just place to dump some bits from downstream use cases. It
is the place to develop and use them. There can be exceptions, but the
rule is different.

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center

[cedric.h...@siemens.com]

No disagreements here. We can have Chris check for a meta-isar / meta-
test place where this feature could be exercised

>
> Isar is not just place to dump some bits from downstream use cases.

Be assured that we are not just throwing stuff over the wall...

[Larson, Chris]

Apologies, I'm still adapting to the differences from Yocto. I have no objection to
aligning this with isar repository convention in a v2. I did want to confirm that there was no objection to this feature before diving too deep into the tests, so I should have used an RFC prefix.
--
Christopher Larson
Siemens AG
www.siemens.com

[chris....@siemens.com]

From: Christopher Larson <chris....@siemens.com>

Add support for generation of per-kernel recipe variants. This aids in the

ability for a MACHINE to support multiple kernels, by allowing us to generate

per-kernel packages in recipes like external kernel modules. Enable this
support by default for external kernel modules.

A new variable KERNEL_NAMES will list the kernels for which variants will be

generated. For any kernels listed other than KERNEL_NAME, a variant of the
recipe will be produced, to generate a package or packages for that kernel.
In each variant, the KERNEL_NAME variable will be set to the kernel name for
which the variant is being built, and the `kernel-<kernel_name>` override
will be added, allowing for further metadata customization on a per-kernel
basis.

In a recipe that already uses KERNEL_NAME and appends it to its PN, all you
need to do to use this is to inherit per-kernel, and add any additional kernels
you want to support to KERNEL_NAMES. The second patch in this series
does so for external kernel modules by default, but this will have no effect
on existing recipes unless KERNEL_NAMES is set to something other than
KERNEL_NAME.

A new test is added to verify that the per-kernel support works as expected.

No documentation for the per-kernel class is added, as it's already being enabled
for external kernel modules, which is the main use case, and no other optional
bbclasses are being documented in the user manual today.

Christopher Larson (4):

per-kernel.bbclass: add class
linux-module: inherit per-kernel

testsuite: add 'extra_lines' argument to configure
testsuite: add a test for per_kernel support

meta/classes/per-kernel.bbclass | 35 +++++++++++++++++++++
meta/recipes-kernel/linux-module/module.inc | 1 +
testsuite/cibuilder.py | 5 +++
testsuite/citest.py | 22 +++++++++++++
4 files changed, 63 insertions(+)

[chris....@siemens.com]

From: Christopher Larson <chris....@siemens.com>

Add support for generation of per-kernel recipe variants. This aids in the
ability for a MACHINE to support multiple kernels, by allowing us to generate
per-kernel packages in recipes like external kernel modules.

A new variable KERNEL_NAMES will list the kernels for which variants will be
generated. For any kernels listed other than KERNEL_NAME, a variant of the
recipe will be produced, to generate a package or packages for that kernel.
In each variant, the KERNEL_NAME variable will be set to the kernel name for
which the variant is being built, and the `kernel-<kernel_name>` override
will be added, allowing for further metadata customization on a per-kernel
basis.

Signed-off-by: Christopher Larson <chris....@siemens.com>
---

meta/classes/per-kernel.bbclass | 35 +++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
create mode 100644 meta/classes/per-kernel.bbclass

[chris....@siemens.com]

From: Christopher Larson <chris....@siemens.com>

This ensures that it's possible to build the kernel module for all kernels which
are supported by the current MACHINE. This will have no effect unless the
KERNEL_NAMES variable is adjusted to add more than just KERNEL_NAME.

Signed-off-by: Christopher Larson <chris....@siemens.com>
---

meta/recipes-kernel/linux-module/module.inc | 1 +
1 file changed, 1 insertion(+)

diff --git a/meta/recipes-kernel/linux-module/module.inc b/meta/recipes-kernel/linux-module/module.inc
index 3b0ceae7..6f877115 100644
--- a/meta/recipes-kernel/linux-module/module.inc
+++ b/meta/recipes-kernel/linux-module/module.inc
@@ -43,6 +43,7 @@ python() {
}

inherit dpkg
+inherit per-kernel

[chris....@siemens.com]

From: Christopher Larson <chris....@siemens.com>

This allows us to add extra lines to the configuration file, which is generally
useful, and will ease future creation of tests by avoiding the need to add new
arguments to the configure function for each configuration needed.

Signed-off-by: Christopher Larson <chris....@siemens.com>
---

testsuite/cibuilder.py | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/testsuite/cibuilder.py b/testsuite/cibuilder.py
index e726ba87..f47d6a77 100755
--- a/testsuite/cibuilder.py
+++ b/testsuite/cibuilder.py
@@ -114,6 +114,7 @@ def configure(
installer_distro=None,
installer_device=None,
customizations=None,
+ lines=None,
**kwargs,
):
# write configuration file and set bitbake_args
@@ -142,6 +143,7 @@ def configure(
distro_apt_premir = os.getenv('DISTRO_APT_PREMIRRORS')
fail_on_cleanup = os.getenv('ISAR_FAIL_ON_CLEANUP')

+ strlines = None if lines is None else '\\n'.join(lines)
self.log.info(
f"===================================================\n"
f"Configuring build_dir {self.build_dir}\n"
@@ -162,6 +164,7 @@ def configure(
f" image_install = {image_install}\n"
f" installer_image = {installer_image}\n"
f" customizations = {customizations}\n"
+ f" lines = {strlines}\n"
f"==================================================="
)

@@ -248,6 +251,8 @@ def configure(
f.write('CUSTOMIZATION_VARS:append = " ${IMAGE}"\n')
f.write('CUSTOMIZATION_FOR_IMAGES:append = " isar-image-ci"\n')
f.write('HOSTNAME:isar-image-ci = "isar-ci"\n')
+ if lines is not None:
+ f.writelines((line + '\n' if not line.endswith('\n') else line) for line in lines)

# include ci_build.conf in local.conf
with open(self.build_dir + '/conf/local.conf', 'r+') as f:
--
2.47.2

[chris....@siemens.com]

From: Christopher Larson <chris....@siemens.com>

This is a build test for the per-kernel support. It will build a kernel module for
multiple kernels, and install all of the kernel modules in the test image.

Signed-off-by: Christopher Larson <chris....@siemens.com>
---

testsuite/citest.py | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)

diff --git a/testsuite/citest.py b/testsuite/citest.py
index a5661eac..4b32b849 100755
--- a/testsuite/citest.py
+++ b/testsuite/citest.py
@@ -205,6 +205,28 @@ def test_cross_rpi(self):
self.perform_build_test(targets)


+class KernelTests(CIBaseTest):
+ """
+ Tests associated with kernel builds and development.
+ :avocado: tags=kernel,full
+ """
+
+ def test_per_kernel(self):
+ """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 = [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}')
+ kernel_names = ' '.join(sorted(kernel_names))
+ lines = [
+ f"KERNEL_NAMES:append = ' {kernel_names}'",
+ ]
+ self.init()
+ self.perform_build_test(targets, image_install=' '.join(modules), lines=lines)
+
+
class WicTest(CIBaseTest):

"""
--
2.47.2

[Larson, Chris]

________________________________________
From: Larson, Chris (FT FDS CES LX MEL) <chris....@siemens.com>
Sent: Friday, April 11, 2025 1:08 PM
To: isar-...@googlegroups.com
Cc: Hombourger, Cedric (FT FDS CES LX); Larson, Chris (FT FDS CES LX MEL)
Subject: [PATCHv2 0/4] Add support for per-kernel recipe variants

Apologies, missed the subject line change to v2 on the individual patches.

[Baurzhan Ismagulov]

On 2025-04-11 20:10, 'Larson, Chris' via isar-users wrote:
> Apologies, missed the subject line change to v2 on the individual patches.

No problem, thanks for the patches and the testcase, applied to next.

Also fixed:
Applying: per-kernel.bbclass: add class
.git/rebase-apply/patch:18: trailing whitespace.
#
warning: 1 line adds whitespace errors.

With kind regards,
Baurzhan