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. > > 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. When a compiler does not support a particular feature, 'depends on $(cc-option )' hides that CONFIG option. Kconfig is meant to work like that. For your case, it is case-by-case. Let's say a stale code is removed from upstream. After "obj-$(CONFIG_FOO) += foo.o" is removed from upstream, CONFIG_FOO in the .config is a "don't care". If it were an error, all arch/*/configs/*_defconfig must be cleaned up at the same time. So, sometimes it is helpful, but sometimes noisy. For the MFD_RK808 case particularly, I believe Kconfig showed MFD_RK8XX_I2C as a new option. Or, when you bumped to a new kernel version, you could run 'make listnewconfig'. (See 17baab68d337a0bf4654091e2b4cd67c3fdb44d8. Redhat says they review every new config option.) If you had done a per-config review you would have noticed c20e8c5b1203af3726561ee5649b147194e0618e before spending time on run-time debugging. -- Best Regards Masahiro Yamada
