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 D098877F39; Tue, 3 Feb 2026 00:40:36 +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=1770079236; cv=none; b=aybPxzW1cZ4MrKyfit7Kl131nG2SLJ06BnXwNcBmr0RVRZlMEqvLVnmnyCY+crvZ/oY/88+HeiBa+KoNQXrzqrbj9eTeldNOs/xH6Anqj/DnCekWpeUn2bfE2VW7kGjFDE3bTw/F2lUdLGfCWohn2gVIzz8U5LvY5pO6iHlKlcY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770079236; c=relaxed/simple; bh=r07P9KyyXMWvtCnmo/ELc9mFvwuiiBSsYPtw1lMOTic=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ErwX1Zp4/im9GtcPVp3gS4flo3W47u2sQiwasIPDHkB/LTcxtk/wB2m6sO0Z+MClfcHziaklhMcuPo3KRl8f2oGb2IDTHejvsZ2pLqEwUTCqqcSNmEWIEEf7yJnVC3Q4Kr8J+0LLc4G6w7F7zuiBbfzcnAamiaUQrDJxp19kQ2o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pCS9vnWY; 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="pCS9vnWY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 16B47C116C6; Tue, 3 Feb 2026 00:40:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770079236; bh=r07P9KyyXMWvtCnmo/ELc9mFvwuiiBSsYPtw1lMOTic=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pCS9vnWYs2VJ0tS1tZryolzMh2XzSjDx+gVankLB/BrNjDRBzmAnEDMRk0fPznXo4 lJdIZIh93M2QrgYTjwMZsvG7vuFN4NbqVI2p2Nd7kgou3pPNlBhsiLxONNiP5SHwlY P9w2wK1ZPz3q+NqO6Vz+r7NsKXw8ACT9kWyG1vmIW2rJEFaKA8nLFg5UuZjemApTAI u3Cu9EHYHivDsR/Rv5cDO7o3sI3rsxTuRB8IivPix05Z55j0qcPWMGOkVu4RuNGJ5G KIxHUHhWG87LVYA4lqacFNm9ksTSpN6UiGyrLANsCCCv70ej8C6r1KwwkAUXZ0Saml CZs5RDfT5Tk2g== Date: Mon, 2 Feb 2026 17:40:32 -0700 From: Nathan Chancellor To: Luis Augenstein Cc: Miguel Ojeda , Greg KH , nsc@kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, maximilian.huber@tngtech.com Subject: Re: [PATCH v2 00/14] Add SPDX SBOM generation tool Message-ID: <20260203004032.GA52989@ax162> References: <20260120115352.10910-1-luis.augenstein@tngtech.com> <2026012214-magician-mashed-c84c@gregkh> <2026012533-preflight-surviving-43e5@gregkh> <20260127231037.GA3378797@ax162> <6ed0fe99-3724-40c2-8d98-3309a3cf0104@tngtech.com> Precedence: bulk X-Mailing-List: linux-kbuild@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6ed0fe99-3724-40c2-8d98-3309a3cf0104@tngtech.com> Hi Luis, On Mon, Feb 02, 2026 at 05:28:39PM +0100, Luis Augenstein wrote: > > I wonder if it would be better for this to live within scripts/ instead > > of tools/, as that should allow it to be integrated into the build > > process a little bit more naturally, such as using $(Q) instead of @, > > $(PYTHON3) instead of the bare python3, being able to access > > CONFIG_MODULES directly, and cleaning up the actual implementation of > > the sbom target in Makefile. > > Thanks, I wasn’t aware that targets under scripts/ have access to more > Make variables by default. During development, we didn’t have strong I think this is a byproduct of being fully within Kbuild at that point, rather than in the tools/ build system. > reasons for choosing either tools/ or scripts/. I’m happy to move it to > scripts/ if that is the preferred location. Yes please. If this tool is designed to run within and parse Kbuild, it should live fully within Kbuild, as the "tools build system" comment in Makefile added by Masahiro in commit 6e6ef2da3a28 ("Makefile: add comment to discourage tools/* addition for kernel builds") notes (even though this is not a C program so the hostprogs comment is irrelevant here). scripts/sbom seems entirely reasonable to me. > Regarding $(Q) and $(PYTHON3), I noticed that these variables are > actually available within the tools/ directory as well, so we could > switch to using them even if we stay under tools/. Ah, good to know. I do not delve into the tools build system all too much. > CONFIG_MODULES and src_tree, on the other hand, need to be passed > explicitly when staying in tools/, whereas they would be available by > default under scripts/ in which case we could simply invoke the script via: > ```Makefile > PHONY += sbom > sbom: all > $(Q)$(MAKE) $(build)=scripts/sbom > ``` > > So yes, I think it makes sense to move it to scripts then. Yeah, that looks much cleaner to me. I suspect scripts/sbom/Makefile could be cleaned up a little bit as a result of that move as well. Also, two other comments I forgot to bring up: 1. With the movement out of tools/, I think the README should become a proper Documentation file so that its contents is more discoverable. That should probably be separate from the change that adds the initial SBOM scaffolding in Kbuild to help with review. 2. This depends on having a clean initial build tree (either empty directory or 'clean' as a make target) due to needing to parse the .cmd files, which could be stale if someone builds a kernel, changes their config, and rebuilds, right? This should be documented since I do not think it is possible to do something like what Masahiro did in commit 3d32285fa995 ("kbuild: wire up the build rule of compile_commands.json to Makefile") because of the drawback that it misses too many things. Cheers, Nathan