Message-ID: <nycvar.YSQ.7.76.2004221649480.2671@knanqh.ubzr>
Date:   Wed, 22 Apr 2020 17:13:09 -0400 (EDT)
From:   Nicolas Pitre <nico@...xnic.net>
To:     Jani Nikula <jani.nikula@...ux.intel.com>
cc:     Saeed Mahameed <saeedm@...lanox.com>,
        "masahiroy@...nel.org" <masahiroy@...nel.org>,
        "Laurent.pinchart@...asonboard.com" 
        <Laurent.pinchart@...asonboard.com>,
        "airlied@...ux.ie" <airlied@...ux.ie>,
        "jgg@...pe.ca" <jgg@...pe.ca>,
        "linux-kbuild@...r.kernel.org" <linux-kbuild@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "jernej.skrabec@...l.net" <jernej.skrabec@...l.net>,
        "arnd@...db.de" <arnd@...db.de>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "jonas@...boo.se" <jonas@...boo.se>,
        "kieran.bingham+renesas@...asonboard.com" 
        <kieran.bingham+renesas@...asonboard.com>,
        "narmstrong@...libre.com" <narmstrong@...libre.com>,
        "leon@...nel.org" <leon@...nel.org>
Subject: Re: [RFC PATCH 1/2] Kconfig: Introduce "uses" keyword

On Wed, 22 Apr 2020, Jani Nikula wrote:

> On Tue, 21 Apr 2020, Nicolas Pitre <nico@...xnic.net> wrote:
> > This is really a conditional dependency. That's all this is about.
> > So why not simply making it so rather than fooling ourselves? All that 
> > is required is an extension that would allow:
> >
> > 	depends on (expression) if (expression)
> >
> > This construct should be obvious even without reading the doc, is 
> > already used extensively for other things already, and is flexible 
> > enough to cover all sort of cases in addition to this particular one.
> 
> Okay, you convinced me. Now you only need to convince whoever is doing
> the actual work of implementing this stuff. ;)

What about this:

----- >8
Subject: [PATCH] kconfig: allow for conditional dependencies

This might appear to be a strange concept, but sometimes we want
a dependency to be conditionally applied. One such case is currently
expressed with:

	depends on FOO || !FOO

This pattern is strange enough to give one's pause. Given that it is
also frequent, let's make the intent more obvious with some syntaxic 
sugar by effectively making dependencies optionally conditional.
This also makes the kconfig language more uniform.

Signed-off-by: Nicolas Pitre <nico@...xnic.net>

diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst
index d0111dd264..0f841e0037 100644
--- a/Documentation/kbuild/kconfig-language.rst
+++ b/Documentation/kbuild/kconfig-language.rst
@@ -114,7 +114,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
@@ -130,6 +130,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 d4ca829736..1a9337d1b9 100644
--- a/scripts/kconfig/lkc.h
+++ b/scripts/kconfig/lkc.h
@@ -72,7 +72,7 @@ void menu_warn(struct menu *menu, const char *fmt, ...);
 struct menu *menu_add_menu(void);
 void menu_end_menu(void);
 void menu_add_entry(struct symbol *sym);
-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, char *prompt, struct expr *dep);
 void menu_add_expr(enum prop_type type, struct expr *expr, struct expr *dep);
diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index e436ba44c9..e6b204225e 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -103,8 +103,22 @@ 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) {
+		struct expr *cond2, *left, *right;
+		/*
+		 * We have "depends on X if Y" and we want:
+		 *	Y != n --> X
+		 *	Y == n --> y
+		 * Meaning: ((Y != n) && X) || (Y == n)
+		 */
+		cond2 = expr_copy(cond);
+		left = expr_trans_compare(cond2, E_UNEQUAL, &symbol_no);
+		left = expr_alloc_and(dep, left);
+		right = expr_trans_compare(cond, E_EQUAL, &symbol_no);
+		dep = expr_alloc_or(left, right);
+	}
 	current_entry->dep = expr_alloc_and(current_entry->dep, dep);
 }
 
diff --git a/scripts/kconfig/parser.y b/scripts/kconfig/parser.y
index 708b6c4b13..4161207da2 100644
--- a/scripts/kconfig/parser.y
+++ b/scripts/kconfig/parser.y
@@ -316,7 +316,7 @@ if_entry: T_IF expr T_EOL
 {
 	printd(DEBUG_PARSE, "%s:%d:if\n", zconf_curname(), zconf_lineno());
 	menu_add_entry(NULL);
-	menu_add_dep($2);
+	menu_add_dep($2, NULL);
 	$$ = menu_add_menu();
 };
 
@@ -412,9 +412,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", zconf_curname(), zconf_lineno());
 };
 

Powered by blists - more mailing lists