Message ID | 20230621144507.55591-1-jlayton@kernel.org (mailing list archive) |
---|---|
Headers | show |
Series | fs: new accessors for inode->i_ctime | expand |
On Wed, 21 Jun 2023 10:45:05 -0400 Jeff Layton <jlayton@kernel.org> wrote: > Most of this conversion was done via coccinelle, with a few of the more > non-standard accesses done by hand. There should be no behavioral > changes with this set. That will come later, as we convert individual > filesystems to use multigrain timestamps. BTW, Linus has suggested to me that whenever a conccinelle script is used, it should be included in the change log. -- Steve
On Wed, 2023-06-21 at 15:21 -0400, Steven Rostedt wrote: > On Wed, 21 Jun 2023 10:45:05 -0400 > Jeff Layton <jlayton@kernel.org> wrote: > > > Most of this conversion was done via coccinelle, with a few of the more > > non-standard accesses done by hand. There should be no behavioral > > changes with this set. That will come later, as we convert individual > > filesystems to use multigrain timestamps. > > BTW, Linus has suggested to me that whenever a conccinelle script is used, > it should be included in the change log. > Ok, here's what I have. I note again that my usage of coccinelle is pretty primitive, so I ended up doing a fair bit of by-hand fixing after applying these. Given the way that this change is broken up into 77 patches by subsystem, to which changelogs should I add it? I could add it to the "infrastructure" patch, but that's the one where I _didn't_ use it. Maybe to patch #79 (the one that renames i_ctime)? ------------------------8<------------------------------ @@ expression inode; @@ - inode->i_ctime = current_time(inode) + inode_set_current_ctime(inode) @@ expression inode; @@ - inode->i_ctime = inode->i_mtime = current_time(inode) + inode->i_mtime = inode_set_current_ctime(inode) @@ struct inode *inode; expression value; @@ - inode->i_ctime = value; + inode_set_ctime(inode, value); @@ struct inode *inode; expression val; @@ - inode->i_ctime.tv_sec = val + inode_set_ctime_sec(inode, val) @@ struct inode *inode; expression val; @@ - inode->i_ctime.tv_nsec = val + inode_set_ctime_nsec(inode, val) @@ struct inode *inode; @@ - inode->i_ctime + inode_ctime_peek(inode)
On Wed, Jun 21, 2023 at 03:52:27PM -0400, Jeff Layton wrote: > On Wed, 2023-06-21 at 15:21 -0400, Steven Rostedt wrote: > > On Wed, 21 Jun 2023 10:45:05 -0400 > > Jeff Layton <jlayton@kernel.org> wrote: > > > > > Most of this conversion was done via coccinelle, with a few of the more > > > non-standard accesses done by hand. There should be no behavioral > > > changes with this set. That will come later, as we convert individual > > > filesystems to use multigrain timestamps. > > > > BTW, Linus has suggested to me that whenever a conccinelle script is used, > > it should be included in the change log. > > > > Ok, here's what I have. I note again that my usage of coccinelle is > pretty primitive, so I ended up doing a fair bit of by-hand fixing after > applying these. > > Given the way that this change is broken up into 77 patches by > subsystem, to which changelogs should I add it? I could add it to the > "infrastructure" patch, but that's the one where I _didn't_ use it. > > Maybe to patch #79 (the one that renames i_ctime)? That works. I can also put this into a merge commit or pr message.
On Wed, Jun 21, 2023 at 03:21:41PM -0400, Steven Rostedt wrote: > On Wed, 21 Jun 2023 10:45:05 -0400 > Jeff Layton <jlayton@kernel.org> wrote: > > > Most of this conversion was done via coccinelle, with a few of the more > > non-standard accesses done by hand. There should be no behavioral > > changes with this set. That will come later, as we convert individual > > filesystems to use multigrain timestamps. > > BTW, Linus has suggested to me that whenever a conccinelle script is used, > it should be included in the change log. Sometimes people like the coccinelle included in the commit, sometimes people don't [0], it really ends up being up to a subjective maintainer preference. A compromise could be to use git notes as these are optional, however if we want to go down that path we should try to make a general consensus on it so we can send a consistent message. [0] https://lore.kernel.org/all/20230512073100.GC32559@twin.jikos.cz/ Luis