LLM disclosure (was: [PATCH v2] vfs: remove the excl argument from the ->create() inode_operation)
NeilBrown
neilb at ownmail.net
Fri Nov 7 15:37:30 PST 2025
On Sat, 08 Nov 2025, Jeff Layton wrote:
> On Fri, 2025-11-07 at 15:35 -0700, Jonathan Corbet wrote:
> > NeilBrown <neilb at ownmail.net> writes:
> >
> > > On Sat, 08 Nov 2025, Jeff Layton wrote:
> >
> > > > Full disclosure: I did use Claude code to generate the first
> > > > approximation of this patch, but I had to fix a number of things that it
> > > > missed. I probably could have given it better prompts. In any case, I'm
> > > > not sure how to properly attribute this (or if I even need to).
> > >
> > > My understanding is that if you fully understand (and can defend) the
> > > code change with all its motivations and implications as well as if you
> > > had written it yourself, then you don't need to attribute whatever fancy
> > > text editor or IDE (e.g. Claude) that you used to help produce the
> > > patch.
> >
> > The proposed policy for such things is here, under review right now:
> >
> > https://lore.kernel.org/all/20251105231514.3167738-1-dave.hansen@linux.intel.com/
> >
> > jon
>
> Thanks Jon.
>
> I'm guessing that this would fall under the "menial task"
> classification, and therefore doesn't need attribution. This seems
> applicable:
>
> + - Purely mechanical transformations like variable renaming
>
> This is a little different, but it's a similar rote task.
> --
> Jeff Layton <jlayton at kernel.org>
>
The bit I particularly liked was:
+
+Even if your tool use is out of scope you should still always consider
+if it would help reviewing your contribution if the reviewer knows
+about the tool that you used.
+
"would it help the reviewer"? I agree that is a key question. In your
case I cannot see how it would help.
Thanks,
NeilBrown
More information about the linux-um
mailing list