Re: [PATCH v2 6/7] streamline_config.pl: process config options set to "y"

Masahiro Yamada
2024-11-05T23:44:56Z

On Wed, Oct 16, 2024 at 8:19 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Mon, 14 Oct 2024 10:13:36 -0400
> David Hunter <david.hunter.linux@gmail.com> wrote:
>
> > An assumption made in this script is that the config options do not need
> > to be processed because they will simply be in the new config file. This
> > assumption is incorrect.
> >
> > Process the config entries set to "y" because those config entries might
> > have dependencies set to "m". If a config entry is set to "m" and is not
> > loaded directly into the machine, the script will currently turn off
> > that config entry; however, if that turned off config entry is a
> > dependency for a "y" option. that means the config entry set to "y"
> > will also be turned off later when the conf executive file is called.
> >
> > Here is a model of the problem (arrows show dependency):
> >
> > Original config file
> > Config_1 (m) <-- Config_2 (y)
> >
> > Config_1 is not loaded in this example, so it is turned off.
> > After scripts/kconfig/streamline_config.pl, but before scripts/kconfig/conf
> > Config_1 (n) <-- Config_2 (y)
> >
> > After scripts/kconfig/conf
> > Config_1 (n) <-- Config_2 (n)
>
> Hmm, can you show the example of this. My worry here is that there are a
> lot of cases that have:
>
> Config_1 (m) <-- Config_2 (y)
>
> Where Config_2 is just some binary option to modify the module set by
> Config_1. If we keep Config_1 because there's some 'y' that selects it, we
> are going to keep a lot of unused modules around.

Basically, there is no good way to distinguish
in-module option (just CONFIG_BCACHEFS_SIX_OPTIMISTIC_SPIN=y,
which is a property for CONFIG_BCACHEFS=m) from real dependency.

> >
> > It should also be noted that any module in the dependency chain will
> > also be turned off, even if that module is loaded directly onto the
> > computer. Here is an example:
> >
> > Original config file
> > Config_1 (m) <-- Config_2 (y) <-- Config_3 (m)
>
> If Config_3 is used, then it should add Config_2 as a dependency. I guess
> that's what this patch does.

Agree, but I am not sure how to pick up only this case.

--
Best Regards
Masahiro Yamada