From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Tomasz Figa <tfiga@chromium.org>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
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>,
linux-kbuild@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] kconfig: introduce listunknownconfig
Date: Sat, 26 Aug 2023 11:10:54 +0900 [thread overview]
Message-ID: <20230826021054.GE3913@google.com> (raw)
In-Reply-To: <CAK7LNATj-jnOLMkgzz=3MfqWgUjKF-MwSKQkr4hW0g7+tEsXUw@mail.gmail.com>
On (23/08/26 10:10), Masahiro Yamada wrote:
>
> 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.
Sounds good. Being able to choose whether those sanity checks are
warnings or errors is quite handful.
I don't have preferences as to implementation. Env variables seem to
have very clear and descriptive names. Command line options look fine
too. I'd probably prefer command line args.
next prev parent reply other threads:[~2023-08-26 2:12 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
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 [this message]
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=20230826021054.GE3913@google.com \
--to=senozhatsky@chromium.org \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=mr.bossman075@gmail.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=nicolas@fjasle.eu \
--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.