linux-kernel - Re: [PATCH v2 05/14] selftests/nolibc: add menuconfig for development

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230722123527.GG17311@1wt.eu>
Date:   Sat, 22 Jul 2023 14:35:27 +0200
From:   Willy Tarreau <w@....eu>
To:     Zhangjin Wu <falcon@...ylab.org>
Cc:     thomas@...ch.de, arnd@...db.de, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v2 05/14] selftests/nolibc: add menuconfig for development

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@...ylab.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