linux-kernel - Re: Toolchain-dependent config options

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20210114145711.3yfx2x6snjij3bxl@treble>
Date:   Thu, 14 Jan 2021 08:57:11 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Bernd Petrovitsch <bernd@...rovitsch.priv.at>
Cc:     Masahiro Yamada <masahiroy@...nel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Toolchain-dependent config options

On Thu, Jan 14, 2021 at 12:55:26PM +0100, Bernd Petrovitsch wrote:
> Hi all!
> 
> On Thu, 2021-01-14 at 13:56 +0900, Masahiro Yamada wrote:
> > On Thu, Jan 14, 2021 at 7:21 AM Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> [...]
> > > If I copy a config with CONFIG_GCC_PLUGINS to another system which
> > > doesn't have the gcc-plugin-devel package, it gets silently disabled by
> > > "make olddefconfig".
> > > 
> > > I've seen multiple cases lately where this is causing confusion.  I
> > > suspect the problem is getting worse with recent added support for a
> > > variety of toolchains and toolchain-dependent features.
> > > 
> > > Would it be possible to have an error (or at least a warning) in this
> > > case?
> > > 
> > > For example, a "depends-error" which triggers an error if its failure
> > > would disable a feature?
> [...]
> > We disable any feature that is unsupported by the compiler in use.
> > 
> > Conventionally, we did that in the top Makefile
> > by using $(call cc-option, ) macro or by running some scripts.
> > 
> > Recently, we are moving such compiler tests to the Kconfig stage.
> > 
> > Anyway, we disable unsupported features so any combination
> > of CONFIG options builds successfully.
> > This will ease randconfg and allmodconfig tests.
> 
> For options of $CC, that makes sense since there are different
> compilers and lots of versions of them out there.
> 
> > A lot of people and CI systems are running allmodconfig tests
> > for various architectures and toolchains.
> 
> Isn't some kind of defying (or more killing) the usefulness
> of regression compile runs if one does `make allmodconfig`
> and some (lots?) of stuff gets automatically configured
> out just because some
> -dev(|el) package is missing?

Right, it sort of defeats the purpose of CI if new toolchain-dependent
features never get tested.  There needs to be some way to alert the user
they're not testing everything, despite "allyesconfig".

I suppose such config options can stop using this new "depends on
some_script" feature and just do it the old-fashioned way with an
$(error) in the makefile.

-- 
Josh