linux-kernel - Re: [RFC PATCH 0/3] kbuild: support syncing .config non-interactively and record ARCH in spec file

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]

Date:   Fri, 7 Sep 2018 18:05:23 -0400
From:   Jeff Mahoney <jeffm@...e.com>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>,
        linux-kbuild@...r.kernel.org
Cc:     Sam Ravnborg <sam@...nborg.org>,
        Javier Martinez Canillas <javierm@...hat.com>,
        Laura Abbott <labbott@...hat.com>,
        Jiri Kosina <jkosina@...e.cz>,
        Ben Hutchings <ben.hutchings@...ethink.co.uk>,
        Michal Such���nek <msuchanek@...e.de>,
        Takashi Iwai <tiwai@...e.de>, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org, Jonathan Corbet <corbet@....net>,
        Michal Marek <michal.lkml@...kovi.net>
Subject: Re: [RFC PATCH 0/3] kbuild: support syncing .config non-interactively
 and record ARCH in spec file

On 9/3/18 6:01 AM, Masahiro Yamada wrote:
> This work was prompted by the criticism about the recent Kconfig change:
> https://lkml.org/lkml/2018/6/27/254
> 
> I may not fully understand his concern, though.

I don't think you do.

Here's the use case for us and, I expect, most distro kernel maintainers
out there.  We build kernels on 8 architectures, with 3 or more configs
for each architecture.  Each product release uses a different build
environment.  Between SLE and openSUSE we have 6 build environments at
the moment.  Our update process for configs is to run a script that adds
the change to every affected config and then run a script that does a
'make oldconfig' on every architecture/config combination to sync them
up and ensure options that may have been enabled by the change are
synced up.  Those changes are also automatically propagated to other
configs.  The config updates can be done on pretty much any linux system
capable of building a kernel.  This is a process that has worked for us
for at least 15 years.  It doesn't now with the GCC_VERSION changes.
Today, I went to do a simple config change: disable an option on every
arch/config combination for a single branch (that wasn't the one that
matched the build environment of the running system) and instead of it
running more or less silently as it has for years, it wanted to change
all the compiler options.  Of course, those changes shouldn't be pushed
to the repository because they'll be wrong for the build environment.
In this simple example it was easy to just modify the option in-place,
but it would've been painful if I was enabling an option that guarded
other new options instead.

Lastly, we fail our builds if there are unresolved config options.  A
build that silently ignored them and accepted defaults isn't something
we'd use.  Otherwise, we could start our builds with yes '' | make
oldconfig and be done with it.

Requiring the config to be generated using the same environment that
will ultimately build the kernel is a huge usability regression for us
and, I would assume, others.

-Jeff
-- 
Jeff Mahoney
SUSE Labs

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)