Re: [RFC PATCH] docs: submitting-patches: (AI?) Tool disclosure tag

[Kees Cook <kees@kernel.org>]

On Thu, Jul 24, 2025 at 03:07:17PM -0400, Konstantin Ryabitsev wrote:
> On Thu, Jul 24, 2025 at 06:54:39PM +0100, linux@treblig.org wrote:
> > From: "Dr. David Alan Gilbert" <linux@treblig.org>
> > 
> > It seems right to require that code which is automatically
> > generated is disclosed in the commit message.
> 
> I'm not sure that's the case. There is a lot of automatically generated
> content being added to the kernel all the time -- such as auto-formatted code,
> documentation, and unit tests generated by non-AI tooling. We've not required
> indicating this usage before, so I'm not sure it makes sense to start doing it
> now.
> 
> Furthermore, merely indicating the tool doesn't really say anything about how
> it was used (e.g. what version, what prompt, what context, etc.) If anything,
> this information needs to live in the cover letter of the submission. I would
> suggest we investigate encouraging contributors to disclose this there, e.g.:
> 
> | ---
> | This patch series was partially generated with "InsensitiveClod o4 Hokus"
> | and then heavily modified to remove the parts where it went completely off
> | the deep end.
> 
> I am also not opposed to having a more standard cover letter footer that would
> allow an easier way to query this information via public-inbox services, e.g.:
> 
> | generated-by: insensitive clod o4 hokus
> 
> However, I don't really think this belongs in the commit trailers.

I agree; I'm not sure I see a benefit in creating a regularized trailer
for this. What automation/tracking is going to key off of it? It's
a detail of patch creation methodology, so the commentary about how
something was created is best put in the prose areas, like we already
do for Coccinelle or other scripts. It's a bit buried in the Researcher
Guidelines[1], but we have explicitly asked for details about tooling:

  When sending patches produced from research, the commit logs should
  contain at least the following details, so that developers have
  appropriate context for understanding the contribution.
  ...
  Specifically include details about any testing, static or dynamic
  analysis programs, and any other tools or methods used to perform the
  work.

Maybe that needs to be repeated in SubmittingPatches?

-Kees

[1] https://docs.kernel.org/process/researcher-guidelines.html

-- 
Kees Cook