[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 11 Apr 2018 09:09:02 -0700
From: Kees Cook <keescook@...omium.org>
To: Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc: linux-kbuild <linux-kbuild@...r.kernel.org>, Sam Ravnborg <sam@...nborg.org>,
Linus Torvalds <torvalds@...ux-foundation.org>, Arnd Bergmann <arnd@...db.de>,
Ulf Magnusson <ulfalizer@...il.com>, Thomas Gleixner <tglx@...utronix.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Randy Dunlap <rdunlap@...radead.org>,
"Luis R . Rodriguez" <mcgrof@...nel.org>, Nicolas Pitre <nico@...aro.org>, LKML <linux-kernel@...r.kernel.org>,
Kernel Hardening <kernel-hardening@...ts.openwall.com>, Emese Revfy <re.emese@...il.com>
Subject: Re: [PATCH v2 19/21] gcc-plugins: test GCC plugin support in Kconfig
On Wed, Apr 11, 2018 at 8:55 AM, Masahiro Yamada
<yamada.masahiro@...ionext.com> wrote:
> No.
> There is no problem to use a compiler without plugin support.
>
> If a user does not want to use plugin in the first place,
> why does he/she need to be bothered by such information in stderr?
So, I don't think it's needed for the first version of this, but it'd
be nice to have a way for end users to discover _why_ some option they
want is unavailable. Having them dig through the Kconfigs, edit
scripts to see stderr again, running those by hand, etc, is really
unfriendly. If, instead, stderr was visible from the menuconfig "help"
for a Kconfig, it could serve as automatic documentation for why
something wasn't enabled. I don't mean for stderr to get sprayed out
during a regular "make"; I agree: that would be ugly and pointless.
I'd just like some way for the reason behind an option being disabled
to be discoverable in some way.
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
