From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 81FC1267B90; Sat, 28 Feb 2026 05:53:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772258031; cv=none; b=de7Ankv2VTHbJnRxNGICa2eqZWGOE8PWlsBYBRjpUzgDbxlITUcRzMCYxpFeTM7wgjz5XJPGD/96oA+XegtyTjUkxngjV3d/fzZNSM1g0oLn4P6BeokKBlEEnszNuqqpqUUnd7jxH47HAppGJ5asqmZoUULxGOXnVbcQaF4h3rs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772258031; c=relaxed/simple; bh=pBEV+jBvJvdSoPvJVuVxRapAX5gdRdCbYo9cbLc5UCk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=h9i6/aLzVb0TdqgjULOpGMrFhfnMHxv//EV7EXJVxOe594qb4mhqBtfxWPBX0ZZCPZqumaOaIwBQheB+emK1jqF73r9/08kFalNVabl6fIVvUbnaxbDTpyoH2l9y4L8WvZ6K6KiCWou+/z45oZPyLXkAsqagT2zweUgCIjKyfUQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=m1I9Ib3x; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="m1I9Ib3x" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8006C116D0; Sat, 28 Feb 2026 05:53:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772258031; bh=pBEV+jBvJvdSoPvJVuVxRapAX5gdRdCbYo9cbLc5UCk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=m1I9Ib3xGI8AzHZj+4PTU9jvIRHD3TiXxNOtYDornttDTtObrQvCo2bmoPaTzrPFD CJnseTLJMkuwdFBzW41HTiSrkzPrs7GoqAgVK7QKAuD3BWNMdxhEBhiCYgjRBWDPd1 J1TWl528T+LxgCji917IhHvWlo08DOxynWU6Uz7uozFbBYMe7niM3tNAA543tlqZMo TcjY8gQLq6CXdzvIUBDdkMiFiqI3i2YKoIDg5fgy0jEJcanvMJZY+CJObFiMYJz3e8 vQkQd7gTfm9WoOoBtF/CjL6OgFv/uhHrEZFOxzjxfVN6NSBXHEI4SDJpcs2xr3wkWi czBTuV+nt1bGg== Date: Fri, 27 Feb 2026 22:53:46 -0700 From: Nathan Chancellor To: Michal =?iso-8859-1?Q?Such=E1nek?= Cc: Josh Poimboeuf , linux-kbuild@vger.kernel.org, Nicolas Schier , Masahiro Yamada , Miguel Ojeda , Thomas =?iso-8859-1?Q?Wei=DFschuh?= , Tamir Duberstein , Steven Rostedt , linux-kernel@vger.kernel.org, Jiri Slaby Subject: Re: [PATCH] kbuild: only clean objtool on mrproper Message-ID: <20260228055346.GA2321981@ax162> References: <20260225112633.6123-1-msuchanek@suse.de> <20260225200417.GE2755225@ax162> <20260225212105.GG2755225@ax162> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20260225212105.GG2755225@ax162> On Wed, Feb 25, 2026 at 02:21:05PM -0700, Nathan Chancellor wrote: > On Wed, Feb 25, 2026 at 09:23:09PM +0100, Michal Suchánek wrote: > > On Wed, Feb 25, 2026 at 01:04:17PM -0700, Nathan Chancellor wrote: > > > Wouldn't resolve_btfids need the same treatment? > > > > No, make clean runs the clean target for resolve_btfids but the tool > > remains. > > That does not reproduce for me personally: > > $ cat kernel/configs/btf.config > CONFIG_BPF_SYSCALL=y > # CONFIG_DEBUG_INFO_NONE is not set > CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y > CONFIG_DEBUG_INFO_BTF=y > > $ make -skj"$(nproc)" ARCH=x86_64 O=build mrproper defconfig btf.config prepare > > $ ls -al build/tools/{bpf/resolve_btfids/resolve_btfids,objtool/objtool} > -rwxr-xr-x 1 nathan nathan 2224456 Feb 25 13:33 build/tools/bpf/resolve_btfids/resolve_btfids > -rwxr-xr-x 1 nathan nathan 4046296 Feb 25 13:33 build/tools/objtool/objtool > > $ make -skj"$(nproc)" ARCH=x86_64 O=build clean > > $ ls -al build/tools/{bpf/resolve_btfids/resolve_btfids,objtool/objtool} > "build/tools/bpf/resolve_btfids/resolve_btfids": No such file or directory (os error 2) > "build/tools/objtool/objtool": No such file or directory (os error 2) > > I guess resolve_btfids is not strictly required for external module > builds because vmlinux may not be present and cmd_btf_ko handles that > gracefully. To close the loop here, 'make clean' removes vmlinux and resolve_btfids at the same time and the check in cmd_btf_ko prevents that from becoming a hard error. So technically no problem but a little fragile. > > > Also, what's the use case? Running 'make clean' then copying what > > > is left? > > > > Yes, that's what my build script has been doing for at least a decade, > > possibly mutiple decades when it was somebody else's build script. > > I guess that is one way to ensure 'make clean' upholds its promise of > leaving just enough to build external modules. I had missed that in > review of this change. > > Another option would be splitting tools/objtool's clean target into > clean and mrproper like the main kernel and mirroring what that does so > that objtool the binary can remain around while all its objects get > cleaned up. FWIW, I sent this as an alternative since I think it adheres a little more to Kbuild's contract that 'make clean' leaves enough around for external module builds while removing all unneeded generated files: https://lore.kernel.org/20260227-avoid-objtool-binary-removal-clean-v1-1-122f3e55eae9@kernel.org/ Cheers, Nathan