Thread (7 messages) flat view 7 messages, 5 authors, 2025-11-08

Re: LLM disclosure (was: [PATCH v2] vfs: remove the excl argument from the ->create() inode_operation)

From: Jeff Layton <jlayton@kernel.org>
Date: 2025-11-07 23:19:32
Also in: ceph-devel, gfs2, linux-btrfs, linux-cifs, linux-efi, linux-ext4, linux-f2fs-devel, linux-fsdevel, linux-hardening, linux-mm, linux-nfs, linux-um, linux-unionfs, linux-xfs, lkml, ntfs3, ocfs2-devel, v9fs

On Fri, 2025-11-07 at 15:35 -0700, Jonathan Corbet wrote:
NeilBrown [off-list ref] writes:
quoted
On Sat, 08 Nov 2025, Jeff Layton wrote:
quoted
quoted
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/ (local)

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 [off-list ref]
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help