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? > > > > 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? > > 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. > I'd argue that clean up should actually happen. An identically named option could be added in the future again and mean something different and would end up accidentally selected by those old defconfigs. > > 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. Among tens or hundreds of other new options. Good luck making sure that you didn't miss it. > > Or, when you bumped to a new kernel version, > you could run 'make listnewconfig'. > (See 17baab68d337a0bf4654091e2b4cd67c3fdb44d8. > Redhat says they review every new config option.) > What is the listnewconfig supposed to show? Regardless of that, shouldn't we strive to automate things rather than just put people at those and wasting the time they could spend on something more productive? > > If you had done a per-config review > you would have noticed > c20e8c5b1203af3726561ee5649b147194e0618e > before spending time on run-time debugging. > Instead, I'd have spent time on researching every single new Kconfig option just to realize that I don't care about it, except the single one that I needed. In fact, it wouldn't have even guaranteed tracking down the problem, because I don't necessarily have to know all the config options that are necessary for my board - how do you associate some MFD driver Kconfig option with an SD/MMC controller not working? Best regards, Tomasz > > > > -- > Best Regards > Masahiro Yamada
