lkml.org 
[lkml]   [2018]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH 0/3] kbuild: support syncing .config non-interactively and record ARCH in spec file
From
Date
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


[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2018-09-08 00:06    [W:0.038 / U:2.304 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site