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

On Tue, Aug 22, 2023 at 4:30 PM Sergey Senozhatsky
[off-list ref] wrote:

On (23/08/21 21:27), Masahiro Yamada wrote:

quoted

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