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

["'cedric.hombourger@siemens.com' via isar-users" <isar-users@googlegroups.com>]

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.