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