public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Michal Marek <mmarek@suse.cz>,
	"Yann E. MORIN" <yann.morin.1998@free.fr>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Darren Hart <dvhart@linux.intel.com>,
	linux-kbuild@vger.kernel.org,
	kernel-build-reports@lists.linaro.org,
	Michal Marek <mmarek@suse.com>,
	Thiago Macieira <thiago.macieira@intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [RFC] Kbuild: avoid "make tinyconfig" warnings
Date: Wed, 6 Jul 2016 11:32:50 -0700	[thread overview]
Message-ID: <20160706183250.GA28362@x> (raw)
In-Reply-To: <7677316.bvNVmygFDv@wuerfel>

On Wed, Jul 06, 2016 at 03:56:25PM +0200, Arnd Bergmann wrote:
> On Monday, July 4, 2016 12:58:15 PM CEST Josh Triplett wrote:
> > On Mon, Jul 04, 2016 at 12:51:56PM -0700, Josh Triplett wrote:
> > > On Mon, Jul 04, 2016 at 04:25:55PM +0200, Arnd Bergmann wrote:
> > > > The introduction of "make *.config" as a shorthand for merging configuration
> > > > files unfortunately introduced some build warnings that we see in every
> > > > single run of the various build bots testing tinyconfig:
> > > > 
> > > > .config:966:warning: override: NOHIGHMEM changes choice state
> > > > .config:965:warning: override: SLOB changes choice state
> > > > .config:963:warning: override: KERNEL_XZ changes choice state
> > > > .config:962:warning: override: CC_OPTIMIZE_FOR_SIZE changes choice state
> > > > .config:933:warning: override: SLOB changes choice state
> > > > .config:930:warning: override: CC_OPTIMIZE_FOR_SIZE changes choice state
> > > > .config:870:warning: override: SLOB changes choice state
> > > > .config:868:warning: override: KERNEL_XZ changes choice state
> > > > .config:867:warning: override: CC_OPTIMIZE_FOR_SIZE changes choice state
> > > > 
> > > > This changes the behavior for tinyconfig again, so we call the special
> > > > allnoconfig target directly, with the fragment as the KCONFIG_ALLCONFIG
> > > > file so it gets merged into the configuration. The disadvantage of
> > > > this approach is that we cannot pass another KCONFIG_ALLCONFIG on
> > > > the command line, that would again have to be done using the mergeconfig
> > > > script afterwards.
> > > > 
> > > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > > Fixes: 63a91033d52e ("kbuild: add generic mergeconfig target, %.config")
> > > > Link: https://storage.kernelci.org/mainline/v4.7-rc6/x86-tinyconfig/build.log
> > > 
> > > Thanks for fixing this.
> > > Reviewed-by: Josh Triplett <josh@joshtriplett.org>
> > > 
> > > As another possibility, which would preserve the ability to use
> > > KCONFIG_ALLCONFIG, what about adding a parameter to mergeconfig to
> > > disable this warning?  I've seen many other uses of mergeconfig in
> > > production systems that have the same problem.
> > 
> > Actually, I just realized something: does this actually do the right
> > thing if both tiny.config files exist?  The documentation for
> > KCONFIG_ALLCONFIG doesn't suggest that it can take two files as
> > arguments.  And if it can, this also need quotes; otherwise, this will
> > expand to "... allnoconfig KCONFIG=path/to/a/tiny.config
> > another/path/to/a/tiny.config".
> 
> You are right, my patch doesn't work.
> 
> I can think of a few other ways to work around this, though none seems
> perfect:
> 
> - add a flag to the kconfig tool to ignore 'choice' symbol overrides and not
>   warn about them (as you suggested). This may be problematic if there
>   are cases in which the warning is actually helpful.

As long as this remains an option and not the default, I don't think it
would cause problems.

> - drop the feature of allowing multiple tiny.config files to be combined
>   and instead have the x86 file include everything from the architecture
>   independent file. This would only be a small annoyance, but it doesn't
>   solve the other cases you mention in which we see similar warnings.

And I'd rather not duplicate the base config into every
architecture-specific tiny.config; that'll become even more problematic
if other architectures add their own.

> - change merge_config.sh to do a 'savedefconfig' step before applying
>   the fragment, so it doesn't warn about choice statements that are
>   overridden from their default, as opposed to having conflicting choices.

This sounds like a potentially interesting approach.  This would produce
warnings only if overriding explicit configuration, but not when
changing a choice from the implicit default?

- Josh Triplett

  reply	other threads:[~2016-07-06 18:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-04 14:25 [PATCH] [RFC] Kbuild: avoid "make tinyconfig" warnings Arnd Bergmann
2016-07-04 19:51 ` Josh Triplett
2016-07-04 19:58   ` Josh Triplett
2016-07-06 13:56     ` Arnd Bergmann
2016-07-06 18:32       ` Josh Triplett [this message]
2016-07-06 19:58         ` Arnd Bergmann
2016-07-06  2:00 ` Masahiro Yamada
2016-07-06 13:49   ` Arnd Bergmann
2016-07-08  1:41     ` Masahiro Yamada
2016-07-08 11:50       ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160706183250.GA28362@x \
    --to=josh@joshtriplett.org \
    --cc=arnd@arndb.de \
    --cc=dvhart@linux.intel.com \
    --cc=kernel-build-reports@lists.linaro.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mmarek@suse.com \
    --cc=mmarek@suse.cz \
    --cc=thiago.macieira@intel.com \
    --cc=yamada.masahiro@socionext.com \
    --cc=yann.morin.1998@free.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox