Re: [RFC][PATCH] kconfig: introduce listunknownconfig

[Tomasz Figa]

On Fri, Sep 1, 2023 at 12:28 AM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote:
>
> On Thu, Aug 31, 2023 at 11:30 AM Tomasz Figa <tfiga@xxxxxxxxxxxx> wrote:
> >
> > On Sat, Aug 26, 2023 at 10:11 AM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote:
> > >
> > > On Thu, Aug 24, 2023 at 2:30 PM Tomasz Figa <tfiga@xxxxxxxxxxxx> wrote:
> > > >
> > > > Hi Masahiro,
> > > >
> > > > On Thu, Aug 24, 2023 at 10:00 AM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote:
> > > > >
> > > > > On Tue, Aug 22, 2023 at 4:30 PM Sergey Senozhatsky
> > > > > <senozhatsky@xxxxxxxxxxxx> wrote:
> > > > > >
> > > > > > On (23/08/21 21:27), Masahiro Yamada wrote:
> > > > > > >
> > > > > > > My (original) hope was to add a single switch, KCONFIG_VERBOSE, 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 name?
> > > > > > Could KCONFIG_SANITY_CHECKS be a little cleaner? Because we basically
> > > > > > 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 build.
> > > > If they are useful, and even better, allow catching issues quickly,
> > > > 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 .config
> > > 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=e)
> > >   -Wall               (associated with W=1)
> > >
> > >
> > >
> > >   $ make W=1e 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 is
> > 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 reasonable.
> > > > > > Is there any reason we would not want to keep them ON by default?
> > > > > > 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 error.
> > > > > If a feature is not available, it is automatically, silently hidden,
> > > > > 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 that
> > > > something is missing (and should maybe be fixed?) if Kconfig silently
> > > > 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 in
> > new kernel solves the "upgraded config" part of the problem.
> >
> > The other part ("new config") would probably be solved by some kind of
> > 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.chretien@xxxxxxxxxxx/
>
>
> 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.

>
>
> Anyway, I applied Sergey's patch, so the life of you guys
> will get a little easier.

Thanks a lot!

Best regards,
Tomasz