| Message ID | 1534229021-8056-1-git-send-email-yamada.masahiro@socionext.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] kconfig: report recursive dependency involving 'imply' | expand |
Masahiro Yamada <yamada.masahiro@socionext.com> writes: > Currently, Kconfig does not report anything about the recursive > dependency where 'imply' keywords are involved. > > [Test Code] > > config A > bool "a" > > config B > bool "b" > imply A > depends on A Hello Masahiro, obviously, it is hard to find a reason why one wants to use dependencies like above but I also wonder how e.g. menuconfig handles this case: First, only "a" is visible, if I then select "a", "b" does not become visible but when I then reset "a" to "n", "b" becomes visible. If I then try to select "b", it becomes invisible... Perhaps it would be better to just error out instead of giving users the impression, Kconfig thinks such questionable behavior is OK. Side note: perhaps, the documentation could be better when it comes to recursive dependencies. The documentation says "select" and "imply" can be used to specify lower limits whereas direct dependencies specify upper limits for symbol values and with this in mind, one might wonder why it is a problem to work with both limits in a recursive way. Not very unlikely that it is just me who still has to understand recursive dependencies or problems with reading English text, though. What definitely seems to get void with your patches is item c) in "Practical solutions to kconfig recursive issue" in Documentation/kbuild/kconfig-language: c) Consider the use of "imply" instead of "select" Dirk > In the code above, Kconfig cannot calculate the symbol values correctly > due to the circular dependency. For example, allyesconfig followed by > syncconfig results in an odd behavior because CONFIG_B becomes visible > in syncconfig. > > $ make allyesconfig > scripts/kconfig/conf --allyesconfig Kconfig > # > # configuration written to .config > # > $ cat .config > # > # Automatically generated file; DO NOT EDIT. > # Main menu > # > CONFIG_A=y > $ make syncconfig > scripts/kconfig/conf --syncconfig Kconfig > * > * Restart config... > * > * > * Main menu > * > a (A) [Y/n/?] y > b (B) [N/y/?] (NEW) > > To report this correctly, sym_check_expr_deps() should recurse to > not only sym->rev_dep.expr but also sym->implied.expr . > > At this moment, sym_check_print_recursive() cannot distinguish > 'select' and 'imply' since it does not know the precise context > where the recursive dependency is hit. This will be solved by > the next commit. > > Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> > --- > > scripts/kconfig/symbol.c | 9 +++++++-- > 1 file changed, 7 insertions(+), 2 deletions(-) > > diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c > index 4ec8b1f..7de7463a 100644 > --- a/scripts/kconfig/symbol.c > +++ b/scripts/kconfig/symbol.c > @@ -1098,7 +1098,7 @@ static void sym_check_print_recursive(struct symbol *last_sym) > sym->name ? sym->name : "<choice>", > next_sym->name ? next_sym->name : "<choice>"); > } else { > - fprintf(stderr, "%s:%d:\tsymbol %s is selected by %s\n", > + fprintf(stderr, "%s:%d:\tsymbol %s is selected or implied by %s\n", > prop->file->name, prop->lineno, > sym->name ? sym->name : "<choice>", > next_sym->name ? next_sym->name : "<choice>"); > @@ -1161,8 +1161,13 @@ static struct symbol *sym_check_sym_deps(struct symbol *sym) > if (sym2) > goto out; > > + sym2 = sym_check_expr_deps(sym->implied.expr); > + if (sym2) > + goto out; > + > for (prop = sym->prop; prop; prop = prop->next) { > - if (prop->type == P_CHOICE || prop->type == P_SELECT) > + if (prop->type == P_CHOICE || prop->type == P_SELECT || > + prop->type == P_IMPLY) > continue; > stack.prop = prop; > sym2 = sym_check_expr_deps(prop->visible.expr);
Dirk Gouders <dirk@gouders.net> writes: > Masahiro Yamada <yamada.masahiro@socionext.com> writes: > >> Currently, Kconfig does not report anything about the recursive >> dependency where 'imply' keywords are involved. >> >> [Test Code] >> >> config A >> bool "a" >> >> config B >> bool "b" >> imply A >> depends on A > > Hello Masahiro, > > obviously, it is hard to find a reason why one wants to use dependencies > like above but I also wonder how e.g. menuconfig handles this case: > > First, only "a" is visible, if I then select "a", "b" does not become > visible but when I then reset "a" to "n", "b" becomes visible. If I then > try to select "b", it becomes invisible... > > Perhaps it would be better to just error out instead of giving users the > impression, Kconfig thinks such questionable behavior is OK. > > Side note: perhaps, the documentation could be better when it comes to > recursive dependencies. The documentation says "select" and > "imply" can be used to specify lower limits whereas direct > dependencies specify upper limits for symbol values and with > this in mind, one might wonder why it is a problem to work > with both limits in a recursive way. > > Not very unlikely that it is just me who still has to > understand recursive dependencies or problems with reading > English text, though. > > What definitely seems to get void with your patches is item c) in > "Practical solutions to kconfig recursive issue" in > Documentation/kbuild/kconfig-language: > > c) Consider the use of "imply" instead of "select" Just some more information that adds to me feeling unsure about the correct definition of recursive dependencies: With commit 29c434f367ea (kconfig: tests: test if recursive dependencies are detected) a test case similar to the example above was introduced, explicitely stating it is _no_ recursive dependency: +# depends on and imply +# This is not recursive dependency + +config E1 + bool "E1" + depends on E2 + imply E2 + +config E2 + bool "E2" Dirk > >> In the code above, Kconfig cannot calculate the symbol values correctly >> due to the circular dependency. For example, allyesconfig followed by >> syncconfig results in an odd behavior because CONFIG_B becomes visible >> in syncconfig. >> >> $ make allyesconfig >> scripts/kconfig/conf --allyesconfig Kconfig >> # >> # configuration written to .config >> # >> $ cat .config >> # >> # Automatically generated file; DO NOT EDIT. >> # Main menu >> # >> CONFIG_A=y >> $ make syncconfig >> scripts/kconfig/conf --syncconfig Kconfig >> * >> * Restart config... >> * >> * >> * Main menu >> * >> a (A) [Y/n/?] y >> b (B) [N/y/?] (NEW) >> >> To report this correctly, sym_check_expr_deps() should recurse to >> not only sym->rev_dep.expr but also sym->implied.expr . >> >> At this moment, sym_check_print_recursive() cannot distinguish >> 'select' and 'imply' since it does not know the precise context >> where the recursive dependency is hit. This will be solved by >> the next commit. >> >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> >> --- >> >> scripts/kconfig/symbol.c | 9 +++++++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) >> >> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c >> index 4ec8b1f..7de7463a 100644 >> --- a/scripts/kconfig/symbol.c >> +++ b/scripts/kconfig/symbol.c >> @@ -1098,7 +1098,7 @@ static void sym_check_print_recursive(struct symbol *last_sym) >> sym->name ? sym->name : "<choice>", >> next_sym->name ? next_sym->name : "<choice>"); >> } else { >> - fprintf(stderr, "%s:%d:\tsymbol %s is selected by %s\n", >> + fprintf(stderr, "%s:%d:\tsymbol %s is selected or implied by %s\n", >> prop->file->name, prop->lineno, >> sym->name ? sym->name : "<choice>", >> next_sym->name ? next_sym->name : "<choice>"); >> @@ -1161,8 +1161,13 @@ static struct symbol *sym_check_sym_deps(struct symbol *sym) >> if (sym2) >> goto out; >> >> + sym2 = sym_check_expr_deps(sym->implied.expr); >> + if (sym2) >> + goto out; >> + >> for (prop = sym->prop; prop; prop = prop->next) { >> - if (prop->type == P_CHOICE || prop->type == P_SELECT) >> + if (prop->type == P_CHOICE || prop->type == P_SELECT || >> + prop->type == P_IMPLY) >> continue; >> stack.prop = prop; >> sym2 = sym_check_expr_deps(prop->visible.expr);
2018-08-14 19:38 GMT+09:00 Dirk Gouders <dirk@gouders.net>: > Masahiro Yamada <yamada.masahiro@socionext.com> writes: > >> Currently, Kconfig does not report anything about the recursive >> dependency where 'imply' keywords are involved. >> >> [Test Code] >> >> config A >> bool "a" >> >> config B >> bool "b" >> imply A >> depends on A > > Hello Masahiro, > > obviously, it is hard to find a reason why one wants to use dependencies > like above but I also wonder how e.g. menuconfig handles this case: > > First, only "a" is visible, if I then select "a", "b" does not become > visible but when I then reset "a" to "n", "b" becomes visible. If I then > try to select "b", it becomes invisible... > > Perhaps it would be better to just error out instead of giving users the > impression, Kconfig thinks such questionable behavior is OK. Taking closer look at the code, the intention is 'recursive dependency is error', but the behavior changed probably by an accident. I fixed this: https://patchwork.kernel.org/patch/10566301/ > Side note: perhaps, the documentation could be better when it comes to > recursive dependencies. The documentation says "select" and > "imply" can be used to specify lower limits whereas direct > dependencies specify upper limits for symbol values and with > this in mind, one might wonder why it is a problem to work > with both limits in a recursive way. > > Not very unlikely that it is just me who still has to > understand recursive dependencies or problems with reading > English text, though. To avoid confusion, two things should be discussed separately: [1] Unmet dependency This is caused by a conflict between the upper limit from 'depends on' and the lower limit from 'select'. This issue does not happen for 'imply' because the upper limit specified by 'imply' is weaker. [2] Recursive depenency This can happen for any combination of 'depends on', 'select', 'imply', 'if', 'default', etc. > What definitely seems to get void with your patches is item c) in > "Practical solutions to kconfig recursive issue" in > Documentation/kbuild/kconfig-language: > > c) Consider the use of "imply" instead of "select" I do not know why commit 237e3ad0f195d8 added this line. Actually, I was also confused. I sent v2 based on your feedback. Thanks. > Dirk > >> In the code above, Kconfig cannot calculate the symbol values correctly >> due to the circular dependency. For example, allyesconfig followed by >> syncconfig results in an odd behavior because CONFIG_B becomes visible >> in syncconfig. >> >> $ make allyesconfig >> scripts/kconfig/conf --allyesconfig Kconfig >> # >> # configuration written to .config >> # >> $ cat .config >> # >> # Automatically generated file; DO NOT EDIT. >> # Main menu >> # >> CONFIG_A=y >> $ make syncconfig >> scripts/kconfig/conf --syncconfig Kconfig >> * >> * Restart config... >> * >> * >> * Main menu >> * >> a (A) [Y/n/?] y >> b (B) [N/y/?] (NEW) >> >> To report this correctly, sym_check_expr_deps() should recurse to >> not only sym->rev_dep.expr but also sym->implied.expr . >> >> At this moment, sym_check_print_recursive() cannot distinguish >> 'select' and 'imply' since it does not know the precise context >> where the recursive dependency is hit. This will be solved by >> the next commit. >> >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> >> --- >> >> scripts/kconfig/symbol.c | 9 +++++++-- >> 1 file changed, 7 insertions(+), 2 deletions(-) >> >> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c >> index 4ec8b1f..7de7463a 100644 >> --- a/scripts/kconfig/symbol.c >> +++ b/scripts/kconfig/symbol.c >> @@ -1098,7 +1098,7 @@ static void sym_check_print_recursive(struct symbol *last_sym) >> sym->name ? sym->name : "<choice>", >> next_sym->name ? next_sym->name : "<choice>"); >> } else { >> - fprintf(stderr, "%s:%d:\tsymbol %s is selected by %s\n", >> + fprintf(stderr, "%s:%d:\tsymbol %s is selected or implied by %s\n", >> prop->file->name, prop->lineno, >> sym->name ? sym->name : "<choice>", >> next_sym->name ? next_sym->name : "<choice>"); >> @@ -1161,8 +1161,13 @@ static struct symbol *sym_check_sym_deps(struct symbol *sym) >> if (sym2) >> goto out; >> >> + sym2 = sym_check_expr_deps(sym->implied.expr); >> + if (sym2) >> + goto out; >> + >> for (prop = sym->prop; prop; prop = prop->next) { >> - if (prop->type == P_CHOICE || prop->type == P_SELECT) >> + if (prop->type == P_CHOICE || prop->type == P_SELECT || >> + prop->type == P_IMPLY) >> continue; >> stack.prop = prop; >> sym2 = sym_check_expr_deps(prop->visible.expr);
2018-08-14 22:44 GMT+09:00 Dirk Gouders <dirk@gouders.net>: > Dirk Gouders <dirk@gouders.net> writes: > >> Masahiro Yamada <yamada.masahiro@socionext.com> writes: >> >>> Currently, Kconfig does not report anything about the recursive >>> dependency where 'imply' keywords are involved. >>> >>> [Test Code] >>> >>> config A >>> bool "a" >>> >>> config B >>> bool "b" >>> imply A >>> depends on A >> >> Hello Masahiro, >> >> obviously, it is hard to find a reason why one wants to use dependencies >> like above but I also wonder how e.g. menuconfig handles this case: >> >> First, only "a" is visible, if I then select "a", "b" does not become >> visible but when I then reset "a" to "n", "b" becomes visible. If I then >> try to select "b", it becomes invisible... >> >> Perhaps it would be better to just error out instead of giving users the >> impression, Kconfig thinks such questionable behavior is OK. >> >> Side note: perhaps, the documentation could be better when it comes to >> recursive dependencies. The documentation says "select" and >> "imply" can be used to specify lower limits whereas direct >> dependencies specify upper limits for symbol values and with >> this in mind, one might wonder why it is a problem to work >> with both limits in a recursive way. >> >> Not very unlikely that it is just me who still has to >> understand recursive dependencies or problems with reading >> English text, though. >> >> What definitely seems to get void with your patches is item c) in >> "Practical solutions to kconfig recursive issue" in >> Documentation/kbuild/kconfig-language: >> >> c) Consider the use of "imply" instead of "select" > > Just some more information that adds to me feeling unsure about the > correct definition of recursive dependencies: > > With commit 29c434f367ea (kconfig: tests: test if recursive dependencies > are detected) a test case similar to the example above was introduced, > explicitely stating it is _no_ recursive dependency: > > +# depends on and imply > +# This is not recursive dependency > + > +config E1 > + bool "E1" > + depends on E2 > + imply E2 > + > +config E2 > + bool "E2" > > > Dirk For some reason, I added this without thinking why. I believe this should be recursive dependency. Thanks. >> >>> In the code above, Kconfig cannot calculate the symbol values correctly >>> due to the circular dependency. For example, allyesconfig followed by >>> syncconfig results in an odd behavior because CONFIG_B becomes visible >>> in syncconfig. >>> >>> $ make allyesconfig >>> scripts/kconfig/conf --allyesconfig Kconfig >>> # >>> # configuration written to .config >>> # >>> $ cat .config >>> # >>> # Automatically generated file; DO NOT EDIT. >>> # Main menu >>> # >>> CONFIG_A=y >>> $ make syncconfig >>> scripts/kconfig/conf --syncconfig Kconfig >>> * >>> * Restart config... >>> * >>> * >>> * Main menu >>> * >>> a (A) [Y/n/?] y >>> b (B) [N/y/?] (NEW) >>> >>> To report this correctly, sym_check_expr_deps() should recurse to >>> not only sym->rev_dep.expr but also sym->implied.expr . >>> >>> At this moment, sym_check_print_recursive() cannot distinguish >>> 'select' and 'imply' since it does not know the precise context >>> where the recursive dependency is hit. This will be solved by >>> the next commit. >>> >>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> >>> --- >>> >>> scripts/kconfig/symbol.c | 9 +++++++-- >>> 1 file changed, 7 insertions(+), 2 deletions(-) >>> >>> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c >>> index 4ec8b1f..7de7463a 100644 >>> --- a/scripts/kconfig/symbol.c >>> +++ b/scripts/kconfig/symbol.c >>> @@ -1098,7 +1098,7 @@ static void sym_check_print_recursive(struct symbol *last_sym) >>> sym->name ? sym->name : "<choice>", >>> next_sym->name ? next_sym->name : "<choice>"); >>> } else { >>> - fprintf(stderr, "%s:%d:\tsymbol %s is selected by %s\n", >>> + fprintf(stderr, "%s:%d:\tsymbol %s is selected or implied by %s\n", >>> prop->file->name, prop->lineno, >>> sym->name ? sym->name : "<choice>", >>> next_sym->name ? next_sym->name : "<choice>"); >>> @@ -1161,8 +1161,13 @@ static struct symbol *sym_check_sym_deps(struct symbol *sym) >>> if (sym2) >>> goto out; >>> >>> + sym2 = sym_check_expr_deps(sym->implied.expr); >>> + if (sym2) >>> + goto out; >>> + >>> for (prop = sym->prop; prop; prop = prop->next) { >>> - if (prop->type == P_CHOICE || prop->type == P_SELECT) >>> + if (prop->type == P_CHOICE || prop->type == P_SELECT || >>> + prop->type == P_IMPLY) >>> continue; >>> stack.prop = prop; >>> sym2 = sym_check_expr_deps(prop->visible.expr);
Masahiro Yamada <yamada.masahiro@socionext.com> writes: > 2018-08-14 19:38 GMT+09:00 Dirk Gouders <dirk@gouders.net>: >> Masahiro Yamada <yamada.masahiro@socionext.com> writes: >> >>> Currently, Kconfig does not report anything about the recursive >>> dependency where 'imply' keywords are involved. >>> >>> [Test Code] >>> >>> config A >>> bool "a" >>> >>> config B >>> bool "b" >>> imply A >>> depends on A >> >> Hello Masahiro, >> >> obviously, it is hard to find a reason why one wants to use dependencies >> like above but I also wonder how e.g. menuconfig handles this case: >> >> First, only "a" is visible, if I then select "a", "b" does not become >> visible but when I then reset "a" to "n", "b" becomes visible. If I then >> try to select "b", it becomes invisible... >> >> Perhaps it would be better to just error out instead of giving users the >> impression, Kconfig thinks such questionable behavior is OK. > > > Taking closer look at the code, the intention is 'recursive dependency > is error', > but the behavior changed probably by an accident. > > I fixed this: > https://patchwork.kernel.org/patch/10566301/ > >> Side note: perhaps, the documentation could be better when it comes to >> recursive dependencies. The documentation says "select" and >> "imply" can be used to specify lower limits whereas direct >> dependencies specify upper limits for symbol values and with >> this in mind, one might wonder why it is a problem to work >> with both limits in a recursive way. >> >> Not very unlikely that it is just me who still has to >> understand recursive dependencies or problems with reading >> English text, though. > > > To avoid confusion, two things should be discussed separately: > > [1] Unmet dependency > This is caused by a conflict between the upper limit from 'depends on' > and the lower limit from 'select'. > > This issue does not happen for 'imply' because the upper limit > specified by 'imply' is weaker. > > > [2] Recursive depenency > > This can happen for any combination of 'depends on', > 'select', 'imply', 'if', 'default', etc. Yes, this is probably just a subject that I still have to get a deeper understanding for, hence I am easyly confused when faced with contradicting information. >> What definitely seems to get void with your patches is item c) in >> "Practical solutions to kconfig recursive issue" in >> Documentation/kbuild/kconfig-language: >> >> c) Consider the use of "imply" instead of "select" > > > I do not know why commit 237e3ad0f195d8 added this line. > > > Actually, I was also confused. > > I sent v2 based on your feedback. Thanks for your responses, making that all more understandable. Dirk > > >> Dirk >> >>> In the code above, Kconfig cannot calculate the symbol values correctly >>> due to the circular dependency. For example, allyesconfig followed by >>> syncconfig results in an odd behavior because CONFIG_B becomes visible >>> in syncconfig. >>> >>> $ make allyesconfig >>> scripts/kconfig/conf --allyesconfig Kconfig >>> # >>> # configuration written to .config >>> # >>> $ cat .config >>> # >>> # Automatically generated file; DO NOT EDIT. >>> # Main menu >>> # >>> CONFIG_A=y >>> $ make syncconfig >>> scripts/kconfig/conf --syncconfig Kconfig >>> * >>> * Restart config... >>> * >>> * >>> * Main menu >>> * >>> a (A) [Y/n/?] y >>> b (B) [N/y/?] (NEW) >>> >>> To report this correctly, sym_check_expr_deps() should recurse to >>> not only sym->rev_dep.expr but also sym->implied.expr . >>> >>> At this moment, sym_check_print_recursive() cannot distinguish >>> 'select' and 'imply' since it does not know the precise context >>> where the recursive dependency is hit. This will be solved by >>> the next commit. >>> >>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> >>> --- >>> >>> scripts/kconfig/symbol.c | 9 +++++++-- >>> 1 file changed, 7 insertions(+), 2 deletions(-) >>> >>> diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c >>> index 4ec8b1f..7de7463a 100644 >>> --- a/scripts/kconfig/symbol.c >>> +++ b/scripts/kconfig/symbol.c >>> @@ -1098,7 +1098,7 @@ static void sym_check_print_recursive(struct symbol *last_sym) >>> sym->name ? sym->name : "<choice>", >>> next_sym->name ? next_sym->name : "<choice>"); >>> } else { >>> - fprintf(stderr, "%s:%d:\tsymbol %s is selected by %s\n", >>> + fprintf(stderr, "%s:%d:\tsymbol %s is selected or implied by %s\n", >>> prop->file->name, prop->lineno, >>> sym->name ? sym->name : "<choice>", >>> next_sym->name ? next_sym->name : "<choice>"); >>> @@ -1161,8 +1161,13 @@ static struct symbol *sym_check_sym_deps(struct symbol *sym) >>> if (sym2) >>> goto out; >>> >>> + sym2 = sym_check_expr_deps(sym->implied.expr); >>> + if (sym2) >>> + goto out; >>> + >>> for (prop = sym->prop; prop; prop = prop->next) { >>> - if (prop->type == P_CHOICE || prop->type == P_SELECT) >>> + if (prop->type == P_CHOICE || prop->type == P_SELECT || >>> + prop->type == P_IMPLY) >>> continue; >>> stack.prop = prop; >>> sym2 = sym_check_expr_deps(prop->visible.expr);
diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c index 4ec8b1f..7de7463a 100644 --- a/scripts/kconfig/symbol.c +++ b/scripts/kconfig/symbol.c @@ -1098,7 +1098,7 @@ static void sym_check_print_recursive(struct symbol *last_sym) sym->name ? sym->name : "<choice>", next_sym->name ? next_sym->name : "<choice>"); } else { - fprintf(stderr, "%s:%d:\tsymbol %s is selected by %s\n", + fprintf(stderr, "%s:%d:\tsymbol %s is selected or implied by %s\n", prop->file->name, prop->lineno, sym->name ? sym->name : "<choice>", next_sym->name ? next_sym->name : "<choice>"); @@ -1161,8 +1161,13 @@ static struct symbol *sym_check_sym_deps(struct symbol *sym) if (sym2) goto out; + sym2 = sym_check_expr_deps(sym->implied.expr); + if (sym2) + goto out; + for (prop = sym->prop; prop; prop = prop->next) { - if (prop->type == P_CHOICE || prop->type == P_SELECT) + if (prop->type == P_CHOICE || prop->type == P_SELECT || + prop->type == P_IMPLY) continue; stack.prop = prop; sym2 = sym_check_expr_deps(prop->visible.expr);
Currently, Kconfig does not report anything about the recursive dependency where 'imply' keywords are involved. [Test Code] config A bool "a" config B bool "b" imply A depends on A In the code above, Kconfig cannot calculate the symbol values correctly due to the circular dependency. For example, allyesconfig followed by syncconfig results in an odd behavior because CONFIG_B becomes visible in syncconfig. $ make allyesconfig scripts/kconfig/conf --allyesconfig Kconfig # # configuration written to .config # $ cat .config # # Automatically generated file; DO NOT EDIT. # Main menu # CONFIG_A=y $ make syncconfig scripts/kconfig/conf --syncconfig Kconfig * * Restart config... * * * Main menu * a (A) [Y/n/?] y b (B) [N/y/?] (NEW) To report this correctly, sym_check_expr_deps() should recurse to not only sym->rev_dep.expr but also sym->implied.expr . At this moment, sym_check_print_recursive() cannot distinguish 'select' and 'imply' since it does not know the precise context where the recursive dependency is hit. This will be solved by the next commit. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> --- scripts/kconfig/symbol.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)