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;
Date:   Sat, 22 Jul 2023 14:35:27 +0200
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 v2 05/14] selftests/nolibc: add menuconfig for development
Message-ID: <20230722123527.GG17311@1wt.eu>
References: <cover.1689759351.git.falcon@tinylab.org>
 <a7fcca12e0f567efd29314172ccf1ad4cd279bf7.1689759351.git.falcon@tinylab.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a7fcca12e0f567efd29314172ccf1ad4cd279bf7.1689759351.git.falcon@tinylab.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

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