Re: LLM disclosure (was: [PATCH v2] vfs: remove the excl argument from the ->create() inode_operation)
Jeff Layton <[email protected]> Fri, 07 Nov 2025 18:19:24 -0500
| Newsgroups | gmane.comp.file-systems.ext4,gmane.linux.kernel,gmane.linux.file-systems,gmane.comp.file-systems.btrfs,gmane.comp.file-systems.ceph.devel,gmane.comp.file-systems.coda.general,gmane.comp.file-systems.ecryptfs.general,gmane.linux.kernel.efi,gmane.linux.file-systems.f2fs,gmane.linux.uml.devel,gmane.linux.kernel.mm,gmane.linux.drivers.mtd,gmane.linux.nfs,gmane.comp.file-systems.nilfs.user,gmane.linux.hardware.karma.devel,gmane.linux.file-systems.union,gmane.linux.kernel.cifs,gmane.network.samba.internals,gmane.linux.documentation |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 2025-11-07 at 15:35 -0700, Jonathan Corbet wrote: > NeilBrown <[email protected]> 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/[email protected]/ > > 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 <[email protected]>