| Message ID | 20250407160148.443385-1-chris.larson@siemens.com |
|---|---|
| Headers | show |
| Series | Add support for per-kernel recipe variants | expand |
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
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 >
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 > >
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 > > > >
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
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 >
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