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

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

[chris.larson via isar-users]

From: Christopher Larson <chris.larson@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

-- 
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/20250407160148.443385-1-chris.larson%40siemens.com.

[PATCH 1/2] per-kernel.bbclass: add class

[chris.larson via isar-users]

From: Christopher Larson <chris.larson@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.larson@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

-- 
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/20250407160148.443385-2-chris.larson%40siemens.com.

[PATCH 2/2] linux-module: inherit per-kernel

[chris.larson via isar-users]

From: Christopher Larson <chris.larson@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.larson@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

-- 
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/20250407160148.443385-3-chris.larson%40siemens.com.

Re: [PATCH 2/2] linux-module: inherit per-kernel

['cedric.hombourger@siemens.com' via isar-users]

On Mon, 2025-04-07 at 09:01 -0700, chris.larson@siemens.com wrote:
> From: Christopher Larson <chris.larson@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.hombourger@siemens.com>

> Signed-off-by: Christopher Larson <chris.larson@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"


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

Re: [PATCH 2/2] linux-module: inherit per-kernel

['Florian Bezdeka' via isar-users]

On Mon, 2025-04-07 at 09:01 -0700, chris.larson via isar-users wrote:
> From: Christopher Larson <chris.larson@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.larson@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

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

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

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

Re: [PATCH 2/2] linux-module: inherit per-kernel

['cedric.hombourger@siemens.com' via isar-users]

On Tue, 2025-04-08 at 10:07 +0200, Florian Bezdeka wrote:
> On Mon, 2025-04-07 at 09:01 -0700, chris.larson via isar-users wrote:
> > From: Christopher Larson <chris.larson@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.larson@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
> 
> AFAIR the rest of the code base uses one inherit statement per class.

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

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

Re: [PATCH 2/2] linux-module: inherit per-kernel

['Larson, Chris' via isar-users]

On 4/8/2025 1:13 AM, Hombourger, Cedric (FT FDS CES LX) wrote:
> On Tue, 2025-04-08 at 10:07 +0200, Florian Bezdeka wrote:
>> On Mon, 2025-04-07 at 09:01 -0700, chris.larson via isar-users wrote:
>>> From: Christopher Larson <chris.larson@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.larson@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
>>
>> AFAIR the rest of the code base uses one inherit statement per class.
> 
> 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)

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

-- 
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/c59de312-59a6-4c89-95c1-866550e06e5c%40siemens.com.

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

['Florian Bezdeka' via isar-users]

On Mon, 2025-04-07 at 09:01 -0700, chris.larson via isar-users wrote:
> From: Christopher Larson <chris.larson@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?

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

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

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

['cedric.hombourger@siemens.com' via isar-users]

On Tue, 2025-04-08 at 10:09 +0200, Florian Bezdeka wrote:
> On Mon, 2025-04-07 at 09:01 -0700, chris.larson via isar-users wrote:
> > From: Christopher Larson <chris.larson@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?

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

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


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

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

['Florian Bezdeka' via isar-users]

On Tue, 2025-04-08 at 08:18 +0000, Hombourger, Cedric (FT FDS CES LX)
wrote:
> On Tue, 2025-04-08 at 10:09 +0200, Florian Bezdeka wrote:
> > On Mon, 2025-04-07 at 09:01 -0700, chris.larson via isar-users wrote:
> > > From: Christopher Larson <chris.larson@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?
> 
> 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

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.

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

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

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

['cedric.hombourger@siemens.com' via isar-users]

On Tue, 2025-04-08 at 10:29 +0200, Florian Bezdeka wrote:
> On Tue, 2025-04-08 at 08:18 +0000, Hombourger, Cedric (FT FDS CES LX)
> wrote:
> > On Tue, 2025-04-08 at 10:09 +0200, Florian Bezdeka wrote:
> > > On Mon, 2025-04-07 at 09:01 -0700, chris.larson via isar-users
> > > wrote:
> > > > From: Christopher Larson <chris.larson@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?
> > 
> > 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
> 
> 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?

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.

> 
> That's the missing part for me.
> 
> > 
> > > 
> > > > 
> > > > 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
> > > 
> 

-- 
Cedric Hombourger
Siemens AG
www.siemens.com

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

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

['Jan Kiszka' via isar-users]

On 08.04.25 10:18, 'cedric.hombourger@siemens.com' via isar-users wrote:
> On Tue, 2025-04-08 at 10:09 +0200, Florian Bezdeka wrote:
>> On Mon, 2025-04-07 at 09:01 -0700, chris.larson via isar-users wrote:
>>> From: Christopher Larson <chris.larson@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?
> 
> 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
> 

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

-- 
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/0fe2440d-190b-4388-b6f6-55b834d5ba09%40siemens.com.

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

['cedric.hombourger@siemens.com' via isar-users]

On Tue, 2025-04-08 at 12:05 +0200, Jan Kiszka wrote:
> On 08.04.25 10:18, 'cedric.hombourger@siemens.com' via isar-users
> wrote:
> > On Tue, 2025-04-08 at 10:09 +0200, Florian Bezdeka wrote:
> > > On Mon, 2025-04-07 at 09:01 -0700, chris.larson via isar-users
> > > wrote:
> > > > From: Christopher Larson <chris.larson@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?
> > 
> > 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
> > 
> 
> It's more than that: New features need demos and test cases.

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

> It
> is the place to develop and use them. There can be exceptions, but
> the
> rule is different.
> 
> Jan
> 


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