On Thu, 2023-06-22 at 09:46 +0900, Damien Le Moal wrote: > On 6/21/23 23:45, Jeff Layton wrote: > > struct timespec64 has unused bits in the tv_nsec field that can be used > > for other purposes. In future patches, we're going to change how the > > inode->i_ctime is accessed in certain inodes in order to make use of > > them. In order to do that safely though, we'll need to eradicate raw > > accesses of the inode->i_ctime field from the kernel. > > > > Add new accessor functions for the ctime that we can use to replace them. > > > > Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxx> > > [...] > > > +/** > > + * inode_ctime_peek - fetch the current ctime from the inode > > + * @inode: inode from which to fetch ctime > > + * > > + * Grab the current ctime from the inode and return it. > > + */ > > +static inline struct timespec64 inode_ctime_peek(const struct inode *inode) > > To be consistent with inode_ctime_set(), why not call this one inode_ctime_get() In later patches fetching the ctime for presentation may have side effects on certain filesystems. Using "peek" here is a hint that we want to avoid those side effects in these calls. > ? Also, inode_set_ctime() & inode_get_ctime() may be a little more natural. But > no strong opinion about that though. > I like the consistency of the inode_ctime_* prefix. It makes it simpler to find these calls when grepping, etc. That said, my opinions on naming are pretty loosely-held, so if the consensus is that the names should as you suggest, I'll go along with it. -- Jeff Layton <jlayton@xxxxxxxxxx>
