On Mon, Sep 4, 2023 at 2:10 PM Tomasz Figa <tfiga@xxxxxxxxxxxx> wrote:
>
> 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.
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@xxxxxxxxxxxx/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
