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.