Message ID | a7fcca12e0f567efd29314172ccf1ad4cd279bf7.1689759351.git.falcon@tinylab.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:c923:0:b0:3e4:2afc:c1 with SMTP id j3csp2453775vqt; Wed, 19 Jul 2023 06:52:19 -0700 (PDT) X-Google-Smtp-Source: APBJJlHYhNgMXZs9LPP4B/XBYUwp8DrBanMV5disg2VYXoJGXCNJUexfKl3apxPfPMNFMhZo5nRr X-Received: by 2002:a05:6358:c11:b0:133:c62:59f4 with SMTP id f17-20020a0563580c1100b001330c6259f4mr2785947rwj.24.1689774738764; Wed, 19 Jul 2023 06:52:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689774738; cv=none; d=google.com; s=arc-20160816; b=vbVJbmbmXdZxwnrXNFMi3loZVcUhiGVrrLdNt7Est/nPuPGyErqhv1fpc4FxPRGqj9 /RZ8HvkP20OgPtRj36m1bkD9jJsLYOtUTVwlV0LDOee7jO/KKGC+wCSB1C063onTyTA0 Sogze6DIbMNIBzp0uVFcrp/9+mEPMDbHsbjuPhcEd67Gcsp0EbFrsd+dgAzrFfHmg57Q PzIa4UExZnkJfXo02coO53N0w3Ag3Av7yqnDbJuF1oL5z4b1GNcYN57ysi9A4tQGDzyE ib8dDILUlPHlQg9b69lmScyb3LVc7MwU1B0dtziSpeLWiFRZ9QooWSJ39ZqjR6n0ZGi7 vmWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:feedback-id:content-transfer-encoding :mime-version:references:in-reply-to:message-id:date:subject:cc:to :from; bh=c22bJ4lEa+qwwtAqPQ8+8QQj4UTP8EXybjKaZRmmWCI=; fh=LUnDCxFG3oyWlcYTkiNww5x4+0V5pkm51/GfDl61ZDU=; b=dWDC5lQwI9fGIMkcEiEfF5LegXQ9l3PXRpM6kTM5beHUJPRBchFgnMW6XBtxpZglAu 6XhenWYr1BS0HdRBXsHJr8T1K8/4zDviWdqArGDObN4kf9B/7VD8W/SqzRPwBiUJhtad bGAsA7sJTZqM09+g4USEcxGSNxE0c5UtNcUe7C/cx4jeA+Sk78Q6ZPU23xAs+4O8yRSn zMuh22G/6NpXyneEckl83KJFlth25dexn/jZHMoxuBtJUk93lyGf6ZmfMeMvZ1+lE6n0 ScDcSJoDAfTAvA+zdtSwl2fIlfNq6B/+P09l90PbZqGgdDUULLBX4LoFyPcdJBRPYqnh MihA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j27-20020a633c1b000000b005574bef6f54si3431430pga.486.2023.07.19.06.52.05; Wed, 19 Jul 2023 06:52:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231200AbjGSNW4 (ORCPT <rfc822;assdfgzxcv4@gmail.com> + 99 others); Wed, 19 Jul 2023 09:22:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47774 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230509AbjGSNWy (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 19 Jul 2023 09:22:54 -0400 Received: from bg4.exmail.qq.com (bg4.exmail.qq.com [43.154.54.12]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7F3C4113; Wed, 19 Jul 2023 06:22:52 -0700 (PDT) X-QQ-mid: bizesmtp82t1689772962tgim8kcd Received: from linux-lab-host.localdomain ( [119.123.130.39]) by bizesmtp.qq.com (ESMTP) with id ; Wed, 19 Jul 2023 21:22:41 +0800 (CST) X-QQ-SSF: 01200000000000D0X000000A0000000 X-QQ-FEAT: +bXiSo2NuBcL7jnLryDuQMhX+oFM/svSg3z6REjIYNvM0REi9CZiqEZnjWRCL ssb+wsQjZ8s935FBqNK3tojAPMVXvl8aV9UwAK4EfLNhW/r5ms/tCdMPpdIOt+EflVmdYDz bGXR5iCBo5Msz82inD3wj21q5qlY68UzWajtjYfmI/qROoSLF/gr8+RZjy0dVjexSpSJAWe ZMJFwMm3toAP1U5OAgMvedAY1thea5XkWrW/IQqVygK0NmrlAtUEjTSFS7v7Asp9KE6SapD ssDVy24csF5bypQdq1aRUxLKlNl2YDCxZxGTf7JBgTaIAPsl6Ys5c8tmCsUlV0nTxpiLOX5 sT+xKsrQRu+BO6ZbNbJYCo79gZik5C5S+DdEarQ8QOA74L72Jrnms/QqWlLrSNmZW5/ZfEV X-QQ-GoodBg: 0 X-BIZMAIL-ID: 1272607350294726886 From: Zhangjin Wu <falcon@tinylab.org> To: w@1wt.eu Cc: thomas@t-8ch.de, arnd@arndb.de, falcon@tinylab.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: [PATCH v2 05/14] selftests/nolibc: add menuconfig for development Date: Wed, 19 Jul 2023 21:22:37 +0800 Message-Id: <a7fcca12e0f567efd29314172ccf1ad4cd279bf7.1689759351.git.falcon@tinylab.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <cover.1689759351.git.falcon@tinylab.org> References: <cover.1689759351.git.falcon@tinylab.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:tinylab.org:qybglogicsvrgz:qybglogicsvrgz5a-1 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1771857236323256540 X-GMAIL-MSGID: 1771857236323256540 |
Series |
selftests/nolibc: add minimal kernel config support - part1
|
|
Commit Message
Zhangjin Wu
July 19, 2023, 1:22 p.m. UTC
The default DEFCONFIG_<ARCH> may not always work for all architectures,
let's allow users to tune some kernel config options with 'menuconfig'.
This is important when porting nolibc to a new architecture, it also
allows to speed up nolibc 'run' target testing via manually disabling
tons of unnecessary kernel config options.
Signed-off-by: Zhangjin Wu <falcon@tinylab.org>
---
tools/testing/selftests/nolibc/Makefile | 3 +++
1 file changed, 3 insertions(+)
Comments
On Wed, Jul 19, 2023 at 09:22:37PM +0800, Zhangjin Wu wrote: > The default DEFCONFIG_<ARCH> may not always work for all architectures, > let's allow users to tune some kernel config options with 'menuconfig'. > > This is important when porting nolibc to a new architecture, it also > allows to speed up nolibc 'run' target testing via manually disabling > tons of unnecessary kernel config options. > > Signed-off-by: Zhangjin Wu <falcon@tinylab.org> > --- > tools/testing/selftests/nolibc/Makefile | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile > index 058e7be070ea..06954b4b3885 100644 > --- a/tools/testing/selftests/nolibc/Makefile > +++ b/tools/testing/selftests/nolibc/Makefile > @@ -202,6 +202,9 @@ KERNEL_IMAGE = $(objtree)/$(IMAGE) > defconfig: > $(Q)$(MAKE_KERNEL) mrproper $(DEFCONFIG) prepare > > +menuconfig: > + $(Q)$(MAKE_KERNEL) menuconfig What is the real benefit of this compared to just running the standard "make menuconfig" ? We should avoid adding makefile targets that do not bring value on top of that the top-level makefile does, because it will make the useful ones much harder to spot, and will tend to encourage users to use only that makefile during the tests, which is a bad practice since many targets will always be missing or work differently. It's important in my opinion that we strictly stick to what is useful to operate the tests themselves and this one doesn't make me feel like it qualifies as such. Willy
> On Wed, Jul 19, 2023 at 09:22:37PM +0800, Zhangjin Wu wrote: > > The default DEFCONFIG_<ARCH> may not always work for all architectures, > > let's allow users to tune some kernel config options with 'menuconfig'. > > > > This is important when porting nolibc to a new architecture, it also > > allows to speed up nolibc 'run' target testing via manually disabling > > tons of unnecessary kernel config options. > > > > Signed-off-by: Zhangjin Wu <falcon@tinylab.org> > > --- > > tools/testing/selftests/nolibc/Makefile | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile > > index 058e7be070ea..06954b4b3885 100644 > > --- a/tools/testing/selftests/nolibc/Makefile > > +++ b/tools/testing/selftests/nolibc/Makefile > > @@ -202,6 +202,9 @@ KERNEL_IMAGE = $(objtree)/$(IMAGE) > > defconfig: > > $(Q)$(MAKE_KERNEL) mrproper $(DEFCONFIG) prepare > > > > +menuconfig: > > + $(Q)$(MAKE_KERNEL) menuconfig > > What is the real benefit of this compared to just running the > standard "make menuconfig" ? We should avoid adding makefile targets > that do not bring value on top of that the top-level makefile does, > because it will make the useful ones much harder to spot, and will > tend to encourage users to use only that makefile during the tests, > which is a bad practice since many targets will always be missing > or work differently. It's important in my opinion that we strictly > stick to what is useful to operate the tests themselves and this > one doesn't make me feel like it qualifies as such. Ok, get it. I did like develop nolibc in tools/testing/selftests/nolibc/ without changing directories frequently or specifying the "-C" option unnecessary ;-) Since "make menuconfig" is only required during the first porting of a new architecture, so, it is ok to drop this patch. Thanks, Zhangjin > > Willy
Hi, Willy > > On Wed, Jul 19, 2023 at 09:22:37PM +0800, Zhangjin Wu wrote: > > > The default DEFCONFIG_<ARCH> may not always work for all architectures, > > > let's allow users to tune some kernel config options with 'menuconfig'. > > > > > > This is important when porting nolibc to a new architecture, it also > > > allows to speed up nolibc 'run' target testing via manually disabling > > > tons of unnecessary kernel config options. > > > > > > Signed-off-by: Zhangjin Wu <falcon@tinylab.org> > > > --- > > > tools/testing/selftests/nolibc/Makefile | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile > > > index 058e7be070ea..06954b4b3885 100644 > > > --- a/tools/testing/selftests/nolibc/Makefile > > > +++ b/tools/testing/selftests/nolibc/Makefile > > > @@ -202,6 +202,9 @@ KERNEL_IMAGE = $(objtree)/$(IMAGE) > > > defconfig: > > > $(Q)$(MAKE_KERNEL) mrproper $(DEFCONFIG) prepare > > > > > > +menuconfig: > > > + $(Q)$(MAKE_KERNEL) menuconfig > > > > What is the real benefit of this compared to just running the > > standard "make menuconfig" ? We should avoid adding makefile targets > > that do not bring value on top of that the top-level makefile does, > > because it will make the useful ones much harder to spot, and will > > tend to encourage users to use only that makefile during the tests, > > which is a bad practice since many targets will always be missing > > or work differently. It's important in my opinion that we strictly > > stick to what is useful to operate the tests themselves and this > > one doesn't make me feel like it qualifies as such. > > Ok, get it. > > I did like develop nolibc in tools/testing/selftests/nolibc/ without > changing directories frequently or specifying the "-C" option > unnecessary ;-) > > Since "make menuconfig" is only required during the first porting of a new > architecture, so, it is ok to drop this patch. > Oh, Willy, I did find this is very important again. I just want to check and test if we need to disable vsx for 32-bit powerpc too, so, I plan to re-configure kernel via menuconfig to disable VSX in kernel side, and forcely enable vsx in application side, but it was very 'painful' when I was running something like this: $ make defconfig ARCH=ppc CROSS_COMPILE=powerpc-linux-gnu- To do a further menuconfig, I must switch to something else: $ make menuconfig ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- -C ../../../../ Especially, our test is able to accept ARCH=ppc, but the top-level kernel still only accept powerpc, it makes the development very comfortable, of course, the typing of the relative or absolute path every time is either not a good idea. so, this doesn't simply duplicate with the one from top-level, it can get the right ARCH, srctree for us, and this is heavily used by our tinyconfig development to tune the config options very frequently, so, let's still add this one in the new revision? But I plan to merge the mrproper targets here to save another patch, what about your idea? menuconfig mrproper: $(Q)$(MAKE_KERNEL) $@ Thanks, Zhangjin > Thanks, > Zhangjin > > > > > Willy
Hi Zhangjin, On Thu, Jul 27, 2023 at 09:24:18PM +0800, Zhangjin Wu wrote: > Hi, Willy > > > > On Wed, Jul 19, 2023 at 09:22:37PM +0800, Zhangjin Wu wrote: > > > > The default DEFCONFIG_<ARCH> may not always work for all architectures, > > > > let's allow users to tune some kernel config options with 'menuconfig'. > > > > > > > > This is important when porting nolibc to a new architecture, it also > > > > allows to speed up nolibc 'run' target testing via manually disabling > > > > tons of unnecessary kernel config options. > > > > > > > > Signed-off-by: Zhangjin Wu <falcon@tinylab.org> > > > > --- > > > > tools/testing/selftests/nolibc/Makefile | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile > > > > index 058e7be070ea..06954b4b3885 100644 > > > > --- a/tools/testing/selftests/nolibc/Makefile > > > > +++ b/tools/testing/selftests/nolibc/Makefile > > > > @@ -202,6 +202,9 @@ KERNEL_IMAGE = $(objtree)/$(IMAGE) > > > > defconfig: > > > > $(Q)$(MAKE_KERNEL) mrproper $(DEFCONFIG) prepare > > > > > > > > +menuconfig: > > > > + $(Q)$(MAKE_KERNEL) menuconfig > > > > > > What is the real benefit of this compared to just running the > > > standard "make menuconfig" ? We should avoid adding makefile targets > > > that do not bring value on top of that the top-level makefile does, > > > because it will make the useful ones much harder to spot, and will > > > tend to encourage users to use only that makefile during the tests, > > > which is a bad practice since many targets will always be missing > > > or work differently. It's important in my opinion that we strictly > > > stick to what is useful to operate the tests themselves and this > > > one doesn't make me feel like it qualifies as such. > > > > Ok, get it. > > > > I did like develop nolibc in tools/testing/selftests/nolibc/ without > > changing directories frequently or specifying the "-C" option > > unnecessary ;-) > > > > Since "make menuconfig" is only required during the first porting of a new > > architecture, so, it is ok to drop this patch. > > > > Oh, Willy, I did find this is very important again. > > I just want to check and test if we need to disable vsx for 32-bit > powerpc too, so, I plan to re-configure kernel via menuconfig to disable > VSX in kernel side, and forcely enable vsx in application side, but it > was very 'painful' when I was running something like this: > > $ make defconfig ARCH=ppc CROSS_COMPILE=powerpc-linux-gnu- > > To do a further menuconfig, I must switch to something else: > > $ make menuconfig ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- -C ../../../../ > > Especially, our test is able to accept ARCH=ppc, but the top-level > kernel still only accept powerpc, it makes the development very > comfortable, of course, the typing of the relative or absolute path > every time is either not a good idea. It is "able" but that's not what ought to be used, since it's going to be remapped to "powerpc". You're supposed to use XARCH for this one since it's a variant (we could find other names if needed). I suspect it just shows that the "override ARCH :=" is excessive and should not be there. Usually when you put override in a makefile, it's going to pop up as a bug elsewhere. Thus actually you could very well have : make ARCH=powerpc XARCH=ppc CROSS_COMPILE=powerpc-linux-gnu- as the prefix for all your commands. Some will prefer to work directly from the kernel dir: $ make ARCH=powerpc XARCH=ppc CROSS_COMPILE=powerpc-linux-gnu- -C tools/testing/selftests/nolibc-test defconfig $ make ARCH=powerpc XARCH=ppc CROSS_COMPILE=powerpc-linux-gnu- menuconfig Others would do it from the nolibc-test dir as you did above. > so, this doesn't simply duplicate with the one from top-level, it can > get the right ARCH, srctree for us, and this is heavily used by our > tinyconfig development to tune the config options very frequently, so, > let's still add this one in the new revision? I'm not *fundamentally* opposed to menuconfig, I just think that it's appearing at the wrong place. Why not oldconfig, allmodconfig, randconfig, allnoconfig etc then ? There is nothing in the test directory that is supposed to be used interactively, either it's run in a batch for cross- arch testing, or you use it to validate your kernel when you're working on it. It feels strange that one would want to configure their kernel from this sub-dir. > But I plan to merge the mrproper targets here to save another patch, > what about your idea? > > menuconfig mrproper: > $(Q)$(MAKE_KERNEL) $@ Please no. Someone doing that in hope to clean only the result of the tests would in fact ruin their config: $ make -C tools/testing/selftests/nolibc-test mrproper This is another reason for not encouraging users to develop from within that dir. Willy
Hi, Willy [...] > > > > > > > > What is the real benefit of this compared to just running the > > > > standard "make menuconfig" ? We should avoid adding makefile targets > > > > that do not bring value on top of that the top-level makefile does, > > > > because it will make the useful ones much harder to spot, and will > > > > tend to encourage users to use only that makefile during the tests, > > > > which is a bad practice since many targets will always be missing > > > > or work differently. It's important in my opinion that we strictly > > > > stick to what is useful to operate the tests themselves and this > > > > one doesn't make me feel like it qualifies as such. > > > > > > Ok, get it. > > > > > > I did like develop nolibc in tools/testing/selftests/nolibc/ without > > > changing directories frequently or specifying the "-C" option > > > unnecessary ;-) > > > > > > Since "make menuconfig" is only required during the first porting of a new > > > architecture, so, it is ok to drop this patch. > > > > > > > Oh, Willy, I did find this is very important again. > > > > I just want to check and test if we need to disable vsx for 32-bit > > powerpc too, so, I plan to re-configure kernel via menuconfig to disable > > VSX in kernel side, and forcely enable vsx in application side, but it > > was very 'painful' when I was running something like this: > > > > $ make defconfig ARCH=ppc CROSS_COMPILE=powerpc-linux-gnu- > > > > To do a further menuconfig, I must switch to something else: > > > > $ make menuconfig ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- -C ../../../../ > > > > Especially, our test is able to accept ARCH=ppc, but the top-level > > kernel still only accept powerpc, it makes the development very > > comfortable, of course, the typing of the relative or absolute path > > every time is either not a good idea. > > It is "able" but that's not what ought to be used, since it's going to > be remapped to "powerpc". You're supposed to use XARCH for this one > since it's a variant (we could find other names if needed). I suspect > it just shows that the "override ARCH :=" is excessive and should not > be there. Usually when you put override in a makefile, it's going to > pop up as a bug elsewhere. Thus actually you could very well have : > > make ARCH=powerpc XARCH=ppc CROSS_COMPILE=powerpc-linux-gnu- > Oh, Seems I have misunderstood your suggestions in another reply, you recommended to add ARCH variable to the help target, at last, I thought it was better to only reserve ARCH as the consistent variable to users, so, the 'override' keyword is added to allow passing anyone of powerpc, ppc, ppc64 and ppc64le to ARCH, since XARCH only accept ppc, ppc64 and ppc64le. Further passing 'ARCH=powerpc XARCH=ppc' is also ok, but the combination of ARCH and XARCH may require more time to teach a new user, is ok for me to remove the override and carefully document this usage in Makefile. Seems 'override' is really required, without it, when users wrongly try ARCH=ppc, ARCH=ppc64, ARCH=ppc64le, the ARCH passed to kernel will be completely wrong, it may mislead users ... With this 'override', it is ok for users to use ARCH only, or XARCH or even together with both of them, no failure and happy, to myself, I'm ok to remove the 'override' keyword, ;-) > as the prefix for all your commands. Some will prefer to work directly > from the kernel dir: > > $ make ARCH=powerpc XARCH=ppc CROSS_COMPILE=powerpc-linux-gnu- -C tools/testing/selftests/nolibc-test defconfig > $ make ARCH=powerpc XARCH=ppc CROSS_COMPILE=powerpc-linux-gnu- menuconfig > > Others would do it from the nolibc-test dir as you did above. > Yeah, we still need one more -C, but it is of course ok to do this in a standalone script as you mentioned before. > > so, this doesn't simply duplicate with the one from top-level, it can > > get the right ARCH, srctree for us, and this is heavily used by our > > tinyconfig development to tune the config options very frequently, so, > > let's still add this one in the new revision? > > I'm not *fundamentally* opposed to menuconfig, I just think that it's > appearing at the wrong place. Why not oldconfig, allmodconfig, randconfig, > allnoconfig etc then ? There is nothing in the test directory that is > supposed to be used interactively, either it's run in a batch for cross- > arch testing, or you use it to validate your kernel when you're working > on it. It feels strange that one would want to configure their kernel > from this sub-dir. Ok, it is reasonable ;-) > > > But I plan to merge the mrproper targets here to save another patch, > > what about your idea? > > > > menuconfig mrproper: > > $(Q)$(MAKE_KERNEL) $@ > > Please no. Someone doing that in hope to clean only the result of > the tests would in fact ruin their config: > > $ make -C tools/testing/selftests/nolibc-test mrproper > Yeah, really a good reason to not add mrproper there. > This is another reason for not encouraging users to develop from > within that dir. > Thanks, Zhangjin > Willy
diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile index 058e7be070ea..06954b4b3885 100644 --- a/tools/testing/selftests/nolibc/Makefile +++ b/tools/testing/selftests/nolibc/Makefile @@ -202,6 +202,9 @@ KERNEL_IMAGE = $(objtree)/$(IMAGE) defconfig: $(Q)$(MAKE_KERNEL) mrproper $(DEFCONFIG) prepare +menuconfig: + $(Q)$(MAKE_KERNEL) menuconfig + extconfig: $(Q)$(srctree)/scripts/kconfig/merge_config.sh -O "$(objtree)" -m "$(KERNEL_CONFIG)" $(foreach c,$(EXTCONFIG),$(wildcard $(CURDIR)/configs/$c)) $(Q)$(MAKE_KERNEL) KCONFIG_ALLCONFIG="$(KERNEL_CONFIG)" allnoconfig