Received-SPF: pass (google.com: domain of linux-kernel+bounces-12434-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20230817012007.131868-1-senozhatsky@chromium.org>
 <CAK7LNASJWKSsdzn5ccgWaC35-XvHGU7pnE6C=eZFDbqrrghtdQ@mail.gmail.com>
 <20230820024519.GK907732@google.com> <CAK7LNAS9KC1GjPgadMEivSpy4TMYU8mQ+BrtfJpNs2kvhK18yA@mail.gmail.com>
 <20230820072119.GM907732@google.com> <20230820073332.GN907732@google.com>
 <CAK7LNARTZXvWD8PrA3bC+Ok7LK85qO=pkMs4kOPGn90OBooL6w@mail.gmail.com>
 <20230822061203.GA610023@google.com> <CAK7LNAS0qEZk+xAq84=7SuJSQz5F3dNBjYKPoeKTd_caq-QMKg@mail.gmail.com>
 <CAAFQd5DeDEhPUQScXB67v9giiV=G33L-YDdtF4e-+UcmBXG6jA@mail.gmail.com>
 <CAK7LNATj-jnOLMkgzz=3MfqWgUjKF-MwSKQkr4hW0g7+tEsXUw@mail.gmail.com>
 <CAAFQd5AhN5m8eaGsrKfh1gHPLiOVd9_3BwoHpr7u6iY92Ft-bg@mail.gmail.com>
 <CAK7LNAR6o=K=eGzi194Ly787Ji4Twfqq3dcr8NE5m23ayGM3Fg@mail.gmail.com> <CAAFQd5DTNfNDPtvFd-=kkGYY5nduLp3SLjzNmHPgu6QfQO3ypw@mail.gmail.com>
In-Reply-To: <CAAFQd5DTNfNDPtvFd-=kkGYY5nduLp3SLjzNmHPgu6QfQO3ypw@mail.gmail.com>
From: Tomasz Figa <tfiga@chromium.org>
Date: Thu, 28 Dec 2023 14:51:55 +0900
Message-ID: <CAAFQd5BY+8O-Wj-A5sVF6SWPhpU_fyZ4c7+6XUCy6RD+Gd3Hug@mail.gmail.com>
Subject: Re: [RFC][PATCH] kconfig: introduce listunknownconfig
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>, Ying Sun <sunying@nj.iscas.ac.cn>, 
	Jesse T <mr.bossman075@gmail.com>, Nathan Chancellor <nathan@kernel.org>, 
	Nick Desaulniers <ndesaulniers@google.com>, Nicolas Schier <nicolas@fjasle.eu>, 
	Jonathan Corbet <corbet@lwn.net>, linux-kbuild@vger.kernel.org, linux-doc@vger.kernel.org, 
	linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 4, 2023 at 2:10=E2=80=AFPM Tomasz Figa <tfiga@chromium.org> wro=
te:
>
> On Fri, Sep 1, 2023 at 12:28=E2=80=AFAM Masahiro Yamada <masahiroy@kernel=
.org> wrote:
> >
> > On Thu, Aug 31, 2023 at 11:30=E2=80=AFAM Tomasz Figa <tfiga@chromium.or=
g> wrote:
> > >
> > > On Sat, Aug 26, 2023 at 10:11=E2=80=AFAM Masahiro Yamada <masahiroy@k=
ernel.org> wrote:
> > > >
> > > > On Thu, Aug 24, 2023 at 2:30=E2=80=AFPM Tomasz Figa <tfiga@chromium=
.org> wrote:
> > > > >
> > > > > Hi Masahiro,
> > > > >
> > > > > On Thu, Aug 24, 2023 at 10:00=E2=80=AFAM Masahiro Yamada <masahir=
oy@kernel.org> wrote:
> > > > > >
> > > > > > On Tue, Aug 22, 2023 at 4:30=E2=80=AFPM Sergey Senozhatsky
> > > > > > <senozhatsky@chromium.org> wrote:
> > > > > > >
> > > > > > > On (23/08/21 21:27), Masahiro Yamada wrote:
> > > > > > > >
> > > > > > > > My (original) hope was to add a single switch, KCONFIG_VERB=
OSE, to address both:
> > > > > > > >
> > > > > > > >   - A CONFIG option is hidden by unmet dependency (Ying Sun=
's case)
> > > > > > > >   - A CONFIG option no longer exists  (your case)
> > > > > > > >   - Anything else we need to be careful
> > > > > > >
> > > > > > > A quick question: is it too late to suggest an alternative na=
me?
> > > > > > > Could KCONFIG_SANITY_CHECKS be a little cleaner? Because we b=
asically
> > > > > > > run sanity checks on the config.
> > > > > >
> > > > > >
> > > > > > Ying's is not applied yet. So, it is not too late.
> > > > > >
> > > > > > But, I started to be a little worried
> > > > > > because it is unpredictable how many KCONFIG_* env
> > > > > > variables will increase until people are satisfied.
> > > > > >
> > > > >
> > > > > Is there really a problem with having those? There are a lot of
> > > > > different env variables affecting different parts of the kernel b=
uild.
> > > > > If they are useful, and even better, allow catching issues quickl=
y,
> > > > > should we favor less options or usefulness for users?
> > > >
> > > >
> > > >
> > > > I am considering how to implement it.
> > > >
> > > >
> > > >
> > > > One way is to add env variables as a new request arises.
> > > >
> > > > Sergey is doing two things by one option.
> > > >
> > > >
> > > >    KCONFIG_WARN_UNKNWON_SYMBOL : warn unknown symbol in input .conf=
ig
> > > > or defconfig
> > > >    KCONFIG_WARN_TO_ERROR       : turn warnings into errors
> > > >
> > > >
> > > >
> > > > Another way is to handle those as command line options.
> > > >
> > > >   -Wunknown-symbol
> > > >   -Werror             (associated with W=3De)
> > > >   -Wall               (associated with W=3D1)
> > > >
> > > >
> > > >
> > > >   $ make W=3D1e olddefconfig
> > > >
> > > >
> > > > will work to sanity check.
> > > >
> > > >
> > >
> > > I see, I think I misunderstood your previous message, sorry. Agreed
> > > that there could be other approaches than an environment variable and
> > > a command line option could definitely work as well. I'll leave the
> > > details to you and Sergey, but ideally we would have something that i=
s
> > > simple to use both in scripts (e.g. distro build systems) and in
> > > manual build for end users
> > >
> > > >
> > > >
> > > >
> > > > > > >
> > > > > > > And one more question: those sanity checks seem very reasonab=
le.
> > > > > > > Is there any reason we would not want to keep them ON by defa=
ult?
> > > > > > > And those brave souls, that do not wish for the tool to very =
that
> > > > > > > the .config is sane and nothing will get downgraded/disabled,=
 can
> > > > > > > always set KCONFIG_SANITY_CHECKS to 0.
> > > > > >
> > > > > >
> > > > > > Kconfig is meant to resolve the dependency without causing an e=
rror.
> > > > > > If a feature is not available, it is automatically, silently hi=
dden,
> > > > > > and that works well.
> > > > >
> > > > > How do you come to the conclusion that it works well? I've heard =
many
> > > > > people unhappy about the way Kconfig works. How does one know tha=
t
> > > > > something is missing (and should maybe be fixed?) if Kconfig sile=
ntly
> > > > > hides it?
> > > >
> > > >
> > > > Kconfig has worked like that for a long time, but I do not know
> > > > how to detect non-existing symbols.
> > > >
> > > >
> > >
> > > I think a tool to detect symbols present in old config, but missing i=
n
> > > new kernel solves the "upgraded config" part of the problem.
> > >
> > > The other part ("new config") would probably be solved by some kind o=
f
> > > a tool that looks at the currently present hardware and spews a list
> > > of Kconfig options together with their dependencies, but arguably
> > > that's not something that would be a part of Kconfig itself.
> > >
> > > For the graphical configuration tools like menuconfig I could imagine
> > > that the options with unmet dependencies could be still displayed but
> > > greyed out, so at least one can open the help for the item and check
> > > which dependencies are missing.
> >
> >
> > Yes. That idea exists, and at least for xconfig,
> > I got a patch to grey out hidden options.
> >
> > https://lore.kernel.org/linux-kbuild/20200708133015.12286-1-maxime.chre=
tien@bootlin.com/
> >
> >
> > I liked the idea, and suggested improvements, but did not receive v2.
> >
> > Maybe I could revisit it when I have some time,
> > but I always have TODOs more than my capacity.
> >
>
> Let me see if I can do something about it. It sounds like a very
> convenient thing, although I'd definitely prefer menuconfig over
> xconfig.

To close the loop, it took me a while to find some time to give it a
stab, but here is a patch:

https://lore.kernel.org/linux-kbuild/20231228054630.3595093-1-tfiga@chromiu=
m.org/T/#u

One thing that may need to be added is a toggle for the new behavior
if there are people who prefer all the options to look the same (or
just the dim text is problematic for some reason).

Best,
Tomasz