[PATCH v2] legacy nfs.c: Change filesystem utime_h handler to utimens_h
Joel Sherrill
joel at rtems.org
Fri May 21 14:43:46 UTC 2021
As a warning, this and the corresponding libbsd patch are queued
behind an RSB patch to get UTIME_NOW and UTIME_OMIT in
newlib. That patch was merged into newlib. Then the RTEMS
*utime* patch set and these two will go in at the same time. Otherwise,
there will be breakage.
On Fri, May 21, 2021 at 9:26 AM Gedare Bloom <gedare at rtems.org> wrote:
> On Mon, May 3, 2021 at 12:41 PM Ryan Long <ryan.long at oarcorp.com> wrote:
> >
> > Changed nfs_utime() to nfs_utimens(), changed the arguments to use
> > a timespec array instead of individual variables for access and
> > modified time.
> >
> > Updates #4400
> > ---
> > nfsclient/src/nfs.c | 50
> +++++++++++++++++++++++++-------------------------
> > 1 file changed, 25 insertions(+), 25 deletions(-)
> >
> > diff --git a/nfsclient/src/nfs.c b/nfsclient/src/nfs.c
> > index bc9a2c6..72fefb9 100644
> > --- a/nfsclient/src/nfs.c
> > +++ b/nfsclient/src/nfs.c
> > @@ -2050,19 +2050,19 @@ static int nfs_rmnod(
> > return rv;
> > }
> >
> > -static int nfs_utime(
> > +static int nfs_utimens(
> > const rtems_filesystem_location_info_t *pathloc, /* IN */
> > - time_t actime, /* IN */
> > - time_t modtime /* IN */
> > + struct timespec times[2] /* IN */
> > +
> > )
> > {
> > sattr arg;
> >
> > /* TODO: add rtems EPOCH - UNIX EPOCH seconds */
> > - arg.atime.seconds = actime;
> > - arg.atime.useconds = 0;
> > - arg.mtime.seconds = modtime;
> > - arg.mtime.useconds = 0;
> > + arg.atime.seconds = times[0].tv_sec;
> > + arg.atime.useconds = times[0].tv_nsec / 1000;
> Do we have a macro exposed for this, like in
> TOD_NANOSECONDS_PER_MICROSECOND? If not, this is fine I suppose.
>
This wouldn't be public since it doesn't start with RTEMS_ and I don't
see any of the TOD_ constants redefined in the RTEMS namespace.
>
> > + arg.mtime.seconds = times[1].tv_sec;
> > + arg.mtime.useconds = times[1].tv_nsec / 1000;
> >
> > return nfs_sattr(pathloc->node_access, &arg, SATTR_ATIME |
> SATTR_MTIME);
> > }
> > @@ -2254,25 +2254,25 @@ sattr arg;
> > }
> >
> > const struct _rtems_filesystem_operations_table nfs_fs_ops = {
> > - .lock_h = nfs_lock,
> > - .unlock_h = nfs_unlock,
> > - .eval_path_h = nfs_eval_path,
> > - .link_h = nfs_link,
> > + .lock_h = nfs_lock,
> > + .unlock_h = nfs_unlock,
> > + .eval_path_h = nfs_eval_path,
> > + .link_h = nfs_link,
> > .are_nodes_equal_h = nfs_are_nodes_equal,
> > - .mknod_h = nfs_mknod,
> > - .rmnod_h = nfs_rmnod,
> > - .fchmod_h = nfs_fchmod,
> > - .chown_h = nfs_chown,
> > - .clonenod_h = nfs_clonenode,
> > - .freenod_h = nfs_freenode,
> > - .mount_h = rtems_filesystem_default_mount,
> > - .unmount_h = rtems_filesystem_default_unmount,
> > - .fsunmount_me_h = nfs_fsunmount_me,
> > - .utime_h = nfs_utime,
> > - .symlink_h = nfs_symlink,
> > - .readlink_h = nfs_readlink,
> > - .rename_h = nfs_rename,
> > - .statvfs_h = rtems_filesystem_default_statvfs
> > + .mknod_h = nfs_mknod,
> > + .rmnod_h = nfs_rmnod,
> > + .fchmod_h = nfs_fchmod,
> > + .chown_h = nfs_chown,
> > + .clonenod_h = nfs_clonenode,
> > + .freenod_h = nfs_freenode,
> > + .mount_h = rtems_filesystem_default_mount,
> > + .unmount_h = rtems_filesystem_default_unmount,
> > + .fsunmount_me_h = nfs_fsunmount_me,
> > + .utimens_h = nfs_utimens,
> > + .symlink_h = nfs_symlink,
> > + .readlink_h = nfs_readlink,
> > + .rename_h = nfs_rename,
> > + .statvfs_h = rtems_filesystem_default_statvfs
> Why so many additional whitespace changes?
>
> > };
> >
> > /*****************************************
> > --
> > 1.8.3.1
> >
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210521/b9821859/attachment.html>
More information about the devel
mailing list