On Sun, Feb 27, 2022 at 6:38 AM Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote:
>
> On Sat, Feb 26, 2022 at 2:34 PM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote:
> >
> > The .config file uses "# CONFIG_FOO is not set" form to represent
> > disabled options. In the old days, it was useful because the .config
> > was directly included from Makefiles. For example, you can use
> > "ifdef CONFIG_FOO" in Makefiles to check if the option is enabled.
> >
> > Commit c955ccafc38e ("kconfig: fix .config dependencies") introduced
> > include/config/auto.conf, which mirrors the .config, but trims down
> > all disabled options.
> >
> > Since then, include/config/auto.conf defines CONFIG options during the
> > build. The .config is used just for storing the user's configuration.
> > I do not see a strong reason to use a particular pattern of comment
> > for disabled options.
> >
> > With this commit, Kconfig will output disable options in a more natural
> > form, "CONFIG_FOO=n".
> >
> > Kconfig accepts both "# CONFIG_FOO is not set" and "CONFIG_FOO=n" as a
> > valid input. You do not need to update arch/*/configs/*_defconfig files
> > for now. "git bisect" should be able to cross the commit in both ways
> > without any issue.
> >
>
> Good.
>
> Lot of people use/used the notation CONFIG_FOO=n, so did I.
>
> Thanks for keeping the "compatibility" with old usage "# CONFIG_FOO is not set".
>
> Normally, I use git diff (or scripts/diffconfig in Git tree) to
> compare two kernel-configs, so seeing
>
> -CONFIG_FOO=y
> +CONFIG_FOO=n
>
> ...might be at first view unfamiliar/unusual.
> With the old notation it was easier to see that Kconfig is unset.
I agree on this point.
"is not set" stands out much better than "=n",
and our eyes are accustomed to this notation for 20 years.
However, real comments do not stand out since
we already (ab)use comments for disabled options.
This is related thread
https://patchwork.kernel.org/project/linux-kbuild/patch/20211213100043.45645-3-arielmarcovitch@xxxxxxxxx/
>
> Is this patch on top of kbuild-next Git?
>
Yes.
