From: Nathan Chancellor <nathan@kernel.org>
To: Graham Roff <grahamr@qti.qualcomm.com>
Cc: Nicolas Schier <nsc@kernel.org>, Jonathan Corbet <corbet@lwn.net>,
linux-kbuild@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Nicolas Pitre <nico@fluxnic.net>
Subject: Re: [PATCH] Support conditional deps using "depends on X if Y"
Date: Sun, 9 Nov 2025 16:29:22 -0700 [thread overview]
Message-ID: <20251109232922.GA2977577@ax162> (raw)
In-Reply-To: <20251107-kconfig_conditional_deps-v1-1-aff22199ec0b@qti.qualcomm.com>
Hi Graham,
On Fri, Nov 07, 2025 at 05:16:34PM -0800, Graham Roff wrote:
> From: Nicolas Pitre <nico@fluxnic.net>
>
> Extend the "depends on" syntax to support conditional dependencies
> using "depends on X if Y". While functionally equivalent to "depends
> on X || (Y == n)", "depends on X if Y" is much more readable and
> makes the kconfig language uniform in supporting the "if <expr>"
> suffix.
>
> The change is implemented by converting the "X if Y" syntax into the
> "X || (Y == n)" syntax during "depends on" token processing.
>
> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
>
> [Graham Roff: Rewrote commit message and redid patch for latest kernel]
>
> Signed-off-by: Graham Roff <grahamr@qti.qualcomm.com>
> ---
> This patch updates an earlier one that was not merged to work on
> the latest kernel release.
>
> Link: https://lwn.net/ml/linux-kernel/nycvar.YSQ.7.76.2004231102480.2671@knanqh.ubzr/#t
>
> Support for this change has been expressed by a number of developers
> since the original patch was proposed back in 2020, and has recently
> also been raised as a patch to the Zephyr kconfig system.
Do you have a link to this Zephyr Kconfig change?
> One specific use is when mapping the Bluetooth specification to Kconfig,
> as it explicitly provides dependencies between features as conditional
> on other features. Many other cases exist where the "slightly
> counterintuitive" (quoted from the Kconfig specification) expression
> "depends on BAR || !BAR" has been used when a proper "if" condition
> would be more readable.
>
> The earlier patch discussion ended without a real conclusion and should
> be revisited now.
I think it would be useful to have a slightly more concrete example in
the documentation of where this could be useful because even with the
"if" syntax, it still feels a little confusing to me at least with the
current example. Since this is just internally converting "depends on A
if B" to "depends on A || !B", this seems like a low risk addition to
the Kconfig language but it would be good to have some tests under
scripts/kconfig/tests like the ones recently added by commit
f9afce4f32e9 ("kconfig: Add transitional symbol attribute for migration
support") upstream.
> ---
> Documentation/kbuild/kconfig-language.rst | 12 +++++++++++-
> scripts/kconfig/lkc.h | 2 +-
> scripts/kconfig/menu.c | 12 +++++++++++-
> scripts/kconfig/parser.y | 6 +++---
> 4 files changed, 26 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst
> index abce88f15d7c..61848f999db8 100644
> --- a/Documentation/kbuild/kconfig-language.rst
> +++ b/Documentation/kbuild/kconfig-language.rst
> @@ -118,7 +118,7 @@ applicable everywhere (see syntax).
> This is a shorthand notation for a type definition plus a value.
> Optionally dependencies for this default value can be added with "if".
>
> -- dependencies: "depends on" <expr>
> +- dependencies: "depends on" <expr> ["if" <expr>]
>
> This defines a dependency for this menu entry. If multiple
> dependencies are defined, they are connected with '&&'. Dependencies
> @@ -134,6 +134,16 @@ applicable everywhere (see syntax).
> bool "foo"
> default y
>
> + The dependency definition itself may be conditional by appending "if"
> + followed by an expression. If such expression is false (n) then this
> + dependency is ignored. One possible use case is:
> +
> + config FOO
> + tristate
> + depends on BAZ if BAZ != n
> +
> + meaning that FOO is constrained by the value of BAZ only when it is set.
> +
> - reverse dependencies: "select" <symbol> ["if" <expr>]
>
> While normal dependencies reduce the upper limit of a symbol (see
> diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h
> index 56548efc14d7..798985961215 100644
> --- a/scripts/kconfig/lkc.h
> +++ b/scripts/kconfig/lkc.h
> @@ -82,7 +82,7 @@ void menu_warn(const struct menu *menu, const char *fmt, ...);
> struct menu *menu_add_menu(void);
> void menu_end_menu(void);
> void menu_add_entry(struct symbol *sym, enum menu_type type);
> -void menu_add_dep(struct expr *dep);
> +void menu_add_dep(struct expr *dep, struct expr *cond);
> void menu_add_visibility(struct expr *dep);
> struct property *menu_add_prompt(enum prop_type type, const char *prompt,
> struct expr *dep);
> diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
> index 0f1a6513987c..b2d8d4e11e07 100644
> --- a/scripts/kconfig/menu.c
> +++ b/scripts/kconfig/menu.c
> @@ -127,8 +127,18 @@ static struct expr *rewrite_m(struct expr *e)
> return e;
> }
>
> -void menu_add_dep(struct expr *dep)
> +void menu_add_dep(struct expr *dep, struct expr *cond)
> {
> + if (cond) {
> + /*
> + * We have "depends on X if Y" and we want:
> + * Y != n --> X
> + * Y == n --> y
> + * That simplifies to: (X || (Y == n))
> + */
> + dep = expr_alloc_or(dep,
> + expr_trans_compare(cond, E_EQUAL, &symbol_no));
> + }
> current_entry->dep = expr_alloc_and(current_entry->dep, dep);
> }
>
> diff --git a/scripts/kconfig/parser.y b/scripts/kconfig/parser.y
> index 49b79dde1725..6d1bbee38f5d 100644
> --- a/scripts/kconfig/parser.y
> +++ b/scripts/kconfig/parser.y
> @@ -323,7 +323,7 @@ if_entry: T_IF expr T_EOL
> {
> printd(DEBUG_PARSE, "%s:%d:if\n", cur_filename, cur_lineno);
> menu_add_entry(NULL, M_IF);
> - menu_add_dep($2);
> + menu_add_dep($2, NULL);
> $$ = menu_add_menu();
> };
>
> @@ -422,9 +422,9 @@ help: help_start T_HELPTEXT
>
> /* depends option */
>
> -depends: T_DEPENDS T_ON expr T_EOL
> +depends: T_DEPENDS T_ON expr if_expr T_EOL
> {
> - menu_add_dep($3);
> + menu_add_dep($3, $4);
> printd(DEBUG_PARSE, "%s:%d:depends on\n", cur_filename, cur_lineno);
> };
>
>
> ---
> base-commit: a1388fcb52fcad3e0b06e2cdd0ed757a82a5be30
> change-id: 20251106-kconfig_conditional_deps-51f1c903f863
>
> Best regards,
> --
> Graham Roff <grahamr@qti.qualcomm.com>
>
next prev parent reply other threads:[~2025-11-09 23:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-08 1:16 [PATCH] Support conditional deps using "depends on X if Y" Graham Roff
2025-11-09 23:29 ` Nathan Chancellor [this message]
2025-11-10 8:48 ` Jani Nikula
2025-11-10 21:15 ` Nathan Chancellor
2025-11-10 22:32 ` Randy Dunlap
2025-11-11 4:09 ` Graham Roff
2025-11-11 7:06 ` Jani Nikula
2025-11-11 22:21 ` Graham Roff
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=20251109232922.GA2977577@ax162 \
--to=nathan@kernel.org \
--cc=corbet@lwn.net \
--cc=grahamr@qti.qualcomm.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nico@fluxnic.net \
--cc=nsc@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.