linux-kernel - Re: [PATCH v2 2/5] selftests/nolibc: drop call to prepare target

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: <20250201100343.GA5849@1wt.eu>
Date: Sat, 1 Feb 2025 11:03:43 +0100
From: Willy Tarreau <w@....eu>
To: Thomas Weißschuh <linux@...ssschuh.net>
Cc: Shuah Khan <shuah@...nel.org>, linux-kselftest@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/5] selftests/nolibc: drop call to prepare target

On Thu, Jan 23, 2025 at 08:37:38AM +0100, Thomas Weißschuh wrote:
> The "prepare" target does not need to be run manually.
> kbuild knows when to use it on its own and the target is not even
> documented.
> 
> Signed-off-by: Thomas Weißschuh <linux@...ssschuh.net>
> ---
>  tools/testing/selftests/nolibc/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/nolibc/Makefile b/tools/testing/selftests/nolibc/Makefile
> index ba044c8a042ce345ff90bdd35569de4b5acd117d..464165e3d9175d283ec0ed14765df29427b6de38 100644
> --- a/tools/testing/selftests/nolibc/Makefile
> +++ b/tools/testing/selftests/nolibc/Makefile
> @@ -261,7 +261,7 @@ initramfs: nolibc-test
>  	$(Q)cp nolibc-test initramfs/init
>  
>  defconfig:
> -	$(Q)$(MAKE) -C $(srctree) ARCH=$(ARCH) CC=$(CC) CROSS_COMPILE=$(CROSS_COMPILE) mrproper $(DEFCONFIG) prepare
> +	$(Q)$(MAKE) -C $(srctree) ARCH=$(ARCH) CC=$(CC) CROSS_COMPILE=$(CROSS_COMPILE) mrproper $(DEFCONFIG)

I'm pretty sure that in the past I had to manually do it for certain
rebuilds (out of the nolibc-test context), but I cannot say for sure
when, but I did definitely discover it when trying to fix some build
issues. It's very possible that the issues that it used to fix have
long been fixed and that it remained in fingers memory, so I'm fine
with dropping it and we'll see. If we ever discover we need to bring
it back, at least we'll explain why in a commit message this time.

Acked-by: Willy Tarreau <w@....eu>

Willy