From: Willy Tarreau <w@1wt.eu>
To: Zhangjin Wu <falcon@tinylab.org>
Cc: thomas@t-8ch.de, arnd@arndb.de, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v3 3/7] selftests/nolibc: add extra configs customize support
Date: Sat, 29 Jul 2023 18:29:07 +0200 [thread overview]
Message-ID: <20230729162907.GA5219@1wt.eu> (raw)
In-Reply-To: <20230729143933.14462-1-falcon@tinylab.org>
On Sat, Jul 29, 2023 at 10:39:33PM +0800, Zhangjin Wu wrote:
> > > diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile
> > > index f42adef87e12..9576f1a0a98d 100644
> > > --- a/tools/testing/selftests/nolibc/Makefile
> > > +++ b/tools/testing/selftests/nolibc/Makefile
> > > @@ -39,6 +39,9 @@ DEFCONFIG_s390 = defconfig
> > > DEFCONFIG_loongarch = defconfig
> > > DEFCONFIG = $(DEFCONFIG_$(ARCH))
> > >
> > > +# extra kernel config files under configs/, include common + architecture specific
> > > +EXTCONFIG = common.config $(ARCH).config
> >
> > As this series seems to need a respin anyways:
> >
> > extconfig means "extended config", correct?
> > That is fairly nondescript.
> >
>
> It is more about 'extra' as commented (or 'additional'), for both
> defconfig (may) and tinyconfig (must) require more options to make boot
> and print work for nolibc-test.
>
> defconfig ------\
> \
> \
> EXTCONFIG ----> a working .config for nolibc-test
> /
> /
> tinyconfig------/
>
> > I would prefer something like "NOLIBC_TEST_CONFIG"
> >
>
> Using NOLIBC_TEST_CONFIG is ok, but with this name, do we still only put
> the 'additional' options there? or we simply use EXTRA_CONFIG instead?
>
> # extra kernel config files under configs/, include common + architecture specific
> EXTRA_CONFIG = common.config $(ARCH).config
Either are fine to me. The most important is to mention that these
configs are appended to the config during the defconfig and tinyconfig
targets.
Also I find it odd to use $(ARCH) here, I would have expected $(XARCH)
since you probably want to distinguish ppc64 from ppc for example.
> > something like "make nolibctestconfig" to make an existing config ready for
> > nolibc-test.
>
> Do you mean rename 'defconfig' to 'nolibctestconfig'? or something
> nolibc-test-config:
>
> nolibc-test-config:
> $(Q)$(MAKE) -C $(srctree) ARCH=$(ARCH) CC=$(CC) CROSS_COMPILE=$(CROSS_COMPILE) mrproper $(DEFCONFIG) prepare
> $(Q)$(srctree)/scripts/kconfig/merge_config.sh -O "$(srctree)" -m "$(srctree)/.config" $(foreach c,$(EXTRA_CONFIG),$(wildcard $(CURDIR)/configs/$c))
> $(Q)$(MAKE) -C $(srctree) ARCH=$(ARCH) CC=$(CC) CROSS_COMPILE=$(CROSS_COMPILE) KCONFIG_ALLCONFIG="$(srctree)/.config" allnoconfig
>
> It looks too long ;-)
I think that as long as we don't claim to call topdir's makefile targets
from this directory, we can reuse some similarly named targets which are
documented in "make help" and are non-ambiguous.
> Currently, we use 'defconfig' by default and we use 'make defconfig
> DEFCONFIG=tinyconfig' to switch to tinyconfig, in the next weeks, when
> all of the nolibc supported architectures have tinyconfig support, it is
> able to switch 'tinyconfig' as the default config target.
As long as it doesn't require to locally maintain too many options, I
think I'm fine with that. But we'll see.
Willy
next prev parent reply other threads:[~2023-07-29 16:29 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-27 14:58 [PATCH v3 0/7] tools/nolibc: add 32/64-bit powerpc support Zhangjin Wu
2023-07-27 14:59 ` [PATCH v3 1/7] tools/nolibc: add support for powerpc Zhangjin Wu
2023-07-27 15:00 ` [PATCH v3 2/7] tools/nolibc: add support for powerpc64 Zhangjin Wu
2023-07-27 15:02 ` [PATCH v3 3/7] selftests/nolibc: add extra configs customize support Zhangjin Wu
2023-07-29 12:36 ` Thomas Weißschuh
2023-07-29 14:39 ` Zhangjin Wu
2023-07-29 16:29 ` Willy Tarreau [this message]
2023-07-29 16:54 ` Zhangjin Wu
2023-07-29 17:10 ` Willy Tarreau
2023-07-30 4:54 ` Zhangjin Wu
2023-07-30 6:01 ` Zhangjin Wu
2023-07-30 6:18 ` Willy Tarreau
2023-07-30 11:21 ` Zhangjin Wu
2023-07-30 18:02 ` Zhangjin Wu
2023-07-27 15:03 ` [PATCH v3 4/7] selftests/nolibc: add XARCH and ARCH mapping support Zhangjin Wu
2023-07-30 6:38 ` Zhangjin Wu
2023-07-30 7:03 ` Willy Tarreau
2023-07-30 11:36 ` Zhangjin Wu
2023-07-27 15:04 ` [PATCH v3 5/7] selftests/nolibc: add test support for ppc Zhangjin Wu
2023-07-27 15:05 ` [PATCH v3 6/7] selftests/nolibc: add test support for ppc64le Zhangjin Wu
2023-07-27 15:06 ` [PATCH v3 7/7] selftests/nolibc: add test support for ppc64 Zhangjin Wu
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=20230729162907.GA5219@1wt.eu \
--to=w@1wt.eu \
--cc=arnd@arndb.de \
--cc=falcon@tinylab.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=thomas@t-8ch.de \
/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