summaryrefslogtreecommitdiff
path: root/block/blk-lib.c
diff options
context:
space:
mode:
authorMasahiro Yamada <masahiroy@kernel.org>2020-04-24 08:49:29 +0300
committerMasahiro Yamada <masahiroy@kernel.org>2020-05-12 07:28:30 +0300
commit09d5873e4d1f70202314b5fe40160f9b14b9d2d0 (patch)
tree6f21c588ba56481e082ee31cdab1ee91fb5b842c /block/blk-lib.c
parentb7546111a43a0fc75d9de4f7bce2104d6eb9d2b9 (diff)
downloadlinux-09d5873e4d1f70202314b5fe40160f9b14b9d2d0.tar.xz
kconfig: allow only 'config', 'comment', and 'if' inside 'choice'
The code block surrounded by 'if' ... 'endif' is reduced into if_stmt, which is accepted in the 'choice' context. Therefore, you can write any statements within a choice block by wrapping 'if y' ... 'end'. For example, you can create a menu inside a choice, like follows: ---------------->8---------------- choice prompt "choice" config A bool "A" config B bool "B" if y menu "strange menu" config C bool "C" endmenu endif endchoice ---------------->8---------------- I want to change such a weird structure into a syntax error. In fact, the USB gadget Kconfig had used nested 'choice' for no good reason until commit df8df5e4bc37 ("usb: get rid of 'choice' for legacy gadget drivers") killed it. I think the 'source' inside 'choice' is on the fence. It is at least gramatically sensible as long as the included file contains only bool/tristate configs. However, it makes the code unreadable, and people tend to forget the fact that the file is included from the choice block. Commit 10e5e6c24963 ("usb: gadget: move choice ... endchoice to legacy/Kconfig") got rid of the only usecase. Going forward, you can only use 'config', 'comment', and 'if' inside 'choice'. This also recursively applies to 'if' blocks inside 'choice'. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Diffstat (limited to 'block/blk-lib.c')
0 files changed, 0 insertions, 0 deletions