public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: bruce.ashfield@gmail.com
To: richard.purdie@linuxfoundation.org
Cc: openembedded-core@lists.openembedded.org
Subject: [PATCH 1/6] kernel-yocto: allow annotated options to be modified
Date: Tue,  6 May 2025 12:32:55 -0400	[thread overview]
Message-ID: <a189bc17538f3bf7f0353d7a861fa58bf2f434e7.1746548780.git.bruce.ashfield@gmail.com> (raw)
In-Reply-To: <cover.1746548780.git.bruce.ashfield@gmail.com>

From: Bruce Ashfield <bruce.ashfield@gmail.com>

Bumping the kern-tools SRCREV to pickup the following commits:

    tools: allow fixups to conditionally change options

    Sometimes we have options that should either be =y or =m depending
    on the use case.

    Rather than force the options into multiple parallel and very similar
    fragments (which is error prone and labour intensive), we can allow
    an annotation in the configuration fragment that allows the default
    value to be overriden by a variable.

    The variable in question comes from a -D<var>=<value> on the scc
    or spp command line. If the define evaluates to a non-zero value
    a fixup is created that will modify the value when scc finishes
    gathering meta-data.

    An example of a notation would be:

      CONFIG_INET_TUNNEL=y # OVERRIDE:$MODULE_OR_Y

    CONFIG_INET_TUNNEL will be =y when standard tools (like merge-config)
    are used. But when scc/spp see this notation, they check the value
    of the variable MODULE_OR_Y, if that variable evalutes to a non-zero
    value, a fixup is created that will change CONFIG_INET_TUNNEL to
    that value before the kernel is configured.

To use the annotations, scc needs to be passed a value that is used
in the override expression. This has always been possible with defines
(-Dx=y), so we leverage that to control these conditional overrides.

In kernel-yocto, we now have a variable: KMETA_CONFIG_FEATURES

  KMETA_CONFIG_FEATURES ?= ""

Which defaults to empty, the only feature that is currently
implemented is "prefer-modules". When prefer-modules is detected
in the kmeta config features, the following define is passed to
scc:

   -DMODULE_OR_Y=m

Which as you can see from the above INET_TUNNEL example, will
evaluate to "m" and will override the default of "y".

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
---
 meta/classes-recipe/kernel-yocto.bbclass                | 7 ++++++-
 meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/meta/classes-recipe/kernel-yocto.bbclass b/meta/classes-recipe/kernel-yocto.bbclass
index cef6b9ec3f..ba93145fd3 100644
--- a/meta/classes-recipe/kernel-yocto.bbclass
+++ b/meta/classes-recipe/kernel-yocto.bbclass
@@ -25,6 +25,7 @@ KCONF_AUDIT_LEVEL ?= "1"
 KCONF_BSP_AUDIT_LEVEL ?= "0"
 KMETA_AUDIT ?= "yes"
 KMETA_AUDIT_WERROR ?= ""
+KMETA_CONFIG_FEATURES ?= ""
 
 # returns local (absolute) path names for all valid patches in the
 # src_uri
@@ -298,7 +299,11 @@ do_kernel_metadata() {
 		elements="`echo -n ${bsp_definition} $sccs_defconfig ${sccs} ${patches} $KERNEL_FEATURES_FINAL`"
 		if [ -n "${elements}" ]; then
 			echo "${bsp_definition}" > ${S}/${meta_dir}/bsp_definition
-			scc --force -o ${S}/${meta_dir}:cfg,merge,meta ${includes} $sccs_defconfig $bsp_definition $sccs $patches $KERNEL_FEATURES_FINAL
+			echo "${KMETA_CONFIG_FEATURES}" | grep -q "prefer-modules"
+			if [ $? -eq 0 ]; then
+				scc_defines="-DMODULE_OR_Y=m"
+			fi
+			scc --force $scc_defines -o ${S}/${meta_dir}:cfg,merge,meta ${includes} $sccs_defconfig $bsp_definition $sccs $patches $KERNEL_FEATURES_FINAL
 			if [ $? -ne 0 ]; then
 				bbfatal_log "Could not generate configuration queue for ${KMACHINE}."
 			fi
diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index 6dd19f1f09..20b1bcaf37 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = "\
 
 DEPENDS += "git-replacement-native"
 
-SRCREV = "c8c1f17867d0cc7d04be225ba4901f2373428be2"
+SRCREV = "fe67c98d2e9b74af44d0c4b660fa18e3a95e7edd"
 PV = "0.3+git"
 
 inherit native
-- 
2.39.2



  reply	other threads:[~2025-05-06 16:33 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-06 16:32 [PATCH 0/6] kernel-yocto: consolidated pull request bruce.ashfield
2025-05-06 16:32 ` bruce.ashfield [this message]
2025-05-06 16:32 ` [PATCH 2/6] linux-yocto-dev: update to v6.15 bruce.ashfield
2025-05-06 16:32 ` [PATCH 3/6] linux-yocto/6.12: update to v6.12.24 bruce.ashfield
2025-05-06 16:32 ` [PATCH 4/6] linux-yocto/6.12: update to v6.12.25 bruce.ashfield
2025-05-06 16:32 ` [PATCH 5/6] linux-yocto/6.12: bsp/genericarm64: modular configuration updates bruce.ashfield
2025-05-06 16:33 ` [PATCH 6/6] linux-yocto/6.12: update to v6.12.27 bruce.ashfield
2025-05-07  7:42 ` [OE-core] [PATCH 0/6] kernel-yocto: consolidated pull request Mathieu Dubois-Briand
2025-05-07  7:58   ` Richard Purdie
     [not found]   ` <183D2FC291E34522.16348@lists.openembedded.org>
2025-05-07 11:18     ` Richard Purdie
2025-05-07 11:39       ` Mikko Rapeli
2025-05-07 13:03         ` Bruce Ashfield
2025-05-15 16:06         ` Fabio Estevam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a189bc17538f3bf7f0353d7a861fa58bf2f434e7.1746548780.git.bruce.ashfield@gmail.com \
    --to=bruce.ashfield@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox