All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Zhangjin Wu <falcon@tinylab.org>
Cc: arnd@arndb.de, linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org, thomas@t-8ch.de
Subject: Re: [PATCH v3 3/7] selftests/nolibc: add extra configs customize support
Date: Sun, 30 Jul 2023 08:18:01 +0200	[thread overview]
Message-ID: <20230730061801.GA7690@1wt.eu> (raw)
In-Reply-To: <20230730060131.10061-1-falcon@tinylab.org>

Hi Zhangjin,

On Sun, Jul 30, 2023 at 02:01:31PM +0800, Zhangjin Wu wrote:
> > > > Seems 'nolibc-test-config' is really more meaningful than 'defconfig', especially
> > > > when we want to use tinyconfig through it?
> > > > 
> > > >     $ make nolibc-test-config DEFCONFIG=tinyconfig
> > > 
> > > As a user, I'd ask "why not make tinyconfig" ? But see my other message,
> > > now I'm having strong doubts about the relevance of tinyconfig if it works
> > > as bad as you described it.
> > >
> > 
> > I have added a nolibc tinyconfig target before, as the same reason,
> > based on your suggestion, I have removed the tinyconfig target and even
> > moved the extconfig to this defconfig to avoid add more similar or extra
> > complex targets in nolibc Makefile. before, tinyconfig + extconfig
> > together work for nolibc-test, so, tinyconfig is the same as the
> > top-level one, it should be removed as your suggested.
> > 
> > But since now, we are ready to get a real different target from the
> > top-level one, we may be able to have different targets for
> > 'defconfig+EXTRA_CONFIG' and 'tinyconfig+EXTRA_CONFIG' like this:
> > 
> >     nolibc-test-config:
> >             $(Q)echo $(MAKE_KERNEL) mrproper $(or $(CONFIG),defconfig)
> 
> It should be $(or $(CONFIG),$(DEFCONFIG))
> 
> >             $(Q)echo $(srctree)/scripts/kconfig/merge_config.sh -Q -O "$(objtree)" -m "$(KERNEL_CONFIG)" $(foreach c,$(EXTRA_CONFIG),$(wildcard $(CURDIR)/configs/$c))
> >             $(Q)echo $(MAKE_KERNEL) KCONFIG_ALLCONFIG="$(KERNEL_CONFIG)" allnoconfig
> >             $(Q)echo $(MAKE_KERNEL) prepare
> > 
> >     nolibc-test-defconfig nolibc-test-tinyconfig: nolibc-test-config
> >     nolibc-test-tinyconfig: CONFIG=tinyconfig
> >
> 
> The above two are not really required in this powerpc series, let's delay them
> to the next tinyconfig part1 series.
> 
> In this series, we only need:
> 
>      nolibc-test-config:
>              $(Q)$(MAKE_KERNEL) mrproper $(or $(CONFIG),$(DEFCONFIG))
>              $(Q)$(srctree)/scripts/kconfig/merge_config.sh -Q -O "$(objtree)" -m "$(KERNEL_CONFIG)" $(foreach c,$(EXTRA_CONFIG),$(wildcard $(CURDIR)/configs/$c))
>              $(Q)$(MAKE_KERNEL) KCONFIG_ALLCONFIG="$(KERNEL_CONFIG)" allnoconfig
>              $(Q)$(MAKE_KERNEL) prepare
> 
> And this:
> 
>     # extra configs/ files appended to .config during the nolibc-test-config target
>     # include common + architecture specific
>     EXTRA_CONFIG         = common.config $(XARCH).config
> 
> And the update of the help target too.
> 
> If both of you are happy with this? let's do it ;-)

Well, I understand "nolibc-test-config" as "the config suitable to
correctly run nolibc-test". In that case I agree. We can indeed start
from the defconfig, and if we manage to refine it we can later map it
to anything else that's known to work. And if we eventually split
nolibc-test into multiple tests (libc, syscalls, ipc, network, whatever)
then we might as well adopt different configs in the future. I'd also
want to keep defconfig on its own because it relies on each arch's
defconfig and is a simple way to verify they work (as they should).
As I said, till now I haven't met issues with defconfig so probably
we don't need to patch it, but we could revisit that option later if
needed.

I'm still having that question about your "make allnoconfig" at the
end, which for me simply replaces the config you've just created, thus
which makes no sense. There might be a trick that I'm missing but if so
it should be explained there because the only situation where anybody
should start a question with "why" when reading code is when they
discovered a bug.

Also please split the mrproper and defconfig on two distinc lines, as
there's no point anymore in keeping them as a single one.

Since you're using the extra options for nolibc-test-config, I think
they should be called "nolibc-test-common.config" and
"nolibc-test-$XARCH.config" so that we don't restart with tons of
"if" and macros when adding a new target.

Thomas, are you also OK with this ?

Thanks,
Willy

  reply	other threads:[~2023-07-30  6:18 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
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 [this message]
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=20230730061801.GA7690@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.