All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masahiro Yamada <masahiroy@kernel.org>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Ying Sun <sunying@nj.iscas.ac.cn>,
	Jesse T <mr.bossman075@gmail.com>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Nicolas Schier <nicolas@fjasle.eu>,
	Jonathan Corbet <corbet@lwn.net>,
	Tomasz Figa <tfiga@chromium.org>,
	linux-kbuild@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] kconfig: introduce listunknownconfig
Date: Thu, 24 Aug 2023 10:00:11 +0900	[thread overview]
Message-ID: <CAK7LNAS0qEZk+xAq84=7SuJSQz5F3dNBjYKPoeKTd_caq-QMKg@mail.gmail.com> (raw)
In-Reply-To: <20230822061203.GA610023@google.com>

On Tue, Aug 22, 2023 at 4:30 PM Sergey Senozhatsky
<senozhatsky@chromium.org> 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

  reply	other threads:[~2023-08-24  1:01 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-17  1:19 [RFC][PATCH] kconfig: introduce listunknownconfig Sergey Senozhatsky
2023-08-17  3:44 ` Sergey Senozhatsky
2023-08-19 23:19 ` Masahiro Yamada
2023-08-20  2:45   ` Sergey Senozhatsky
2023-08-20  4:58     ` Sergey Senozhatsky
2023-08-20  5:11     ` Masahiro Yamada
2023-08-20  7:21       ` Sergey Senozhatsky
2023-08-20  7:33         ` Sergey Senozhatsky
2023-08-21 12:27           ` Masahiro Yamada
2023-08-21 16:08             ` Sergey Senozhatsky
2023-08-22  6:12             ` Sergey Senozhatsky
2023-08-24  1:00               ` Masahiro Yamada [this message]
2023-08-24  1:20                 ` Sergey Senozhatsky
2023-08-26  1:12                   ` Masahiro Yamada
2023-08-26  5:38                     ` Masahiro Yamada
2023-08-26  5:53                       ` Sergey Senozhatsky
2023-08-24  1:51                 ` Tomasz Figa
2023-08-26  1:10                   ` Masahiro Yamada
2023-08-26  2:10                     ` Sergey Senozhatsky
2023-08-30  7:30                     ` Tomasz Figa
2023-08-31 15:28                       ` Masahiro Yamada
2023-09-04  5:10                         ` Tomasz Figa
2023-12-28  5:51                           ` Tomasz Figa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAK7LNAS0qEZk+xAq84=7SuJSQz5F3dNBjYKPoeKTd_caq-QMKg@mail.gmail.com' \
    --to=masahiroy@kernel.org \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mr.bossman075@gmail.com \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=nicolas@fjasle.eu \
    --cc=senozhatsky@chromium.org \
    --cc=sunying@nj.iscas.ac.cn \
    --cc=tfiga@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.