From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1427372AbcBSVPh (ORCPT ); Fri, 19 Feb 2016 16:15:37 -0500 Received: from mout.kundenserver.de ([217.72.192.75]:62988 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423430AbcBSVPf (ORCPT ); Fri, 19 Feb 2016 16:15:35 -0500 From: Arnd Bergmann To: Russell King - ARM Linux Cc: Nicolas Pitre , linux-arm-kernel@lists.infradead.org, Ard Biesheuvel , Jon Medhurst , Marc Zyngier , linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/9] ARM: add CONFIG_PHYS_OFFSET default values Date: Fri, 19 Feb 2016 22:14:57 +0100 Message-ID: <3612170.sHbTTc5Sc9@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160219180725.GB19428@n2100.arm.linux.org.uk> References: <1455804123-2526139-1-git-send-email-arnd@arndb.de> <20160219180725.GB19428@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:mS5Bu2MZBCdSChxqJfCmvqRTQqf0nwU7h0tC63zQL0Lg9vImPF2 zvsookn3qyeRqEPvYWxIMOUEG/WDI+o3IDw4kGmC0JY1f1eTd31b6zDlYguFFo2KNmW/wkE RfSNMs5v602bQGizjoGbNA62DVlVFOheSYhd1JxhpcXvoSbdaW85AgTvmLYWReavWFGhRlL zJC92xu0vosiKB/FUYpWw== X-UI-Out-Filterresults: notjunk:1;V01:K0:kVBtJ4JHLDk=:uojb1WvzhKblX8iew2Fb/Y 8JAETLGFe7H4PnKuPfwK7Xea+cbJsMciEt9xw/ev+f7WXqtfOOpMZwi2Id6L+QCvBf8w1CJ/Z LuOLMV0RDNWoz6NElf135Oyo646eyZBNsz3gv12MwwaPEepyYz1INGkvcUaqA9qaBd1Z/T+zj RZdanixe0ObOjgWRDReiQM1hPockz9YFinMxlR8dKt90z3qVBaVK7//sBp/twbGTP9kdFGhLf Bnp8jXCc5ZJuNRwj48qoz7p3Ej2wAo/CSVqui0KYnexk5MpnnOSCLqQCvd4FxBNwZEGmzSXYf Ux9wnL/62sAq35gGbRk8aUL4r2R+xd5e+Ik7f2UB1uvaMt7NLDcqJ9a0d4gHWx2XRoNGA03hw gSxjDYDcwtU1FJRe+BRDugpYlh7fpNZBRyLIx7wP16XfFol0d852V+pjqXSbK6Si3itIRAnU6 XA+0bi/M6+OjoX8xgKduIQg5ewmYwTyqrxJKdpgbLuUT3wofPH/r8nNpI4z9rMiabZgGHsIHm tExsvAct9gJeJHCxVGK9I3WZb2Y7tISbXTLRNBZdyPlwImVhpLmOW/ergendmy3fpp0cw3rNH dEtCn+AceRlLGxFgF1dpHmY9Z8ayFvQM+NiZX3mFV0P9GEwHXyQAtLjTh6tpbA5vWddKiqfjx BeA+UxH05Les62Dx02l8OMJHo7ohDcmvr5vR8XeMxj55VwldEdbEOrd8Wa984aw835Lv+Dfx0 ZgwPhZf5Vy+EK5co Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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