linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values
Date: Fri, 19 Feb 2016 22:14:57 +0100	[thread overview]
Message-ID: <3612170.sHbTTc5Sc9@wuerfel> (raw)
In-Reply-To: <20160219180725.GB19428@n2100.arm.linux.org.uk>

On Friday 19 February 2016 18:07:25 Russell King - ARM Linux wrote:
> On Fri, Feb 19, 2016 at 12:31:02PM -0500, Nicolas Pitre wrote:
> > Yet, the only reason for a default here is to accommodate automatic 
> > build tests like randconfig, right?
> > 
> > If so then this should be "fixed" by having the config system provide 
> > built-in symbols that can be tested from kconfig files.  This way you 
> > could terminate the above list with:
> > 
> > 	default 0x00000000 if RANDCONFIG || ALLYESCONFIG
> > 
> > or the like.
> 
> I've suggested in the past that we have kconf read a seed file for
> these configurations.  kconf already has most of the required support
> for this, we just need to teach it where to read it from.  Maybe
> something like this.
> 
>  arch/arm/allrandom.config |  1 +
>  scripts/kconfig/conf.c    | 61 ++++++++++++++++++++++++++++++++++++++---------
>  2 files changed, 51 insertions(+), 11 deletions(-)

Interesting, I had never noticed that we had the infrastructure to have
separate presets for allno/allmod/allyes/...config by file name,
aside from the ${KCONFIG_ALLCONFIG}, I think your extension to make
it architecture specific is a very good idea, and it can solve a
couple of other problems as well, such as new toolchains barfing
on -march=armv3 and OABI support.

There is a bit of overlap with the Kconfig fragments, which are
defined in a similar way:

> diff --git a/arch/arm/allrandom.config b/arch/arm/allrandom.config
> index e69de29bb2d1..5a70ef5926f5 100644
> --- a/arch/arm/allrandom.config
> +++ b/arch/arm/allrandom.config
> @@ -0,0 +1 @@
> +CONFIG_PHYS_OFFSET=0

With the recently added Kconfig fragments support, you could do
(almost) the same thing by specifying

make randconfig allrandom.config

"almost", because

- The fragments use a search path including kernel/config/*.config
  and arch/*/configs/*.config, rather than arch/*/*.config
  I would prefer using the search path we have for the fragments now.

- The current implementation does not start out with the symbols
  from the fragment but instead applies the fragments one by one
  after the initial config, so the example above is the same as

	make randconfig
	make allrandom.config

  which does not have the same results. For this, I think starting
  with the fragment makes more sense, but that unfortunately requires
  changing the command line interface if we want to generalize it.

	Arnd

  reply	other threads:[~2016-02-19 21:14 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-18 14:01 [PATCH 0/9] ARM: randconfig testing fallout Arnd Bergmann
2016-02-18 14:01 ` [PATCH 1/9] ARM: ARMv7-M uses BE-8, not BE-32 Arnd Bergmann
2016-02-18 16:06   ` Nicolas Pitre
2016-02-18 16:12     ` Arnd Bergmann
2016-02-19  8:47       ` Vladimir Murzin
2016-02-19 10:17         ` Arnd Bergmann
2016-02-18 14:01 ` [PATCH 2/9] ARM: change NR_IPIS to 8 Arnd Bergmann
2016-02-18 14:26   ` Marc Zyngier
2016-02-18 14:37   ` Russell King - ARM Linux
2016-02-18 15:18     ` Arnd Bergmann
2018-09-18  8:19       ` Chunyan Zhang
2016-02-18 14:01 ` [PATCH 3/9] ARM: make free_memmap as __init Arnd Bergmann
2016-02-18 15:55   ` Nicolas Pitre
2016-02-18 14:01 ` [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values Arnd Bergmann
2016-02-18 16:02   ` Nicolas Pitre
2016-02-19  8:33     ` Arnd Bergmann
2016-02-19 14:29       ` Chris Brandt
2016-02-19 15:34         ` Arnd Bergmann
2016-02-19 16:43           ` Russell King - ARM Linux
2016-02-19 17:18             ` Chris Brandt
2016-02-19 17:57             ` Nicolas Pitre
2016-02-19 16:10       ` Nicolas Pitre
2016-02-19 16:23         ` Arnd Bergmann
2016-02-19 17:31           ` Nicolas Pitre
2016-02-19 18:07             ` Russell King - ARM Linux
2016-02-19 21:14               ` Arnd Bergmann [this message]
2016-02-18 14:01 ` [PATCH 5/9] ARM: atags_to_fdt: don't warn about stack size Arnd Bergmann
2016-02-18 16:13   ` Nicolas Pitre
2016-02-18 16:26     ` [PATCH v2] " Arnd Bergmann
2016-02-18 17:14       ` Nicolas Pitre
2016-02-19 16:58       ` Arnd Bergmann
2016-02-18 14:01 ` [PATCH 6/9] ARM: uaccess: avoid warning for NOMMU in access_ok Arnd Bergmann
2016-02-18 16:15   ` Nicolas Pitre
2016-02-18 14:01 ` [PATCH 7/9] ARM: move NO_DMA definition to ecard.h Arnd Bergmann
2016-02-18 16:17   ` Nicolas Pitre
2016-02-18 14:02 ` [PATCH 8/9] ARM: do not use optimized do_div for ARMv3 Arnd Bergmann
2016-02-18 17:20   ` Nicolas Pitre
2016-02-19  9:03     ` Arnd Bergmann
2016-02-19 18:44       ` Nicolas Pitre
2016-02-18 14:02 ` [PATCH 9/9] ARM: fix kprobe test with CONFIG_CPU_32v3 Arnd Bergmann
2016-02-18 14:21   ` Jon Medhurst (Tixy)
2016-02-18 16:21   ` Nicolas Pitre

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=3612170.sHbTTc5Sc9@wuerfel \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).