public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Luis Augenstein <luis.augenstein@tngtech.com>,
	Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
	Greg KH <gregkh@linuxfoundation.org>
Cc: 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, 27 Jan 2026 16:10:37 -0700	[thread overview]
Message-ID: <20260127231037.GA3378797@ax162> (raw)
In-Reply-To: <a01233b9-23a2-4666-91ed-f1cf030dcb9f@tngtech.com>

Hi Luis, Greg, and Miguel,

Sorry for not having any input up until this point, as I felt this was
not going to be ready for 6.20/7.0 and I wanted to focus on getting
things ready for that release (on top of other work). Some high level
comments based on what has been discussed so far to follow, it was going
to be hard to reply inline to everything. I will try to take a closer
look at v3 in the next couple of weeks but I might not get to it until
after the merge window closes.

I agree with Miguel that if there is any information that we can add to
the .cmd files or another file generated by Kbuild to avoid hard coding
things while preprocessing, it should be pursued, as we should be making
the build system work for us. We have already some prior art with post
processing Kbuild files like scripts/clang-tools/gen_compile_commands.py
so I am not too worried about that. At the same time, I do like how self
contained the implementation currently is, as it is just there available
for people to use if they want it but it impacts nothing if it is not
being used. It also makes it an easier maintenance burden in the
immediate term, as I would like this to be shown as useful to various
entities before it starts to entangle itself into the build system.

I think getting rid of CONFIG_SBOM in favor of just an sbom make target
is a good direction. If we really wanted some sort of configuration
option, I think it should only mean "generate an SBOM by default" and
nothing more but I worry about this getting turned on via compile
testing and causing issues. At that point, it feels like whatever entity
wants this information can just add 'make sbom' to their build system
since they may have to control the outputs beyond the simple "all" make
target.

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.

Cheers,
Nathan

  reply	other threads:[~2026-01-27 23:10 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-20 11:53 [PATCH v2 00/14] Add SPDX SBOM generation tool 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 [this message]
2026-02-02 16:28               ` Luis Augenstein
2026-02-03  0:40                 ` Nathan Chancellor
2026-02-03 14:41                   ` Luis Augenstein
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=20260127231037.GA3378797@ax162 \
    --to=nathan@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luis.augenstein@tngtech.com \
    --cc=maximilian.huber@tngtech.com \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --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