* Sasha Levin (sas...@kernel.org) wrote: > On Thu, Jul 24, 2025 at 04:54:11PM -0700, Kees Cook wrote: > > On Thu, Jul 24, 2025 at 07:45:56PM -0400, Steven Rostedt wrote: > > > My thought is to treat AI as another developer. If a developer helps you > > > like the AI is helping you, would you give that developer credit for that > > > work? If so, then you should also give credit to the tooling that's > > > helping > > > you. > > > > > > I suggested adding a new tag to note any tool that has done non-trivial > > > work to produce the patch where you give it credit if it has helped you as > > > much as another developer that you would give credit to. > > > > We've got tags to choose from already in that case: > > > > Suggested-by: LLM > > > > or > > > > Co-developed-by: LLM <n...@human.with.legal.standing> > > Signed-off-by: LLM <n...@human.with.legal.standing> > > > > The latter seems ... not good, as it implies DCO SoB from a thing that > > can't and hasn't acknowledged the DCO. > > In my mind, "any tool" would also be something like gcc giving you a > "non-trivial" error (think something like a buffer overflow warning that > could have been a security issue). > > In that case, should we encode the entire toolchain used for developing > a patch? > > Maybe... > > Some sort of semi-standardized shorthand notation of the tooling used to > develop a patch could be interesting not just for plain disclosure, but > also to be able to trace back issues with patches ("oh! the author > didn't see a warning because they use gcc 13 while the warning was added > in gcc 14!"). > > Signed-off-by: John Doe <j...@example.com> # > gcc:14.1;ccache:1.2;sparse:4.7;claude-code:0.5 > > This way some of it could be automated via git hooks and we can recommend > a relevant string to add with checkpatch.
For me there are two separate things: a) A tool that found a problem b) A tool that wrote a piece of code. I think the cases you're referring to are all (a), where as I'm mostly thinking here about (b). In the case of (a) it's normally _one_ of those tools that found it, e.g. I see some: Found by gcc -fanalyzer but we don't have a defined way to refer to them. I also see a variety from coverity, e.g. Addresses-Coverity: xxxxx or the use of Link: to refer to a coverity failure or Addresses-Coverity-ID: xxxx ("Description of it") or a few others. It would be great to standardise some of that as well. Dave > -- > Thanks, > Sasha > -- -----Open up your eyes, open up your mind, open up your code ------- / Dr. David Alan Gilbert | Running GNU/Linux | Happy \ \ dave @ treblig.org | | In Hex / \ _________________________|_____ http://www.treblig.org |_______/