From: Luis Augenstein <luis.augenstein@tngtech.com>
To: Nathan Chancellor <nathan@kernel.org>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
Greg KH <gregkh@linuxfoundation.org>,
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
Date: Tue, 3 Feb 2026 15:41:42 +0100 [thread overview]
Message-ID: <a6f5f9e9-3652-4aff-8422-05e1c88850de@tngtech.com> (raw)
In-Reply-To: <20260203004032.GA52989@ax162>
[-- Attachment #1.1.1: Type: text/plain, Size: 1520 bytes --]
Hi Nathan,
> 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.
There might be edge cases, but in general stale .cmd files should not be
an issue.
The script does not scan the build tree for .cmd files. It starts from a
set of root build artifacts (kernel image and .ko modules listed in
modules.order). From these roots, it parses the corresponding .cmd files
to discover the immediate dependencies, and then recursively processes
the .cmd files of those dependencies, effectively walking the entire
dependency graph up to the individual source files.
Stale .cmd files should not be referenced as dependencies by the root
artifacts and therefore not be part of the resulting dependency graph.
Best,
Luis
--
Luis Augenstein * luis.augenstein@tngtech.com * +49-152-25275761
TNG Technology Consulting GmbH, Beta-Str. 13, 85774 Unterföhring
Geschäftsführer: Henrik Klagges, Dr. Robert Dahlke, Thomas Endres
Aufsichtsratsvorsitzender: Christoph Stock
Sitz: Unterföhring * Amtsgericht München * HRB 135082
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3207 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
next prev parent reply other threads:[~2026-02-03 14:41 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-20 11:53 Luis Augenstein
2026-01-20 11:53 ` [PATCH v2 01/14] tools/sbom: integrate tool in make process Luis Augenstein
2026-01-20 11:53 ` [PATCH v2 02/14] tools/sbom: setup sbom logging Luis Augenstein
2026-01-20 11:53 ` [PATCH v2 03/14] tools/sbom: add command parsers Luis Augenstein
2026-01-20 11:53 ` [PATCH v2 04/14] tools/sbom: add cmd graph generation Luis Augenstein
2026-01-20 11:53 ` [PATCH v2 05/14] tools/sbom: add additional dependency sources for cmd graph Luis Augenstein
2026-01-20 11:53 ` [PATCH v2 06/14] tools/sbom: add SPDX classes Luis Augenstein
2026-01-20 11:53 ` [PATCH v2 07/14] tools/sbom: add JSON-LD serialization Luis Augenstein
2026-01-20 11:53 ` [PATCH v2 08/14] tools/sbom: add shared SPDX elements Luis Augenstein
2026-01-20 11:53 ` [PATCH v2 09/14] tools/sbom: collect file metadata Luis Augenstein
2026-01-20 11:53 ` [PATCH v2 10/14] tools/sbom: add SPDX output graph Luis Augenstein
2026-01-20 11:53 ` [PATCH v2 11/14] tools/sbom: add SPDX source graph Luis Augenstein
2026-01-20 11:53 ` [PATCH v2 12/14] tools/sbom: add SPDX build graph Luis Augenstein
2026-01-20 11:53 ` [PATCH v2 13/14] tools/sbom: add unit tests for command parsers Luis Augenstein
2026-01-22 6:00 ` Miguel Ojeda
2026-01-22 20:01 ` Luis Augenstein
2026-01-20 11:53 ` [PATCH v2 14/14] tools/sbom: add unit tests for SPDX-License-Identifier parsing Luis Augenstein
2026-01-20 15:40 ` [PATCH v2 00/14] Add SPDX SBOM generation tool Greg KH
2026-01-20 16:14 ` Luis Augenstein
2026-01-22 6:18 ` Miguel Ojeda
2026-01-22 6:35 ` Greg KH
2026-01-25 15:20 ` Miguel Ojeda
2026-01-25 15:33 ` Miguel Ojeda
2026-01-25 15:40 ` Greg KH
2026-01-25 15:34 ` Greg KH
2026-01-25 17:24 ` Miguel Ojeda
2026-01-27 8:03 ` Luis Augenstein
2026-01-27 23:10 ` Nathan Chancellor
2026-02-02 16:28 ` Luis Augenstein
2026-02-03 0:40 ` Nathan Chancellor
2026-02-03 14:41 ` Luis Augenstein [this message]
2026-02-03 20:51 ` Nathan Chancellor
2026-01-22 20:32 ` Luis Augenstein
2026-01-25 15:30 ` Miguel Ojeda
2026-01-26 6:46 ` Luis Augenstein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a6f5f9e9-3652-4aff-8422-05e1c88850de@tngtech.com \
--to=luis.augenstein@tngtech.com \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maximilian.huber@tngtech.com \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=nathan@kernel.org \
--cc=nsc@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®