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-next>] [day] [month] [year] [list]

Date:   Sat, 3 Mar 2018 10:34:53 +0100
From:   Ulf Magnusson <ulfalizer@...il.com>
To:     "Luis R. Rodriguez" <mcgrof@...nel.org>
Cc:     Masahiro Yamada <yamada.masahiro@...ionext.com>,
        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

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

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