On Fri, Mar 2, 2018 at 10:29 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote: > > > On Fri, Mar 2, 2018, 3:14 AM Ulf Magnusson <ulfalizer@xxxxxxxxx> wrote: >> >> On Fri, Mar 2, 2018 at 5:31 AM, Masahiro Yamada >> > This is complicated usage, but it is still used in the real world; >> > drivers/usb/gadget/legacy/Kconfig is source'd in a choice context, >> > then creates a sub-choice in it. >> >> That file is the only one that does all that weird choice stuff btw. >> >> It's as if it was written to make use of as much obscure Kconfig stuff >> as possible. :P > > > Can't we just use another way to describe this requirement on this file, > with the trade-off of simplifying kconfig semantics? > > Luis I don't think changing how drivers/usb/gadget/legacy/Kconfig does things would allow for any simplifications, unfortunately (except to get rid of the fix tested by this patch, maybe). Being able to have non-choice-value symbols and choices in choices is a side effect of automatic submenu creation. Symbols and choices that depend on the symbol before them end up in a submenu, and only the top-level symbols in the choice are marked as choice value symbols. I always wondered whether that was an intended feature or just something people discovered works (it seems to work anyway...). It feels pretty iffy to have cosmetic submenus affect behavior like that, but playing devil's advocate, it kinda makes sense to put symbols close to the symbols they depend on if you can get away with it. Cheers, Ulf -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
