2018-03-03 18:34 GMT+09:00 Ulf Magnusson <ulfali...@gmail.com>:
> On Fri, Mar 2, 2018 at 10:29 PM, Luis R. Rodriguez <mcg...@kernel.org> wrote:
>> On Fri, Mar 2, 2018, 3:14 AM Ulf Magnusson <ulfali...@gmail.com> 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).

We could also revert 3b9a19e08960e5cd.  :)

> 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.

I am happy to drop this test
if removing the seem-to-work feature will clean up the code.

Now I am accumulating test cases.

Best Regards
Masahiro Yamada

Reply via email to