Message ID | 4d6023634c5d97694e75b460b39c25e44642c4d3.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 j3csp2456426vqt; Wed, 19 Jul 2023 06:57:32 -0700 (PDT) X-Google-Smtp-Source: APBJJlG4thhMEaPOEKprsHrYsjjxoF2x1qsrN3dP6zRXhp0oUZCZ1I0Fobw8aoWxD0I0ZCZfYOvC X-Received: by 2002:a05:6a20:7d93:b0:133:c12a:4d6 with SMTP id v19-20020a056a207d9300b00133c12a04d6mr2790681pzj.1.1689775051762; Wed, 19 Jul 2023 06:57:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689775051; cv=none; d=google.com; s=arc-20160816; b=VlPiyweO1V4eKNOcJD0CVvBtcYAFb0/5g7UuNAJQdnX9i+14PKAQm2s3tP7WK2yvGc InksETxsXWV6mZX5S1KBf94qcRNZ6omuRRPj/UOkrig+V9w9tH/UmZGJXrhIEwLNlXpQ Gnt9DuiIHRQbfDcCDrwcq/o5aPA9tv1ZgDVDf3bQJiDkYwqlECLUc0H8XF2pu/i/nyrM LeNhK3RbZlCZ93Zs1K/64lDUpMBycMkhWnjuwVc0ZAY4WflThIfduK5ofPNr5pE7F1VW liL9D2gG4bLvyCPLUY4mSc0J151ybivUXa82mQA2YFDMhD1xj9kZpUGTqViSyMjbqYSx ZJnw== 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=QknTgF4KPG74w4eE4urkc2Szkey8NTPE/UIwcS9gmYE=; fh=LUnDCxFG3oyWlcYTkiNww5x4+0V5pkm51/GfDl61ZDU=; b=l2oglBKfY7D0oXcVx3uJD4vZw36A/ND4kV+UNayL077Aae6hSNIKPfPoG6AXHOcylZ dzYGA9p2kWtoT4wEpc8DnYLxQJOa7fJ4gbDVKGMFxRh7xrGylOOE0v8GzUUoCWPce9V0 NkBHTSpz5IwCpYjX7C1Ly/f7hPxq9JyY5NokSsryjyc63qGMjXE3+pLKBkjVyN5nIkxl HLos3KmV0f7P6n5EMDLD7ifq8leSwGQcVkBVxEt7zmJAJCMS3a/XXwLntpda6NMIvKAY 3CKmtpilXog0xCBks7yxJ97iGr+9JO+Y2Nzs7Zh5FnuM/KIV3AyHptgGTPK8kMb/1kHW squA== 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 k62-20020a638441000000b005439273f2a4si3496474pgd.139.2023.07.19.06.57.18; Wed, 19 Jul 2023 06:57:31 -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 S230245AbjGSN0Q (ORCPT <rfc822;assdfgzxcv4@gmail.com> + 99 others); Wed, 19 Jul 2023 09:26:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50150 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229512AbjGSN0P (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 19 Jul 2023 09:26:15 -0400 Received: from bg4.exmail.qq.com (bg4.exmail.qq.com [43.155.65.254]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD116113; Wed, 19 Jul 2023 06:26:13 -0700 (PDT) X-QQ-mid: bizesmtp81t1689773163tzuoiaar Received: from linux-lab-host.localdomain ( [119.123.130.39]) by bizesmtp.qq.com (ESMTP) with id ; Wed, 19 Jul 2023 21:26:02 +0800 (CST) X-QQ-SSF: 01200000000000D0X000000A0000000 X-QQ-FEAT: Fc2LLDWeHZ8VdczlC7KmDhEPzY0whHqO82tCkg/2DH+O58nfZufXy/1LZ57Ez bYwAChOjliqF3DXvAK8o2kR9iCuiP+OI0g9sAaZVoeK3YF2xhwnh5ghx7bXdO8H43l/aM3m Bru5MzOnEkD7RbQTnvdurcqkRtaa0Ti/iZoRfkPriK1EHO3Ws1mqhylOyC1YXaWKwUc7CbF AqTAxciM24nJjSL+4lOojxVZ5azHBlT3XfogfmGMiSeZhrlYM5F1QSL0avzOy45ESALMgbH yeeImRshlL/b1C1wMCnqkpzfeH3oBhycjOtLHYZgbErbI2rr39HsTvCs2w/7cEVyA1gC7ko D0B/9RqqtA3ECHFY4D4VV5Dt3EgxY3S+JaGfbjxD3iy1CqjTtqVWUT3pKcTuLrvoGRNE4b2 X-QQ-GoodBg: 0 X-BIZMAIL-ID: 17285314132285918324 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 08/14] selftests/nolibc: string the core targets Date: Wed, 19 Jul 2023 21:26:01 +0800 Message-Id: <4d6023634c5d97694e75b460b39c25e44642c4d3.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: 1771857564595621446 X-GMAIL-MSGID: 1771857564595621446 |
Series |
selftests/nolibc: add minimal kernel config support - part1
|
|
Commit Message
Zhangjin Wu
July 19, 2023, 1:26 p.m. UTC
To avoid run targets one by one manually and boringly, let's string them
with IMAGE and .config, the MAKE command will trigger the dependencies
for us.
Note, to allow do menuconfig before extconfig manually, only trigger
defconfig while the .config is not there, it means only trigger
defconfig for the first run or after a mrproper.
Signed-off-by: Zhangjin Wu <falcon@tinylab.org>
---
tools/testing/selftests/nolibc/Makefile | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
Comments
On Wed, Jul 19, 2023 at 09:26:01PM +0800, Zhangjin Wu wrote: > To avoid run targets one by one manually and boringly, let's string them > with IMAGE and .config, the MAKE command will trigger the dependencies > for us. > > Note, to allow do menuconfig before extconfig manually, only trigger > defconfig while the .config is not there, it means only trigger > defconfig for the first run or after a mrproper. > > Signed-off-by: Zhangjin Wu <falcon@tinylab.org> > --- > tools/testing/selftests/nolibc/Makefile | 18 +++++++++++++----- > 1 file changed, 13 insertions(+), 5 deletions(-) > > diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile > index 83cb4b017bef..541f3565e584 100644 > --- a/tools/testing/selftests/nolibc/Makefile > +++ b/tools/testing/selftests/nolibc/Makefile (...) > -extconfig: > +extconfig: $(KERNEL_CONFIG) > $(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 > > -kernel: initramfs > +kernel: extconfig > + $(Q)$(MAKE) --no-print-directory initramfs There seems to be something wrong here. From what I'm seeing, now if I run "make kernel" it will run extconfig and possibly change the config I just edited. Or am I missing something ? I must confess all of this is becoming more and more obscure :-( Willy
> On Wed, Jul 19, 2023 at 09:26:01PM +0800, Zhangjin Wu wrote: > > To avoid run targets one by one manually and boringly, let's string them > > with IMAGE and .config, the MAKE command will trigger the dependencies > > for us. > > > > Note, to allow do menuconfig before extconfig manually, only trigger > > defconfig while the .config is not there, it means only trigger > > defconfig for the first run or after a mrproper. > > > > Signed-off-by: Zhangjin Wu <falcon@tinylab.org> > > --- > > tools/testing/selftests/nolibc/Makefile | 18 +++++++++++++----- > > 1 file changed, 13 insertions(+), 5 deletions(-) > > > > diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile > > index 83cb4b017bef..541f3565e584 100644 > > --- a/tools/testing/selftests/nolibc/Makefile > > +++ b/tools/testing/selftests/nolibc/Makefile > (...) > > -extconfig: > > +extconfig: $(KERNEL_CONFIG) > > $(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 > > > > -kernel: initramfs > > +kernel: extconfig > > + $(Q)$(MAKE) --no-print-directory initramfs > > There seems to be something wrong here. From what I'm seeing, now if I > run "make kernel" it will run extconfig and possibly change the config > I just edited. > Yeah, extconfig will run for every 'make kernel', it is ok for us to let kernel depends on $(KERNEL_CONFIG), but this requires users to run extconfig explictly, the solution may be: - move extconfig operations to defconfig target and future tinyconfig target (it looks cleaner ...) - but it is not convenient to trigger additional changes introduced by extconfig, not necessary, but really helpful, something like 'menuconfig' - let users run extconfig manually after a defconfig or tinyconfig (it is a little complex) - this make users hard to learn what to do, should give up this method - run extconfig for every 'make kernel' as it currently do - this may change something after a menuconfig, but it only trigger minimal required options, the 'hurt' should be minimal, but of course, it may confuse sometimes ;-( As a summary, let's remove 'extconfig' and move its operations to the defconfig and the future tinyconfig targets? 'extconfig' should be a 'default' config action, let users apply additional ones manually from the top-level 'make menuconfig', what's your idea? > Or am I missing something ? I must confess all of this is becoming more > and more obscure :-( Yeah ... let's find a better solution ;-) Best regards, Zhangjin > > Willy
On Tue, Jul 25, 2023 at 10:20:17PM +0800, Zhangjin Wu wrote: > > On Wed, Jul 19, 2023 at 09:26:01PM +0800, Zhangjin Wu wrote: > > > To avoid run targets one by one manually and boringly, let's string them > > > with IMAGE and .config, the MAKE command will trigger the dependencies > > > for us. > > > > > > Note, to allow do menuconfig before extconfig manually, only trigger > > > defconfig while the .config is not there, it means only trigger > > > defconfig for the first run or after a mrproper. > > > > > > Signed-off-by: Zhangjin Wu <falcon@tinylab.org> > > > --- > > > tools/testing/selftests/nolibc/Makefile | 18 +++++++++++++----- > > > 1 file changed, 13 insertions(+), 5 deletions(-) > > > > > > diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile > > > index 83cb4b017bef..541f3565e584 100644 > > > --- a/tools/testing/selftests/nolibc/Makefile > > > +++ b/tools/testing/selftests/nolibc/Makefile > > (...) > > > -extconfig: > > > +extconfig: $(KERNEL_CONFIG) > > > $(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 > > > > > > -kernel: initramfs > > > +kernel: extconfig > > > + $(Q)$(MAKE) --no-print-directory initramfs > > > > There seems to be something wrong here. From what I'm seeing, now if I > > run "make kernel" it will run extconfig and possibly change the config > > I just edited. > > > > Yeah, extconfig will run for every 'make kernel', it is ok for us to > let kernel depends on $(KERNEL_CONFIG), but this requires users to run > extconfig explictly, the solution may be: > > - move extconfig operations to defconfig target and future tinyconfig target (it looks cleaner ...) > > - but it is not convenient to trigger additional changes introduced by > extconfig, not necessary, but really helpful, something like 'menuconfig' > > - let users run extconfig manually after a defconfig or tinyconfig (it is a little complex) > > - this make users hard to learn what to do, should give up this method > > - run extconfig for every 'make kernel' as it currently do > > - this may change something after a menuconfig, but it only trigger minimal > required options, the 'hurt' should be minimal, but of course, it may confuse sometimes ;-( > > As a summary, let's remove 'extconfig' and move its operations to the defconfig > and the future tinyconfig targets? 'extconfig' should be a 'default' config > action, let users apply additional ones manually from the top-level 'make > menuconfig', what's your idea? Well, it's important to apply the principle of least surprise for the user. You're a developer who spent time working on your config, you believe it's OK and you just remind that you've heard about that nolibc test thing recently and you think "why not give it a try in case it spots something I forgot in my config". Then you just run the test there and once done your config was secretly modified. This is exactly an example of what *not* to do. We should never modify user's config nor files in general without an explicit request from the user. If the user types "make defconfig", they're implicitly requesting to replace the config, so we can do what we want with it. If they type "make kernel", they expect to make a kernel based on this config, not to mollest this precious config file and then make a kernel out of it. So I'm fine with the idea of adding config snippets on top of defconfig and tinyconfig to allow the user to generate a working config for a given architecture, but not for modifying their config without their consent. Willy
> On Tue, Jul 25, 2023 at 10:20:17PM +0800, Zhangjin Wu wrote: > > > On Wed, Jul 19, 2023 at 09:26:01PM +0800, Zhangjin Wu wrote: > > > > To avoid run targets one by one manually and boringly, let's string them > > > > with IMAGE and .config, the MAKE command will trigger the dependencies > > > > for us. > > > > > > > > Note, to allow do menuconfig before extconfig manually, only trigger > > > > defconfig while the .config is not there, it means only trigger > > > > defconfig for the first run or after a mrproper. > > > > > > > > Signed-off-by: Zhangjin Wu <falcon@tinylab.org> > > > > --- > > > > tools/testing/selftests/nolibc/Makefile | 18 +++++++++++++----- > > > > 1 file changed, 13 insertions(+), 5 deletions(-) > > > > > > > > diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile > > > > index 83cb4b017bef..541f3565e584 100644 > > > > --- a/tools/testing/selftests/nolibc/Makefile > > > > +++ b/tools/testing/selftests/nolibc/Makefile > > > (...) > > > > -extconfig: > > > > +extconfig: $(KERNEL_CONFIG) > > > > $(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 > > > > > > > > -kernel: initramfs > > > > +kernel: extconfig > > > > + $(Q)$(MAKE) --no-print-directory initramfs > > > > > > There seems to be something wrong here. From what I'm seeing, now if I > > > run "make kernel" it will run extconfig and possibly change the config > > > I just edited. > > > > > > > Yeah, extconfig will run for every 'make kernel', it is ok for us to > > let kernel depends on $(KERNEL_CONFIG), but this requires users to run > > extconfig explictly, the solution may be: > > > > - move extconfig operations to defconfig target and future tinyconfig target (it looks cleaner ...) > > > > - but it is not convenient to trigger additional changes introduced by > > extconfig, not necessary, but really helpful, something like 'menuconfig' > > > > - let users run extconfig manually after a defconfig or tinyconfig (it is a little complex) > > > > - this make users hard to learn what to do, should give up this method > > > > - run extconfig for every 'make kernel' as it currently do > > > > - this may change something after a menuconfig, but it only trigger minimal > > required options, the 'hurt' should be minimal, but of course, it may confuse sometimes ;-( > > > > As a summary, let's remove 'extconfig' and move its operations to the defconfig > > and the future tinyconfig targets? 'extconfig' should be a 'default' config > > action, let users apply additional ones manually from the top-level 'make > > menuconfig', what's your idea? > > Well, it's important to apply the principle of least surprise for the > user. You're a developer who spent time working on your config, you > believe it's OK and you just remind that you've heard about that nolibc > test thing recently and you think "why not give it a try in case it spots > something I forgot in my config". Then you just run the test there and > once done your config was secretly modified. This is exactly an example > of what *not* to do. We should never modify user's config nor files in > general without an explicit request from the user. If the user types > "make defconfig", they're implicitly requesting to replace the config, > so we can do what we want with it. If they type "make kernel", they > expect to make a kernel based on this config, not to mollest this > precious config file and then make a kernel out of it. > > So I'm fine with the idea of adding config snippets on top of defconfig > and tinyconfig to allow the user to generate a working config for a > given architecture, but not for modifying their config without their > consent. > Agree, seems our additional config snippets are minimal and 'necessary' for boot and print, so, I ignored the override issue before. What about the version in v3 here: https://lore.kernel.org/lkml/9b52e26748eda1ac108d569207bf428bf37b3bbc.1690489039.git.falcon@tinylab.org/ The 'defconfig' will only be triggered while there is no .config there, I do think it is important, at the first time of using nolibc, I directly run kernel but it fails for it has a manual defconfig requirement every time, so, I do think a default defconfig for kernel for the first run or after a mrproper is helpful, it doesn't modify any .config for there is no one there. +PHONY += $(KERNEL_CONFIG) +$(KERNEL_CONFIG): + $(Q)if [ ! -f "$(KERNEL_CONFIG)" ]; then $(MAKE) --no-print-directory defconfig; fi + +kernel: $(KERNEL_CONFIG) + $(Q)$(MAKE) --no-print-directory initramfs $(Q)$(MAKE_KERNEL) $(IMAGE_NAME) CONFIG_INITRAMFS_SOURCE=$(CURDIR)/initramfs Thanks, Zhangjin > Willy
On Sat, Jul 29, 2023 at 05:54:47PM +0800, Zhangjin Wu wrote: > The 'defconfig' will only be triggered while there is no .config there, > I do think it is important, at the first time of using nolibc, I > directly run kernel but it fails for it has a manual defconfig > requirement every time, so, I do think a default defconfig for kernel > for the first run or after a mrproper is helpful, it doesn't modify any > .config for there is no one there. On the opposite, that's yet another example of automatic stuff that for me adds zero value and just doubts in the user's head: "is it safe to call this with my own config or should I keep a safe copy of it?", "what will it use for the config?", "will the arch be correct if my current config references 32BIT and the generated default one switches it to 64?" etc. Please let's not add unneeded dependencies and chaining. It does not help and makes it harder to restart at one specific step, thus lowers the overall value. Willy
diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile index 83cb4b017bef..541f3565e584 100644 --- a/tools/testing/selftests/nolibc/Makefile +++ b/tools/testing/selftests/nolibc/Makefile @@ -150,6 +150,7 @@ all: run sysroot: sysroot/$(ARCH)/include +PHONY = sysroot/$(ARCH)/include sysroot/$(ARCH)/include: $(Q)rm -rf sysroot/$(ARCH) sysroot/sysroot $(QUIET_MKDIR)mkdir -p sysroot @@ -205,21 +206,28 @@ mrproper: defconfig: $(Q)$(MAKE_KERNEL) $(DEFCONFIG) prepare -menuconfig: +PHONY += $(KERNEL_CONFIG) +$(KERNEL_CONFIG): + $(Q)if [ ! -f "$(KERNEL_CONFIG)" ]; then $(MAKE) --no-print-directory defconfig; fi + +menuconfig: $(KERNEL_CONFIG) $(Q)$(MAKE_KERNEL) menuconfig -extconfig: +extconfig: $(KERNEL_CONFIG) $(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 -kernel: initramfs +kernel: extconfig + $(Q)$(MAKE) --no-print-directory initramfs $(Q)$(MAKE_KERNEL) $(IMAGE_NAME) CONFIG_INITRAMFS_SOURCE=$(CURDIR)/initramfs # common macros for qemu run/rerun targets QEMU_SYSTEM_RUN = qemu-system-$(QEMU_ARCH) -display none -no-reboot -kernel "$(KERNEL_IMAGE)" -serial stdio $(QEMU_ARGS) # run the tests after building the kernel -run: kernel +PHONY += $(KERNEL_IMAGE) +$(KERNEL_IMAGE): kernel +run: $(KERNEL_IMAGE) $(Q)$(QEMU_SYSTEM_RUN) $(LOG_OUT) $(Q)$(REPORT_RUN_OUT) @@ -244,4 +252,4 @@ clean: $(call QUIET_CLEAN, run.out) $(Q)rm -rf run.out -.PHONY: sysroot/$(ARCH)/include +.PHONY: $(PHONY)