linux-kernel - Re: [PATCH v2 09/11] kconfig: unittest: test randconfig for choice in choice

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 6 Mar 2018 18:36:50 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Ulf Magnusson <ulfalizer@...il.com>
Cc:     "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Sam Ravnborg <sam@...nborg.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        Randy Dunlap <rdunlap@...radead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 09/11] kconfig: unittest: test randconfig for choice in choice

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