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

[Masahiro Yamada]

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.



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



--
Best Regards
Masahiro Yamada