linux-kernel - Re: [PATCH v2 5/7] streamline_config.pl: fix: implement choice for kconfigs

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]

Message-ID: <CAK7LNARv+2r1v8t8HwjzQVQqz4M+-WUn52XL+jb1=0OgHqOY5A@mail.gmail.com>
Date: Sat, 30 Nov 2024 18:41:12 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: David Hunter <david.hunter.linux@...il.com>
Cc: linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org, 
	shuah@...nel.org, javier.carrasco.cruz@...il.com, 
	Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH v2 5/7] streamline_config.pl: fix: implement choice for kconfigs

On Wed, Nov 27, 2024 at 10:18 PM David Hunter
<david.hunter.linux@...il.com> wrote:
>
> On 11/5/24 18:33, Masahiro Yamada wrote:
> > I previously suggested checking how the 'if' statement is handled.
> > https://lore.kernel.org/lkml/CAK7LNAQ8D4OVT81iTVs8jjrBXX6Zgwc+VJ_vb7hb4J-vCZZN=g@mail.gmail.com/
> >
> I think I understand now what you were saying. I misunderstood what you
> were saying because I thought that you were saying that the "if" blocks
> were not implemented.
>
> To paraphrase, I believe that you are saying that the "choice" blocks
> should have a similar style to the "if" blocks.
>
> I will take a look at the patch that you sent and figure out how it
> would work. I would like some clarification on the information in the
> choice blocks that are not "depends." Should those also have the same
> style as the "if" block?
>

I am not sure if I understood your question correctly, but I guess you are
referring to the similarity between the following two constructs:


[1]
choice
      prompt "choice"
      depends on X

     [ code block]

endchoice



[2]
if X

   [code block]

endif



choice  ...  endchoice
if    ...   endif
are similar in the sense that they both define a code block.


The if ... endif construct is always associated with a dependency.

The choice ... endchoice construct can optionally have a 'depends on'
statement. If it does, the dependency is applied to the entire code block
within choice ... endchoice.






> I am not sure if you saw this email:
> https://lore.kernel.org/all/994efba2-2829-4874-b5fa-9f5317f6ea6b@gmail.com/
>
> There are lots of information, specifically "prompts" and "defaults"
> that are distributed to each of the config options in the "choice" blocks.

- A choice entry cannot have a 'select' property.

- A choice entry should always have 'prompt', otherwise
   the choice statement is non-sense.

- A choice entry can optionally have 'default'.
 If 'default' is not explicitly specified, the first CONFIG option within
  the choice block is the default.

- A choice entry can optionally have 'depends on'.








> >
> > BTW, 'menu' also can have 'depends on'.
> >
> >
> > menu "menu"
> >           depends on FOO
> > config A
> >             bool "A"
> > config B
> >             bool "B"
> > endmenu
> >
> >
> > This is not implemented, either.
> >
> > I am not sure how much effort should be invested in this script, though.
> >
> >
> I will look into distributing the "menu" information.



-- 
Best Regards
Masahiro Yamada